linaro-kernel January 2014

linaro-kernel@lists.linaro.org

112 participants
241 discussions

[PATCH 00/34] CPUFreq: Move freq change notifications out of drivers

by Viresh Kumar

Another 452 lines gone :) Total stats upto now for all the 5 patchsets: Viresh Kumar (186): ... 69 files changed, 700 insertions(+), 2451 deletions(-) Net: 1751 lines gone.. -----x-------------x---------------- Most of the drivers do following in their ->target_index() routines: struct cpufreq_freqs freqs; freqs.old = old freq... freqs.new = new freq... cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE); /* Change rate here */ cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE); This is replicated over all cpufreq drivers today and there doesn't exists a good enough reason why this shouldn't be moved to cpufreq core instead. There are few special cases though, like exynos5440, which doesn't do everything on the call to ->target_index() routine and call some kind of bottom halves for doing this work, work/tasklet/etc.. They may continue doing notification from their own code and so this patch introduces another flag: CPUFREQ_NO_NOTIFICATION, which will be set by such drivers. This is Fifth part of my cleanup work for CPUFreq, first three are (And obviously its rebased over them): 1: cpufreq: Introduce cpufreq_table_validate_and_show() https://lkml.org/lkml/2013/8/8/263 2: cpufreq: define generic routines for cpufreq drivers https://lkml.org/lkml/2013/8/10/48 3. CPUFreq: Implement light weight ->target(): for 3.13 https://lkml.org/lkml/2013/8/13/349 4. CPUFreq: set policy->cur in cpufreq core instead of drivers https://lkml.org/lkml/2013/8/14/288 All these are pushed here: https://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/… -- viresh Cc: Andrew Lunn <andrew(a)lunn.ch> Cc: David S. Miller <davem(a)davemloft.net> Cc: Dmitry Eremin-Solenikov <dbaryshkov(a)gmail.com> Cc: Eric Miao <eric.y.miao(a)gmail.com> Cc: Hans-Christian Egtvedt <egtvedt(a)samfundet.no> Cc: Jesper Nilsson <jesper.nilsson(a)axis.com> Cc: John Crispin <blogic(a)openwrt.org> Cc: Kukjin Kim <kgene.kim(a)samsung.com> Cc: Linus Walleij <linus.walleij(a)linaro.org> Cc: linux-cris-kernel(a)axis.com Cc: Mikael Starvik <starvik(a)axis.com> Cc: Russell King <linux(a)arm.linux.org.uk> Cc: Santosh Shilimkar <santosh.shilimkar(a)ti.com> Cc: Sekhar Nori <nsekhar(a)ti.com> Cc: Shawn Guo <shawn.guo(a)linaro.org> Cc: sparclinux(a)vger.kernel.org Cc: spear-devel(a)list.st.com Cc: Stephen Warren <swarren(a)nvidia.com> Cc: Steven Miao <realmz6(a)gmail.com> Cc: Tony Luck <tony.luck(a)intel.com> Viresh Kumar (34): cpufreq: move freq change notifications to cpufreq core cpufreq: acpi: remove calls to cpufreq_notify_transition() cpufreq: arm_big_little: remove calls to cpufreq_notify_transition() cpufreq: at32ap: remove calls to cpufreq_notify_transition() cpufreq: blackfin: remove calls to cpufreq_notify_transition() cpufreq: cpu0: remove calls to cpufreq_notify_transition() cpufreq: cris: remove calls to cpufreq_notify_transition() cpufreq: davinci: remove calls to cpufreq_notify_transition() cpufreq: dbx500: remove calls to cpufreq_notify_transition() cpufreq: e_powersaver: remove calls to cpufreq_notify_transition() cpufreq: elanfreq: remove calls to cpufreq_notify_transition() cpufreq: exynos: remove calls to cpufreq_notify_transition() cpufreq: exynos5440: set CPUFREQ_NO_NOTIFICATION flag cpufreq: ia64-acpi: remove calls to cpufreq_notify_transition() cpufreq: imx6q: remove calls to cpufreq_notify_transition() cpufreq: kirkwood: remove calls to cpufreq_notify_transition() cpufreq: longhaul: set CPUFREQ_NO_NOTIFICATION flag cpufreq: loongson2: remove calls to cpufreq_notify_transition() cpufreq: maple: remove calls to cpufreq_notify_transition() cpufreq: omap: remove calls to cpufreq_notify_transition() cpufreq: p4-clockmod: remove calls to cpufreq_notify_transition() cpufreq: pasemi: remove calls to cpufreq_notify_transition() cpufreq: pmac: remove calls to cpufreq_notify_transition() cpufreq: powernow: remove calls to cpufreq_notify_transition() cpufreq: ppc: remove calls to cpufreq_notify_transition() cpufreq: pxa: remove calls to cpufreq_notify_transition() cpufreq: s3c: remove calls to cpufreq_notify_transition() cpufreq: s5pv210: remove calls to cpufreq_notify_transition() cpufreq: sa11x0: remove calls to cpufreq_notify_transition() cpufreq: sc520: remove calls to cpufreq_notify_transition() cpufreq: sparc: remove calls to cpufreq_notify_transition() cpufreq: SPEAr: remove calls to cpufreq_notify_transition() cpufreq: speedstep: remove calls to cpufreq_notify_transition() cpufreq: tegra: remove calls to cpufreq_notify_transition() drivers/cpufreq/acpi-cpufreq.c | 14 ++------- drivers/cpufreq/arm_big_little.c | 25 ++-------------- drivers/cpufreq/at32ap-cpufreq.c | 22 ++++++-------- drivers/cpufreq/blackfin-cpufreq.c | 22 +++++--------- drivers/cpufreq/cpufreq-cpu0.c | 33 ++++++++------------- drivers/cpufreq/cpufreq.c | 34 +++++++++++++++++++++ drivers/cpufreq/cris-artpec3-cpufreq.c | 8 ----- drivers/cpufreq/cris-etraxfs-cpufreq.c | 8 ----- drivers/cpufreq/davinci-cpufreq.c | 30 +++++++------------ drivers/cpufreq/dbx500-cpufreq.c | 22 +------------- drivers/cpufreq/e_powersaver.c | 23 ++------------- drivers/cpufreq/elanfreq.c | 13 -------- drivers/cpufreq/exynos-cpufreq.c | 28 +++++------------- drivers/cpufreq/exynos5440-cpufreq.c | 2 +- drivers/cpufreq/ia64-acpi-cpufreq.c | 19 ------------ drivers/cpufreq/imx6q-cpufreq.c | 39 ++++++++++-------------- drivers/cpufreq/kirkwood-cpufreq.c | 54 +++++++++++++--------------------- drivers/cpufreq/longhaul.c | 1 + drivers/cpufreq/loongson2_cpufreq.c | 16 ---------- drivers/cpufreq/maple-cpufreq.c | 18 +----------- drivers/cpufreq/omap-cpufreq.c | 39 +++++++++--------------- drivers/cpufreq/p4-clockmod.c | 10 ------- drivers/cpufreq/pasemi-cpufreq.c | 14 +-------- drivers/cpufreq/pmac32-cpufreq.c | 20 +++---------- drivers/cpufreq/pmac64-cpufreq.c | 18 +----------- drivers/cpufreq/powernow-k6.c | 8 ----- drivers/cpufreq/powernow-k7.c | 11 +------ drivers/cpufreq/powernow-k8.c | 15 +--------- drivers/cpufreq/ppc-corenet-cpufreq.c | 19 +----------- drivers/cpufreq/ppc_cbe_cpufreq.c | 19 +----------- drivers/cpufreq/pxa2xx-cpufreq.c | 27 ++++------------- drivers/cpufreq/pxa3xx-cpufreq.c | 12 -------- drivers/cpufreq/s3c2416-cpufreq.c | 21 +++---------- drivers/cpufreq/s3c64xx-cpufreq.c | 48 ++++++++++-------------------- drivers/cpufreq/s5pv210-cpufreq.c | 16 ++++------ drivers/cpufreq/sa1100-cpufreq.c | 17 ++++------- drivers/cpufreq/sa1110-cpufreq.c | 12 ++------ drivers/cpufreq/sc520_freq.c | 11 ------- drivers/cpufreq/sparc-us2e-cpufreq.c | 7 ----- drivers/cpufreq/sparc-us3-cpufreq.c | 7 ----- drivers/cpufreq/spear-cpufreq.c | 13 +------- drivers/cpufreq/speedstep-centrino.c | 20 +------------ drivers/cpufreq/speedstep-ich.c | 9 ------ drivers/cpufreq/speedstep-smi.c | 7 ----- drivers/cpufreq/tegra-cpufreq.c | 25 ++++------------ include/linux/cpufreq.h | 6 ++++ 46 files changed, 205 insertions(+), 657 deletions(-) -- 1.7.12.rc2.18.g61b472e

