Re: USB Ethernet gadget on Nokia n900
* Pali Rohár [150707 00:48]: > On Monday 06 July 2015 06:53:18 Tony Lindgren wrote: > > * Pali Rohár [150706 06:27]: > > > On Tuesday 28 October 2014 23:26:41 Tony Lindgren wrote: > > > > * Pavel Machek [141028 15:22]: > > > > > On Tue 2014-10-28 23:04:50, Pavel Machek wrote: > > > > > > > > > > > > Networking now works against 3.17-based kernel. Thanks! > > > > > > > > > > It works on 3.18-rc1 kernel, too. (I had to hand-modify patch to > > > > > apply to 3.17, no changes needed for 3.18-rc1.) > > > > > > > > > > Tested-by: Pavel Machek > > > > > > > > Whatever we decice to do to fix this regression, it should probably > > > > be backported to at least v3.16 stable for distro use, maybe earlier > > > > too. I'd assume this is broken on multiple platforms currently. > > > > > > > it looks like this patch was not included into any kernel version... I'm > > > still using it on top of 4.x kernels. Are you going to send this patch > > > into upstream? Or do you have another fix for this problem? > > > > I think Felipe mentioned a better built-in gether fix that's been > > reviewed on linux-usb list. > > Do you have link to that email thread? Or was Felipe's fix already > merged into mainline kernel? Sorry I don't have a link, maybe Felipe can point you to the right patch. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] mfd: arizona: Fixup register table definitions
On Tue, 30 Jun 2015, Charles Keepax wrote:
> The regmap register definitions have been a source of many small fixes
> as issues are discovered. As such I made a small automated tool to
> check these definitions. This patch fixes the issues (mostly harmless)
> located by that tool, the issues fall into three catagories:
>
> 1) Volatile registers that have a default in the defaults table (default
> has been removed from the table since it is redundant)
> 2) Registers that are marked as volatile but unreadable (register has
> been removed from the volatile list since it is obviously not being
> used)
> 3) Registers that arn't readable but have an entry in the defaults
> table (again removed since it is redundant)
> 4) Readable non-volatile registers that are missing a default, these are
> dangerous as they won't get synced during a cache sync. Fortunately,
> most of them seem to be registers that shouldn't be there (for example
> wm5102 had readable registers for DRC2 and ISRC3 which is doesn't have)
>
> Hopefully another tool will be produced to check the actual default
> values themselves but that is outside the scope of this patch.
>
> Signed-off-by: Charles Keepax
> ---
> drivers/mfd/wm5102-tables.c | 47 +-
> drivers/mfd/wm5110-tables.c | 10 -
> drivers/mfd/wm8997-tables.c |6 +---
> 3 files changed, 4 insertions(+), 59 deletions(-)
Applied, thanks.
> diff --git a/drivers/mfd/wm5102-tables.c b/drivers/mfd/wm5102-tables.c
> index aeae6ec..5a5b371 100644
> --- a/drivers/mfd/wm5102-tables.c
> +++ b/drivers/mfd/wm5102-tables.c
> @@ -266,8 +266,6 @@ static const struct reg_default wm5102_reg_default[] = {
> { 0x0069, 0x01FF }, /* R105 - Always On Triggers Sequence
> Select 4 */
> { 0x006A, 0x01FF }, /* R106 - Always On Triggers Sequence
> Select 5 */
> { 0x006B, 0x01FF }, /* R107 - Always On Triggers Sequence
> Select 6 */
> - { 0x006E, 0x01FF }, /* R110 - Trigger Sequence Select 32 */
> - { 0x006F, 0x01FF }, /* R111 - Trigger Sequence Select 33 */
> { 0x0070, 0x }, /* R112 - Comfort Noise Generator */
> { 0x0090, 0x }, /* R144 - Haptics Control 1 */
> { 0x0091, 0x7FFF }, /* R145 - Haptics Control 2 */
> @@ -300,7 +298,6 @@ static const struct reg_default wm5102_reg_default[] = {
> { 0x0175, 0x0004 }, /* R373 - FLL1 Control 5 */
> { 0x0176, 0x }, /* R374 - FLL1 Control 6 */
> { 0x0177, 0x0181 }, /* R375 - FLL1 Loop Filter Test 1 */
> - { 0x0178, 0x }, /* R376 - FLL1 NCO Test 0 */
> { 0x0179, 0x }, /* R377 - FLL1 Control 7 */
> { 0x0181, 0x }, /* R385 - FLL1 Synchroniser 1 */
> { 0x0182, 0x }, /* R386 - FLL1 Synchroniser 2 */
> @@ -318,7 +315,6 @@ static const struct reg_default wm5102_reg_default[] = {
> { 0x0195, 0x0004 }, /* R405 - FLL2 Control 5 */
> { 0x0196, 0x }, /* R406 - FLL2 Control 6 */
> { 0x0197, 0x }, /* R407 - FLL2 Loop Filter Test 1 */
> - { 0x0198, 0x }, /* R408 - FLL2 NCO Test 0 */
> { 0x0199, 0x }, /* R409 - FLL2 Control 7 */
> { 0x01A1, 0x }, /* R417 - FLL2 Synchroniser 1 */
> { 0x01A2, 0x }, /* R418 - FLL2 Synchroniser 2 */
> @@ -338,12 +334,9 @@ static const struct reg_default wm5102_reg_default[] = {
> { 0x021A, 0x01A6 }, /* R538 - Mic Bias Ctrl 3 */
> { 0x0293, 0x }, /* R659 - Accessory Detect Mode 1 */
> { 0x029B, 0x0020 }, /* R667 - Headphone Detect 1 */
> - { 0x029C, 0x }, /* R668 - Headphone Detect 2 */
> - { 0x029F, 0x }, /* R671 - Headphone Detect Test */
> { 0x02A2, 0x }, /* R674 - Micd clamp control */
> { 0x02A3, 0x1102 }, /* R675 - Mic Detect 1 */
> { 0x02A4, 0x009F }, /* R676 - Mic Detect 2 */
> - { 0x02A5, 0x }, /* R677 - Mic Detect 3 */
> { 0x02A6, 0x3737 }, /* R678 - Mic Detect Level 1 */
> { 0x02A7, 0x372C }, /* R679 - Mic Detect Level 2 */
> { 0x02A8, 0x1422 }, /* R680 - Mic Detect Level 3 */
> @@ -887,11 +880,11 @@ static const struct reg_default wm5102_reg_default[] = {
> { 0x0D1B, 0x }, /* R3355 - IRQ2 Status 4 Mask */
> { 0x0D1C, 0x }, /* R3356 - IRQ2 Status 5 Mask */
> { 0x0D1F, 0x }, /* R3359 - IRQ2 Control */
> + { 0x0D41, 0x }, /* R3393 - ADSP2 IRQ0 */
> { 0x0D53, 0x }, /* R3411 - AOD IRQ Mask IRQ1 */
> { 0x0D54, 0x }, /* R3412 - AOD IRQ Mask IRQ2 */
> { 0x0D56, 0x }, /* R3414 - Jack detect debounce */
> { 0x0E00, 0x }, /* R3584 - FX_Ctrl1 */
> - { 0x0E01, 0x }, /* R3585 - FX_Ctrl2 */
> { 0x00
[RFC PATCH v3 0/2] Make eBPF programs output data to perf event
Hi,
The two previous versions tried to combine bpf output data with the
sample event of the attached kprobe point, which leads to problems
about perf_trace_buf.
After discussion we found it's not necessary to combine those two
parts of information, even we do not need the orignial kprobe output
event at all. Based on this idea, the implementation becomes simple,
just like what perf do with ftrace:functions, we set up a bpf ftrace
entry for perf tools to poll and collect data on it, eBpf program use
a helper function to submit data to ring-buffer, that's all. This
implementation also leaves all issues such as sample-types to perf
commandline.
Currently, we just use raw data in the format fields to not interfere
perf sample parser, because the raw-data can be parsed by perf script
plugin easily.
Modify the sample in patch v1 slightly:
SEC("generic_perform_write=generic_perform_write")
int NODE_generic_perform_write(struct pt_regs *ctx)
{
char fmt[] = "generic_perform_write, cur=0x%llx, del=0x%llx\n";
u64 cur_time, del_time;
int ind =0;
struct time_table output, *last =
bpf_map_lookup_elem(&global_time_table, &ind);
if (!last)
return 0;
cur_time = bpf_ktime_get_ns();
if (!last->last_time)
del_time = 0;
else
del_time = cur_time - last->last_time;
/* For debug */
bpf_trace_printk(fmt, sizeof(fmt), cur_time, del_time);
/* Update time table */
output.last_time = cur_time;
bpf_map_update_elem(&global_time_table, &ind, &output, BPF_ANY);
/* This is a casual condition to show the funciton */
if (del_time < 1000)
return 0;
bpf_output_sample(&del_time, sizeof(del_time));
return 0;
}
Record bpf events:
$ perf record -e ftrace:bpf -e sample.o -- dd if=/dev/zero of=test bs=4k
count=3
The results showed in perf-script:
$ perf script
dd 994 [000] 166.686779: ftrace:bpf: 8: (0542b426, ...)
dd 994 [000] 166.686779: ftrace:bpf: 8: (001011ef, ...)
dd 994 [000] 166.686779: ftrace:bpf: 8: (0007a2b6, ...)
Thank you.
He Kuang (2):
tracing: Add new trace type for bpf data output
bpf: Introduce function for outputing data to perf event
include/uapi/linux/bpf.h | 3 +++
kernel/trace/bpf_trace.c | 43 +++
kernel/trace/trace.h | 6 ++
kernel/trace/trace_entries.h | 18 ++
samples/bpf/bpf_helpers.h| 2 ++
5 files changed, 72 insertions(+)
--
1.8.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v3 1/2] tracing: Add new trace type for bpf data output
Add TRACE_BPF as a new trace type to establish infrastruction for bpf
output data to perf. This new trace type creates a static singleton
ftrace entry in kernel, userspace perf tools can detect and use this
new ftrace entry just as using the existing tracepoint events.
This added a new bpf ftrace entry in debugfs:
/sys/kernel/debug/tracing/events/ftrace/bpf
Userspace perf tools detect the new tracepoint event as:
ftrace:bpf [Tracepoint event]
Data in ring-buffer of perf events added to this ftrace:bpf event can
be polled out, sample types and other attributes can be adjusted to
those events directly without touching the original kprobe events.
Signed-off-by: He Kuang
---
kernel/trace/trace.h | 1 +
kernel/trace/trace_entries.h | 18 ++
2 files changed, 19 insertions(+)
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index d261201..d135f55 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -38,6 +38,7 @@ enum trace_type {
TRACE_USER_STACK,
TRACE_BLK,
TRACE_BPUTS,
+ TRACE_BPF,
__TRACE_LAST_TYPE,
};
diff --git a/kernel/trace/trace_entries.h b/kernel/trace/trace_entries.h
index ee7b94a..c237212 100644
--- a/kernel/trace/trace_entries.h
+++ b/kernel/trace/trace_entries.h
@@ -322,3 +322,21 @@ FTRACE_ENTRY(branch, trace_branch,
FILTER_OTHER
);
+#define TRACE_BPF_MAX_ENTRY64
+#define TRACE_BPF_MAX_SIZE (TRACE_BPF_MAX_ENTRY * sizeof(u64))
+
+FTRACE_ENTRY_REG(bpf, trace_bpf,
+
+ TRACE_BPF,
+
+ F_STRUCT(
+ __field(long, size)
+ __array(u64,raw_data, TRACE_BPF_MAX_ENTRY)
+ ),
+
+ F_printk("%ld: (%016llx, ...)", __entry->size, __entry->raw_data[0]),
+
+ FILTER_OTHER,
+
+ perf_ftrace_event_register
+);
--
1.8.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v3 2/2] bpf: Introduce function for outputing data to perf event
There're scenarios that we need an eBPF program to record not only
kprobe point args, but also the PMU counters, time latencies or cache
miss numbers between two probe points and other information we can
get when the probe point is entered.
This helper function gives eBPF program ability to output data as perf
sample event. The function works as kprobe_perf_func(), it packets the
data from bpf stack space into a sample record and submits it to the
ring-buffer of perf_events which are binded to BPF ftrace
entry. Userspace perf tools can record BPF ftrace event to collect
those records.
Signed-off-by: He Kuang
---
include/uapi/linux/bpf.h | 3 +++
kernel/trace/bpf_trace.c | 43 +++
kernel/trace/trace.h | 5 +
samples/bpf/bpf_helpers.h | 2 ++
4 files changed, 53 insertions(+)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index a9ebdf5..f44b0aa 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -210,6 +210,9 @@ enum bpf_func_id {
* Return: 0 on success
*/
BPF_FUNC_l4_csum_replace,
+
+ /* int bpf_output_data(void *src, int size, void *regs) */
+ BPF_FUNC_output_data,
__BPF_FUNC_MAX_ID,
};
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 2d56ce5..45dbeab 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -79,6 +79,47 @@ static const struct bpf_func_proto bpf_probe_read_proto = {
.arg3_type = ARG_ANYTHING,
};
+static u64 bpf_output_data(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
+{
+ void *src = (void *) (long) r1;
+ int dsize = (int) r2, __size, size;
+ void *regs = (void *) (long) r3;
+ struct bpf_trace_entry_head *entry;
+ struct hlist_head *head;
+ int rctx;
+
+ if (dsize > TRACE_BPF_MAX_SIZE)
+ return -ENOMEM;
+
+ head = this_cpu_ptr(event_bpf.perf_events);
+ if (hlist_empty(head))
+ return -ENOENT;
+
+ __size = sizeof(*entry) + dsize;
+ size = ALIGN(__size + sizeof(u32), sizeof(u64));
+ size -= sizeof(u32);
+
+ entry = perf_trace_buf_prepare(size, TRACE_BPF, NULL, &rctx);
+ if (!entry)
+ return -ENOMEM;
+
+ entry->size = dsize;
+ memcpy(&entry[1], src, dsize);
+
+ perf_tp_event(0, 1, entry, size, regs, head, rctx, NULL);
+
+ return 0;
+}
+
+static const struct bpf_func_proto bpf_output_data_proto = {
+ .func = bpf_output_data,
+ .gpl_only = true,
+ .ret_type = RET_INTEGER,
+ .arg1_type = ARG_PTR_TO_STACK,
+ .arg2_type = ARG_CONST_STACK_SIZE,
+ .arg3_type = ARG_PTR_TO_CTX,
+};
+
static u64 bpf_ktime_get_ns(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
{
/* NMI safe access to clock monotonic */
@@ -170,6 +211,8 @@ static const struct bpf_func_proto
*kprobe_prog_func_proto(enum bpf_func_id func
return &bpf_map_delete_elem_proto;
case BPF_FUNC_probe_read:
return &bpf_probe_read_proto;
+ case BPF_FUNC_output_data:
+ return &bpf_output_data_proto;
case BPF_FUNC_ktime_get_ns:
return &bpf_ktime_get_ns_proto;
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index d135f55..8d9100d 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -113,6 +113,11 @@ struct kretprobe_trace_entry_head {
unsigned long ret_ip;
};
+struct bpf_trace_entry_head {
+ struct trace_entry ent;
+ unsigned long size;
+};
+
/*
* trace_flag_type is an enumeration that holds different
* states when a trace occurs. These are:
diff --git a/samples/bpf/bpf_helpers.h b/samples/bpf/bpf_helpers.h
index f960b5f..bc7f13c 100644
--- a/samples/bpf/bpf_helpers.h
+++ b/samples/bpf/bpf_helpers.h
@@ -49,5 +49,7 @@ static int (*bpf_l3_csum_replace)(void *ctx, int off, int
from, int to, int flag
(void *) BPF_FUNC_l3_csum_replace;
static int (*bpf_l4_csum_replace)(void *ctx, int off, int from, int to, int
flags) =
(void *) BPF_FUNC_l4_csum_replace;
+static int (*bpf_output_data)(void *src, int size, void *regs) =
+ (void *) BPF_FUNC_output_data;
#endif
--
1.8.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5 2/2] devicetree: da9062: Add bindings for DA9062 driver
On Wed, 01 Jul 2015, S Twiss wrote:
> From: S Twiss
>
> Add device tree bindings for the DA9062 driver
>
> Signed-off-by: Steve Twiss
>
> ---
> Changes in V5:
> - No change
>
> Changes in V4:
> - No change
>
> Changes in V3:
> - No change
>
> Changes in V2:
> - Dropped the RTC and Onkey binding information in this patch-set
>Those drivers have been dropped from this patch set and the
>binding information has been removed accordingly.
>
> This patch applies against linux-next and next-20150701
>
>
>
> Documentation/devicetree/bindings/mfd/da9062.txt | 79
>
> 1 file changed, 79 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/da9062.txt
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/da9062.txt
> b/Documentation/devicetree/bindings/mfd/da9062.txt
> new file mode 100644
> index 000..5765ed9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/da9062.txt
> @@ -0,0 +1,79 @@
> +* Dialog DA9062 Power Management Integrated Circuit (PMIC)
> +
> +DA9062 consists of a large and varied group of sub-devices:
> +
> +Device Supply NamesDescription
> +-- ---
> +da9062-regulator: : LDOs & BUCKs
> +da9062-watchdog : : Watchdog Timer
> +
> +==
> +
> +Required properties:
> +
> +- compatible : Should be "dlg,da9062".
> +- reg : Specifies the I2C slave address (this defaults to 0x58 but it can be
> + modified to match the chip's OTP settings).
> +- interrupt-parent : Specifies the reference to the interrupt controller for
> + the DA9062.
> +- interrupts : IRQ line information.
> +- interrupt-controller
> +
> +See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for
> +further information on IRQ bindings.
> +
> +Sub-nodes:
> +
> +- regulators : This node defines the settings for the LDOs and BUCKs. The
> + DA9062 regulators are bound using their names listed below:
> +
> +buck1: BUCK_1
> +buck2: BUCK_2
> +buck3: BUCK_3
> +buck4: BUCK_4
> +ldo1 : LDO_1
> +ldo2 : LDO_2
> +ldo3 : LDO_3
> +ldo4 : LDO_4
> +
> + The component follows the standard regulator framework and the bindings
> + details of individual regulator device can be found in:
> + Documentation/devicetree/bindings/regulator/regulator.txt
> +
> +
> +- watchdog: This node defines the settings for the watchdog driver associated
> + with the DA9062 PMIC. The compatible = "dlg,da9062-watchdog" should be
> added
> + if a node is created.
> +
> +
> +Example:
> +
> + pmic0: da9062@58 {
> + compatible = "dlg,da9062";
> + reg = <0x58>;
> + interrupt-parent = <&gpio6>;
> + interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-controller;
> +
> + watchdog {
> + compatible = "dlg,da9062-watchdog";
> + };
> +
> + regulators {
> + DA9062_BUCK1: buck1 {
> + regulator-name = "BUCK1";
> + regulator-min-microvolt = <30>;
> + regulator-max-microvolt = <157>;
> + regulator-min-microamp = <50>;
> + regulator-max-microamp = <200>;
> + regulator-boot-on;
> + };
> + DA9062_LDO1: ldo1 {
> + regulator-name = "LDO_1";
> + regulator-min-microvolt = <90>;
> + regulator-max-microvolt = <360>;
> + regulator-boot-on;
> + };
> + };
> + };
> +
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5 1/2] mfd: da9062: DA9062 MFD core driver
On Wed, 01 Jul 2015, S Twiss wrote: > From: S Twiss > > Add MFD core driver support for DA9062 > > Signed-off-by: Steve Twiss > > --- > Changes in V5: > - Alter register.h file with the following: >bit macro change defines of the form (0x01> Changes in V4: > - Removal of struct da9062 unrequired data from core.h and driver code > - Remove IRQ handler for VDD_WARN and corresponding IRQ request code > - Use DEFINE_RES_NAMED() macro for resource definitions > - Refactor da9062_clear_fault_log() to remove inconsistencies > - Refactor da9062_device_init() and da9062_irq_init() into probe() > - Add new function get_device_type() for variant and device_id information > - devm_kzalloc to alloc *chip instead of struct and use not-chip on error > - Move da9062_dt_ids closer to usage > - Move LUT definitions into da9062_regmap_config structure > - Erase da9062_device_exit() abstractions > - Clean up header inclusions through removal of redundant entries > - Whitespace and string literal discipline > > Changes in V3: > - Removed references to the RTC and OnKey in the mfd_cell definition. > > Changes in V2: > - Copyright headers GPL v2 (and later) match correct 'GPL' in MODULE_LICENSE > - Ensure DA9062 core is tristate in Kconfig so it can be built as a module > - Move VDD_WARN code and resource into the core instead of regulator driver > > This patch applies against linux-next and next-20150701 > > > > drivers/mfd/Kconfig | 12 + > drivers/mfd/Makefile |3 +- > drivers/mfd/da9062-core.c| 512 > include/linux/mfd/da9062/core.h | 50 ++ > include/linux/mfd/da9062/registers.h | 1108 > ++ > 5 files changed, 1684 insertions(+), 1 deletion(-) > create mode 100644 drivers/mfd/da9062-core.c > create mode 100644 include/linux/mfd/da9062/core.h > create mode 100644 include/linux/mfd/da9062/registers.h Applied, thanks. > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index 6538159..1109d09 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -186,6 +186,18 @@ config MFD_DA9055 > This driver can be built as a module. If built as a module it will be > called "da9055" > > +config MFD_DA9062 > + tristate "Dialog Semiconductor DA9062 PMIC Support" > + select MFD_CORE > + select REGMAP_I2C > + select REGMAP_IRQ > + depends on I2C=y > + help > + Say yes here for support for the Dialog Semiconductor DA9062 PMIC. > + This includes the I2C driver and core APIs. > + Additional drivers must be enabled in order to use the functionality > + of the device. > + > config MFD_DA9063 > bool "Dialog Semiconductor DA9063 PMIC Support" > select MFD_CORE > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > index ea40e07..fd4d8b4 100644 > --- a/drivers/mfd/Makefile > +++ b/drivers/mfd/Makefile > @@ -110,10 +110,11 @@ obj-$(CONFIG_MFD_LP8788)+= lp8788.o lp8788-irq.o > > da9055-objs := da9055-core.o da9055-i2c.o > obj-$(CONFIG_MFD_DA9055) += da9055.o > - > +obj-$(CONFIG_MFD_DA9062) += da9062-core.o > da9063-objs := da9063-core.o da9063-irq.o da9063-i2c.o > obj-$(CONFIG_MFD_DA9063) += da9063.o > obj-$(CONFIG_MFD_DA9150) += da9150-core.o > + > obj-$(CONFIG_MFD_MAX14577) += max14577.o > obj-$(CONFIG_MFD_MAX77686) += max77686.o > obj-$(CONFIG_MFD_MAX77693) += max77693.o > diff --git a/drivers/mfd/da9062-core.c b/drivers/mfd/da9062-core.c > new file mode 100644 > index 000..4cf0643 > --- /dev/null > +++ b/drivers/mfd/da9062-core.c > @@ -0,0 +1,512 @@ > +/* > + * Core, IRQ and I2C device driver for DA9062 PMIC > + * Copyright (C) 2015 Dialog Semiconductor Ltd. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version 2 > + * of the License, or (at your option) any later version. > + * > + * 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 > +#include > + > +#define DA9062_REG_EVENT_A_OFFSET 0 > +#define DA9062_REG_EVENT_B_OFFSET 1 > +#define DA9062_REG_EVENT_C_OFFSET 2 > + > +static struct regmap_irq da9062_irqs[] = { > + /* EVENT A */ > + [DA9062_IRQ_ONKEY] = { > + .reg_offset = DA9062_REG_EVENT_A_OFFSET, > + .mask = DA9062AA_M_NONKEY_MASK, > + }, > + [DA9062_IRQ_ALARM] = { > + .reg_o
Re: [PATCH 5/6] Input: pixcir_i2c_ts - simplify input device initialization
On 07/07/15 03:30, Dmitry Torokhov wrote: input_mt_init_slots() will perform necessary settings for performing multi-touch to single-touch emulation, we do not need to do that ourselves. Signed-off-by: Dmitry Torokhov Acked-by: Roger Quadros cheers, -roger --- drivers/input/touchscreen/pixcir_i2c_ts.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/input/touchscreen/pixcir_i2c_ts.c b/drivers/input/touchscreen/pixcir_i2c_ts.c index 9d9ac08..043d219 100644 --- a/drivers/input/touchscreen/pixcir_i2c_ts.c +++ b/drivers/input/touchscreen/pixcir_i2c_ts.c @@ -510,11 +510,6 @@ static int pixcir_i2c_ts_probe(struct i2c_client *client, input->close = pixcir_input_close; input->dev.parent = &client->dev; - __set_bit(EV_KEY, input->evbit); - __set_bit(EV_ABS, input->evbit); - __set_bit(BTN_TOUCH, input->keybit); - input_set_abs_params(input, ABS_X, 0, pdata->x_max, 0, 0); - input_set_abs_params(input, ABS_Y, 0, pdata->y_max, 0, 0); input_set_abs_params(input, ABS_MT_POSITION_X, 0, pdata->x_max, 0, 0); input_set_abs_params(input, ABS_MT_POSITION_Y, 0, pdata->y_max, 0, 0); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC v2 3/6] irq: bypass: Extend skeleton for ARM forwarding control
> -Original Message-
> From: Wu, Feng
> Sent: Tuesday, July 07, 2015 7:24 PM
> To: Paolo Bonzini; Eric Auger; eric.au...@st.com;
> linux-arm-ker...@lists.infradead.org; kvm...@lists.cs.columbia.edu;
> k...@vger.kernel.org; christoffer.d...@linaro.org; marc.zyng...@arm.com;
> alex.william...@redhat.com; avi.kiv...@gmail.com; mtosa...@redhat.com;
> j...@8bytes.org; b.rey...@virtualopensystems.com
> Cc: linux-kernel@vger.kernel.org; patc...@linaro.org; Wu, Feng
> Subject: RE: [RFC v2 3/6] irq: bypass: Extend skeleton for ARM forwarding
> control
>
>
>
> > -Original Message-
> > From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> > Sent: Tuesday, July 07, 2015 7:22 PM
> > To: Wu, Feng; Eric Auger; eric.au...@st.com;
> > linux-arm-ker...@lists.infradead.org; kvm...@lists.cs.columbia.edu;
> > k...@vger.kernel.org; christoffer.d...@linaro.org; marc.zyng...@arm.com;
> > alex.william...@redhat.com; avi.kiv...@gmail.com; mtosa...@redhat.com;
> > j...@8bytes.org; b.rey...@virtualopensystems.com
> > Cc: linux-kernel@vger.kernel.org; patc...@linaro.org
> > Subject: Re: [RFC v2 3/6] irq: bypass: Extend skeleton for ARM forwarding
> > control
> >
> >
> >
> > On 07/07/2015 13:18, Wu, Feng wrote:
> > > Then I still need assign prod and de-assign prod in
> > > irq_bypass_register_consumer/irq_bypass_unregister_consumer, Right?
> > > Would you please share why this is better.
> >
> > The need to store the consumer->producer link seems to be unique to
> > posted interrupts. It is difficult to say without seeing the PI code,
> > but I prefer to keep the bypass manager as small as possible.
>
> Fine. I will follow your suggestion!
If using the following changes, how can we assign 'prod', we need to use
container_of to get struct kvm_kernel_irqfd and then refer to 'prod', but
we cannot do this in irq_bypass_register_consumer(), right? It is a
common API. But we can only get the associated producer info inside
bypass manager, right?
Thanks,
Feng
struct kvm_kernel_irqfd {
..
struct irq_bypass_consumer cons;
struct irq_bypass_producer *prod;
};
>
> Thanks,
> Feng
>
> >
> > Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Mon, Jul 06, 2015 at 10:26:13PM +0200, Pali Rohár wrote: > Legacy bootloaders can pass additional information for kernel or legacy > userspace applications. When booting DT kernel then ATAGs structure is not > more visible after running kernel uncompress code. This patch stores full > ATAGs structure into DT "/chosen/linux,atags" entry, so kernel can later > reuse it and export via /proc/atags to userspace. I think you need to go through your commit messages and improve them, especially the ones with "TODO" in them. As long as there's still things to be done, they're obviously not ready for merging. Moreover, exporting the ATAGS is questionable, even _if_ there are non- kexec programs making use of this. The ATAGs have _never_ been exported to userspace when kexec disabled is the kernel - it was introduced for kexec, and has always had this: config ATAGS_PROC bool "Export atags in procfs" depends on ATAGS && KEXEC default y Now, the fact that someone decided to start using it is pretty sad, because it means that if you disable KEXEC, userspace breaks. That's not a kernel regression in any shape or form, because /proc/atags has never been there without KEXEC enabled. That's a userspace bug, plain and simple. Given that, I'm in two minds about whether to accept the last two patches which make this more than just "for KEXEC use to enable a KEXEC kernel to be booted." Had it been provided without the KEXEC conditional, then I don't have a problem with these two patches. It also sets a precedent: by adding this into DT, it is creating a new DT ABI as well, and we'll end up seeing dts files with an ATAG block patched into them. Are the ATAGs at a fixed address on the N900? Can that be handled in some kind of legacy file for the N900 which calls save_atags() on it, so we don't end up introducing yet more stuff that we have to maintain into the distant future? If not, what about copying a known working atag structure into a legacy file for the N900? -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/2] tick/broadcast: Prevent deep idle states if no broadcast device available
Hi Thomas,
On 07/07/15 08:31, Thomas Gleixner wrote:
On Mon, 6 Jul 2015, Thomas Gleixner wrote:
On Mon, 6 Jul 2015, Sudeep Holla wrote:
This triggered the below crash on boot, looks like it's accessing
hrtimer->function which is null in periodic mode IIUC
Regards,
Sudeep
Gah. I have no idea how that gets queued. /me goes off to tweak x86 to
emulate that crap.
So with a less heat damaged brain, I think I was able to decode the
twisted logic behind all this.
Can you test the patch below please?
Yes I tested this patch for all the combinations I had mentioned in my
earlier email. Everything works as expected. Thanks a lot for the
patience. Please feel free to add:
Tested-by: Sudeep Holla
{
Index: tip/kernel/time/tick-broadcast.c
===
--- tip.orig/kernel/time/tick-broadcast.c
+++ tip/kernel/time/tick-broadcast.c
@@ -938,6 +972,16 @@ bool tick_broadcast_oneshot_available(vo
return bc ? bc->features & CLOCK_EVT_FEAT_ONESHOT : false;
}
+#else
+int __tick_broadcast_oneshot_control(enum tick_broadcast_state state)
+{
+ struct clock_event_device *bc = tick_broadcast_device.evtdev;
+
+ if (!bc || (bc->features & CLOCK_EVT_FEAT_HRTIMER)
missing ')' at the end in the above statement
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-V5 3/4] mfd: 88pm800: Set default interrupt clear method
On Tuesday 07 July 2015 04:48 PM, Vaibhav Hiremath wrote:
On Tuesday 07 July 2015 04:42 PM, Lee Jones wrote:
On Tue, 07 Jul 2015, Vaibhav Hiremath wrote:
On Tuesday 07 July 2015 04:10 PM, Lee Jones wrote:
On Tue, 07 Jul 2015, Vaibhav Hiremath wrote:
On Tuesday 07 July 2015 12:59 PM, Lee Jones wrote:
On Mon, 29 Jun 2015, Vaibhav Hiremath wrote:
As per the spec, bit 1 (INT_CLEAR_MODE) of reg addr 0xe
(page 0) controls the method of clearing interrupt
status of 88pm800 family of devices;
0: clear on read
1: clear on write
If pdata is not coming from board file, then set the
default irq clear method to "irq clear on write"
Also, as suggested by "Lee Jones" renaming variable field
to appropriate name.
Signed-off-by: Zhao Ye
Signed-off-by: Vaibhav Hiremath
---
drivers/mfd/88pm800.c | 15 ++-
include/linux/mfd/88pm80x.h | 10 --
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index d495737..66347be 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -374,7 +374,7 @@ static int device_irq_init_800(struct
pm80x_chip *chip)
{
struct regmap *map = chip->regmap;
unsigned long flags = IRQF_ONESHOT;
-int data, mask, ret = -EINVAL;
+int irq_clr_mode, mask, ret = -EINVAL;
if (!map || !chip->irq) {
dev_err(chip->dev, "incorrect parameters\n");
@@ -382,15 +382,16 @@ static int device_irq_init_800(struct
pm80x_chip *chip)
}
/*
- * irq_mode defines the way of clearing interrupt. it's
read-clear by
- * default.
+ * irq_clr_on_wr defines the way of clearing interrupt by
+ * read/write(0/1). It's read-clear by default.
*/
mask =
PM800_WAKEUP2_INV_INT | PM800_WAKEUP2_INT_CLEAR |
PM800_WAKEUP2_INT_MASK;
-data = PM800_WAKEUP2_INT_CLEAR;
-ret = regmap_update_bits(map, PM800_WAKEUP2, mask, data);
+irq_clr_mode = chip->irq_clr_method == PM800_IRQ_CLR_ON_WRITE ?
+PM800_WAKEUP2_INT_WRITE_CLEAR :
PM800_WAKEUP2_INT_READ_CLEAR;
+ret = regmap_update_bits(map, PM800_WAKEUP2, mask,
irq_clr_mode);
What's stopping you just passing PM800_WAKEUP2_INT_WRITE_CLEAR or
PM800_WAKEUP2_INT_READ_CLEAR from pdata? Then you can use the value
directly without all of this faffing about.
regmap_update_bits(map, PM800_WAKEUP2, mask, pdata->irq_clr_mode);
Because "irq_clr_method" is of boolean type.
And macros which you are referring to is,
#define PM800_WAKEUP2_INT_READ_CLEAR(0 << 1)
#define PM800_WAKEUP2_INT_WRITE_CLEAR (1 << 1)
And also, I feel it is more cleaner approach with the current code as
register definition and userflag are maintained separately.
I see your point, although it's a shame we have to have this code in
its place.
One thing I think you can do though is rid chip->irq_clr_method, just
use the one you already have in pdata.
Looking at the current code,
Yes, this can be done, but I have to do some more changes around it,
to make code cleaner,
change the signature of
static int device_irq_init_800(struct pm80x_chip *chip)
TO
static int device_irq_init_800(struct pm80x_chip *chip, struct
pm80x_platform_data *pdata)
and then only use pdata->irq_clr_method.
How do you want to get this inside? V6 version? or separate patch?
I have one more cleanup patch in the queue, which I am planning to
submit today, if you are ok then I can submit along with that.
Ideally not. Don't you save the 'struct device' into *chip? You
should use that to fetch the pdata, like:
pdata = dev_get_platdata(chip->dev);
Yes certainly, this is another option (rather preferred one).
But to be consistent with other's I proposed this, please refer to the
fn device_800_init(), where all xxx_init() are taking 2 arguments, and
second argument is pdata.
There is room for cleanup, I agree.
I can put this too in the next cleanup series.
Note that this is init function, called from probe.
So both approach looks ok to me.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] locking/qrwlock: Use direct MCS lock/unlock in slowpath
On Mon, Jul 06, 2015 at 11:43:06AM -0400, Waiman Long wrote: > Lock waiting in the qrwlock uses the spinlock (qspinlock for x86) > as the waiting queue. This is slower than using MCS lock directly > because of the extra level of indirection causing more atomics to > be used as well as 2 waiting threads spinning on the lock cacheline > instead of only one. This needs a better explanation. Didn't we find with the qspinlock thing that the pending spinner improved performance on light loads? Taking it out seems counter intuitive, we could very much like these two the be the same. > --- a/kernel/locking/qrwlock.c > +++ b/kernel/locking/qrwlock.c > +static DEFINE_PER_CPU_ALIGNED(struct mcs_spinlock, _mcs_qnodes[4]); > --- a/kernel/locking/qspinlock.c > +++ b/kernel/locking/qspinlock.c > @@ -81,8 +81,9 @@ > * Exactly fits one 64-byte cacheline on a 64-bit architecture. > * > * PV doubles the storage and uses the second cacheline for PV state. > + * The MCS nodes are also shared with qrwlock. > */ > -static DEFINE_PER_CPU_ALIGNED(struct mcs_spinlock, mcs_nodes[MAX_NODES]); > +DEFINE_PER_CPU_ALIGNED(struct mcs_spinlock, _mcs_qnodes[MAX_NODES]); Except you don't... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC v2 3/6] irq: bypass: Extend skeleton for ARM forwarding control
> -Original Message- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: Tuesday, July 07, 2015 7:22 PM > To: Wu, Feng; Eric Auger; eric.au...@st.com; > linux-arm-ker...@lists.infradead.org; kvm...@lists.cs.columbia.edu; > k...@vger.kernel.org; christoffer.d...@linaro.org; marc.zyng...@arm.com; > alex.william...@redhat.com; avi.kiv...@gmail.com; mtosa...@redhat.com; > j...@8bytes.org; b.rey...@virtualopensystems.com > Cc: linux-kernel@vger.kernel.org; patc...@linaro.org > Subject: Re: [RFC v2 3/6] irq: bypass: Extend skeleton for ARM forwarding > control > > > > On 07/07/2015 13:18, Wu, Feng wrote: > > Then I still need assign prod and de-assign prod in > > irq_bypass_register_consumer/irq_bypass_unregister_consumer, Right? > > Would you please share why this is better. > > The need to store the consumer->producer link seems to be unique to > posted interrupts. It is difficult to say without seeing the PI code, > but I prefer to keep the bypass manager as small as possible. Fine. I will follow your suggestion! Thanks, Feng > > Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 3/6] irq: bypass: Extend skeleton for ARM forwarding control
On 07/07/2015 13:18, Wu, Feng wrote: > Then I still need assign prod and de-assign prod in > irq_bypass_register_consumer/irq_bypass_unregister_consumer, Right? > Would you please share why this is better. The need to store the consumer->producer link seems to be unique to posted interrupts. It is difficult to say without seeing the PI code, but I prefer to keep the bypass manager as small as possible. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] regulator: ltc3589: Constify ltc3589_reg_defaults
ltc3589_reg_defaults[] is not modified after initialized, so make it const.
Signed-off-by: Axel Lin
---
drivers/regulator/ltc3589.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/ltc3589.c b/drivers/regulator/ltc3589.c
index 0ce8e4e..c31dfa8 100644
--- a/drivers/regulator/ltc3589.c
+++ b/drivers/regulator/ltc3589.c
@@ -378,7 +378,7 @@ static bool ltc3589_volatile_reg(struct device *dev,
unsigned int reg)
return false;
}
-static struct reg_default ltc3589_reg_defaults[] = {
+static const struct reg_default ltc3589_reg_defaults[] = {
{ LTC3589_SCR1, 0x00 },
{ LTC3589_OVEN, 0x00 },
{ LTC3589_SCR2, 0x00 },
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC v2 3/6] irq: bypass: Extend skeleton for ARM forwarding control
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Tuesday, July 07, 2015 7:14 PM
> To: Wu, Feng; Eric Auger; eric.au...@st.com;
> linux-arm-ker...@lists.infradead.org; kvm...@lists.cs.columbia.edu;
> k...@vger.kernel.org; christoffer.d...@linaro.org; marc.zyng...@arm.com;
> alex.william...@redhat.com; avi.kiv...@gmail.com; mtosa...@redhat.com;
> j...@8bytes.org; b.rey...@virtualopensystems.com
> Cc: linux-kernel@vger.kernel.org; patc...@linaro.org
> Subject: Re: [RFC v2 3/6] irq: bypass: Extend skeleton for ARM forwarding
> control
>
>
>
> On 07/07/2015 13:13, Wu, Feng wrote:
> >> > You can use container_of to add it to your own struct, e.g.
> >> >
> >> > struct irq_bypass_consumer cons;
> >> > struct irq_bypass_producer *prod;
> > Do you mean this:
> >
> > struct kvm_kernel_irqfd {
> >
> > ..
> >
> > struct irq_bypass_consumer cons;
> > struct irq_bypass_producer *prod;
> > };
>
> Yes.
Then I still need assign prod and de-assign prod in
irq_bypass_register_consumer/irq_bypass_unregister_consumer,
Right? Would you please share why this is better. My original though is as
below:
diff --git a/include/linux/irqbypass.h b/include/linux/irqbypass.h
index 8f62235..11930c1 100644
--- a/include/linux/irqbypass.h
+++ b/include/linux/irqbypass.h
@@ -20,6 +20,7 @@ struct irq_bypass_producer {
struct irq_bypass_consumer {
struct list_head node;
void *token;
+ struct irq_bypass_producer *producer;
void (*stop)(struct irq_bypass_consumer *);
void (*resume)(struct irq_bypass_consumer *);
void (*add_producer)(struct irq_bypass_consumer *,
diff --git a/kernel/irq/bypass.c b/kernel/irq/bypass.c
index efadbe5..be2da25 100644
--- a/kernel/irq/bypass.c
+++ b/kernel/irq/bypass.c
@@ -122,6 +122,7 @@ int irq_bypass_register_consumer(struct irq_bypass_consumer
*consumer)
list_for_each_entry(producer, &producers, node) {
if (producer->token == consumer->token) {
+ consumer->producer = producer;
connect(producer, consumer);
break;
}
@@ -140,6 +141,7 @@ void irq_bypass_unregister_consumer(struct
irq_bypass_consumer *consumer)
list_for_each_entry(producer, &producers, node) {
if (producer->token == consumer->token) {
+ consumer->producer = NULL;
disconnect(producer, consumer);
break;
}
Thanks,
Feng
>
> Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-V5 3/4] mfd: 88pm800: Set default interrupt clear method
On Tuesday 07 July 2015 04:42 PM, Lee Jones wrote:
On Tue, 07 Jul 2015, Vaibhav Hiremath wrote:
On Tuesday 07 July 2015 04:10 PM, Lee Jones wrote:
On Tue, 07 Jul 2015, Vaibhav Hiremath wrote:
On Tuesday 07 July 2015 12:59 PM, Lee Jones wrote:
On Mon, 29 Jun 2015, Vaibhav Hiremath wrote:
As per the spec, bit 1 (INT_CLEAR_MODE) of reg addr 0xe
(page 0) controls the method of clearing interrupt
status of 88pm800 family of devices;
0: clear on read
1: clear on write
If pdata is not coming from board file, then set the
default irq clear method to "irq clear on write"
Also, as suggested by "Lee Jones" renaming variable field
to appropriate name.
Signed-off-by: Zhao Ye
Signed-off-by: Vaibhav Hiremath
---
drivers/mfd/88pm800.c | 15 ++-
include/linux/mfd/88pm80x.h | 10 --
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index d495737..66347be 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -374,7 +374,7 @@ static int device_irq_init_800(struct pm80x_chip *chip)
{
struct regmap *map = chip->regmap;
unsigned long flags = IRQF_ONESHOT;
- int data, mask, ret = -EINVAL;
+ int irq_clr_mode, mask, ret = -EINVAL;
if (!map || !chip->irq) {
dev_err(chip->dev, "incorrect parameters\n");
@@ -382,15 +382,16 @@ static int device_irq_init_800(struct pm80x_chip *chip)
}
/*
-* irq_mode defines the way of clearing interrupt. it's read-clear by
-* default.
+* irq_clr_on_wr defines the way of clearing interrupt by
+* read/write(0/1). It's read-clear by default.
*/
mask =
PM800_WAKEUP2_INV_INT | PM800_WAKEUP2_INT_CLEAR |
PM800_WAKEUP2_INT_MASK;
- data = PM800_WAKEUP2_INT_CLEAR;
- ret = regmap_update_bits(map, PM800_WAKEUP2, mask, data);
+ irq_clr_mode = chip->irq_clr_method == PM800_IRQ_CLR_ON_WRITE ?
+ PM800_WAKEUP2_INT_WRITE_CLEAR : PM800_WAKEUP2_INT_READ_CLEAR;
+ ret = regmap_update_bits(map, PM800_WAKEUP2, mask, irq_clr_mode);
What's stopping you just passing PM800_WAKEUP2_INT_WRITE_CLEAR or
PM800_WAKEUP2_INT_READ_CLEAR from pdata? Then you can use the value
directly without all of this faffing about.
regmap_update_bits(map, PM800_WAKEUP2, mask, pdata->irq_clr_mode);
Because "irq_clr_method" is of boolean type.
And macros which you are referring to is,
#define PM800_WAKEUP2_INT_READ_CLEAR(0 << 1)
#define PM800_WAKEUP2_INT_WRITE_CLEAR (1 << 1)
And also, I feel it is more cleaner approach with the current code as
register definition and userflag are maintained separately.
I see your point, although it's a shame we have to have this code in
its place.
One thing I think you can do though is rid chip->irq_clr_method, just
use the one you already have in pdata.
Looking at the current code,
Yes, this can be done, but I have to do some more changes around it,
to make code cleaner,
change the signature of
static int device_irq_init_800(struct pm80x_chip *chip)
TO
static int device_irq_init_800(struct pm80x_chip *chip, struct
pm80x_platform_data *pdata)
and then only use pdata->irq_clr_method.
How do you want to get this inside? V6 version? or separate patch?
I have one more cleanup patch in the queue, which I am planning to
submit today, if you are ok then I can submit along with that.
Ideally not. Don't you save the 'struct device' into *chip? You
should use that to fetch the pdata, like:
pdata = dev_get_platdata(chip->dev);
Yes certainly, this is another option (rather preferred one).
But to be consistent with other's I proposed this, please refer to the
fn device_800_init(), where all xxx_init() are taking 2 arguments, and
second argument is pdata.
There is room for cleanup, I agree.
I can put this too in the next cleanup series.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH?] Livelock in pick_next_task_fair() / idle_balance()
On Mon, Jul 06, 2015 at 07:36:56PM +0200, Dietmar Eggemann wrote: > Rabin, could you share the content of your > /sys/fs/cgroup/cpu/system.slice directory and of /proc/cgroups ? Here's /proc/cgroups, # cat /proc/cgroups #subsys_namehierarchy num_cgroups enabled cpu 2 98 1 cpuacct 2 98 1 and the contents of /sys/fs/cgroup/cpu/system.slice are available here: https://drive.google.com/file/d/0B4tMLbMvJ-l6ZVBvZ09QOE15MU0/view /Rabin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] locking/qrwlock: Reduce reader/writer to reader lock transfer latency
On Tue, Jul 07, 2015 at 10:17:11AM +0100, Will Deacon wrote: > > > Thinking about it, can we kill _QW_WAITING altogether and set (cmpxchg > > > from 0) wmode to _QW_LOCKED in the write_lock slowpath, polling (acquire) > > > rmode until it hits zero? > > > > No, this is how we make the lock fair so that an incoming streams of > > later readers won't block a writer from getting the lock. > > But won't those readers effectively see that the lock is held for write > (because we set wmode to _QW_LOCKED before the existing reader had drained) > and therefore fall down the slow-path and get held up on the spinlock? Yes, that's the entire point. Once there's a writer pending, new readers should queue too. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf tools: Fix lockup using 32-bit compat vdso
__machine__findnew_compat() is called only from __machine__findnew_vdso_compat() which is called only from machine__findnew_vdso() which already holds machine->dsos.lock, so remove locking from __machine__findnew_compat(). This manifests itself tracing 32-bit programs with a 64-bit perf. Signed-off-by: Adrian Hunter --- tools/perf/util/vdso.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/tools/perf/util/vdso.c b/tools/perf/util/vdso.c index 4b89118f158d..44d440da15dc 100644 --- a/tools/perf/util/vdso.c +++ b/tools/perf/util/vdso.c @@ -236,18 +236,16 @@ static struct dso *__machine__findnew_compat(struct machine *machine, const char *file_name; struct dso *dso; - pthread_rwlock_wrlock(&machine->dsos.lock); dso = __dsos__find(&machine->dsos, vdso_file->dso_name, true); if (dso) - goto out_unlock; + goto out; file_name = vdso__get_compat_file(vdso_file); if (!file_name) - goto out_unlock; + goto out; dso = __machine__addnew_vdso(machine, vdso_file->dso_name, file_name); -out_unlock: - pthread_rwlock_unlock(&machine->dsos.lock); +out: return dso; } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] x86, acpi, cpu-hotplug: Introduce apicid_to_cpuid[] array to store persistent cpuid <-> apicid mapping.
I think you forgot to reserve CPU 0 for BSP in cpuid mask.
--Mika
On Tue, Jul 7, 2015 at 12:30 PM, Tang Chen wrote:
> From: Gu Zheng
>
> In this patch, we introduce a new static array named apicid_to_cpuid[],
> which is large enough to store info for all possible cpus.
>
> And then, we modify the cpuid calculation. In generic_processor_info(),
> it simply finds the next unused cpuid. And it is also why the cpuid <-> nodeid
> mapping changes with node hotplug.
>
> After this patch, we find the next unused cpuid, map it to an apicid,
> and store the mapping in apicid_to_cpuid[], so that cpuid <-> apicid
> mapping will be persistent.
>
> And finally we will use this array to make cpuid <-> nodeid persistent.
>
> cpuid <-> apicid mapping is established at local apic registeration time.
> But non-present or disabled cpus are ignored.
>
> In this patch, we establish all possible cpuid <-> apicid mapping when
> registering local apic.
>
>
> Signed-off-by: Gu Zheng
> Signed-off-by: Tang Chen
> ---
> arch/x86/include/asm/mpspec.h | 1 +
> arch/x86/kernel/acpi/boot.c | 6 ++
> arch/x86/kernel/apic/apic.c | 47
> ---
> 3 files changed, 47 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/include/asm/mpspec.h b/arch/x86/include/asm/mpspec.h
> index b07233b..db902d8 100644
> --- a/arch/x86/include/asm/mpspec.h
> +++ b/arch/x86/include/asm/mpspec.h
> @@ -86,6 +86,7 @@ static inline void early_reserve_e820_mpc_new(void) { }
> #endif
>
> int generic_processor_info(int apicid, int version);
> +int __generic_processor_info(int apicid, int version, bool enabled);
>
> #define PHYSID_ARRAY_SIZE BITS_TO_LONGS(MAX_LOCAL_APIC)
>
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index e49ee24..bcc85b2 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -174,15 +174,13 @@ static int acpi_register_lapic(int id, u8 enabled)
> return -EINVAL;
> }
>
> - if (!enabled) {
> + if (!enabled)
> ++disabled_cpus;
> - return -EINVAL;
> - }
>
> if (boot_cpu_physical_apicid != -1U)
> ver = apic_version[boot_cpu_physical_apicid];
>
> - return generic_processor_info(id, ver);
> + return __generic_processor_info(id, ver, enabled);
> }
>
> static int __init
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index a9c9830..c744ffb 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -1977,7 +1977,38 @@ void disconnect_bsp_APIC(int virt_wire_setup)
> apic_write(APIC_LVT1, value);
> }
>
> -static int __generic_processor_info(int apicid, int version, bool enabled)
> +/*
> + * Logic cpu number(cpuid) to local APIC id persistent mappings.
> + * Do not clear the mapping even if cpu is hot-removed.
> + */
> +static int apicid_to_cpuid[] = {
> + [0 ... NR_CPUS - 1] = -1,
> +};
> +
> +/*
> + * Internal cpu id bits, set the bit once cpu present, and never clear it.
> + */
> +static cpumask_t cpuid_mask = CPU_MASK_NONE;
> +
> +static int get_cpuid(int apicid)
> +{
> + int free_id, i;
> +
> + free_id = cpumask_next_zero(-1, &cpuid_mask);
> + if (free_id >= nr_cpu_ids)
> + return -1;
> +
> + for (i = 0; i < free_id; i++)
> + if (apicid_to_cpuid[i] == apicid)
> + return i;
> +
> + apicid_to_cpuid[free_id] = apicid;
> + cpumask_set_cpu(free_id, &cpuid_mask);
> +
> + return free_id;
> +}
> +
> +int __generic_processor_info(int apicid, int version, bool enabled)
> {
> int cpu, max = nr_cpu_ids;
> bool boot_cpu_detected = physid_isset(boot_cpu_physical_apicid,
> @@ -2058,8 +2089,18 @@ static int __generic_processor_info(int apicid, int
> version, bool enabled)
> * for BSP.
> */
> cpu = 0;
> - } else
> - cpu = cpumask_next_zero(-1, cpu_present_mask);
> + } else {
> + cpu = get_cpuid(apicid);
> + if (cpu < 0) {
> + int thiscpu = max + disabled_cpus;
> +
> + pr_warning(" Processor %d/0x%x ignored.\n",
> + thiscpu, apicid);
> + if (enabled)
> + disabled_cpus++;
> + return -EINVAL;
> + }
> + }
>
> /*
> * Validate version
> --
> 1.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.ht
RE: [RFC v2 3/6] irq: bypass: Extend skeleton for ARM forwarding control
> -Original Message-
> From: Paolo Bonzini [mailto:pbonz...@redhat.com]
> Sent: Tuesday, July 07, 2015 7:01 PM
> To: Wu, Feng; Eric Auger; eric.au...@st.com;
> linux-arm-ker...@lists.infradead.org; kvm...@lists.cs.columbia.edu;
> k...@vger.kernel.org; christoffer.d...@linaro.org; marc.zyng...@arm.com;
> alex.william...@redhat.com; avi.kiv...@gmail.com; mtosa...@redhat.com;
> j...@8bytes.org; b.rey...@virtualopensystems.com
> Cc: linux-kernel@vger.kernel.org; patc...@linaro.org
> Subject: Re: [RFC v2 3/6] irq: bypass: Extend skeleton for ARM forwarding
> control
>
>
>
> On 07/07/2015 12:58, Wu, Feng wrote:
> >
> >
> >> -Original Message-
> >> From: Eric Auger [mailto:eric.au...@linaro.org]
> >> Sent: Monday, July 06, 2015 8:11 PM
> >> To: eric.au...@st.com; eric.au...@linaro.org;
> >> linux-arm-ker...@lists.infradead.org; kvm...@lists.cs.columbia.edu;
> >> k...@vger.kernel.org; christoffer.d...@linaro.org; marc.zyng...@arm.com;
> >> alex.william...@redhat.com; pbonz...@redhat.com; avi.kiv...@gmail.com;
> >> mtosa...@redhat.com; Wu, Feng; j...@8bytes.org;
> >> b.rey...@virtualopensystems.com
> >> Cc: linux-kernel@vger.kernel.org; patc...@linaro.org
> >> Subject: [RFC v2 3/6] irq: bypass: Extend skeleton for ARM forwarding
> control
> >>
> >> - [add,del]_[consumer,producer] updated to takes both the consumer and
> >> producer handles. This is requested to combine info from both,
> >> typically to link the source irq owned by the producer with the gsi
> >> owned by the consumer (forwarded IRQ setup).
> >> - new methods are added:
> >> x stop/resume: Those are needed for forwarding since the state change
> >> requires to entermingle actions at consumer, producer.
> >> x consumer update for posted interrupts
> >> - On handshake, we now call connect, disconnect which features the more
> >> complex sequence.
> >> - add irq on producer side
> >>
> >> Signed-off-by: Eric Auger
> >>
> >> ---
> >>
> >> v1 -> v2:
> >> - remove vfio_device, kvm, gsi, opaque fields included in v1 except common
> >> - all those in can be retrieved with container_of in callbacks
> >> ---
> >> include/linux/irqbypass.h | 19 ---
> >> kernel/irq/bypass.c | 44
> >>
> >> 2 files changed, 56 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/include/linux/irqbypass.h b/include/linux/irqbypass.h
> >> index 718508e..8f62235 100644
> >> --- a/include/linux/irqbypass.h
> >> +++ b/include/linux/irqbypass.h
> >> @@ -3,17 +3,30 @@
> >>
> >> #include
> >>
> >> +struct irq_bypass_consumer;
> >> +
> >> struct irq_bypass_producer {
> >>struct list_head node;
> >>void *token;
> >> - /* TBD */
> >> + int irq; /* linux irq */
> >> + void (*stop)(struct irq_bypass_producer *);
> >> + void (*resume)(struct irq_bypass_producer *);
> >> + void (*add_consumer)(struct irq_bypass_producer *,
> >> + struct irq_bypass_consumer *);
> >> + void (*del_consumer)(struct irq_bypass_producer *,
> >> + struct irq_bypass_consumer *);
> >> };
> >>
> >> struct irq_bypass_consumer {
> >>struct list_head node;
> >>void *token;
> >
> > Can we add a pointer to ' struct irq_bypass_producer ', and
> > assign it when connecting, de-assign it when disconnecting.
> > since in some case, I need to update IRTE from the consumer
> > side, where I cannot get the related producer info (I need irq info)
> > without iterating it again.
>
> You can use container_of to add it to your own struct, e.g.
>
> struct irq_bypass_consumer cons;
> struct irq_bypass_producer *prod;
Do you mean this:
struct kvm_kernel_irqfd {
..
struct irq_bypass_consumer cons;
struct irq_bypass_producer *prod;
};
Thanks,
Feng
>
> Paolo
>
> > Thanks,
> > Feng
> >
> >> - void (*add_producer)(struct irq_bypass_producer *);
> >> - void (*del_producer)(struct irq_bypass_producer *);
> >> + void (*stop)(struct irq_bypass_consumer *);
> >> + void (*resume)(struct irq_bypass_consumer *);
> >> + void (*add_producer)(struct irq_bypass_consumer *,
> >> + struct irq_bypass_producer *);
> >> + void (*del_producer)(struct irq_bypass_consumer *,
> >> + struct irq_bypass_producer *);
> >> + void (*update)(struct irq_bypass_consumer *);
> >> };
> >>
> >> int irq_bypass_register_producer(struct irq_bypass_producer *);
> >> diff --git a/kernel/irq/bypass.c b/kernel/irq/bypass.c
> >> index 5d0f92b..efadbe5 100644
> >> --- a/kernel/irq/bypass.c
> >> +++ b/kernel/irq/bypass.c
> >> @@ -19,6 +19,42 @@ static LIST_HEAD(producers);
> >> static LIST_HEAD(consumers);
> >> static DEFINE_MUTEX(lock);
> >>
> >> +/* lock must be hold when calling connect */
> >> +static void connect(struct irq_bypass_producer *prod,
> >> + struct irq_bypass_consumer *cons)
> >> +{
> >> + if (prod->stop)
> >> + prod->stop(prod);
> >> + if (cons->stop)
> >> +
Re: [Patch v3 1/1] media: am437x-vpfe: Requested frame size and fmt overwritten by current sensor setting
On Mon, Jun 29, 2015 at 10:19 PM, Benoit Parrot wrote:
> Upon a S_FMT the input/requested frame size and pixel format is
> overwritten by the current sub-device settings.
> Fix this so application can actually set the frame size and format.
>
> Fixes: 417d2e507edc ("[media] media: platform: add VPFE capture driver
> support for AM437X")
> Cc: # v4.0+
> Signed-off-by: Benoit Parrot
Acked-by: Lad, Prabhakar
Cheers,
--Prabhakar Lad
> ---
> Changes since v2:
> - fix the stable commit reference syntax
>
> drivers/media/platform/am437x/am437x-vpfe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/am437x/am437x-vpfe.c
> b/drivers/media/platform/am437x/am437x-vpfe.c
> index eb25c43da126..0fa62c50f62d 100644
> --- a/drivers/media/platform/am437x/am437x-vpfe.c
> +++ b/drivers/media/platform/am437x/am437x-vpfe.c
> @@ -1584,7 +1584,7 @@ static int vpfe_s_fmt(struct file *file, void *priv,
> return -EBUSY;
> }
>
> - ret = vpfe_try_fmt(file, priv, fmt);
> + ret = vpfe_try_fmt(file, priv, &format);
> if (ret)
> return ret;
>
> --
> 1.8.5.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v3 1/1] media: am437x-vpfe: Fix a race condition during release
On Mon, Jun 29, 2015 at 10:18 PM, Benoit Parrot wrote:
> There was a race condition where during cleanup/release operation
> on-going streaming would cause a kernel panic because the hardware
> module was disabled prematurely with IRQ still pending.
>
> Fixes: 417d2e507edc ("[media] media: platform: add VPFE capture driver
> support for AM437X")
> Cc: # v4.0+
> Signed-off-by: Benoit Parrot
Acked-by: Lad, Prabhakar
Cheers,
--Prabhakar Lad
> ---
> Changes since v2:
> - fix the stable commit reference syntax
>
> drivers/media/platform/am437x/am437x-vpfe.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/am437x/am437x-vpfe.c
> b/drivers/media/platform/am437x/am437x-vpfe.c
> index a30cc2f7e4f1..eb25c43da126 100644
> --- a/drivers/media/platform/am437x/am437x-vpfe.c
> +++ b/drivers/media/platform/am437x/am437x-vpfe.c
> @@ -1185,14 +1185,21 @@ static int vpfe_initialize_device(struct vpfe_device
> *vpfe)
> static int vpfe_release(struct file *file)
> {
> struct vpfe_device *vpfe = video_drvdata(file);
> + bool fh_singular = v4l2_fh_is_singular_file(file);
> int ret;
>
> mutex_lock(&vpfe->lock);
>
> - if (v4l2_fh_is_singular_file(file))
> - vpfe_ccdc_close(&vpfe->ccdc, vpfe->pdev);
> + /* the release helper will cleanup any on-going streaming */
> ret = _vb2_fop_release(file, NULL);
>
> + /*
> +* If this was the last open file.
> +* Then de-initialize hw module.
> +*/
> + if (fh_singular)
> + vpfe_ccdc_close(&vpfe->ccdc, vpfe->pdev);
> +
> mutex_unlock(&vpfe->lock);
>
> return ret;
> --
> 1.8.5.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-V5 3/4] mfd: 88pm800: Set default interrupt clear method
On Tue, 07 Jul 2015, Vaibhav Hiremath wrote:
> On Tuesday 07 July 2015 04:10 PM, Lee Jones wrote:
> >On Tue, 07 Jul 2015, Vaibhav Hiremath wrote:
> >>On Tuesday 07 July 2015 12:59 PM, Lee Jones wrote:
> >>>On Mon, 29 Jun 2015, Vaibhav Hiremath wrote:
> >>>
> As per the spec, bit 1 (INT_CLEAR_MODE) of reg addr 0xe
> (page 0) controls the method of clearing interrupt
> status of 88pm800 family of devices;
>
> 0: clear on read
> 1: clear on write
>
> If pdata is not coming from board file, then set the
> default irq clear method to "irq clear on write"
>
> Also, as suggested by "Lee Jones" renaming variable field
> to appropriate name.
>
> Signed-off-by: Zhao Ye
> Signed-off-by: Vaibhav Hiremath
> ---
> drivers/mfd/88pm800.c | 15 ++-
> include/linux/mfd/88pm80x.h | 10 --
> 2 files changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
> index d495737..66347be 100644
> --- a/drivers/mfd/88pm800.c
> +++ b/drivers/mfd/88pm800.c
> @@ -374,7 +374,7 @@ static int device_irq_init_800(struct pm80x_chip
> *chip)
> {
> struct regmap *map = chip->regmap;
> unsigned long flags = IRQF_ONESHOT;
> - int data, mask, ret = -EINVAL;
> + int irq_clr_mode, mask, ret = -EINVAL;
>
> if (!map || !chip->irq) {
> dev_err(chip->dev, "incorrect parameters\n");
> @@ -382,15 +382,16 @@ static int device_irq_init_800(struct pm80x_chip
> *chip)
> }
>
> /*
> - * irq_mode defines the way of clearing interrupt. it's read-clear by
> - * default.
> + * irq_clr_on_wr defines the way of clearing interrupt by
> + * read/write(0/1). It's read-clear by default.
> */
> mask =
> PM800_WAKEUP2_INV_INT | PM800_WAKEUP2_INT_CLEAR |
> PM800_WAKEUP2_INT_MASK;
>
> - data = PM800_WAKEUP2_INT_CLEAR;
> - ret = regmap_update_bits(map, PM800_WAKEUP2, mask, data);
> + irq_clr_mode = chip->irq_clr_method == PM800_IRQ_CLR_ON_WRITE ?
> + PM800_WAKEUP2_INT_WRITE_CLEAR : PM800_WAKEUP2_INT_READ_CLEAR;
> + ret = regmap_update_bits(map, PM800_WAKEUP2, mask, irq_clr_mode);
> >>>
> >>>What's stopping you just passing PM800_WAKEUP2_INT_WRITE_CLEAR or
> >>>PM800_WAKEUP2_INT_READ_CLEAR from pdata? Then you can use the value
> >>>directly without all of this faffing about.
> >>>
> >>> regmap_update_bits(map, PM800_WAKEUP2, mask, pdata->irq_clr_mode);
> >>>
> >>
> >>Because "irq_clr_method" is of boolean type.
> >>And macros which you are referring to is,
> >>
> >>#define PM800_WAKEUP2_INT_READ_CLEAR(0 << 1)
> >>#define PM800_WAKEUP2_INT_WRITE_CLEAR (1 << 1)
> >>
> >>
> >>And also, I feel it is more cleaner approach with the current code as
> >>register definition and userflag are maintained separately.
> >
> >I see your point, although it's a shame we have to have this code in
> >its place.
> >
> >One thing I think you can do though is rid chip->irq_clr_method, just
> >use the one you already have in pdata.
> >
>
> Looking at the current code,
> Yes, this can be done, but I have to do some more changes around it,
> to make code cleaner,
>
> change the signature of
>
> static int device_irq_init_800(struct pm80x_chip *chip)
>
> TO
>
> static int device_irq_init_800(struct pm80x_chip *chip, struct
> pm80x_platform_data *pdata)
>
>
> and then only use pdata->irq_clr_method.
>
>
> How do you want to get this inside? V6 version? or separate patch?
>
> I have one more cleanup patch in the queue, which I am planning to
> submit today, if you are ok then I can submit along with that.
Ideally not. Don't you save the 'struct device' into *chip? You
should use that to fetch the pdata, like:
pdata = dev_get_platdata(chip->dev);
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 3/6] irq: bypass: Extend skeleton for ARM forwarding control
On 07/07/2015 13:13, Wu, Feng wrote:
>> > You can use container_of to add it to your own struct, e.g.
>> >
>> >struct irq_bypass_consumer cons;
>> >struct irq_bypass_producer *prod;
> Do you mean this:
>
> struct kvm_kernel_irqfd {
>
> ..
>
> struct irq_bypass_consumer cons;
> struct irq_bypass_producer *prod;
> };
Yes.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 00/17] x86: Rewrite exit-to-userspace code
So this looks mostly problem free on my boxen, except this warning triggers: Adding 3911820k swap on /dev/sda2. Priority:-1 extents:1 across:3911820k capability: warning: `dbus-daemon' uses 32-bit capabilities (legacy support in use) [ cut here ] WARNING: CPU: 1 PID: 2445 at arch/x86/entry/common.c:311 syscall_return_slowpath+0x4c/0x270() syscall 6 left IRQs disabled Modules linked in: CPU: 1 PID: 2445 Comm: distccd Not tainted 4.2.0-rc1-01597-gaecd781-dirty #18 776afac2 880035413e58 81c8915f 880035413eb0 880035413e98 810a8d82 880035413e78 880035413f58 20020002 88003541 Call Trace: [] dump_stack+0x4f/0x7b [] warn_slowpath_common+0xa2/0xc0 [] warn_slowpath_fmt+0x55/0x70 [] syscall_return_slowpath+0x4c/0x270 [] int_ret_from_sys_call+0x25/0x9f ---[ end trace 083efc734e089d37 ]--- device: 'vcs2': device_add PM: Adding info for No Bus:vcs2 device: 'vcsa2': device_add with ancient user-space, running the attached .config. The system booted up fine otherwise. The warning corresponds to: if (WARN(irqs_disabled(), "syscall %ld left IRQs disabled", regs->orig_ax)) local_irq_enable(); and this was just the regular startup of the distccd daemon during bootup, nothing particularly fancy. Note that 'distccd' is a 32-bit ELF binary - and this is a 64-bit kernel. Syscall 6 would be: arch/x86/entry/syscalls/syscall_32.tbl:6i386close sys_close Thanks, Ingo # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 4.2.0-rc1 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf64-x86-64" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_64_SMP=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11" CONFIG_BOOTPARAM_SUPPORT_NOT_WANTED=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=4 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_BOOT_ALLOWED4=y # CONFIG_BROKEN_BOOT_ALLOWED3 is not set # CONFIG_BROKEN_BOOT_DISALLOWED is not set CONFIG_BROKEN_BOOT_EUROPE=y CONFIG_BROKEN_BOOT_TITAN=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set CONFIG_KERNEL_BZIP2=y # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_CROSS_MEMORY_ATTACH is not set # CONFIG_FHANDLE is not set # CONFIG_USELIB is not set # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # # CONFIG_TICK_CPU_ACCOUNTING is not set # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set CONFIG_IRQ_TIME_ACCOUNTING=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # # RCU Subsystem # CONFIG_PREEMP
Re: [RFC PATCH v3 0/4] Integration of trace events with System Trace IP blocks
Chunyan Zhang writes: > I'm eager to see your comments on this, and if you have some good > ideas that can slow down the overhead, please let me know. Any > questions are also welcome. Hi, A brief looks tells me that your code is based on an older version of mine. Can you please update so that our work is more in sync and it would also make it easier for me to review. Thanks, -- Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] base: power: wakeirq: don't leak dev->power.wakeirq
On Tue, Jul 7, 2015 at 10:11 AM, Felipe Balbi wrote: > On Tue, Jul 07, 2015 at 12:40:53AM -0700, Tony Lindgren wrote: >> * Rafael J. Wysocki [150706 15:49]: >> > On Monday, July 06, 2015 01:01:18 PM Felipe Balbi wrote: >> > > on a first call to dev_pm_attach_wake_irq(), if it >> > > fails, it will leave dev->power.wakeirq set to a >> > > dangling pointer. Instead, let's clear it to make >> > > sure a subsequent call to dev_pm_attach_wake_irq() >> > > has chance to succeed. >> > > >> > > Cc: Tony Lindgren >> > > Signed-off-by: Felipe Balbi >> > > --- >> > > drivers/base/power/wakeirq.c | 9 - >> > > 1 file changed, 8 insertions(+), 1 deletion(-) >> > > >> > > diff --git a/drivers/base/power/wakeirq.c b/drivers/base/power/wakeirq.c >> > > index 7470004ca810..394d250a1ad8 100644 >> > > --- a/drivers/base/power/wakeirq.c >> > > +++ b/drivers/base/power/wakeirq.c >> > > @@ -50,9 +50,16 @@ static int dev_pm_attach_wake_irq(struct device *dev, >> > > int irq, >> > > >> > > err = device_wakeup_attach_irq(dev, wirq); >> > > if (err) >> > > - return err; >> > > + goto err_cleanup; >> > > >> > > return 0; >> > > + >> > > +err_cleanup: >> > > + spin_lock_irqsave(&dev->power.lock, flags); >> > > + dev->power.wakeirq = NULL; >> > > + spin_unlock_irqrestore(&dev->power.lock, flags); >> > > + >> > > + return err; >> > > } >> > >> > Too many labels for me and the fact that acquiring of the lock again in >> > the error >> > patch doesn't look good. >> > >> > However, we can do the entire device_wakeup_attach_irq() under the lock >> > (after >> > removing the locking from it), because we're its only caller. >> > >> > So what about the below instead (build-tested only)? >> >> Nice, still works for me and simplifies things: >> >> Tested-by: Tony Lindgren > > Cool, thanks for testing Tony. Rafael, I'm fine with your version too. > FWIW: > > Reported-by: Felipe Balbi OK, applied. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mfd: wm8994-regmap: Constify reg_default tables
These reg_default tables are not modified after initialized, so make them
const.
Signed-off-by: Axel Lin
---
drivers/mfd/wm8994-regmap.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/wm8994-regmap.c b/drivers/mfd/wm8994-regmap.c
index 300e9b6..c56b160 100644
--- a/drivers/mfd/wm8994-regmap.c
+++ b/drivers/mfd/wm8994-regmap.c
@@ -19,7 +19,7 @@
#include "wm8994.h"
-static struct reg_default wm1811_defaults[] = {
+static const struct reg_default wm1811_defaults[] = {
{ 0x0001, 0x },/* R1- Power Management (1) */
{ 0x0002, 0x6000 },/* R2- Power Management (2) */
{ 0x0003, 0x },/* R3- Power Management (3) */
@@ -251,7 +251,7 @@ static struct reg_default wm1811_defaults[] = {
{ 0x0748, 0x003F },/* R1864 - IRQ Debounce */
};
-static struct reg_default wm8994_defaults[] = {
+static const struct reg_default wm8994_defaults[] = {
{ 0x0001, 0x },/* R1 - Power Management (1) */
{ 0x0002, 0x6000 },/* R2 - Power Management (2) */
{ 0x0003, 0x },/* R3 - Power Management (3) */
@@ -470,7 +470,7 @@ static struct reg_default wm8994_defaults[] = {
{ 0x0748, 0x003F },/* R1864 - IRQ Debounce */
};
-static struct reg_default wm8958_defaults[] = {
+static const struct reg_default wm8958_defaults[] = {
{ 0x0001, 0x },/* R1 - Power Management (1) */
{ 0x0002, 0x6000 },/* R2 - Power Management (2) */
{ 0x0003, 0x },/* R3 - Power Management (3) */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] megaraid:Remove no longer required variable ret from the function megasas_sync_map_info
> -Original Message-
> From: Frans Klaver [mailto:franskla...@gmail.com]
> Sent: Tuesday, July 07, 2015 3:37 PM
> To: Sumit Saxena
> Cc: Nicholas Krause; Kashyap Desai; Uday Lingala; jbottom...@odin.com;
> PDL,MEGARAIDLINUX; linux-s...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] megaraid:Remove no longer required variable ret from
> the
> function megasas_sync_map_info
>
> Can't seem to find the original, so here's a reply to the ack mail.
>
> On Tue, Jul 7, 2015 at 10:49 AM, Sumit Saxena
> wrote:
> > -Original Message-
> > From: Nicholas Krause [mailto:xerofo...@gmail.com]
> > Sent: Monday, July 06, 2015 9:43 PM
> > To: kashyap.de...@avagotech.com
> > Cc: sumit.sax...@avagotech.com; uday.ling...@avagotech.com;
> > jbottom...@odin.com; megaraidlinux@avagotech.com;
> > linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org
> > Subject: [PATCH] megaraid:Remove no longer required variable ret from
> > the function megasas_sync_map_info
>
> Isn't something shorter like
>
> [PATCH] megaraid: remove pointless variable
>
> much more readable?
>
>
> > This removes the no longer required variable ret due to this variable
> > only ever being used at the end of the function megasas_sync_map_info
> > without changing it's value from the orginal setting of its value to
> > zero due to this just remove the variable ret and just return the
> > value of zero directly here in order to indicate to the caller the
> > call to this function has run successfully without any non recoverable
> > issues.
>
> No interpunction?
>
>
> > Signed-off-by: Nicholas Krause
> > ---
> > drivers/scsi/megaraid/megaraid_sas_fusion.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> > b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> > index 46a0f8f..b5a8c65 100644
> > --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> > +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> > @@ -836,7 +836,7 @@ megasas_get_map_info(struct megasas_instance
> > *instance) int megasas_sync_map_info(struct megasas_instance
> > *instance) {
> > - int ret = 0, i;
> > + int i;
> > struct megasas_cmd *cmd;
> > struct megasas_dcmd_frame *dcmd;
> > u32 size_sync_info, num_lds;
> > @@ -906,7 +906,7 @@ megasas_sync_map_info(struct megasas_instance
> > *instance)
> >
> > instance->instancet->issue_dcmd(instance, cmd);
> >
> > - return ret;
> > + return 0;
> > }
> >
> > Acked-by: Sumit Saxena
>
> This ack in an outlook-style response confused the hell out of me ;).
Sorry for confusion. I just got new laptop with default outlook settings so
last message sent was in outlook-style, configured it now.
Thanks,
Sumit
>
> Thanks,
> Frans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 3/6] irq: bypass: Extend skeleton for ARM forwarding control
On 07/07/2015 12:58, Wu, Feng wrote:
>
>
>> -Original Message-
>> From: Eric Auger [mailto:eric.au...@linaro.org]
>> Sent: Monday, July 06, 2015 8:11 PM
>> To: eric.au...@st.com; eric.au...@linaro.org;
>> linux-arm-ker...@lists.infradead.org; kvm...@lists.cs.columbia.edu;
>> k...@vger.kernel.org; christoffer.d...@linaro.org; marc.zyng...@arm.com;
>> alex.william...@redhat.com; pbonz...@redhat.com; avi.kiv...@gmail.com;
>> mtosa...@redhat.com; Wu, Feng; j...@8bytes.org;
>> b.rey...@virtualopensystems.com
>> Cc: linux-kernel@vger.kernel.org; patc...@linaro.org
>> Subject: [RFC v2 3/6] irq: bypass: Extend skeleton for ARM forwarding control
>>
>> - [add,del]_[consumer,producer] updated to takes both the consumer and
>> producer handles. This is requested to combine info from both,
>> typically to link the source irq owned by the producer with the gsi
>> owned by the consumer (forwarded IRQ setup).
>> - new methods are added:
>> x stop/resume: Those are needed for forwarding since the state change
>> requires to entermingle actions at consumer, producer.
>> x consumer update for posted interrupts
>> - On handshake, we now call connect, disconnect which features the more
>> complex sequence.
>> - add irq on producer side
>>
>> Signed-off-by: Eric Auger
>>
>> ---
>>
>> v1 -> v2:
>> - remove vfio_device, kvm, gsi, opaque fields included in v1 except common
>> - all those in can be retrieved with container_of in callbacks
>> ---
>> include/linux/irqbypass.h | 19 ---
>> kernel/irq/bypass.c | 44
>>
>> 2 files changed, 56 insertions(+), 7 deletions(-)
>>
>> diff --git a/include/linux/irqbypass.h b/include/linux/irqbypass.h
>> index 718508e..8f62235 100644
>> --- a/include/linux/irqbypass.h
>> +++ b/include/linux/irqbypass.h
>> @@ -3,17 +3,30 @@
>>
>> #include
>>
>> +struct irq_bypass_consumer;
>> +
>> struct irq_bypass_producer {
>> struct list_head node;
>> void *token;
>> -/* TBD */
>> +int irq; /* linux irq */
>> +void (*stop)(struct irq_bypass_producer *);
>> +void (*resume)(struct irq_bypass_producer *);
>> +void (*add_consumer)(struct irq_bypass_producer *,
>> + struct irq_bypass_consumer *);
>> +void (*del_consumer)(struct irq_bypass_producer *,
>> + struct irq_bypass_consumer *);
>> };
>>
>> struct irq_bypass_consumer {
>> struct list_head node;
>> void *token;
>
> Can we add a pointer to ' struct irq_bypass_producer ', and
> assign it when connecting, de-assign it when disconnecting.
> since in some case, I need to update IRTE from the consumer
> side, where I cannot get the related producer info (I need irq info)
> without iterating it again.
You can use container_of to add it to your own struct, e.g.
struct irq_bypass_consumer cons;
struct irq_bypass_producer *prod;
Paolo
> Thanks,
> Feng
>
>> -void (*add_producer)(struct irq_bypass_producer *);
>> -void (*del_producer)(struct irq_bypass_producer *);
>> +void (*stop)(struct irq_bypass_consumer *);
>> +void (*resume)(struct irq_bypass_consumer *);
>> +void (*add_producer)(struct irq_bypass_consumer *,
>> + struct irq_bypass_producer *);
>> +void (*del_producer)(struct irq_bypass_consumer *,
>> + struct irq_bypass_producer *);
>> +void (*update)(struct irq_bypass_consumer *);
>> };
>>
>> int irq_bypass_register_producer(struct irq_bypass_producer *);
>> diff --git a/kernel/irq/bypass.c b/kernel/irq/bypass.c
>> index 5d0f92b..efadbe5 100644
>> --- a/kernel/irq/bypass.c
>> +++ b/kernel/irq/bypass.c
>> @@ -19,6 +19,42 @@ static LIST_HEAD(producers);
>> static LIST_HEAD(consumers);
>> static DEFINE_MUTEX(lock);
>>
>> +/* lock must be hold when calling connect */
>> +static void connect(struct irq_bypass_producer *prod,
>> +struct irq_bypass_consumer *cons)
>> +{
>> +if (prod->stop)
>> +prod->stop(prod);
>> +if (cons->stop)
>> +cons->stop(cons);
>> +if (prod->add_consumer)
>> +prod->add_consumer(prod, cons);
>> +if (cons->add_producer)
>> +cons->add_producer(cons, prod);
>> +if (cons->resume)
>> +cons->resume(cons);
>> +if (prod->resume)
>> +prod->resume(prod);
>> +}
>> +
>> +/* lock must be hold when calling disconnect */
>> +static void disconnect(struct irq_bypass_producer *prod,
>> + struct irq_bypass_consumer *cons)
>> +{
>> +if (prod->stop)
>> +prod->stop(prod);
>> +if (cons->stop)
>> +cons->stop(cons);
>> +if (cons->del_producer)
>> +cons->del_producer(cons, prod);
>> +if (prod->del_consumer)
>> +prod->del_consumer(prod, cons);
>> +if (cons->resume)
>> +cons->resume(cons);
>> +if (prod->resume)
>> +prod->resume(prod);
>> +}
>> +
>> int irq_b
RE: [RFC v2 3/6] irq: bypass: Extend skeleton for ARM forwarding control
> -Original Message-
> From: Eric Auger [mailto:eric.au...@linaro.org]
> Sent: Monday, July 06, 2015 8:11 PM
> To: eric.au...@st.com; eric.au...@linaro.org;
> linux-arm-ker...@lists.infradead.org; kvm...@lists.cs.columbia.edu;
> k...@vger.kernel.org; christoffer.d...@linaro.org; marc.zyng...@arm.com;
> alex.william...@redhat.com; pbonz...@redhat.com; avi.kiv...@gmail.com;
> mtosa...@redhat.com; Wu, Feng; j...@8bytes.org;
> b.rey...@virtualopensystems.com
> Cc: linux-kernel@vger.kernel.org; patc...@linaro.org
> Subject: [RFC v2 3/6] irq: bypass: Extend skeleton for ARM forwarding control
>
> - [add,del]_[consumer,producer] updated to takes both the consumer and
> producer handles. This is requested to combine info from both,
> typically to link the source irq owned by the producer with the gsi
> owned by the consumer (forwarded IRQ setup).
> - new methods are added:
> x stop/resume: Those are needed for forwarding since the state change
> requires to entermingle actions at consumer, producer.
> x consumer update for posted interrupts
> - On handshake, we now call connect, disconnect which features the more
> complex sequence.
> - add irq on producer side
>
> Signed-off-by: Eric Auger
>
> ---
>
> v1 -> v2:
> - remove vfio_device, kvm, gsi, opaque fields included in v1 except common
> - all those in can be retrieved with container_of in callbacks
> ---
> include/linux/irqbypass.h | 19 ---
> kernel/irq/bypass.c | 44
>
> 2 files changed, 56 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/irqbypass.h b/include/linux/irqbypass.h
> index 718508e..8f62235 100644
> --- a/include/linux/irqbypass.h
> +++ b/include/linux/irqbypass.h
> @@ -3,17 +3,30 @@
>
> #include
>
> +struct irq_bypass_consumer;
> +
> struct irq_bypass_producer {
> struct list_head node;
> void *token;
> - /* TBD */
> + int irq; /* linux irq */
> + void (*stop)(struct irq_bypass_producer *);
> + void (*resume)(struct irq_bypass_producer *);
> + void (*add_consumer)(struct irq_bypass_producer *,
> + struct irq_bypass_consumer *);
> + void (*del_consumer)(struct irq_bypass_producer *,
> + struct irq_bypass_consumer *);
> };
>
> struct irq_bypass_consumer {
> struct list_head node;
> void *token;
Can we add a pointer to ' struct irq_bypass_producer ', and
assign it when connecting, de-assign it when disconnecting.
since in some case, I need to update IRTE from the consumer
side, where I cannot get the related producer info (I need irq info)
without iterating it again.
Thanks,
Feng
> - void (*add_producer)(struct irq_bypass_producer *);
> - void (*del_producer)(struct irq_bypass_producer *);
> + void (*stop)(struct irq_bypass_consumer *);
> + void (*resume)(struct irq_bypass_consumer *);
> + void (*add_producer)(struct irq_bypass_consumer *,
> + struct irq_bypass_producer *);
> + void (*del_producer)(struct irq_bypass_consumer *,
> + struct irq_bypass_producer *);
> + void (*update)(struct irq_bypass_consumer *);
> };
>
> int irq_bypass_register_producer(struct irq_bypass_producer *);
> diff --git a/kernel/irq/bypass.c b/kernel/irq/bypass.c
> index 5d0f92b..efadbe5 100644
> --- a/kernel/irq/bypass.c
> +++ b/kernel/irq/bypass.c
> @@ -19,6 +19,42 @@ static LIST_HEAD(producers);
> static LIST_HEAD(consumers);
> static DEFINE_MUTEX(lock);
>
> +/* lock must be hold when calling connect */
> +static void connect(struct irq_bypass_producer *prod,
> + struct irq_bypass_consumer *cons)
> +{
> + if (prod->stop)
> + prod->stop(prod);
> + if (cons->stop)
> + cons->stop(cons);
> + if (prod->add_consumer)
> + prod->add_consumer(prod, cons);
> + if (cons->add_producer)
> + cons->add_producer(cons, prod);
> + if (cons->resume)
> + cons->resume(cons);
> + if (prod->resume)
> + prod->resume(prod);
> +}
> +
> +/* lock must be hold when calling disconnect */
> +static void disconnect(struct irq_bypass_producer *prod,
> +struct irq_bypass_consumer *cons)
> +{
> + if (prod->stop)
> + prod->stop(prod);
> + if (cons->stop)
> + cons->stop(cons);
> + if (cons->del_producer)
> + cons->del_producer(cons, prod);
> + if (prod->del_consumer)
> + prod->del_consumer(prod, cons);
> + if (cons->resume)
> + cons->resume(cons);
> + if (prod->resume)
> + prod->resume(prod);
> +}
> +
> int irq_bypass_register_producer(struct irq_bypass_producer *producer)
> {
> struct irq_bypass_producer *tmp;
> @@ -38,7 +74,7 @@ int irq_bypass_register_producer(struct
> irq_bypass_producer *producer)
>
> list_for_each_entry(consumer, &consumers, node) {
>
Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature
On Tue, Jul 07, Dexuan Cui wrote: > OK, removing the line seems better than 'default n', though both reproduce > the same "# CONFIG_HYPERV_SOCK is not set". Perhaps "default VMBUS" (or whatever syntax is needed) may be the way to enable it conditionally. Olaf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi
> I just don't want to end up with something like: > (GICV3 && ARM64) || (GICV3 && ARM && KERNEL>4.4) || (SuperIRQC && i986) > or > (ARM || ARM64) && HAS_IRQ_ROUTING > > Instead: If the kernel needs it, it tells you. Full stop. Agree. > To be honest it's me to blame here to not having introduced the > capability earlier. At the moment ARM has a different code path for > KVM_SIGNAL_MSI, which does not bail out if the flag field is set. With > Eric's patches this changes and we use the irqchip.c generic code, which > returns -EINVAL atm. So I plan to introduce this capability already with > the ITS emulation series, so we can just pick it up in the IRQ routing > series. Then may be you follow https://lkml.org/lkml/2015/7/7/115 and replace flag with something like KVM_SIGNAL_EXT_MSI ioctl ? After all you were one of people who voted against using flags. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/6] Input: pixcir_i2c_ts - allow using with GPIO expanders
On 07/07/15 03:30, Dmitry Torokhov wrote:
We are using threaded interrupt handler and thus are allowed to sleep.
Let's switch over to gpiod_get_value_cansleep() so that we do not get
ugly warnings in case GPIO controller might sleep when accessing GPIO.
Signed-off-by: Dmitry Torokhov
Acked-by: Roger Quadros
cheers,
-roger
---
drivers/input/touchscreen/pixcir_i2c_ts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/pixcir_i2c_ts.c
b/drivers/input/touchscreen/pixcir_i2c_ts.c
index 9093aa9..8965d7c 100644
--- a/drivers/input/touchscreen/pixcir_i2c_ts.c
+++ b/drivers/input/touchscreen/pixcir_i2c_ts.c
@@ -171,7 +171,7 @@ static irqreturn_t pixcir_ts_isr(int irq, void *dev_id)
/* report it */
pixcir_ts_report(tsdata, &report);
- if (gpiod_get_value(tsdata->gpio_attb)) {
+ if (gpiod_get_value_cansleep(tsdata->gpio_attb)) {
if (report.num_touches) {
/*
* Last report with no finger up?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/asm] x86/irq, context_tracking: Document how IRQ context tracking works and add an RCU assertion
Commit-ID: 0333a209cbf600e980fc55c24878a56f25f48b65
Gitweb: http://git.kernel.org/tip/0333a209cbf600e980fc55c24878a56f25f48b65
Author: Andy Lutomirski
AuthorDate: Fri, 3 Jul 2015 12:44:34 -0700
Committer: Ingo Molnar
CommitDate: Tue, 7 Jul 2015 10:59:10 +0200
x86/irq, context_tracking: Document how IRQ context tracking works and add an
RCU assertion
Signed-off-by: Andy Lutomirski
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: Denys Vlasenko
Cc: Frederic Weisbecker
Cc: H. Peter Anvin
Cc: Kees Cook
Cc: Linus Torvalds
Cc: Oleg Nesterov
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: paul...@linux.vnet.ibm.com
Link:
http://lkml.kernel.org/r/e8bdc4ed0193fb2fd130f3d6b7b8023e2ec1ab62.1435952415.git.l...@kernel.org
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/irq.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index 88b36648..6233de0 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -216,8 +216,23 @@ __visible unsigned int __irq_entry do_IRQ(struct pt_regs
*regs)
unsigned vector = ~regs->orig_ax;
unsigned irq;
+ /*
+* NB: Unlike exception entries, IRQ entries do not reliably
+* handle context tracking in the low-level entry code. This is
+* because syscall entries execute briefly with IRQs on before
+* updating context tracking state, so we can take an IRQ from
+* kernel mode with CONTEXT_USER. The low-level entry code only
+* updates the context if we came from user mode, so we won't
+* switch to CONTEXT_KERNEL. We'll fix that once the syscall
+* code is cleaned up enough that we can cleanly defer enabling
+* IRQs.
+*/
+
entering_irq();
+ /* entering_irq() tells RCU that we're not quiescent. Check it. */
+ rcu_lockdep_assert(rcu_is_watching(), "IRQ failed to wake up RCU");
+
irq = __this_cpu_read(vector_irq[vector]);
if (!handle_irq(irq, regs)) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/asm] x86/entry: Remove SCHEDULE_USER and asm/ context-tracking.h
Commit-ID: 06a7b36c7bd932e60997bedbae32b3d8e6722281 Gitweb: http://git.kernel.org/tip/06a7b36c7bd932e60997bedbae32b3d8e6722281 Author: Andy Lutomirski AuthorDate: Fri, 3 Jul 2015 12:44:33 -0700 Committer: Ingo Molnar CommitDate: Tue, 7 Jul 2015 10:59:09 +0200 x86/entry: Remove SCHEDULE_USER and asm/context-tracking.h SCHEDULE_USER is no longer used, and asm/context-tracking.h contained nothing else. Remove the header entirely. Signed-off-by: Andy Lutomirski Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: Denys Vlasenko Cc: Frederic Weisbecker Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Oleg Nesterov Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Cc: paul...@linux.vnet.ibm.com Link: http://lkml.kernel.org/r/854e9b45f69af20e26c47099eb236321563ebcee.1435952415.git.l...@kernel.org Signed-off-by: Ingo Molnar --- arch/x86/entry/entry_64.S | 1 - arch/x86/include/asm/context_tracking.h | 10 -- 2 files changed, 11 deletions(-) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index 168ee26..041a37a 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -33,7 +33,6 @@ #include #include #include -#include #include #include #include diff --git a/arch/x86/include/asm/context_tracking.h b/arch/x86/include/asm/context_tracking.h deleted file mode 100644 index 1fe4970..000 --- a/arch/x86/include/asm/context_tracking.h +++ /dev/null @@ -1,10 +0,0 @@ -#ifndef _ASM_X86_CONTEXT_TRACKING_H -#define _ASM_X86_CONTEXT_TRACKING_H - -#ifdef CONFIG_CONTEXT_TRACKING -# define SCHEDULE_USER call schedule_user -#else -# define SCHEDULE_USER call schedule -#endif - -#endif -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/asm] x86/entry: Remove exception_enter() from most trap handlers
Commit-ID: 8c84014f3bbb112d07e73f30a10ac8a3a72f8649
Gitweb: http://git.kernel.org/tip/8c84014f3bbb112d07e73f30a10ac8a3a72f8649
Author: Andy Lutomirski
AuthorDate: Fri, 3 Jul 2015 12:44:32 -0700
Committer: Ingo Molnar
CommitDate: Tue, 7 Jul 2015 10:59:09 +0200
x86/entry: Remove exception_enter() from most trap handlers
On 64-bit kernels, we don't need it any more: we handle context
tracking directly on entry from user mode and exit to user mode.
On 32-bit kernels, we don't support context tracking at all, so
these callbacks had no effect.
Note: this doesn't change do_page_fault(). Before we do that,
we need to make sure that there is no code that can page fault
from kernel mode with CONTEXT_USER. The 32-bit fast system call
stack argument code is the only offender I'm aware of right now.
Signed-off-by: Andy Lutomirski
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: Denys Vlasenko
Cc: Frederic Weisbecker
Cc: H. Peter Anvin
Cc: Kees Cook
Cc: Linus Torvalds
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: paul...@linux.vnet.ibm.com
Link:
http://lkml.kernel.org/r/ae22f4dfebd799c916574089964592be218151f9.1435952415.git.l...@kernel.org
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/traps.h | 4 +-
arch/x86/kernel/cpu/mcheck/mce.c | 5 +--
arch/x86/kernel/cpu/mcheck/p5.c | 5 +--
arch/x86/kernel/cpu/mcheck/winchip.c | 4 +-
arch/x86/kernel/traps.c | 78 +---
5 files changed, 27 insertions(+), 69 deletions(-)
diff --git a/arch/x86/include/asm/traps.h b/arch/x86/include/asm/traps.h
index c5380be..c3496619 100644
--- a/arch/x86/include/asm/traps.h
+++ b/arch/x86/include/asm/traps.h
@@ -112,8 +112,8 @@ asmlinkage void smp_threshold_interrupt(void);
asmlinkage void smp_deferred_error_interrupt(void);
#endif
-extern enum ctx_state ist_enter(struct pt_regs *regs);
-extern void ist_exit(struct pt_regs *regs, enum ctx_state prev_state);
+extern void ist_enter(struct pt_regs *regs);
+extern void ist_exit(struct pt_regs *regs);
extern void ist_begin_non_atomic(struct pt_regs *regs);
extern void ist_end_non_atomic(void);
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 96ccecc..99940d1 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1029,7 +1029,6 @@ void do_machine_check(struct pt_regs *regs, long
error_code)
{
struct mca_config *cfg = &mca_cfg;
struct mce m, *final;
- enum ctx_state prev_state;
int i;
int worst = 0;
int severity;
@@ -1055,7 +1054,7 @@ void do_machine_check(struct pt_regs *regs, long
error_code)
int flags = MF_ACTION_REQUIRED;
int lmce = 0;
- prev_state = ist_enter(regs);
+ ist_enter(regs);
this_cpu_inc(mce_exception_count);
@@ -1227,7 +1226,7 @@ out:
local_irq_disable();
ist_end_non_atomic();
done:
- ist_exit(regs, prev_state);
+ ist_exit(regs);
}
EXPORT_SYMBOL_GPL(do_machine_check);
diff --git a/arch/x86/kernel/cpu/mcheck/p5.c b/arch/x86/kernel/cpu/mcheck/p5.c
index 737b0ad..12402e1 100644
--- a/arch/x86/kernel/cpu/mcheck/p5.c
+++ b/arch/x86/kernel/cpu/mcheck/p5.c
@@ -19,10 +19,9 @@ int mce_p5_enabled __read_mostly;
/* Machine check handler for Pentium class Intel CPUs: */
static void pentium_machine_check(struct pt_regs *regs, long error_code)
{
- enum ctx_state prev_state;
u32 loaddr, hi, lotype;
- prev_state = ist_enter(regs);
+ ist_enter(regs);
rdmsr(MSR_IA32_P5_MC_ADDR, loaddr, hi);
rdmsr(MSR_IA32_P5_MC_TYPE, lotype, hi);
@@ -39,7 +38,7 @@ static void pentium_machine_check(struct pt_regs *regs, long
error_code)
add_taint(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);
- ist_exit(regs, prev_state);
+ ist_exit(regs);
}
/* Set up machine check reporting for processors with Intel style MCE: */
diff --git a/arch/x86/kernel/cpu/mcheck/winchip.c
b/arch/x86/kernel/cpu/mcheck/winchip.c
index 44f1382..01dd870 100644
--- a/arch/x86/kernel/cpu/mcheck/winchip.c
+++ b/arch/x86/kernel/cpu/mcheck/winchip.c
@@ -15,12 +15,12 @@
/* Machine check handler for WinChip C6: */
static void winchip_machine_check(struct pt_regs *regs, long error_code)
{
- enum ctx_state prev_state = ist_enter(regs);
+ ist_enter(regs);
printk(KERN_EMERG "CPU0: Machine Check Exception.\n");
add_taint(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);
- ist_exit(regs, prev_state);
+ ist_exit(regs);
}
/* Set up machine check reporting on the Winchip C6 series */
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 2a783c4..8e65d8a 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -108,13 +108,10 @@ static inline void preempt_conditional_cli(struct pt_regs
*regs)
preempt_count_dec();
}
-enum ctx_state ist_ente
Re: [PATCH 2/6] Input: pixcir_i2c_ts - switch the device over to gpiod
On 07/07/15 03:30, Dmitry Torokhov wrote:
This allows uniform parsing on legacy, DT and ACPI systems.
Signed-off-by: Dmitry Torokhov
Acked-by: Roger Quadros
cheers,
-roger
---
drivers/input/touchscreen/pixcir_i2c_ts.c | 26 +-
include/linux/platform_data/pixcir_i2c_ts.h | 1 -
2 files changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/input/touchscreen/pixcir_i2c_ts.c
b/drivers/input/touchscreen/pixcir_i2c_ts.c
index ccafa75..9093aa9 100644
--- a/drivers/input/touchscreen/pixcir_i2c_ts.c
+++ b/drivers/input/touchscreen/pixcir_i2c_ts.c
@@ -25,8 +25,8 @@
#include
#include
#include
+#include
#include
-#include
#include
#include
@@ -35,6 +35,7 @@
struct pixcir_i2c_ts_data {
struct i2c_client *client;
struct input_dev *input;
+ struct gpio_desc *gpio_attb;
const struct pixcir_ts_platform_data *pdata;
bool running;
int max_fingers;/* Max fingers supported in this instance */
@@ -161,7 +162,6 @@ static void pixcir_ts_report(struct pixcir_i2c_ts_data *ts,
static irqreturn_t pixcir_ts_isr(int irq, void *dev_id)
{
struct pixcir_i2c_ts_data *tsdata = dev_id;
- const struct pixcir_ts_platform_data *pdata = tsdata->pdata;
struct pixcir_report_data report;
while (tsdata->running) {
@@ -171,7 +171,7 @@ static irqreturn_t pixcir_ts_isr(int irq, void *dev_id)
/* report it */
pixcir_ts_report(tsdata, &report);
- if (gpio_get_value(pdata->gpio_attb)) {
+ if (gpiod_get_value(tsdata->gpio_attb)) {
if (report.num_touches) {
/*
* Last report with no finger up?
@@ -427,9 +427,6 @@ static struct pixcir_ts_platform_data
*pixcir_parse_dt(struct device *dev)
pdata->chip = *(const struct pixcir_i2c_chip_data *)match->data;
- pdata->gpio_attb = of_get_named_gpio(np, "attb-gpio", 0);
- /* gpio_attb validity is checked in probe */
-
if (of_property_read_u32(np, "touchscreen-size-x", &pdata->x_max)) {
dev_err(dev, "Failed to get touchscreen-size-x property\n");
return ERR_PTR(-EINVAL);
@@ -442,8 +439,8 @@ static struct pixcir_ts_platform_data
*pixcir_parse_dt(struct device *dev)
}
pdata->y_max -= 1;
- dev_dbg(dev, "%s: x %d, y %d, gpio %d\n", __func__,
- pdata->x_max + 1, pdata->y_max + 1, pdata->gpio_attb);
+ dev_dbg(dev, "%s: x %d, y %d\n", __func__,
+ pdata->x_max + 1, pdata->y_max + 1);
return pdata;
}
@@ -476,11 +473,6 @@ static int pixcir_i2c_ts_probe(struct i2c_client *client,
return -EINVAL;
}
- if (!gpio_is_valid(pdata->gpio_attb)) {
- dev_err(dev, "Invalid gpio_attb in pdata\n");
- return -EINVAL;
- }
-
if (!pdata->chip.max_fingers) {
dev_err(dev, "Invalid max_fingers in pdata\n");
return -EINVAL;
@@ -530,10 +522,10 @@ static int pixcir_i2c_ts_probe(struct i2c_client *client,
input_set_drvdata(input, tsdata);
- error = devm_gpio_request_one(dev, pdata->gpio_attb,
- GPIOF_DIR_IN, "pixcir_i2c_attb");
- if (error) {
- dev_err(dev, "Failed to request ATTB gpio\n");
+ tsdata->gpio_attb = devm_gpiod_get(dev, "attb", GPIOD_IN);
+ if (IS_ERR(tsdata->gpio_attb)) {
+ error = PTR_ERR(tsdata->gpio_attb);
+ dev_err(dev, "Failed to request ATTB gpio: %d\n", error);
return error;
}
diff --git a/include/linux/platform_data/pixcir_i2c_ts.h
b/include/linux/platform_data/pixcir_i2c_ts.h
index 7bae83b..646af6f 100644
--- a/include/linux/platform_data/pixcir_i2c_ts.h
+++ b/include/linux/platform_data/pixcir_i2c_ts.h
@@ -57,7 +57,6 @@ struct pixcir_i2c_chip_data {
struct pixcir_ts_platform_data {
int x_max;
int y_max;
- int gpio_attb; /* GPIO connected to ATTB line */
struct pixcir_i2c_chip_data chip;
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/asm] x86/asm/entry/64: Save all regs on interrupt entry
Commit-ID: ff467594f2a4be01a0fa5e9ffc223fa930d232dd Gitweb: http://git.kernel.org/tip/ff467594f2a4be01a0fa5e9ffc223fa930d232dd Author: Andy Lutomirski AuthorDate: Fri, 3 Jul 2015 12:44:29 -0700 Committer: Ingo Molnar CommitDate: Tue, 7 Jul 2015 10:59:07 +0200 x86/asm/entry/64: Save all regs on interrupt entry To prepare for the big rewrite of the error and interrupt exit paths, we will need pt_regs completely filled in. It's already completely filled in when error_exit runs, so rearrange interrupt handling to match it. This will slow down interrupt handling very slightly (eight instructions), but the simplification it enables will be more than worth it. Signed-off-by: Andy Lutomirski Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: Denys Vlasenko Cc: Frederic Weisbecker Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Oleg Nesterov Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Cc: paul...@linux.vnet.ibm.com Link: http://lkml.kernel.org/r/d8a766a7f558b30e6e01352854628a2d9943460c.1435952415.git.l...@kernel.org Signed-off-by: Ingo Molnar --- arch/x86/entry/calling.h | 3 --- arch/x86/entry/entry_64.S | 29 + 2 files changed, 9 insertions(+), 23 deletions(-) diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h index 519207f..3c71dd9 100644 --- a/arch/x86/entry/calling.h +++ b/arch/x86/entry/calling.h @@ -135,9 +135,6 @@ For 32-bit we have the following conventions - kernel is built with movq %rbp, 4*8+\offset(%rsp) movq %rbx, 5*8+\offset(%rsp) .endm - .macro SAVE_EXTRA_REGS_RBP offset=0 - movq %rbp, 4*8+\offset(%rsp) - .endm .macro RESTORE_EXTRA_REGS offset=0 movq 0*8+\offset(%rsp), %r15 diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index 4ca5b78..65029f4 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -502,21 +502,13 @@ END(irq_entries_start) /* 0(%rsp): ~(interrupt number) */ .macro interrupt func cld - /* -* Since nothing in interrupt handling code touches r12...r15 members -* of "struct pt_regs", and since interrupts can nest, we can save -* four stack slots and simultaneously provide -* an unwind-friendly stack layout by saving "truncated" pt_regs -* exactly up to rbp slot, without these members. -*/ - ALLOC_PT_GPREGS_ON_STACK -RBP - SAVE_C_REGS -RBP - /* this goes to 0(%rsp) for unwinder, not for saving the value: */ - SAVE_EXTRA_REGS_RBP -RBP + ALLOC_PT_GPREGS_ON_STACK + SAVE_C_REGS + SAVE_EXTRA_REGS - leaq-RBP(%rsp), %rdi/* arg1 for \func (pointer to pt_regs) */ + movq%rsp,%rdi /* arg1 for \func (pointer to pt_regs) */ - testb $3, CS-RBP(%rsp) + testb $3, CS(%rsp) jz 1f SWAPGS 1: @@ -553,9 +545,7 @@ ret_from_intr: declPER_CPU_VAR(irq_count) /* Restore saved previous stack */ - popq%rsi - /* return code expects complete pt_regs - adjust rsp accordingly: */ - leaq-RBP(%rsi), %rsp + popq%rsp testb $3, CS(%rsp) jz retint_kernel @@ -580,7 +570,7 @@ retint_swapgs: /* return to user-space */ TRACE_IRQS_IRETQ SWAPGS - jmp restore_c_regs_and_iret + jmp restore_regs_and_iret /* Returning to kernel space */ retint_kernel: @@ -604,6 +594,8 @@ retint_kernel: * At this label, code paths which return to kernel and to user, * which come from interrupts/exception and from syscalls, merge. */ +restore_regs_and_iret: + RESTORE_EXTRA_REGS restore_c_regs_and_iret: RESTORE_C_REGS REMOVE_PT_GPREGS_FROM_STACK 8 @@ -674,12 +666,10 @@ retint_signal: jz retint_swapgs TRACE_IRQS_ON ENABLE_INTERRUPTS(CLBR_NONE) - SAVE_EXTRA_REGS movq$-1, ORIG_RAX(%rsp) xorl%esi, %esi /* oldset */ movq%rsp, %rdi /* &pt_regs */ calldo_notify_resume - RESTORE_EXTRA_REGS DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_OFF GET_THREAD_INFO(%rcx) @@ -1160,7 +1150,6 @@ END(error_entry) */ ENTRY(error_exit) movl%ebx, %eax - RESTORE_EXTRA_REGS DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_OFF testl %eax, %eax -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/asm] x86/asm/entry/64: Simplify IRQ stack pt_regs handling
Commit-ID: a586f98e9767fb0dfdb989002866b4024f00ce08 Gitweb: http://git.kernel.org/tip/a586f98e9767fb0dfdb989002866b4024f00ce08 Author: Andy Lutomirski AuthorDate: Fri, 3 Jul 2015 12:44:30 -0700 Committer: Ingo Molnar CommitDate: Tue, 7 Jul 2015 10:59:08 +0200 x86/asm/entry/64: Simplify IRQ stack pt_regs handling There's no need for both RSI and RDI to point to the original stack. Signed-off-by: Andy Lutomirski Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: Denys Vlasenko Cc: Frederic Weisbecker Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Oleg Nesterov Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Cc: paul...@linux.vnet.ibm.com Link: http://lkml.kernel.org/r/3a0481f809dd340c7d3f54ce3fd6d66ef2a578cd.1435952415.git.l...@kernel.org Signed-off-by: Ingo Molnar --- arch/x86/entry/entry_64.S | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index 65029f4..83eb63d 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -506,8 +506,6 @@ END(irq_entries_start) SAVE_C_REGS SAVE_EXTRA_REGS - movq%rsp,%rdi /* arg1 for \func (pointer to pt_regs) */ - testb $3, CS(%rsp) jz 1f SWAPGS @@ -519,14 +517,14 @@ END(irq_entries_start) * a little cheaper to use a separate counter in the PDA (short of * moving irq_enter into assembly, which would be too much work) */ - movq%rsp, %rsi + movq%rsp, %rdi inclPER_CPU_VAR(irq_count) cmovzq PER_CPU_VAR(irq_stack_ptr), %rsp - pushq %rsi + pushq %rdi /* We entered an interrupt context - irqs are off: */ TRACE_IRQS_OFF - call\func + call\func /* rdi points to pt_regs */ .endm /* -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/asm] x86/asm/entry/64: Migrate error and IRQ exit work to C and remove old assembly code
Commit-ID: 02bc7768fe447ae305e924b931fa629073a4a1b9 Gitweb: http://git.kernel.org/tip/02bc7768fe447ae305e924b931fa629073a4a1b9 Author: Andy Lutomirski AuthorDate: Fri, 3 Jul 2015 12:44:31 -0700 Committer: Ingo Molnar CommitDate: Tue, 7 Jul 2015 10:59:08 +0200 x86/asm/entry/64: Migrate error and IRQ exit work to C and remove old assembly code Signed-off-by: Andy Lutomirski Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: Denys Vlasenko Cc: Frederic Weisbecker Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Oleg Nesterov Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Cc: paul...@linux.vnet.ibm.com Link: http://lkml.kernel.org/r/60e90901eee611e59e958bfdbbe39969b4f88fe5.1435952415.git.l...@kernel.org Signed-off-by: Ingo Molnar --- arch/x86/entry/entry_64.S| 64 +++- arch/x86/entry/entry_64_compat.S | 5 2 files changed, 23 insertions(+), 46 deletions(-) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index 83eb63d..168ee26 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -508,7 +508,16 @@ END(irq_entries_start) testb $3, CS(%rsp) jz 1f + + /* +* IRQ from user mode. Switch to kernel gsbase and inform context +* tracking that we're in kernel mode. +*/ SWAPGS +#ifdef CONFIG_CONTEXT_TRACKING + call enter_from_user_mode +#endif + 1: /* * Save previous stack pointer, optionally switch to interrupt stack. @@ -547,26 +556,13 @@ ret_from_intr: testb $3, CS(%rsp) jz retint_kernel - /* Interrupt came from user space */ -GLOBAL(retint_user) - GET_THREAD_INFO(%rcx) - /* %rcx: thread info. Interrupts are off. */ -retint_with_reschedule: - movl$_TIF_WORK_MASK, %edi -retint_check: + /* Interrupt came from user space */ LOCKDEP_SYS_EXIT_IRQ - movlTI_flags(%rcx), %edx - andl%edi, %edx - jnz retint_careful - -retint_swapgs: /* return to user-space */ - /* -* The iretq could re-enable interrupts: -*/ - DISABLE_INTERRUPTS(CLBR_ANY) +GLOBAL(retint_user) + mov %rsp,%rdi + callprepare_exit_to_usermode TRACE_IRQS_IRETQ - SWAPGS jmp restore_regs_and_iret @@ -644,35 +640,6 @@ native_irq_return_ldt: popq%rax jmp native_irq_return_iret #endif - - /* edi: workmask, edx: work */ -retint_careful: - bt $TIF_NEED_RESCHED, %edx - jnc retint_signal - TRACE_IRQS_ON - ENABLE_INTERRUPTS(CLBR_NONE) - pushq %rdi - SCHEDULE_USER - popq%rdi - GET_THREAD_INFO(%rcx) - DISABLE_INTERRUPTS(CLBR_NONE) - TRACE_IRQS_OFF - jmp retint_check - -retint_signal: - testl $_TIF_DO_NOTIFY_MASK, %edx - jz retint_swapgs - TRACE_IRQS_ON - ENABLE_INTERRUPTS(CLBR_NONE) - movq$-1, ORIG_RAX(%rsp) - xorl%esi, %esi /* oldset */ - movq%rsp, %rdi /* &pt_regs */ - calldo_notify_resume - DISABLE_INTERRUPTS(CLBR_NONE) - TRACE_IRQS_OFF - GET_THREAD_INFO(%rcx) - jmp retint_with_reschedule - END(common_interrupt) /* @@ -1088,7 +1055,12 @@ ENTRY(error_entry) SWAPGS .Lerror_entry_from_usermode_after_swapgs: +#ifdef CONFIG_CONTEXT_TRACKING + call enter_from_user_mode +#endif + .Lerror_entry_done: + TRACE_IRQS_OFF ret diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S index d9bbd31..25aca51 100644 --- a/arch/x86/entry/entry_64_compat.S +++ b/arch/x86/entry/entry_64_compat.S @@ -458,6 +458,11 @@ ia32_badarg: DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_OFF + /* Now finish entering normal kernel mode. */ +#ifdef CONFIG_CONTEXT_TRACKING + call enter_from_user_mode +#endif + /* And exit again. */ jmp retint_user -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/asm] x86/entry/64: Really create an error-entry-from-usermode code path
Commit-ID: cb6f64ed5a04036eef07e70b57dd5dd78f2fbcef
Gitweb: http://git.kernel.org/tip/cb6f64ed5a04036eef07e70b57dd5dd78f2fbcef
Author: Andy Lutomirski
AuthorDate: Fri, 3 Jul 2015 12:44:27 -0700
Committer: Ingo Molnar
CommitDate: Tue, 7 Jul 2015 10:59:07 +0200
x86/entry/64: Really create an error-entry-from-usermode code path
In 539f51136500 ("x86/asm/entry/64: Disentangle error_entry/exit
gsbase/ebx/usermode code"), I arranged the code slightly wrong
-- IRET faults would skip the code path that was intended to
execute on all error entries from user mode. Fix it up.
While we're at it, make all the labels in error_entry local.
This does not fix a bug, but we'll need it, and it slightly
shrinks the code.
Signed-off-by: Andy Lutomirski
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: Denys Vlasenko
Cc: Frederic Weisbecker
Cc: H. Peter Anvin
Cc: Kees Cook
Cc: Linus Torvalds
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: paul...@linux.vnet.ibm.com
Link:
http://lkml.kernel.org/r/91e17891e49fa3d61357eadc451529ad48143ee1.1435952415.git.l...@kernel.org
Signed-off-by: Ingo Molnar
---
arch/x86/entry/entry_64.S | 28
1 file changed, 16 insertions(+), 12 deletions(-)
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 141a5d4..ccfcba9 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1143,12 +1143,17 @@ ENTRY(error_entry)
SAVE_EXTRA_REGS 8
xorl%ebx, %ebx
testb $3, CS+8(%rsp)
- jz error_kernelspace
+ jz .Lerror_kernelspace
- /* We entered from user mode */
+.Lerror_entry_from_usermode_swapgs:
+ /*
+* We entered from user mode or we're pretending to have entered
+* from user mode due to an IRET fault.
+*/
SWAPGS
-error_entry_done:
+.Lerror_entry_from_usermode_after_swapgs:
+.Lerror_entry_done:
TRACE_IRQS_OFF
ret
@@ -1158,31 +1163,30 @@ error_entry_done:
* truncated RIP for IRET exceptions returning to compat mode. Check
* for these here too.
*/
-error_kernelspace:
+.Lerror_kernelspace:
incl%ebx
leaqnative_irq_return_iret(%rip), %rcx
cmpq%rcx, RIP+8(%rsp)
- je error_bad_iret
+ je .Lerror_bad_iret
movl%ecx, %eax /* zero extend */
cmpq%rax, RIP+8(%rsp)
- je bstep_iret
+ je .Lbstep_iret
cmpq$gs_change, RIP+8(%rsp)
- jne error_entry_done
+ jne .Lerror_entry_done
/*
* hack: gs_change can fail with user gsbase. If this happens, fix up
* gsbase and proceed. We'll fix up the exception and land in
* gs_change's error handler with kernel gsbase.
*/
- SWAPGS
- jmp error_entry_done
+ jmp .Lerror_entry_from_usermode_swapgs
-bstep_iret:
+.Lbstep_iret:
/* Fix truncated RIP */
movq%rcx, RIP+8(%rsp)
/* fall through */
-error_bad_iret:
+.Lerror_bad_iret:
/*
* We came from an IRET to user mode, so we have user gsbase.
* Switch to kernel gsbase:
@@ -1198,7 +1202,7 @@ error_bad_iret:
callfixup_bad_iret
mov %rax, %rsp
decl%ebx
- jmp error_entry_done
+ jmp .Lerror_entry_from_usermode_after_swapgs
END(error_entry)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/asm] x86/entry/64: Migrate 64-bit and compat syscalls to the new exit handlers and remove old assembly code
Commit-ID: 29ea1b258b98a862e59d72556714b75051ae93fb Gitweb: http://git.kernel.org/tip/29ea1b258b98a862e59d72556714b75051ae93fb Author: Andy Lutomirski AuthorDate: Fri, 3 Jul 2015 12:44:28 -0700 Committer: Ingo Molnar CommitDate: Tue, 7 Jul 2015 10:59:07 +0200 x86/entry/64: Migrate 64-bit and compat syscalls to the new exit handlers and remove old assembly code These need to be migrated together, as the compat case used to jump into the middle of the 64-bit exit code. Remove the old assembly code. Signed-off-by: Andy Lutomirski Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: Denys Vlasenko Cc: Frederic Weisbecker Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Oleg Nesterov Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Cc: paul...@linux.vnet.ibm.com Link: http://lkml.kernel.org/r/d4d1d70de08ac3640badf50048a9e8f18fe2497f.1435952415.git.l...@kernel.org Signed-off-by: Ingo Molnar --- arch/x86/entry/entry_64.S| 69 +--- arch/x86/entry/entry_64_compat.S | 6 ++-- 2 files changed, 11 insertions(+), 64 deletions(-) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index ccfcba9..4ca5b78 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -229,6 +229,11 @@ entry_SYSCALL_64_fastpath: */ USERGS_SYSRET64 +GLOBAL(int_ret_from_sys_call_irqs_off) + TRACE_IRQS_ON + ENABLE_INTERRUPTS(CLBR_NONE) + jmp int_ret_from_sys_call + /* Do syscall entry tracing */ tracesys: movq%rsp, %rdi @@ -272,69 +277,11 @@ tracesys_phase2: * Has correct iret frame. */ GLOBAL(int_ret_from_sys_call) - DISABLE_INTERRUPTS(CLBR_NONE) -int_ret_from_sys_call_irqs_off: /* jumps come here from the irqs-off SYSRET path */ - TRACE_IRQS_OFF - movl$_TIF_ALLWORK_MASK, %edi - /* edi: mask to check */ -GLOBAL(int_with_check) - LOCKDEP_SYS_EXIT_IRQ - GET_THREAD_INFO(%rcx) - movlTI_flags(%rcx), %edx - andl%edi, %edx - jnz int_careful - andl$~TS_COMPAT, TI_status(%rcx) - jmp syscall_return - - /* -* Either reschedule or signal or syscall exit tracking needed. -* First do a reschedule test. -* edx: work, edi: workmask -*/ -int_careful: - bt $TIF_NEED_RESCHED, %edx - jnc int_very_careful - TRACE_IRQS_ON - ENABLE_INTERRUPTS(CLBR_NONE) - pushq %rdi - SCHEDULE_USER - popq%rdi - DISABLE_INTERRUPTS(CLBR_NONE) - TRACE_IRQS_OFF - jmp int_with_check - - /* handle signals and tracing -- both require a full pt_regs */ -int_very_careful: - TRACE_IRQS_ON - ENABLE_INTERRUPTS(CLBR_NONE) SAVE_EXTRA_REGS - /* Check for syscall exit trace */ - testl $_TIF_WORK_SYSCALL_EXIT, %edx - jz int_signal - pushq %rdi - leaq8(%rsp), %rdi /* &ptregs -> arg1 */ - callsyscall_trace_leave - popq%rdi - andl$~(_TIF_WORK_SYSCALL_EXIT|_TIF_SYSCALL_EMU), %edi - jmp int_restore_rest - -int_signal: - testl $_TIF_DO_NOTIFY_MASK, %edx - jz 1f - movq%rsp, %rdi /* &ptregs -> arg1 */ - xorl%esi, %esi /* oldset -> arg2 */ - calldo_notify_resume -1: movl$_TIF_WORK_MASK, %edi -int_restore_rest: + movq%rsp, %rdi + callsyscall_return_slowpath /* returns with IRQs disabled */ RESTORE_EXTRA_REGS - DISABLE_INTERRUPTS(CLBR_NONE) - TRACE_IRQS_OFF - jmp int_with_check - -syscall_return: - /* The IRETQ could re-enable interrupts: */ - DISABLE_INTERRUPTS(CLBR_ANY) - TRACE_IRQS_IRETQ + TRACE_IRQS_IRETQ/* we're about to change IF */ /* * Try to use SYSRET instead of IRET if we're returning to diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S index e5ebdd9..d9bbd31 100644 --- a/arch/x86/entry/entry_64_compat.S +++ b/arch/x86/entry/entry_64_compat.S @@ -210,10 +210,10 @@ sysexit_from_sys_call: .endm .macro auditsys_exit exit - testl $(_TIF_ALLWORK_MASK & ~_TIF_SYSCALL_AUDIT), ASM_THREAD_INFO(TI_flags, %rsp, SIZEOF_PTREGS) - jnz ia32_ret_from_sys_call TRACE_IRQS_ON ENABLE_INTERRUPTS(CLBR_NONE) + testl $(_TIF_ALLWORK_MASK & ~_TIF_SYSCALL_AUDIT), ASM_THREAD_INFO(TI_flags, %rsp, SIZEOF_PTREGS) + jnz ia32_ret_from_sys_call movl%eax, %esi /* second arg, syscall return value */ cmpl$-MAX_ERRNO, %eax /* is it an error ? */ jbe 1f @@ -232,7 +232,7 @@ sysexit_from_sys_call: movq%rax, R10(%rsp) movq%rax, R9(%rsp) movq%rax, R8(%rsp) - jmp int_with_check + jmp int_ret_f
[tip:x86/asm] x86/entry: Add enter_from_user_mode() and use it in syscalls
Commit-ID: feed36cde0a10adb957445a37e48f957f30b2273
Gitweb: http://git.kernel.org/tip/feed36cde0a10adb957445a37e48f957f30b2273
Author: Andy Lutomirski
AuthorDate: Fri, 3 Jul 2015 12:44:25 -0700
Committer: Ingo Molnar
CommitDate: Tue, 7 Jul 2015 10:59:06 +0200
x86/entry: Add enter_from_user_mode() and use it in syscalls
Changing the x86 context tracking hooks is dangerous because
there are no good checks that we track our context correctly.
Add a helper to check that we're actually in CONTEXT_USER when
we enter from user mode and wire it up for syscall entries.
Subsequent patches will wire this up for all non-NMI entries as
well. NMIs are their own special beast and cannot currently
switch overall context tracking state. Instead, they have their
own special RCU hooks.
This is a tiny speedup if !CONFIG_CONTEXT_TRACKING (removes a
branch) and a tiny slowdown if CONFIG_CONTEXT_TRACING (adds a
layer of indirection). Eventually, we should fix up the core
context tracking code to supply a function that does what we
want (and can be much simpler than user_exit), which will enable
us to get rid of the extra call.
Signed-off-by: Andy Lutomirski
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: Denys Vlasenko
Cc: Frederic Weisbecker
Cc: H. Peter Anvin
Cc: Kees Cook
Cc: Linus Torvalds
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: paul...@linux.vnet.ibm.com
Link:
http://lkml.kernel.org/r/853b42420066ec3fb856779cdc223a6dcb5d355b.1435952415.git.l...@kernel.org
Signed-off-by: Ingo Molnar
---
arch/x86/entry/common.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
index 917d0c3..9a327ee 100644
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -28,6 +28,15 @@
#define CREATE_TRACE_POINTS
#include
+#ifdef CONFIG_CONTEXT_TRACKING
+/* Called on entry from user mode with IRQs off. */
+__visible void enter_from_user_mode(void)
+{
+ CT_WARN_ON(ct_state() != CONTEXT_USER);
+ user_exit();
+}
+#endif
+
static void do_audit_syscall_entry(struct pt_regs *regs, u32 arch)
{
#ifdef CONFIG_X86_64
@@ -65,14 +74,16 @@ unsigned long syscall_trace_enter_phase1(struct pt_regs
*regs, u32 arch)
work = ACCESS_ONCE(current_thread_info()->flags) &
_TIF_WORK_SYSCALL_ENTRY;
+#ifdef CONFIG_CONTEXT_TRACKING
/*
* If TIF_NOHZ is set, we are required to call user_exit() before
* doing anything that could touch RCU.
*/
if (work & _TIF_NOHZ) {
- user_exit();
+ enter_from_user_mode();
work &= ~_TIF_NOHZ;
}
+#endif
#ifdef CONFIG_SECCOMP
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/asm] x86/traps, context_tracking: Assert that we' re in CONTEXT_KERNEL in exception entries
Commit-ID: 02fdcd5eac9d653d1addbd69b0c58d73650e1c00
Gitweb: http://git.kernel.org/tip/02fdcd5eac9d653d1addbd69b0c58d73650e1c00
Author: Andy Lutomirski
AuthorDate: Fri, 3 Jul 2015 12:44:24 -0700
Committer: Ingo Molnar
CommitDate: Tue, 7 Jul 2015 10:59:05 +0200
x86/traps, context_tracking: Assert that we're in CONTEXT_KERNEL in exception
entries
Other than the super-atomic exception entries, all exception
entries are supposed to switch our context tracking state to
CONTEXT_KERNEL. Assert that they do. These assertions appear
trivial at this point, as exception_enter() is the function
responsible for switching context, but I'm planning on reworking
x86's exception context tracking, and these assertions will help
make sure that all of this code keeps working.
Signed-off-by: Andy Lutomirski
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: Denys Vlasenko
Cc: Frederic Weisbecker
Cc: H. Peter Anvin
Cc: Kees Cook
Cc: Linus Torvalds
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: paul...@linux.vnet.ibm.com
Link:
http://lkml.kernel.org/r/20fa1ee2d943233a184aaf96ff75394d3b34dfba.1435952415.git.l...@kernel.org
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/traps.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index f579192..2a783c4 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -292,6 +292,8 @@ static void do_error_trap(struct pt_regs *regs, long
error_code, char *str,
enum ctx_state prev_state = exception_enter();
siginfo_t info;
+ CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
+
if (notify_die(DIE_TRAP, str, regs, error_code, trapnr, signr) !=
NOTIFY_STOP) {
conditional_sti(regs);
@@ -376,6 +378,7 @@ dotraplinkage void do_bounds(struct pt_regs *regs, long
error_code)
siginfo_t *info;
prev_state = exception_enter();
+ CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
if (notify_die(DIE_TRAP, "bounds", regs, error_code,
X86_TRAP_BR, SIGSEGV) == NOTIFY_STOP)
goto exit;
@@ -457,6 +460,7 @@ do_general_protection(struct pt_regs *regs, long error_code)
enum ctx_state prev_state;
prev_state = exception_enter();
+ CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
conditional_sti(regs);
if (v8086_mode(regs)) {
@@ -514,6 +518,7 @@ dotraplinkage void notrace do_int3(struct pt_regs *regs,
long error_code)
return;
prev_state = ist_enter(regs);
+ CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
#ifdef CONFIG_KGDB_LOW_LEVEL_TRAP
if (kgdb_ll_trap(DIE_INT3, "int3", regs, error_code, X86_TRAP_BP,
SIGTRAP) == NOTIFY_STOP)
@@ -750,6 +755,7 @@ dotraplinkage void do_coprocessor_error(struct pt_regs
*regs, long error_code)
enum ctx_state prev_state;
prev_state = exception_enter();
+ CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
math_error(regs, error_code, X86_TRAP_MF);
exception_exit(prev_state);
}
@@ -760,6 +766,7 @@ do_simd_coprocessor_error(struct pt_regs *regs, long
error_code)
enum ctx_state prev_state;
prev_state = exception_enter();
+ CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
math_error(regs, error_code, X86_TRAP_XF);
exception_exit(prev_state);
}
@@ -776,6 +783,7 @@ do_device_not_available(struct pt_regs *regs, long
error_code)
enum ctx_state prev_state;
prev_state = exception_enter();
+ CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
BUG_ON(use_eager_fpu());
#ifdef CONFIG_MATH_EMULATION
@@ -805,6 +813,7 @@ dotraplinkage void do_iret_error(struct pt_regs *regs, long
error_code)
enum ctx_state prev_state;
prev_state = exception_enter();
+ CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
local_irq_enable();
info.si_signo = SIGILL;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/asm] x86/entry: Add new, comprehensible entry and exit handlers written in C
Commit-ID: c5c46f59e4e7c1ab244b8d38f2b61d317df90bba
Gitweb: http://git.kernel.org/tip/c5c46f59e4e7c1ab244b8d38f2b61d317df90bba
Author: Andy Lutomirski
AuthorDate: Fri, 3 Jul 2015 12:44:26 -0700
Committer: Ingo Molnar
CommitDate: Tue, 7 Jul 2015 10:59:06 +0200
x86/entry: Add new, comprehensible entry and exit handlers written in C
The current x86 entry and exit code, written in a mixture of assembly and
C code, is incomprehensible due to being open-coded in a lot of places
without coherent documentation.
It appears to work primary by luck and duct tape: i.e. obvious runtime
failures were fixed on-demand, without re-thinking the design.
Due to those reasons our confidence level in that code is low, and it is
very difficult to incrementally improve.
Add new code written in C, in preparation for simply deleting the old
entry code.
prepare_exit_to_usermode() is a new function that will handle all
slow path exits to user mode. It is called with IRQs disabled
and it leaves us in a state in which it is safe to immediately
return to user mode. IRQs must not be re-enabled at any point
after prepare_exit_to_usermode() returns and user mode is actually
entered. (We can, of course, fail to enter user mode and treat
that failure as a fresh entry to kernel mode.)
All callers of do_notify_resume() will be migrated to call
prepare_exit_to_usermode() instead; prepare_exit_to_usermode() needs
to do everything that do_notify_resume() does today, but it also
takes care of scheduling and context tracking. Unlike
do_notify_resume(), it does not need to be called in a loop.
syscall_return_slowpath() is exactly what it sounds like: it will
be called on any syscall exit slow path. It will replace
syscall_trace_leave() and it calls prepare_exit_to_usermode() on the
way out.
Signed-off-by: Andy Lutomirski
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: Denys Vlasenko
Cc: Frederic Weisbecker
Cc: H. Peter Anvin
Cc: Kees Cook
Cc: Linus Torvalds
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: paul...@linux.vnet.ibm.com
Link:
http://lkml.kernel.org/r/c57c8b87661a4152801d7d3786eac2d1a2f209dd.1435952415.git.l...@kernel.org
[ Improved the changelog a bit. ]
Signed-off-by: Ingo Molnar
---
arch/x86/entry/common.c | 112 +++-
1 file changed, 111 insertions(+), 1 deletion(-)
diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
index 9a327ee..febc530 100644
--- a/arch/x86/entry/common.c
+++ b/arch/x86/entry/common.c
@@ -207,6 +207,7 @@ long syscall_trace_enter(struct pt_regs *regs)
return syscall_trace_enter_phase2(regs, arch, phase1_result);
}
+/* Deprecated. */
void syscall_trace_leave(struct pt_regs *regs)
{
bool step;
@@ -237,8 +238,117 @@ void syscall_trace_leave(struct pt_regs *regs)
user_enter();
}
+static struct thread_info *pt_regs_to_thread_info(struct pt_regs *regs)
+{
+ unsigned long top_of_stack =
+ (unsigned long)(regs + 1) + TOP_OF_KERNEL_STACK_PADDING;
+ return (struct thread_info *)(top_of_stack - THREAD_SIZE);
+}
+
+/* Called with IRQs disabled. */
+__visible void prepare_exit_to_usermode(struct pt_regs *regs)
+{
+ if (WARN_ON(!irqs_disabled()))
+ local_irq_disable();
+
+ /*
+* In order to return to user mode, we need to have IRQs off with
+* none of _TIF_SIGPENDING, _TIF_NOTIFY_RESUME, _TIF_USER_RETURN_NOTIFY,
+* _TIF_UPROBE, or _TIF_NEED_RESCHED set. Several of these flags
+* can be set at any time on preemptable kernels if we have IRQs on,
+* so we need to loop. Disabling preemption wouldn't help: doing the
+* work to clear some of the flags can sleep.
+*/
+ while (true) {
+ u32 cached_flags =
+ READ_ONCE(pt_regs_to_thread_info(regs)->flags);
+
+ if (!(cached_flags & (_TIF_SIGPENDING | _TIF_NOTIFY_RESUME |
+ _TIF_UPROBE | _TIF_NEED_RESCHED)))
+ break;
+
+ /* We have work to do. */
+ local_irq_enable();
+
+ if (cached_flags & _TIF_NEED_RESCHED)
+ schedule();
+
+ if (cached_flags & _TIF_UPROBE)
+ uprobe_notify_resume(regs);
+
+ /* deal with pending signal delivery */
+ if (cached_flags & _TIF_SIGPENDING)
+ do_signal(regs);
+
+ if (cached_flags & _TIF_NOTIFY_RESUME) {
+ clear_thread_flag(TIF_NOTIFY_RESUME);
+ tracehook_notify_resume(regs);
+ }
+
+ if (cached_flags & _TIF_USER_RETURN_NOTIFY)
+ fire_user_return_notifiers();
+
+ /* Disable IRQs and retry */
+ local_irq_disable();
+ }
+
+ user_enter();
+}
+
+/*
+ * Called with
Re: [PATCHv3 08/16] staging: vme_user: provide DMA functionality
Hi Alessio, [Sorry for double post] > On 07 Jul 2015, at 10:08, Alessio Igor Bogani > wrote: > > Hi Dmitry, > > On 6 July 2015 at 19:24, Dmitry Kalinkin wrote: > [...] > I'm not a VME expert, but it seems that VME windows are a quiet limited > resource > no matter how you allocate your resources. Theoretically we could put up to 32 > different boards in a single crate, so there won't be enough windows for each > driver to allocate. That said, there is no way around this when putting > together > a really heterogeneous VME system. To overcome such problem, one could > develop a different kernel API that would not provide windows to the > drivers, but > handle reads and writes by reconfiguring windows on the fly, which in turn > would > introduce more latency. > > In my humble opinion using user-space drivers (as workaround for limited > windows/images) introduce more latency than let VME driver dynamically > configure windows/images. After all VME systems usually aren't so much > dynamic by its nature (Who likes continuously put in and out a board which > requires an insertion force between 20 and 50 kg?) and are instead heavily > used in critical contexts often in non-stop way. Userspace drivers are not exactly doing this differently. It’s just that you can use that interface to quickly build more flexible site-specific software that knows about whole VME system. So there, having a low level access to windows works well (there is a 20+ year history of such drivers). But if we want reusable drivers, especially in the kernel, that will require some more effort in making a driver stack. The API I had in mind would have only vme_master_read and vme_master_write that would take absolute addresses (not relative to any window). These variants of access functions would then try to reuse any window that is already able to serve the request or wait for a free window and reconfigure it for the need of the request. After usage the window is to be returned back to the window pool. Other way to implement these would be to use DMA for everything, since it doesn’t have the limitations that the windows have. > > In fact this is a big obstacle for adoption of this VME stack (at least for > us). We use VME a lot and we care about latency as well so we use only > kernel-space drivers for ours VME boards but unfortunately the VME stack let > us to link a single board with a single window/image (so max 8 boards on > tsi148) only. That said that stack has proven to be very rock solid. Current VME stack links windows not to the boards, but to device drivers. Driver could potentially minimise window usage within it’s scope (any sort of window reusing, like mapping whole A16 once to be used with all boards), but this won’t work across multiple drivers. Even if all of your drivers are window-wise economic, they will still need some amount of windows per each driver. Not that we have that many kernel drivers... > > Until now we have used a modified version of the old vmelinux.org stack for > sharing windows/images between all (ours) VME kernel drivers and we would be > very happy to see something similar in vanilla (at least coalescence two > adjacent addresses with same modifiers). > > Those who need such API are welcome to develop it :) > > I would be glad to try it if the maintainer is willing to receive this type > of changes. > > Ciao, > Alessio > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/asm] x86/entry: Move C entry and exit code to arch/x86/ entry/common.c
Commit-ID: 1f484aa6904697f390027c12fba130fa94b20831
Gitweb: http://git.kernel.org/tip/1f484aa6904697f390027c12fba130fa94b20831
Author: Andy Lutomirski
AuthorDate: Fri, 3 Jul 2015 12:44:23 -0700
Committer: Ingo Molnar
CommitDate: Tue, 7 Jul 2015 10:59:05 +0200
x86/entry: Move C entry and exit code to arch/x86/entry/common.c
The entry and exit C helpers were confusingly scattered between
ptrace.c and signal.c, even though they aren't specific to
ptrace or signal handling. Move them together in a new file.
This change just moves code around. It doesn't change anything.
Signed-off-by: Andy Lutomirski
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: Denys Vlasenko
Cc: Frederic Weisbecker
Cc: H. Peter Anvin
Cc: Kees Cook
Cc: Linus Torvalds
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: paul...@linux.vnet.ibm.com
Link:
http://lkml.kernel.org/r/324d686821266544d8572423cc281f961da445f4.1435952415.git.l...@kernel.org
Signed-off-by: Ingo Molnar
---
arch/x86/entry/Makefile | 1 +
arch/x86/entry/common.c | 253 ++
arch/x86/include/asm/signal.h | 1 +
arch/x86/kernel/ptrace.c | 202 +
arch/x86/kernel/signal.c | 28 +
5 files changed, 257 insertions(+), 228 deletions(-)
diff --git a/arch/x86/entry/Makefile b/arch/x86/entry/Makefile
index 7a14497..bd55ded 100644
--- a/arch/x86/entry/Makefile
+++ b/arch/x86/entry/Makefile
@@ -2,6 +2,7 @@
# Makefile for the x86 low level entry code
#
obj-y := entry_$(BITS).o thunk_$(BITS).o
syscall_$(BITS).o
+obj-y += common.o
obj-y += vdso/
obj-y += vsyscall/
diff --git a/arch/x86/entry/common.c b/arch/x86/entry/common.c
new file mode 100644
index 000..917d0c3
--- /dev/null
+++ b/arch/x86/entry/common.c
@@ -0,0 +1,253 @@
+/*
+ * common.c - C code for kernel entry and exit
+ * Copyright (c) 2015 Andrew Lutomirski
+ * GPL v2
+ *
+ * Based on asm and ptrace code by many authors. The code here originated
+ * in ptrace.c and signal.c.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define CREATE_TRACE_POINTS
+#include
+
+static void do_audit_syscall_entry(struct pt_regs *regs, u32 arch)
+{
+#ifdef CONFIG_X86_64
+ if (arch == AUDIT_ARCH_X86_64) {
+ audit_syscall_entry(regs->orig_ax, regs->di,
+ regs->si, regs->dx, regs->r10);
+ } else
+#endif
+ {
+ audit_syscall_entry(regs->orig_ax, regs->bx,
+ regs->cx, regs->dx, regs->si);
+ }
+}
+
+/*
+ * We can return 0 to resume the syscall or anything else to go to phase
+ * 2. If we resume the syscall, we need to put something appropriate in
+ * regs->orig_ax.
+ *
+ * NB: We don't have full pt_regs here, but regs->orig_ax and regs->ax
+ * are fully functional.
+ *
+ * For phase 2's benefit, our return value is:
+ * 0: resume the syscall
+ * 1: go to phase 2; no seccomp phase 2 needed
+ * anything else: go to phase 2; pass return value to seccomp
+ */
+unsigned long syscall_trace_enter_phase1(struct pt_regs *regs, u32 arch)
+{
+ unsigned long ret = 0;
+ u32 work;
+
+ BUG_ON(regs != task_pt_regs(current));
+
+ work = ACCESS_ONCE(current_thread_info()->flags) &
+ _TIF_WORK_SYSCALL_ENTRY;
+
+ /*
+* If TIF_NOHZ is set, we are required to call user_exit() before
+* doing anything that could touch RCU.
+*/
+ if (work & _TIF_NOHZ) {
+ user_exit();
+ work &= ~_TIF_NOHZ;
+ }
+
+#ifdef CONFIG_SECCOMP
+ /*
+* Do seccomp first -- it should minimize exposure of other
+* code, and keeping seccomp fast is probably more valuable
+* than the rest of this.
+*/
+ if (work & _TIF_SECCOMP) {
+ struct seccomp_data sd;
+
+ sd.arch = arch;
+ sd.nr = regs->orig_ax;
+ sd.instruction_pointer = regs->ip;
+#ifdef CONFIG_X86_64
+ if (arch == AUDIT_ARCH_X86_64) {
+ sd.args[0] = regs->di;
+ sd.args[1] = regs->si;
+ sd.args[2] = regs->dx;
+ sd.args[3] = regs->r10;
+ sd.args[4] = regs->r8;
+ sd.args[5] = regs->r9;
+ } else
+#endif
+ {
+ sd.args[0] = regs->bx;
+ sd.args[1] = regs->cx;
+ sd.args[2] = regs->dx;
+ sd.args[3] = regs->si;
+ sd.args[4] = regs->di;
+ sd.args[5] = regs->bp;
[tip:x86/asm] notifiers, RCU: Assert that RCU is watching in notify_die()
Commit-ID: e727c7d7a11e109849582e9165d54b254eb181d7 Gitweb: http://git.kernel.org/tip/e727c7d7a11e109849582e9165d54b254eb181d7 Author: Andy Lutomirski AuthorDate: Fri, 3 Jul 2015 12:44:22 -0700 Committer: Ingo Molnar CommitDate: Tue, 7 Jul 2015 10:59:04 +0200 notifiers, RCU: Assert that RCU is watching in notify_die() Low-level arch entries often call notify_die(), and it's easy for arch code to fail to exit an RCU quiescent state first. Assert that we're not quiescent in notify_die(). Signed-off-by: Andy Lutomirski Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: Denys Vlasenko Cc: Frederic Weisbecker Cc: H. Peter Anvin Cc: Paul E. McKenney Cc: Kees Cook Cc: Linus Torvalds Cc: Oleg Nesterov Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Cc: paul...@linux.vnet.ibm.com Link: http://lkml.kernel.org/r/1f5fe6c23d5b432a23267102f2d72b787d80fdd8.1435952415.git.l...@kernel.org Signed-off-by: Ingo Molnar --- kernel/notifier.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/notifier.c b/kernel/notifier.c index ae9fc7c..980e433 100644 --- a/kernel/notifier.c +++ b/kernel/notifier.c @@ -544,6 +544,8 @@ int notrace notify_die(enum die_val val, const char *str, .signr = sig, }; + rcu_lockdep_assert(rcu_is_watching(), + "notify_die called but RCU thinks we're quiescent"); return atomic_notifier_call_chain(&die_chain, val, &args); } NOKPROBE_SYMBOL(notify_die); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-V5 3/4] mfd: 88pm800: Set default interrupt clear method
On Tuesday 07 July 2015 04:10 PM, Lee Jones wrote:
On Tue, 07 Jul 2015, Vaibhav Hiremath wrote:
On Tuesday 07 July 2015 12:59 PM, Lee Jones wrote:
On Mon, 29 Jun 2015, Vaibhav Hiremath wrote:
As per the spec, bit 1 (INT_CLEAR_MODE) of reg addr 0xe
(page 0) controls the method of clearing interrupt
status of 88pm800 family of devices;
0: clear on read
1: clear on write
If pdata is not coming from board file, then set the
default irq clear method to "irq clear on write"
Also, as suggested by "Lee Jones" renaming variable field
to appropriate name.
Signed-off-by: Zhao Ye
Signed-off-by: Vaibhav Hiremath
---
drivers/mfd/88pm800.c | 15 ++-
include/linux/mfd/88pm80x.h | 10 --
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index d495737..66347be 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -374,7 +374,7 @@ static int device_irq_init_800(struct pm80x_chip *chip)
{
struct regmap *map = chip->regmap;
unsigned long flags = IRQF_ONESHOT;
- int data, mask, ret = -EINVAL;
+ int irq_clr_mode, mask, ret = -EINVAL;
if (!map || !chip->irq) {
dev_err(chip->dev, "incorrect parameters\n");
@@ -382,15 +382,16 @@ static int device_irq_init_800(struct pm80x_chip *chip)
}
/*
-* irq_mode defines the way of clearing interrupt. it's read-clear by
-* default.
+* irq_clr_on_wr defines the way of clearing interrupt by
+* read/write(0/1). It's read-clear by default.
*/
mask =
PM800_WAKEUP2_INV_INT | PM800_WAKEUP2_INT_CLEAR |
PM800_WAKEUP2_INT_MASK;
- data = PM800_WAKEUP2_INT_CLEAR;
- ret = regmap_update_bits(map, PM800_WAKEUP2, mask, data);
+ irq_clr_mode = chip->irq_clr_method == PM800_IRQ_CLR_ON_WRITE ?
+ PM800_WAKEUP2_INT_WRITE_CLEAR : PM800_WAKEUP2_INT_READ_CLEAR;
+ ret = regmap_update_bits(map, PM800_WAKEUP2, mask, irq_clr_mode);
What's stopping you just passing PM800_WAKEUP2_INT_WRITE_CLEAR or
PM800_WAKEUP2_INT_READ_CLEAR from pdata? Then you can use the value
directly without all of this faffing about.
regmap_update_bits(map, PM800_WAKEUP2, mask, pdata->irq_clr_mode);
Because "irq_clr_method" is of boolean type.
And macros which you are referring to is,
#define PM800_WAKEUP2_INT_READ_CLEAR(0 << 1)
#define PM800_WAKEUP2_INT_WRITE_CLEAR (1 << 1)
And also, I feel it is more cleaner approach with the current code as
register definition and userflag are maintained separately.
I see your point, although it's a shame we have to have this code in
its place.
One thing I think you can do though is rid chip->irq_clr_method, just
use the one you already have in pdata.
Looking at the current code,
Yes, this can be done, but I have to do some more changes around it,
to make code cleaner,
change the signature of
static int device_irq_init_800(struct pm80x_chip *chip)
TO
static int device_irq_init_800(struct pm80x_chip *chip, struct
pm80x_platform_data *pdata)
and then only use pdata->irq_clr_method.
How do you want to get this inside? V6 version? or separate patch?
I have one more cleanup patch in the queue, which I am planning to
submit today, if you are ok then I can submit along with that.
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/asm] context_tracking: Add ct_state() and CT_WARN_ON()
Commit-ID: f9281648ecd5081803bb2da84b9ccb0cf48436cd
Gitweb: http://git.kernel.org/tip/f9281648ecd5081803bb2da84b9ccb0cf48436cd
Author: Andy Lutomirski
AuthorDate: Fri, 3 Jul 2015 12:44:21 -0700
Committer: Ingo Molnar
CommitDate: Tue, 7 Jul 2015 10:59:04 +0200
context_tracking: Add ct_state() and CT_WARN_ON()
This will let us sprinkle sanity checks around the kernel
without making too much of a mess.
Signed-off-by: Andy Lutomirski
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: Denys Vlasenko
Cc: Frederic Weisbecker
Cc: H. Peter Anvin
Cc: Kees Cook
Cc: Linus Torvalds
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: paul...@linux.vnet.ibm.com
Link:
http://lkml.kernel.org/r/5da41fb2ceb29eac671f427c67040401ba2a1fa0.1435952415.git.l...@kernel.org
Signed-off-by: Ingo Molnar
---
include/linux/context_tracking.h | 15 +++
include/linux/context_tracking_state.h | 1 +
2 files changed, 16 insertions(+)
diff --git a/include/linux/context_tracking.h b/include/linux/context_tracking.h
index b96bd29..008fc67 100644
--- a/include/linux/context_tracking.h
+++ b/include/linux/context_tracking.h
@@ -49,13 +49,28 @@ static inline void exception_exit(enum ctx_state prev_ctx)
}
}
+
+/**
+ * ct_state() - return the current context tracking state if known
+ *
+ * Returns the current cpu's context tracking state if context tracking
+ * is enabled. If context tracking is disabled, returns
+ * CONTEXT_DISABLED. This should be used primarily for debugging.
+ */
+static inline enum ctx_state ct_state(void)
+{
+ return context_tracking_is_enabled() ?
+ this_cpu_read(context_tracking.state) : CONTEXT_DISABLED;
+}
#else
static inline void user_enter(void) { }
static inline void user_exit(void) { }
static inline enum ctx_state exception_enter(void) { return 0; }
static inline void exception_exit(enum ctx_state prev_ctx) { }
+static inline enum ctx_state ct_state(void) { return CONTEXT_DISABLED; }
#endif /* !CONFIG_CONTEXT_TRACKING */
+#define CT_WARN_ON(cond) WARN_ON(context_tracking_is_enabled() && (cond))
#ifdef CONFIG_CONTEXT_TRACKING_FORCE
extern void context_tracking_init(void);
diff --git a/include/linux/context_tracking_state.h
b/include/linux/context_tracking_state.h
index 678ecdf..ee956c5 100644
--- a/include/linux/context_tracking_state.h
+++ b/include/linux/context_tracking_state.h
@@ -14,6 +14,7 @@ struct context_tracking {
bool active;
int recursion;
enum ctx_state {
+ CONTEXT_DISABLED = -1, /* returned by ct_state() if unknown */
CONTEXT_KERNEL = 0,
CONTEXT_USER,
CONTEXT_GUEST,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/asm] um: Fix do_signal() prototype
Commit-ID: ccaee5f851470dec6894a6835b6fadffc2bb7514
Gitweb: http://git.kernel.org/tip/ccaee5f851470dec6894a6835b6fadffc2bb7514
Author: Ingo Molnar
AuthorDate: Fri, 3 Jul 2015 12:44:20 -0700
Committer: Ingo Molnar
CommitDate: Tue, 7 Jul 2015 10:58:54 +0200
um: Fix do_signal() prototype
Once x86 exports its do_signal(), the prototypes will clash.
Fix the clash and also improve the code a bit: remove the
unnecessary kern_do_signal() indirection. This allows
interrupt_end() to share the 'regs' parameter calculation.
Also remove the unused return code to match x86.
Minimally build and boot tested.
Signed-off-by: Ingo Molnar
Signed-off-by: Andy Lutomirski
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: Denys Vlasenko
Cc: Frederic Weisbecker
Cc: H. Peter Anvin
Cc: Kees Cook
Cc: Linus Torvalds
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Richard Weinberger
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: paul...@linux.vnet.ibm.com
Link:
http://lkml.kernel.org/r/67c57eac09a589bac3c6c5ff22f9623ec55a184a.1435952415.git.l...@kernel.org
Signed-off-by: Ingo Molnar
---
arch/um/include/shared/kern_util.h | 3 ++-
arch/um/kernel/process.c | 6 --
arch/um/kernel/signal.c| 8 +---
arch/um/kernel/tlb.c | 2 +-
arch/um/kernel/trap.c | 2 +-
5 files changed, 9 insertions(+), 12 deletions(-)
diff --git a/arch/um/include/shared/kern_util.h
b/arch/um/include/shared/kern_util.h
index 83a91f9..35ab97e 100644
--- a/arch/um/include/shared/kern_util.h
+++ b/arch/um/include/shared/kern_util.h
@@ -22,7 +22,8 @@ extern int kmalloc_ok;
extern unsigned long alloc_stack(int order, int atomic);
extern void free_stack(unsigned long stack, int order);
-extern int do_signal(void);
+struct pt_regs;
+extern void do_signal(struct pt_regs *regs);
extern void interrupt_end(void);
extern void relay_signal(int sig, struct siginfo *si, struct uml_pt_regs
*regs);
diff --git a/arch/um/kernel/process.c b/arch/um/kernel/process.c
index 68b9119..a6d9226 100644
--- a/arch/um/kernel/process.c
+++ b/arch/um/kernel/process.c
@@ -90,12 +90,14 @@ void *__switch_to(struct task_struct *from, struct
task_struct *to)
void interrupt_end(void)
{
+ struct pt_regs *regs = ¤t->thread.regs;
+
if (need_resched())
schedule();
if (test_thread_flag(TIF_SIGPENDING))
- do_signal();
+ do_signal(regs);
if (test_and_clear_thread_flag(TIF_NOTIFY_RESUME))
- tracehook_notify_resume(¤t->thread.regs);
+ tracehook_notify_resume(regs);
}
void exit_thread(void)
diff --git a/arch/um/kernel/signal.c b/arch/um/kernel/signal.c
index 4f60e4a..57acbd6 100644
--- a/arch/um/kernel/signal.c
+++ b/arch/um/kernel/signal.c
@@ -64,7 +64,7 @@ static void handle_signal(struct ksignal *ksig, struct
pt_regs *regs)
signal_setup_done(err, ksig, singlestep);
}
-static int kern_do_signal(struct pt_regs *regs)
+void do_signal(struct pt_regs *regs)
{
struct ksignal ksig;
int handled_sig = 0;
@@ -110,10 +110,4 @@ static int kern_do_signal(struct pt_regs *regs)
*/
if (!handled_sig)
restore_saved_sigmask();
- return handled_sig;
-}
-
-int do_signal(void)
-{
- return kern_do_signal(¤t->thread.regs);
}
diff --git a/arch/um/kernel/tlb.c b/arch/um/kernel/tlb.c
index f1b3eb1..2077248 100644
--- a/arch/um/kernel/tlb.c
+++ b/arch/um/kernel/tlb.c
@@ -291,7 +291,7 @@ void fix_range_common(struct mm_struct *mm, unsigned long
start_addr,
/* We are under mmap_sem, release it such that current can
terminate */
up_write(¤t->mm->mmap_sem);
force_sig(SIGKILL, current);
- do_signal();
+ do_signal(¤t->thread.regs);
}
}
diff --git a/arch/um/kernel/trap.c b/arch/um/kernel/trap.c
index 557232f..d8a9fce 100644
--- a/arch/um/kernel/trap.c
+++ b/arch/um/kernel/trap.c
@@ -173,7 +173,7 @@ static void bad_segv(struct faultinfo fi, unsigned long ip)
void fatal_sigsegv(void)
{
force_sigsegv(SIGSEGV, current);
- do_signal();
+ do_signal(¤t->thread.regs);
/*
* This is to tell gcc that we're not returning - do_signal
* can, in general, return, but in this case, it's not, since
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/asm] x86/entry/64/compat: Fix bad fast syscall arg failure path
Commit-ID: 5e99cb7c35ca0580da8e892f91c655d35ecf8798 Gitweb: http://git.kernel.org/tip/5e99cb7c35ca0580da8e892f91c655d35ecf8798 Author: Andy Lutomirski AuthorDate: Fri, 3 Jul 2015 12:44:19 -0700 Committer: Ingo Molnar CommitDate: Tue, 7 Jul 2015 10:58:30 +0200 x86/entry/64/compat: Fix bad fast syscall arg failure path If user code does SYSCALL32 or SYSENTER without a valid stack, then our attempt to determine the syscall args will result in a failed uaccess fault. Previously, we would try to recover by jumping to the syscall exit code, but we'd run the syscall exit work even though we never made it to the syscall entry work. Clean it up by treating the failure path as a non-syscall entry and exit pair. This fixes strace's output when running the syscall_arg_fault test. Without this fix, strace would get out of sync and would fail to associate syscall entries with syscall exits. Signed-off-by: Andy Lutomirski Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: Denys Vlasenko Cc: Frederic Weisbecker Cc: H. Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Oleg Nesterov Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Cc: paul...@linux.vnet.ibm.com Link: http://lkml.kernel.org/r/903010762c07a3d67df914fea2da84b52b0f8f1d.1435952415.git.l...@kernel.org Signed-off-by: Ingo Molnar --- arch/x86/entry/entry_64.S| 2 +- arch/x86/entry/entry_64_compat.S | 35 +-- 2 files changed, 34 insertions(+), 3 deletions(-) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index 3bb2c43..141a5d4 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -613,7 +613,7 @@ ret_from_intr: testb $3, CS(%rsp) jz retint_kernel /* Interrupt came from user space */ -retint_user: +GLOBAL(retint_user) GET_THREAD_INFO(%rcx) /* %rcx: thread info. Interrupts are off. */ diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S index b868cfc..e5ebdd9 100644 --- a/arch/x86/entry/entry_64_compat.S +++ b/arch/x86/entry/entry_64_compat.S @@ -428,8 +428,39 @@ cstar_tracesys: END(entry_SYSCALL_compat) ia32_badarg: - ASM_CLAC - movq$-EFAULT, RAX(%rsp) + /* +* So far, we've entered kernel mode, set AC, turned on IRQs, and +* saved C regs except r8-r11. We haven't done any of the other +* standard entry work, though. We want to bail, but we shouldn't +* treat this as a syscall entry since we don't even know what the +* args are. Instead, treat this as a non-syscall entry, finish +* the entry work, and immediately exit after setting AX = -EFAULT. +* +* We're really just being polite here. Killing the task outright +* would be a reasonable action, too. Given that the only valid +* way to have gotten here is through the vDSO, and we already know +* that the stack pointer is bad, the task isn't going to survive +* for long no matter what we do. +*/ + + ASM_CLAC/* undo STAC */ + movq$-EFAULT, RAX(%rsp) /* return -EFAULT if possible */ + + /* Fill in the rest of pt_regs */ + xorl%eax, %eax + movq%rax, R11(%rsp) + movq%rax, R10(%rsp) + movq%rax, R9(%rsp) + movq%rax, R8(%rsp) + SAVE_EXTRA_REGS + + /* Turn IRQs back off. */ + DISABLE_INTERRUPTS(CLBR_NONE) + TRACE_IRQS_OFF + + /* And exit again. */ + jmp retint_user + ia32_ret_from_sys_call: xorl%eax, %eax /* Do not leak kernel information */ movq%rax, R11(%rsp) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/asm] x86/entry, selftests/x86: Add a test for 32-bit fast syscall arg faults
Commit-ID: 5e5c684a2c78b98dcba3d6fce56773a375f63980
Gitweb: http://git.kernel.org/tip/5e5c684a2c78b98dcba3d6fce56773a375f63980
Author: Andy Lutomirski
AuthorDate: Fri, 3 Jul 2015 12:44:18 -0700
Committer: Ingo Molnar
CommitDate: Tue, 7 Jul 2015 10:58:30 +0200
x86/entry, selftests/x86: Add a test for 32-bit fast syscall arg faults
This test passes on 4.0 and fails on some newer kernels.
Fortunately, the failure is likely not a big deal.
This test will make sure that we don't break it further (e.g. OOPSing)
as we clean up the entry code and that we eventually fix the
regression.
There's arguably no need to preserve the old ABI here --
anything that makes it into a fast (vDSO) syscall with a bad
stack is about to crash no matter what we do.
Signed-off-by: Andy Lutomirski
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: Denys Vlasenko
Cc: Frederic Weisbecker
Cc: H. Peter Anvin
Cc: Kees Cook
Cc: Linus Torvalds
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: paul...@linux.vnet.ibm.com
Link:
http://lkml.kernel.org/r/9cfcc51005168cb1b06b31991931214d770fc59a.1435952415.git.l...@kernel.org
Signed-off-by: Ingo Molnar
---
tools/testing/selftests/x86/Makefile| 2 +-
tools/testing/selftests/x86/syscall_arg_fault.c | 130
2 files changed, 131 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/x86/Makefile
b/tools/testing/selftests/x86/Makefile
index caa60d5..e8df47e 100644
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@ -5,7 +5,7 @@ include ../lib.mk
.PHONY: all all_32 all_64 warn_32bit_failure clean
TARGETS_C_BOTHBITS := sigreturn single_step_syscall sysret_ss_attrs
-TARGETS_C_32BIT_ONLY := entry_from_vm86
+TARGETS_C_32BIT_ONLY := entry_from_vm86 syscall_arg_fault
TARGETS_C_32BIT_ALL := $(TARGETS_C_BOTHBITS) $(TARGETS_C_32BIT_ONLY)
BINARIES_32 := $(TARGETS_C_32BIT_ALL:%=%_32)
diff --git a/tools/testing/selftests/x86/syscall_arg_fault.c
b/tools/testing/selftests/x86/syscall_arg_fault.c
new file mode 100644
index 000..7db4fc9
--- /dev/null
+++ b/tools/testing/selftests/x86/syscall_arg_fault.c
@@ -0,0 +1,130 @@
+/*
+ * syscall_arg_fault.c - tests faults 32-bit fast syscall stack args
+ * Copyright (c) 2015 Andrew Lutomirski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#define _GNU_SOURCE
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Our sigaltstack scratch space. */
+static unsigned char altstack_data[SIGSTKSZ];
+
+static void sethandler(int sig, void (*handler)(int, siginfo_t *, void *),
+ int flags)
+{
+ struct sigaction sa;
+ memset(&sa, 0, sizeof(sa));
+ sa.sa_sigaction = handler;
+ sa.sa_flags = SA_SIGINFO | flags;
+ sigemptyset(&sa.sa_mask);
+ if (sigaction(sig, &sa, 0))
+ err(1, "sigaction");
+}
+
+static volatile sig_atomic_t sig_traps;
+static sigjmp_buf jmpbuf;
+
+static volatile sig_atomic_t n_errs;
+
+static void sigsegv(int sig, siginfo_t *info, void *ctx_void)
+{
+ ucontext_t *ctx = (ucontext_t*)ctx_void;
+
+ if (ctx->uc_mcontext.gregs[REG_EAX] != -EFAULT) {
+ printf("[FAIL]\tAX had the wrong value: 0x%x\n",
+ ctx->uc_mcontext.gregs[REG_EAX]);
+ n_errs++;
+ } else {
+ printf("[OK]\tSeems okay\n");
+ }
+
+ siglongjmp(jmpbuf, 1);
+}
+
+static void sigill(int sig, siginfo_t *info, void *ctx_void)
+{
+ printf("[SKIP]\tIllegal instruction\n");
+ siglongjmp(jmpbuf, 1);
+}
+
+int main()
+{
+ stack_t stack = {
+ .ss_sp = altstack_data,
+ .ss_size = SIGSTKSZ,
+ };
+ if (sigaltstack(&stack, NULL) != 0)
+ err(1, "sigaltstack");
+
+ sethandler(SIGSEGV, sigsegv, SA_ONSTACK);
+ sethandler(SIGILL, sigill, SA_ONSTACK);
+
+ /*
+* Exercise another nasty special case. The 32-bit SYSCALL
+* and SYSENTER instructions (even in compat mode) each
+* clobber one register. A Linux system call has a syscall
+* number and six arguments, and the user stack pointer
+* needs to live in some register on return. That means
+* that we need eight registers, but SYSCALL and SYSENTER
+* only preserve seven registers. As a result, one argument
+* ends up on the stack. The stack is user memory, which
+* means that the kernel can fail to read it.
+*
+
[tip:x86/boot] x86/boot: Add hex output for debugging
Commit-ID: 79063a7c0239419d5f6bee63228f66256fdc0fc4
Gitweb: http://git.kernel.org/tip/79063a7c0239419d5f6bee63228f66256fdc0fc4
Author: Kees Cook
AuthorDate: Mon, 6 Jul 2015 16:06:20 -0700
Committer: Ingo Molnar
CommitDate: Tue, 7 Jul 2015 08:59:05 +0200
x86/boot: Add hex output for debugging
This is useful for reporting various addresses or other values
while debugging early boot, for example, the recent kernel image
size vs kernel run size. For example, when
CONFIG_X86_VERBOSE_BOOTUP is set, this is now visible at boot
time:
early console in setup code
early console in decompress_kernel
input_data: 0x01e1526e
input_len: 0x00732236
output: 0x0100
output_len: 0x01535640
run_size: 0x021fb000
KASLR using RDTSC...
Signed-off-by: Kees Cook
Cc: Andrey Ryabinin
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Jan Beulich
Cc: Jiri Kosina
Cc: Joe Perches
Cc: Josh Triplett
Cc: Junjie Mao
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Vivek Goyal
Cc: Yinghai Lu
Link: http://lkml.kernel.org/r/20150706230620.ga17...@www.outflux.net
Signed-off-by: Ingo Molnar
---
arch/x86/boot/compressed/misc.c | 24
arch/x86/boot/compressed/misc.h | 11 +++
2 files changed, 35 insertions(+)
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index a107b93..f637979 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -220,6 +220,23 @@ void __putstr(const char *s)
outb(0xff & (pos >> 1), vidport+1);
}
+void __puthex(unsigned long value)
+{
+ char alpha[2] = "0";
+ int bits;
+
+ for (bits = sizeof(value) * 8 - 4; bits >= 0; bits -= 4) {
+ unsigned long digit = (value >> bits) & 0xf;
+
+ if (digit < 0xA)
+ alpha[0] = '0' + digit;
+ else
+ alpha[0] = 'a' + (digit - 0xA);
+
+ __putstr(alpha);
+ }
+}
+
static void error(char *x)
{
error_putstr("\n\n");
@@ -399,6 +416,13 @@ asmlinkage __visible void *decompress_kernel(void *rmode,
memptr heap,
free_mem_ptr = heap;/* Heap */
free_mem_end_ptr = heap + BOOT_HEAP_SIZE;
+ /* Report initial kernel position details. */
+ debug_putaddr(input_data);
+ debug_putaddr(input_len);
+ debug_putaddr(output);
+ debug_putaddr(output_len);
+ debug_putaddr(run_size);
+
/*
* The memory hole needed for the kernel is the larger of either
* the entire decompressed kernel plus relocation table, or the
diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
index 805d25c..3783dc3 100644
--- a/arch/x86/boot/compressed/misc.h
+++ b/arch/x86/boot/compressed/misc.h
@@ -34,16 +34,27 @@ extern memptr free_mem_ptr;
extern memptr free_mem_end_ptr;
extern struct boot_params *real_mode; /* Pointer to real-mode data */
void __putstr(const char *s);
+void __puthex(unsigned long value);
#define error_putstr(__x) __putstr(__x)
+#define error_puthex(__x) __puthex(__x)
#ifdef CONFIG_X86_VERBOSE_BOOTUP
#define debug_putstr(__x) __putstr(__x)
+#define debug_puthex(__x) __puthex(__x)
+#define debug_putaddr(__x) { \
+ debug_putstr(#__x ": 0x"); \
+ debug_puthex((unsigned long)(__x)); \
+ debug_putstr("\n"); \
+ }
#else
static inline void debug_putstr(const char *s)
{ }
+static inline void debug_puthex(const char *s)
+{ }
+#define debug_putaddr(x) /* */
#endif
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: mediatek: Add MT8173 MMPLL change rate support
Am Dienstag, 7. Juli 2015, 17:48:45 schrieb James Liao:
> Hi Heiko,
>
> On Tue, 2015-07-07 at 11:34 +0200, Heiko Stübner wrote:
> > > > > @@ -135,16 +138,26 @@ static void mtk_pll_calc_values(struct
> > > > > mtk_clk_pll
> > > > > *pll, u32 *pcw, u32 *postdiv, u32 freq, u32 fin)
> > > > >
> > > > > {
> > > > >
> > > > > unsigned long fmin = 1000 * MHZ;
> > > > >
> > > > > + const unsigned long *div_rate = pll->data->div_rate;
> > > > >
> > > > > u64 _pcw;
> > > > > u32 val;
> > > > >
> > > > > if (freq > pll->data->fmax)
> > > > >
> > > > > freq = pll->data->fmax;
> > > > >
> > > > > - for (val = 0; val < 4; val++) {
> > > > > + if (div_rate) {
> > > > > + for (val = 1; div_rate[val] != 0; val++) {
> > > > > + if (freq > div_rate[val])
> > > > > + break;
> > > > > + }
> > > > > + val--;
> > > >
> > > > if you're changing the table struct, this of course also would need to
> > > > be
> > > > adapted.
> > > >
> > > >
> > > > Hmm, what I don't understand is, what does MT8173_PLL_FMAX in the
> > > > table,
> > > > if
> > > > you ignore it here all the time?
> > > >
> > > > So the table should probably look more like [when using the concept
> > > > from
> > > > above]
> > > >
> > > > static const struct mtk_pll_div_table mmpll_div_rate[] = {
> > > >
> > > > { .freq = 10, .div = 0 },
> > > > { .freq = 70200, .div = 1 },
> > > > { .freq = 25350, .div = 2 },
> > > > { .freq = 12675, .div = 3 },
> > > > { /* sentinel */ },
> > > >
> > > > };
> > >
> > > The freq-div table describes the maximum frequency of each divider
> > > setting. Although the first element doesn't used in current
> > > implementation, I think it's better to keep freq-div table's
> > > completeness.
> >
> > the issue I see is, that its value is currently 0 and the code substracts
> > 1. So if anything would (accidentially) select MT8173_PLL_FMAX, the u32
> > val would wrap around, as you're subtracting 1 from 0 .
>
> Subtracting 1 from val is safe now because it starts from 1:
>
> for (val = 1; div_rate[val] != 0; val++) {
> ...
> }
> val--;
>
> I can change this implementation to a more readable one such as:
>
> for (val = 0; div_rate[val + 1] != 0; val++) {
> if (freq <= div_rate[val] && freq > div_rate[val + 1]) {
> ...
>
> Do you think it is OK?
My issue is, that you have the MT8173_PLL_FMAX entry in the table, which is
effectively unused, as it is ignored by the for loop. They why have it all, if
nothing cares about it.
So if in the future somebody notices, "oh this is ignoring the first entry"
without look further what the code does, this explodes ;-)
Heiko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acpi-cpufreq: replace per_cpu with driver_data of policy
On 07-07-15, 18:29, Pan Xinhui wrote:
>
> Now policy has field of driver_data, we can use it to get rid of per_cpu
> acpi_cpufreq_data.
Instead:
"Drivers can store their internal per-policy information in
policy->driver_data, lets use it."
> we have benefits after this replacing. 1) memory saving. 2) policy is
s/we/We
Also these points can be kept in separate lines :)
> shared by several cpus, per_cpu seems not correct. useing *driver_data*
using
> is more reasonable. 3) fix a memory leak in acpi_cpufreq_cpu_exit.
Not just that. You are also fixing NULL pointer dereferences if wrong
or uninitialized per-cpu data is used, because of a recent hotplug of
policy->cpu.
> as
> policy->cpu might change after cpu hotplug. So sometimes we cant't free
> *data*, use *driver_data* to fix it. 4) fix a zero return value of
> get_cur_freq_on_cpu. Only per_cpu(policy->cpu) is set to *data*, if we
> try to get cpufreq on other cpus, we get zero instead of correct values.
> Use *driver_data* to fix it.
>
> Signed-off-by: Pan Xinhui
> ---
> drivers/cpufreq/acpi-cpufreq.c | 38 +++---
> 1 file changed, 23 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
> index 0136dfc..7f662dd 100644
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -72,8 +72,6 @@ struct acpi_cpufreq_data {
> cpumask_var_t freqdomain_cpus;
> };
>
> -static DEFINE_PER_CPU(struct acpi_cpufreq_data *, acfreq_data);
> -
> /* acpi_perf_data is a pointer to percpu data. */
> static struct acpi_processor_performance __percpu *acpi_perf_data;
>
> @@ -144,7 +142,7 @@ static int _store_boost(int val)
>
> static ssize_t show_freqdomain_cpus(struct cpufreq_policy *policy, char *buf)
> {
> - struct acpi_cpufreq_data *data = per_cpu(acfreq_data, policy->cpu);
> + struct acpi_cpufreq_data *data = policy->driver_data;
>
> return cpufreq_show_cpus(data->freqdomain_cpus, buf);
> }
> @@ -327,7 +325,8 @@ static void drv_write(struct drv_cmd *cmd)
> put_cpu();
> }
>
> -static u32 get_cur_val(const struct cpumask *mask)
> +static u32 get_cur_val(const struct cpumask *mask,
> + struct acpi_cpufreq_data *data)
Run checkpatch --strict to see some alignment warnings here..
> {
> struct acpi_processor_performance *perf;
> struct drv_cmd cmd;
> @@ -335,7 +334,7 @@ static u32 get_cur_val(const struct cpumask *mask)
> if (unlikely(cpumask_empty(mask)))
> return 0;
>
> - switch (per_cpu(acfreq_data, cpumask_first(mask))->cpu_feature) {
> + switch (data->cpu_feature) {
> case SYSTEM_INTEL_MSR_CAPABLE:
> cmd.type = SYSTEM_INTEL_MSR_CAPABLE;
> cmd.addr.msr.reg = MSR_IA32_PERF_CTL;
> @@ -346,7 +345,7 @@ static u32 get_cur_val(const struct cpumask *mask)
> break;
> case SYSTEM_IO_CAPABLE:
> cmd.type = SYSTEM_IO_CAPABLE;
> - perf = per_cpu(acfreq_data, cpumask_first(mask))->acpi_data;
> + perf = data->acpi_data;
> cmd.addr.io.port = perf->control_register.address;
> cmd.addr.io.bit_width = perf->control_register.bit_width;
> break;
> @@ -364,19 +363,26 @@ static u32 get_cur_val(const struct cpumask *mask)
>
> static unsigned int get_cur_freq_on_cpu(unsigned int cpu)
> {
> - struct acpi_cpufreq_data *data = per_cpu(acfreq_data, cpu);
> + struct acpi_cpufreq_data *data;
> + struct cpufreq_policy *policy;
> unsigned int freq;
> unsigned int cached_freq;
>
> pr_debug("get_cur_freq_on_cpu (%d)\n", cpu);
>
> + policy = cpufreq_cpu_get(cpu);
> + if (unlikely(!policy))
> + return 0;
> +
> + data = policy->driver_data;
Do
+ cpufreq_cpu_put(policy);
right here. No need of doing this towards the end.
> if (unlikely(data == NULL ||
>data->acpi_data == NULL || data->freq_table == NULL)) {
Maybe this if you like:
if (unlikely(! data || !data->acpi_data || !data->freq_table))
return 0;
> + cpufreq_cpu_put(policy);
> return 0;
> }
>
> cached_freq = data->freq_table[data->acpi_data->state].frequency;
And this freq_table thing gives you opportunity to write another
patch :)
policy already have: policy->freq_table :)
> - freq = extract_freq(get_cur_val(cpumask_of(cpu)), data);
> + freq = extract_freq(get_cur_val(cpumask_of(cpu), data), data);
> if (freq != cached_freq) {
> /*
>* The dreaded BIOS frequency change behind our back.
> @@ -385,6 +391,8 @@ static unsigned int get_cur_freq_on_cpu(unsigned int cpu)
> data->resume = 1;
> }
>
> + cpufreq_cpu_put(policy);
> +
> pr_debug("cur freq = %u\n", freq);
>
> return fr
Re: [PATCH 1/6] Input: pixcir_i2c_ts - move platform data
On 07/07/15 03:30, Dmitry Torokhov wrote:
Let's move driver's platform data definitions from include/linux/input/
into include/linux/platform_data/ so that it stays with the rest of
platform data definitions.
Signed-off-by: Dmitry Torokhov
Acked-by: Roger Quadros
cheers,
-roger
---
drivers/input/touchscreen/pixcir_i2c_ts.c | 2 +-
include/linux/input/pixcir_ts.h | 64 -
include/linux/platform_data/pixcir_i2c_ts.h | 64 +
3 files changed, 65 insertions(+), 65 deletions(-)
delete mode 100644 include/linux/input/pixcir_ts.h
create mode 100644 include/linux/platform_data/pixcir_i2c_ts.h
diff --git a/drivers/input/touchscreen/pixcir_i2c_ts.c
b/drivers/input/touchscreen/pixcir_i2c_ts.c
index 8f3e243..ccafa75 100644
--- a/drivers/input/touchscreen/pixcir_i2c_ts.c
+++ b/drivers/input/touchscreen/pixcir_i2c_ts.c
@@ -24,11 +24,11 @@
#include
#include
#include
-#include
#include
#include
#include
#include
+#include
#define PIXCIR_MAX_SLOTS 5 /* Max fingers supported by driver */
diff --git a/include/linux/input/pixcir_ts.h b/include/linux/input/pixcir_ts.h
deleted file mode 100644
index 7bae83b..000
--- a/include/linux/input/pixcir_ts.h
+++ /dev/null
@@ -1,64 +0,0 @@
-#ifndef_PIXCIR_I2C_TS_H
-#define_PIXCIR_I2C_TS_H
-
-/*
- * Register map
- */
-#define PIXCIR_REG_POWER_MODE 51
-#define PIXCIR_REG_INT_MODE52
-
-/*
- * Power modes:
- * active: max scan speed
- * idle: lower scan speed with automatic transition to active on touch
- * halt: datasheet says sleep but this is more like halt as the chip
- * clocks are cut and it can only be brought out of this mode
- * using the RESET pin.
- */
-enum pixcir_power_mode {
- PIXCIR_POWER_ACTIVE,
- PIXCIR_POWER_IDLE,
- PIXCIR_POWER_HALT,
-};
-
-#define PIXCIR_POWER_MODE_MASK 0x03
-#define PIXCIR_POWER_ALLOW_IDLE (1UL << 2)
-
-/*
- * Interrupt modes:
- * periodical: interrupt is asserted periodicaly
- * diff coordinates: interrupt is asserted when coordinates change
- * level on touch: interrupt level asserted during touch
- * pulse on touch: interrupt pulse asserted druing touch
- *
- */
-enum pixcir_int_mode {
- PIXCIR_INT_PERIODICAL,
- PIXCIR_INT_DIFF_COORD,
- PIXCIR_INT_LEVEL_TOUCH,
- PIXCIR_INT_PULSE_TOUCH,
-};
-
-#define PIXCIR_INT_MODE_MASK 0x03
-#define PIXCIR_INT_ENABLE (1UL << 3)
-#define PIXCIR_INT_POL_HIGH(1UL << 2)
-
-/**
- * struct pixcir_irc_chip_data - chip related data
- * @max_fingers: Max number of fingers reported simultaneously by h/w
- * @has_hw_ids:Hardware supports finger tracking IDs
- *
- */
-struct pixcir_i2c_chip_data {
- u8 max_fingers;
- bool has_hw_ids;
-};
-
-struct pixcir_ts_platform_data {
- int x_max;
- int y_max;
- int gpio_attb; /* GPIO connected to ATTB line */
- struct pixcir_i2c_chip_data chip;
-};
-
-#endif
diff --git a/include/linux/platform_data/pixcir_i2c_ts.h
b/include/linux/platform_data/pixcir_i2c_ts.h
new file mode 100644
index 000..7bae83b
--- /dev/null
+++ b/include/linux/platform_data/pixcir_i2c_ts.h
@@ -0,0 +1,64 @@
+#ifndef_PIXCIR_I2C_TS_H
+#define_PIXCIR_I2C_TS_H
+
+/*
+ * Register map
+ */
+#define PIXCIR_REG_POWER_MODE 51
+#define PIXCIR_REG_INT_MODE52
+
+/*
+ * Power modes:
+ * active: max scan speed
+ * idle: lower scan speed with automatic transition to active on touch
+ * halt: datasheet says sleep but this is more like halt as the chip
+ * clocks are cut and it can only be brought out of this mode
+ * using the RESET pin.
+ */
+enum pixcir_power_mode {
+ PIXCIR_POWER_ACTIVE,
+ PIXCIR_POWER_IDLE,
+ PIXCIR_POWER_HALT,
+};
+
+#define PIXCIR_POWER_MODE_MASK 0x03
+#define PIXCIR_POWER_ALLOW_IDLE (1UL << 2)
+
+/*
+ * Interrupt modes:
+ * periodical: interrupt is asserted periodicaly
+ * diff coordinates: interrupt is asserted when coordinates change
+ * level on touch: interrupt level asserted during touch
+ * pulse on touch: interrupt pulse asserted druing touch
+ *
+ */
+enum pixcir_int_mode {
+ PIXCIR_INT_PERIODICAL,
+ PIXCIR_INT_DIFF_COORD,
+ PIXCIR_INT_LEVEL_TOUCH,
+ PIXCIR_INT_PULSE_TOUCH,
+};
+
+#define PIXCIR_INT_MODE_MASK 0x03
+#define PIXCIR_INT_ENABLE (1UL << 3)
+#define PIXCIR_INT_POL_HIGH(1UL << 2)
+
+/**
+ * struct pixcir_irc_chip_data - chip related data
+ * @max_fingers: Max number of fingers reported simultaneously by h/w
+ * @has_hw_ids:Hardware supports finger tracking IDs
+ *
+ */
+struct pixcir_i2c_chip_data {
+ u8 max_fingers;
+ bool has_hw_ids;
+};
+
+struct pixcir_ts_platform_data {
+ int x_max;
+ int y_max;
+ int gpio_attb; /* GPIO connected to ATTB line */
+ struct pixcir_i2c_chip_data chip;
+};
+
+#endif
--
To unsubscribe from this list: send the line "unsubscribe lin
Re: rx51-battery.ko incompatiblity: board code vs DT
On Mon 2015-07-06 21:44:22, Pali Rohár wrote: > Hello, > > now I found out that rx51-battery.ko driver register sysnode > /sys/class/power_supply/rx51-battery/ when booting with legacy board > code. But when booting DT kernel it register sysnode with different name > /sys/class/power_supply/n900-battery/ > > Sysfs node for DT kernel comes from Nokia N900 DTS file: > arch/arm/boot/dts/omap3-n900.dts > > I would propose change which change DTS to "rx51-battery" to have it > compatible with naming which is for legacy board code. It is just > because to have compatibility and same naming scheme and also to make > existing programs to work without needing patching them. > > What do you think? Makes sense.. along with _big_ comment in the dts why we are doing this. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-V5 3/4] mfd: 88pm800: Set default interrupt clear method
On Tue, 07 Jul 2015, Vaibhav Hiremath wrote:
> On Tuesday 07 July 2015 12:59 PM, Lee Jones wrote:
> >On Mon, 29 Jun 2015, Vaibhav Hiremath wrote:
> >
> >>As per the spec, bit 1 (INT_CLEAR_MODE) of reg addr 0xe
> >>(page 0) controls the method of clearing interrupt
> >>status of 88pm800 family of devices;
> >>
> >> 0: clear on read
> >> 1: clear on write
> >>
> >>If pdata is not coming from board file, then set the
> >>default irq clear method to "irq clear on write"
> >>
> >>Also, as suggested by "Lee Jones" renaming variable field
> >>to appropriate name.
> >>
> >>Signed-off-by: Zhao Ye
> >>Signed-off-by: Vaibhav Hiremath
> >>---
> >> drivers/mfd/88pm800.c | 15 ++-
> >> include/linux/mfd/88pm80x.h | 10 --
> >> 2 files changed, 18 insertions(+), 7 deletions(-)
> >>
> >>diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
> >>index d495737..66347be 100644
> >>--- a/drivers/mfd/88pm800.c
> >>+++ b/drivers/mfd/88pm800.c
> >>@@ -374,7 +374,7 @@ static int device_irq_init_800(struct pm80x_chip *chip)
> >> {
> >>struct regmap *map = chip->regmap;
> >>unsigned long flags = IRQF_ONESHOT;
> >>- int data, mask, ret = -EINVAL;
> >>+ int irq_clr_mode, mask, ret = -EINVAL;
> >>
> >>if (!map || !chip->irq) {
> >>dev_err(chip->dev, "incorrect parameters\n");
> >>@@ -382,15 +382,16 @@ static int device_irq_init_800(struct pm80x_chip
> >>*chip)
> >>}
> >>
> >>/*
> >>-* irq_mode defines the way of clearing interrupt. it's read-clear by
> >>-* default.
> >>+* irq_clr_on_wr defines the way of clearing interrupt by
> >>+* read/write(0/1). It's read-clear by default.
> >> */
> >>mask =
> >>PM800_WAKEUP2_INV_INT | PM800_WAKEUP2_INT_CLEAR |
> >>PM800_WAKEUP2_INT_MASK;
> >>
> >>- data = PM800_WAKEUP2_INT_CLEAR;
> >>- ret = regmap_update_bits(map, PM800_WAKEUP2, mask, data);
> >>+ irq_clr_mode = chip->irq_clr_method == PM800_IRQ_CLR_ON_WRITE ?
> >>+ PM800_WAKEUP2_INT_WRITE_CLEAR : PM800_WAKEUP2_INT_READ_CLEAR;
> >>+ ret = regmap_update_bits(map, PM800_WAKEUP2, mask, irq_clr_mode);
> >
> >What's stopping you just passing PM800_WAKEUP2_INT_WRITE_CLEAR or
> >PM800_WAKEUP2_INT_READ_CLEAR from pdata? Then you can use the value
> >directly without all of this faffing about.
> >
> > regmap_update_bits(map, PM800_WAKEUP2, mask, pdata->irq_clr_mode);
> >
>
> Because "irq_clr_method" is of boolean type.
> And macros which you are referring to is,
>
> #define PM800_WAKEUP2_INT_READ_CLEAR(0 << 1)
> #define PM800_WAKEUP2_INT_WRITE_CLEAR (1 << 1)
>
>
> And also, I feel it is more cleaner approach with the current code as
> register definition and userflag are maintained separately.
I see your point, although it's a shame we have to have this code in
its place.
One thing I think you can do though is rid chip->irq_clr_method, just
use the one you already have in pdata.
> >>if (ret < 0)
> >>goto out;
> >>@@ -512,6 +513,7 @@ static int device_800_init(struct pm80x_chip *chip,
> >>}
> >>
> >>chip->regmap_irq_chip = &pm800_irq_chip;
> >>+ chip->irq_clr_method = pdata->irq_clr_method;
> >>
> >>ret = device_irq_init_800(chip);
> >>if (ret < 0) {
> >>@@ -564,6 +566,9 @@ static int pm800_probe(struct i2c_client *client,
> >>pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
> >>if (!pdata)
> >>return -ENOMEM;
> >>+
> >>+ /* by default, set irq clear method on write */
> >>+ pdata->irq_clr_method = PM800_IRQ_CLR_ON_WRITE;
> >>}
> >>
> >>ret = pm80x_init(client);
> >>diff --git a/include/linux/mfd/88pm80x.h b/include/linux/mfd/88pm80x.h
> >>index 8fcad63..648e01a 100644
> >>--- a/include/linux/mfd/88pm80x.h
> >>+++ b/include/linux/mfd/88pm80x.h
> >>@@ -77,6 +77,8 @@ enum {
> >> #define PM800_WAKEUP2 (0x0E)
> >> #define PM800_WAKEUP2_INV_INT BIT(0)
> >> #define PM800_WAKEUP2_INT_CLEAR BIT(1)
> >>+#define PM800_WAKEUP2_INT_READ_CLEAR (0 << 1)
> >>+#define PM800_WAKEUP2_INT_WRITE_CLEAR (1 << 1)
> >> #define PM800_WAKEUP2_INT_MASKBIT(2)
> >>
> >> #define PM800_POWER_UP_LOG(0x10)
> >>@@ -300,7 +302,11 @@ struct pm80x_chip {
> >>struct regmap_irq_chip_data *irq_data;
> >>int type;
> >>int irq;
> >>- int irq_mode;
> >>+
> >>+#define PM800_IRQ_CLR_ON_READ 0
> >>+#define PM800_IRQ_CLR_ON_WRITE 1
> >
> >Defines in the middle of structs makes for ugly code.
> >
>
> Sorry, but kernel code is full of such implementations.
> Infact it is right place in terms of readability.
>
> If you still feel insist to fix it, please let me know whether you want
> to submit V6 just for this. Or you will fix it while merging.
> I am OK with anything here...
>
>
> Thanks,
> Vaibhav
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow
Re: [1/1] cxl/vphb.c: Use phb pointer after NULL check
On Mon, 2015-29-06 at 10:35:11 UTC, Maninder Singh wrote: > static Anlaysis detected below error:- > (error) Possible null pointer dereference: phb > > So, Use phb after NULL check. > > Signed-off-by: Maninder Singh > Acked-by: Ian Munsie Applied to powerpc fixes, thanks. https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git/commit/?h=fixes&id=14f21189df33bc972455d6a0ed875aa68718d7fc cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/3] clk: Add regmap support for clk mulitplexer
On Tuesday, June 16, 2015 04:23:32 PM Matthias Brugger wrote: > This patch set adds regmap support for the simple clock multiplexer, > the divider clock and the clock gate. > Regmap use, apart from a pointer to the regmap struct, needs an > offset value to know where in the regmap it has to read/write. > We add both fields to the corresponding structs. > > The driver will distinguish between a clock which is based on regmap or not > through a flag specified in the clock hardware struct. > The approach does not break the existing clock framework API but adds > new functions for registering regmap clocks. Unregistering the clocks is > independent of the use of regmap or not, so that no new functions were > implemented. > > As an example user of the regmap clock multiplexer, it was implemented on > the mt8135. When accepted it will also be applied to the other Mediatek > SoCs. Other possible user are Qualcomm SoCs which up to now implement their > own regmap based clock multiplexer. > > This patch set is based on linux next. > To get the mt8135 eval board up and running, we need to enable the clock > support [1] and use the two clocks for the uart port [2]. > > Any comments welcome. > > [1] https://patchwork.kernel.org/patch/6261141/ > [2] https://patchwork.kernel.org/patch/6261151/ > Hi Mike, hi Stephen, Any comments on this patch set? Regrads, Matthias > Changes for v4: > - fix style issues > - use __clk_get_flags > - delete #ifdef CONFIG_REGMAP > > Changes for v3: > - rebase against linux-next > - provide regmap access to all three clock types in a unified way > > Changes for v2: > - use regmap_update_bits instead of read-write > - fix flag check > - add union in struct clk_mux > - fix typo in commit message > > --- > > Matthias Brugger (3): > clk: Add regmap support > clk: mediatek: Add support for clk-mux using regmap > clk: mediatek: Use regmap clk-mux for mt8135 > > drivers/clk/Makefile | 1 + > drivers/clk/clk-divider.c | 68 ++-- > drivers/clk/clk-gate.c| 57 +++- > drivers/clk/clk-io.c | 48 > drivers/clk/clk-io.h | 22 + > drivers/clk/clk-mux.c | 94 > --- drivers/clk/mediatek/clk-mt8135.c | > 21 +++-- > drivers/clk/mediatek/clk-mtk.c| 37 +++ > drivers/clk/mediatek/clk-mtk.h| 26 +++ > include/linux/clk-provider.h | 54 -- > 10 files changed, 370 insertions(+), 58 deletions(-) > create mode 100644 drivers/clk/clk-io.c > create mode 100644 drivers/clk/clk-io.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v2] powerpc/powernv: Fix race in updating core_idle_state
On Mon, 2015-06-07 at 20:09:23 UTC, "Shreyas B. Prabhu" wrote: > core_idle_state is maintained for each core. It uses 0-7 bits to track > whether a thread in the core has entered fastsleep or winkle. 8th bit is > used as a lock bit. ... > Signed-off-by: Shreyas B. Prabhu > Fixes: 7b54e9f213f76 'powernv/powerpc: Add winkle support for offline > cpus' Applied to powerpc fixes, thanks. https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git/commit/?h=fixes&id=b32aadc1a8ed84afbe924cd2ced31cd6a2e67074 cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf, kprobes: fuzzer generates huge number of WARNings
On 2015/07/07 13:00, Vince Weaver wrote: > On Tue, 7 Jul 2015, Masami Hiramatsu wrote: > >> On 2015/07/07 6:27, Vince Weaver wrote: >>> Hello >>> >>> I've been working on trying to get the perf_fuzzer to start fuzzing the >>> PERF_EVENT_IOC_SET_BPF so I've added some really hackish kprobe support. >>> >>> However before I can get to the BPF testing the kprobe code generates a >>> constant stream of WARNINGS which make the machine more or less useless >>> until I stop it. I've included a small selection here. >>> >>> Is this expected? >> >> Did you get same message without BPF hack? And also, could you tell us >> your kernel version and configuration? > > It's a Hawell machine running 4.2-rc1. I can post the .config if it's of > interest. Yes, I'm interested in. > Well the BPF hack is in the fuzzer, not the kernel. And it's not really a > hack, it just turned out to be a huge pain to figure out how to > manually create a valid BPF program in conjunction with a valid kprobe > event. > > I did have to sprinkle printks in the kprobe and bpf code to find out > where various EINVAL returns were coming from, so potentially this is just > a problem of printks happening where they shouldn't. I'll remove those > changes and try to reproduce this tomorrow. OK, and also, if you have a chance, please run the ftracetest as below. $ cd tools/testing/selftest/ftrace/ $ sudo ./ftracetest This will do a series of basic tests on ftrace and report it. > This is possibly a long standing issue, until now I never ran the fuzzer > as root so these particular code paths weren't tested. Thanks, -- Masami HIRAMATSU Linux Technology Research Center, System Productivity Research Dept. Center for Technology Innovation - Systems Engineering Hitachi, Ltd., Research & Development Group E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature
> -Original Message-
> From: Paul Bolle
> Sent: Tuesday, July 7, 2015 17:38
> To: Dexuan Cui
> Subject: Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature
>
> Just two nits.
>
> On ma, 2015-07-06 at 07:47 -0700, Dexuan Cui wrote:
> > --- /dev/null
> > +++ b/net/hv_sock/Kconfig
>
> > +config HYPERV_SOCK
> > + tristate "Microsoft Hyper-V Socket (EXPERIMENTAL)"
> > + depends on HYPERV
> > + default m
> > + help
> > + Hyper-V Socket is a socket protocol similar to TCP, allowing
> > + communication between a Linux guest and the host.
> > +
> > + To compile this driver as a module, choose M here: the module
> > + will be called hv_sock. If unsure, say N.
>
> It's a bit odd to advise to say N if one is unsure and set the default
> to 'm' at the same time.
Hi Paul,
Thanks for the suggestion!
I'll change the 'default' to n in V2.
> > --- /dev/null
> > +++ b/net/hv_sock/af_hvsock.c
>
> > +static int hvsock_init(void)
> > +{
> > + [...]
> > +}
> > +
> > +static void hvsock_exit(void)
> > +{
> > + [...]
> > +}
> > +
> > +module_init(hvsock_init);
> > +module_exit(hvsock_exit);
>
> Any specific reason not to mark these functions __init and __exit?
>
> Paul Bolle
Thanks for pointing this out -- I missed that.
I'll add __init and __exit in V2.
Thanks,
-- Dexuan
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH] clocksource: Allow toggling between runtime and persistent clocksource for idle
* John Stultz [150706 10:55]: > On Mon, Jul 6, 2015 at 10:34 AM, Thomas Gleixner wrote: > > On Mon, 6 Jul 2015, John Stultz wrote: > >> On Mon, Jul 6, 2015 at 12:12 AM, Tony Lindgren wrote: > >> > Some persistent clocksources can be on a slow external bus. For shorter > >> > latencies for RT use, let's allow toggling the clocksource during idle > >> > between a faster non-persistent runtime clocksource and a slower > >> > persistent > >> > clocksource. > >> > >> So yea, as Thomas mentioned, this will cause problems for timekeeping > >> accuracy, since we end up resetting the ntp state when we change > >> clocksource (additionally you gain a bit of error each time you switch > >> clocksources). So you'll most likely see trouble w/ ntpd steering the > >> clock. > >> > >> I'm not sure its quite clear in the description as to the need here. > >> Could you expand a bit as to the rational for why? I assume it has to > >> do with you have a high-res clocksource that is good for fine-grained > >> clock_gettime() calls, but wraps quickly, making it poor for long idle > >> times. So you're trying to swap to a less fine grained clocksource > >> that won't wrap so fast? > >> > >> The persistent-clock-like name muddies things further, since the > >> persistent-clock is used for suspend, while it looks like this is just > >> for idle times. > > > > Though that are idle states where the cpu is powered off so the fast > > clock source is powered off as well > > > > We all know how well that works from the x86/TSC horror. It's just the > > same thing again with a different arch prefix. > > Right.. and it might be telling that on x86 systems with this issue, > we don't play games with it and that sort of hardware just has to use > the slower and less fine-grained clocksources all the time. Yes it's similar to the old x86 TSC vs ACPI PM timer issue. We have ARM global timer powered off during idle. It may be best to just use kernel cmdline to select the ARM global timer and then disable any deeper power states if ARM global timer is selected. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] acpi-cpufreq: replace per_cpu with driver_data of policy
Now policy has field of driver_data, we can use it to get rid of per_cpu
acpi_cpufreq_data.
we have benefits after this replacing. 1) memory saving. 2) policy is
shared by several cpus, per_cpu seems not correct. useing *driver_data*
is more reasonable. 3) fix a memory leak in acpi_cpufreq_cpu_exit. as
policy->cpu might change after cpu hotplug. So sometimes we cant't free
*data*, use *driver_data* to fix it. 4) fix a zero return value of
get_cur_freq_on_cpu. Only per_cpu(policy->cpu) is set to *data*, if we
try to get cpufreq on other cpus, we get zero instead of correct values.
Use *driver_data* to fix it.
Signed-off-by: Pan Xinhui
---
drivers/cpufreq/acpi-cpufreq.c | 38 +++---
1 file changed, 23 insertions(+), 15 deletions(-)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 0136dfc..7f662dd 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -72,8 +72,6 @@ struct acpi_cpufreq_data {
cpumask_var_t freqdomain_cpus;
};
-static DEFINE_PER_CPU(struct acpi_cpufreq_data *, acfreq_data);
-
/* acpi_perf_data is a pointer to percpu data. */
static struct acpi_processor_performance __percpu *acpi_perf_data;
@@ -144,7 +142,7 @@ static int _store_boost(int val)
static ssize_t show_freqdomain_cpus(struct cpufreq_policy *policy, char *buf)
{
- struct acpi_cpufreq_data *data = per_cpu(acfreq_data, policy->cpu);
+ struct acpi_cpufreq_data *data = policy->driver_data;
return cpufreq_show_cpus(data->freqdomain_cpus, buf);
}
@@ -327,7 +325,8 @@ static void drv_write(struct drv_cmd *cmd)
put_cpu();
}
-static u32 get_cur_val(const struct cpumask *mask)
+static u32 get_cur_val(const struct cpumask *mask,
+ struct acpi_cpufreq_data *data)
{
struct acpi_processor_performance *perf;
struct drv_cmd cmd;
@@ -335,7 +334,7 @@ static u32 get_cur_val(const struct cpumask *mask)
if (unlikely(cpumask_empty(mask)))
return 0;
- switch (per_cpu(acfreq_data, cpumask_first(mask))->cpu_feature) {
+ switch (data->cpu_feature) {
case SYSTEM_INTEL_MSR_CAPABLE:
cmd.type = SYSTEM_INTEL_MSR_CAPABLE;
cmd.addr.msr.reg = MSR_IA32_PERF_CTL;
@@ -346,7 +345,7 @@ static u32 get_cur_val(const struct cpumask *mask)
break;
case SYSTEM_IO_CAPABLE:
cmd.type = SYSTEM_IO_CAPABLE;
- perf = per_cpu(acfreq_data, cpumask_first(mask))->acpi_data;
+ perf = data->acpi_data;
cmd.addr.io.port = perf->control_register.address;
cmd.addr.io.bit_width = perf->control_register.bit_width;
break;
@@ -364,19 +363,26 @@ static u32 get_cur_val(const struct cpumask *mask)
static unsigned int get_cur_freq_on_cpu(unsigned int cpu)
{
- struct acpi_cpufreq_data *data = per_cpu(acfreq_data, cpu);
+ struct acpi_cpufreq_data *data;
+ struct cpufreq_policy *policy;
unsigned int freq;
unsigned int cached_freq;
pr_debug("get_cur_freq_on_cpu (%d)\n", cpu);
+ policy = cpufreq_cpu_get(cpu);
+ if (unlikely(!policy))
+ return 0;
+
+ data = policy->driver_data;
if (unlikely(data == NULL ||
data->acpi_data == NULL || data->freq_table == NULL)) {
+ cpufreq_cpu_put(policy);
return 0;
}
cached_freq = data->freq_table[data->acpi_data->state].frequency;
- freq = extract_freq(get_cur_val(cpumask_of(cpu)), data);
+ freq = extract_freq(get_cur_val(cpumask_of(cpu), data), data);
if (freq != cached_freq) {
/*
* The dreaded BIOS frequency change behind our back.
@@ -385,6 +391,8 @@ static unsigned int get_cur_freq_on_cpu(unsigned int cpu)
data->resume = 1;
}
+ cpufreq_cpu_put(policy);
+
pr_debug("cur freq = %u\n", freq);
return freq;
@@ -397,7 +405,7 @@ static unsigned int check_freqs(const struct cpumask *mask,
unsigned int freq,
unsigned int i;
for (i = 0; i < 100; i++) {
- cur_freq = extract_freq(get_cur_val(mask), data);
+ cur_freq = extract_freq(get_cur_val(mask, data), data);
if (cur_freq == freq)
return 1;
udelay(10);
@@ -408,7 +416,7 @@ static unsigned int check_freqs(const struct cpumask *mask,
unsigned int freq,
static int acpi_cpufreq_target(struct cpufreq_policy *policy,
unsigned int index)
{
- struct acpi_cpufreq_data *data = per_cpu(acfreq_data, policy->cpu);
+ struct acpi_cpufreq_data *data = policy->driver_data;
struct acpi_processor_performance *perf;
struct drv_cmd cmd;
unsigned int next_perf_state = 0; /* Index into perf table */
@@ -673,7 +681,7 @@ static int acpi_
[PATCH v2 2/2] kconfig: Regenerate shipped zconf.{hash,lex}.c files
Update the shipped files generated by flex and gperf to support the
explicit use of "---help---" and to emit warnings for unsupported
characters on COMMAND tokens.
As I could not find out which flex/gperf version was used to generate
the previous version, I used flex 2.5.35 and gperf 3.0.4 from
Ubuntu 14.04 - this also leads to the big number of changed lines
in this patch.
Signed-off-by: Andreas Ruprecht
---
scripts/kconfig/zconf.hash.c_shipped | 58 +
scripts/kconfig/zconf.lex.c_shipped | 120 +++
2 files changed, 97 insertions(+), 81 deletions(-)
diff --git a/scripts/kconfig/zconf.hash.c_shipped
b/scripts/kconfig/zconf.hash.c_shipped
index c77a8ef..0af8a04 100644
--- a/scripts/kconfig/zconf.hash.c_shipped
+++ b/scripts/kconfig/zconf.hash.c_shipped
@@ -50,7 +50,7 @@ kconf_id_hash (register const char *str, register unsigned
int len)
73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
- 73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
+ 73, 73, 73, 73, 73, 0, 73, 73, 73, 73,
73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
73, 73, 73, 73, 73, 73, 73, 73, 73, 73,
@@ -96,6 +96,7 @@ struct kconf_id_strings_t
char kconf_id_strings_str7[sizeof("default")];
char kconf_id_strings_str8[sizeof("tristate")];
char kconf_id_strings_str9[sizeof("endchoice")];
+char kconf_id_strings_str10[sizeof("---help---")];
char kconf_id_strings_str12[sizeof("def_tristate")];
char kconf_id_strings_str13[sizeof("def_bool")];
char kconf_id_strings_str14[sizeof("defconfig_list")];
@@ -132,6 +133,7 @@ static const struct kconf_id_strings_t
kconf_id_strings_contents =
"default",
"tristate",
"endchoice",
+"---help---",
"def_tristate",
"def_bool",
"defconfig_list",
@@ -172,7 +174,7 @@ kconf_id_lookup (register const char *str, register
unsigned int len)
{
enum
{
- TOTAL_KEYWORDS = 33,
+ TOTAL_KEYWORDS = 34,
MIN_WORD_LENGTH = 2,
MAX_WORD_LENGTH = 14,
MIN_HASH_VALUE = 2,
@@ -182,34 +184,36 @@ kconf_id_lookup (register const char *str, register
unsigned int len)
static const struct kconf_id wordlist[] =
{
{-1}, {-1},
-#line 25 "scripts/kconfig/zconf.gperf"
+#line 26 "scripts/kconfig/zconf.gperf"
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str2,
T_IF, TF_COMMAND|TF_PARAM},
-#line 36 "scripts/kconfig/zconf.gperf"
+#line 37 "scripts/kconfig/zconf.gperf"
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str3,
T_TYPE, TF_COMMAND, S_INT},
{-1},
-#line 26 "scripts/kconfig/zconf.gperf"
+#line 27 "scripts/kconfig/zconf.gperf"
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str5,
T_ENDIF,TF_COMMAND},
{-1},
-#line 29 "scripts/kconfig/zconf.gperf"
+#line 30 "scripts/kconfig/zconf.gperf"
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str7,
T_DEFAULT, TF_COMMAND, S_UNKNOWN},
-#line 31 "scripts/kconfig/zconf.gperf"
+#line 32 "scripts/kconfig/zconf.gperf"
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str8,
T_TYPE, TF_COMMAND, S_TRISTATE},
#line 20 "scripts/kconfig/zconf.gperf"
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str9,
T_ENDCHOICE,TF_COMMAND},
- {-1}, {-1},
-#line 32 "scripts/kconfig/zconf.gperf"
+#line 25 "scripts/kconfig/zconf.gperf"
+ {(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str10,
T_HELP, TF_COMMAND},
+ {-1},
+#line 33 "scripts/kconfig/zconf.gperf"
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str12,
T_DEFAULT, TF_COMMAND, S_TRISTATE},
-#line 35 "scripts/kconfig/zconf.gperf"
+#line 36 "scripts/kconfig/zconf.gperf"
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str13,
T_DEFAULT, TF_COMMAND, S_BOOLEAN},
-#line 45 "scripts/kconfig/zconf.gperf"
+#line 46 "scripts/kconfig/zconf.gperf"
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str14,
T_OPT_DEFCONFIG_LIST,TF_OPTION},
{-1}, {-1},
-#line 43 "scripts/kconfig/zconf.gperf"
+#line 44 "scripts/kconfig/zconf.gperf"
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str17,
T_ON, TF_PARAM},
-#line 28 "scripts/kconfig/zconf.gperf"
+#line 29 "scripts/kconfig/zconf.gperf"
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str18,
T_OPTIONAL, TF_COMMAND},
{-1}, {-1},
-#line 42 "scripts/kconfig/zconf.gperf"
+#line 43 "scripts/kconfig/zconf.gperf"
{(int)(long)&((struct kconf_id_strings_t *)0)->kconf_id_strings_str21,
T_OPTION, TF_COMMAND},
#line 17 "scripts/kconfig/zconf.gperf"
{(int)(long)&((struct
[PATCH v2 1/2] kconfig: warn of unhandled characters in Kconfig commands
In Kconfig, definitions of options take the following form:
" ...". COMMANDs and PARAMs are treated
slightly different by the underlying parser.
While commit 2e0d737fc76f ("kconfig: don't silently ignore unhandled
characters") introduced a warning for unsupported characters around
PARAMs, it does not cover situations where a COMMAND has additional
characters around it.
This change makes Kconfig emit a warning if superfluous characters
are found around COMMANDs. As the 'help' statement sometimes is
written as '---help---', the '-' character would now also be regarded
as unhandled and generate a warning. To avoid that, '-' is added to
the list of allowed characters, and the token '---help---' is included
in the zconf.gperf file.
Reported-by: Valentin Rothberg
Signed-off-by: Andreas Ruprecht
---
scripts/kconfig/zconf.gperf | 1 +
scripts/kconfig/zconf.l | 18 --
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/scripts/kconfig/zconf.gperf b/scripts/kconfig/zconf.gperf
index b6ac02d..7aceb7b 100644
--- a/scripts/kconfig/zconf.gperf
+++ b/scripts/kconfig/zconf.gperf
@@ -22,6 +22,7 @@ comment, T_COMMENT, TF_COMMAND
config,T_CONFIG, TF_COMMAND
menuconfig,T_MENUCONFIG, TF_COMMAND
help, T_HELP, TF_COMMAND
+"---help---", T_HELP, TF_COMMAND
if,T_IF, TF_COMMAND|TF_PARAM
endif, T_ENDIF,TF_COMMAND
depends, T_DEPENDS, TF_COMMAND
diff --git a/scripts/kconfig/zconf.l b/scripts/kconfig/zconf.l
index 200a3fe..3078244 100644
--- a/scripts/kconfig/zconf.l
+++ b/scripts/kconfig/zconf.l
@@ -66,9 +66,16 @@ static void alloc_string(const char *str, int size)
memcpy(text, str, size);
text[size] = 0;
}
+
+static void warn_ignored_character(const char chr)
+{
+ fprintf(stderr,
+ "%s:%d:warning: ignoring unsupported character '%c'\n",
+ zconf_curname(), zconf_lineno(), chr);
+}
%}
-n [A-Za-z0-9_]
+n [A-Za-z0-9_-]
%%
int str = 0;
@@ -106,7 +113,9 @@ n [A-Za-z0-9_]
zconflval.string = text;
return T_WORD;
}
- .
+ . {
+ warn_ignored_character(*yytext);
+ }
\n {
BEGIN(INITIAL);
current_file->lineno++;
@@ -132,7 +141,6 @@ n [A-Za-z0-9_]
BEGIN(STRING);
}
\n BEGIN(INITIAL); current_file->lineno++; return T_EOL;
- --- /* ignore */
({n}|[-/.])+{
const struct kconf_id *id = kconf_id_lookup(yytext, yyleng);
if (id && id->flags & TF_PARAM) {
@@ -147,9 +155,7 @@ n [A-Za-z0-9_]
\\\ncurrent_file->lineno++;
[[:blank:]]+
. {
- fprintf(stderr,
- "%s:%d:warning: ignoring unsupported character '%c'\n",
- zconf_curname(), zconf_lineno(), *yytext);
+ warn_ignored_character(*yytext);
}
<> {
BEGIN(INITIAL);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/2] kconfig: warn of unhandled characters in Kconfig commands
This patchset changes the lexer file to emit a warning if any unhandled
characters are found in the input. So far, Kconfig options like
+config FOO
bool
[...]
(note the wrong '+'!) were parsed without a warning. As simply adding a
warning for '.' produces lots of warnings as occasionally '---help---'
is used instead of 'help' (and thus '-' is recognized as an unhandled
character), we need to handle '---help---' separately.
Andreas Ruprecht (2):
kconfig: warn of unhandled characters in Kconfig commands
kconfig: Regenerate shipped zconf.{hash,lex}.c files
scripts/kconfig/zconf.gperf | 1 +
scripts/kconfig/zconf.hash.c_shipped | 58 +
scripts/kconfig/zconf.l | 18 --
scripts/kconfig/zconf.lex.c_shipped | 120 +++
4 files changed, 110 insertions(+), 87 deletions(-)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] trivial: fix typos and remove double words
- to to - when when Signed-off-by: Cristian Stoica --- Documentation/PCI/pci.txt | 2 +- Documentation/RCU/lockdep.txt | 4 ++-- Documentation/cpu-freq/cpu-drivers.txt| 2 +- arch/arc/mm/cache.c | 2 +- arch/arm/mach-davinci/cp_intc.c | 2 +- arch/ia64/kernel/acpi.c | 2 +- arch/powerpc/sysdev/ppc4xx_cpm.c | 2 +- arch/x86/kvm/paging_tmpl.h| 2 +- arch/x86/mm/pgtable.c | 2 +- drivers/block/cciss.c | 2 +- drivers/block/cciss_cmd.h | 2 +- drivers/clk/bcm/clk-kona-setup.c | 2 +- drivers/crypto/n2_core.c | 2 +- drivers/dma/ep93xx_dma.c | 2 +- drivers/gpu/drm/i915/intel_panel.c| 2 +- drivers/gpu/drm/vmwgfx/svga_reg.h | 2 +- drivers/i2c/busses/Kconfig| 2 +- drivers/i2c/busses/i2c-cros-ec-tunnel.c | 4 ++-- drivers/i2c/busses/i2c-viperboard.c | 2 +- drivers/infiniband/hw/qib/qib_pcie.c | 2 +- drivers/input/mouse/hgpk.c| 2 +- drivers/md/dm-cache-policy-mq.c | 2 +- drivers/mmc/core/host.c | 2 +- drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c | 2 +- drivers/net/ethernet/chelsio/cxgb4vf/sge.c| 2 +- drivers/net/ethernet/intel/e1000/e1000_hw.c | 2 +- drivers/net/wireless/ath/ath10k/mac.c | 2 +- drivers/net/wireless/ath/ath10k/testmode.c| 4 ++-- drivers/net/wireless/ath/ath9k/hw.h | 2 +- drivers/net/wireless/brcm80211/brcmsmac/types.h | 4 ++-- drivers/net/wireless/iwlwifi/dvm/lib.c| 2 +- drivers/net/wireless/iwlwifi/mvm/d3.c | 2 +- drivers/net/wireless/iwlwifi/mvm/fw-api-power.h | 2 +- drivers/ps3/ps3-lpm.c | 2 +- drivers/scsi/hpsa.c | 2 +- drivers/scsi/mpt2sas/mpt2sas_base.h | 2 +- drivers/scsi/mpt2sas/mpt2sas_transport.c | 2 +- drivers/scsi/mpt3sas/mpt3sas_base.h | 2 +- drivers/scsi/mpt3sas/mpt3sas_transport.c | 2 +- drivers/scsi/snic/snic_debugfs.c | 2 +- drivers/staging/lustre/lustre/include/cl_object.h | 2 +- drivers/staging/lustre/lustre/libcfs/hash.c | 2 +- drivers/staging/wilc1000/host_interface.c | 2 +- drivers/usb/host/uhci-grlib.c | 2 +- drivers/usb/host/uhci-platform.c | 2 +- fs/btrfs/ioctl.c | 2 +- fs/ocfs2/refcounttree.c | 2 +- fs/xfs/xfs_trans_ail.c| 2 +- include/linux/cpufreq.h | 2 +- include/linux/mm.h| 2 +- net/mac80211/sta_info.h | 4 ++-- net/netlink/genetlink.c | 2 +- net/tipc/msg.c| 2 +- sound/soc/tegra/tegra20_das.h | 4 ++-- tools/perf/Documentation/perf-script-perl.txt | 2 +- tools/perf/Documentation/perf-script-python.txt | 2 +- tools/perf/util/event.h | 2 +- tools/testing/ktest/sample.conf | 2 +- tools/testing/selftests/ftrace/test.d/ftrace/func_profiler.tc | 2 +- 59 files changed, 65 insertions(+), 65 deletions(-) diff --git a/Documentation/PCI/pci.txt b/Documentation/PCI/pci.txt index 123881f..e93e4b1 100644 --- a/Documentation/PCI/pci.txt +++ b/Documentation/PCI/pci.txt @@ -266,7 +266,7 @@ NOTE: pci_enable_device() can fail! Check the return value. [ OS BUG: we don't check resource allocations before enabling those resources. The sequence would make more sense if we called pci_request_resources() before calling pci_enable_device(). - Currently, the device drivers can't detect the bug when when two + Currently, the device drivers can't detect the bug when two devices have been allocated the same range. This is not a common problem and unlikely to get fixed soon. diff --git a/Documentation/RCU/lockdep.txt b/Documentation/RCU/lock
Re: [PATCH v5 2/6] arch: unify ioremap prototypes and macro aliases
On Tue, Jul 7, 2015 at 12:13 PM, Russell King - ARM Linux
wrote:
> Another issue is... the use of memcpy()/memset() directly on memory
> returned from ioremap*(). The pmem driver does this. This fails sparse
> checks. However, years ago, x86 invented the memcpy_fromio()/memcpy_toio()
> memset_io() functions, which took a __iomem pointer (which /presumably/
> means they're supposed to operate on the memory associated with an
> ioremap'd region.)
>
> Should these functions always be used for mappings via ioremap*(), and
> the standard memcpy()/memset() be avoided? To me, that sounds like a
> very good thing, because that gives us more control over the
> implementation of the functions used to access ioremap'd regions,
> and the arch can decide to prevent GCC inlining its own memset() or
> memcpy() code if desired.
Yes they should. Not doing that is a typical portability bug (works on x86,
not everywhere).
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] thermal: cpu_cooling: Iterate over all CPUs in clip_cpu mask to get frequency table
On 01-07-15, 12:13, Pi-Cheng Chen wrote:
> Sorry for the mistake I made when cherry-picking the patch. Fix and resend
> again.
You really want above to show up in git logs ?
Any comments like this should be present:
- in cover-letter
- OR after the three dashes below ---
- OR must be followed with a scissors line, like this:
--8<
> __cpufreq_cooling_register() might fail if some CPU other than first one in
> clip_cpu mask is present earlier e.g. CPU hotplug. Iterate all CPUs in the
> mask
> to handle this case.
>
> Signed-off-by: Pi-Cheng Chen
> ---
> drivers/thermal/cpu_cooling.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index 6509c61..5e90eb6 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -776,9 +776,14 @@ __cpufreq_cooling_register(struct device_node *np,
> char dev_name[THERMAL_NAME_LENGTH];
> struct cpufreq_frequency_table *pos, *table;
> unsigned int freq, i, num_cpus;
> - int ret;
> + int ret, cpu;
> +
> + for_each_cpu(cpu, clip_cpus) {
> + table = cpufreq_frequency_get_table(cpu);
> + if (table)
> + break;
> + }
>
> - table = cpufreq_frequency_get_table(cpumask_first(clip_cpus));
Nah, that's wrong. I hope that's a hypothetical problem and not a real
one. Would have been better if cpufreq maintainers were cc'd as they
can provide more insight into this :)
cpufreq_frequency_get_table() does: policy->freq_table and so it
doesn't matter if the cpu is online or not.
cpufreq_cpu_data was getting unset earlier on hotplug, but that's not
the case anymore. So nothing to worry about :)
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Notebook does not resume from hibernation
On Mon 2015-07-06 20:13:45, Markus Weyermann wrote: > Pavel > > I just verified: > > 3.19.0-18 does resume as well from "Bereitschaft" (probably standby) as > from "Ruhezustand" (hibernation). > > 4.0.4-040004 does resume from standby but not from hibernation. Ok, can you unload the Realtek/Ralink stuff and try hibernation? Otherwise its Intel graphics, pretty boring stuff. Is bisect an option? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] suspend: delete sys_sync()
On Mon 2015-07-06 15:59:15, Rafael J. Wysocki wrote: > On Monday, July 06, 2015 01:06:45 PM Pavel Machek wrote: > > On Mon 2015-07-06 01:28:20, Rafael J. Wysocki wrote: > > > On Saturday, July 04, 2015 10:19:55 AM Alan Stern wrote: > > > > On Sat, 4 Jul 2015, Rafael J. Wysocki wrote: > > > > > > > > > The only argument against dropping sys_sync() from the suspend code > > > > > path > > > > > I've seen in this thread that I entirely agree with is that it may > > > > > lead to > > > > > regressions, because we've done it practically forever and it may > > > > > hide latent > > > > > bugs somewhere in block drivers etc. Dropping it, though, is the > > > > > only way > > > > > to see those bugs, if any, and if we want to ever fix them, we need > > > > > to see > > > > > them. That's why I think that it may be a good idea to allow people > > > > > to > > > > > drop it if they are willing to accept some extra risk (via the kernel > > > > > command line, for example). > > > > > > > > I'd be perfectly happy to have the sync selectable at runtime, one way > > > > or another. The three most reasonable options seem to be: > > > > > > > > kernel command line > > > > > > > > sysfs file > > > > > > > > sysctl setting > > > > > > > > The command line is less flexible (it can't be changed after booting). > > > > Either of the other two would be fine with me. > > > > > > We'll probably use a sysfs file (possibly plus a Kconfig option to set the > > > boot time default). > > > > Android people can already do sync-less s2ram using existing > > interface. IMO they should just do it. > > > > In any case, sysfs file + Kconfig is an overkill. We already have too > > many Kconfig options. > > I don't think we can reach a general agreement on what's the *right* approach > with respect to the sys_sync() in the suspend code path, so the only way out > of this situation I can see is to make it configurable. So first: not having general agreement does not mean we should introduce Kconfig + sysfs file. Second: your proposal of "lets sync if runtime was shorter than xxx" is over complex, but at least should not need Kconfig support... Third: we have ioctl() based interface, and I guess android should use that one; it already has "s2ram without sync" method. > > There's not a single Android phone supported by mainline > > kernel. I'm sure they have bigger problems than Android setting > > default sysfs values... > > But perhaps we'd like to change that? We'd like to, but lets start with the real hard stuff (merging support for Qualcomm chipsets) that is 100 LoC+, not with trivial tweaks that would be 1-line change, but we pollute code with Kconfig+sysfs making it 100.. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clocksource: Allow toggling between runtime and persistent clocksource for idle
* John Stultz [150706 10:53]: > On Mon, Jul 6, 2015 at 8:46 AM, Thomas Gleixner wrote: > > On Mon, 6 Jul 2015, Tony Lindgren wrote: > >> * Thomas Gleixner [150706 07:20]: > >> > On Mon, 6 Jul 2015, Tony Lindgren wrote: > >> The timekeeping accuracy issue certainly needs some thinking, and > >> also the resolution between the clocksources can be different.. In the > >> test case I have the slow timer is always on and of a lower resolution > >> than the ARM global timer being used during runtime. > >> > >> Got some handy timer test in mind you want me to run to provide data > >> on the accuracy? > > > > John Stultz might have something. > > You can turn on ntp stats in your ntp.conf and chart the loopstats > data w/ gnuplot: > > set terminal png > set output "loopstat.png" > plot "/var/log/ntpstats/loopstats." using 2:3 with linespoints > > > I also have the drift-log.py and graph-log.py scripts I use here: > https://github.com/johnstultz-work/timetests > > But those aren't really ready for mass consumption, as they're > probably not very cross-distro compatible. Great thanks, I'll play a bit with those to see how bad the jitter gets. Regrds, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature
> -Original Message- > From: Olaf Hering [mailto:o...@aepfle.de] > Sent: Tuesday, July 7, 2015 18:10 > To: Dexuan Cui; Paul Bolle > Cc: gre...@linuxfoundation.org; da...@davemloft.net; > net...@vger.kernel.org; linux-kernel@vger.kernel.org; driverdev- > de...@linuxdriverproject.org; a...@canonical.com; jasow...@redhat.com; KY > Srinivasan; Haiyang Zhang > Subject: Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature > > On Tue, Jul 07, Paul Bolle wrote: > > > On ma, 2015-07-06 at 07:47 -0700, Dexuan Cui wrote: > > > --- /dev/null > > > +++ b/net/hv_sock/Kconfig > > > > > +config HYPERV_SOCK > > > + tristate "Microsoft Hyper-V Socket (EXPERIMENTAL)" > > > + depends on HYPERV > > > + default m > > > It's a bit odd to advise to say N if one is unsure and set the default > > to 'm' at the same time. > > The 'default' line has to be removed IMO. > > Olaf OK, removing the line seems better than 'default n', though both reproduce the same "# CONFIG_HYPERV_SOCK is not set". -- Dexuan
Re: [PATCH v5 2/6] arch: unify ioremap prototypes and macro aliases
On Tue, Jul 07, 2015 at 11:50:12AM +0200, Luis R. Rodriguez wrote: > mcgrof@ergon ~/linux-next (git::kill-mtrr)$ git grep ioremap_nocache > drivers/| wc -l > 359 Yes, it's because we have: (a) LDD telling people they should be using ioremap_nocache() for mapping devices. (b) We have documentation in the Documentation/ subdirectory telling people to use ioremap_nocache() for the same. > This is part of the work I've been doing lately. The > eventual goal once we have the write-combing areas properly split with > ioremap_wc() and using the new proper preferred architecture agnostic modifier > (arch_phys_wc_add()) is to change the default ioremap behaviour on x86 to use > strong UC for PAT enabled systems for *both* ioremap() and ioremap_nocache(). Please note that on ARM, ioremap_wc() gives what's termed in ARM ARM speak "normal memory, non-cacheable" - which can be subject to speculation, write combining, multiple accesses, etc. The important point is that such mapping is not suitable for device registers, but is suitable for device regions that have "memory like" properties (iow, a chunk of RAM, like video drivers.) It does support unaligned accesses. > Because of these grammatical issues and the issues with > unaligned access with ARM I think its important we put some effort > to care a bit more about defining clear semantics through grammar > for new APIs or as we rewrite APIs. We have tools to do this these > days, best make use of them. I'm in support of anything which more clearly specifies the requirements for these APIs. > While we're at it and reconsidering all this, a few items I wish for > us to address as well then, most of them related to grammar, some > procedural clarification: > > * Document it as not supported to have overlapping ioremap() calls. > No one seems to have a clue if this should work, but clearly this > is just a bad idea. I don't see why we should support the complexity > of having this. It seems we can write grammar rules to prevent this. On ARM, we (probably) have a lot of cases where ioremap() is used multiple times for the same physical address space, so we shouldn't rule out having multiple mappings of the same type. However, differing types would be a problem on ARM. > * We seem to care about device drivers / kernel code doing unaligned > accesses with certain ioremap() variants. At least for ARM you should > not do unaligned accesses on ioremap_nocache() areas. ... and ioremap() areas. If we can stop the "abuse" of ioremap_nocache() to map device registers, then we could potentially switch ioremap_nocache() to be a normal-memory like mapping, which would allow it to support unaligned accesses. > I am not sure > if we can come up with grammar to vet for / warn for unaligned access > type of code in driver code on some memory area when some ioremap() > variant is used, but this could be looked into. I believe we may > want rules for unaligned access maybe in general, and not attached > to certain calls due to performance considerations, so this work > may be welcomed regardless (refer to > Documentation/unaligned-memory-access.txt) > > * We seem to want to be pedantic about adding new ioremap() variants, the > unaligned issue on ARM is one reason, do we ideally then want *all* > architecture maintainers to provide an Acked-by for any new ioremap > variants ? /If/ we get the current mess sorted out so that we have a safe fallback, and we have understanding of the different architecture variants (iow, documented what the safe fallback is) I don't see any reason why we'd need acks from arch maintainers. Unfortunately, we're not in that situation today, because of the poorly documented mess that ioremap*() currently is (and yes, I'm partly to blame for that too by not documenting ARMs behaviour here.) I have some patches (prepared last week, I was going to push them out towards the end of the merge window) which address that, but unfortunately the ARM autobuilders have been giving a number of seemingly random boot failures, and I'm not yet sure what's going on... so I'm holding that back until stuff has settled down. Another issue is... the use of memcpy()/memset() directly on memory returned from ioremap*(). The pmem driver does this. This fails sparse checks. However, years ago, x86 invented the memcpy_fromio()/memcpy_toio() memset_io() functions, which took a __iomem pointer (which /presumably/ means they're supposed to operate on the memory associated with an ioremap'd region.) Should these functions always be used for mappings via ioremap*(), and the standard memcpy()/memset() be avoided? To me, that sounds like a very good thing, because that gives us more control over the implementation of the functions used to access ioremap'd regions, and the arch can decide to prevent GCC inlining its own memset() or memcpy() code if desired. Note that on x86, these three func
[RFC PATCH v3 4/4] trace: Trace log handler for logging into STM blocks
Add the function 'trace_event_stm_output_##call' for printing events
trace log into STM blocks.
This patch also adds a function call at where the events have been
committed to ring buffer to export the trace event information to
STM blocks.
Signed-off-by: Chunyan Zhang
---
include/linux/trace_events.h | 8
include/trace/perf.h | 3 +++
include/trace/trace_events.h | 44
3 files changed, 55 insertions(+)
diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
index 28dcdff..705bd4e 100644
--- a/include/linux/trace_events.h
+++ b/include/linux/trace_events.h
@@ -418,6 +418,14 @@ enum event_trigger_type {
#ifdef CONFIG_STM_TRACE_EVENT
extern void stm_trace_event_write(const char *buf, unsigned len);
+extern void trace_event_stm_log(struct trace_event_buffer *buffer);
+extern void trace_event_buf_vprintf(struct trace_buffer_stm *tb,
+ const char *fmt, ...) __attribute__ ((weak));
+#else
+static inline void trace_event_stm_log(struct trace_event_buffer *buffer) {}
+static inline void trace_event_buf_vprintf(struct trace_buffer_stm *tb,
+ const char *fmt, ...) {}
+
#endif
extern int filter_match_preds(struct event_filter *filter, void *rec);
diff --git a/include/trace/perf.h b/include/trace/perf.h
index 1b5443c..79906de 100644
--- a/include/trace/perf.h
+++ b/include/trace/perf.h
@@ -175,6 +175,7 @@ trace_event_raw_event_##call(void *__data, proto)
\
{ assign; } \
\
trace_event_buffer_commit(&fbuffer);\
+ trace_event_stm_log(&fbuffer); \
}
/*
* The ftrace_test_probe is compiled out, it is only here as a build time check
@@ -234,6 +235,7 @@ static struct trace_event_call __used event_##call = {
\
.event.funcs= &trace_event_type_funcs_##template, \
.print_fmt = print_fmt_##template, \
.flags = TRACE_EVENT_FL_TRACEPOINT,\
+ .output_stm = trace_event_stm_output_##template,\
}; \
static struct trace_event_call __used \
__attribute__((section("_ftrace_events"))) *__event_##call = &event_##call
@@ -251,6 +253,7 @@ static struct trace_event_call __used event_##call = {
\
.event.funcs= &trace_event_type_funcs_##call, \
.print_fmt = print_fmt_##call, \
.flags = TRACE_EVENT_FL_TRACEPOINT,\
+ .output_stm = trace_event_stm_output_##call,\
}; \
static struct trace_event_call __used \
__attribute__((section("_ftrace_events"))) *__event_##call = &event_##call
diff --git a/include/trace/trace_events.h b/include/trace/trace_events.h
index 43be3b0..db4d8a7 100644
--- a/include/trace/trace_events.h
+++ b/include/trace/trace_events.h
@@ -303,6 +303,50 @@ TRACE_MAKE_SYSTEM_STR();
#undef DECLARE_EVENT_CLASS
#define DECLARE_EVENT_CLASS(call, proto, args, tstruct, assign, print) \
+static notrace void\
+trace_event_stm_output_##call(struct trace_seq *tmp_seq, \
+void *entry, \
+struct trace_buffer_stm *trace_buf)\
+{ \
+ struct trace_event_raw_##call *field = entry; \
+ struct trace_seq *p = tmp_seq; \
+ \
+ trace_seq_init(p); \
+ \
+ trace_event_buf_vprintf(trace_buf, print); \
+ \
+ return; \
+}
+
+#undef DEFINE_EVENT_PRINT
+#define DEFINE_EVENT_PRINT(template, call, proto, args, print) \
+static notrace void\
+trace_event_stm_output_##call(struct trace_seq *tmp_seq, \
+void *entry, \
+struct trace_buffer_stm *trace_buf)\
+{ \
+ struct trace_seq *p = tmp_seq; \
+ st
[RFC PATCH v3 1/4] STM trace event: Adding generic buffer interface driver
From: Mathieu Poirier
This patch adds a driver that models itself as an stm_source and
who's sole purpose is to export an interface to the rest of the
kernel. Once the stm and stm_source have been linked via sysfs,
everything that is passed to the interface will endup in the STM
trace engine.
Signed-off-by: Mathieu Poirier
Signed-off-by: Chunyan Zhang
---
drivers/stm/Kconfig | 11 +++
drivers/stm/Makefile | 2 ++
drivers/stm/stm_trace_event.c | 46 +++
3 files changed, 59 insertions(+)
create mode 100644 drivers/stm/stm_trace_event.c
diff --git a/drivers/stm/Kconfig b/drivers/stm/Kconfig
index 6f2db70..8ead418 100644
--- a/drivers/stm/Kconfig
+++ b/drivers/stm/Kconfig
@@ -25,3 +25,14 @@ config STM_SOURCE_CONSOLE
If you want to send kernel console messages over STM devices,
say Y.
+
+config STM_TRACE_EVENT
+ tristate "Redirect/copy the output from kernel trace event to STM
engine"
+ depends on STM
+ help
+ This option can be used to redirect or copy the output from kernel
trace
+ event to STM engine. Enabling this option will introduce a slight
+ timing effect.
+
+ If you want to send kernel trace event messages over STM devices,
+ say Y.
diff --git a/drivers/stm/Makefile b/drivers/stm/Makefile
index 74baf59..55b152c 100644
--- a/drivers/stm/Makefile
+++ b/drivers/stm/Makefile
@@ -5,3 +5,5 @@ stm_core-y := core.o policy.o
obj-$(CONFIG_STM_DUMMY)+= dummy_stm.o
obj-$(CONFIG_STM_SOURCE_CONSOLE) += console.o
+
+obj-$(CONFIG_STM_TRACE_EVENT) += stm_trace_event.o
diff --git a/drivers/stm/stm_trace_event.c b/drivers/stm/stm_trace_event.c
new file mode 100644
index 000..bc77dae
--- /dev/null
+++ b/drivers/stm/stm_trace_event.c
@@ -0,0 +1,46 @@
+/*
+ * Simple kernel driver to link kernel trace event and an STM device
+ * Copyright (c) 2015, Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+static struct stm_source_data stm_trace_event_data = {
+ .name = "stm_trace_event",
+ .nr_chans = 1,
+};
+
+void stm_trace_event_write(const char *buf, unsigned len)
+{
+ stm_source_write(&stm_trace_event_data, 0, buf, len);
+}
+
+static int __init stm_trace_event_init(void)
+{
+ return stm_source_register_device(NULL, &stm_trace_event_data);
+}
+
+static void __exit stm_trace_event_exit(void)
+{
+ stm_source_unregister_device(&stm_trace_event_data);
+}
+
+module_init(stm_trace_event_init);
+module_exit(stm_trace_event_exit);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("stm_trace_event driver");
+MODULE_AUTHOR("Mathieu Poirier ");
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v3 0/4] Integration of trace events with System Trace IP blocks
IP blocks allowing a variety of trace sources to log debugging information to a pre-defined area have been introduced on a couple of architecture [1][2]. These system trace blocks (also known as STM) typically follow the MIPI STPv2 protocol [3] and provide a system wide logging facility to any device, running a kernel or not, with access to the block's log entry port(s). Since each trace message has a timestamp is it possible to correlate events happening in the entire system rather than being confined to the logging facility of a single entity. This patch is using a very simple "stm_source" introduced in [2] to duplicate the output of the trace event subsystem to an STM, in this case coresight STM. That way logging information generated by the trace event subsystem and gathered in the coresight sink can be used in conjunction with trace data from other board components, also collected in the same trace sink. This example is using coresight but the same would apply to any architecture wishing to do the same. The goal of this RFC is to solicit comments on the method used to connect trace event logging with STMs (using the generic STM API) rather than function "stm_ftrace_write()" itself, which was provided for completeness of the proof of concept only. I'm eager to see your comments on this, and if you have some good ideas that can slow down the overhead, please let me know. Any questions are also welcome. Thanks, Chunyan [1]. https://lkml.org/lkml/2015/2/4/729 [2]. http://comments.gmane.org/gmane.linux.kernel/1914526 [3]. http://mipi.org/specifications/debug#STP Changes from RFC v2: - Revised some types and variable's name according to the code of v4.2-rc1 - Sorted this patch-set based on the v4.2-rc1 - Splited the patch 2/3 of my last patch-set to make code can be compiled after each patch is applied in order. Changes from RFC v1: - Marked module init/exit functions with __init/__exit key word according to the comments from Paul Bolle Chunyan Zhang (3): trace: Add an entry for printing trace log to STM trace: Introduce trace log output function for STM trace: Trace log handler for logging into STM blocks Mathieu Poirier (1): STM trace event: Adding generic buffer interface driver drivers/stm/Kconfig | 11 + drivers/stm/Makefile| 2 + drivers/stm/stm_trace_event.c | 46 +++ include/linux/trace_events.h| 16 +++ include/trace/perf.h| 3 ++ include/trace/trace_events.h| 44 ++ kernel/trace/Makefile | 1 + kernel/trace/trace_output_stm.c | 99 + 8 files changed, 222 insertions(+) create mode 100644 drivers/stm/stm_trace_event.c create mode 100644 kernel/trace/trace_output_stm.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v3 3/4] trace: Introduce trace log output function for STM
This patch introduced a few functions to print the event trace log to
STM buffer when the trace event happened and the event information
was committed to ring buffer.
Before outputting the trace log to STM, we have to get the human readable
trace log content and print it into a local buffer in the format of a
string, the function 'trace_event_buf_vprintf()' is just for this purpose.
Signed-off-by: Chunyan Zhang
---
kernel/trace/Makefile | 1 +
kernel/trace/trace_output_stm.c | 99 +
2 files changed, 100 insertions(+)
create mode 100644 kernel/trace/trace_output_stm.c
diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile
index 9b1044e..002de34 100644
--- a/kernel/trace/Makefile
+++ b/kernel/trace/Makefile
@@ -67,4 +67,5 @@ obj-$(CONFIG_UPROBE_EVENT) += trace_uprobe.o
obj-$(CONFIG_TRACEPOINT_BENCHMARK) += trace_benchmark.o
+obj-$(CONFIG_STM_TRACE_EVENT) += trace_output_stm.o
libftrace-y := ftrace.o
diff --git a/kernel/trace/trace_output_stm.c b/kernel/trace/trace_output_stm.c
new file mode 100644
index 000..689c6d5
--- /dev/null
+++ b/kernel/trace/trace_output_stm.c
@@ -0,0 +1,99 @@
+#include
+#include
+#include
+#include "trace.h"
+
+#define STM_OUTPUT_STRLEN 128
+
+/* store the event trace log for STM */
+struct trace_buffer_stm {
+ char buffer[STM_OUTPUT_STRLEN];
+ unsigned int used_len;
+ unsigned int size;
+};
+
+static struct trace_buffer_stm *trace_event_stm_buffer;
+static struct trace_seq *stm_tmp_seq;
+static int stm_buffers_allocated;
+
+void trace_event_buf_vprintf(struct trace_buffer_stm *tb, const char *fmt, ...)
+{
+ va_list ap;
+ char *buffer = tb->buffer + tb->used_len;
+ unsigned int size = tb->size - tb->used_len;
+
+ va_start(ap, fmt);
+ tb->used_len += vsnprintf(buffer, size, fmt, ap);
+ va_end(ap);
+}
+EXPORT_SYMBOL_GPL(trace_event_buf_vprintf);
+
+static inline void stm_buf_reset(struct trace_buffer_stm *tb)
+{
+ tb->used_len = 0;
+}
+
+void trace_event_stm_log(struct trace_event_buffer *buffer)
+{
+
+ struct trace_seq *p = stm_tmp_seq;
+ struct trace_buffer_stm *tb;
+ struct trace_event_call *event_call = buffer->trace_file->event_call;
+ struct trace_entry *entry = (struct trace_entry *)buffer->entry;
+
+ if (!stm_buffers_allocated)
+ return;
+
+ tb = trace_event_stm_buffer;
+
+ if (event_call->output_stm)
+ event_call->output_stm(p, entry, tb);
+
+ stm_trace_event_write(tb->buffer, tb->used_len);
+
+ stm_buf_reset(tb);
+}
+EXPORT_SYMBOL_GPL(trace_event_stm_log);
+
+static int alloc_stm_tmp_seq(void)
+{
+ struct trace_seq *seq;
+
+ seq = kzalloc(sizeof(struct trace_seq), GFP_KERNEL);
+ if (!seq)
+ return -ENOMEM;
+
+ stm_tmp_seq = seq;
+
+ return 0;
+}
+
+static int alloc_stm_trace_buffer(void)
+{
+ struct trace_buffer_stm *buffer;
+
+ buffer = kzalloc(sizeof(struct trace_buffer_stm), GFP_KERNEL);
+ if (!buffer)
+ return -ENOMEM;
+
+ buffer->used_len = 0;
+ buffer->size = ARRAY_SIZE(buffer->buffer);
+
+ trace_event_stm_buffer = buffer;
+
+ return 0;
+}
+
+static __init int trace_stm_init_buffers(void)
+{
+ if (alloc_stm_trace_buffer())
+ return -ENOMEM;
+
+ if (alloc_stm_tmp_seq())
+ return -ENOMEM;
+
+ stm_buffers_allocated = 1;
+
+ return 0;
+}
+fs_initcall(trace_stm_init_buffers);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v3 2/4] trace: Add an entry for printing trace log to STM
output_stm is a link which is used to connect trace event
logging with STMs, will be used in the upcoming patches.
Signed-off-by: Chunyan Zhang
---
include/linux/trace_events.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/linux/trace_events.h b/include/linux/trace_events.h
index 1063c85..28dcdff 100644
--- a/include/linux/trace_events.h
+++ b/include/linux/trace_events.h
@@ -14,6 +14,7 @@ struct trace_buffer;
struct tracer;
struct dentry;
struct bpf_prog;
+struct trace_buffer_stm;
struct trace_print_flags {
unsigned long mask;
@@ -293,6 +294,9 @@ struct trace_event_call {
*/
int flags; /* static flags of different events */
+ void (*output_stm)(struct trace_seq *tmp_seq, void *entry,
+ struct trace_buffer_stm *tb);
+
#ifdef CONFIG_PERF_EVENTS
int perf_refcount;
struct hlist_head __percpu *perf_events;
@@ -412,6 +416,10 @@ enum event_trigger_type {
ETT_EVENT_ENABLE= (1 << 3),
};
+#ifdef CONFIG_STM_TRACE_EVENT
+extern void stm_trace_event_write(const char *buf, unsigned len);
+#endif
+
extern int filter_match_preds(struct event_filter *filter, void *rec);
extern int filter_check_discard(struct trace_event_file *file, void *rec,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] hvsock: introduce Hyper-V VM Sockets feature
On Tue, Jul 07, Paul Bolle wrote: > On ma, 2015-07-06 at 07:47 -0700, Dexuan Cui wrote: > > --- /dev/null > > +++ b/net/hv_sock/Kconfig > > > +config HYPERV_SOCK > > + tristate "Microsoft Hyper-V Socket (EXPERIMENTAL)" > > + depends on HYPERV > > + default m > It's a bit odd to advise to say N if one is unsure and set the default > to 'm' at the same time. The 'default' line has to be removed IMO. Olaf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] amba: Support clk parents and rates assigned in DT
On 2015/7/7 17:33, Russell King - ARM Linux wrote: On Tue, Jul 07, 2015 at 04:47:33PM +0800, Bintian wrote: Hi Russell, Could you spend several minutes to review Stephen's patch? Sorry, I'm busy this week, I need to sort out my git tree, get some fixes out which should've been pushed during the merge window, and other stuff. I'm not going to have much time to read email, let alone do reviews. Please be patient. No problem, just keep your own pace. Thanks, Bintian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] megaraid:Remove no longer required variable ret from the function megasas_sync_map_info
Can't seem to find the original, so here's a reply to the ack mail.
On Tue, Jul 7, 2015 at 10:49 AM, Sumit Saxena
wrote:
> -Original Message-
> From: Nicholas Krause [mailto:xerofo...@gmail.com]
> Sent: Monday, July 06, 2015 9:43 PM
> To: kashyap.de...@avagotech.com
> Cc: sumit.sax...@avagotech.com; uday.ling...@avagotech.com;
> jbottom...@odin.com; megaraidlinux@avagotech.com;
> linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [PATCH] megaraid:Remove no longer required variable ret from the
> function megasas_sync_map_info
Isn't something shorter like
[PATCH] megaraid: remove pointless variable
much more readable?
> This removes the no longer required variable ret due to this variable only
> ever being used at the end of the function megasas_sync_map_info without
> changing it's value from the orginal setting of its value to zero due to
> this just remove the variable ret and just return the value of zero
> directly here in order to indicate to the caller the call to this function
> has run successfully without any non recoverable issues.
No interpunction?
> Signed-off-by: Nicholas Krause
> ---
> drivers/scsi/megaraid/megaraid_sas_fusion.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> index 46a0f8f..b5a8c65 100644
> --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
> +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
> @@ -836,7 +836,7 @@ megasas_get_map_info(struct megasas_instance
> *instance) int megasas_sync_map_info(struct megasas_instance *instance)
> {
> - int ret = 0, i;
> + int i;
> struct megasas_cmd *cmd;
> struct megasas_dcmd_frame *dcmd;
> u32 size_sync_info, num_lds;
> @@ -906,7 +906,7 @@ megasas_sync_map_info(struct megasas_instance
> *instance)
>
> instance->instancet->issue_dcmd(instance, cmd);
>
> - return ret;
> + return 0;
> }
>
> Acked-by: Sumit Saxena
This ack in an outlook-style response confused the hell out of me ;).
Thanks,
Frans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.2-rc1 v21 3/6] irqchip: gic: Introduce plumbing for IPI FIQ
> Currently it is not possible to exploit FIQ for systems with a GIC, even > on systems are otherwise capable of it. This patch makes it possible > for IPIs to be delivered using FIQ. I wonder if gic_set_group_irq() can easily be married with mxc_set_irq_fiq(). The driver sound/soc/fsl/imx-pcm-fiq.c uses mxc_set_irq_fiq() to connect an (assembly) FIQ handler with a hardware IRQ. However, the underlying implementation of mxc_set_irq_fiq() is only supported for TZIC and AVIC (see arch/arm/mach-imx/irq-common.c). On my i.MX6, which doesn't have an AVIC/TZIC but a GIC I could use a method to turn a normal IRQ into a FIQ :-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dmaengine: xgene-dma: Fix the resource map to handle overlapping
There is an overlap in dma ring cmd csr region due to sharing of ethernet
ring cmd csr region. This patch fix the resource overlapping by mapping
the entire dma ring cmd csr region.
Signed-off-by: Rameshwar Prasad Sahu
---
Documentation/devicetree/bindings/dma/apm-xgene-dma.txt | 2 +-
arch/arm64/boot/dts/apm/apm-storm.dtsi | 2 +-
drivers/dma/xgene-dma.c | 3 +++
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
b/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
index d305876..c53e0b0 100644
--- a/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
+++ b/Documentation/devicetree/bindings/dma/apm-xgene-dma.txt
@@ -35,7 +35,7 @@ Example:
device_type = "dma";
reg = <0x0 0x1f27 0x0 0x1>,
<0x0 0x1f20 0x0 0x1>,
- <0x0 0x1b008000 0x0 0x2000>,
+ <0x0 0x1b00 0x0 0x40>,
<0x0 0x1054a000 0x0 0x100>;
interrupts = <0x0 0x82 0x4>,
<0x0 0xb8 0x4>,
diff --git a/arch/arm64/boot/dts/apm/apm-storm.dtsi
b/arch/arm64/boot/dts/apm/apm-storm.dtsi
index 0689c3f..58093ed 100644
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@ -823,7 +823,7 @@
device_type = "dma";
reg = <0x0 0x1f27 0x0 0x1>,
<0x0 0x1f20 0x0 0x1>,
- <0x0 0x1b008000 0x0 0x2000>,
+ <0x0 0x1b00 0x0 0x40>,
<0x0 0x1054a000 0x0 0x100>;
interrupts = <0x0 0x82 0x4>,
<0x0 0xb8 0x4>,
diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c
index 620fd55ec..dff22ab 100644
--- a/drivers/dma/xgene-dma.c
+++ b/drivers/dma/xgene-dma.c
@@ -111,6 +111,7 @@
#define XGENE_DMA_MEM_RAM_SHUTDOWN 0xD070
#define XGENE_DMA_BLK_MEM_RDY 0xD074
#define XGENE_DMA_BLK_MEM_RDY_VAL 0x
+#define XGENE_DMA_RING_CMD_SM_OFFSET 0x8000
/* X-Gene SoC EFUSE csr register and bit defination */
#define XGENE_SOC_JTAG1_SHADOW 0x18
@@ -1887,6 +1888,8 @@ static int xgene_dma_get_resources(struct platform_device
*pdev,
return -ENOMEM;
}
+ pdma->csr_ring_cmd += XGENE_DMA_RING_CMD_SM_OFFSET;
+
/* Get efuse csr region */
res = platform_get_resource(pdev, IORESOURCE_MEM, 3);
if (!res) {
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] KVM: api: add kvm_irq_routing_extended_msi
Good morning Pavel,
On 07/07/15 08:16, Pavel Fedin wrote:
> Hello!
>
>> Wouldn't:
>> if (kvm_vm_check_extension(s, KVM_CAP_MSI_DEVID)) {
>> kroute.flags = KVM_MSI_VALID_DEVID;
>> kroute.u.msi.devid = (pci_bus_num(dev->bus) << 8) | dev->devfn;
>> }
>>
>> be saner (without a global variable)?
>
> No it would not, because:
> a) kvm_vm_check_extension() calls ioctl every time, therefore it's slow. But,
> well, doesn't really
> matter because it's possible to check for the capability once in generic
> code, and cache it.
Indeed, as mentioned before I have it in a wrapper function with a
static variable.
> b) Capability is a global thing as far as i understand. The kernel either has
> it, or doesn't have.
There are two flavours of capabilities: global and per-VM ones,
depending on which fd you are issuing the ioctl. The per-VM ones are
just not very widely used yet (I only found PowerPC doing so).
> However, whether we want this flag or not, depends also on what GIC model we
> use. GICv2(m) doesn't
> want it, GICv3 does. qemu actually has two sets of flags: one set actually
> specifies capabilities,
> another set enables use of these capabilities.
That's why I do a per-VM capability check and I do it as late as
possible to let the GIC initialize first (hence the wrapper function).
> But, well, you can make GICv2 kernel code simply ignoring it instead of
> bailing out if flags != 0.
> And add the capability for ARM64 architecture (ARM32 can't use GICv3, can
> it?). And this will work
> and it'll be OK. So, i'm not against it, and if you want it, you can do it. I
> just want to point
> that it is not strictly necessary to add new APIs, because existing ones are
> pretty much enough.
As said before I don't like the idea of inferring the validity of a flag
by some hard-coded dependencies like "GICv3 on ARM64". I guess ARM(32)
will get GICv3 support sooner or later (I think I saw patches to do so
already). So as soon as a kernel supports it, we automatically get the
support from userland without changing a single line there. Also what
tells you that no other architecture or IRQ controller will ever need a
device ID? I just don't want to end up with something like:
(GICV3 && ARM64) || (GICV3 && ARM && KERNEL>4.4) || (SuperIRQC && i986)
or
(ARM || ARM64) && HAS_IRQ_ROUTING
Instead: If the kernel needs it, it tells you. Full stop.
> But, you are the architects here, so you of course can do it if you want.
> It's just me being not a
> big fan of adding APIs without which it's completely possible to live.
>
> Below i'm answering to Eric's comment, because my reply is tightly coupled
> with this one.
>
>> So not sure whether we eventually concluded;-)
>> - introduce a KVM_CAP_MSI_DEVID capability? All OK except Pavel not
>> convinced?
>
> See above. I'm not against it, i just don't think it's necessary. You can do
> it if you want, it
> actually won't change things much.
>
>> - userspaces puts the devid in struct kvm_irq_routing_msi pad field:
>> consensus (we do not intrduce a new kvm_irq_routing_ext_msi)
>
> Yes.
>
>> - userspace tells it conveyed a devid by setting
>> A) the kvm_irq_routing_entry's field?
>> B) the kvm_irq_routing_entry's type
>> no consensus. If there is a cap, does it really matter?
>
> It has absolutely nothing to do with the cap. My argument here is the same
> as above again - why
> adding new API's / definitions? We already have KVM_MSI_VALID_DEVID and we
> already have 'flags'
> field. Using them would just make the API more consistent because
> KVM_SIGNAL_MSI already uses them
> in absolutely the same manner. That's my point and nothing more.
To be honest it's me to blame here to not having introduced the
capability earlier. At the moment ARM has a different code path for
KVM_SIGNAL_MSI, which does not bail out if the flag field is set. With
Eric's patches this changes and we use the irqchip.c generic code, which
returns -EINVAL atm. So I plan to introduce this capability already with
the ITS emulation series, so we can just pick it up in the IRQ routing
series.
So we now have already two users of this, if that makes more sense.
Cheers,
Andre.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: pca953x: Fix warning when HW interrupts are rescheduled by the softirq tasklet
Hi Christian,
On 07/07/2015 09:29 AM, Christian Gmeiner wrote:
> Hi all
>
> 2014-09-26 11:07 GMT+02:00 Linus Walleij :
>> On Thu, Sep 25, 2014 at 6:26 PM, Grygorii Strashko
>> wrote:
>>> On 09/25/2014 11:07 AM, Linus Walleij wrote:
On Wed, Sep 24, 2014 at 2:28 PM, Grygorii Strashko
wrote:
> On 09/24/2014 02:17 PM, Linus Walleij wrote:
>> So PCA cannot use gpiochip_set_chained_irqchip()?
>
> Yes. It can't - pca is i2c device.
? I don't get this statement.
Why does the fact that it is an I2C device matter?
We have several devices that are in fact on top of
I2C (albeit as MFD cells) like gpio-tc3589x.c.
>>>
>>> gpio-tc3589x.c doesn't call gpiochip_set_chained_irqchip()
>>
>> Ah yeah you're right of course. I considered adding a separate
>> registration function for the sleeping handlers, like
>> gpiochip_set_threaded_irqchip() that would handle
>> setting up the nested case.
>>
Yes, but the .map function isn't called until a client
wants to use an IRQ. And that won't happen until after
we exit the whole .probe() function.
>>>
>>> .map function is called from irq_create_mapping() which,
>>> in turn, can be called as from irq_domain_add_simple() -
>>> as result .map will be always called from gpiochip_irqchip_add().
>>
>> Ah yeah you're right, I was just wrong here :-/
>>
Well it happens in one single driver, and was done by me.
Maybe I should either disallow that, as that means we're adding
multiple parents (which is what you want, right?) or actually
implement it in a way so that multiple parents can be handled
by the helpers, by adding the parents to a list or something.
>>>
>>> Sorry, but It seems the simplest way is to allow drivers to manage
>>> parent IRQs for the complex cases. So, I vote for custom .map()
>>> callback, but It could be not too simple to implement it, because
>>> private driver data need to be passed as parameter to this callback
>>> somehow.
>>
>> Yeah. Well what I'm thinking as subsystem maintainer, is that
>> when I added the generic GPIOlib irqchip helpers we managed to
>> smoke out a large:ish set of subtle bugs that different drivers
>> had created independently of each other.
>>
>> So centralizing code is very important if at all possible to bring
>> down the maintainer burden.
>>
>> So for that reason I'm looking a second and a third time at these
>> things before going ahead with custom code in drivers...
>>
>>> === Simple one - driver need to set parent_irq before adding gpiochip ===
>>>
>>> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
>>> index 8aa84d5..292840b 100644
>>> --- a/drivers/gpio/gpiolib.c
>>> +++ b/drivers/gpio/gpiolib.c
>>> @@ -447,8 +447,11 @@ static int gpiochip_irq_map(struct irq_domain *d,
>>> unsigned int irq,
>>> irq_set_lockdep_class(irq, &gpiochip_irq_lock_class);
>>> irq_set_chip_and_handler(irq, chip->irqchip, chip->irq_handler);
>>> /* Chips that can sleep need nested thread handlers */
>>> - if (chip->can_sleep)
>>> + if (chip->can_sleep) {
>>> irq_set_nested_thread(irq, 1);
>>> + if (chip->parent_irq)
>>> + irq_set_parent(irq, chip->parent_irq);
>>> + }
>>
>> Yeah I need to think of something like this...
>>
>
> I did run into exact the same situation with a 4.1.1 kernel :)
>
> [ 312.863047] [ cut here ]
> [ 312.867681] WARNING: CPU: 1 PID: 12 at kernel/irq/manage.c:696
> irq_nested_primary_handler+0x30/0x38()
> [ 312.876901] Primary handler called for nested irq 301
> [ 312.881953] Modules linked in: uinput ipv6 smsc95xx usbnet mii
> imx2_wdt etnaviv(C) matrix_keypad matrix_keymap ar1021_i2c
> [ 312.893067] CPU: 1 PID: 12 Comm: ksoftirqd/1 Tainted: GWC
> 4.1.1 #9
> [ 312.900378] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [ 312.906906] Backtrace:
> [ 312.909377] [] (dump_backtrace) from []
> (show_stack+0x20/0x24)
> [ 312.916947] r6:0009 r5: r4: r3:dc8ba301
> [ 312.922673] [] (show_stack) from []
> (dump_stack+0x70/0xc0)
> [ 312.929924] [] (dump_stack) from []
> (warn_slowpath_common+0x88/0xc0)
> [ 312.938029] r5:02b8 r4:
> [ 312.941678] [] (warn_slowpath_common) from []
> (warn_slowpath_fmt+0x40/0x48)
> [ 312.950391] r8: r7:c07b1314 r6:012d r5:eea07720 r4:c3048840
> [ 312.957233] [] (warn_slowpath_fmt) from []
> (irq_nested_primary_handler+0x30/0x38)
> [ 312.966467] r3:012d r2:c06b9128
> [ 312.970113] [] (irq_nested_primary_handler) from
> [] (handle_irq_event_percpu+0x70/0x2d0)
> [ 312.979967] [] (handle_irq_event_percpu) from
> [] (handle_irq_event+0x4c/0x6c)
> [ 312.988854] r10:0002 r9:0018 r8: r7:c07b1314
> r6:c3048840 r5:eea07720
> [ 312.996812] r4:eea076c0
> [ 312.999395] [] (handle_irq_event) from []
> (handle_simple_irq+0xa4/0xc8)
> [ 313.007760] r6:c07c5404 r5:eea07720 r4:eea076c
[tip:x86/urgent] x86/irq: Retrieve irq data after locking irq_desc
Commit-ID: 09cf92b784fae6109450c5d64f9908066d605249
Gitweb: http://git.kernel.org/tip/09cf92b784fae6109450c5d64f9908066d605249
Author: Thomas Gleixner
AuthorDate: Sun, 5 Jul 2015 17:12:35 +
Committer: Thomas Gleixner
CommitDate: Tue, 7 Jul 2015 11:54:04 +0200
x86/irq: Retrieve irq data after locking irq_desc
irq_data is protected by irq_desc->lock, so retrieving the irq chip
from irq_data outside the lock is racy vs. an concurrent update. Move
it into the lock held region.
While at it add a comment why the vector walk does not require
vector_lock.
Signed-off-by: Thomas Gleixner
Cc: Peter Zijlstra
Cc: xiao jin
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Yanmin Zhang
Link: http://lkml.kernel.org/r/20150705171102.331320...@linutronix.de
---
arch/x86/kernel/irq.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index 85ca76e..c7dfe1b 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -497,6 +497,11 @@ void fixup_irqs(void)
*/
mdelay(1);
+ /*
+* We can walk the vector array of this cpu without holding
+* vector_lock because the cpu is already marked !online, so
+* nothing else will touch it.
+*/
for (vector = FIRST_EXTERNAL_VECTOR; vector < NR_VECTORS; vector++) {
unsigned int irr;
@@ -508,9 +513,9 @@ void fixup_irqs(void)
irq = __this_cpu_read(vector_irq[vector]);
desc = irq_to_desc(irq);
+ raw_spin_lock(&desc->lock);
data = irq_desc_get_irq_data(desc);
chip = irq_data_get_irq_chip(data);
- raw_spin_lock(&desc->lock);
if (chip->irq_retrigger) {
chip->irq_retrigger(data);
__this_cpu_write(vector_irq[vector],
VECTOR_RETRIGGERED);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/urgent] x86/irq: Use proper locking in check_irq_vectors_for_cpu_disable()
Commit-ID: cbb24dc761d95fe39a7a122bb1b298e9604cae15
Gitweb: http://git.kernel.org/tip/cbb24dc761d95fe39a7a122bb1b298e9604cae15
Author: Thomas Gleixner
AuthorDate: Sun, 5 Jul 2015 17:12:33 +
Committer: Thomas Gleixner
CommitDate: Tue, 7 Jul 2015 11:54:04 +0200
x86/irq: Use proper locking in check_irq_vectors_for_cpu_disable()
It's unsafe to examine fields in the irq descriptor w/o holding the
descriptor lock. Add proper locking.
While at it add a comment why the vector check can run lock less
Signed-off-by: Thomas Gleixner
Cc: Peter Zijlstra
Cc: xiao jin
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Yanmin Zhang
Link: http://lkml.kernel.org/r/20150705171102.236544...@linutronix.de
---
arch/x86/kernel/irq.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index 88b36648..85ca76e 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -347,14 +347,22 @@ int check_irq_vectors_for_cpu_disable(void)
if (!desc)
continue;
+ /*
+* Protect against concurrent action removal,
+* affinity changes etc.
+*/
+ raw_spin_lock(&desc->lock);
data = irq_desc_get_irq_data(desc);
cpumask_copy(&affinity_new, data->affinity);
cpumask_clear_cpu(this_cpu, &affinity_new);
/* Do not count inactive or per-cpu irqs. */
- if (!irq_has_action(irq) || irqd_is_per_cpu(data))
+ if (!irq_has_action(irq) || irqd_is_per_cpu(data)) {
+ raw_spin_unlock(&desc->lock);
continue;
+ }
+ raw_spin_unlock(&desc->lock);
/*
* A single irq may be mapped to multiple
* cpu's vector_irq[] (for example IOAPIC cluster
@@ -385,6 +393,9 @@ int check_irq_vectors_for_cpu_disable(void)
* vector. If the vector is marked in the used vectors
* bitmap or an irq is assigned to it, we don't count
* it as available.
+*
+* As this is an inaccurate snapshot anyway, we can do
+* this w/o holding vector_lock.
*/
for (vector = FIRST_EXTERNAL_VECTOR;
vector < first_system_vector; vector++) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/urgent] x86/irq: Plug irq vector hotplug race
Commit-ID: 5a3f75e3f02836518ce49536e9c460ca8e1fa290
Gitweb: http://git.kernel.org/tip/5a3f75e3f02836518ce49536e9c460ca8e1fa290
Author: Thomas Gleixner
AuthorDate: Sun, 5 Jul 2015 17:12:32 +
Committer: Thomas Gleixner
CommitDate: Tue, 7 Jul 2015 11:54:04 +0200
x86/irq: Plug irq vector hotplug race
Jin debugged a nasty cpu hotplug race which results in leaking a irq
vector on the newly hotplugged cpu.
cpu N cpu M
native_cpu_up device_shutdown
do_boot_cpu free_msi_irqs
start_secondary arch_teardown_msi_irqs
smp_callindefault_teardown_msi_irqs
setup_vector_irq arch_teardown_msi_irq
__setup_vector_irq native_teardown_msi_irq
lock(vector_lock) destroy_irq
install vectors
unlock(vector_lock)
lock(vector_lock)
---> __clear_irq_vector
unlock(vector_lock)
lock(vector_lock)
set_cpu_online
unlock(vector_lock)
This leaves the irq vector(s) which are torn down on CPU M stale in
the vector array of CPU N, because CPU M does not see CPU N online
yet. There is a similar issue with concurrent newly setup interrupts.
The alloc/free protection of irq descriptors does not prevent the
above race, because it merily prevents interrupt descriptors from
going away or changing concurrently.
Prevent this by moving the call to setup_vector_irq() into the
vector_lock held region which protects set_cpu_online():
cpu N cpu M
native_cpu_up device_shutdown
do_boot_cpu free_msi_irqs
start_secondary arch_teardown_msi_irqs
smp_callindefault_teardown_msi_irqs
lock(vector_lock)arch_teardown_msi_irq
setup_vector_irq()
__setup_vector_irq native_teardown_msi_irq
install vectorsdestroy_irq
set_cpu_online
unlock(vector_lock)
lock(vector_lock)
__clear_irq_vector
unlock(vector_lock)
So cpu M either sees the cpu N online before clearing the vector or
cpu N installs the vectors after cpu M has cleared it.
Reported-by: xiao jin
Signed-off-by: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Yanmin Zhang
Link: http://lkml.kernel.org/r/20150705171102.141898...@linutronix.de
---
arch/x86/kernel/apic/vector.c | 10 ++
arch/x86/kernel/smpboot.c | 13 +
2 files changed, 7 insertions(+), 16 deletions(-)
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 28eba2d..f813261 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -409,12 +409,6 @@ static void __setup_vector_irq(int cpu)
int irq, vector;
struct apic_chip_data *data;
- /*
-* vector_lock will make sure that we don't run into irq vector
-* assignments that might be happening on another cpu in parallel,
-* while we setup our initial vector to irq mappings.
-*/
- raw_spin_lock(&vector_lock);
/* Mark the inuse vectors */
for_each_active_irq(irq) {
data = apic_chip_data(irq_get_irq_data(irq));
@@ -436,16 +430,16 @@ static void __setup_vector_irq(int cpu)
if (!cpumask_test_cpu(cpu, data->domain))
per_cpu(vector_irq, cpu)[vector] = VECTOR_UNDEFINED;
}
- raw_spin_unlock(&vector_lock);
}
/*
- * Setup the vector to irq mappings.
+ * Setup the vector to irq mappings. Must be called with vector_lock held.
*/
void setup_vector_irq(int cpu)
{
int irq;
+ lockdep_assert_held(&vector_lock);
/*
* On most of the platforms, legacy PIC delivers the interrupts on the
* boot cpu. But there are certain platforms where PIC interrupts are
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 0bd8c1d..d3010aa 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -171,11 +171,6 @@ static void smp_callin(void)
apic_ap_setup();
/*
-* Need to setup vector mappings before we enable interrupts.
-*/
- setup_vector_irq(smp_processor_id());
-
- /*
* Save our processor parameters. Note: this information
* is needed for clock calibration.
*/
@@ -239,11 +234,13 @@ static void notrace start_secondary(void *unused)
check_tsc_sync_target();
/*
-* We need to hold vector_lock so there the set of online cpus
-* does not change while we are assigning vectors to cpus. Holdin
Re: [PATCH 3/4] irqchip, gicv3: Implement Cavium ThunderX erratum 23154
Russell,
thanks for your comments.
On 06.07.15 11:48:12, Russell King - ARM Linux wrote:
> On Tue, Jun 30, 2015 at 04:14:02PM +0200, Robert Richter wrote:
> > +static u64 gic_read_iar_cavium_thunderx(void)
> > {
> > u64 irqstat;
> >
> > + asm volatile("nop;nop;nop;nop;");
> > + asm volatile("nop;nop;nop;nop;");
> > asm volatile("mrs_s %0, " __stringify(ICC_IAR1_EL1) : "=r" (irqstat));
> > + asm volatile("nop;nop;nop;nop;");
> > + mb();
>
> NAK. Please read the GCC manual for proper use of asm(). Even with
> "volatile" there, it doesn't stop GCC from inserting instructions
> between these.
>
> If you need an instruction sequence to be consecutive, then it _must_
> be one single asm().
I will update this section.
> There should also be a comment explaining why that code is necessary
> here. Please think about the future when you've forgotten why those
> nops are there. The kernel is a long term project, and it's important
> that people understand why things are coded the way they are so that
> the kernel can be properly maintained into the future.
I will add a comment to the code with a brief description. Would the
current text from the patch description including the erratum number
be sufficient for that?
Thanks,
-Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH-V5 3/4] mfd: 88pm800: Set default interrupt clear method
On Tuesday 07 July 2015 12:59 PM, Lee Jones wrote:
On Mon, 29 Jun 2015, Vaibhav Hiremath wrote:
As per the spec, bit 1 (INT_CLEAR_MODE) of reg addr 0xe
(page 0) controls the method of clearing interrupt
status of 88pm800 family of devices;
0: clear on read
1: clear on write
If pdata is not coming from board file, then set the
default irq clear method to "irq clear on write"
Also, as suggested by "Lee Jones" renaming variable field
to appropriate name.
Signed-off-by: Zhao Ye
Signed-off-by: Vaibhav Hiremath
---
drivers/mfd/88pm800.c | 15 ++-
include/linux/mfd/88pm80x.h | 10 --
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/mfd/88pm800.c b/drivers/mfd/88pm800.c
index d495737..66347be 100644
--- a/drivers/mfd/88pm800.c
+++ b/drivers/mfd/88pm800.c
@@ -374,7 +374,7 @@ static int device_irq_init_800(struct pm80x_chip *chip)
{
struct regmap *map = chip->regmap;
unsigned long flags = IRQF_ONESHOT;
- int data, mask, ret = -EINVAL;
+ int irq_clr_mode, mask, ret = -EINVAL;
if (!map || !chip->irq) {
dev_err(chip->dev, "incorrect parameters\n");
@@ -382,15 +382,16 @@ static int device_irq_init_800(struct pm80x_chip *chip)
}
/*
-* irq_mode defines the way of clearing interrupt. it's read-clear by
-* default.
+* irq_clr_on_wr defines the way of clearing interrupt by
+* read/write(0/1). It's read-clear by default.
*/
mask =
PM800_WAKEUP2_INV_INT | PM800_WAKEUP2_INT_CLEAR |
PM800_WAKEUP2_INT_MASK;
- data = PM800_WAKEUP2_INT_CLEAR;
- ret = regmap_update_bits(map, PM800_WAKEUP2, mask, data);
+ irq_clr_mode = chip->irq_clr_method == PM800_IRQ_CLR_ON_WRITE ?
+ PM800_WAKEUP2_INT_WRITE_CLEAR : PM800_WAKEUP2_INT_READ_CLEAR;
+ ret = regmap_update_bits(map, PM800_WAKEUP2, mask, irq_clr_mode);
What's stopping you just passing PM800_WAKEUP2_INT_WRITE_CLEAR or
PM800_WAKEUP2_INT_READ_CLEAR from pdata? Then you can use the value
directly without all of this faffing about.
regmap_update_bits(map, PM800_WAKEUP2, mask, pdata->irq_clr_mode);
Because "irq_clr_method" is of boolean type.
And macros which you are referring to is,
#define PM800_WAKEUP2_INT_READ_CLEAR(0 << 1)
#define PM800_WAKEUP2_INT_WRITE_CLEAR (1 << 1)
And also, I feel it is more cleaner approach with the current code as
register definition and userflag are maintained separately.
if (ret < 0)
goto out;
@@ -512,6 +513,7 @@ static int device_800_init(struct pm80x_chip *chip,
}
chip->regmap_irq_chip = &pm800_irq_chip;
+ chip->irq_clr_method = pdata->irq_clr_method;
ret = device_irq_init_800(chip);
if (ret < 0) {
@@ -564,6 +566,9 @@ static int pm800_probe(struct i2c_client *client,
pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
return -ENOMEM;
+
+ /* by default, set irq clear method on write */
+ pdata->irq_clr_method = PM800_IRQ_CLR_ON_WRITE;
}
ret = pm80x_init(client);
diff --git a/include/linux/mfd/88pm80x.h b/include/linux/mfd/88pm80x.h
index 8fcad63..648e01a 100644
--- a/include/linux/mfd/88pm80x.h
+++ b/include/linux/mfd/88pm80x.h
@@ -77,6 +77,8 @@ enum {
#define PM800_WAKEUP2 (0x0E)
#define PM800_WAKEUP2_INV_INT BIT(0)
#define PM800_WAKEUP2_INT_CLEAR BIT(1)
+#define PM800_WAKEUP2_INT_READ_CLEAR (0 << 1)
+#define PM800_WAKEUP2_INT_WRITE_CLEAR (1 << 1)
#define PM800_WAKEUP2_INT_MASKBIT(2)
#define PM800_POWER_UP_LOG(0x10)
@@ -300,7 +302,11 @@ struct pm80x_chip {
struct regmap_irq_chip_data *irq_data;
int type;
int irq;
- int irq_mode;
+
+#define PM800_IRQ_CLR_ON_READ 0
+#define PM800_IRQ_CLR_ON_WRITE 1
Defines in the middle of structs makes for ugly code.
Sorry, but kernel code is full of such implementations.
Infact it is right place in terms of readability.
If you still feel insist to fix it, please let me know whether you want
to submit V6 just for this. Or you will fix it while merging.
I am OK with anything here...
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2] dmaengine: imx-sdma: Add device to device support
This patch adds DEV_TO_DEV support for i.MX SDMA driver to support data
transfer between two peripheral FIFOs.
The per_2_per script requires two peripheral addresses and two DMA
requests, and it need to check the src addr and dst addr is in the SPBA
bus space or in the AIPS bus space.
Signed-off-by: Shengjiu Wang
---
changes in V2
- refine the sdma_set_watermarklevel_for_p2p(), add description.
- exchange the meaning of per_address, per_address2. per_address is dst_addr
per_address2 is src_addr, which is align with not p2p case.
drivers/dma/imx-sdma.c | 140 +++-
1 file changed, 128 insertions(+), 12 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 77b6aab..845f200 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
@@ -259,8 +260,9 @@ struct sdma_channel {
struct sdma_buffer_descriptor *bd;
dma_addr_t bd_phys;
unsigned intpc_from_device, pc_to_device;
+ unsigned intdevice_to_device;
unsigned long flags;
- dma_addr_t per_address;
+ dma_addr_t per_address, per_address2;
unsigned long event_mask[2];
unsigned long watermark_level;
u32 shp_addr, per_addr;
@@ -328,6 +330,8 @@ struct sdma_engine {
u32 script_number;
struct sdma_script_start_addrs *script_addrs;
const struct sdma_driver_data *drvdata;
+ u32 spba_start_addr;
+ u32 spba_end_addr;
};
static struct sdma_driver_data sdma_imx31 = {
@@ -705,6 +709,7 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
sdmac->pc_from_device = 0;
sdmac->pc_to_device = 0;
+ sdmac->device_to_device = 0;
switch (peripheral_type) {
case IMX_DMATYPE_MEMORY:
@@ -780,6 +785,7 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
sdmac->pc_from_device = per_2_emi;
sdmac->pc_to_device = emi_2_per;
+ sdmac->device_to_device = per_2_per;
}
static int sdma_load_context(struct sdma_channel *sdmac)
@@ -792,11 +798,12 @@ static int sdma_load_context(struct sdma_channel *sdmac)
int ret;
unsigned long flags;
- if (sdmac->direction == DMA_DEV_TO_MEM) {
+ if (sdmac->direction == DMA_DEV_TO_MEM)
load_address = sdmac->pc_from_device;
- } else {
+ else if (sdmac->direction == DMA_DEV_TO_DEV)
+ load_address = sdmac->device_to_device;
+ else
load_address = sdmac->pc_to_device;
- }
if (load_address < 0)
return load_address;
@@ -851,6 +858,84 @@ static int sdma_disable_channel(struct dma_chan *chan)
return 0;
}
+/*
+ * p_2_p watermark_level description
+ * BitsNameDescription
+ * 0-7 Lower WML Lower watermark level
+ * 8 PS 1: Pad Swallowing
+ * 0: No Pad Swallowing
+ * 9 PA 1: Pad Adding
+ * 0: No Pad Adding
+ * 10 SPDIF If this bit is set both source
+ * and destination are on SPBA
+ * 11 Source Bit(SP) 1: Source on SPBA
+ * 0: Source on AIPS
+ * 12 Destination Bit(DP) 1: Destination on SPBA
+ * 0: Destination on AIPS
+ * 13-15 - MUST BE 0
+ * 16-23 Higher WML HWML
+ * 24-27 N Total number of samples after
+ * which Pad adding/Swallowing
+ * must be done. It must be odd.
+ * 28 Lower WML Event(LWE)SDMA events reg to check for
+ * LWML event mask
+ * 0: LWE in EVENTS register
+ * 1: LWE in EVENTS2 register
+ * 29 Higher WML Event(HWE) SDMA events reg to check for
+ * HWML event mask
+ * 0: HWE in EVENTS register
+ * 1: HWE in EVENTS2 register
+ * 30 - MUST BE 0
+ * 31 CONT1: Amount of samples to be
+ *
Re: [PATCH v5 2/6] arch: unify ioremap prototypes and macro aliases
On Wed, Jul 01, 2015 at 09:28:28AM +0200, Christoph Hellwig wrote:
> On Wed, Jul 01, 2015 at 09:19:29AM +0200, Geert Uytterhoeven wrote:
> > >> So it would be the responsibility of the caller to fall back from
> > >> ioremap(..., CACHED) to ioremap(..., UNCACHED)?
> > >> I.e. all drivers using it should be changed...
> > >
> > > All of the zero users we currently have will need to be changed, yes.
> >
> > Good. Less work to convert all of these ;-)
>
> And I didn't have enough coffee yet. We of course have a few users of
> ioremap_cache(), and two implememantions but no users of ioremap_cached().
> Looks like the implementations can't even agree on the name.
Yies, that naming is icky... we also have quite a bit of ioremap_nocache()
users:
mcgrof@ergon ~/linux-next (git::kill-mtrr)$ git grep ioremap_nocache drivers/|
wc -l
359
On x86 the default ioremap() happens to map to ioremap_nocache() anyway as well.
This is on purpose, there is an ongoing effort to streamline ioremap_nocache()
for registers on the x86 front with the long term goal then of making PAT
strong UC the default preference for both ioremap() and ioremap_nocache() for
PAT enabled systems. This would prevent things like write-combining modifiers
from having any effect on the area. This comes with a small architectural
driver cost, it means all write-combining desired areas must be split out in
drivers properly. This is part of the work I've been doing lately. The
eventual goal once we have the write-combing areas properly split with
ioremap_wc() and using the new proper preferred architecture agnostic modifier
(arch_phys_wc_add()) is to change the default ioremap behaviour on x86 to use
strong UC for PAT enabled systems for *both* ioremap() and ioremap_nocache().
This was aleady done once but reverted later due to the regression issues on
video drivers not haveing the right ioremap_wc() calls. I'm finishing this
effort and am about a few patches away...
Once done and once things cool down we should go back and may consider flipping
the switch again to make strong UC default. For details refer to commit
de33c442ed2a465 ("x86 PAT: fix performance drop for glx, use UC minus
for ioremap(), ioremap_nocache() and pci_mmap_page_range()").
All this is fine in theory -- but Benjamin Herrenschmidt recently also
noted that on powerpc the write-combining may end up requiring each
register read/write with its own specific API. That is, we'd lose the
magic of having things being done behind the scenes, and that would
also mean tons of reads/writes may need to be converted over to be
explicit about write-combining preferences...
I will note that upon discussions it seems that the above requirement
may have been a slight mishap on not being explicit about our semantics
and requirements on ioremap() variants, technically it may be possible
that effectively PowerPC may not get any write-combining effects on
infiniband / networking / anything not doing write-combining on
userspace such as framebuffer... from what I gather that needs to
be fixed. Because of these grammatical issues and the issues with
unaligned access with ARM I think its important we put some effort
to care a bit more about defining clear semantics through grammar
for new APIs or as we rewrite APIs. We have tools to do this these
days, best make use of them.
While we're at it and reconsidering all this, a few items I wish for
us to address as well then, most of them related to grammar, some
procedural clarification:
* Document it as not supported to have overlapping ioremap() calls.
No one seems to have a clue if this should work, but clearly this
is just a bad idea. I don't see why we should support the complexity
of having this. It seems we can write grammar rules to prevent this.
* We seem to care about device drivers / kernel code doing unaligned
accesses with certain ioremap() variants. At least for ARM you should
not do unaligned accesses on ioremap_nocache() areas. I am not sure
if we can come up with grammar to vet for / warn for unaligned access
type of code in driver code on some memory area when some ioremap()
variant is used, but this could be looked into. I believe we may
want rules for unaligned access maybe in general, and not attached
to certain calls due to performance considerations, so this work
may be welcomed regardless (refer to
Documentation/unaligned-memory-access.txt)
* We seem to want to be pedantic about adding new ioremap() variants, the
unaligned issue on ARM is one reason, do we ideally then want *all*
architecture maintainers to provide an Acked-by for any new ioremap
variants ? Are we going to have to sit and wait for a kumbaya every time
a helper comes along to see how it all fits well for all architectures?
The asm-generic io.h seemed to have set in place the ability to let
architectures define things *when* they get to it, that seems like a much
more fair app
