Linux 4.0-rc2
So rc2 missed the usual Sunday afternoon timing, because I spent most of the weekend debugging an issue that happened on an old Mac Mini I have around, and I hate making even early -rc releases with problems on machines that I have direct access to. Even if it only affected old machines that actual developers are unlikely to have or at least use. Today I got the patch from Daniel Vetter to fix it, so instead of doing a Sunday evening rc2, it's a Tuesday morning one. Go get it. It works better for the delay. Other than that little one-liner i915 fix? Not much, actually. It's been a very quiet week, for being this early in the release process. Sure, 3.19-rc2 was even smaller, so it continues a trend, but that was the xmas week. I hope this low volume is just because the 4.0 merge window itself was somewhat calmer than most recent releases. But I suspect the real reason is that the driver and networking trees from GregKH and davem are pending, and didn't make rc2. We'll see. Anyway, the shortlog is appended, and testing is appreciated, Linus --- Adrian Hunter (2): perf tools: Fix pthread_attr_setaffinity_np build error perf tools: Fix probing for PERF_FLAG_FD_CLOEXEC flag Alex Deucher (6): drm/radeon: use drm_mode_vrefresh() rather than mode->vrefresh drm/radeon: disable mclk switching with 120hz+ monitors drm/radeon: dump full IB if we hit a packet error drm/radeon: fix 1 RB harvest config setup for TN/RL drm/radeon: fix atom aux payload size check for writes (v2) drm/radeon: only enable DP audio if the monitor supports it Antonio Ospite (1): HID: sony: Fix a WARNING shown when rmmod-ing the driver Ard Biesheuvel (1): arm64: crypto: increase AES interleave to 4x Arnd Bergmann (1): rtc: ds1685: fix ds1685_rtc_alarm_irq_enable build error Axel Lin (1): hwmon: (ads7828) Check return value of devm_regmap_init_i2c Boris Brezillon (2): drm: atmel-hlcdc: reset layer A2Q and UPDATE bits when disabling it drm: atmel-hlcdc: remove useless pm_runtime_put_sync in probe Boris Ostrovsky (2): x86/xen: Make sure X2APIC_ENABLE bit of MSR_IA32_APICBASE is not set x86/xen: Initialize cr4 shadow for 64-bit PV(H) guests Brian Norris (8): tools/thermal: tmon: add --target-temp parameter tools/thermal: tmon: add min/max macros tools/thermal: tmon: tui: don't hard-code dialog window size assumptions tools/thermal: tmon: fixup tui windowing calculations tools/thermal: tmon: add .gitignore tools/thermal: tmon: support cross-compiling tools/thermal: tmon: use pkg-config to determine library dependencies tools/thermal: tmon: silence 'set but not used' warnings Bruce Merry (1): perf bench: Fix order of arguments to memcpy_alloc_mem Catalin Marinas (2): arm64: Increase the swiotlb buffer size 64MB arm64: compat Fix siginfo_t -> compat_siginfo_t conversion on big endian Chanwoo Choi (1): thermal: exynos: Clean-up code to use oneline entry for exynos compatible table Chris Mason (1): Btrfs: fix allocation size calculations in alloc_btrfs_bio Chris Wilson (1): drm/i915: Check obj->vma_list under the struct_mutex Christian König (2): drm/radeon: enable SRBM timeout interrupt on SI drm/radeon: enable SRBM timeout interrupt on EG/NI Daniel Lezcano (1): clockevents: asm9260: Fix compilation error with sparc/sparc64 allyesconfig Daniel Vetter (3): drm: Fix deadlock due to getconnector locking changes drm/i915: Align initial plane backing objects correctly drm/i915: Fix modeset state confusion in the load detect code Darren Salt (1): HID: saitek: add USB ID for older R.A.T. 7 Dave Chinner (1): xfs: ensure truncate forces zeroed blocks to disk David Ahern (3): perf top: Fix SIGBUS on sparc64 perf symbols: Define EM_AARCH64 for older OSes perf tools: Make sparc64 arch point to sparc David Vrabel (1): x86/xen: allow privcmd hypercalls to be preempted Eric Mei (1): raid5: check faulty flag for array status during recovery. Eric Sandeen (2): xfs: Ensure we have target_ip for RENAME_EXCHANGE xfs: cancel failed transaction in xfs_fs_commit_blocks() Felipe Balbi (3): ARM: dts: am437x-idk: fix TPS62362 i2c bus ARM: omap2plus_defconfig: enable TPS62362 regulator ARM: dts: am437x-idk: fix sleep pinctrl state Feng Kan (1): arm64: enable PTE type bit in the mask for pte_modify Frank Praznik (1): HID: sony: fix uninitialized per-controller spinlock Geert Uytterhoeven (5): drivers: sh: Disable PM runtime for multi-platform r8a7740 with genpd thermal: rcar: Fix race condition between init and interrupt thermal: rcar: Make error and remove paths symmetrical with init ARM: multi_v7_defconfig: Enable shmobile platforms rtc: ds1685: remove superfluous checks for out-of-range u8 values
Re: [Patch] apple-gmux: lock iGP IO to protect from vgaarb changes
On Mon, Feb 23, 2015 at 09:51:55PM +0100, Bruno Prémont wrote:
> As GMUX depends on IO for iGP to be enabled and active, lock the IO at
> vgaarb level. This should prevent GPU driver for dGPU to disable IO for
> iGP while it tries to own legacy VGA IO.
>
> This fixes usage of backlight control combined with closed nvidia
> driver on some Apple dual-GPU (intel/nvidia) systems.
>
> On those systems loading nvidia driver disables intel IO decoding,
> disabling the gmux backlight controls as a side effect.
> Prior to commits moving boot_vga from (optional) efifb to less optional
> vgaarb this mis-behavior could be avoided by using right kernel config
> (efifb enabled but vgaarb disabled).
>
> This patch explicitly does not try to trigger vgaarb changes in order
> to avoid confusing already running graphics drivers. If IO has been
> mis-configured by vgaarb gmux will thus fail to probe.
> It is expected to load/probe gmux prior to graphics drivers.
>
> Fixes: ce027dac592c0ada241ce0f95ae65856828ac450 # nvidia interaction
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86121
> Reported-by: Petri Hodju
> Tested-by: Petri Hodju
> Cc: Bjorn Helgaas
> Cc: Matthew Garrett
> Signed-off-by: Bruno Prémont
Hi Bruno,
Only a minor nit below.
> ---
> drivers/platform/x86/apple-gmux.c | 43
> ++-
> 1 file changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/platform/x86/apple-gmux.c
> b/drivers/platform/x86/apple-gmux.c
> index b9429fb..22da6a3 100644
> --- a/drivers/platform/x86/apple-gmux.c
> +++ b/drivers/platform/x86/apple-gmux.c
...
> @@ -475,7 +494,7 @@ static int gmux_probe(struct pnp_dev *pnp, const struct
> pnp_device_id *id)
> ver_minor = (version >> 16) & 0xff;
> ver_release = (version >> 8) & 0xff;
> } else {
> - pr_info("gmux device not present\n");
> + pr_info("gmux device not present or IO disabled\n");
> ret = -ENODEV;
> goto err_release;
> }
> @@ -483,6 +502,22 @@ static int gmux_probe(struct pnp_dev *pnp, const struct
> pnp_device_id *id)
> pr_info("Found gmux version %d.%d.%d [%s]\n", ver_major, ver_minor,
> ver_release, (gmux_data->indexed ? "indexed" : "classic"));
>
> + /*
> + * Apple systems with gmux are EFI based and normally don't use
> + * VGA. In addition changing IO+MEM ownership between IGP and dGPU
> + * disables IO/MEM used for backlight control on some systems.
> + * Lock IO+MEM to GPU with active IO to prevent switch.
> + */
> + pdev = gmux_find_pdev();
> + if (pdev && vga_tryget(pdev,
> +VGA_RSRC_NORMAL_IO | VGA_RSRC_NORMAL_MEM)) {
> + pr_err("gmux boot_vga IO+MEM vgaarb-locking failed\n");
On this and the above, keep in mind the pr_fmt will already prefix this with
KBUILD_MODNAME, the "gmux" is probably redundant.
> + ret = -EBUSY;
> + goto err_release;
> + } else if (pdev)
> + pr_info("gmux: locked IO for PCI:%s\n", pci_name(pdev));
The driver uses pr_fmt, so no need to prefix with "gmux:"
--
Darren Hart
Intel Open Source Technology Center
--
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 PATCH] arm64: cmpxchg.h: Bring ldxr and stxr closer
On Tue, Mar 03, 2015 at 11:58:26AM -0500, Pranith Kumar wrote: > On Tue, Mar 3, 2015 at 9:34 AM, Catalin Marinas > wrote: > > Do you mean the cmpxchg_double() change? Becuase %w0 and %0 is the same > > physical register. You set it to 0 and immediately override it with > > ldxp. > > Thanks Catalin. I realized the blunder a while after Will pointed it > out. The asm here was a bit confusing. %0 usually refers to the first > input/output variable. But for ldxp instruction(which is just a > double-word load, not exclusive), it refers to the physical registers. OK, so please try not to touch any asm code until you understood (a) the AArch64 instruction set and (b) the gcc inline assembly syntax ;). > What about the changes in cmpxchg()? Why do we need to set %w0 to 0 > after the ldxrh instruction? Also, could you please point me to any > arm64 asm reference? "info gcc" for the inline assembly syntax and the ARMv8 ARM for the description of the AArch64 instruction set. It also helps if you look at the code generated by the compiler (e.g. objdump -d). -- Catalin -- 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] regulator: Only enable disabled regulators on resume
Javier,
On Mon, Mar 2, 2015 at 12:40 PM, Javier Martinez Canillas
wrote:
> After leaving from system wide suspend state, regulator_suspend_finish()
> turn on regulators that may be turned off by regulator_suspend_prepare()
> but it tries to enable all regulators that have an enable count > 0 or
> that were marked as "always-on" regardless if those were disabled or not.
>
> Trying to enable an already enabled regulator may cause issues so is
> better to skip enabling regulators that were not disabled before suspend.
>
> Signed-off-by: Javier Martinez Canillas
> ---
> drivers/regulator/core.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
I've tested this and it also fixes the problem that my patch
(regulator: core: Fix enable GPIO reference counting -
https://patchwork.kernel.org/patch/5903071) fixes.
As I said in the other conversation I think both patches could land.
...but maybe change your commit message to something like:
The _regulator_do_enable() call ought to be a no-op when called on an
already-enabled regulator. However, as an optimization
_regulator_enable() doesn't call _regulator_do_enable() on an already
enabled regulator. That means we never test the case of calling
_regulator_do_enable() during normal usage and there may be hidden
bugs or warnings. We have seen warnings issued by the tps65090 driver
and bugs when using the GPIO enable pin.
Let's match the same optimization that _regulator_enable() in
regulator_suspend_finish(). That may speed up suspend/resume and also
avoids exposing hidden bugs.
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index f2452148c8da..8551400d57e4 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -3816,9 +3816,11 @@ int regulator_suspend_finish(void)
> list_for_each_entry(rdev, ®ulator_list, list) {
> mutex_lock(&rdev->mutex);
> if (rdev->use_count > 0 || rdev->constraints->always_on) {
> - error = _regulator_do_enable(rdev);
> - if (error)
> - ret = error;
> + if (!_regulator_is_enabled(rdev)) {
Looking at _regulator_enable() I see that _regulator_is_enabled()
could return an error. Should we be checking? Maybe we should have a
helper function called by both callers?
I have tested this on my system and it works. Other than the error
check / updated commit message this looks good to me.
-Doug
--
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] i2c: designware: Suppress error message if platform_get_irq() returns -EPROBE_DEFER
> which omit this type of messages completely. Andy's proposal of > centralising this looks like a very good solution here (and on top of > that removes many useless strings from the kernel binary). I am all for centralizing printouts. I recommended this at my ELCE talk last year, too. However, you need to keep in mind that irqs are sometimes optional and you don't want error messages for those irqs. IMO worthwhile, but not a low hanging fruit... signature.asc Description: Digital signature
[PATCH] HID: wacom: ask for a in-prox report when it was missed
If noone listens to the input device when a tool comes in proximity,
the tablet does not send the in-prox event when a client becomes available.
That means that no events will be sent until the tool is taken out of
proximity.
In this situation, ask for the report WACOM_REPORT_INTUOSREAD which will
read the corresponding feature and generate an in-prox event.
We don't schedule this read while we are in an IO interrupt because we
know that usbhid will do it asynchronously. If this is triggered by uhid
then this is obviously a client side bug :)
Signed-off-by: Benjamin Tissoires
---
drivers/hid/wacom_wac.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index 9ec4545..ff9a7ab 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -430,6 +430,19 @@ exit:
return retval;
}
+static void wacom_intuos_schedule_prox_event(struct wacom_wac *wacom_wac)
+{
+ struct wacom *wacom = container_of(wacom_wac, struct wacom, wacom_wac);
+ struct hid_report *r;
+ struct hid_report_enum *re;
+
+ re = &(wacom->hdev->report_enum[HID_FEATURE_REPORT]);
+ r = re->report_id_hash[WACOM_REPORT_INTUOSREAD];
+ if (r) {
+ hid_hw_request(wacom->hdev, r, HID_REQ_GET_REPORT);
+ }
+}
+
static int wacom_intuos_inout(struct wacom_wac *wacom)
{
struct wacom_features *features = &wacom->features;
@@ -609,8 +622,11 @@ static int wacom_intuos_inout(struct wacom_wac *wacom)
}
/* don't report other events if we don't know the ID */
- if (!wacom->id[idx])
+ if (!wacom->id[idx]) {
+ /* but reschedule a read of the current tool */
+ wacom_intuos_schedule_prox_event(wacom);
return 1;
+ }
return 0;
}
--
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 11/14] tools build: Move feature checks code under tools/build
On 3/3/15 7:26 AM, Jiri Olsa wrote: Moving feature checks code under tools/build directory. How does a specific tool specify which features are of interest? I can't imagine all features for perf are wanted by other tools. David Changing also $feature_dir to point to new feature directory location and perf Makefiles to include Makefile.feature from new location. Signed-off-by: Jiri Olsa Cc: Arnaldo Carvalho de Melo Cc: Corey Ashford Cc: David Ahern Cc: Ingo Molnar Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra --- tools/build/Makefile.feature | 171 + tools/build/feature/.gitignore | 2 + tools/build/feature/Makefile | 159 +++ tools/build/feature/test-all.c | 136 tools/build/feature/test-backtrace.c | 13 ++ tools/build/feature/test-bionic.c | 6 + tools/build/feature/test-compile.c | 4 + tools/build/feature/test-cplus-demangle.c | 14 ++ tools/build/feature/test-dwarf.c | 10 ++ tools/build/feature/test-fortify-source.c | 6 + tools/build/feature/test-glibc.c | 8 + tools/build/feature/test-gtk2-infobar.c| 11 ++ tools/build/feature/test-gtk2.c| 10 ++ tools/build/feature/test-hello.c | 6 + tools/build/feature/test-libaudit.c| 10 ++ tools/build/feature/test-libbabeltrace.c | 8 + tools/build/feature/test-libbfd.c | 15 ++ tools/build/feature/test-libdw-dwarf-unwind.c | 13 ++ tools/build/feature/test-libelf-getphdrnum.c | 8 + tools/build/feature/test-libelf-mmap.c | 8 + tools/build/feature/test-libelf.c | 8 + tools/build/feature/test-libnuma.c | 9 ++ tools/build/feature/test-libperl.c | 9 ++ tools/build/feature/test-libpython-version.c | 10 ++ tools/build/feature/test-libpython.c | 8 + tools/build/feature/test-libslang.c| 6 + tools/build/feature/test-libunwind-debug-frame.c | 16 ++ tools/build/feature/test-libunwind.c | 27 .../feature/test-pthread-attr-setaffinity-np.c | 17 ++ tools/build/feature/test-stackprotector-all.c | 6 + tools/build/feature/test-sync-compare-and-swap.c | 14 ++ tools/build/feature/test-timerfd.c | 18 +++ tools/build/feature/test-zlib.c| 9 ++ tools/perf/Makefile.perf | 2 +- tools/perf/config/Makefile | 2 +- tools/perf/config/Makefile.feature | 171 - tools/perf/config/feature-checks/.gitignore| 2 - tools/perf/config/feature-checks/Makefile | 159 --- tools/perf/config/feature-checks/test-all.c| 136 tools/perf/config/feature-checks/test-backtrace.c | 13 -- tools/perf/config/feature-checks/test-bionic.c | 6 - tools/perf/config/feature-checks/test-compile.c| 4 - .../config/feature-checks/test-cplus-demangle.c| 14 -- tools/perf/config/feature-checks/test-dwarf.c | 10 -- .../config/feature-checks/test-fortify-source.c| 6 - tools/perf/config/feature-checks/test-glibc.c | 8 - .../perf/config/feature-checks/test-gtk2-infobar.c | 11 -- tools/perf/config/feature-checks/test-gtk2.c | 10 -- tools/perf/config/feature-checks/test-hello.c | 6 - tools/perf/config/feature-checks/test-libaudit.c | 10 -- .../config/feature-checks/test-libbabeltrace.c | 8 - tools/perf/config/feature-checks/test-libbfd.c | 15 -- .../feature-checks/test-libdw-dwarf-unwind.c | 13 -- .../config/feature-checks/test-libelf-getphdrnum.c | 8 - .../perf/config/feature-checks/test-libelf-mmap.c | 8 - tools/perf/config/feature-checks/test-libelf.c | 8 - tools/perf/config/feature-checks/test-libnuma.c| 9 -- tools/perf/config/feature-checks/test-libperl.c| 9 -- .../config/feature-checks/test-libpython-version.c | 10 -- tools/perf/config/feature-checks/test-libpython.c | 8 - tools/perf/config/feature-checks/test-libslang.c | 6 - .../feature-checks/test-libunwind-debug-frame.c| 16 -- tools/perf/config/feature-checks/test-libunwind.c | 27 .../test-pthread-attr-setaffinity-np.c | 17 -- .../feature-checks/test-stackprotector-all.c | 6 - .../feature-checks/test-sync-compare-and-swap.c| 14 -- tools/perf/config/feature-checks/test-timerfd.c| 18 --- tools/perf/config/feature-checks/test-zlib.c | 9 -- 68 files changed, 777 insertions(+), 777 deletions(-) create mode 100644 tools/build/Makefile.feature create mode 100644 tools/build/feature/.gitignore
Re: [Debug 0/2] Fix regressions caused by commit 593669c2ac0f
On 03.03.2015 05:34, Dave Airlie wrote: > On 3 March 2015 at 14:25, Jiang Liu wrote: >> Commit 593669c2ac0f (x86/PCI/ACPI: Use common ACPI resource interfaces >> to simplify implementation) causes regression to several platforms, >> which is caused by stricter checks in new ACPI resource parsing code >> and BIOSes report incorrect ACPI resource descriptors. So try to relax >> the check to avoid regressions. >> >> Jiang Liu (2): >> x86/PCI/ACPI: Ignore resources consumed by host bridge itself >> x86/PCI/ACPI: Relax ACPI resource descriptor checks to work around >> BIOS bugs > > I've booted my machine with that lost its r8169 and it appears to be > working now. > > So from the regression POV: > Tested-by: Dave Airlie Works for me, as well. Thanks! Tested-by: Prakash Punnoor Regards, Prakash -- 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 tip/core/rcu 1/5] rcu: Provide rcu_expedite_gp() and rcu_unexpedite_gp()
From: "Paul E. McKenney"
Currently, expediting of normal synchronous grace-period primitives
(synchronize_rcu() and friends) is controlled by the rcu_expedited()
boot/sysfs parameter. This works well, but does not handle nesting.
This commit therefore provides rcu_expedite_gp() to enable expediting
and rcu_unexpedite_gp() to cancel a prior rcu_expedite_gp(), both of
which support nesting.
Reported-by: Arjan van de Ven
Signed-off-by: Paul E. McKenney
---
include/linux/rcupdate.h | 20
kernel/rcu/update.c | 48
2 files changed, 68 insertions(+)
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 78097491cd99..57a4d1f73a00 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -48,6 +48,26 @@
extern int rcu_expedited; /* for sysctl */
+#ifdef CONFIG_TINY_RCU
+/* Tiny RCU doesn't expedite, as its purpose in life is instead to be tiny. */
+static inline bool rcu_gp_is_expedited(void) /* Internal RCU use. */
+{
+ return false;
+}
+
+static inline void rcu_expedite_gp(void)
+{
+}
+
+static inline void rcu_unexpedite_gp(void)
+{
+}
+#else /* #ifdef CONFIG_TINY_RCU */
+bool rcu_gp_is_expedited(void); /* Internal RCU use. */
+void rcu_expedite_gp(void);
+void rcu_unexpedite_gp(void);
+#endif /* #else #ifdef CONFIG_TINY_RCU */
+
enum rcutorture_type {
RCU_FLAVOR,
RCU_BH_FLAVOR,
diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
index e0d31a345ee6..5f850823c187 100644
--- a/kernel/rcu/update.c
+++ b/kernel/rcu/update.c
@@ -62,6 +62,54 @@ MODULE_ALIAS("rcupdate");
module_param(rcu_expedited, int, 0);
+#ifndef CONFIG_TINY_RCU
+
+static atomic_t rcu_expedited_nesting;
+
+/*
+ * Should normal grace-period primitives be expedited? Intended for
+ * use within RCU. Note that this function takes the rcu_expedited
+ * sysfs/boot variable into account as well as the rcu_expedite_gp()
+ * nesting. So looping on rcu_unexpedite_gp() until rcu_gp_is_expedited()
+ * returns false is a -really- bad idea.
+ */
+bool rcu_gp_is_expedited(void)
+{
+ return rcu_expedited || atomic_read(&rcu_expedited_nesting);
+}
+EXPORT_SYMBOL_GPL(rcu_gp_is_expedited);
+
+/**
+ * rcu_expedite_gp - Expedite future RCU grace periods
+ *
+ * After a call to this function, future calls to synchronize_rcu() and
+ * friends act as the corresponding synchronize_rcu_expedited() function
+ * had instead been called.
+ */
+void rcu_expedite_gp(void)
+{
+ atomic_inc(&rcu_expedited_nesting);
+}
+EXPORT_SYMBOL_GPL(rcu_expedite_gp);
+
+/**
+ * rcu_unexpedite_gp - Cancel prior rcu_expedite_gp() invocation
+ *
+ * Undo a prior call to rcu_expedite_gp(). If all prior calls to
+ * rcu_expedite_gp() are undone by a subsequent call to rcu_unexpedite_gp(),
+ * and if the rcu_expedited sysfs/boot parameter is not set, then all
+ * subsequent calls to synchronize_rcu() and friends will return to
+ * their normal non-expedited behavior.
+ */
+void rcu_unexpedite_gp(void)
+{
+ atomic_dec(&rcu_expedited_nesting);
+}
+EXPORT_SYMBOL_GPL(rcu_unexpedite_gp);
+
+#endif /* #ifndef CONFIG_TINY_RCU */
+
+
#ifdef CONFIG_PREEMPT_RCU
/*
--
1.8.1.5
--
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 tip/core/rcu 3/5] rcu: Update from rcu_expedited variable to rcu_gp_is_expedited()
From: "Paul E. McKenney"
This commit updates open-coded tests of the rcu_expedited variable
to instead use rcu_gp_is_expedited().
Signed-off-by: Paul E. McKenney
---
kernel/rcu/srcu.c| 2 +-
kernel/rcu/tree.c| 9 +
kernel/rcu/tree_plugin.h | 2 +-
3 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/kernel/rcu/srcu.c b/kernel/rcu/srcu.c
index 445bf8ffe3fb..c871f07eff69 100644
--- a/kernel/rcu/srcu.c
+++ b/kernel/rcu/srcu.c
@@ -507,7 +507,7 @@ static void __synchronize_srcu(struct srcu_struct *sp, int
trycount)
*/
void synchronize_srcu(struct srcu_struct *sp)
{
- __synchronize_srcu(sp, rcu_expedited
+ __synchronize_srcu(sp, rcu_gp_is_expedited()
? SYNCHRONIZE_SRCU_EXP_TRYCOUNT
: SYNCHRONIZE_SRCU_TRYCOUNT);
}
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 48d640ca1a05..4325fbe79d84 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2954,7 +2954,7 @@ void synchronize_sched(void)
"Illegal synchronize_sched() in RCU-sched read-side
critical section");
if (rcu_blocking_is_gp())
return;
- if (rcu_expedited)
+ if (rcu_gp_is_expedited())
synchronize_sched_expedited();
else
wait_rcu_gp(call_rcu_sched);
@@ -2981,7 +2981,7 @@ void synchronize_rcu_bh(void)
"Illegal synchronize_rcu_bh() in RCU-bh read-side
critical section");
if (rcu_blocking_is_gp())
return;
- if (rcu_expedited)
+ if (rcu_gp_is_expedited())
synchronize_rcu_bh_expedited();
else
wait_rcu_gp(call_rcu_bh);
@@ -3660,11 +3660,12 @@ static int rcu_pm_notify(struct notifier_block *self,
case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
if (nr_cpu_ids <= 256) /* Expediting bad for large systems. */
- rcu_expedited = 1;
+ rcu_expedite_gp();
break;
case PM_POST_HIBERNATION:
case PM_POST_SUSPEND:
- rcu_expedited = 0;
+ if (nr_cpu_ids <= 256) /* Expediting bad for large systems. */
+ rcu_unexpedite_gp();
break;
default:
break;
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 0a571e9a0f1d..63726b734d34 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -585,7 +585,7 @@ void synchronize_rcu(void)
"Illegal synchronize_rcu() in RCU read-side critical
section");
if (!rcu_scheduler_active)
return;
- if (rcu_expedited)
+ if (rcu_gp_is_expedited())
synchronize_rcu_expedited();
else
wait_rcu_gp(call_rcu);
--
1.8.1.5
--
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] sched,rt,nohz: stop scheduler tick if running realtime task
On Mon, Feb 16, 2015 at 03:23:49PM -0500, Rik van Riel wrote:
> If the CPU is running a realtime task that does not round-robin with
> another realtime task of equal priority, there is no point in keeping
> the scheduler tick going. After all, whenever the scheduler tick runs,
> the kernel will just decide not to reschedule.
>
> Extend sched_can_stop_tick to recognize these situations, and inform
> the rest of the kernel that the scheduler tick can be stopped.
>
> Signed-off-by: Rik van Riel
> Tested-by: Luiz Capitulino
> ---
> kernel/sched/core.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index ade2958a9197..ad985a632c4d 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -745,6 +745,22 @@ static inline bool got_nohz_idle_kick(void)
> bool sched_can_stop_tick(void)
> {
> /*
> + * FIFO realtime policy runs the highest priority task. Other runnable
> + * tasks are of a lower priority. The scheduler tick does nothing.
> + */
> + if (current->policy == SCHED_FIFO)
> + return true;
> +
> + /*
> + * Round-robin realtime tasks time slice with other tasks at the same
> + * realtime priority. Is this task the only one at this priority?
> + */
> + if (current->policy == SCHED_RR) {
> + struct sched_rt_entity *rt_se = ¤t->rt;
> + return rt_se->run_list.prev == rt_se->run_list.next;
> + }
> +
> + /*
I think it should work yes.
There are still many things, that the tick updates, which are broken without it
(rq->rt_avg is supposed to be updated avery tick for example) but it goes way
beyond
the scope of this change since SCHED_FIFO tasks are already allowed to stop the
tick
when no SCHED_OTHER task is running so the problem is there already before this
patch.
So it's a welcome fix, thanks.
>* More than one running task need preemption.
>* nr_running update is assumed to be visible
>* after IPI is sent from wakers.
> --
> 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.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH tip/core/rcu 5/5] rcutorture: Make consistent use of variables
From: "Paul E. McKenney" The "if" statement at the beginning of rcu_torture_writer() should use the same set of variables. In theory, this does not matter because the corresponding variables (gp_sync and gp_sync1) have the same value at this point in the code, but in practice such puzzles should be removed. This commit therefore makes the use of variables consistent. Signed-off-by: Paul E. McKenney --- kernel/rcu/rcutorture.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c index 3833aa611ae7..8dbe27611ec3 100644 --- a/kernel/rcu/rcutorture.c +++ b/kernel/rcu/rcutorture.c @@ -875,7 +875,7 @@ rcu_torture_writer(void *arg) torture_type); /* Initialize synctype[] array. If none set, take default. */ - if (!gp_cond1 && !gp_exp1 && !gp_normal1 && !gp_sync) + if (!gp_cond1 && !gp_exp1 && !gp_normal1 && !gp_sync1) gp_cond1 = gp_exp1 = gp_normal1 = gp_sync1 = true; if (gp_cond1 && cur_ops->get_state && cur_ops->cond_sync) synctype[nsynctypes++] = RTWS_COND_GET; -- 1.8.1.5 -- 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 tip/core/rcu 6/7] rcu: Move early-boot callbacks to no-CBs lists for no-CBs CPUs
On Tue, Mar 03, 2015 at 04:57:16PM +, Mathieu Desnoyers wrote:
> - Original Message -
> > From: "Paul E. McKenney"
> > To: linux-kernel@vger.kernel.org
> > Cc: mi...@kernel.org, la...@cn.fujitsu.com, dipan...@in.ibm.com,
> > a...@linux-foundation.org, "mathieu desnoyers"
> > , j...@joshtriplett.org,
> > t...@linutronix.de, pet...@infradead.org,
> > rost...@goodmis.org, dhowe...@redhat.com, eduma...@google.com,
> > dvh...@linux.intel.com, fweis...@gmail.com,
> > o...@redhat.com, "bobby prani" , "Paul E. McKenney"
> >
> > Sent: Tuesday, March 3, 2015 11:45:47 AM
> > Subject: [PATCH tip/core/rcu 6/7] rcu: Move early-boot callbacks to no-CBs
> > lists for no-CBs CPUs
> >
> > From: "Paul E. McKenney"
> >
> > When a CPU is first determined to be a no-CBs CPUs, this commit causes
> > any early boot callbacks to be moved to the no-CBs callback list,
> > allowing them t obe invoked.
> ^
> out-of-order space ;)
I clearly needed a typography barrier! ;-)
Good catch!
Thanx, Paul
> Thanks,
>
> Mathieu
>
> >
> > Signed-off-by: Paul E. McKenney
> > ---
> > kernel/rcu/tree.c| 1 +
> > kernel/rcu/tree_plugin.h | 24
> > 2 files changed, 13 insertions(+), 12 deletions(-)
> >
> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index 92fd3eab5823..0317bf7d997f 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -2851,6 +2851,7 @@ __call_rcu(struct rcu_head *head, void (*func)(struct
> > rcu_head *rcu),
> > * and then drop through to queue the callback.
> > */
> > BUG_ON(cpu != -1);
> > + WARN_ON_ONCE(!rcu_is_watching());
> > if (!likely(rdp->nxtlist))
> > init_default_callback_list(rdp);
> > }
> > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> > index 75d5f096bcb0..afddd5641bea 100644
> > --- a/kernel/rcu/tree_plugin.h
> > +++ b/kernel/rcu/tree_plugin.h
> > @@ -2393,18 +2393,8 @@ void __init rcu_init_nohz(void)
> > pr_info("\tPoll for callbacks from no-CBs CPUs.\n");
> >
> > for_each_rcu_flavor(rsp) {
> > - for_each_cpu(cpu, rcu_nocb_mask) {
> > - struct rcu_data *rdp = per_cpu_ptr(rsp->rda, cpu);
> > -
> > - /*
> > -* If there are early callbacks, they will need
> > -* to be moved to the nocb lists.
> > -*/
> > - WARN_ON_ONCE(rdp->nxttail[RCU_NEXT_TAIL] !=
> > -&rdp->nxtlist &&
> > -rdp->nxttail[RCU_NEXT_TAIL] != NULL);
> > - init_nocb_callback_list(rdp);
> > - }
> > + for_each_cpu(cpu, rcu_nocb_mask)
> > + init_nocb_callback_list(per_cpu_ptr(rsp->rda, cpu));
> > rcu_organize_nocb_kthreads(rsp);
> > }
> > }
> > @@ -2541,6 +2531,16 @@ static bool init_nocb_callback_list(struct rcu_data
> > *rdp)
> > if (!rcu_is_nocb_cpu(rdp->cpu))
> > return false;
> >
> > + /* If there are early-boot callbacks, move them to nocb lists. */
> > + if (rdp->nxtlist) {
> > + rdp->nocb_head = rdp->nxtlist;
> > + rdp->nocb_tail = rdp->nxttail[RCU_NEXT_TAIL];
> > + atomic_long_set(&rdp->nocb_q_count, rdp->qlen);
> > + atomic_long_set(&rdp->nocb_q_count_lazy, rdp->qlen_lazy);
> > + rdp->nxtlist = NULL;
> > + rdp->qlen = 0;
> > + rdp->qlen_lazy = 0;
> > + }
> > rdp->nxttail[RCU_NEXT_TAIL] = NULL;
> > return true;
> > }
> > --
> > 1.8.1.5
> >
> >
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.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/
[PATCH tip/core/rcu 08/12] rcu: Add boot-up check for non-default CONFIG_RCU_FANOUT_LEAF values
From: "Paul E. McKenney"
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree_plugin.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 2484b3f716e0..12273dc0ee53 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -76,6 +76,9 @@ static void __init rcu_bootup_announce_oddness(void)
pr_info("\tAdditional per-CPU info printed with stalls.\n");
if (NUM_RCU_LVL_4 != 0)
pr_info("\tFour-level hierarchy is enabled.\n");
+ if (CONFIG_RCU_FANOUT_LEAF != 16)
+ pr_info("\tBuild-time adjustment of leaf fanout to %d.\n",
+ CONFIG_RCU_FANOUT_LEAF);
if (rcu_fanout_leaf != CONFIG_RCU_FANOUT_LEAF)
pr_info("\tBoot-time adjustment of leaf fanout to %d.\n",
rcu_fanout_leaf);
if (nr_cpu_ids != NR_CPUS)
--
1.8.1.5
--
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 tip/core/rcu 2/5] rcu: Add rcu_expedite_gp() and rcu_unexpedite_gp() to rcutorture
From: "Paul E. McKenney"
Signed-off-by: Paul E. McKenney
---
kernel/rcu/rcutorture.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 30d42aa55d83..3833aa611ae7 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -853,6 +853,8 @@ rcu_torture_fqs(void *arg)
static int
rcu_torture_writer(void *arg)
{
+ bool can_expedite = !rcu_gp_is_expedited();
+ int expediting = 0;
unsigned long gp_snap;
bool gp_cond1 = gp_cond, gp_exp1 = gp_exp, gp_normal1 = gp_normal;
bool gp_sync1 = gp_sync;
@@ -865,6 +867,12 @@ rcu_torture_writer(void *arg)
int nsynctypes = 0;
VERBOSE_TOROUT_STRING("rcu_torture_writer task started");
+ pr_alert("%s" TORTURE_FLAG
+" Grace periods expedited from boot/sysfs for %s,\n",
+torture_type, cur_ops->name);
+ pr_alert("%s" TORTURE_FLAG
+" Testing of dynamic grace-period expediting diabled.\n",
+torture_type);
/* Initialize synctype[] array. If none set, take default. */
if (!gp_cond1 && !gp_exp1 && !gp_normal1 && !gp_sync)
@@ -949,9 +957,26 @@ rcu_torture_writer(void *arg)
}
}
rcutorture_record_progress(++rcu_torture_current_version);
+ /* Cycle through nesting levels of rcu_expedite_gp() calls. */
+ if (can_expedite &&
+ !(torture_random(&rand) & 0xff & (!!expediting - 1))) {
+ WARN_ON_ONCE(expediting == 0 && rcu_gp_is_expedited());
+ if (expediting >= 0)
+ rcu_expedite_gp();
+ else
+ rcu_unexpedite_gp();
+ if (++expediting > 3)
+ expediting = -expediting;
+ }
rcu_torture_writer_state = RTWS_STUTTER;
stutter_wait("rcu_torture_writer");
} while (!torture_must_stop());
+ /* Reset expediting back to unexpedited. */
+ if (expediting > 0)
+ expediting = -expediting;
+ while (can_expedite && expediting++ < 0)
+ rcu_unexpedite_gp();
+ WARN_ON_ONCE(can_expedite && rcu_gp_is_expedited());
rcu_torture_writer_state = RTWS_STOPPING;
torture_kthread_stopping("rcu_torture_writer");
return 0;
--
1.8.1.5
--
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 tip/core/rcu 4/5] rcu: Add Kconfig option to expedite grace periods during boot
From: "Paul E. McKenney"
This commit adds a CONFIG_RCU_EXPEDITE_BOOT Kconfig parameter
that emulates a very early boot rcu_expedite_gp(). A late-boot
call to rcu_end_inkernel_boot() will provide the corresponding
rcu_unexpedite_gp(). The late-boot call to rcu_end_inkernel_boot()
should be made just before init is spawned.
According to Arjan:
> To show the boot time, I'm using the timestamp of the "Write protecting"
> line, that's pretty much the last thing we print prior to ring 3 execution.
>
> A kernel with default RCU behavior (inside KVM, only virtual devices)
> looks like this:
>
> [0.038724] Write protecting the kernel read-only data: 10240k
>
> a kernel with expedited RCU (using the command line option, so that I
> don't have to recompile between measurements and thus am completely
> oranges-to-oranges)
>
> [0.031768] Write protecting the kernel read-only data: 10240k
>
> which, in percentage, is an 18% improvement.
Reported-by: Arjan van de Ven
Signed-off-by: Paul E. McKenney
Tested-by: Arjan van de Ven
---
include/linux/rcupdate.h | 1 +
init/Kconfig | 13 +
kernel/rcu/update.c | 11 ++-
3 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 57a4d1f73a00..b9f039b11d31 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -278,6 +278,7 @@ static inline int rcu_preempt_depth(void)
/* Internal to kernel */
void rcu_init(void);
+void rcu_end_inkernel_boot(void);
void rcu_sched_qs(void);
void rcu_bh_qs(void);
void rcu_check_callbacks(int user);
diff --git a/init/Kconfig b/init/Kconfig
index f5dbc6d4261b..9a0592516f48 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -791,6 +791,19 @@ config RCU_NOCB_CPU_ALL
endchoice
+config RCU_EXPEDITE_BOOT
+ bool
+ default n
+ help
+ This option enables expedited grace periods at boot time,
+ as if rcu_expedite_gp() had been invoked early in boot.
+ The corresponding rcu_unexpedite_gp() is invoked from
+ rcu_end_inkernel_boot(), which is intended to be invoked
+ at the end of the kernel-only boot sequence, just before
+ init is exec'ed.
+
+ Accept the default if unsure.
+
endmenu # "RCU Subsystem"
config BUILD_BIN2C
diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
index 5f850823c187..7b12466f90bc 100644
--- a/kernel/rcu/update.c
+++ b/kernel/rcu/update.c
@@ -64,7 +64,8 @@ module_param(rcu_expedited, int, 0);
#ifndef CONFIG_TINY_RCU
-static atomic_t rcu_expedited_nesting;
+static atomic_t rcu_expedited_nesting =
+ ATOMIC_INIT(IS_ENABLED(CONFIG_RCU_EXPEDITE_BOOT) ? 1 : 0);
/*
* Should normal grace-period primitives be expedited? Intended for
@@ -109,6 +110,14 @@ EXPORT_SYMBOL_GPL(rcu_unexpedite_gp);
#endif /* #ifndef CONFIG_TINY_RCU */
+/*
+ * Inform RCU of the end of the in-kernel boot sequence.
+ */
+void rcu_end_inkernel_boot(void)
+{
+ if (IS_ENABLED(CONFIG_RCU_EXPEDITE_BOOT))
+ rcu_unexpedite_gp();
+}
#ifdef CONFIG_PREEMPT_RCU
--
1.8.1.5
--
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] c6x: kernel: setup: Type cast 'fdt' to "void *" for early_init_dt_scan() in machine_init()
On Sun, 2015-03-01 at 16:11 +0800, Chen Gang wrote: > early_init_dt_scan() accepts "void *", so c6x needs to type cast 'fdt' > to "void *" to avoid warning: > > CC arch/c6x/kernel/setup.o > arch/c6x/kernel/setup.c: In function 'machine_init': > arch/c6x/kernel/setup.c:290:21: warning: passing argument 1 of > 'early_init_dt_scan' discards 'const' qualifier from pointer target type > [-Wdiscarded-qualifiers] > early_init_dt_scan(fdt); >^ > In file included from arch/c6x/kernel/setup.c:19:0: > include/linux/of_fdt.h:75:13: note: expected 'void *' but argument is of > type 'const void *' >extern bool early_init_dt_scan(void *params); >^ > > Signed-off-by: Chen Gang > --- > arch/c6x/kernel/setup.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/c6x/kernel/setup.c b/arch/c6x/kernel/setup.c > index a5f6e0e..e5ea757 100644 > --- a/arch/c6x/kernel/setup.c > +++ b/arch/c6x/kernel/setup.c > @@ -289,7 +289,7 @@ notrace void __init machine_init(unsigned long dt_ptr) > fdt = dtb; > > /* Do some early initialization based on the flat device tree */ > - early_init_dt_scan(fdt); > + early_init_dt_scan((void *)fdt); > > parse_early_param(); > } I don't like the cast. I think the thing to do is just remove the const from local variables. -- 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 tip/core/rcu 0/5] In-kernel programmatic grace-period expediting for v4.1
Hello! This series provides an in-kernel API to expedite and unexpedite normal RCU grace-period primitives such as synchronize_rcu(). It also provides a Kconfig parameter that implicitly expedites at boot time, along with a function that notes the end of in-kernel boot. This last function is intended to be invoked just before init is spawned. 1. Provide rcu_expedite_gp() and rcu_unexpedite_gp(). 2. Add rcu_expedite_gp() and rcu_unexpedite_gp() to rcutorture. 3. Change open-coded references ot the rcu_expedited variable to instead use the new rcu_gp_is_expedited() function. 4. Add a CONFIG_RCU_EXPEDITE_BOOT Kconfig parameter that emulates a very early boot rcu_expedite_gp(). Also provide a new rcu_end_inkernel_boot() function that provides the corresponding rcu_unexpedite_gp() if CONFIG_RCU_EXPEDITE_BOOT. 5. Make consistent use of variables in rcu_torture_writer(). Thanx, Paul b/include/linux/rcupdate.h | 21 b/init/Kconfig | 13 + b/kernel/rcu/rcutorture.c | 27 +++- b/kernel/rcu/srcu.c|2 - b/kernel/rcu/tree.c|9 +++--- b/kernel/rcu/tree_plugin.h |2 - b/kernel/rcu/update.c | 59 - 7 files changed, 125 insertions(+), 8 deletions(-) -- 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/5] perf,tools: check and re-organize evsel cpu maps
> Em Tue, Mar 03, 2015 at 01:09:29PM -0300, Arnaldo Carvalho de Melo
> escreveu:
> > Em Tue, Mar 03, 2015 at 03:54:43AM -0500, kan.li...@intel.com escreveu:
> > > From: Kan Liang
> > >
> > > With the patch 1/5, it's possible to group read events from
> > > different pmus. "-C" can be used to set cpu list. The cpu list may
> > > be incompatible with pmu's cpumask.
> > > This patch checks the event's cpu maps, and discard the incompatible
> > > cpu maps.
> > > event's cpu maps is saved in evsel->cpus during option parse. Then
> > > the evlist's cpu maps is created in perf_evlist__create_maps. So the
> > > cpu maps can be check and re-organized in perf_evlist__create_maps.
> > > Only cpu_list need to check the cpu maps.
> >
> > Humm, I had something done in this area...
> >
> > Stephane complained about the confusion about which cpumap to use
> with
> > pmus, so I wrote a patch and sent an RFC, which I think I got no
> > comments, lemme dig it...
>
> Here it is, can you take a look? Stephane?
>
Your patch is more like my 3/5 patch. The difference is your patch force
the evsel->cpus = evlist->cpus, if evsel->cpus == NULL.
My patch handle the evsel->cpus == NULL case when using it.
> @@ -1216,8 +1206,8 @@ static void print_aggr(char *prefix)
> evlist__for_each(evsel_list, counter) {
> val = ena = run = 0;
> nr = 0;
> - for (cpu = 0; cpu < perf_evsel__nr_cpus(counter);
> cpu++) {
> - cpu2 = perf_evsel__cpus(counter)-
> >map[cpu];
> + for (cpu = 0; cpu < cpu_map__nr(counter->cpus);
> cpu++) {
> + cpu2 = counter->cpus->map[cpu];
> s2 = aggr_get_id(evsel_list->cpus, cpu2);
> if (s2 != id)
> continue;
print_aggr also need to be special handled. In the past, all events use
evlist's cpu map,so it uses index to find the real cpu id.
Now, event's cpu map are different. The s2 could be wrong.
For example, evlist's cpu map is 0,4,5,18. Event's cpu map could be 0,18.
When cpu == 1, the return of aggr_get_id must be wrong, since it
still use index to find s2.
My 3/5 patch introduce a function perf_evsel__get_cpumap_index
to handle it.
Only your patch is not enough, we still need 2/5 and 4/5.
2/5 is used to check if the event's cpu maps are compatible as evlist's
cpu map. For example, evlist's cpu map is 1,2,17. Event's cpu map
could be 0,18. We can error out earlier.
4/5 is used to special handle the open and mmap. We need to do
the same thing as what we did in print_aggr.
Thanks,
Kan
--
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 V2] (gpio-fan): Add thermal control hooks
On 02/24/2015 02:06 PM, Nishanth Menon wrote: > On Tue, Feb 24, 2015 at 1:55 PM, Guenter Roeck wrote: >> On Tue, Feb 24, 2015 at 03:29:35PM -0400, Eduardo Valentin wrote: >>> Guenter, >>> >>> On Thu, Jan 08, 2015 at 08:48:40PM -0800, Guenter Roeck wrote: On 01/08/2015 10:05 AM, Nishanth Menon wrote: > Allow gpio-fan to be used as thermal cooling device for platforms that > use GPIO maps to control fans. > > As part of this change, we make the shutdown and remove logic the same > as well. > > Signed-off-by: Nishanth Menon > --- Applied to -next. >>> >>> What is the target kernel version for this change? It didn't make >>> 4.0-rc1 >>> >> If I recall correctly, I had to pull it because the thermal framework >> does not provide hooks if disabled. Weird, I am sure I sent an e-mail >> about this, but I don't find it right now. >> >> It can't make it in before the hooks are in place, or we'll need >> another version with ifdefs around the thermal registration code. > > I had posted the required hooks. > https://patchwork.kernel.org/patch/5828261/ -> I think Eduardo picked > this one up.. So once it hits mainline, we should ideally be clear. > merged as 12ca7188468ee29c4e717f73db4bf43c90954fc7 upstream. Can we pick up this patch now? -- Regards, Nishanth Menon -- 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 tip/core/rcu 04/12] rcu: Drive PROVE_RCU directly off of PROVE_LOCKING
From: "Paul E. McKenney" In the past, it has been useful to enable PROVE_LOCKING without also enabling PROVE_RCU. However, experience with PROVE_RCU over the past few years has demonstrated its usefulness, so this commit makes PROVE_LOCKING directly imply PROVE_RCU. Signed-off-by: Paul E. McKenney --- lib/Kconfig.debug | 11 +-- 1 file changed, 1 insertion(+), 10 deletions(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index c5cefb3c009c..0766672e4c5f 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1180,16 +1180,7 @@ config DEBUG_CREDENTIALS menu "RCU Debugging" config PROVE_RCU - bool "RCU debugging: prove RCU correctness" - depends on PROVE_LOCKING - default n - help -This feature enables lockdep extensions that check for correct -use of RCU APIs. This is currently under development. Say Y -if you want to debug RCU usage or help work on the PROVE_RCU -feature. - -Say N if you are unsure. + def_bool PROVE_LOCKING config PROVE_RCU_REPEATEDLY bool "RCU debugging: don't disable PROVE_RCU on first splat" -- 1.8.1.5 -- 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] selftests: Add install, generate tar, and run_kselftest tools
On 03/03/2015 07:49 AM, Dave Jones wrote: > On Mon, Mar 02, 2015 at 09:48:08PM -0700, Shuah Khan wrote: > > kselftest_install.sh tool adds support for installing selftests > > at user specified location/kselftest. By default this tool > > will install selftests in the selftests/kselftest directory. > > For example, kselftest_install /tmp will install tests under > > /tmp/kselftest > > How is this an improvement over having each test install method isolated > to its own Makefile ? Dave/Michael, Makefile approach requires changes to all the existing test Makefiles. After looking at the churn to individual Makefiles, I have the following concerns. I am concerned about maintenance and potential for mistakes in install logic in individual Makefiles when new tests get added. I keep seeing run_tests target breaking when new tests get added and also when existing tests get modified. That said, I looked at Michael's patches and Michael's work does address several of my concerns. Hence, the following plan: I will take the following patches from Michael after requested changes are made: - [PATCH 1/9] selftests: Introduce minimal shared logic for running tests This improves current run_tests logic. Will need changes to account for duplicate cpu and memory hot-plug scripts. Both are named on-off-test.sh - won't make a difference for this patch, but will for install logic Note: I am seeing failures when I run sudo make kselftest after applying this patch /bin/sh: 1: ./run_netsocktests: Permission denied selftests: run_netsocktests [FAIL] /bin/sh: 1: ./run_afpackettests: Permission denied selftests: run_afpackettests [FAIL] /bin/sh: 1: ./run_numerictests: Permission denied selftests: run_numerictests [FAIL] /bin/sh: 1: ./run_stringtests: Permission denied selftests: run_stringtests [FAIL] /bin/sh: 1: ./run_vmtests: Permission denied Please make sure make kselftest doesn't regress when run as root as well as user. In addition, the following don't regress: make -C tools/testing/selftests TARGETS=test1 run_tests make -C tools/testing/selftests TARGETS="test1 test2" run_tests make -C tools/testing/selftests run_hotplug Please see Documentation/kselftest.txt - don't want to regress the current use-cases. - [PATCH 2/9] selftests: Add install target Looks like lib.mk logic is addressing some of my concerns about the individual Makefile install logic. I would like to see 1. the all script name changed to run_kselftest.sh - [PATCH 3/9] selftests: Add install support for the powerpc tests This is good as is. - [PATCH 5/9] kbuild: Don't pass -rR to selftest makefiles Drop kselftest_install from this patch. There is no need. More on this below. - PATCH 6/9] selftests: Set CC using CROSS_COMPILE once in lib.mk - [PATCH 7/9] selftests/timers: Use implicit rules Please check John Stultz's timers test work to make sure there is no conflict. Please see: [PATCH 01/19] selftests/timers: Cleanup Makefile to make it easier to add future tests https://lkml.org/lkml/2015/2/5/56 - [PATCH 8/9] selftests/mqueue: Use implicit rules This is good as is. - [PATCH 9/9] selftests/mount: Use implicit rules This is good as is. Drop these patches: - [PATCH 4/9] kbuild: add a new kselftest_install make target to install selftests I am not seeing any value in adding install target to the main Makefile. Invoking test run makes sense as it allows user to run them from the git without install step which makes sense. Being able to invoke install from main Makefile really doesn't add any value. We can isolate install logic under selftests and also avoid adding one more target to the main Makefile. I still want a wrapper script for install, so: - I will change kselftest_install.sh to leverage the above work. It can just invoke make install at the selftests directory after figuring base directory logic etc. This will be based on the above patches. - Keep gen_kselftest_tar.sh as is - no changes need. - I can drop run_kselftest tool completely, since emit logic in Michael's work takes care of it. Comments and questions? I am cc'ing Michal Marek to keep him in the loop. Michael! Please let me know if you want to see responses to your individual patches, in addition to this email. thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- 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 tip/core/rcu 10/12] torture: Avoid script syntax error when insufficient CPUs
From: "Paul E. McKenney" Parentheses are special to bash, so use an overflow flag that doesn't use them. Signed-off-by: Paul E. McKenney --- tools/testing/selftests/rcutorture/bin/kvm.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/rcutorture/bin/kvm.sh b/tools/testing/selftests/rcutorture/bin/kvm.sh index 368d64ac779e..dd2812ceb0ba 100755 --- a/tools/testing/selftests/rcutorture/bin/kvm.sh +++ b/tools/testing/selftests/rcutorture/bin/kvm.sh @@ -310,7 +310,7 @@ function dump(first, pastlast) cfr[jn] = cf[j] "." cfrep[cf[j]]; } if (cpusr[jn] > ncpus && ncpus != 0) - ovf = "(!)"; + ovf = "-ovf"; else ovf = ""; print "echo ", cfr[jn], cpusr[jn] ovf ": Starting build. `date`"; -- 1.8.1.5 -- 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/
[GIT PULL] x86/alternatives padding
Hi guys, so this one has been long in the making and has been passing testing on a bunch of boxes and bitness here so maybe we should try to put it into the wider tip mix and see what happens. If all is well, great, if there's trouble which I haven't managed to trigger in my testing, we can remove it from tip/master until all issues are fixed. Btw, the last three patches are adjusting and improving perf bench a little as it includes memcpy/memset_64.S directly and this patchset breaks it with the changes otherwise. Please pull, thanks. --- The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git tags/alternatives_padding for you to fetch changes up to dfecb95cdfeaf7872d83a96bec3a606e9cd95c8d: perf/bench: Add -r all so that you can run all mem* routines (2015-03-03 18:01:58 +0100) A more involved rework of the alternatives framework to be able to pad instructions and thus make using the alternatives macros more straightforward and without having to figure out old and new instruction sizes but have the toolchain figure that out for us. Furthermore, it optimizes JMPs used so that fetch and decode can be relieved with smaller versions of the JMPs, where possible. Some stats: x86_64 defconfig: Alternatives sites total: 2478 Total padding added (in Bytes): 6051 The padding is currently done for: X86_FEATURE_ALWAYS X86_FEATURE_ERMS X86_FEATURE_LFENCE_RDTSC X86_FEATURE_MFENCE_RDTSC X86_FEATURE_SMAP This is with the latest version of the patchset. Of course, on each machine the alternatives sites actually being patched are a proper subset of the total number. Borislav Petkov (18): x86/lib/copy_user_64.S: Remove FIX_ALIGNMENT define x86/alternatives: Cleanup DPRINTK macro x86/alternatives: Add instruction padding x86/alternatives: Make JMPs more robust x86/alternatives: Use optimized NOPs for padding x86/lib/copy_page_64.S: Use generic ALTERNATIVE macro x86/lib/copy_user_64.S: Convert to ALTERNATIVE_2 x86/smap: Use ALTERNATIVE macro x86/entry_32: Convert X86_INVD_BUG to ALTERNATIVE macro x86/lib/clear_page_64.S: Convert to ALTERNATIVE_2 macro x86/asm: Use alternative_2() in rdtsc_barrier() x86/asm: Cleanup prefetch primitives x86/lib/memset_64.S: Convert to ALTERNATIVE_2 macro x86/lib/memmove_64.S: Convert memmove() to ALTERNATIVE macro x86/lib/memcpy_64.S: Convert memcpy to ALTERNATIVE_2 macro perf/bench: Fix mem* routines usage after alternatives change perf/bench: Carve out mem routine benchmarking perf/bench: Add -r all so that you can run all mem* routines arch/x86/include/asm/alternative-asm.h| 43 ++- arch/x86/include/asm/alternative.h| 65 +++ arch/x86/include/asm/apic.h | 2 +- arch/x86/include/asm/barrier.h| 6 +- arch/x86/include/asm/cpufeature.h | 30 ++--- arch/x86/include/asm/processor.h | 16 ++- arch/x86/include/asm/smap.h | 30 ++--- arch/x86/kernel/alternative.c | 158 ++ arch/x86/kernel/cpu/amd.c | 5 + arch/x86/kernel/entry_32.S| 12 +- arch/x86/lib/clear_page_64.S | 66 +-- arch/x86/lib/copy_page_64.S | 37 ++ arch/x86/lib/copy_user_64.S | 46 ++-- arch/x86/lib/memcpy_64.S | 68 --- arch/x86/lib/memmove_64.S | 19 +--- arch/x86/lib/memset_64.S | 61 -- arch/x86/um/asm/barrier.h | 4 +- tools/perf/bench/mem-memcpy-x86-64-asm-def.h | 6 +- tools/perf/bench/mem-memcpy-x86-64-asm.S | 2 - tools/perf/bench/mem-memcpy.c | 128 +++-- tools/perf/bench/mem-memset-x86-64-asm-def.h | 6 +- tools/perf/bench/mem-memset-x86-64-asm.S | 2 - tools/perf/util/include/asm/alternative-asm.h | 1 + 23 files changed, 433 insertions(+), 380 deletions(-) -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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/3] early kprobes: x86: don't try to recover ftraced instruction before ftrace get ready.
On Tue 2015-03-03 13:09:05, Wang Nan wrote: > Before ftrace convertin instruction to nop, if an early kprobe is > registered then unregistered, without this patch its first bytes will > be replaced by head of NOP, which may confuse ftrace. > > Actually, since we have a patch which convert ftrace entry to nop > when probing, this problem should never be triggered. Provide it for > safety. > > Signed-off-by: Wang Nan > --- > arch/x86/kernel/kprobes/core.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c > index 87beb64..c7d304d 100644 > --- a/arch/x86/kernel/kprobes/core.c > +++ b/arch/x86/kernel/kprobes/core.c > @@ -225,6 +225,9 @@ __recover_probed_insn(kprobe_opcode_t *buf, unsigned long > addr) > struct kprobe *kp; > unsigned long faddr; > > + if (!kprobes_on_ftrace_initialized) > + return addr; This is not correct. The function has to return a buffer with the original code also when it is modified by normal kprobes. If it is a normal Kprobe, it reads the current code and replaces the first byte (INT3 instruction) with the saved kp->opcode. > + > kp = get_kprobe((void *)addr); > faddr = ftrace_location(addr); IMHO, the proper fix might be to replace the above line with if (kprobes_on_ftrace_initialized) faddr = ftrace_location(addr); else faddr = 0UL; By other words, it might pretend that it is not a ftrace location when the ftrace is not ready yet. Or is the code modified another special way when it is a ftrace location but ftrace has not been initialized yet? Best Regards, Petr > /* > -- > 1.8.4 > > -- > 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.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH tip/core/rcu 05/12] rcu: Remove CONFIG_RCU_FANOUT_EXACT from tree.c file
From: "Paul E. McKenney"
This commit moves the rcu_init_levelspread() functions from
kernel/rcu/tree.c to kernel/rcu/tree_plugin.h to get an ifdef out
of a .c file.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree.c| 29 -
kernel/rcu/tree.h| 1 +
kernel/rcu/tree_plugin.h | 26 ++
3 files changed, 27 insertions(+), 29 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 4e37c7fd9e29..840663122dda 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3731,35 +3731,6 @@ void rcu_scheduler_starting(void)
}
/*
- * Compute the per-level fanout, either using the exact fanout specified
- * or balancing the tree, depending on CONFIG_RCU_FANOUT_EXACT.
- */
-#ifdef CONFIG_RCU_FANOUT_EXACT
-static void __init rcu_init_levelspread(struct rcu_state *rsp)
-{
- int i;
-
- rsp->levelspread[rcu_num_lvls - 1] = rcu_fanout_leaf;
- for (i = rcu_num_lvls - 2; i >= 0; i--)
- rsp->levelspread[i] = CONFIG_RCU_FANOUT;
-}
-#else /* #ifdef CONFIG_RCU_FANOUT_EXACT */
-static void __init rcu_init_levelspread(struct rcu_state *rsp)
-{
- int ccur;
- int cprv;
- int i;
-
- cprv = nr_cpu_ids;
- for (i = rcu_num_lvls - 1; i >= 0; i--) {
- ccur = rsp->levelcnt[i];
- rsp->levelspread[i] = (cprv + ccur - 1) / ccur;
- cprv = ccur;
- }
-}
-#endif /* #else #ifdef CONFIG_RCU_FANOUT_EXACT */
-
-/*
* Helper function for rcu_init() that initializes one rcu_state structure.
*/
static void __init rcu_init_one(struct rcu_state *rsp,
diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
index 119de399eb2f..eb47a83d1549 100644
--- a/kernel/rcu/tree.h
+++ b/kernel/rcu/tree.h
@@ -595,6 +595,7 @@ static void rcu_sysidle_init_percpu_data(struct
rcu_dynticks *rdtp);
static bool rcu_nohz_full_cpu(struct rcu_state *rsp);
static void rcu_dynticks_task_enter(void);
static void rcu_dynticks_task_exit(void);
+static void __init rcu_init_levelspread(struct rcu_state *rsp);
#endif /* #ifndef RCU_TREE_NONCORE */
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 0a571e9a0f1d..93eeefeacc02 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -3091,3 +3091,29 @@ static void rcu_dynticks_task_exit(void)
ACCESS_ONCE(current->rcu_tasks_idle_cpu) = -1;
#endif /* #if defined(CONFIG_TASKS_RCU) && defined(CONFIG_NO_HZ_FULL) */
}
+
+/*
+ * Compute the per-level fanout, either using the exact fanout specified
+ * or balancing the tree, depending on CONFIG_RCU_FANOUT_EXACT.
+ */
+static void __init rcu_init_levelspread(struct rcu_state *rsp)
+{
+#ifdef CONFIG_RCU_FANOUT_EXACT
+ int i;
+
+ rsp->levelspread[rcu_num_lvls - 1] = rcu_fanout_leaf;
+ for (i = rcu_num_lvls - 2; i >= 0; i--)
+ rsp->levelspread[i] = CONFIG_RCU_FANOUT;
+#else /* #ifdef CONFIG_RCU_FANOUT_EXACT */
+ int ccur;
+ int cprv;
+ int i;
+
+ cprv = nr_cpu_ids;
+ for (i = rcu_num_lvls - 1; i >= 0; i--) {
+ ccur = rsp->levelcnt[i];
+ rsp->levelspread[i] = (cprv + ccur - 1) / ccur;
+ cprv = ccur;
+ }
+#endif /* #else #ifdef CONFIG_RCU_FANOUT_EXACT */
+}
--
1.8.1.5
--
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 tip/core/rcu 07/12] rcu: Use IS_ENABLED() to simplify rcu_bootup_announce_oddness()
From: "Paul E. McKenney"
This commit gets rid of some inline #ifdefs by replacing them with
IS_ENABLED.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree_plugin.h | 48
1 file changed, 20 insertions(+), 28 deletions(-)
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index fec7034d41db..2484b3f716e0 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -58,38 +58,30 @@ static bool __read_mostly rcu_nocb_poll;/* Offload
kthread are to poll. */
*/
static void __init rcu_bootup_announce_oddness(void)
{
-#ifdef CONFIG_RCU_TRACE
- pr_info("\tRCU debugfs-based tracing is enabled.\n");
-#endif
-#if (defined(CONFIG_64BIT) && CONFIG_RCU_FANOUT != 64) ||
(!defined(CONFIG_64BIT) && CONFIG_RCU_FANOUT != 32)
- pr_info("\tCONFIG_RCU_FANOUT set to non-default value of %d\n",
- CONFIG_RCU_FANOUT);
-#endif
-#ifdef CONFIG_RCU_FANOUT_EXACT
- pr_info("\tHierarchical RCU autobalancing is disabled.\n");
-#endif
-#ifdef CONFIG_RCU_FAST_NO_HZ
- pr_info("\tRCU dyntick-idle grace-period acceleration is enabled.\n");
-#endif
-#ifdef CONFIG_PROVE_RCU
- pr_info("\tRCU lockdep checking is enabled.\n");
-#endif
-#ifdef CONFIG_RCU_TORTURE_TEST_RUNNABLE
- pr_info("\tRCU torture testing starts during boot.\n");
-#endif
-#if defined(CONFIG_RCU_CPU_STALL_INFO)
- pr_info("\tAdditional per-CPU info printed with stalls.\n");
-#endif
-#if NUM_RCU_LVL_4 != 0
- pr_info("\tFour-level hierarchy is enabled.\n");
-#endif
+ if (IS_ENABLED(CONFIG_RCU_TRACE))
+ pr_info("\tRCU debugfs-based tracing is enabled.\n");
+ if ((IS_ENABLED(CONFIG_64BIT) && CONFIG_RCU_FANOUT != 64) ||
+ (!IS_ENABLED(CONFIG_64BIT) && CONFIG_RCU_FANOUT != 32))
+ pr_info("\tCONFIG_RCU_FANOUT set to non-default value of %d\n",
+ CONFIG_RCU_FANOUT);
+ if (IS_ENABLED(CONFIG_RCU_FANOUT_EXACT))
+ pr_info("\tHierarchical RCU autobalancing is disabled.\n");
+ if (IS_ENABLED(CONFIG_RCU_FAST_NO_HZ))
+ pr_info("\tRCU dyntick-idle grace-period acceleration is
enabled.\n");
+ if (IS_ENABLED(CONFIG_PROVE_RCU))
+ pr_info("\tRCU lockdep checking is enabled.\n");
+ if (IS_ENABLED(CONFIG_RCU_TORTURE_TEST_RUNNABLE))
+ pr_info("\tRCU torture testing starts during boot.\n");
+ if (IS_ENABLED(CONFIG_RCU_CPU_STALL_INFO))
+ pr_info("\tAdditional per-CPU info printed with stalls.\n");
+ if (NUM_RCU_LVL_4 != 0)
+ pr_info("\tFour-level hierarchy is enabled.\n");
if (rcu_fanout_leaf != CONFIG_RCU_FANOUT_LEAF)
pr_info("\tBoot-time adjustment of leaf fanout to %d.\n",
rcu_fanout_leaf);
if (nr_cpu_ids != NR_CPUS)
pr_info("\tRCU restricting CPUs from NR_CPUS=%d to
nr_cpu_ids=%d.\n", NR_CPUS, nr_cpu_ids);
-#ifdef CONFIG_RCU_BOOST
- pr_info("\tRCU kthread priority: %d.\n", kthread_prio);
-#endif
+ if (IS_ENABLED(CONFIG_RCU_BOOST))
+ pr_info("\tRCU kthread priority: %d.\n", kthread_prio);
}
#ifdef CONFIG_PREEMPT_RCU
--
1.8.1.5
--
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 tip/core/rcu 06/12] rcu: Improve diagnostics for blocked critical sections in irq
From: "Paul E. McKenney"
If an RCU read-side critical section occurs within an interrupt handler
or a softirq handler, it cannot have been preempted. Therefore, there is
a check in rcu_read_unlock_special() checking for this error. However,
when this check triggers, it lacks diagnostic information. This commit
therefore moves rcu_read_unlock()'s lockdep annotation to follow the
call to __rcu_read_unlock() and changes rcu_read_unlock_special()'s
WARN_ON_ONCE() to an lockdep_rcu_suspicious() in order to locate where
the offending RCU read-side critical section began. In addition, the
value of the ->rcu_read_unlock_special field is printed.
Signed-off-by: Paul E. McKenney
---
include/linux/lockdep.h | 7 ++-
include/linux/rcupdate.h | 2 +-
kernel/rcu/tree_plugin.h | 8 +++-
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 74ab23176e9b..066ba4157541 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -531,8 +531,13 @@ do {
\
# define might_lock_read(lock) do { } while (0)
#endif
-#ifdef CONFIG_PROVE_RCU
+#ifdef CONFIG_LOCKDEP
void lockdep_rcu_suspicious(const char *file, const int line, const char *s);
+#else
+static inline void
+lockdep_rcu_suspicious(const char *file, const int line, const char *s)
+{
+}
#endif
#endif /* __LINUX_LOCKDEP_H */
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 3e6afed51051..70b896e16f19 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -942,9 +942,9 @@ static inline void rcu_read_unlock(void)
{
rcu_lockdep_assert(rcu_is_watching(),
"rcu_read_unlock() used illegally while idle");
- rcu_lock_release(&rcu_lock_map);
__release(RCU);
__rcu_read_unlock();
+ rcu_lock_release(&rcu_lock_map); /* Keep acq info for rls diags. */
}
/**
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 93eeefeacc02..fec7034d41db 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -334,7 +334,13 @@ void rcu_read_unlock_special(struct task_struct *t)
}
/* Hardware IRQ handlers cannot block, complain if they get here. */
- if (WARN_ON_ONCE(in_irq() || in_serving_softirq())) {
+ if (in_irq() || in_serving_softirq()) {
+ lockdep_rcu_suspicious(__FILE__, __LINE__,
+ "rcu_read_unlock() from irq or softirq
with blocking in critical section!!!\n");
+ pr_alert("->rcu_read_unlock_special: %#x (b: %d, nq: %d)\n",
+t->rcu_read_unlock_special.s,
+t->rcu_read_unlock_special.b.blocked,
+t->rcu_read_unlock_special.b.need_qs);
local_irq_restore(flags);
return;
}
--
1.8.1.5
--
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 tip/core/rcu 11/12] rcu: Get rcu_sched_force_quiescent_state() where it belongs
From: "Paul E. McKenney"
The very similar functions rcu_force_quiescent_state(),
rcu_bh_force_quiescent_state(), and rcu_sched_force_quiescent_state()
are supposed to be together, but have drifted apart. This commit
restores rcu_sched_force_quiescent_state() to its rightful place.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 840663122dda..9820119f40b5 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -410,6 +410,15 @@ void rcu_bh_force_quiescent_state(void)
EXPORT_SYMBOL_GPL(rcu_bh_force_quiescent_state);
/*
+ * Force a quiescent state for RCU-sched.
+ */
+void rcu_sched_force_quiescent_state(void)
+{
+ force_quiescent_state(&rcu_sched_state);
+}
+EXPORT_SYMBOL_GPL(rcu_sched_force_quiescent_state);
+
+/*
* Show the state of the grace-period kthreads.
*/
void show_rcu_gp_kthreads(void)
@@ -483,15 +492,6 @@ void rcutorture_record_progress(unsigned long vernum)
EXPORT_SYMBOL_GPL(rcutorture_record_progress);
/*
- * Force a quiescent state for RCU-sched.
- */
-void rcu_sched_force_quiescent_state(void)
-{
- force_quiescent_state(&rcu_sched_state);
-}
-EXPORT_SYMBOL_GPL(rcu_sched_force_quiescent_state);
-
-/*
* Does the CPU have callbacks ready to be invoked?
*/
static int
--
1.8.1.5
--
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 tip/core/rcu 03/12] rcu: Fix a couple of typos in rcu_all_qs() comment header
From: "Paul E. McKenney" Signed-off-by: Paul E. McKenney --- kernel/rcu/tree.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 077d0b700f74..4e37c7fd9e29 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -292,10 +292,10 @@ void rcu_note_context_switch(void) EXPORT_SYMBOL_GPL(rcu_note_context_switch); /* - * Register a quiesecent state for all RCU flavors. If there is an + * Register a quiescent state for all RCU flavors. If there is an * emergency, invoke rcu_momentary_dyntick_idle() to do a heavy-weight * dyntick-idle quiescent state visible to other CPUs (but only for those - * RCU flavors in desparate need of a quiescent state, which will normally + * RCU flavors in desperate need of a quiescent state, which will normally * be none of them). Either way, do a lightweight quiescent state for * all RCU flavors. */ -- 1.8.1.5 -- 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 tip/core/rcu 01/12] rcu: Consolidate rcu_synchronize and wakeme_after_rcu()
From: "Paul E. McKenney"
There are currently duplicate identical definitions of the
rcu_synchronize() structure and the wakeme_after_rcu() function.
Thie commit therefore consolidates them.
Signed-off-by: Paul E. McKenney
---
include/linux/rcupdate.h | 9 +
kernel/rcu/srcu.c| 17 -
kernel/rcu/update.c | 15 ++-
3 files changed, 15 insertions(+), 26 deletions(-)
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 78097491cd99..3e6afed51051 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -195,6 +195,15 @@ void call_rcu_sched(struct rcu_head *head,
void synchronize_sched(void);
+/*
+ * Structure allowing asynchronous waiting on RCU.
+ */
+struct rcu_synchronize {
+ struct rcu_head head;
+ struct completion completion;
+};
+void wakeme_after_rcu(struct rcu_head *head);
+
/**
* call_rcu_tasks() - Queue an RCU for invocation task-based grace period
* @head: structure to be used for queueing the RCU updates.
diff --git a/kernel/rcu/srcu.c b/kernel/rcu/srcu.c
index 445bf8ffe3fb..81f53b504c18 100644
--- a/kernel/rcu/srcu.c
+++ b/kernel/rcu/srcu.c
@@ -402,23 +402,6 @@ void call_srcu(struct srcu_struct *sp, struct rcu_head
*head,
}
EXPORT_SYMBOL_GPL(call_srcu);
-struct rcu_synchronize {
- struct rcu_head head;
- struct completion completion;
-};
-
-/*
- * Awaken the corresponding synchronize_srcu() instance now that a
- * grace period has elapsed.
- */
-static void wakeme_after_rcu(struct rcu_head *head)
-{
- struct rcu_synchronize *rcu;
-
- rcu = container_of(head, struct rcu_synchronize, head);
- complete(&rcu->completion);
-}
-
static void srcu_advance_batches(struct srcu_struct *sp, int trycount);
static void srcu_reschedule(struct srcu_struct *sp);
diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
index e0d31a345ee6..8864ed90f0d7 100644
--- a/kernel/rcu/update.c
+++ b/kernel/rcu/update.c
@@ -199,16 +199,13 @@ EXPORT_SYMBOL_GPL(rcu_read_lock_bh_held);
#endif /* #ifdef CONFIG_DEBUG_LOCK_ALLOC */
-struct rcu_synchronize {
- struct rcu_head head;
- struct completion completion;
-};
-
-/*
- * Awaken the corresponding synchronize_rcu() instance now that a
- * grace period has elapsed.
+/**
+ * wakeme_after_rcu() - Callback function to awaken a task after grace period
+ * @head: Pointer to rcu_head member within rcu_synchronize structure
+ *
+ * Awaken the corresponding task now that a grace period has elapsed.
*/
-static void wakeme_after_rcu(struct rcu_head *head)
+void wakeme_after_rcu(struct rcu_head *head)
{
struct rcu_synchronize *rcu;
--
1.8.1.5
--
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] thinkpad_acpi: Add support for more adaptive kbd buttons
On Mon, Mar 02, 2015 at 02:17:01PM -0300, Henrique de Moraes Holschuh wrote: > On Mon, Mar 2, 2015, at 10:45, Bastien Nocera wrote: > > This commit adds new elements to the ThinkPad keymaps, and > > will send key events for keys for which an input.h declaration > > exists. > > > > Signed-off-by: Bastien Nocera > > Reviewed-by: Henrique de Moraes Holschuh > Acked-by: Henrique de Moraes Holschuh As I understand it, and how I interpret these tags, Reviewed-by is a superset of Acked-by. Acked implies acceptance of the general idea, Reviewed implies a careful code review. No need for both. I'm queueing these for testing in the pdx86 tree because we've been discussing that approach. However, I've asked Henrique to let me know how he prefers to handle this driver. -- Darren Hart Intel Open Source Technology Center -- 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 tip/core/rcu 0/12] Miscellaneous fixes for v4.1
Hello! This series contains miscellaneous fixes: 1. Merge identical definitions of the rcu_synchronize structure and the wakeme_after_rcu() functions. 2. Avoid needlessly writing to rnp->completed when a new grace period is started, courtesy of Lai Jiangshan. 3. Fix a couple of typos in rcu_all_qs() comment header. 4. Eliminate CONFIG_PROVE_RCU as a separately settable Kconfig parameter by driving its value off of CONFIG_PROVE_LOCKING. 5. Remove a #ifdef from tree.c by moving the rcu_init_levelspread() functions to tree_plugin.h. Only moves code. 6. Improve diagnostics for blocked critical sections in interrupt handlers. 7. Use IS_ENABLED() to simplify rcu_bootup_announce_oddness(). 8. Add rcu_bootup_announce_oddness() check for non-default CONFIG_RCU_FANOUT_LEAF values. 9. Reverse rcu_dereference_check() conditions to avoid invoking lockdep functions from NMI handlers. 10. Avoid script syntax error when insufficient CPUs. 11. Put rcu_sched_force_quiescent_state() back where it belongs. Only code movement. 12. Remove redundant check of cpu_online() by __call_rcu_core(), courtesy of Yao Dongdong. Thanx, Paul -- 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 tip/core/rcu 09/12] rcu: Reverse rcu_dereference_check() conditions
From: "Paul E. McKenney" The rcu_dereference_check() family of primitives evaluates the RCU lockdep expression first, and only then evaluates the expression passed in. This works fine normally, but can potentially fail in environments (such as NMI handlers) where lockdep cannot be invoked. The problem is that even if the expression passed in is "1", the compiler would need to prove that the RCU lockdep expression (rcu_read_lock_held(), for example) is free of side effects in order to be able to elide it. Given that rcu_read_lock_held() is sometimes separately compiled, the compiler cannot always use this optimization. This commit therefore reverse the order of evaluation, so that the expression passed in is evaluated first, and the RCU lockdep expression is evaluated only if the passed-in expression evaluated to false, courtesy of the C-language short-circuit boolean evaluation rules. This compells the compiler to forego executing the RCU lockdep expression in cases where the passed-in expression evaluates to "1" at compile time, so that (for example) rcu_dereference_raw() can be guaranteed to execute safely within an NMI handler. Signed-off-by: Paul E. McKenney Acked-by: Peter Zijlstra (Intel) --- include/linux/rcupdate.h | 6 +++--- include/linux/srcu.h | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h index 70b896e16f19..416ae2848c6c 100644 --- a/include/linux/rcupdate.h +++ b/include/linux/rcupdate.h @@ -729,7 +729,7 @@ static inline void rcu_preempt_sleep_check(void) * annotated as __rcu. */ #define rcu_dereference_check(p, c) \ - __rcu_dereference_check((p), rcu_read_lock_held() || (c), __rcu) + __rcu_dereference_check((p), (c) || rcu_read_lock_held(), __rcu) /** * rcu_dereference_bh_check() - rcu_dereference_bh with debug checking @@ -739,7 +739,7 @@ static inline void rcu_preempt_sleep_check(void) * This is the RCU-bh counterpart to rcu_dereference_check(). */ #define rcu_dereference_bh_check(p, c) \ - __rcu_dereference_check((p), rcu_read_lock_bh_held() || (c), __rcu) + __rcu_dereference_check((p), (c) || rcu_read_lock_bh_held(), __rcu) /** * rcu_dereference_sched_check() - rcu_dereference_sched with debug checking @@ -749,7 +749,7 @@ static inline void rcu_preempt_sleep_check(void) * This is the RCU-sched counterpart to rcu_dereference_check(). */ #define rcu_dereference_sched_check(p, c) \ - __rcu_dereference_check((p), rcu_read_lock_sched_held() || (c), \ + __rcu_dereference_check((p), (c) || rcu_read_lock_sched_held(), \ __rcu) #define rcu_dereference_raw(p) rcu_dereference_check(p, 1) /*@@@ needed? @@@*/ diff --git a/include/linux/srcu.h b/include/linux/srcu.h index 9cfd9623fb03..bdeb4567b71e 100644 --- a/include/linux/srcu.h +++ b/include/linux/srcu.h @@ -182,7 +182,7 @@ static inline int srcu_read_lock_held(struct srcu_struct *sp) * lockdep_is_held() calls. */ #define srcu_dereference_check(p, sp, c) \ - __rcu_dereference_check((p), srcu_read_lock_held(sp) || (c), __rcu) + __rcu_dereference_check((p), (c) || srcu_read_lock_held(sp), __rcu) /** * srcu_dereference - fetch SRCU-protected pointer for later dereferencing -- 1.8.1.5 -- 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 tip/core/rcu 02/12] rcu_tree: Avoid touching rnp->completed when a new GP is started
From: Lai Jiangshan In rcu_gp_init(), rnp->completed equals to rsp->completed in THEORY, we don't need to touch it normally. If something goes wrong, it will complain and fixup rnp->completed and avoid oops. This commit thus avoids the normal needless store to rnp->completed. Signed-off-by: Lai Jiangshan Signed-off-by: Paul E. McKenney --- kernel/rcu/tree.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 48d640ca1a05..077d0b700f74 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -1757,8 +1757,8 @@ static int rcu_gp_init(struct rcu_state *rsp) rcu_preempt_check_blocked_tasks(rnp); rnp->qsmask = rnp->qsmaskinit; ACCESS_ONCE(rnp->gpnum) = rsp->gpnum; - WARN_ON_ONCE(rnp->completed != rsp->completed); - ACCESS_ONCE(rnp->completed) = rsp->completed; + if (WARN_ON_ONCE(rnp->completed != rsp->completed)) + ACCESS_ONCE(rnp->completed) = rsp->completed; if (rnp == rdp->mynode) (void)__note_gp_changes(rsp, rnp, rdp); rcu_preempt_boost_start_gp(rnp); -- 1.8.1.5 -- 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 tip/core/rcu 12/12] rcu: Remove redundant check of cpu_online()
From: Yao Dongdong Because invoke_cpu_core() checks whether the current CPU is online, there is no need for __call_rcu_core() to redundantly check it. There should not be any performance degradation because the called function is visible to the compiler. This commit therefore removes the redundant check. Signed-off-by: Yao Dongdong Signed-off-by: Paul E. McKenney --- kernel/rcu/tree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 9820119f40b5..75366019e15c 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -2741,7 +2741,7 @@ static void __call_rcu_core(struct rcu_state *rsp, struct rcu_data *rdp, * If called from an extended quiescent state, invoke the RCU * core in order to force a re-evaluation of RCU's idleness. */ - if (!rcu_is_watching() && cpu_online(smp_processor_id())) + if (!rcu_is_watching()) invoke_rcu_core(); /* If interrupts were disabled or CPU offline, don't invoke RCU core. */ -- 1.8.1.5 -- 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 PATCH] arm64: cmpxchg.h: Bring ldxr and stxr closer
On Tue, Mar 3, 2015 at 9:34 AM, Catalin Marinas wrote: > > Do you mean the cmpxchg_double() change? Becuase %w0 and %0 is the same > physical register. You set it to 0 and immediately override it with > ldxp. > Thanks Catalin. I realized the blunder a while after Will pointed it out. The asm here was a bit confusing. %0 usually refers to the first input/output variable. But for ldxp instruction(which is just a double-word load, not exclusive), it refers to the physical registers. What about the changes in cmpxchg()? Why do we need to set %w0 to 0 after the ldxrh instruction? Also, could you please point me to any arm64 asm reference? Thanks! -- Pranith -- 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 tip/core/rcu 6/7] rcu: Move early-boot callbacks to no-CBs lists for no-CBs CPUs
- Original Message -
> From: "Paul E. McKenney"
> To: linux-kernel@vger.kernel.org
> Cc: mi...@kernel.org, la...@cn.fujitsu.com, dipan...@in.ibm.com,
> a...@linux-foundation.org, "mathieu desnoyers"
> , j...@joshtriplett.org, t...@linutronix.de,
> pet...@infradead.org,
> rost...@goodmis.org, dhowe...@redhat.com, eduma...@google.com,
> dvh...@linux.intel.com, fweis...@gmail.com,
> o...@redhat.com, "bobby prani" , "Paul E. McKenney"
>
> Sent: Tuesday, March 3, 2015 11:45:47 AM
> Subject: [PATCH tip/core/rcu 6/7] rcu: Move early-boot callbacks to no-CBs
> lists for no-CBs CPUs
>
> From: "Paul E. McKenney"
>
> When a CPU is first determined to be a no-CBs CPUs, this commit causes
> any early boot callbacks to be moved to the no-CBs callback list,
> allowing them t obe invoked.
^
out-of-order space ;)
Thanks,
Mathieu
>
> Signed-off-by: Paul E. McKenney
> ---
> kernel/rcu/tree.c| 1 +
> kernel/rcu/tree_plugin.h | 24
> 2 files changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 92fd3eab5823..0317bf7d997f 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -2851,6 +2851,7 @@ __call_rcu(struct rcu_head *head, void (*func)(struct
> rcu_head *rcu),
>* and then drop through to queue the callback.
>*/
> BUG_ON(cpu != -1);
> + WARN_ON_ONCE(!rcu_is_watching());
> if (!likely(rdp->nxtlist))
> init_default_callback_list(rdp);
> }
> diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> index 75d5f096bcb0..afddd5641bea 100644
> --- a/kernel/rcu/tree_plugin.h
> +++ b/kernel/rcu/tree_plugin.h
> @@ -2393,18 +2393,8 @@ void __init rcu_init_nohz(void)
> pr_info("\tPoll for callbacks from no-CBs CPUs.\n");
>
> for_each_rcu_flavor(rsp) {
> - for_each_cpu(cpu, rcu_nocb_mask) {
> - struct rcu_data *rdp = per_cpu_ptr(rsp->rda, cpu);
> -
> - /*
> - * If there are early callbacks, they will need
> - * to be moved to the nocb lists.
> - */
> - WARN_ON_ONCE(rdp->nxttail[RCU_NEXT_TAIL] !=
> - &rdp->nxtlist &&
> - rdp->nxttail[RCU_NEXT_TAIL] != NULL);
> - init_nocb_callback_list(rdp);
> - }
> + for_each_cpu(cpu, rcu_nocb_mask)
> + init_nocb_callback_list(per_cpu_ptr(rsp->rda, cpu));
> rcu_organize_nocb_kthreads(rsp);
> }
> }
> @@ -2541,6 +2531,16 @@ static bool init_nocb_callback_list(struct rcu_data
> *rdp)
> if (!rcu_is_nocb_cpu(rdp->cpu))
> return false;
>
> + /* If there are early-boot callbacks, move them to nocb lists. */
> + if (rdp->nxtlist) {
> + rdp->nocb_head = rdp->nxtlist;
> + rdp->nocb_tail = rdp->nxttail[RCU_NEXT_TAIL];
> + atomic_long_set(&rdp->nocb_q_count, rdp->qlen);
> + atomic_long_set(&rdp->nocb_q_count_lazy, rdp->qlen_lazy);
> + rdp->nxtlist = NULL;
> + rdp->qlen = 0;
> + rdp->qlen_lazy = 0;
> + }
> rdp->nxttail[RCU_NEXT_TAIL] = NULL;
> return true;
> }
> --
> 1.8.1.5
>
>
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.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 02/14] perf tools: Add feature check for lzma library
On Tue, Mar 03, 2015 at 12:50:30PM -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Mar 03, 2015 at 04:29:29PM +0100, Jiri Olsa escreveu: > > Will be used to decompress 'xz' objects. The check detects > > the liblzma.so devel library normally delivered by xz package. > > Hey, don't we want to emit some warning like the one below for CTF/libunwind? hum.. we probably want, right? ;-) will add in v2 thanks, jirka -- 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] i2c: imx: add required clocks property to binding
A clock specifier is required for i.MX I2C and is provided in all DTS implementations. Add this to the list of required properties in the binding. Signed-off-by: Matt Porter --- Documentation/devicetree/bindings/i2c/i2c-imx.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.txt b/Documentation/devicetree/bindings/i2c/i2c-imx.txt index 52d37fd..ce4311d 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-imx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-imx.txt @@ -7,6 +7,7 @@ Required properties: - "fsl,vf610-i2c" for I2C compatible with the one integrated on Vybrid vf610 SoC - reg : Should contain I2C/HS-I2C registers location and length - interrupts : Should contain I2C/HS-I2C interrupt +- clocks : Should contain the I2C/HS-I2C clock specifier Optional properties: - clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz. -- 1.8.4 -- 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] c6x: kernel: setup: Include "linux/console.h" if both VT and DUMMY_CONSOLE enabled
On Sun, 2015-03-01 at 15:59 +0800, Chen Gang wrote: > Or c6x will cause building break for allmodconfig, the related error: > > CC arch/c6x/kernel/setup.o > arch/c6x/kernel/setup.c: In function 'setup_arch': > arch/c6x/kernel/setup.c:433:2: error: 'conswitchp' undeclared (first use in > this function) > conswitchp = &dummy_con; > ^ > arch/c6x/kernel/setup.c:433:2: note: each undeclared identifier is reported > only once for each function it appears in > arch/c6x/kernel/setup.c:433:16: error: 'dummy_con' undeclared (first use in > this function) > conswitchp = &dummy_con; > ^ > > Signed-off-by: Chen Gang > --- > arch/c6x/kernel/setup.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/c6x/kernel/setup.c b/arch/c6x/kernel/setup.c > index 7571288..a5f6e0e 100644 > --- a/arch/c6x/kernel/setup.c > +++ b/arch/c6x/kernel/setup.c > @@ -26,7 +26,9 @@ > #include > #include > #include > - > +#if defined(CONFIG_VT) && defined(CONFIG_DUMMY_CONSOLE) > +#include > +#endif No need for the #ifdefs around the include. I removed them and pulled this into the c6x tree. Thanks! > > #include > #include -- 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 2/2] x86: svm: make wbinvd faster
2015-03-02 13:43-0600, Joel Schopp: > From: David Kaplan > > No need to re-decode WBINVD since we know what it is from the intercept. > > Signed-off-by: David Kaplan > [extracted from larger unlrelated patch, forward ported, tested,style cleanup] > Signed-off-by: Joel Schopp > --- Reviewed-by: Radim Krčmář Thanks. -- 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/2] kvm: x86: make kvm_emulate_* consistant
2015-03-02 13:43-0600, Joel Schopp:
> Currently kvm_emulate() skips the instruction but kvm_emulate_* sometimes
> don't. The end reult is the caller ends up doing the skip themselves.
> Let's make them consistant.
>
> Signed-off-by: Joel Schopp
> ---
Reviewed-by: Radim Krčmář
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> @@ -4723,11 +4723,19 @@ int kvm_emulate_wbinvd(struct kvm_vcpu *vcpu)
> wbinvd();
> return X86EMUL_CONTINUE;
> }
> +
> +int kvm_emulate_wbinvd(struct kvm_vcpu *vcpu)
> +{
> + kvm_x86_ops->skip_emulated_instruction(vcpu);
> + return kvm_emulate_wbinvd_noskip(vcpu);
> +}
> EXPORT_SYMBOL_GPL(kvm_emulate_wbinvd);
>
> +
> +
(sneaky newlines)
> static void emulator_wbinvd(struct x86_emulate_ctxt *ctxt)
> {
> - kvm_emulate_wbinvd(emul_to_vcpu(ctxt));
> + kvm_emulate_wbinvd_noskip(emul_to_vcpu(ctxt));
> }
>
> int emulator_get_dr(struct x86_emulate_ctxt *ctxt, int dr, unsigned long
> *dest)
--
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] i2c: designware: Suppress error message if platform_get_irq() returns -EPROBE_DEFER
Hello Alexey,
Alexey Brodkin wrote on 03/03/2015 05:37:31
PM:
> From:
>
> Alexey Brodkin
>
> To:
>
> "christian.rupp...@alitech.com" ,
>
> Cc:
>
> "mika.westerb...@linux.intel.com" ,
> "linux-kernel@vger.kernel.org" ,
> "vineet.gup...@synopsys.com" , "wsa@the-
> dreams.de" , "andriy.shevche...@linux.intel.com"
> , "linux-...@vger.kernel.org"
> , "christian.rupp...@abilis.com"
>
>
> Date:
>
> 03/03/2015 05:38 PM
>
> Subject:
>
> Re: [PATCH] i2c: designware: Suppress error message if
> platform_get_irq() returns -EPROBE_DEFER
>
> Hi Christian,
> [...]
> > >
> > > irq = platform_get_irq(pdev, 0);
> > > if (irq < 0) {
> > > - dev_err(&pdev->dev, "no irq resource?\n");
> > > + if (irq != -EPROBE_DEFER)
> > > + dev_err(&pdev->dev, "no irq resource?\n");
> >
> > Presented like this I wonder if this merits being a dev_err at all.
> > Wouldn't dev_dbg be more adequate? This might remove the need for the
> > condition and also avoid bothering everyone if something in the
platform
> > device structures or device tree is not right.
> >
> > >return irq; /* -ENXIO */
> > > }
>
> We've just had similar discussion related to DW APB UART with Andy here
> https://lkml.org/lkml/2015/3/3/412
>
> So yes probably we may safely remove error message from here completely.
I agree. Although you do have a point (in the other thread) when saying
this
kind of messages can be useful in some situations. The process of
debugging
device tree and platform device setup is definitely more painful for
drivers
which omit this type of messages completely. Andy's proposal of
centralising
this looks like a very good solution here (and on top of that removes many
useless strings from the kernel binary).
Greetings,
Christian
--
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 tip/core/rcu 2/7] rcu: Wire ->rda pointers at compile time
From: "Paul E. McKenney"
This commit wires up the rcu_state structures' ->rda pointers to the
per-CPU rcu_data structures at compile time, thus ensuring that this
linkage is present at early boot, in turn allowing posting of callbacks
before rcu_init() is executed.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index f8cdb92da10b..d2fa95e4a268 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -91,8 +91,10 @@ static const char *tp_##sname##_varname __used
__tracepoint_string = sname##_var
#define RCU_STATE_INITIALIZER(sname, sabbr, cr) \
DEFINE_RCU_TPS(sname) \
+DEFINE_PER_CPU_SHARED_ALIGNED(struct rcu_data, sname##_data); \
struct rcu_state sname##_state = { \
.level = { &sname##_state.node[0] }, \
+ .rda = &sname##_data, \
.call = cr, \
.fqs_state = RCU_GP_IDLE, \
.gpnum = 0UL - 300UL, \
@@ -104,8 +106,7 @@ struct rcu_state sname##_state = { \
.onoff_mutex = __MUTEX_INITIALIZER(sname##_state.onoff_mutex), \
.name = RCU_STATE_NAME(sname), \
.abbr = sabbr, \
-}; \
-DEFINE_PER_CPU_SHARED_ALIGNED(struct rcu_data, sname##_data)
+}
RCU_STATE_INITIALIZER(rcu_sched, 's', call_rcu_sched);
RCU_STATE_INITIALIZER(rcu_bh, 'b', call_rcu_bh);
@@ -3843,7 +3844,6 @@ static void __init rcu_init_one(struct rcu_state *rsp,
}
}
- rsp->rda = rda;
init_waitqueue_head(&rsp->gp_wq);
rnp = rsp->level[rcu_num_lvls - 1];
for_each_possible_cpu(i) {
--
1.8.1.5
--
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: [ibm-acpi-devel] [PATCH 1/7] thinkpad_acpi: Remember adaptive kbd presence
On Fri, Feb 27, 2015 at 08:16:19AM -0300, Henrique de Moraes Holschuh wrote: > On Fri, Feb 27, 2015, at 08:05, Henrique de Moraes Holschuh wrote: > > On Thu, Feb 26, 2015, at 03:18, Darren Hart wrote: > > > On Fri, Feb 20, 2015 at 03:44:10PM +0100, Bastien Nocera wrote: > > > > Rather than checking on each suspend and resume whether the laptop > > > > has an adaptive keyboard, check when the driver is initialised. > > > > > > Bastien, am I awaiting another version of this from you to address > > > comments from > > > Henrique? > > > > > > Henrique, when you're satisfied, please provide a Reviewed-by for the > > > series. > > > > I usually provide a signed-off-by, as I am the thinkpad-acpi driver > > maintainer... reviewed-by is implied in that case. > > Or an Acked-by, for that matter. Which is what I'd use for this series, > since there is no reason to gatekeep it and it is being sent to you > directly. > Henrique, I believe I may have overstepped with thinkpad-acpi and dealt with it like the other drivers in platform/drivers/x86, when instead I should have been leaving it to you. My apologies, it was not intentional. Do you typically send pull-requests for the thinkpad-acpi driver directly to Linus? Geeze, I see that the tree listed in MAINTAINERS is not even mine. Ugh, my sincere apologies. I would be more than happy to basically ignore anything to thinkpad-acpi until after you have provided a review. I can also roll up pull requests from you if you prefer to integrate into the platform-drivers-x86 tree as the path to Linus. How do you want to handle your driver? -- Darren Hart Intel Open Source Technology Center -- 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/
heads up/RFC: 'perf trace' using ordered_events
Hi, Just a preview, but this is something David had mentioned at some point, a major problem with 'perf trace' was that it wasn't using 'perf_session' event reordering mechanism, so I've been working on making it use it, refactoring the ordered_events code so that it can be used by tools that don't deal with perf.data files. I still have to investigate why there are so many sched_wakeup at the beginning, but probably they are really being generated by the kernel and 'perf trace' has to make this output more compact, perhaps noticing that a number of similar events appeared on the stream and instead of writing N lines, print some prefix ([N*] perhaps) and then the line. Also its keeping pointers to the ring buffer, probably we'll need to copy or store the perf_sample somehow in the 'ordered_event' instance. But as this is touching things that Namhyung is touching as well, I thought about sharing this stuff, its on my tree, branch tmp.perf/trace_ordered_events. Lunchtime, bbl! - Arnaldo [root@ssdandy ~]# trace --ev sched:* usleep 1 0.000 ( ): sched:sched_wakeup:comm=trace pid=4677 prio=120 success=1 target_cpu=001) 0.001 ( ): sched:sched_wakeup:comm=trace pid=4677 prio=120 success=1 target_cpu=001) 0.002 ( ): sched:sched_wakeup:comm=trace pid=4677 prio=120 success=1 target_cpu=001) 0.002 ( ): sched:sched_wakeup:comm=trace pid=4677 prio=120 success=1 target_cpu=001) 0.003 ( ): sched:sched_wakeup:comm=trace pid=4677 prio=120 success=1 target_cpu=001) 0.003 ( ): sched:sched_wakeup:comm=trace pid=4677 prio=120 success=1 target_cpu=001) 0.003 ( ): sched:sched_wakeup:comm=trace pid=4677 prio=120 success=1 target_cpu=001) 0.004 ( ): sched:sched_wakeup:comm=trace pid=4677 prio=120 success=1 target_cpu=001) 1.367 ( ): sched:sched_wakeup:comm=trace pid=4677 prio=120 success=1 target_cpu=003) 1.368 ( ): sched:sched_wakeup:comm=trace pid=4677 prio=120 success=1 target_cpu=003) 1.369 ( ): sched:sched_wakeup:comm=trace pid=4677 prio=120 success=1 target_cpu=003) 1.369 ( ): sched:sched_wakeup:comm=trace pid=4677 prio=120 success=1 target_cpu=003) 1.369 ( ): sched:sched_wakeup:comm=trace pid=4677 prio=120 success=1 target_cpu=003) 1.370 ( ): sched:sched_wakeup:comm=trace pid=4677 prio=120 success=1 target_cpu=003) 1.370 ( ): sched:sched_wakeup:comm=trace pid=4677 prio=120 success=1 target_cpu=003) 1.371 ( ): sched:sched_wakeup:comm=trace pid=4677 prio=120 success=1 target_cpu=003) 1.615 ( ): sched:sched_process_exec:filename=/bin/usleep pid=4677 old_pid=4677) 1.621 ( ): sched:sched_wakeup:comm=rcuop/3 pid=16 prio=120 success=1 target_cpu=005) 1.640 ( 0.001 ms): usleep/4677 brk( ) = 0x64e000 1.662 ( 0.005 ms): usleep/4677 mmap(len: 4096, prot: READ|WRITE, flags: PRIVATE|ANONYMOUS, fd: -1) = 0x7f3d1d7ef000 1.675 ( 0.005 ms): usleep/4677 access(filename: 0x7f3d1d5edbe0, mode: R ) = -1 ENOENT No such file or directory 1.687 ( 0.004 ms): usleep/4677 open(filename: 0x7f3d1d5ec4d8, flags: CLOEXEC ) = 3 1.689 ( 0.001 ms): usleep/4677 fstat(fd: 3, statbuf: 0x7fff28219d10 ) = 0 1.695 ( 0.005 ms): usleep/4677 mmap(len: 68635, prot: READ, flags: PRIVATE, fd: 3) = 0x7f3d1d7de000 1.696 ( 0.001 ms): usleep/4677 close(fd: 3 ) = 0 1.714 ( 0.007 ms): usleep/4677 open(filename: 0x7f3d1d7e867d, flags: CLOEXEC ) = 3 1.716 ( 0.002 ms): usleep/4677 read(fd: 3, buf: 0x7fff28219eb0, count: 832 ) = 832 1.719 ( 0.001 ms): usleep/4677 fstat(fd: 3, statbuf: 0x7fff28219d60 ) = 0 1.727 ( 0.006 ms): usleep/4677 mmap(len: 2135088, prot: EXEC|READ, flags: PRIVATE|DENYWRITE, fd: 3 ) = 0x7f3d1d3c6000 1.734 ( 0.007 ms): usleep/4677 mprotect(start: 0x7f3d1d3cf000, len: 2093056 ) = 0 1.741 ( 0.007 ms): usleep/4677 mmap(addr: 0x7f3d1d5ce000, len: 8192, prot: READ|WRITE, flags: PRIVATE|DENYWRITE|FIXED, fd: 3, off: 32768) = 0x7f3d1d5ce000 1.748 ( 0.001 ms): usleep/4677 close(fd: 3 ) = 0 1.763 ( 0.006 ms): usleep/4677 open(filename: 0x7f3d1d7ed5fa, flags: CLOEXEC ) = 3 1.765 ( 0.002 ms): usleep/4677 read(fd: 3, buf: 0x7fff28219e80, count: 832 ) = 832 1.767 ( 0.001 ms): usleep/4677 fstat(fd: 3, statbuf: 0x7fff28219d30 ) = 0 1.775 ( 0.006 ms): usleep/4677 mmap(len: 3932736, prot: EXEC|READ
Re: [RESEND PATCH 1/6] mfd: arizona: Add support for WM8280/WM8281
On Tue, 03 Mar 2015, Charles Keepax wrote:
> From: Richard Fitzgerald
>
> This adds support for the Wolfson Microelectronics WM8280 and WM8281
> codecs.
>
> Signed-off-by: Richard Fitzgerald
> Acked-by: Lee Jones
> [ Minor fixup to remove potentially uninitialised variable. ]
> Signed-off-by: Charles Keepax
> ---
> drivers/mfd/Kconfig |5 +++--
> drivers/mfd/arizona-core.c | 15 +--
> drivers/mfd/arizona-i2c.c|2 ++
> drivers/mfd/arizona-irq.c|1 +
> drivers/mfd/arizona-spi.c|2 ++
> include/linux/mfd/arizona/core.h |1 +
> 6 files changed, 22 insertions(+), 4 deletions(-)
Applied, thanks.
Will send out pull-request once this has had time to soak in -next.
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 0ad88c7..b5fb03c 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1290,10 +1290,11 @@ config MFD_WM5102
> Support for Wolfson Microelectronics WM5102 low power audio SoC
>
> config MFD_WM5110
> - bool "Wolfson Microelectronics WM5110"
> + bool "Wolfson Microelectronics WM5110 and WM8280/WM8281"
> depends on MFD_ARIZONA
> help
> - Support for Wolfson Microelectronics WM5110 low power audio SoC
> + Support for Wolfson Microelectronics WM5110 and WM8280/WM8281
> + low power audio SoC
>
> config MFD_WM8997
> bool "Wolfson Microelectronics WM8997"
> diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
> index 09ba8f1..9f81998 100644
> --- a/drivers/mfd/arizona-core.c
> +++ b/drivers/mfd/arizona-core.c
> @@ -567,6 +567,7 @@ static int arizona_of_get_core_pdata(struct arizona
> *arizona)
> const struct of_device_id arizona_of_match[] = {
> { .compatible = "wlf,wm5102", .data = (void *)WM5102 },
> { .compatible = "wlf,wm5110", .data = (void *)WM5110 },
> + { .compatible = "wlf,wm8280", .data = (void *)WM8280 },
> { .compatible = "wlf,wm8997", .data = (void *)WM8997 },
> {},
> };
> @@ -671,6 +672,7 @@ int arizona_dev_init(struct arizona *arizona)
> switch (arizona->type) {
> case WM5102:
> case WM5110:
> + case WM8280:
> case WM8997:
> for (i = 0; i < ARRAY_SIZE(wm5102_core_supplies); i++)
> arizona->core_supplies[i].supply
> @@ -834,11 +836,19 @@ int arizona_dev_init(struct arizona *arizona)
> #endif
> #ifdef CONFIG_MFD_WM5110
> case 0x5110:
> - type_name = "WM5110";
> - if (arizona->type != WM5110) {
> + switch (arizona->type) {
> + case WM5110:
> + type_name = "WM5110";
> + break;
> + case WM8280:
> + type_name = "WM8280";
> + break;
> + default:
> + type_name = "WM5110";
> dev_err(arizona->dev, "WM5110 registered as %d\n",
> arizona->type);
> arizona->type = WM5110;
> + break;
> }
> apply_patch = wm5110_patch;
> break;
> @@ -1010,6 +1020,7 @@ int arizona_dev_init(struct arizona *arizona)
> ARRAY_SIZE(wm5102_devs), NULL, 0, NULL);
> break;
> case WM5110:
> + case WM8280:
> ret = mfd_add_devices(arizona->dev, -1, wm5110_devs,
> ARRAY_SIZE(wm5110_devs), NULL, 0, NULL);
> break;
> diff --git a/drivers/mfd/arizona-i2c.c b/drivers/mfd/arizona-i2c.c
> index 9d4156f..ff782a5d 100644
> --- a/drivers/mfd/arizona-i2c.c
> +++ b/drivers/mfd/arizona-i2c.c
> @@ -44,6 +44,7 @@ static int arizona_i2c_probe(struct i2c_client *i2c,
> #endif
> #ifdef CONFIG_MFD_WM5110
> case WM5110:
> + case WM8280:
> regmap_config = &wm5110_i2c_regmap;
> break;
> #endif
> @@ -87,6 +88,7 @@ static int arizona_i2c_remove(struct i2c_client *i2c)
> static const struct i2c_device_id arizona_i2c_id[] = {
> { "wm5102", WM5102 },
> { "wm5110", WM5110 },
> + { "wm8280", WM8280 },
> { "wm8997", WM8997 },
> { }
> };
> diff --git a/drivers/mfd/arizona-irq.c b/drivers/mfd/arizona-irq.c
> index 3a3fe7c..d063b94 100644
> --- a/drivers/mfd/arizona-irq.c
> +++ b/drivers/mfd/arizona-irq.c
> @@ -211,6 +211,7 @@ int arizona_irq_init(struct arizona *arizona)
> #endif
> #ifdef CONFIG_MFD_WM5110
> case WM5110:
> + case WM8280:
> aod = &wm5110_aod;
>
> switch (arizona->rev) {
> diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c
> index 8ef58bc..1e845f6 100644
> --- a/drivers/mfd/arizona-spi.c
> +++ b/drivers/mfd/arizona-spi.c
> @@ -44,6 +44,7 @@ static int arizona_spi_probe(struct spi_device *spi)
> #endif
> #ifdef CONFIG_MFD_WM5110
> case WM5110:
> + case WM8280:
> regmap_config = &wm5110_spi_regm
[PATCH tip/core/rcu 4/7] rcu: Refine diagnostics for lacking kthread for no-CBs callbacks
From: "Paul E. McKenney"
Some diagnostics under CONFIG_PROVE_RCU in rcu_nocb_cpu_needs_barrier()
assume that there can be no early-boot callbacks. This commit therefore
qualifies the diagnostic with rcu_scheduler_fully_active to permit
early boot callbacks to avoid this splat.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree_plugin.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 0a571e9a0f1d..75d5f096bcb0 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -1945,7 +1945,8 @@ static bool rcu_nocb_cpu_needs_barrier(struct rcu_state
*rsp, int cpu)
rhp = ACCESS_ONCE(rdp->nocb_follower_head);
/* Having no rcuo kthread but CBs after scheduler starts is bad! */
- if (!ACCESS_ONCE(rdp->nocb_kthread) && rhp) {
+ if (!ACCESS_ONCE(rdp->nocb_kthread) && rhp &&
+ rcu_scheduler_fully_active) {
/* RCU callback enqueued before CPU first came online??? */
pr_err("RCU: Never-onlined no-CBs CPU %d has CB %p\n",
cpu, rhp->func);
--
1.8.1.5
--
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 tip/core/rcu 6/7] rcu: Move early-boot callbacks to no-CBs lists for no-CBs CPUs
From: "Paul E. McKenney"
When a CPU is first determined to be a no-CBs CPUs, this commit causes
any early boot callbacks to be moved to the no-CBs callback list,
allowing them t obe invoked.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree.c| 1 +
kernel/rcu/tree_plugin.h | 24
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 92fd3eab5823..0317bf7d997f 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2851,6 +2851,7 @@ __call_rcu(struct rcu_head *head, void (*func)(struct
rcu_head *rcu),
* and then drop through to queue the callback.
*/
BUG_ON(cpu != -1);
+ WARN_ON_ONCE(!rcu_is_watching());
if (!likely(rdp->nxtlist))
init_default_callback_list(rdp);
}
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 75d5f096bcb0..afddd5641bea 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -2393,18 +2393,8 @@ void __init rcu_init_nohz(void)
pr_info("\tPoll for callbacks from no-CBs CPUs.\n");
for_each_rcu_flavor(rsp) {
- for_each_cpu(cpu, rcu_nocb_mask) {
- struct rcu_data *rdp = per_cpu_ptr(rsp->rda, cpu);
-
- /*
-* If there are early callbacks, they will need
-* to be moved to the nocb lists.
-*/
- WARN_ON_ONCE(rdp->nxttail[RCU_NEXT_TAIL] !=
-&rdp->nxtlist &&
-rdp->nxttail[RCU_NEXT_TAIL] != NULL);
- init_nocb_callback_list(rdp);
- }
+ for_each_cpu(cpu, rcu_nocb_mask)
+ init_nocb_callback_list(per_cpu_ptr(rsp->rda, cpu));
rcu_organize_nocb_kthreads(rsp);
}
}
@@ -2541,6 +2531,16 @@ static bool init_nocb_callback_list(struct rcu_data *rdp)
if (!rcu_is_nocb_cpu(rdp->cpu))
return false;
+ /* If there are early-boot callbacks, move them to nocb lists. */
+ if (rdp->nxtlist) {
+ rdp->nocb_head = rdp->nxtlist;
+ rdp->nocb_tail = rdp->nxttail[RCU_NEXT_TAIL];
+ atomic_long_set(&rdp->nocb_q_count, rdp->qlen);
+ atomic_long_set(&rdp->nocb_q_count_lazy, rdp->qlen_lazy);
+ rdp->nxtlist = NULL;
+ rdp->qlen = 0;
+ rdp->qlen_lazy = 0;
+ }
rdp->nxttail[RCU_NEXT_TAIL] = NULL;
return true;
}
--
1.8.1.5
--
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 tip/core/rcu 7/7] rcu: Move early boot callback tests earlier
From: "Paul E. McKenney"
Because callbacks can now be posted quite early in boot, move the
early boot callback tests to precede RCU initialization.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 0317bf7d997f..c8e6569c5fbd 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3948,6 +3948,8 @@ void __init rcu_init(void)
{
int cpu;
+ rcu_early_boot_tests();
+
rcu_bootup_announce();
rcu_init_geometry();
rcu_init_one(&rcu_bh_state, &rcu_bh_data);
@@ -3964,8 +3966,6 @@ void __init rcu_init(void)
pm_notifier(rcu_pm_notify, 0);
for_each_online_cpu(cpu)
rcu_cpu_notify(NULL, CPU_UP_PREPARE, (void *)(long)cpu);
-
- rcu_early_boot_tests();
}
#include "tree_plugin.h"
--
1.8.1.5
--
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] i2c: designware: Suppress error message if platform_get_irq() returns -EPROBE_DEFER
On 2015-03-03 16:27, Alexey Brodkin wrote:
> There's no point in printing error message if platform_get_irq()
> returns -EPROBE_DEFER because probe deferring subsystem already outputs
> message in bootlog like this:
> --->8---
> platform e001d000.i2c: Driver i2c_designware requests probe deferral
> --->8---
>
> Moreover in case of probe deferral following message may mislead user:
> --->8---
> i2c_designware e001d000.i2c: no irq resource?
> --->8---
> even though it's expected that platform_get_irq() may return
> -EPROBE_DEFER.
>
> Signed-off-by: Alexey Brodkin
> Cc: Vineet Gupta
> Cc: Christian Ruppert
> Cc: Mika Westerberg
> Cc: Wolfram Sang
> ---
> drivers/i2c/busses/i2c-designware-platdrv.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
> b/drivers/i2c/busses/i2c-designware-platdrv.c
> index c270f5f..01c1b17 100644
> --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> @@ -144,7 +144,8 @@ static int dw_i2c_probe(struct platform_device *pdev)
>
> irq = platform_get_irq(pdev, 0);
> if (irq < 0) {
> - dev_err(&pdev->dev, "no irq resource?\n");
> + if (irq != -EPROBE_DEFER)
> + dev_err(&pdev->dev, "no irq resource?\n");
Presented like this I wonder if this merits being a dev_err at all.
Wouldn't dev_dbg be more adequate? This might remove the need for the
condition and also avoid bothering everyone if something in the platform
device structures or device tree is not right.
> return irq; /* -ENXIO */
> }
>
>
--
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: [RESEND PATCH 2/6] mfd: arizona: Update binding documentation for WM8280
On Tue, 03 Mar 2015, Charles Keepax wrote: > From: Richard Fitzgerald > > Signed-off-by: Richard Fitzgerald > Signed-off-by: Charles Keepax > --- > Documentation/devicetree/bindings/mfd/arizona.txt | 15 +++ > 1 files changed, 11 insertions(+), 4 deletions(-) Applied, thanks. Will send out pull-request once this has had time to soak in -next. > diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt > b/Documentation/devicetree/bindings/mfd/arizona.txt > index bfef000..af8646f 100644 > --- a/Documentation/devicetree/bindings/mfd/arizona.txt > +++ b/Documentation/devicetree/bindings/mfd/arizona.txt > @@ -8,6 +8,7 @@ Required properties: >- compatible : One of the following chip-specific strings: > "wlf,wm5102" > "wlf,wm5110" > +"wlf,wm8280" > "wlf,wm8997" >- reg : I2C slave address when connected using I2C, chip select number when > using SPI. > @@ -26,10 +27,16 @@ Required properties: >- #gpio-cells : Must be 2. The first cell is the pin number and the > second cell is used to specify optional parameters (currently unused). > > - - AVDD-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply (wm5102, > wm5110), > -CPVDD-supply, SPKVDDL-supply (wm5102, wm5110), SPKVDDR-supply (wm5102, > -wm5110), SPKVDD-supply (wm8997) : Power supplies for the device, as > covered > -in Documentation/devicetree/bindings/regulator/regulator.txt > + - AVDD-supply, DBVDD1-supply, CPVDD-supply : Power supplies for the device, > +as covered in Documentation/devicetree/bindings/regulator/regulator.txt > + > + - DBVDD2-supply, DBVDD3-supply : Additional databus power supplies (wm5102, > +wm5110, wm8280) > + > + - SPKVDDL-supply, SPKVDDR-supply : Speaker driver power supplies (wm5102, > +wm5110, wm8280) > + > + - SPKVDD-supply : Speaker driver power supply (wm8997) > > Optional properties: > -- 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/
[PATCH tip/core/rcu 5/7] rcu: Avoid clobbering early boot callbacks
From: "Paul E. McKenney" When a CPU comes online, it initializes its callback list. This is a bad thing if this is the first time that the CPU has come online and if that CPU has early boot callbacks. This commit therefore avoid initializing the callback list if there are callbacks present, in which case the initial call_rcu() did the initialization for us. Signed-off-by: Paul E. McKenney --- kernel/rcu/tree.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index fcfdbe53bb70..92fd3eab5823 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -3583,7 +3583,8 @@ rcu_init_percpu_data(int cpu, struct rcu_state *rsp) rdp->qlen_last_fqs_check = 0; rdp->n_force_qs_snap = rsp->n_force_qs; rdp->blimit = blimit; - init_callback_list(rdp); /* Re-enable callbacks on this CPU. */ + if (!rdp->nxtlist) + init_callback_list(rdp); /* Re-enable callbacks on this CPU. */ rdp->dynticks->dynticks_nesting = DYNTICK_TASK_EXIT_IDLE; rcu_sysidle_init_percpu_data(rdp->dynticks); atomic_set(&rdp->dynticks->dynticks, -- 1.8.1.5 -- 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: [RESEND PATCH 5/6] extcon: arizona: Add support for WM8280/WM8281
On Tue, 03 Mar 2015, Charles Keepax wrote:
> From: Richard Fitzgerald
>
> Signed-off-by: Richard Fitzgerald
> Acked-by: Chanwoo Choi
> Signed-off-by: Charles Keepax
> ---
> drivers/extcon/extcon-arizona.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Applied, thanks.
Will send out pull-request once this has had time to soak in -next.
> diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
> index 63f01c4..6b5e795 100644
> --- a/drivers/extcon/extcon-arizona.c
> +++ b/drivers/extcon/extcon-arizona.c
> @@ -1149,6 +1149,7 @@ static int arizona_extcon_probe(struct platform_device
> *pdev)
> }
> break;
> case WM5110:
> + case WM8280:
> switch (arizona->rev) {
> case 0 ... 2:
> break;
--
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/
[PATCH 04/14] perf tools: Add kmod_path__parse function
Provides united way of parsing kernel module path
into several components.
The new kmod_path__parse function and few defines:
int __kmod_path__parse(struct kmod_path *m, const char *path,
bool alloc_name, bool alloc_ext);
#define kmod_path__parse(__m, __p) __kmod_path__parse(__m, __p, false,
false)
#define kmod_path__parse_name(__m, __p) __kmod_path__parse(__m, __p, true ,
false)
#define kmod_path__parse_ext(__m, __p) __kmod_path__parse(__m, __p, false,
true)
parse kernel module @path and updates @m argument like:
@comp - true if @path contains supported compression suffix,
false otherwise
@kmod - true if @path contains '.ko' suffix in right position,
false otherwise
@name - if (@alloc_name && @kmod) is true, it contains strdup-ed base name
of the kernel module without suffixes, otherwise strudup-ed
base name of @path
@ext - if (@alloc_ext && @comp) is true, it contains strdup-ed string
the compression suffix
It returns 0 if there's no strdup error, -ENOMEM otherwise.
Signed-off-by: Jiri Olsa
Cc: Adrian Hunter
Cc: Arnaldo Carvalho de Melo
Cc: Corey Ashford
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
---
tools/perf/tests/Build | 1 +
tools/perf/tests/builtin-test.c | 4 +++
tools/perf/tests/kmod-path.c| 73 +
tools/perf/tests/tests.h| 1 +
tools/perf/util/util.c | 66 +
tools/perf/util/util.h | 14
6 files changed, 159 insertions(+)
create mode 100644 tools/perf/tests/kmod-path.c
diff --git a/tools/perf/tests/Build b/tools/perf/tests/Build
index 2de01a4b4084..6a8801b32017 100644
--- a/tools/perf/tests/Build
+++ b/tools/perf/tests/Build
@@ -30,6 +30,7 @@ perf-y += keep-tracking.o
perf-y += code-reading.o
perf-y += sample-parsing.o
perf-y += parse-no-sample-id-all.o
+perf-y += kmod-path.o
perf-$(CONFIG_X86) += perf-time-to-tsc.o
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index 4b7d9ab0f049..31f9959c04c8 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -167,6 +167,10 @@ static struct test {
.func = test__fdarray__add,
},
{
+ .desc = "Test kmod_path__parse function",
+ .func = test__kmod_path__parse,
+ },
+ {
.func = NULL,
},
};
diff --git a/tools/perf/tests/kmod-path.c b/tools/perf/tests/kmod-path.c
new file mode 100644
index ..277cb851722b
--- /dev/null
+++ b/tools/perf/tests/kmod-path.c
@@ -0,0 +1,73 @@
+#include
+#include "tests.h"
+#include "util.h"
+#include "debug.h"
+
+static int test(const char *path, bool alloc_name, bool alloc_ext,
+ bool kmod, bool comp, const char *name, const char *ext)
+{
+ struct kmod_path m;
+
+ memset(&m, 0x0, sizeof(m));
+
+ TEST_ASSERT_VAL("kmod_path__parse",
+ !__kmod_path__parse(&m, path, alloc_name, alloc_ext));
+
+ pr_debug("%s - alloc name %d, alloc ext %d, kmod %d, comp %d, name
'%s', ext '%s'\n",
+path, alloc_name, alloc_ext, m.kmod, m.comp, m.name, m.ext);
+
+ TEST_ASSERT_VAL("wrong kmod", m.kmod == kmod);
+ TEST_ASSERT_VAL("wrong comp", m.comp == comp);
+
+ if (ext)
+ TEST_ASSERT_VAL("wrong ext", m.ext && !strcmp(ext, m.ext));
+ else
+ TEST_ASSERT_VAL("wrong ext", !m.ext);
+
+ if (name)
+ TEST_ASSERT_VAL("wrong name", m.name && !strcmp(name, m.name));
+ else
+ TEST_ASSERT_VAL("wrong name", !m.name);
+
+ free(m.name);
+ free(m.ext);
+ return 0;
+}
+
+#define T(path, an, ae, k, c, n, e) \
+ TEST_ASSERT_VAL("failed", !test(path, an, ae, k, c, n, e))
+
+int test__kmod_path__parse(void)
+{
+ /* pathalloc_name alloc_ext kmod comp name
ext */
+ T("///x-x.ko", true , true , true, false, "[x_x]",
NULL);
+ T("///x-x.ko", false , true , true, false, NULL ,
NULL);
+ T("///x-x.ko", true , false , true, false, "[x_x]",
NULL);
+ T("///x-x.ko", false , false , true, false, NULL ,
NULL);
+
+ /* pathalloc_name alloc_ext kmod comp name ext */
+ T("///x.ko.gz", true , true , true, true, "[x]", "gz");
+ T("///x.ko.gz", false, true , true, true, NULL , "gz");
+ T("///x.ko.gz", true , false , true, true, "[x]", NULL);
+ T("///x.ko.gz", false, false , true, true, NULL , NULL);
+
+ /* path alloc_name alloc_ext kmod comp nameext */
+ T("///x.gz", true , true , false, true, "x.gz" ,"gz");
[PATCH 03/14] perf tools: Add lzma decompression support for kernel module
In short, Fedora compresses kernel modules now (since version 21)
with lzma compression.
Adding lzma decompress support into the dso.c:compressions array
introduced by Nmahyung earlier.
Signed-off-by: Jiri Olsa
Cc: Adrian Hunter
Cc: Arnaldo Carvalho de Melo
Cc: Corey Ashford
Cc: David Ahern
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
---
tools/perf/Makefile.perf | 2 +
tools/perf/config/Makefile | 10 +
tools/perf/util/Build | 1 +
tools/perf/util/dso.c | 3 ++
tools/perf/util/lzma.c | 95 ++
tools/perf/util/util.h | 4 ++
6 files changed, 115 insertions(+)
create mode 100644 tools/perf/util/lzma.c
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index ec4c063ed9f3..9b981c9e3340 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -71,6 +71,8 @@ include config/utilities.mak
#
# Define NO_LIBBABELTRACE if you do not want libbabeltrace support
# for CTF data format.
+#
+# Define NO_LZMA if you do not want to support compressed (xz) kernel modules
ifeq ($(srctree),)
srctree := $(patsubst %/,%,$(dir $(shell pwd)))
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index d77bcea691dd..ba9f9811812e 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -660,6 +660,16 @@ ifndef NO_ZLIB
endif
endif
+ifndef NO_LZMA
+ ifeq ($(feature-lzma), 1)
+CFLAGS += -DHAVE_LZMA_SUPPORT
+EXTLIBS += -llzma
+$(call detected,CONFIG_LZMA)
+ else
+NO_LZMA := 1
+ endif
+endif
+
ifndef NO_BACKTRACE
ifeq ($(feature-backtrace), 1)
CFLAGS += -DHAVE_BACKTRACE_SUPPORT
diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 972a6e0da7ad..797490a40075 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -94,6 +94,7 @@ libperf-y += scripting-engines/
libperf-$(CONFIG_PERF_REGS) += perf_regs.o
libperf-$(CONFIG_ZLIB) += zlib.o
+libperf-$(CONFIG_LZMA) += lzma.o
CFLAGS_config.o += -DETC_PERFCONFIG="BUILD_STR($(ETC_PERFCONFIG_SQ))"
CFLAGS_exec_cmd.o += -DPERF_EXEC_PATH="BUILD_STR($(perfexecdir_SQ))"
-DPREFIX="BUILD_STR($(prefix_SQ))"
diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 814554d1b857..be368414036c 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -148,6 +148,9 @@ static const struct {
#ifdef HAVE_ZLIB_SUPPORT
{ "gz", gzip_decompress_to_file },
#endif
+#ifdef HAVE_LZMA_SUPPORT
+ { "xz", lzma_decompress_to_file },
+#endif
{ NULL, NULL },
};
diff --git a/tools/perf/util/lzma.c b/tools/perf/util/lzma.c
new file mode 100644
index ..95a1acb61245
--- /dev/null
+++ b/tools/perf/util/lzma.c
@@ -0,0 +1,95 @@
+#include
+#include
+#include
+#include "util.h"
+#include "debug.h"
+
+#define BUFSIZE 8192
+
+static const char *lzma_strerror(lzma_ret ret)
+{
+ switch ((int) ret) {
+ case LZMA_MEM_ERROR:
+ return "Memory allocation failed";
+ case LZMA_OPTIONS_ERROR:
+ return "Unsupported decompressor flags";
+ case LZMA_FORMAT_ERROR:
+ return "The input is not in the .xz format";
+ case LZMA_DATA_ERROR:
+ return "Compressed file is corrupt";
+ case LZMA_BUF_ERROR:
+ return "Compressed file is truncated or otherwise corrupt";
+ default:
+ return "Unknown error, possibly a bug";
+ }
+}
+
+int lzma_decompress_to_file(const char *input, int output_fd)
+{
+ lzma_action action = LZMA_RUN;
+ lzma_stream strm = LZMA_STREAM_INIT;
+ lzma_ret ret;
+
+ u8 buf_in[BUFSIZE];
+ u8 buf_out[BUFSIZE];
+ FILE *infile;
+
+ infile = fopen(input, "rb");
+ if (!infile) {
+ pr_err("lzma: fopen failed on %s: '%s'\n",
+ input, strerror(errno));
+ return -1;
+ }
+
+ ret = lzma_stream_decoder(&strm, UINT64_MAX, LZMA_CONCATENATED);
+ if (ret != LZMA_OK) {
+ pr_err("lzma: lzma_stream_decoder failed %s (%d)\n",
+ lzma_strerror(ret), ret);
+ return -1;
+ }
+
+ strm.next_in = NULL;
+ strm.avail_in = 0;
+ strm.next_out = buf_out;
+ strm.avail_out = sizeof(buf_out);
+
+ while (1) {
+ if (strm.avail_in == 0 && !feof(infile)) {
+ strm.next_in = buf_in;
+ strm.avail_in = fread(buf_in, 1, sizeof(buf_in),
infile);
+
+ if (ferror(infile)) {
+ pr_err("lzma: read error: %s\n",
strerror(errno));
+ return -1;
+ }
+
+ if (feof(infile))
+ action = LZMA_FINISH;
+ }
+
+ ret = lzma_code(&strm, action);
+
+ if (strm.avail_out == 0 || ret == LZM
Re: [RESEND PATCH 4/6] gpio: arizona: Add support for WM8280/WM8281
On Tue, 03 Mar 2015, Charles Keepax wrote:
> From: Richard Fitzgerald
>
> Signed-off-by: Richard Fitzgerald
> Acked-by: Linus Walleij
> Signed-off-by: Charles Keepax
> ---
> drivers/gpio/gpio-arizona.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Applied, thanks.
Will send out pull-request once this has had time to soak in -next.
> diff --git a/drivers/gpio/gpio-arizona.c b/drivers/gpio/gpio-arizona.c
> index fe369f5..9665d0a 100644
> --- a/drivers/gpio/gpio-arizona.c
> +++ b/drivers/gpio/gpio-arizona.c
> @@ -116,6 +116,7 @@ static int arizona_gpio_probe(struct platform_device
> *pdev)
> switch (arizona->type) {
> case WM5102:
> case WM5110:
> + case WM8280:
> case WM8997:
> arizona_gpio->gpio_chip.ngpio = 5;
> break;
--
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: [RESEND PATCH 3/6] regulator: arizona-micsupp: Add support for WM8280/WM8281
On Tue, 03 Mar 2015, Charles Keepax wrote:
> From: Richard Fitzgerald
>
> Signed-off-by: Richard Fitzgerald
> Reviewed-by: Mark Brown
> Signed-off-by: Charles Keepax
> ---
> drivers/regulator/arizona-micsupp.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Applied, thanks.
Will send out pull-request once this has had time to soak in -next.
> diff --git a/drivers/regulator/arizona-micsupp.c
> b/drivers/regulator/arizona-micsupp.c
> index 2007900..bfe5dac 100644
> --- a/drivers/regulator/arizona-micsupp.c
> +++ b/drivers/regulator/arizona-micsupp.c
> @@ -246,6 +246,7 @@ static int arizona_micsupp_probe(struct platform_device
> *pdev)
>*/
> switch (arizona->type) {
> case WM5110:
> + case WM8280:
> desc = &arizona_micsupp_ext;
> micsupp->init_data = arizona_micsupp_ext_default;
> break;
--
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/
[PATCH tip/core/rcu 1/7] rcu: Abstract default callback-list initialization from init_callback_list()
From: "Paul E. McKenney"
In preparation for early-boot posting of callbacks, this commit abstracts
initialization of the default (non-no-CB) callbacks list from the
init_callback_list() function into a new init_default_callback_list()
function.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 48d640ca1a05..f8cdb92da10b 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1328,20 +1328,30 @@ void rcu_cpu_stall_reset(void)
}
/*
- * Initialize the specified rcu_data structure's callback list to empty.
+ * Initialize the specified rcu_data structure's default callback list
+ * to empty. The default callback list is the one that is not used by
+ * no-callbacks CPUs.
*/
-static void init_callback_list(struct rcu_data *rdp)
+static void init_default_callback_list(struct rcu_data *rdp)
{
int i;
- if (init_nocb_callback_list(rdp))
- return;
rdp->nxtlist = NULL;
for (i = 0; i < RCU_NEXT_SIZE; i++)
rdp->nxttail[i] = &rdp->nxtlist;
}
/*
+ * Initialize the specified rcu_data structure's callback list to empty.
+ */
+static void init_callback_list(struct rcu_data *rdp)
+{
+ if (init_nocb_callback_list(rdp))
+ return;
+ init_default_callback_list(rdp);
+}
+
+/*
* Determine the value that ->completed will have at the end of the
* next subsequent grace period. This is used to tag callbacks so that
* a CPU can invoke callbacks in a timely fashion even if that CPU has
--
1.8.1.5
--
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: [RESEND PATCH 6/6] ASoC: arizona: Add support for WM8280/WM8281
On Tue, 03 Mar 2015, Charles Keepax wrote:
> From: Richard Fitzgerald
>
> Signed-off-by: Richard Fitzgerald
> Acked-by: Mark Brown
> Signed-off-by: Charles Keepax
> ---
> sound/soc/codecs/arizona.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
Applied, thanks.
Will send out pull-request once this has had time to soak in -next.
> diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c
> index 4c90602..95d31d6 100644
> --- a/sound/soc/codecs/arizona.c
> +++ b/sound/soc/codecs/arizona.c
> @@ -280,6 +280,7 @@ int arizona_init_gpio(struct snd_soc_codec *codec)
>
> switch (arizona->type) {
> case WM5110:
> + case WM8280:
> snd_soc_dapm_disable_pin(&codec->dapm, "DRC2 Signal Activity");
> break;
> default:
> @@ -1728,6 +1729,7 @@ static int arizona_calc_fratio(struct arizona_fll *fll,
>
> switch (fll->arizona->type) {
> case WM5110:
> + case WM8280:
> if (fll->arizona->rev < 3 || sync)
> return init_ratio;
> break;
--
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/
[PATCH tip/core/rcu 0/7] Early-boot RCU callbacks for v4.1
Hello! This series allows RCU callbacks to be posted very early at boot time, even before rcu_init() is called. 1. Abstract initialization of the default (non-no-CB) callbacks list from the init_callback_list() function into a new init_default_callback_list() function. 2. Initialize rcu_state structures' ->rda pointers to per-CPU rcu_data structures at compile time, so that this linkage is established for early-boot usage. 3. Remove diagnostics that currently splat in the presence of early-boot RCU callbacks. 4. Update no-CBs diagnostics to allow for early-boot RCU callbacks. 5. Make RCU's CPU-hotplug online code avoid initializing non-empty RCU callback lists in order to avoid leaking early-boot callbacks. 6. When a given CPU is determined to be a no-CBs CPU, move any early-boot callbacks to its no-CBs callback list. 7. Move the early-boot callback tests to precede rcu_init()'s initialization code, the better to test all the above. Thanx, Paul b/kernel/rcu/tree.c| 52 - b/kernel/rcu/tree_plugin.h | 27 --- 2 files changed, 51 insertions(+), 28 deletions(-) -- 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 tip/core/rcu 3/7] rcu: Prevent early-boot RCU callbacks from splatting
From: "Paul E. McKenney"
Currently, a call_rcu() that precedes rcu_init() will splat due to the
callback lists not having yet been initialized. This commit causes the
first such callback to initialize the boot CPU's RCU callback list.
Note that this commit does not change rcu_init()-time initialization,
which means that the callback will be discarded at rcu_init() time.
Fixing this is the job of later commits.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index d2fa95e4a268..fcfdbe53bb70 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2838,11 +2838,21 @@ __call_rcu(struct rcu_head *head, void (*func)(struct
rcu_head *rcu),
if (cpu != -1)
rdp = per_cpu_ptr(rsp->rda, cpu);
- offline = !__call_rcu_nocb(rdp, head, lazy, flags);
- WARN_ON_ONCE(offline);
- /* _call_rcu() is illegal on offline CPU; leak the callback. */
- local_irq_restore(flags);
- return;
+ if (likely(rdp->mynode)) {
+ /* Post-boot, so this should be for a no-CBs CPU. */
+ offline = !__call_rcu_nocb(rdp, head, lazy, flags);
+ WARN_ON_ONCE(offline);
+ /* Offline CPU, _call_rcu() illegal, leak callback. */
+ local_irq_restore(flags);
+ return;
+ }
+ /*
+* Very early boot, before rcu_init(). Initialize if needed
+* and then drop through to queue the callback.
+*/
+ BUG_ON(cpu != -1);
+ if (!likely(rdp->nxtlist))
+ init_default_callback_list(rdp);
}
ACCESS_ONCE(rdp->qlen) = rdp->qlen + 1;
if (lazy)
--
1.8.1.5
--
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] x86: svm: use kvm_fast_pio_in()
2015-03-02 15:02-0600, Joel Schopp:
> +int kvm_fast_pio_in(struct kvm_vcpu *vcpu, int size, unsigned short port)
> +{
> + unsigned long val;
> + int ret = emulator_pio_in_emulated(&vcpu->arch.emulate_ctxt, size,
> +port, &val, 1);
> +
Btw. does this return 1 in some scenario?
> + if (ret)
> + kvm_register_write(vcpu, VCPU_REGS_RAX, val);
> + else
> + vcpu->arch.complete_userspace_io = complete_fast_pio;
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(kvm_fast_pio_in);
--
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 11/20] power_supply: Change ownership from driver to core
On Thu, Feb 26, 2015 at 12:31:13PM +0100, Krzysztof Kozlowski wrote: > On czw, 2015-02-26 at 12:28 +0100, Krzysztof Kozlowski wrote: > > On śro, 2015-02-25 at 22:14 -0800, Darren Hart wrote: > > > On Thu, Feb 26, 2015 at 01:45:22AM +0100, Sebastian Reichel wrote: > > > > (...) > > > > > > I would like to merge this via the power supply subsystem. Some of > > > > the files being patched are not under my maintainence, though. It > > > > would be nice if I get an Acked-By from their maintainers. > > > > > > > > As far as I can see this patch is currently missing feedback from: > > > > > > > > arch/x86/platform/olpc: x86 Maintainers > > > > drivers/acpi: Rafael J. Wysocki, Len Brown > > > > drivers/hid: Jiri Kosina > > > > drivers/platform/x86: Darren Hart > > > > > > For compal-laptop.c: > > > > > > Acked-by: Darren Hart > > (previous mail sent by mistake) > > Hi Darren, > > Could you also look at my other fixes sent few days ago: > https://lkml.org/lkml/2015/2/20/158 > compal-laptop: Check return value of power_supply_register > > It touches the same line so the patchset power-supply-rework depends on > it to avoid conflicts. If the fix looks OK, maybe it could go through > Sebastian's tree with your ack? Done, and apologies for the delay. Going through Sebastien is preferred, thanks. -- Darren Hart Intel Open Source Technology Center -- 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: [RFT PATCH v3 2/2] compal-laptop: Check return value of power_supply_register
On Fri, Feb 20, 2015 at 02:13:35PM +0100, Krzysztof Kozlowski wrote:
> The return value of power_supply_register() call was not checked and
> even on error probe() function returned 0. If registering failed then
> during unbind the driver tried to unregister power supply which was not
> actually registered.
>
> This could lead to memory corruption because power_supply_unregister()
> unconditionally cleans up given power supply.
>
> Fix this by checking return status of power_supply_register() call. In
> case of failure, clean up sysfs entries and fail the probe.
>
> Signed-off-by: Krzysztof Kozlowski
> Fixes: 9be0fcb5ed46 ("compal-laptop: add JHL90, battery & hwmon interface")
> Cc:
Acked-by: Darren Hart
--
Darren Hart
Intel Open Source Technology Center
--
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] Revert "drm/i915: Switch planes from transitional helpers to full atomic helpers"
On Mon, Mar 02, 2015 at 04:35:20PM +0100, Daniel Vetter wrote:
> This reverts commit 3f678c96abb43a977d2ea41aefccdc49e8a3e896.
>
> We've been a bit too optimistic with this one here :(
>
> The trouble is that internally we're still using these plane
> update/disable hooks. Which was totally ok pre-atomic since the drm
> core did all the book-keeping updating and these just mostly updated
> hw state. But with atomic there's lots more going on, and it causes
> heaps of trouble with the load detect code.
>
> This one specifically cause a deadlock since both the load detect code
> and the nested plane atomic helper functions tried to grab the same
> locks. It only blows up because of the evil tricks though we play with
> the implicit ww acquire context.
>
> Applying this revert unearths the NULL deref on already freed
> framebuffer objects reported as a regression in 4.0 by various people.
>
> Fixing this will be fairly invasive, hence revert even for the
> 4.1-next queue.
>
> Cc: Matt Roper
> Cc: Linus Torvalds
> Cc: Paul Bolle
> Signed-off-by: Daniel Vetter
Queued for -next with Matt's ack.
-Daniel
> ---
> Just to make it really clear: This is 4.1-next material. It's simply
> the explanation for why we didn't notice the oops ourselves. The 4.0
> oops itself looks like some glue lacking in the load detect code,
> still working on that one.
> -Daniel
> ---
> drivers/gpu/drm/i915/intel_display.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 3156d77b2215..cc3305e30c1b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12179,8 +12179,8 @@ void intel_plane_destroy(struct drm_plane *plane)
> }
>
> const struct drm_plane_funcs intel_plane_funcs = {
> - .update_plane = drm_atomic_helper_update_plane,
> - .disable_plane = drm_atomic_helper_disable_plane,
> + .update_plane = drm_plane_helper_update,
> + .disable_plane = drm_plane_helper_disable,
> .destroy = intel_plane_destroy,
> .set_property = drm_atomic_helper_plane_set_property,
> .atomic_get_property = intel_plane_atomic_get_property,
> --
> 1.8.4.rc3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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] x86: svm: use kvm_fast_pio_in()
2015-03-02 15:02-0600, Joel Schopp:
> From: David Kaplan
>
> We can make the in instruction go faster the same way the out instruction is
> already.
(How much faster do benchmarks run?)
> Changes from v2[Joel]:
> * changed rax from u32 to unsigned long
> * changed a couple return 0 to BUG_ON()
> * changed 8 to sizeof(new_rax)
> * added trace hook
> * removed redundant clearing of count
> Changes from v1[Joel]
> * Added kvm_fast_pio_in() implementation that was left out of v1
>
> Signed-off-by: David Kaplan
> [extracted from larger unlrelated patch, forward ported, addressed reviews,
> tested]
> Signed-off-by: Joel Schopp
> ---
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> @@ -5463,6 +5463,36 @@ int kvm_fast_pio_out(struct kvm_vcpu *vcpu, int size,
> unsigned short port)
> }
> EXPORT_SYMBOL_GPL(kvm_fast_pio_out);
>
> +static int complete_fast_pio(struct kvm_vcpu *vcpu)
(complete_fast_pio_in()?)
> +{
> + unsigned long new_rax = kvm_register_read(vcpu, VCPU_REGS_RAX);
Shouldn't we handle writes in EAX differently than in AX and AL, because
of implicit zero extension.
> +
> + BUG_ON(!vcpu->arch.pio.count);
> + BUG_ON(vcpu->arch.pio.count * vcpu->arch.pio.size > sizeof(new_rax));
(Looking at it again, a check for 'vcpu->arch.pio.count == 1' would be
sufficient.)
> +
> + memcpy(&new_rax, vcpu, sizeof(new_rax));
> + trace_kvm_pio(KVM_PIO_IN, vcpu->arch.pio.port, vcpu->arch.pio.size,
> + vcpu->arch.pio.count, vcpu->arch.pio_data);
> + kvm_register_write(vcpu, VCPU_REGS_RAX, new_rax);
> + vcpu->arch.pio.count = 0;
I think it is better to call emulator_pio_in_emulated directly, like
emulator_pio_in_out(&vcpu->arch.emulate_ctxt, vcpu->arch.pio.size,
vcpu->arch.pio.port, &new_rax, 1);
kvm_register_write(vcpu, VCPU_REGS_RAX, new_rax);
because we know that vcpu->arch.pio.count != 0.
Refactoring could avoid the weird vcpu->ctxt->vcpu conversion.
(A better name is always welcome.)
---
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 96a8333f3db0..d0e5b086f2e1 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4663,22 +4663,23 @@ static int emulator_pio_in_out(struct kvm_vcpu *vcpu,
int size,
return 0;
}
+static void emulator_complete_pio_in(struct kvm_vcpu *vcpu, int size,
+ unsigned short port, void *val, unsigned int count)
+{
+ memcpy(val, vcpu->arch.pio_data, size * count);
+ trace_kvm_pio(KVM_PIO_IN, port, size, count, vcpu->arch.pio_data);
+ vcpu->arch.pio.count = 0;
+}
+
static int emulator_pio_in_emulated(struct x86_emulate_ctxt *ctxt,
int size, unsigned short port, void *val,
unsigned int count)
{
struct kvm_vcpu *vcpu = emul_to_vcpu(ctxt);
- int ret;
- if (vcpu->arch.pio.count)
- goto data_avail;
-
- ret = emulator_pio_in_out(vcpu, size, port, val, count, true);
- if (ret) {
-data_avail:
- memcpy(val, vcpu->arch.pio_data, size * count);
- trace_kvm_pio(KVM_PIO_IN, port, size, count,
vcpu->arch.pio_data);
- vcpu->arch.pio.count = 0;
+ if (vcpu->arch.pio.count ||
+ emulator_pio_in_out(vcpu, size, port, val, count, true)) {
+ emulator_complete_pio_in(vcpu, size, port, val, count);
return 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: [RFC PATCH 0/4] make memtest a generic kernel feature
On Mon, Mar 02, 2015 at 02:55:41PM +, Vladimir Murzin wrote: > Hi, Hi Vladimir, > Memtest is a simple feature which fills the memory with a given set of > patterns and validates memory contents, if bad memory regions is detected it > reserves them via memblock API. Since memblock API is widely used by other > architectures this feature can be enabled outside of x86 world. > > This patch set promotes memtest to live under generic mm umbrella and enables > memtest feature for arm/arm64. > > Patches are built on top of 4.0-rc1 Thanks for putting this together. I've found this extremely useful for tracking down an issue with some errant DMA on an arm64 platform. For the first three patches: Tested-by: Mark Rutland Thanks, Mark. > > Vladimir Murzin (4): > mm: move memtest under /mm > memtest: use phys_addr_t for physical addresses > arm64: add support for memtest > arm: add support for memtest > > arch/arm/mm/init.c |3 ++ > arch/arm64/mm/init.c|2 + > arch/x86/Kconfig| 11 > arch/x86/include/asm/e820.h |8 --- > arch/x86/mm/Makefile|2 - > arch/x86/mm/memtest.c | 118 > --- > include/linux/memblock.h|8 +++ > lib/Kconfig.debug | 11 > mm/Makefile |1 + > mm/memtest.c| 118 > +++ > 10 files changed, 143 insertions(+), 139 deletions(-) > delete mode 100644 arch/x86/mm/memtest.c > create mode 100644 mm/memtest.c > > -- > 1.7.9.5 > -- 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 tip/core/rcu 5/6] documentation: Clarify memory-barrier semantics of atomic operations
From: "Paul E. McKenney" All value-returning atomic read-modify-write operations must provide full memory-barrier semantics on both sides of the operation. This commit clarifies the documentation to make it clear that these memory-barrier semantics are provided by the operations themselves, not by their callers. Reported-by: Peter Hurley Signed-off-by: Paul E. McKenney --- Documentation/atomic_ops.txt | 45 ++-- 1 file changed, 23 insertions(+), 22 deletions(-) diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt index 183e41bdcb69..dab6da3382d9 100644 --- a/Documentation/atomic_ops.txt +++ b/Documentation/atomic_ops.txt @@ -201,11 +201,11 @@ These routines add 1 and subtract 1, respectively, from the given atomic_t and return the new counter value after the operation is performed. -Unlike the above routines, it is required that explicit memory -barriers are performed before and after the operation. It must be -done such that all memory operations before and after the atomic -operation calls are strongly ordered with respect to the atomic -operation itself. +Unlike the above routines, it is required that these primitives +include explicit memory barriers that are performed before and after +the operation. It must be done such that all memory operations before +and after the atomic operation calls are strongly ordered with respect +to the atomic operation itself. For example, it should behave as if a smp_mb() call existed both before and after the atomic operation. @@ -233,21 +233,21 @@ These two routines increment and decrement by 1, respectively, the given atomic counter. They return a boolean indicating whether the resulting counter value was zero or not. -It requires explicit memory barrier semantics around the operation as -above. +Again, these primitives provide explicit memory barrier semantics around +the atomic operation. int atomic_sub_and_test(int i, atomic_t *v); This is identical to atomic_dec_and_test() except that an explicit -decrement is given instead of the implicit "1". It requires explicit -memory barrier semantics around the operation. +decrement is given instead of the implicit "1". This primitive must +provide explicit memory barrier semantics around the operation. int atomic_add_negative(int i, atomic_t *v); -The given increment is added to the given atomic counter value. A -boolean is return which indicates whether the resulting counter value -is negative. It requires explicit memory barrier semantics around the -operation. +The given increment is added to the given atomic counter value. A boolean +is return which indicates whether the resulting counter value is negative. +This primitive must provide explicit memory barrier semantics around +the operation. Then: @@ -257,7 +257,7 @@ This performs an atomic exchange operation on the atomic variable v, setting the given new value. It returns the old value that the atomic variable v had just before the operation. -atomic_xchg requires explicit memory barriers around the operation. +atomic_xchg must provide explicit memory barriers around the operation. int atomic_cmpxchg(atomic_t *v, int old, int new); @@ -266,7 +266,7 @@ with the given old and new values. Like all atomic_xxx operations, atomic_cmpxchg will only satisfy its atomicity semantics as long as all other accesses of *v are performed through atomic_xxx operations. -atomic_cmpxchg requires explicit memory barriers around the operation. +atomic_cmpxchg must provide explicit memory barriers around the operation. The semantics for atomic_cmpxchg are the same as those defined for 'cas' below. @@ -279,8 +279,8 @@ If the atomic value v is not equal to u, this function adds a to v, and returns non zero. If v is equal to u then it returns zero. This is done as an atomic operation. -atomic_add_unless requires explicit memory barriers around the operation -unless it fails (returns 0). +atomic_add_unless must provide explicit memory barriers around the +operation unless it fails (returns 0). atomic_inc_not_zero, equivalent to atomic_add_unless(v, 1, 0) @@ -460,9 +460,9 @@ the return value into an int. There are other places where things like this occur as well. These routines, like the atomic_t counter operations returning values, -require explicit memory barrier semantics around their execution. All -memory operations before the atomic bit operation call must be made -visible globally before the atomic bit operation is made visible. +must provide explicit memory barrier semantics around their execution. +All memory operations before the atomic bit operation call must be +made visible globally before the atomic bit operation is made visible. Likewise, the atomic bit operation must be visible globally before any subsequent memory operation is made visible. For example: @@ -536,8 +536,9 @@ except that two underscores are pref
[PATCH tip/core/rcu 2/6] documentation: Update based on on-demand vmstat workers
From: "Paul E. McKenney" Now that the on-demand vmstat workers commit is in mainline, it is possible to eliminate vmstat_update()-induced OS jitter. This commit updates the documentation accordingly. Signed-off-by: Paul E. McKenney --- Documentation/kernel-per-CPU-kthreads.txt | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/Documentation/kernel-per-CPU-kthreads.txt b/Documentation/kernel-per-CPU-kthreads.txt index f3cd299fcc41..81fe051c4447 100644 --- a/Documentation/kernel-per-CPU-kthreads.txt +++ b/Documentation/kernel-per-CPU-kthreads.txt @@ -190,14 +190,16 @@ To reduce its OS jitter, do any of the following: on each CPU, including cs_dbs_timer() and od_dbs_timer(). WARNING: Please check your CPU specifications to make sure that this is safe on your particular system. - d. It is not possible to entirely get rid of OS jitter - from vmstat_update() on CONFIG_SMP=y systems, but you - can decrease its frequency by writing a large value - to /proc/sys/vm/stat_interval. The default value is - HZ, for an interval of one second. Of course, larger - values will make your virtual-memory statistics update - more slowly. Of course, you can also run your workload - at a real-time priority, thus preempting vmstat_update(), + d. As of v3.18, Christoph Lameter's on-demand vmstat workers + commit prevents OS jitter due to vmstat_update() on + CONFIG_SMP=y systems. Before v3.18, is not possible + to entirely get rid of the OS jitter, but you can + decrease its frequency by writing a large value to + /proc/sys/vm/stat_interval. The default value is HZ, + for an interval of one second. Of course, larger values + will make your virtual-memory statistics update more + slowly. Of course, you can also run your workload at + a real-time priority, thus preempting vmstat_update(), but if your workload is CPU-bound, this is a bad idea. However, there is an RFC patch from Christoph Lameter (based on an earlier one from Gilad Ben-Yossef) that -- 1.8.1.5 -- 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] i2c: designware: Suppress error message if platform_get_irq() returns -EPROBE_DEFER
Hi Christian,
On Tue, 2015-03-03 at 17:28 +0100, Christian Ruppert wrote:
> On 2015-03-03 16:27, Alexey Brodkin wrote:
> > There's no point in printing error message if platform_get_irq()
> > returns -EPROBE_DEFER because probe deferring subsystem already outputs
> > message in bootlog like this:
> > --->8---
> > platform e001d000.i2c: Driver i2c_designware requests probe deferral
> > --->8---
> >
> > Moreover in case of probe deferral following message may mislead user:
> > --->8---
> > i2c_designware e001d000.i2c: no irq resource?
> > --->8---
> > even though it's expected that platform_get_irq() may return
> > -EPROBE_DEFER.
> >
> > irq = platform_get_irq(pdev, 0);
> > if (irq < 0) {
> > - dev_err(&pdev->dev, "no irq resource?\n");
> > + if (irq != -EPROBE_DEFER)
> > + dev_err(&pdev->dev, "no irq resource?\n");
>
> Presented like this I wonder if this merits being a dev_err at all.
> Wouldn't dev_dbg be more adequate? This might remove the need for the
> condition and also avoid bothering everyone if something in the platform
> device structures or device tree is not right.
>
> > return irq; /* -ENXIO */
> > }
We've just had similar discussion related to DW APB UART with Andy here
https://lkml.org/lkml/2015/3/3/412
So yes probably we may safely remove error message from here completely.
-Alexey
--
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] scripts: fix link-vmlinux.sh bash-ism
On Fri, Jan 02, 2015 at 04:55:42PM +0100, Michal Marek wrote: > On 2014-12-29 17:34, Sylvain BERTRAND wrote: > > Chocked while compiling linux with dash shell instead of bash shell. > > See: > > http://pubs.opengroup.org/onlinepubs/95399/utilities/trap.html > > Please describe the actual problem in the changelog. I guess it's > because of the 'ERR' trap? Indeed: - ERR is specific to bash - signal names in a trap built-in instruction should be without the SIG prefix Shall I repost a v2 with the above lines? -- Sylvain -- 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 tip/core/rcu 0/6] Documentation updates for 3.21^W4.1
Hello! This series contains a few documentation updates: 1. Record the fact that the rcutree.kthread_prio kernel boot parameter also controls the priority of the grace-period kthreads. 2. Update the kernel-per-CPU-kthreads.txt documentation based on Christoph Lameter's on-demand vmstat workers commit. 3. Update NO_HZ.txt documentation to reflect the fact that POSIX timers are no longer starved on adaptive-ticks CPUs. 4. Update kernel-per-CPU-kthreads.txt documentation to reflect workqueue usage and nosoftlockup boot parameter. 5. Clarify memory-barrier semantics of atomic operations. 6. Clarify control-dependency pairing. Thanx, Paul b/Documentation/atomic_ops.txt | 45 ++-- b/Documentation/kernel-parameters.txt | 14 +--- b/Documentation/kernel-per-CPU-kthreads.txt | 34 + b/Documentation/memory-barriers.txt | 42 ++ b/Documentation/timers/NO_HZ.txt| 10 +- 5 files changed, 85 insertions(+), 60 deletions(-) -- 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 tip/core/rcu 6/6] documentation: Clarify control-dependency pairing
From: "Paul E. McKenney"
This commit explicitly states that control dependencies pair normally
with other barriers, and gives an example of such pairing.
Reported-by: Peter Zijlstra
Signed-off-by: Paul E. McKenney
Acked-by: Peter Zijlstra (Intel)
---
Documentation/memory-barriers.txt | 42 +++
1 file changed, 29 insertions(+), 13 deletions(-)
diff --git a/Documentation/memory-barriers.txt
b/Documentation/memory-barriers.txt
index ca2387ef27ab..6974f1c2b4e1 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -592,9 +592,9 @@ See also the subsection on "Cache Coherency" for a more
thorough example.
CONTROL DEPENDENCIES
-A control dependency requires a full read memory barrier, not simply a data
-dependency barrier to make it work correctly. Consider the following bit of
-code:
+A load-load control dependency requires a full read memory barrier, not
+simply a data dependency barrier to make it work correctly. Consider the
+following bit of code:
q = ACCESS_ONCE(a);
if (q) {
@@ -615,14 +615,15 @@ case what's actually required is:
}
However, stores are not speculated. This means that ordering -is- provided
-in the following example:
+for load-store control dependencies, as in the following example:
q = ACCESS_ONCE(a);
if (q) {
ACCESS_ONCE(b) = p;
}
-Please note that ACCESS_ONCE() is not optional! Without the
+Control dependencies pair normally with other types of barriers.
+That said, please note that ACCESS_ONCE() is not optional! Without the
ACCESS_ONCE(), might combine the load from 'a' with other loads from
'a', and the store to 'b' with other stores to 'b', with possible highly
counterintuitive effects on ordering.
@@ -813,6 +814,8 @@ In summary:
barrier() can help to preserve your control dependency. Please
see the Compiler Barrier section for more information.
+ (*) Control dependencies pair normally with other types of barriers.
+
(*) Control dependencies do -not- provide transitivity. If you
need transitivity, use smp_mb().
@@ -823,14 +826,14 @@ SMP BARRIER PAIRING
When dealing with CPU-CPU interactions, certain types of memory barrier should
always be paired. A lack of appropriate pairing is almost certainly an error.
-General barriers pair with each other, though they also pair with
-most other types of barriers, albeit without transitivity. An acquire
-barrier pairs with a release barrier, but both may also pair with other
-barriers, including of course general barriers. A write barrier pairs
-with a data dependency barrier, an acquire barrier, a release barrier,
-a read barrier, or a general barrier. Similarly a read barrier or a
-data dependency barrier pairs with a write barrier, an acquire barrier,
-a release barrier, or a general barrier:
+General barriers pair with each other, though they also pair with most
+other types of barriers, albeit without transitivity. An acquire barrier
+pairs with a release barrier, but both may also pair with other barriers,
+including of course general barriers. A write barrier pairs with a data
+dependency barrier, a control dependency, an acquire barrier, a release
+barrier, a read barrier, or a general barrier. Similarly a read barrier,
+control dependency, or a data dependency barrier pairs with a write
+barrier, an acquire barrier, a release barrier, or a general barrier:
CPU 1 CPU 2
=== ===
@@ -850,6 +853,19 @@ Or:
y = *x;
+Or even:
+
+ CPU 1 CPU 2
+ === ===
+ r1 = ACCESS_ONCE(y);
+
+ ACCESS_ONCE(y) = 1; if (r2 = ACCESS_ONCE(x)) {
+
+ACCESS_ONCE(y) = 1;
+ }
+
+ assert(r1 == 0 || r2 == 0);
+
Basically, the read barrier always has to be there, even though it can be of
the "weaker" type.
--
1.8.1.5
--
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 tip/core/rcu 1/6] documentation: Update rcutree.kthread_prio for grace-period kthread use
From: "Paul E. McKenney" Now that the rcutree.kthread_prio kernel boot parameter also controls the priority of the grace-period kthreads, update the documentation to reflect this change. Signed-off-by: Paul E. McKenney --- Documentation/kernel-parameters.txt | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index bfcb1a62a7b4..d913e3b4bf0d 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2991,11 +2991,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted. value is one, and maximum value is HZ. rcutree.kthread_prio=[KNL,BOOT] - Set the SCHED_FIFO priority of the RCU - per-CPU kthreads (rcuc/N). This value is also - used for the priority of the RCU boost threads - (rcub/N). Valid values are 1-99 and the default - is 1 (the least-favored priority). + Set the SCHED_FIFO priority of the RCU per-CPU + kthreads (rcuc/N). This value is also used for + the priority of the RCU boost threads (rcub/N) + and for the RCU grace-period kthreads (rcu_bh, + rcu_preempt, and rcu_sched). If RCU_BOOST is + set, valid values are 1-99 and the default is 1 + (the least-favored priority). Otherwise, when + RCU_BOOST is not set, valid values are 0-99 and + the default is zero (non-realtime operation). rcutree.rcu_nocb_leader_stride= [KNL] Set the number of NOCB kthread groups, which -- 1.8.1.5 -- 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 tip/core/rcu 3/6] documentation: Update NO_HZ_FULL interaction with POSIX timers
From: "Paul E. McKenney" POSIX timers are no longer starved on adaptive-ticks CPUs. Instead, they prevent affected CPUs from entering adaptive-ticks mode. This commit therefore updates the NO_HZ.txt documentation. Signed-off-by: Paul E. McKenney --- Documentation/timers/NO_HZ.txt | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/Documentation/timers/NO_HZ.txt b/Documentation/timers/NO_HZ.txt index cca122f25120..6eaf576294f3 100644 --- a/Documentation/timers/NO_HZ.txt +++ b/Documentation/timers/NO_HZ.txt @@ -158,13 +158,9 @@ not come for free: to the need to inform kernel subsystems (such as RCU) about the change in mode. -3. POSIX CPU timers on adaptive-tick CPUs may miss their deadlines - (perhaps indefinitely) because they currently rely on - scheduling-tick interrupts. This will likely be fixed in - one of two ways: (1) Prevent CPUs with POSIX CPU timers from - entering adaptive-tick mode, or (2) Use hrtimers or other - adaptive-ticks-immune mechanism to cause the POSIX CPU timer to - fire properly. +3. POSIX CPU timers prevent CPUs from entering adaptive-tick mode. + Real-time applications needing to take actions based on CPU time + consumption need to use other means of doing so. 4. If there are more perf events pending than the hardware can accommodate, they are normally round-robined so as to collect -- 1.8.1.5 -- 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 tip/core/rcu 4/6] documentation: Update per-CPU kthreads documentation
From: "Paul E. McKenney" Signed-off-by: Paul E. McKenney --- Documentation/kernel-per-CPU-kthreads.txt | 16 +++- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/Documentation/kernel-per-CPU-kthreads.txt b/Documentation/kernel-per-CPU-kthreads.txt index 81fe051c4447..f4cbfe0ba108 100644 --- a/Documentation/kernel-per-CPU-kthreads.txt +++ b/Documentation/kernel-per-CPU-kthreads.txt @@ -205,7 +205,9 @@ To reduce its OS jitter, do any of the following: (based on an earlier one from Gilad Ben-Yossef) that reduces or even eliminates vmstat overhead for some workloads at https://lkml.org/lkml/2013/9/4/379. - e. If running on high-end powerpc servers, build with + e. Boot with "elevator=noop" to avoid workqueue use by + the block layer. + f. If running on high-end powerpc servers, build with CONFIG_PPC_RTAS_DAEMON=n. This prevents the RTAS daemon from running on each CPU every second or so. (This will require editing Kconfig files and will defeat @@ -213,12 +215,12 @@ To reduce its OS jitter, do any of the following: due to the rtas_event_scan() function. WARNING: Please check your CPU specifications to make sure that this is safe on your particular system. - f. If running on Cell Processor, build your kernel with + g. If running on Cell Processor, build your kernel with CBE_CPUFREQ_SPU_GOVERNOR=n to avoid OS jitter from spu_gov_work(). WARNING: Please check your CPU specifications to make sure that this is safe on your particular system. - g. If running on PowerMAC, build your kernel with + h. If running on PowerMAC, build your kernel with CONFIG_PMAC_RACKMETER=n to disable the CPU-meter, avoiding OS jitter from rackmeter_do_timer(). @@ -260,8 +262,12 @@ Purpose: Detect software lockups on each CPU. To reduce its OS jitter, do at least one of the following: 1. Build with CONFIG_LOCKUP_DETECTOR=n, which will prevent these kthreads from being created in the first place. -2. Echo a zero to /proc/sys/kernel/watchdog to disable the +2. Boot with "nosoftlockup=0", which will also prevent these kthreads + from being created. Other related watchdog and softlockup boot + parameters may be found in Documentation/kernel-parameters.txt + and Documentation/watchdog/watchdog-parameters.txt. +3. Echo a zero to /proc/sys/kernel/watchdog to disable the watchdog timer. -3. Echo a large number of /proc/sys/kernel/watchdog_thresh in +4. Echo a large number of /proc/sys/kernel/watchdog_thresh in order to reduce the frequency of OS jitter due to the watchdog timer down to a level that is acceptable for your workload. -- 1.8.1.5 -- 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] x86: Unbreak early processor microcode loading
On Tue, Mar 03, 2015 at 11:10:44PM +0800, Daniel J Blueman wrote: > The changes in 871b72dd "x86: microcode: use smp_call_function_single instead > of set_cpus_allowed, cleanup of synchronization logic" introduced a check > that prevents built-in microcode from being loaded before init starts. > > Conditionalise it on early microcode loading, so we get the expected behaviour > when early microcode loading is enabled, and when it is not. This has > potential > importance as BIOSes often don't load the current microcode. ... probably because they don't have it. Which is also the main reason for the existence of this microcode loader btw :) > > Signed-off-by: Daniel J Blueman > --- > arch/x86/kernel/cpu/microcode/core.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/x86/kernel/cpu/microcode/core.c > b/arch/x86/kernel/cpu/microcode/core.c > index 36a8361..fa7f9fc 100644 > --- a/arch/x86/kernel/cpu/microcode/core.c > +++ b/arch/x86/kernel/cpu/microcode/core.c > @@ -391,9 +391,11 @@ static enum ucode_state microcode_init_cpu(int cpu, bool > refresh_fw) > if (collect_cpu_info(cpu)) > return UCODE_ERROR; > > +#if !defined(CONFIG_MICROCODE_AMD_EARLY) && > !defined(CONFIG_MICROCODE_INTEL_EARLY) > /* --dimm. Trigger a delayed update? */ > if (system_state != SYSTEM_RUNNING) > return UCODE_NFOUND; > +#endif Ok, let me try to understand this correctly: where is this microcode built in, into the kernel? If yes, you should consider enabling the early loading method and build in the microcode into the initrd, see Documentation/x86/early-microcode.txt This is the preferred method as we're applying the microcode much earlier. Back to you. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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] slub memory quarantine
On Tue, 3 Mar 2015, Andrey Ryabinin wrote: > On 03/03/2015 12:10 PM, Dmitry Vyukov wrote: > > Please hold on with this. > > Dmitry Chernenkov is working on a quarantine that works with both slub > > and slab, does not cause spurious OOMs and does not depend on > > slub-debug which has unacceptable performance (acquires global lock). > > I think that it's a separate issue. KASan already depend on slub_debug - it > required for redzones/user tracking. > I think that some parts slub debugging (like user tracking and this > quarantine) > could be moved (for CONFIG_KASAN=y) to the fast path without any locking. In general these features need to be ifdeffed out since they add significant overhead for the data structures and execution paths. -- 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: [RFT PATCH v3 1/2] compal-laptop: Fix leaking hwmon device
On Fri, Feb 20, 2015 at 02:13:34PM +0100, Krzysztof Kozlowski wrote:
> The commit c2be45f09bb0 ("compal-laptop: Use
> devm_hwmon_device_register_with_groups") wanted to change the
> registering of hwmon device to resource-managed version. It mostly did
> it except the main thing - it forgot to use devm-like function so the
> hwmon device leaked after device removal or probe failure.
>
> Signed-off-by: Krzysztof Kozlowski
> Fixes: c2be45f09bb0 ("compal-laptop: Use
> devm_hwmon_device_register_with_groups")
> Cc:
Acked-by: Darren Hart
(Assuming this is going through Sebastien's tree)
--
Darren Hart
Intel Open Source Technology Center
--
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] bcm63xx_enet: fix poll callback.
On Tue, 2015-03-03 at 08:09 -0800, Alexander Duyck wrote: > This rmb() can probably be replaced with a dma_rmb() since it is just a > coherent/coherent ordering you are concerned with based on the comment. Right, but this patch would be a stable candidate, where dma_rmb() does not exist yet. -- 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] x86: Fix sibling map with NumaChip
On Tue, Mar 03, 2015 at 11:18:13PM +0800, Daniel J Blueman wrote:
> @@ -180,11 +180,15 @@ static int __init numachip_probe(void)
>
> static void fixup_cpu_id(struct cpuinfo_x86 *c, int node)
> {
> -
> - if (c->phys_proc_id != node) {
> - c->phys_proc_id = node;
> - per_cpu(cpu_llc_id, smp_processor_id()) = node;
> - }
> + u64 val;
> + u32 nodes;
> +
> + per_cpu(cpu_llc_id, smp_processor_id()) = node;
> +
> + /* Account for nodes per socket in multi-core-module processors */
> + rdmsrl(MSR_FAM10H_NODE_ID, val);
You need to check a CPUID bit before accessing that MSR, see
amd_get_topology(). get_apic_id() in apic_numachip.c should be corrected
too.
Thanks.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
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 12/38] perf tools: Introduce thread__comm_time() helpers
On Tue, Mar 03, 2015 at 12:07:24PM +0900, Namhyung Kim wrote:
> When data file indexing is enabled, it processes all task, comm and mmap
> events first and then goes to the sample events. So all it sees is the
> last comm of a thread although it has information at the time of sample.
>
> Sort thread's comm by time so that it can find appropriate comm at the
> sample time. The thread__comm_time() will mostly work even if
> PERF_SAMPLE_TIME bit is off since in that case, sample->time will be
> -1 so it'll take the last comm anyway.
>
> Cc: Frederic Weisbecker
> Signed-off-by: Namhyung Kim
> ---
> tools/perf/util/thread.c | 33 -
> tools/perf/util/thread.h | 2 ++
> 2 files changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
> index 9ebc8b1f9be5..ad96725105c2 100644
> --- a/tools/perf/util/thread.c
> +++ b/tools/perf/util/thread.c
> @@ -103,6 +103,21 @@ struct comm *thread__exec_comm(const struct thread
> *thread)
> return last;
> }
>
> +struct comm *thread__comm_time(const struct thread *thread, u64 timestamp)
Usually thread__comm_foo() would suggest that we return the "foo" from a thread
comm.
For example thread__comm_len() returns the len of the last thread comm.
thread__comm_str() returns the string of the last thread comm.
So thread__comm_time() suggests that we return the timestamp of the default
thread comm.
Ideally all thread__comm_foo() accessors should now take a timestamp as an
argument. Now there
are quite some callers of such APIs, I'm not sure they will all turn into
passing a precise timestamp,
but the current callers are interested in the last comm so perhaps those can be
turned into thread__last_comm[_str]().
The call would gain some clarity.
> +{
> + struct comm *comm;
> +
> + list_for_each_entry(comm, &thread->comm_list, list) {
> + if (timestamp >= comm->start)
> + return comm;
> + }
> +
> + if (list_empty(&thread->comm_list))
> + return NULL;
> +
> + return list_last_entry(&thread->comm_list, struct comm, list);
> +}
Yes, handling the thread's comm lifecycle correctly with fetching the right
comm at a given time is
the evolution I had in mind. I haven't looked at the rest of your patchset but
this
change alone seem to go to the right direction.
Thanks!
> +
> int __thread__set_comm(struct thread *thread, const char *str, u64 timestamp,
> bool exec)
> {
> @@ -118,7 +133,13 @@ int __thread__set_comm(struct thread *thread, const char
> *str, u64 timestamp,
> new = comm__new(str, timestamp, exec);
> if (!new)
> return -ENOMEM;
> - list_add(&new->list, &thread->comm_list);
> +
> + /* sort by time */
> + list_for_each_entry(curr, &thread->comm_list, list) {
> + if (timestamp >= curr->start)
> + break;
> + }
> + list_add_tail(&new->list, &curr->list);
>
> if (exec)
> unwind__flush_access(thread);
> @@ -139,6 +160,16 @@ const char *thread__comm_str(const struct thread *thread)
> return comm__str(comm);
> }
>
> +const char *thread__comm_str_time(const struct thread *thread, u64 timestamp)
> +{
> + const struct comm *comm = thread__comm_time(thread, timestamp);
> +
> + if (!comm)
> + return NULL;
> +
> + return comm__str(comm);
> +}
> +
> /* CHECKME: it should probably better return the max comm len from its comm
> list */
> int thread__comm_len(struct thread *thread)
> {
> diff --git a/tools/perf/util/thread.h b/tools/perf/util/thread.h
> index 160fd066a7d1..be67c3bad5e7 100644
> --- a/tools/perf/util/thread.h
> +++ b/tools/perf/util/thread.h
> @@ -53,7 +53,9 @@ static inline int thread__set_comm(struct thread *thread,
> const char *comm,
> int thread__comm_len(struct thread *thread);
> struct comm *thread__comm(const struct thread *thread);
> struct comm *thread__exec_comm(const struct thread *thread);
> +struct comm *thread__comm_time(const struct thread *thread, u64 timestamp);
> const char *thread__comm_str(const struct thread *thread);
> +const char *thread__comm_str_time(const struct thread *thread, u64
> timestamp);
> void thread__insert_map(struct thread *thread, struct map *map);
> int thread__fork(struct thread *thread, struct thread *parent, u64
> timestamp);
> size_t thread__fprintf(struct thread *thread, FILE *fp);
> --
> 2.2.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: [RFC PATCH v4 23/34] ftrace: notify kprobe when ftrace is initialized.
On Mon 2015-03-02 22:25:01, Wang Nan wrote:
> Makes ftrace calls init_kprobes_on_ftrace() when ftrace_init()
> finished. Before this call, marks kprobes on ftrace with
> 'KPROBE_FLAG_FTRACE_EARLY' instead of 'KPROBE_FLAG_FTRACE' to make
> kprobe not to kprobe treats these kprobes as ftrace kprobes.
>
> Following patches should convert such kprobes into kprobes on ftrace.
>
> Signed-off-by: Wang Nan
> ---
> include/linux/kprobes.h | 11 +++
> kernel/kprobes.c| 17 -
> kernel/trace/ftrace.c | 2 ++
> 3 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
> index bb2b2c6..96dc842 100644
> --- a/include/linux/kprobes.h
> +++ b/include/linux/kprobes.h
> @@ -130,6 +130,8 @@ struct kprobe {
> * this flag is only for optimized_kprobe.
> */
> #define KPROBE_FLAG_FTRACE 8 /* probe is using ftrace */
> +/* probe will use ftrace, but ftrace is not ready when registering */
> +#define KPROBE_FLAG_FTRACE_EARLY 16
>
> /* Has this kprobe gone ? */
> static inline int kprobe_gone(struct kprobe *p)
> @@ -269,6 +271,14 @@ extern void show_registers(struct pt_regs *regs);
> extern void kprobes_inc_nmissed_count(struct kprobe *p);
> extern bool arch_within_kprobe_blacklist(unsigned long addr);
>
> +#if defined(CONFIG_EARLY_KPROBES) && defined(CONFIG_KPROBES_ON_FTRACE)
> +extern void init_kprobes_on_ftrace(void);
> +#else
> +static inline void init_kprobes_on_ftrace(void)
> +{
> +}
> +#endif // CONFIG_EARLY_KPROBES && CONFIG_KPROBES_ON_FTRACE
> +
> #ifdef CONFIG_EARLY_KPROBES
>
> #define NR_EARLY_KPROBES_SLOTS CONFIG_NR_EARLY_KPROBES_SLOTS
> @@ -453,6 +463,7 @@ extern int proc_kprobes_optimization_handler(struct
> ctl_table *table,
> extern void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
> struct ftrace_ops *ops, struct pt_regs *regs);
> extern int arch_prepare_kprobe_ftrace(struct kprobe *p);
> +
> #endif
>
> int arch_check_ftrace_location(struct kprobe *p);
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index 4b7b20a..b5e13ba 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -69,6 +69,11 @@
>
> static int kprobes_initialized;
> static int kprobes_blacklist_initialized;
> +#if defined(CONFIG_KPROBES_ON_FTRACE) && defined(CONFIG_EARLY_KPROBES)
> +static bool kprobes_on_ftrace_initialized __read_mostly = false;
> +#else
> +# define kprobes_on_ftrace_initialized false
> +#endif
>
> bool kprobes_is_early(void)
> {
> @@ -1497,7 +1502,10 @@ int __weak arch_check_ftrace_location(struct kprobe *p)
> /* Given address is not on the instruction boundary */
> if ((unsigned long)p->addr != ftrace_addr)
> return -EILSEQ;
> - p->flags |= KPROBE_FLAG_FTRACE;
> + if (unlikely(!kprobes_on_ftrace_initialized))
> + p->flags |= KPROBE_FLAG_FTRACE_EARLY;
> + else
> + p->flags |= KPROBE_FLAG_FTRACE;
> #else/* !CONFIG_KPROBES_ON_FTRACE */
> return -EINVAL;
> #endif
> @@ -2574,3 +2582,10 @@ module_init(init_kprobes);
>
> /* defined in arch/.../kernel/kprobes.c */
> EXPORT_SYMBOL_GPL(jprobe_return);
> +
> +#if defined(CONFIG_KPROBES_ON_FTRACE) && defined(CONFIG_EARLY_KPROBES)
> +void init_kprobes_on_ftrace(void)
> +{
> + kprobes_on_ftrace_initialized = true;
This flag is later used to decide whether the location is modified by
ftrace or by kprobe, see https://lkml.org/lkml/2015/3/3/4
Therefore you need to convert the probes and set the flag atomically. By
other words, you need to set this flag at the end of
convert_early_kprobes_on_ftrace() when you still hold kprobe_mutex.
Or you need to take the mutex already in init_kprobes_on_frace()
around both changes.
Note that I check only this aspect of this patchset because it was
affected by my fix of the kprobe recovery code.
Best Regards,
Petr
> +}
> +#endif
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 7fa88d0..5cb0269 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -5022,6 +5023,7 @@ void __init ftrace_init(void)
> if (ret)
> pr_warning("Failed to register trace ftrace module exit
> notifier\n");
>
> + init_kprobes_on_ftrace();
> set_ftrace_early_filters();
>
> return;
> --
> 1.8.4
>
> --
> 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 ma
[PATCH 01/14] perf tools: Remove superfluous thread->comm_set setting
It is set by calling thread__set_comm right before the removed line. Signed-off-by: Jiri Olsa Cc: Adrian Hunter Cc: Arnaldo Carvalho de Melo Cc: Corey Ashford Cc: David Ahern Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian --- tools/perf/util/thread.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c index a5dbba95107f..1c8fbc9588c5 100644 --- a/tools/perf/util/thread.c +++ b/tools/perf/util/thread.c @@ -206,7 +206,6 @@ int thread__fork(struct thread *thread, struct thread *parent, u64 timestamp) err = thread__set_comm(thread, comm, timestamp); if (err) return err; - thread->comm_set = true; } thread->ppid = parent->tid; -- 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/
Re: [PATCH 0/4] Staging: rtl8188eu rtw_efuse.c: fix coding style
On Tue, Mar 03, 2015 at 02:49:47PM +0100, Matteo Semenzato wrote: > From: Matteo Semenzato usually [PATCH 0/n] doesnot contain any patch, it can have a summary of your patch series. and since you are doing same type of change on rtl8188eu, i think you could have sent a single patch insted of a series. regards sudip > > This patch fixes the following errors: > ERROR: space prohibited before that ',' > > Signed-off-by: Matteo Semenzato > --- > drivers/staging/rtl8188eu/core/rtw_efuse.c | 4 ++-- -- 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/4] regulator: qcom: Refactor of-parsing code
On Tue 03 Mar 06:13 PST 2015, Mark Brown wrote:
> On Mon, Mar 02, 2015 at 08:25:39PM -0800, Bjorn Andersson wrote:
>
> > + if ((vreg->parts->uV.mask || vreg->parts->mV.mask) &&
> > + (!initdata->constraints.min_uV || !initdata->constraints.max_uV)) {
> > + dev_err(&pdev->dev, "no voltage specified for regulator\n");
> > + return -EINVAL;
> > + }
>
> OK, so it looks like we're using it because we can't read the initial
> hardware state - can we introduce a specific interface for that perhaps?
> A call to query the current constraints might do it. Or possibly just
> change your earlier patch to make sure the constraints are marked const
> would do it, reading them isn't the problem that modifying them is. I
> might've missed some other usage somewhere though.
No, the reason for init_data is this snippet:
/* Regulators with ia property suppports drms */
if (vreg->parts->ia.mask)
init_data->constraints.valid_ops_mask |= REGULATOR_CHANGE_DRMS;
This patch just moves the code around to make it possible to implement
patch 4 as cleanly as possible.
The quoted code checks to see that for regulators with voltage-nobs
(could have checked for set_voltage ops) the of-parser did find voltage
limits. So it's a sanity check that discards regulators with missing
dt parameters.
I did drop this in patch 4, as it's not strictly needed. But the result
is that we will successfully register the regulator and the consumers
will be faced with errors upon trying to set voltage or enable it.
Regards,
Bjorn
--
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/
[RESEND PATCH 4/6] gpio: arizona: Add support for WM8280/WM8281
From: Richard Fitzgerald
Signed-off-by: Richard Fitzgerald
Acked-by: Linus Walleij
Signed-off-by: Charles Keepax
---
drivers/gpio/gpio-arizona.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-arizona.c b/drivers/gpio/gpio-arizona.c
index fe369f5..9665d0a 100644
--- a/drivers/gpio/gpio-arizona.c
+++ b/drivers/gpio/gpio-arizona.c
@@ -116,6 +116,7 @@ static int arizona_gpio_probe(struct platform_device *pdev)
switch (arizona->type) {
case WM5102:
case WM5110:
+ case WM8280:
case WM8997:
arizona_gpio->gpio_chip.ngpio = 5;
break;
--
1.7.2.5
--
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/
[RESEND PATCH 3/6] regulator: arizona-micsupp: Add support for WM8280/WM8281
From: Richard Fitzgerald
Signed-off-by: Richard Fitzgerald
Reviewed-by: Mark Brown
Signed-off-by: Charles Keepax
---
drivers/regulator/arizona-micsupp.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/arizona-micsupp.c
b/drivers/regulator/arizona-micsupp.c
index 2007900..bfe5dac 100644
--- a/drivers/regulator/arizona-micsupp.c
+++ b/drivers/regulator/arizona-micsupp.c
@@ -246,6 +246,7 @@ static int arizona_micsupp_probe(struct platform_device
*pdev)
*/
switch (arizona->type) {
case WM5110:
+ case WM8280:
desc = &arizona_micsupp_ext;
micsupp->init_data = arizona_micsupp_ext_default;
break;
--
1.7.2.5
--
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/
[RESEND PATCH 1/6] mfd: arizona: Add support for WM8280/WM8281
From: Richard Fitzgerald
This adds support for the Wolfson Microelectronics WM8280 and WM8281
codecs.
Signed-off-by: Richard Fitzgerald
Acked-by: Lee Jones
[ Minor fixup to remove potentially uninitialised variable. ]
Signed-off-by: Charles Keepax
---
drivers/mfd/Kconfig |5 +++--
drivers/mfd/arizona-core.c | 15 +--
drivers/mfd/arizona-i2c.c|2 ++
drivers/mfd/arizona-irq.c|1 +
drivers/mfd/arizona-spi.c|2 ++
include/linux/mfd/arizona/core.h |1 +
6 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 0ad88c7..b5fb03c 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1290,10 +1290,11 @@ config MFD_WM5102
Support for Wolfson Microelectronics WM5102 low power audio SoC
config MFD_WM5110
- bool "Wolfson Microelectronics WM5110"
+ bool "Wolfson Microelectronics WM5110 and WM8280/WM8281"
depends on MFD_ARIZONA
help
- Support for Wolfson Microelectronics WM5110 low power audio SoC
+ Support for Wolfson Microelectronics WM5110 and WM8280/WM8281
+ low power audio SoC
config MFD_WM8997
bool "Wolfson Microelectronics WM8997"
diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
index 09ba8f1..9f81998 100644
--- a/drivers/mfd/arizona-core.c
+++ b/drivers/mfd/arizona-core.c
@@ -567,6 +567,7 @@ static int arizona_of_get_core_pdata(struct arizona
*arizona)
const struct of_device_id arizona_of_match[] = {
{ .compatible = "wlf,wm5102", .data = (void *)WM5102 },
{ .compatible = "wlf,wm5110", .data = (void *)WM5110 },
+ { .compatible = "wlf,wm8280", .data = (void *)WM8280 },
{ .compatible = "wlf,wm8997", .data = (void *)WM8997 },
{},
};
@@ -671,6 +672,7 @@ int arizona_dev_init(struct arizona *arizona)
switch (arizona->type) {
case WM5102:
case WM5110:
+ case WM8280:
case WM8997:
for (i = 0; i < ARRAY_SIZE(wm5102_core_supplies); i++)
arizona->core_supplies[i].supply
@@ -834,11 +836,19 @@ int arizona_dev_init(struct arizona *arizona)
#endif
#ifdef CONFIG_MFD_WM5110
case 0x5110:
- type_name = "WM5110";
- if (arizona->type != WM5110) {
+ switch (arizona->type) {
+ case WM5110:
+ type_name = "WM5110";
+ break;
+ case WM8280:
+ type_name = "WM8280";
+ break;
+ default:
+ type_name = "WM5110";
dev_err(arizona->dev, "WM5110 registered as %d\n",
arizona->type);
arizona->type = WM5110;
+ break;
}
apply_patch = wm5110_patch;
break;
@@ -1010,6 +1020,7 @@ int arizona_dev_init(struct arizona *arizona)
ARRAY_SIZE(wm5102_devs), NULL, 0, NULL);
break;
case WM5110:
+ case WM8280:
ret = mfd_add_devices(arizona->dev, -1, wm5110_devs,
ARRAY_SIZE(wm5110_devs), NULL, 0, NULL);
break;
diff --git a/drivers/mfd/arizona-i2c.c b/drivers/mfd/arizona-i2c.c
index 9d4156f..ff782a5d 100644
--- a/drivers/mfd/arizona-i2c.c
+++ b/drivers/mfd/arizona-i2c.c
@@ -44,6 +44,7 @@ static int arizona_i2c_probe(struct i2c_client *i2c,
#endif
#ifdef CONFIG_MFD_WM5110
case WM5110:
+ case WM8280:
regmap_config = &wm5110_i2c_regmap;
break;
#endif
@@ -87,6 +88,7 @@ static int arizona_i2c_remove(struct i2c_client *i2c)
static const struct i2c_device_id arizona_i2c_id[] = {
{ "wm5102", WM5102 },
{ "wm5110", WM5110 },
+ { "wm8280", WM8280 },
{ "wm8997", WM8997 },
{ }
};
diff --git a/drivers/mfd/arizona-irq.c b/drivers/mfd/arizona-irq.c
index 3a3fe7c..d063b94 100644
--- a/drivers/mfd/arizona-irq.c
+++ b/drivers/mfd/arizona-irq.c
@@ -211,6 +211,7 @@ int arizona_irq_init(struct arizona *arizona)
#endif
#ifdef CONFIG_MFD_WM5110
case WM5110:
+ case WM8280:
aod = &wm5110_aod;
switch (arizona->rev) {
diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c
index 8ef58bc..1e845f6 100644
--- a/drivers/mfd/arizona-spi.c
+++ b/drivers/mfd/arizona-spi.c
@@ -44,6 +44,7 @@ static int arizona_spi_probe(struct spi_device *spi)
#endif
#ifdef CONFIG_MFD_WM5110
case WM5110:
+ case WM8280:
regmap_config = &wm5110_spi_regmap;
break;
#endif
@@ -84,6 +85,7 @@ static int arizona_spi_remove(struct spi_device *spi)
static const struct spi_device_id arizona_spi_ids[] = {
{ "wm5102", WM5102 },
{ "wm5110", WM5110 },
+ { "wm8280", WM8280 },
Re: [PATCH 05/14] perf tools: Add dsos__new function
Em Tue, Mar 03, 2015 at 04:29:32PM +0100, Jiri Olsa escreveu:
> Separate the creation of new dso object and its addition
> to the dsos list. It will be used in following patch.
>
> Signed-off-by: Jiri Olsa
> Cc: Adrian Hunter
> Cc: Arnaldo Carvalho de Melo
> Cc: Corey Ashford
> Cc: David Ahern
> Cc: Frederic Weisbecker
> Cc: Ingo Molnar
> Cc: Namhyung Kim
> Cc: Paul Mackerras
> Cc: Peter Zijlstra
> Cc: Stephane Eranian
> ---
> tools/perf/util/dso.c | 21 -
> tools/perf/util/dso.h | 1 +
> 2 files changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
> index be368414036c..fc54cb81c7f8 100644
> --- a/tools/perf/util/dso.c
> +++ b/tools/perf/util/dso.c
> @@ -1005,21 +1005,24 @@ struct dso *dsos__find(const struct dsos *dsos, const
> char *name,
> return dso__find_by_longname(&dsos->root, name);
> }
>
> -struct dso *__dsos__findnew(struct dsos *dsos, const char *name)
> +struct dso *dsos__new(struct dsos *dsos, const char *name)
When I read dsos__new() I think that it will surely return a 'struct dsos'
pointer, as it is the constructor ('__new') for the 'dsos' class. :-)
Right now we don't have a constructor for dsos, because its only used in
machine where they are not m'allocated, i.e. we use just dsos__init(),
but if we ever need a constructor for it, it will be called dsos__new().
So, to use the same rationale for dsos__findnew(), we can call it
dsos__addnew(), because it will not find anything, just add a new dso.
- Arnaldo
> {
> - struct dso *dso = dsos__find(dsos, name, false);
> + struct dso *dso = dso__new(name);
>
> - if (!dso) {
> - dso = dso__new(name);
> - if (dso != NULL) {
> - dsos__add(dsos, dso);
> - dso__set_basename(dso);
> - }
> + if (dso != NULL) {
> + dsos__add(dsos, dso);
> + dso__set_basename(dso);
> }
> -
> return dso;
> }
>
> +struct dso *__dsos__findnew(struct dsos *dsos, const char *name)
> +{
> + struct dso *dso = dsos__find(dsos, name, false);
> +
> + return dso ? dso : dsos__new(dsos, name);
> +}
> +
> size_t __dsos__fprintf_buildid(struct list_head *head, FILE *fp,
> bool (skip)(struct dso *dso, int parm), int parm)
> {
> diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
> index ced92841ff97..a712cbcd3a72 100644
> --- a/tools/perf/util/dso.h
> +++ b/tools/perf/util/dso.h
> @@ -249,6 +249,7 @@ struct dso *dso__kernel_findnew(struct machine *machine,
> const char *name,
> const char *short_name, int dso_type);
>
> void dsos__add(struct dsos *dsos, struct dso *dso);
> +struct dso *dsos__new(struct dsos *dsos, const char *name);
> struct dso *dsos__find(const struct dsos *dsos, const char *name,
> bool cmp_short);
> struct dso *__dsos__findnew(struct dsos *dsos, const char *name);
> --
> 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/
[RESEND PATCH 6/6] ASoC: arizona: Add support for WM8280/WM8281
From: Richard Fitzgerald
Signed-off-by: Richard Fitzgerald
Acked-by: Mark Brown
Signed-off-by: Charles Keepax
---
sound/soc/codecs/arizona.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c
index 4c90602..95d31d6 100644
--- a/sound/soc/codecs/arizona.c
+++ b/sound/soc/codecs/arizona.c
@@ -280,6 +280,7 @@ int arizona_init_gpio(struct snd_soc_codec *codec)
switch (arizona->type) {
case WM5110:
+ case WM8280:
snd_soc_dapm_disable_pin(&codec->dapm, "DRC2 Signal Activity");
break;
default:
@@ -1728,6 +1729,7 @@ static int arizona_calc_fratio(struct arizona_fll *fll,
switch (fll->arizona->type) {
case WM5110:
+ case WM8280:
if (fll->arizona->rev < 3 || sync)
return init_ratio;
break;
--
1.7.2.5
--
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/
[RESEND PATCH 5/6] extcon: arizona: Add support for WM8280/WM8281
From: Richard Fitzgerald
Signed-off-by: Richard Fitzgerald
Acked-by: Chanwoo Choi
Signed-off-by: Charles Keepax
---
drivers/extcon/extcon-arizona.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index 63f01c4..6b5e795 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -1149,6 +1149,7 @@ static int arizona_extcon_probe(struct platform_device
*pdev)
}
break;
case WM5110:
+ case WM8280:
switch (arizona->rev) {
case 0 ... 2:
break;
--
1.7.2.5
--
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/
[RESEND PATCH 2/6] mfd: arizona: Update binding documentation for WM8280
From: Richard Fitzgerald Signed-off-by: Richard Fitzgerald Signed-off-by: Charles Keepax --- Documentation/devicetree/bindings/mfd/arizona.txt | 15 +++ 1 files changed, 11 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt index bfef000..af8646f 100644 --- a/Documentation/devicetree/bindings/mfd/arizona.txt +++ b/Documentation/devicetree/bindings/mfd/arizona.txt @@ -8,6 +8,7 @@ Required properties: - compatible : One of the following chip-specific strings: "wlf,wm5102" "wlf,wm5110" +"wlf,wm8280" "wlf,wm8997" - reg : I2C slave address when connected using I2C, chip select number when using SPI. @@ -26,10 +27,16 @@ Required properties: - #gpio-cells : Must be 2. The first cell is the pin number and the second cell is used to specify optional parameters (currently unused). - - AVDD-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply (wm5102, wm5110), -CPVDD-supply, SPKVDDL-supply (wm5102, wm5110), SPKVDDR-supply (wm5102, -wm5110), SPKVDD-supply (wm8997) : Power supplies for the device, as covered -in Documentation/devicetree/bindings/regulator/regulator.txt + - AVDD-supply, DBVDD1-supply, CPVDD-supply : Power supplies for the device, +as covered in Documentation/devicetree/bindings/regulator/regulator.txt + + - DBVDD2-supply, DBVDD3-supply : Additional databus power supplies (wm5102, +wm5110, wm8280) + + - SPKVDDL-supply, SPKVDDR-supply : Speaker driver power supplies (wm5102, +wm5110, wm8280) + + - SPKVDD-supply : Speaker driver power supply (wm8997) Optional properties: -- 1.7.2.5 -- 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] regulator: core: Expose init_data to of_parse_cb
On Tue 03 Mar 04:50 PST 2015, Mark Brown wrote: > On Mon, Mar 02, 2015 at 08:25:38PM -0800, Bjorn Andersson wrote: > > > Expose the newly created init_data to the driver's parse callback so > > that it can futher enhance it with e.g. constraints of the regulator. > > Why would the driver need to do that? I guess I'll see later on in the > series but the changelog should make that clear. Drivers aren't > supposed to ever need to look at their init data, modifying the init > data from what the machine provied is usually a red flag. > I think what you're getting at is that the init_data should come from a board file or device tree. With the reworkings done in patch 4 this makes more sense than it did before (e.g. I no longer call of_get_regulator_init_data()). However, by calling register_regulator() with dev->of_node being non-NULL and desc->of_match being something that will match a DT entry all init_data is now coming from device tree, through: regulator_register() regulator_of_get_init_data() of_get_regulator_init_data() of_get_regulation_constraints() As this matches a regulator, there is no way for the driver (or anyone else to affect the init_data). The problem at hand is that there is nothing in this code path telling the core that we can do DRMS - something we can figure out in the driver by basically looking at the ops for the registering regulator. > > This is needed because calling regulator_register() with a of_node and > > of_match will overwrite the passed config->init_data. An alternative way > > would be to merge the parsed init_data with the driver provided one. > > Put any explanation as to why the feature is needed in the changelog. Point taken. Let me know if you think I'm on a sane path with the above reasoning and I can resend the patch with a better description of the problem at hand. Regards, Bjorn -- 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 - v7] of: Move of_dma_configure() to device.c to help re-use
On Mon, Mar 2, 2015 at 3:59 PM, Murali Karicheri wrote:
> Move of_dma_configure() to device.c so it can be re-used for PCI devices to
> obtain DMA configuration from DT. Also add a second argument so that for
> PCI, the DT node of root bus host bridge can be used to obtain the DMA
> configuration for the slave PCI device.
>
> Tested-by: Suravee Suthikulpanit (AMD Seattle)
> Signed-off-by: Murali Karicheri
> Signed-off-by: Bjorn Helgaas
> Reviewed-by: Catalin Marinas
> Acked-by: Will Deacon
> CC: Joerg Roedel
> CC: Grant Likely
> CC: Rob Herring
> CC: Russell King
> CC: Arnd Bergmann
Acked-by: Rob Herring
> ---
> - Based on the existing patch applied to arm-pci/pci/iommu for pci next
> (Bjorn)
> - Fixed the build issue reported on ARCH=x86_64
> drivers/of/device.c | 59
> +
> drivers/of/platform.c | 58 ++--
> include/linux/of_device.h |2 ++
> 3 files changed, 63 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index 46d6c75c..31a7875 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -2,6 +2,9 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> #include
> #include
> #include
> @@ -66,6 +69,62 @@ int of_device_add(struct platform_device *ofdev)
> return device_add(&ofdev->dev);
> }
>
> +/**
> + * of_dma_configure - Setup DMA configuration
> + * @dev: Device to apply DMA configuration
> + * @np:Pointer to OF node having DMA configuration
> + *
> + * Try to get devices's DMA configuration from DT and update it
> + * accordingly.
> + *
> + * If platform code needs to use its own special DMA configuration, it
> + * can use a platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE events
> + * to fix up DMA configuration.
> + */
> +void of_dma_configure(struct device *dev, struct device_node *np)
> +{
> + u64 dma_addr, paddr, size;
> + int ret;
> + bool coherent;
> + unsigned long offset;
> + struct iommu_ops *iommu;
> +
> + /*
> +* Set default dma-mask to 32 bit. Drivers are expected to setup
> +* the correct supported dma_mask.
> +*/
> + dev->coherent_dma_mask = DMA_BIT_MASK(32);
> +
> + /*
> +* Set it to coherent_dma_mask by default if the architecture
> +* code has not set it.
> +*/
> + if (!dev->dma_mask)
> + dev->dma_mask = &dev->coherent_dma_mask;
> +
> + ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
> + if (ret < 0) {
> + dma_addr = offset = 0;
> + size = dev->coherent_dma_mask;
> + } else {
> + offset = PFN_DOWN(paddr - dma_addr);
> + dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
> + }
> +
> + dev->dma_pfn_offset = offset;
> +
> + coherent = of_dma_is_coherent(np);
> + dev_dbg(dev, "device is%sdma coherent\n",
> + coherent ? " " : " not ");
> +
> + iommu = of_iommu_configure(dev, np);
> + dev_dbg(dev, "device is%sbehind an iommu\n",
> + iommu ? " " : " not ");
> +
> + arch_setup_dma_ops(dev, dma_addr, size, iommu, coherent);
> +}
> +EXPORT_SYMBOL_GPL(of_dma_configure);
> +
> int of_device_register(struct platform_device *pdev)
> {
> device_initialize(&pdev->dev);
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 667c6f1..a01f57c 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -19,7 +19,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -150,59 +149,6 @@ struct platform_device *of_device_alloc(struct
> device_node *np,
> }
> EXPORT_SYMBOL(of_device_alloc);
>
> -/**
> - * of_dma_configure - Setup DMA configuration
> - * @dev: Device to apply DMA configuration
> - *
> - * Try to get devices's DMA configuration from DT and update it
> - * accordingly.
> - *
> - * In case if platform code need to use own special DMA configuration,it
> - * can use Platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE event
> - * to fix up DMA configuration.
> - */
> -static void of_dma_configure(struct device *dev)
> -{
> - u64 dma_addr, paddr, size;
> - int ret;
> - bool coherent;
> - unsigned long offset;
> - struct iommu_ops *iommu;
> -
> - /*
> -* Set default dma-mask to 32 bit. Drivers are expected to setup
> -* the correct supported dma_mask.
> -*/
> - dev->coherent_dma_mask = DMA_BIT_MASK(32);
> -
> - /*
> -* Set it to coherent_dma_mask by default if the architecture
> -* code has not set it.
> -*/
> - if (!dev->dma_mask)
> - dev->dma_mask = &dev->coherent_dma_mask;
> -
> - ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
> - if (ret < 0) {
> -
randconfig build error with next-20150303, in drivers/bcma/driver_pcie2.c
Building with the attached random configuration file, drivers/bcma/driver_pcie2.c: In function 'bcma_core_pcie2_up': drivers/bcma/driver_pcie2.c:196:2: error: implicit declaration of function 'pcie_set_readrq' [-Werror=implicit-function-declaration] err = pcie_set_readrq(dev, pcie2->reqsize); ^ cc1: some warnings being treated as errors scripts/Makefile.build:258: recipe for target 'drivers/bcma/driver_pcie2.o' failed make[2]: *** [drivers/bcma/driver_pcie2.o] Error 1 # # Automatically generated file; DO NOT EDIT. # Linux/x86 4.0.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_HWEIGHT=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_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_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=4 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_CONSTRUCTORS=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set 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=y # CONFIG_KERNEL_BZIP2 is not set # 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=y # CONFIG_CROSS_MEMORY_ATTACH is not set CONFIG_FHANDLE=y CONFIG_USELIB=y # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_IRQ_DOMAIN=y # CONFIG_IRQ_DOMAIN_DEBUG is not set 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_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TINY_RCU=y CONFIG_SRCU=y # CONFIG_TASKS_RCU is not set # CONFIG_RCU_STALL_COMMON is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_RCU_KTHREAD_PRIO=0 # CONFIG_RCU_EXPEDITE_BOOT is not set # CONFIG_BUILD_BIN2C is not set # CONFIG_IKCONFIG is not set CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_SUPPORTS_INT128=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set # CONFIG_CGROUP_FREEZER is not set CONFIG_CGROUP_DEVICE=y # CONFIG_CPUSETS is not set # CONFIG_CGROUP_CPUACCT is not set CONFIG_PAGE_COUNTER=y CONFIG_MEMCG=y # CONFIG_MEMCG_SWAP is not set CONFIG_MEMCG_KMEM=y CONFIG_CGROUP_HUGETLB=y # CONFIG_CGROUP_PERF is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y # CONFIG_RT_GROUP_SCHED is not set # CONFIG_BLK_CGROUP is not set CONFIG_CHECKPOINT_RESTORE=y # CONFIG_NAMESPACES is not set CONFIG_SCHED_AUTOGROUP=y CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_LTO_MENU=y # CONFIG_LTO_DISABLE is not set CONFIG_LTO=y # CONFIG_LTO_DEBUG is not set CONFIG_LTO_CP_CLONE=y CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BPF=y CONFIG_EXPERT=y CONFIG_UID16=y CONFIG_MULTIUSER=y CONFIG_SGETMASK_SYSCALL=y # CONFIG_SYSFS_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_PRINTK is not set # CONFIG_BUG is not set # CONFIG_ELF_CORE is not set CONFIG_PCSPKR_PLATFORM=y # CONFIG_BASE_FULL is not set CO
Re: [PATCH v2 7/9] get the random phy addr according to slot_area info
On Tue, Mar 3, 2015 at 3:42 AM, Baoquan He wrote: > > Here input means the region where kernel was linked to load? > > In normal kernel the linked address is 0x100. In your input region > the result of ALIGN(0x13f5ed3b4, CONFIG_PHYSICAL_ALIGN) is 0x14000. > And size of this region is smaller than 16M. It should return in > process_e820_entry() with two checks. > > I guess you use kexec or a special bootloader to put kernel in this > load address. > with patched grub2 that load kernel/initrd/param/cmdline etc above 4G. kernel: read done [ linux 9.55MiB 100% 7.25MiB/s ] params: [13fffc000,13fff] cmdline: [13fffb000,13fffb7fe] kernel: [13c00,13f38cfff] initrd: [139d7c000,13bfff7e3] initrd: read 1 file done [ initrd.img 34.51MiB 100% 11.17MiB/s ] early console in decompress_kernel KASLR using RDTSC... decompress_kernel: input: [0x13e9ed3b4-0x13f36a64b], output: 0x16c00, heap: [0x13f376000-0x13f37dfff] Decompressing Linux... xz... XZ-compressed data is corrupt -- System halted 13c00 is loaded address. 0x13e9ed3b4 is the copied address, and decompress_kernel will use it as input. output is back to 13c00 if aslr is not used. Thanks Yinghai -- 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/5] perf,tools: check and re-organize evsel cpu maps
Em Tue, Mar 03, 2015 at 01:09:29PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Mar 03, 2015 at 03:54:43AM -0500, kan.li...@intel.com escreveu:
> > From: Kan Liang
> >
> > With the patch 1/5, it's possible to group read events from different
> > pmus. "-C" can be used to set cpu list. The cpu list may be incompatible
> > with pmu's cpumask.
> > This patch checks the event's cpu maps, and discard the incompatible cpu
> > maps.
> > event's cpu maps is saved in evsel->cpus during option parse. Then the
> > evlist's cpu maps is created in perf_evlist__create_maps. So the cpu
> > maps can be check and re-organized in perf_evlist__create_maps.
> > Only cpu_list need to check the cpu maps.
>
> Humm, I had something done in this area...
>
> Stephane complained about the confusion about which cpumap to use with
> pmus, so I wrote a patch and sent an RFC, which I think I got no
> comments, lemme dig it...
Here it is, can you take a look? Stephane?
- Arnaldo
commit 9ecdd9b9bf0a7fd5645957ba4e6a98b6ee526109
Author: Arnaldo Carvalho de Melo
Date: Mon Jan 26 13:43:42 2015 -0300
perf evsel: Set evsel->cpus to the evlist->cpus when not constrained
So that we don't need to know about the evlist all the time and can cope
with cases where evsel->cpus were set because it was for an event on a
PMU with a cpumask.
Reported-by: Stephane Eranian
Cc: Adrian Hunter
Cc: Andi Kleen
Cc: Borislav Petkov
Cc: David Ahern
Cc: Don Zickus
Cc: Frederic Weisbecker
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Yan, Zheng
echo Link: http://lkml.kernel.org/n/tip-`ranpwd -l 24`@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index e598e4e98170..ddf41bede0b8 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -163,16 +163,6 @@ static inline void diff_timespec(struct timespec *r,
struct timespec *a,
}
}
-static inline struct cpu_map *perf_evsel__cpus(struct perf_evsel *evsel)
-{
- return (evsel->cpus && !target.cpu_list) ? evsel->cpus :
evsel_list->cpus;
-}
-
-static inline int perf_evsel__nr_cpus(struct perf_evsel *evsel)
-{
- return perf_evsel__cpus(evsel)->nr;
-}
-
static void perf_evsel__reset_stat_priv(struct perf_evsel *evsel)
{
int i;
@@ -202,7 +192,7 @@ static int perf_evsel__alloc_prev_raw_counts(struct
perf_evsel *evsel)
size_t sz;
sz = sizeof(*evsel->counts) +
-(perf_evsel__nr_cpus(evsel) * sizeof(struct perf_counts_values));
+(cpu_map__nr(evsel->cpus) * sizeof(struct perf_counts_values));
addr = zalloc(sz);
if (!addr)
@@ -235,7 +225,7 @@ static int perf_evlist__alloc_stats(struct perf_evlist
*evlist, bool alloc_raw)
evlist__for_each(evlist, evsel) {
if (perf_evsel__alloc_stat_priv(evsel) < 0 ||
- perf_evsel__alloc_counts(evsel, perf_evsel__nr_cpus(evsel))
< 0 ||
+ perf_evsel__alloc_counts(evsel, cpu_map__nr(evsel->cpus)) <
0 ||
(alloc_raw && perf_evsel__alloc_prev_raw_counts(evsel) < 0))
goto out_free;
}
@@ -269,7 +259,7 @@ static void perf_stat__reset_stats(struct perf_evlist
*evlist)
evlist__for_each(evlist, evsel) {
perf_evsel__reset_stat_priv(evsel);
- perf_evsel__reset_counts(evsel, perf_evsel__nr_cpus(evsel));
+ perf_evsel__reset_counts(evsel, cpu_map__nr(evsel->cpus));
}
memset(runtime_nsecs_stats, 0, sizeof(runtime_nsecs_stats));
@@ -302,7 +292,7 @@ static int create_perf_stat_counter(struct perf_evsel
*evsel)
attr->inherit = !no_inherit;
if (target__has_cpu(&target))
- return perf_evsel__open_per_cpu(evsel, perf_evsel__cpus(evsel));
+ return perf_evsel__open_per_cpu(evsel, evsel->cpus);
if (!target__has_task(&target) && perf_evsel__is_group_leader(evsel)) {
attr->disabled = 1;
@@ -397,7 +387,7 @@ static void zero_per_pkg(struct perf_evsel *counter)
static int check_per_pkg(struct perf_evsel *counter, int cpu, bool *skip)
{
unsigned long *mask = counter->per_pkg_mask;
- struct cpu_map *cpus = perf_evsel__cpus(counter);
+ struct cpu_map *cpus = counter->cpus;
int s;
*skip = false;
@@ -507,7 +497,7 @@ static int read_counter_aggr(struct perf_evsel *counter)
static int read_counter(struct perf_evsel *counter)
{
int nthreads = thread_map__nr(evsel_list->threads);
- int ncpus = perf_evsel__nr_cpus(counter);
+ int ncpus = cpu_map__nr(counter->cpus);
int cpu, thread;
if (counter->system_wide)
@@ -727,13 +717,13 @@ static int __run_perf_stat(int argc, const char **argv)
if (aggr_mode == AGGR_GLOBAL) {
evlist__for_each(evsel_list, counter) {
read_counter_aggr(counter);
-