7 years, 3 months

[PATCH v2 0/6] arm64: Add ftrace support

by AKASHI Takahiro

This is my second version of patchset for ftrace support. Actually v1 was submitted serveral weeks ago, but is still moderated. (Just ignore them for now.) There is another implementation from Cavium network, but both works are independent, and my code has additional system call trace support. I confirmed that I could compile the patches on v3.12-rc4 by Linaro's coming 2013.10 gcc (4.8.2), and that the kernel worked on Fast Model with the following tracers: function tracer with dynamic ftrace function graph tracer with dynamic ftrace syscall tracepoint irqsoff & preemptirqsoff (which use CALLER_ADDRx) Also verified with in-kernel tests, FTRACE_SELFTEST, FTRACE_STARTUP_TEST and EVENT_TRACE_TEST_SYSCALLS. Patch[3/6] has warnings from checkpatch, but they follow other arch's style. Please be careful that host's elf.h must have AArch64 definitions, EM_AARCH64 and R_AARCH64_ABS64, to build the kernel. See [4/6]. Issues * Can we optimize register usages in asm (by not saving x0, x1 and x2)? [1/6] * Do we need "fault protection" code in ftrace_modify_code()? [1/6] It exists in x86 and other architectures, but not in arm. * We may be able to use aarch64_insn_patch_text_nosync() instead of ftrace_modify_code().[2/6] But the former function does not use probe_kernel_write(). Is this safe? Changes from v1 to v2: * splitted one patch into some pieces for easier review (especially function tracer + dynamic ftrace + CALLER_ADDRx) * put return_address() in a separate file * renamed __mcount to _mcount (it was my mistake) * changed stackframe handling to get parent's frame pointer * removed ARCH_SUPPORTS_FTRACE_OPS * switched to "hotpatch" interfaces from Huawai * revised descriptions in comments AKASHI Takahiro (6): arm64: Add ftrace support arm64: ftrace: Add dynamic ftrace support arm64: ftrace: Add CALLER_ADDRx macros ftrace: Add arm64 support to recordmcount arm64: ftrace: Add system call tracepoint arm64: Add 'notrace' attribute to unwind_frame() for ftrace arch/arm64/Kconfig | 6 + arch/arm64/include/asm/ftrace.h | 54 +++++++++ arch/arm64/include/asm/syscall.h | 1 + arch/arm64/include/asm/thread_info.h | 1 + arch/arm64/include/asm/unistd.h | 2 + arch/arm64/kernel/Makefile | 9 +- arch/arm64/kernel/arm64ksyms.c | 4 + arch/arm64/kernel/entry-ftrace.S | 211 ++++++++++++++++++++++++++++++++++ arch/arm64/kernel/entry.S | 1 + arch/arm64/kernel/ftrace.c | 186 ++++++++++++++++++++++++++++++ arch/arm64/kernel/ptrace.c | 10 ++ arch/arm64/kernel/return_address.c | 55 +++++++++ arch/arm64/kernel/stacktrace.c | 2 +- scripts/recordmcount.c | 4 + scripts/recordmcount.pl | 5 + 15 files changed, 549 insertions(+), 2 deletions(-) create mode 100644 arch/arm64/include/asm/ftrace.h create mode 100644 arch/arm64/kernel/entry-ftrace.S create mode 100644 arch/arm64/kernel/ftrace.c create mode 100644 arch/arm64/kernel/return_address.c -- 1.7.9.5

10 years, 7 months

[PATCH 0/4] arm64: Add audit support

by AKASHI Takahiro

This patchset adds audit support on arm64. The implementation is just like in other architectures, and so I think little explanation is needed. I verified this patch with some commands on both 64-bit rootfs and 32-bit rootfs(, but only in little-endian): # auditctl -a exit,always -S openat -F path=/etc/inittab # auditctl -a exit,always -F dir=/tmp -F perm=rw # auditctl -a task,always # autrace /bin/ls What else? (Thanks to Clayton for his cross-compiling patch) I'd like to discuss about the following issues: (issues) * AUDIT_ARCH_* Why do we need to distiguish big-endian and little-endian? [2/4] * AArch32 We need to add a check for identifying the endian in 32-bit tasks. [3/4] * syscall no in AArch32 Currently all the definitions are added in unistd32.h with "ifdef __AARCH32_AUDITSYSCALL" to use asm-generic/audit_*.h. [3/4] "ifdef" is necessary to avoid a conflict with 64-bit definitions. Do we need a more sophisticated way? * TIF_AUDITSYSCALL Most architectures, except x86, do not check TIF_AUDITSYSCALL. Why not? [4/4] * Userspace audit package There are some missing syscall definitions in lib/aarch64_table.h. There is no support for AUDIT_ARCH_ARM (I mean LE. armeb is BE). AKASHI Takahiro (4): audit: Enable arm64 support arm64: Add audit support arm64: audit: Add AArch32 support arm64: audit: Add audit hook in ptrace/syscall_trace arch/arm64/Kconfig | 3 + arch/arm64/include/asm/audit32.h | 12 ++ arch/arm64/include/asm/ptrace.h | 5 + arch/arm64/include/asm/syscall.h | 18 ++ arch/arm64/include/asm/thread_info.h | 1 + arch/arm64/include/asm/unistd32.h | 387 ++++++++++++++++++++++++++++++++++ arch/arm64/kernel/Makefile | 4 + arch/arm64/kernel/audit.c | 77 +++++++ arch/arm64/kernel/audit32.c | 46 ++++ arch/arm64/kernel/entry.S | 3 + arch/arm64/kernel/ptrace.c | 12 ++ include/uapi/linux/audit.h | 2 + init/Kconfig | 2 +- 13 files changed, 571 insertions(+), 1 deletion(-) create mode 100644 arch/arm64/include/asm/audit32.h create mode 100644 arch/arm64/kernel/audit.c create mode 100644 arch/arm64/kernel/audit32.c -- 1.7.9.5

10 years, 8 months

[PATCH 0/4] ARM: OMAP: raw read and write endian fix

by Taras Kondratiuk

This series does trivial replacement of __raw_xxx functions with xxx_relaxed endian-neutral variants in 'mach-omap2' and 'plat-omap' directories. Some code here most probably won't be used in BE mode (like debug-leds for OMAP1 boards), but changes are made anyway to remove __raw_xxx() functions completely and simplify future grep'ing for new __raw_xxx() entries. This is a part of RFC series [1]. Based on v3.13-rc5. [1] http://www.spinics.net/lists/linux-omap/msg99927.html Victor Kamensky (4): ARM: OMAP2+: raw read and write endian fix ARM: OMAP: dmtimer: raw read and write endian fix ARM: OMAP: counter-32k: raw read and write endian fix ARM: OMAP: debug-leds: raw read and write endian fix arch/arm/mach-omap2/board-flash.c | 4 +-- arch/arm/mach-omap2/clkt2xxx_dpllcore.c | 2 +- arch/arm/mach-omap2/clkt2xxx_osc.c | 8 +++--- arch/arm/mach-omap2/clkt2xxx_sys.c | 2 +- arch/arm/mach-omap2/clkt_clksel.c | 10 +++---- arch/arm/mach-omap2/clkt_dpll.c | 6 ++--- arch/arm/mach-omap2/clkt_iclk.c | 8 +++--- arch/arm/mach-omap2/clock.c | 16 +++++------ arch/arm/mach-omap2/clock36xx.c | 6 ++--- arch/arm/mach-omap2/cm2xxx_3xxx.h | 4 +-- arch/arm/mach-omap2/cm33xx.c | 4 +-- arch/arm/mach-omap2/cm3xxx.c | 8 +++--- arch/arm/mach-omap2/cm44xx.c | 8 +++--- arch/arm/mach-omap2/cminst44xx.c | 4 +-- arch/arm/mach-omap2/control.c | 20 +++++++------- arch/arm/mach-omap2/dma.c | 4 +-- arch/arm/mach-omap2/dpll3xxx.c | 32 +++++++++++----------- arch/arm/mach-omap2/dpll44xx.c | 12 ++++----- arch/arm/mach-omap2/gpmc.c | 8 +++--- arch/arm/mach-omap2/id.c | 2 +- arch/arm/mach-omap2/irq.c | 4 +-- arch/arm/mach-omap2/mux.c | 8 +++--- arch/arm/mach-omap2/omap-hotplug.c | 4 +-- arch/arm/mach-omap2/omap-mpuss-lowpower.c | 18 ++++++------- arch/arm/mach-omap2/omap-smp.c | 4 +-- arch/arm/mach-omap2/omap-wakeupgen.c | 42 ++++++++++++++--------------- arch/arm/mach-omap2/omap4-common.c | 16 +++++------ arch/arm/mach-omap2/omap_hwmod.c | 10 +++---- arch/arm/mach-omap2/omap_phy_internal.c | 6 ++--- arch/arm/mach-omap2/prcm_mpu44xx.c | 4 +-- arch/arm/mach-omap2/prm2xxx.h | 2 +- arch/arm/mach-omap2/prm2xxx_3xxx.h | 4 +-- arch/arm/mach-omap2/prm33xx.c | 4 +-- arch/arm/mach-omap2/prm3xxx.h | 2 +- arch/arm/mach-omap2/prm44xx.c | 4 +-- arch/arm/mach-omap2/prminst44xx.c | 4 +-- arch/arm/mach-omap2/sdrc.h | 8 +++--- arch/arm/mach-omap2/sdrc2xxx.c | 4 +-- arch/arm/mach-omap2/sr_device.c | 2 +- arch/arm/mach-omap2/sram.c | 16 +++++------ arch/arm/mach-omap2/timer.c | 8 +++--- arch/arm/mach-omap2/vc.c | 4 +-- arch/arm/mach-omap2/wd_timer.c | 8 +++--- arch/arm/plat-omap/counter_32k.c | 6 ++--- arch/arm/plat-omap/debug-leds.c | 14 +++++----- arch/arm/plat-omap/dmtimer.c | 8 +++--- arch/arm/plat-omap/include/plat/dmtimer.h | 16 +++++------ 47 files changed, 199 insertions(+), 199 deletions(-) -- 1.7.9.5

10 years, 9 months

[GIT PULL] ARM: kprobes: big-endian support

by Taras Kondratiuk

Hi Russell, Please pull fixes for ARM Kprobes big-endian support. It is reworked initial Ben's series for big endian support [1]. Dropped patches that are not directly related to kprobes. Current set of patches is enough to have functional BE kprobes. One ARM kprobe test fails on Cortex-A15 boards (TC2 and Keystone2 EVM), while it passes on Pandaboard. The issue is not related to this series and already present in v3.13-rc7. [1] http://www.spinics.net/lists/arm-kernel/msg285210.html -- Taras Kondratiuk --->8 The following changes since commit 7e22e91102c6b9df7c4ae2168910e19d2bb14cd6: Linux 3.13-rc8 (2014-01-12 17:04:18 +0700) are available in the git repository at: git://git.linaro.org/people/taras.kondratiuk/linux.git tags/for_russell/arm-be-kprobes for you to fetch changes up to 1c2d814c019b63bf0778fc2d2fd54c6e44f1ab5d: ARM: kprobes-test: Workaround GAS .align bug (2014-01-13 13:58:52 +0200) ---------------------------------------------------------------- Ben Dooks (4): ARM: kprobes: fix instruction fetch order with <asm/opcodes.h> ARM: kprobes-test: use <asm/opcodes.h> for instruction accesses ARM: kprobes-test: use <asm/opcodes.h> for ARM instruction building ARM: kprobes-test: use <asm/opcodes.h> for Thumb instruction building Taras Kondratiuk (1): ARM: kprobes-test: Workaround GAS .align bug arch/arm/kernel/kprobes-common.c | 19 +- arch/arm/kernel/kprobes-test-arm.c | 603 +++++++++++++++++----------------- arch/arm/kernel/kprobes-test-thumb.c | 447 ++++++++++++------------- arch/arm/kernel/kprobes-test.c | 13 +- arch/arm/kernel/kprobes-test.h | 2 +- arch/arm/kernel/kprobes-thumb.c | 20 +- arch/arm/kernel/kprobes.c | 9 +- 7 files changed, 562 insertions(+), 551 deletions(-)

10 years, 9 months

[PATCH v3] audit: generic compat system call support

by AKASHI Takahiro

Arm64 supports 32-bit mode(AArch32) and 64-bit mode(AArch64). To enable audit on arm64, we want to use lib/audit.c and re-work it to support compat system calls as well without copying it under arch sub-directory. So this patch is mandatory for my "system call audit support for arm64" patch. Please review it as well for better understandings. This code was tested on armv8 fast model with 64-bit and 32-bit userland by using modified audit-test-code. Changes v1 -> v2: * Specify AUDIT_CLASS_XYZ_32 instead of AUDIT_CLASS_XYZ when registering compat syscalls (bug fix) AKASHI Takahiro (1): audit: Add generic compat syscall support include/linux/audit.h | 9 +++++++++ lib/Makefile | 3 +++ lib/audit.c | 17 +++++++++++++++++ lib/compat_audit.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 80 insertions(+) create mode 100644 lib/compat_audit.c -- 1.7.9.5

10 years, 10 months

[RFC v2 PATCH 0/1] ARM64: KGDB: Add FPSIMD debug support

by vijay.kilari＠gmail.com

From: Vijaya Kumar K <Vijaya.Kumar(a)caviumnetworks.com> Based on ARM64 KGDB support patches, KGDB support for FPSIMD is added. Only debugging of FPSIMD kernel context is supported. This patch requires Ard's patches where in kernel support and below patch for holding thread's fpsimd state. http://permalink.gmane.org/gmane.linux.ports.arm.kernel/277228 So CONFIG_KERNEL_MODE_NEON should be enabled. with this, FPSIMD registers can be viewed or set from gdb tool. Unlike CPU registers, the FPSIMD registers are not saved on exception entry. With the known restriction that FPSIMD should not be touched in interrupt/exception context, in this patch the FPSIMD registers are directly read/written on gdb tool request Here, the FPSIMD registers are read and restored for every FPSIMD register read and write by GDB tool. So this has impact on gdb tool response which is neglible. Other architectures like mips are also implemented similarly v2 changes: - Added API to know thread fpsimd state by checking TIF_FOREIGN_FPSTATE flag. This is based on below patch http://permalink.gmane.org/gmane.linux.ports.arm.kernel/277228 - Allow FPSIMD registers access only when FPSIMD is under use by current thread v1 changes: - Initial patch Tested on ARM64 simulator Vijaya Kumar K (1): ARM64: KGDB: Add FP/SIMD debug support arch/arm64/include/asm/fpsimd.h | 1 + arch/arm64/kernel/fpsimd.c | 5 ++ arch/arm64/kernel/kgdb.c | 105 +++++++++++++++++++++++++-------------- 3 files changed, 73 insertions(+), 38 deletions(-) -- 1.7.9.5

10 years, 10 months

[QUERY]: Is using CPU hotplug right for isolating CPUs?

by Viresh Kumar

Hi Again, I am now successful in isolating a CPU completely using CPUsets, NO_HZ_FULL and CPU hotplug.. My setup and requirements for those who weren't following the earlier mails: For networking machines it is required to run data plane threads on some CPUs (i.e. one thread per CPU) and these CPUs shouldn't be interrupted by kernel at all. Earlier I tried CPUSets with NO_HZ by creating two groups with load_balancing disabled between them and manually tried to move all tasks out to CPU0 group. But even then there were interruptions which were continuously coming on CPU1 (which I am trying to isolate). These were some workqueue events, some timers (like prandom), timer overflow events (As NO_HZ_FULL pushes hrtimer to long ahead in future, 450 seconds, rather than disabling them completely, and these hardware timers were overflowing their counters after 90 seconds on Samsung Exynos board). So after creating CPUsets I hotunplugged CPU1 and added it back immediately. This moved all these interruptions away and now CPU1 is running my single thread ("stress") for ever. Now my question is: Is there anything particularly wrong about using hotplugging here ? Will that lead to a disaster :) Thanks in Advance. -- viresh

10 years, 10 months

[PATCH] pinctrl: Quiet logging about missing DT nodes when not using DT

by Mark Brown

From: Mark Brown <broonie(a)linaro.org> On systems which were not booted using DT it is entirely unsurprising that device nodes don't have any DT information and this is going to happen for every single device in the system. Make pinctrl be less chatty about this situation by only logging in the case where we have DT. Signed-off-by: Mark Brown <broonie(a)linaro.org> --- drivers/pinctrl/devicetree.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/pinctrl/devicetree.c b/drivers/pinctrl/devicetree.c index 340fb4e6c600..eda13de2e7c0 100644 --- a/drivers/pinctrl/devicetree.c +++ b/drivers/pinctrl/devicetree.c @@ -186,7 +186,9 @@ int pinctrl_dt_to_map(struct pinctrl *p) /* CONFIG_OF enabled, p->dev not instantiated from DT */ if (!np) { - dev_dbg(p->dev, "no of_node; not parsing pinctrl DT\n"); + if (of_have_populated_dt()) + dev_dbg(p->dev, + "no of_node; not parsing pinctrl DT\n"); return 0; } -- 1.9.rc1

10 years, 10 months

[PATCH v9 0/6] arm64: KGDB Support

by vijay.kilari＠gmail.com

From: Vijaya Kumar K <Vijaya.Kumar(a)caviumnetworks.com> Based on the step-handler and break-handler hooks patch from Sandeepa, KGDB debugging support is added for EL1 debug in AArch64 mode. In first patch, PSTATE.D is set correctly In second patch,register layout is updated to be inline with GDB tool. Basic GDB connection, break point set/clear and info commands are supported except step/next debugging With second patch, step/next debugging support is added, where in pc is updated to point to the instruction to be stepped and stopped. With third patch, the compile time breakpoint instruction reordering is fixed by making kgbd_breakpoint() as noinline Tested with ARM64 simulator v9: - minor code movement comments fix v8: - fixed comments on local_dbg_{save,restore} macros - instruction_pointer() macro to return unsigned long to fix compilation warnings v7: - Changes made to set PSTATE.D properly - Performed KGDB boot tests - Fixed compilation warnings in driver/misc/kgbdts.c Results: kgdb boot test: [32927.237895] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [32927.266066] kgdb: Registered I/O driver kgdbts. [32927.266419] kgdb: Waiting for connection from remote gdb... [32927.268598] kgdbts:RUN plant and detach test [32927.270683] kgdbts:RUN sw breakpoint test [32927.287659] kgdbts:RUN bad memory access test [32927.290322] kgdbts:RUN singlestep test 1000 iterations [32927.330342] kgdbts:RUN singlestep [0/1000] [32931.286356] kgdbts:RUN singlestep [100/1000] [32935.242536] kgdbts:RUN singlestep [200/1000] [32939.205392] kgdbts:RUN singlestep [300/1000] [32943.169522] kgdbts:RUN singlestep [400/1000] [32947.231868] kgdbts:RUN singlestep [500/1000] [32951.188008] kgdbts:RUN singlestep [600/1000] [32955.332243] kgdbts:RUN singlestep [700/1000] [32959.467109] kgdbts:RUN singlestep [800/1000] [32963.430888] kgdbts:RUN singlestep [900/1000] [32967.346992] kgdbts:RUN do_fork for 100 breakpoints kgdb test from sysfs: ~ # echo V1F1000 > /sys/module/kgdbts/parameters/kgdbts [33231.554237] kgdb: Registered I/O driver kgdbts. [33231.554677] kgdbts:RUN plant and detach test [33231.557072] kgdbts:RUN sw breakpoint test [33231.576980] kgdbts:RUN bad memory access test [33231.580022] kgdbts:RUN singlestep test 1000 iterations [33231.627056] kgdbts:RUN singlestep [0/1000] [33235.954027] kgdbts:RUN singlestep [100/1000] [33240.429086] kgdbts:RUN singlestep [200/1000] [33244.687118] kgdbts:RUN singlestep [300/1000] [33248.945191] kgdbts:RUN singlestep [400/1000] [33253.203751] kgdbts:RUN singlestep [500/1000] [33257.462019] kgdbts:RUN singlestep [600/1000] [33261.817809] kgdbts:RUN singlestep [700/1000] [33266.081268] kgdbts:RUN singlestep [800/1000] [33270.339813] kgdbts:RUN singlestep [900/1000] [33274.712404] kgdbts:RUN do_fork for 1000 breakpoints ~ # v6: - Change pstate register to 8 bytes to make endian nuetral. Use GDB below GDB patch to display pstate in Big endian mode. https://sourceware.org/ml/gdb-patches/2013-12/msg00720.html Thanks to Andrew. v5: - Updated BRK #imm16 value to 0x400 & 0x401 as per recommendation as per Marcus recommendataion http://patchwork.ozlabs.org/patch/290801/ - Rebased to 3.13 AArch64 kernel v4: - Updated kgdb_single_step and kgdb_cpu_doing_single_step variables properly based on gdb state v3: - Rebased to v4 version of Sandeepa Prabhu's patch (patch 1) - Made dynamic break point instruction encoding generic - Made ESR value encoding generic for dynamic and compile break point - Used memcpy and memset to copy register contents to gdb buffer - Fixed reordering of break point instruction by compiler with patch 3 - Rebased against AAach64 upstream kernel v2: - Moved break instruction encoding to debug-monitors.h file - Fixed endianess of compile break instruction encoding - Updated I/O buffer sizes - Updated register buffer size - Remove changes to debug_exception handler in entry.S for - ELR update and step debugging with update pc instead of ELR - Rebased against AArch64 upstream kernel v1: - Initial patch-set Vijaya Kumar K (6): arm64: Add macros to manage processor debug state arm64: KGDB: Add Basic KGDB support arm64: KGDB: Add step debugging support KGDB: make kgdb_breakpoint() as noinline misc: debug: remove compilation warnings arm64: KGDB: Add KGDB config arch/arm64/Kconfig | 1 + arch/arm64/include/asm/debug-monitors.h | 64 ++++-- arch/arm64/include/asm/irqflags.h | 23 +++ arch/arm64/include/asm/kgdb.h | 84 ++++++++ arch/arm64/include/asm/ptrace.h | 2 +- arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/debug-monitors.c | 1 + arch/arm64/kernel/kgdb.c | 336 +++++++++++++++++++++++++++++++ kernel/debug/debug_core.c | 2 +- 9 files changed, 495 insertions(+), 19 deletions(-) create mode 100644 arch/arm64/include/asm/kgdb.h create mode 100644 arch/arm64/kernel/kgdb.c -- 1.7.9.5

10 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

linaro-kernel January 2014