Re: [PATCH] Documentation/Intel-IOMMU.txt: Modify definition of DRHD
Hi Jonathan, Got it, thanks very much! Best Regards Nan Xiao On Tue, Aug 25, 2015 at 1:41 AM, Jonathan Corbet cor...@lwn.net wrote: On Thu, 20 Aug 2015 18:17:10 +0800 Nan Xiao xiaonan830...@gmail.com wrote: According to Intel Virtualization Technology for Directed I/O specification, DRHD stands for DMA Remapping Hardware Unit Definition , not DMA Engine Reporting Structure. Applied to the docs tree, thanks. Note that this patch was line-wrapped by your mail client and required manual fixing; please configure your client to not do that (Documentation/email-clients.txt can be helpful) before sending any further patches. jon -- 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/
Lockups with 4.2-rc kernels and qemu
(Cc'ing qemu-devel, please keep me in the Cc). TL;DR - qemu locks up my machine when I use 4.2-rc kernels. I only use qemu from time to time, mostly to test changes to my own scripts, or new package versions, in beyond.linuxfromscratch.org. A few days ago I came back to that, building an LFS system from the beginning of this month and then using that to try out my changes. In the beginning I built a 4.2-rc5 kernel and booted that system in qemu-2.4.0. I had several lockups along the way from a minimal system to the end of my attempts to build a full desktop, and in fact I dropped back to a 4.1 kernel and qemu-2.3.0 before I completed the build. Mostly, the qemu system appeared to have been idle when the box locked up, or else idle apart from xscreensaver, but on one occasion it ran through several steps to build Xorg protocol header packages - I write a 'stamp' file so that I can resume after a failure, and several of these were created, but empty (instead of a small amount of version, time, space data) and it later turned out that nothing had been installed for those packages. In all cases I have nothing relevant in either the guest or the host logs. On one or two occasions I got the flashing keyboard LEDs. After the initial problems I ran memtest86+ for 10 hours without any errors. In the end, I dropped back to a 4.1 kernel and also qemu-2.3.0 because my concern was to finish the build. I was thinking - erroneously, of course - that this was a qemu problem. Gradually, I moved to 4.2-rc kernels and things appeared to be ok. But today I installed 4.2-rc8 and thought about trying to create a test-case to see if the kernel+qemu combination is probably ok. I decided to start qemu, login, run startx [ xscreensaver will be invoked, otherwise userspace is idle ], and leave it for 3 hours - lockups varied in how long they took to appear, but all were in 2 hours or less. So, I left -rc8 and qemu-2.3.0, and when I returned to it after about 3 and a quarter hours the box had locked up. The machine is an AMD phenom (not always the most reliable, I had to drop caches today to get it to reliably build -rc8 with make -j 4 but otherwise it seems to have not needed that in the past month). I'll attach the kernel config. I compiled qemu-2.3.0 with: sed -i '/resource/ i#include sys/xattr.h' \ fsdev/virtfs-proxy-helper.c ./configure --prefix=/usr \ --sysconfdir=/etc \ --docdir=/usr/share/doc/qemu-2.3.0 \ --target-list=x86_64-softmmu \ --audio-drv-list=alsa and I use a wrapper script for qemu which tells me that what I am actually running is: qemu-system-x86_64 -enable-kvm -hda svn20150803-32-desk2.img -hdb svn-logging-tools.img -m 2G -usb -usbdevice tablet -show-cursor -display sdl -cpu kvm32 -monitor stdio -smp 4 -vga std That was for building a new system, later runs only use a -hda image. And all of the uses have been for i686 guests. The host (and the initial guest used to build the new system) is gcc-5.1.0, the newly built guests 5.2.0; binutils 2.25 / 2.25.1; glibc 2.21 throughout. Because I need to leave the system running for up to 3 hours to get an idea if a particular kernel is ok, I don't think this problem lends itself to bisection. Any suggestions, please ? ĸen -- This one goes up to eleven: but only on a clear day, with the wind in the right direction. # # Automatically generated file; DO NOT EDIT. # Linux/x86 4.2.0-rc8 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_PERF_EVENTS_INTEL_UNCORE=y CONFIG_OUTPUT_FORMAT=elf64-x86-64 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_64_SMP=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11 CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_PGTABLE_LEVELS=4 CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y
Re: [PATCH v4 4/4] Use 2GB memory block size on large-memory x86-64 systems
On Mon, Aug 24, 2015 at 3:39 PM, Tony Luck tony.l...@gmail.com wrote:
On Mon, Aug 24, 2015 at 2:25 PM, Yinghai Lu ying...@kernel.org wrote:
Can you boot with debug ignore_loglevel so we can see following print out
for vmemmap?
See attached. There are a few extra messages from my own debug printk()
calls. It seems that we successfully deal with node 0 from topology_init()
but die walking node 1. I see that the NODE_DATA limits for memory
on node 1 were from 1d7 to 3a0. But when we get into
register_mem_sect_under_node() we have rounded the start pfn down to
1d0 ... and we panic processing that range (which is in a hole in e820).
We seem to die here:
for (pfn = sect_start_pfn; pfn = sect_end_pfn; pfn++) {
int page_nid;
page_nid = get_nid_for_pfn(pfn);
oh, no.
register_mem_sect_under_node() is assuming:
first section in the block is present and first page in that section is present.
--
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 -mm] selftests/capabilities: Add tests for capability evolution
On Mon, Aug 24, 2015 at 4:03 PM, Andy Lutomirski l...@kernel.org wrote:
This test focuses on ambient capabilities. It requires either root
or the ability to create user namespaces. Some of the test cases
will be skipped for nonroot users.
Signed-off-by: Andy Lutomirski l...@kernel.org
Looks great! Thanks for this!
Acked-by: Kees Cook keesc...@chromium.org
-Kees
---
I took taking advantage of the extra week to make my test case work :)
tools/testing/selftests/capabilities/.gitignore| 2 +
tools/testing/selftests/capabilities/Makefile | 19 +
tools/testing/selftests/capabilities/test_execve.c | 427
+
.../testing/selftests/capabilities/validate_cap.c | 73
4 files changed, 521 insertions(+)
create mode 100644 tools/testing/selftests/capabilities/.gitignore
create mode 100644 tools/testing/selftests/capabilities/Makefile
create mode 100644 tools/testing/selftests/capabilities/test_execve.c
create mode 100644 tools/testing/selftests/capabilities/validate_cap.c
diff --git a/tools/testing/selftests/capabilities/.gitignore
b/tools/testing/selftests/capabilities/.gitignore
new file mode 100644
index ..b732dd0d4738
--- /dev/null
+++ b/tools/testing/selftests/capabilities/.gitignore
@@ -0,0 +1,2 @@
+test_execve
+validate_cap
diff --git a/tools/testing/selftests/capabilities/Makefile
b/tools/testing/selftests/capabilities/Makefile
new file mode 100644
index ..5b90ed14cccb
--- /dev/null
+++ b/tools/testing/selftests/capabilities/Makefile
@@ -0,0 +1,19 @@
+all:
+
+include ../lib.mk
+
+.PHONY: all clean
+
+TARGETS := validate_cap test_execve
+TEST_PROGS := test_execve
+
+CFLAGS := -O2 -g -std=gnu99 -Wall -lcap-ng
+
+all: $(TARGETS)
+
+clean:
+ $(RM) $(TARGETS)
+
+$(TARGETS): %: %.c
+ $(CC) -o $@ $(CFLAGS) $(EXTRA_CFLAGS) $^ -lrt -ldl
+
diff --git a/tools/testing/selftests/capabilities/test_execve.c
b/tools/testing/selftests/capabilities/test_execve.c
new file mode 100644
index ..10a21a958aaf
--- /dev/null
+++ b/tools/testing/selftests/capabilities/test_execve.c
@@ -0,0 +1,427 @@
+#define _GNU_SOURCE
+
+#include cap-ng.h
+#include err.h
+#include linux/capability.h
+#include stdbool.h
+#include string.h
+#include stdio.h
+#include fcntl.h
+#include errno.h
+#include stdarg.h
+#include sched.h
+#include sys/mount.h
+#include limits.h
+#include libgen.h
+#include malloc.h
+#include sys/wait.h
+#include sys/prctl.h
+#include sys/stat.h
+
+#ifndef PR_CAP_AMBIENT
+#define PR_CAP_AMBIENT 47
+# define PR_CAP_AMBIENT_IS_SET 1
+# define PR_CAP_AMBIENT_RAISE 2
+# define PR_CAP_AMBIENT_LOWER 3
+# define PR_CAP_AMBIENT_CLEAR_ALL 4
+#endif
+
+static int nerrs;
+
+static void vmaybe_write_file(bool enoent_ok, char *filename, char *fmt,
va_list ap)
+{
+ char buf[4096];
+ int fd;
+ ssize_t written;
+ int buf_len;
+
+ buf_len = vsnprintf(buf, sizeof(buf), fmt, ap);
+ if (buf_len 0) {
+ err(1, vsnprintf failed);
+ }
+ if (buf_len = sizeof(buf)) {
+ errx(1, vsnprintf output truncated);
+ }
+
+ fd = open(filename, O_WRONLY);
+ if (fd 0) {
+ if ((errno == ENOENT) enoent_ok)
+ return;
+ err(1, open of %s failed, filename);
+ }
+ written = write(fd, buf, buf_len);
+ if (written != buf_len) {
+ if (written = 0) {
+ errx(1, short write to %s, filename);
+ } else {
+ err(1, write to %s failed, filename);
+ }
+ }
+ if (close(fd) != 0) {
+ err(1, close of %s failed, filename);
+ }
+}
+
+static void maybe_write_file(char *filename, char *fmt, ...)
+{
+ va_list ap;
+
+ va_start(ap, fmt);
+ vmaybe_write_file(true, filename, fmt, ap);
+ va_end(ap);
+}
+
+static void write_file(char *filename, char *fmt, ...)
+{
+ va_list ap;
+
+ va_start(ap, fmt);
+ vmaybe_write_file(false, filename, fmt, ap);
+ va_end(ap);
+}
+
+static bool create_and_enter_ns(uid_t inner_uid)
+{
+ uid_t outer_uid;
+ gid_t outer_gid;
+ int i;
+ bool have_outer_privilege;
+
+ outer_uid = getuid();
+ outer_gid = getgid();
+
+ /*
+* TODO: If we're already root, we could skip creating the userns.
+*/
+
+ if (unshare(CLONE_NEWNS) == 0) {
+ printf([NOTE]\tUsing global UIDs for tests\n);
+ if (prctl(PR_SET_KEEPCAPS, 1, 0, 0, 0) != 0)
+ err(1, PR_SET_KEEPCAPS);
+ if (setresuid(inner_uid, inner_uid, -1) != 0)
+ err(1, setresuid);
+
+ // Re-enable effective caps
+
Re: [PATCH] Input: edt-ft5x06 - Switch to newer gpio framework
On Mon, Aug 24, 2015 at 05:16:15PM -0500, Franklin S Cooper Jr. wrote:
On 08/24/2015 03:56 PM, Dmitry Torokhov wrote:
On Mon, Aug 24, 2015 at 03:23:43PM -0500, Franklin S Cooper Jr. wrote:
On 08/24/2015 03:16 PM, Franklin S Cooper Jr. wrote:
On 08/24/2015 03:01 PM, Dmitry Torokhov wrote:
On Mon, Aug 24, 2015 at 02:48:36PM -0500, Franklin S Cooper Jr. wrote:
On 08/24/2015 02:41 PM, Dmitry Torokhov wrote:
On Fri, Aug 21, 2015 at 02:08:32PM -0500, Franklin S Cooper Jr wrote:
The current/old gpio framework used doesn't properly listen to
ACTIVE_LOW and ACTIVE_HIGH flags. The newer gpio framework takes into
account these flags when setting gpio values.
Also use gpiod_set_value_cansleep since wake and reset pins can be
provided by bus based io expanders.
Signed-off-by: Franklin S Cooper Jr fcoo...@ti.com
---
.../bindings/input/touchscreen/edt-ft5x06.txt | 4 +-
drivers/input/touchscreen/edt-ft5x06.c | 115
+++--
include/linux/input/edt-ft5x06.h | 4 +-
3 files changed, 43 insertions(+), 80 deletions(-)
diff --git
a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
index 76db967..9330d4d 100644
---
a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
+++
b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
@@ -50,6 +50,6 @@ Example:
pinctrl-0 = edt_ft5x06_pins;
interrupt-parent = gpio2;
interrupts = 5 0;
- reset-gpios = gpio2 6 1;
- wake-gpios = gpio4 9 0;
+ reset-gpios = gpio2 6 GPIO_ACTIVE_LOW;
+ wake-gpios = gpio4 9 GPIO_ACTIVE_HIGH;
};
diff --git a/drivers/input/touchscreen/edt-ft5x06.c
b/drivers/input/touchscreen/edt-ft5x06.c
index 394b1de..6b128b3 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -91,9 +91,9 @@ struct edt_ft5x06_ts_data {
u16 num_x;
u16 num_y;
- int reset_pin;
- int irq_pin;
- int wake_pin;
+ struct gpio_desc *reset_pin;
+ struct gpio_desc *wake_pin;
+ struct gpio_desc *irq_pin;
#if defined(CONFIG_DEBUG_FS)
struct dentry *debug_dir;
@@ -755,36 +755,14 @@ edt_ft5x06_ts_teardown_debugfs(struct
edt_ft5x06_ts_data *tsdata)
static int edt_ft5x06_ts_reset(struct i2c_client *client,
struct edt_ft5x06_ts_data *tsdata)
{
- int error;
-
- if (gpio_is_valid(tsdata-wake_pin)) {
- error = devm_gpio_request_one(client-dev,
- tsdata-wake_pin,
GPIOF_OUT_INIT_LOW,
- edt-ft5x06 wake);
- if (error) {
- dev_err(client-dev,
- Failed to request GPIO %d as wake pin,
error %d\n,
- tsdata-wake_pin, error);
- return error;
- }
-
+ if (tsdata-wake_pin) {
msleep(5);
- gpio_set_value(tsdata-wake_pin, 1);
+ gpiod_set_value_cansleep(tsdata-wake_pin, 1);
}
- if (gpio_is_valid(tsdata-reset_pin)) {
- /* this pulls reset down, enabling the low active reset
*/
- error = devm_gpio_request_one(client-dev,
- tsdata-reset_pin,
GPIOF_OUT_INIT_LOW,
- edt-ft5x06 reset);
- if (error) {
- dev_err(client-dev,
- Failed to request GPIO %d as reset
pin, error %d\n,
- tsdata-reset_pin, error);
- return error;
- }
+ if (tsdata-reset_pin) {
msleep(5);
- gpio_set_value(tsdata-reset_pin, 1);
+ gpiod_set_value_cansleep(tsdata-reset_pin, 1);
So this leaves the reset pin active. How exactly was this tested?
Normally if the output gpio connected to the reset pin is ACTIVE_HIGH
then this will take the tsc out of reset since
the reset pin is active low. However, I have a board that has an
inverter between the gpio and reset pin. So if I leave
the gpio as ACTIVE_HIGH then the inverter would cause the reset pin to
go low which will keep it in reset. So instead
I set the gpio to ACTIVE_LOW which gives me the expected result.
I do not really care about particular board. Assuming that polarity of
the GPIO in DTS is specified correctly the effect of:
gpiod_set_value_cansleep(tsdata-reset_pin, 1);
is reset pin being _active_, i.e. the chip is staying in reset state.
Setting the reset pin to 1/high will take the tsc out of reset. Setting
the pin to 0/low will put the tsc into reset mode.
It seems you are
Re: [PATCH 01/10] mm: make cleancache.c explicitly non-modular
[Re: [PATCH 01/10] mm: make cleancache.c explicitly non-modular] On 24/08/2015 (Mon 20:10) Konrad Rzeszutek Wilk wrote: On August 24, 2015 6:14:33 PM EDT, Paul Gortmaker paul.gortma...@windriver.com wrote: The Kconfig currently controlling compilation of this code is: config CLEANCACHE bool Enable cleancache driver to cache clean pages if tmem is present ...meaning that it currently is not being built as a module by anyone. Why not make it a tristate? Simple. I'm making the code consistent with its current behaviour. I'm not looking to extend functionality in code that I don't know intimately. I can't do that and do it reliably and guarantee it works as a module when it has never been used as such before. I've got about 130 of these and counting. Some of them have been bool since before git history ; before the turn of the century. If there was demand for them to be tristate, then it would have happened by now. So clearly there is no point in looking at making _those_ tristate. I did have one uart driver author indicate that he _meant_ his code to be tristate, and he tested it as such, and asked if I would convert it to tristate on his behalf. And that was fine and I did exactly that. But unless there are interested users who want their code tristate and can vouch that their code works OK as such, I can only make the code consistent with the implicit non-modular behaviour that the Kconfig and Makefiles have dictated up to now. Are there such users for CLEANCACHE? Paul. -- Lets remove the couple traces of modularity so that when reading the driver there is no doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com Cc: linux...@kvack.org Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- mm/cleancache.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/cleancache.c b/mm/cleancache.c index 8fc5089b..ee0646d1c2fa 100644 --- a/mm/cleancache.c +++ b/mm/cleancache.c @@ -11,7 +11,7 @@ * This work is licensed under the terms of the GNU GPL, version 2. */ -#include linux/module.h +#include linux/init.h #include linux/fs.h #include linux/exportfs.h #include linux/mm.h @@ -316,4 +316,4 @@ static int __init init_cleancache(void) #endif return 0; } -module_init(init_cleancache) +device_initcall(init_cleancache) -- 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: [BUG/RFC] perf test fails on AMD CPUs
On 08/18/2015 05:10 AM, Jiri Olsa wrote: On Mon, Aug 17, 2015 at 09:06:59AM -0700, Andy Lutomirski wrote: On Sun, Aug 16, 2015 at 9:36 PM, Borislav Petkov b...@suse.de wrote: On Mon, Aug 17, 2015 at 12:29:56AM +0200, Jiri Olsa wrote: hi, 'perf test 18' is failing on systems with AMD processor. Hmm, still using that b0rked test box? :-) Also, which kernel? There have been substantial changes to the entry code recently. Although I don't see anything being done differently on AMD there except X86_BUG_SYSRET_SS_ATTRS but that should be unrelated. The only reason I could find is that AMD does not set 'resume flag' in RFLAGS register the way the Intel CPU does. (simplified) test scenario: - create breakpoint (on test_function) perf event with SIGIO signal to be delivered any time the breakpoint is hit - run test_function expected course of actions is: 1) CPU hits 'test_function' 2) DB exception is triggered, with RFLAGS.RF=0 3) DB exception handler sets regs-RFLAGS.RF=1 and perf handler triggers irq_work pending work 4) DB exception executes iretd 5) irq_work interrupt is triggered, with RFLAGS.RF=1 6) irq_work interrupt calls kill_fasync with SIGIO signal 7) irq_work interrupt on return to userspace calls prepare_exit_to_usermode which actually delivers the SIGIO signal 8) sigreturn syscall prepare registers to return to the instruction from step 1) and sets RFLAGS.RF to the its original value from step 5) (RFLAGS.RF=1) 9) CPU hits 'test_function' and DB exception is NOT triggered due to RFLAGS.RF=1 this is how I see it works on Intel But AMD gives me RFLAGS.RF=0 on step 5, which makes the step 9 to trigger the DB exception once again and makes the test fail. Adding Andy, he might have an idea. Leaving in the rest for reference. Gee thanks :-p Jiri, did you instrument the code and observe do_IRQ sees RF clear in its pt_regs? Also, it might be worth checking that regs-ip in the irq_work matches regs-ip. yep, thats what I saw.. once irq_work interrupt was triggered the regs-ip was same as for the previous debug exception but the RFLAGS.RF was 0 It's *possible* that I messed up and broke RF restore with opportunistic sysret, but the code looks correct: testq $(X86_EFLAGS_RF|X86_EFLAGS_TF), %r11 jnz opportunistic_sysret_failed AFAICS the problematic paths did not hit syscalls buut anyway, it looks like latest AMD firmware issue: [root@amd-pike-07 ~]# cat /sys/devices/system/cpu/cpu0/microcode/version 0x6000822 [root@amd-pike-07 perf]# ./perf test 18 18: Test breakpoint overflow signal handler : Ok [root@amd-pike-07 perf]# cat /sys/devices/system/cpu/cpu0/microcode/version 0x6000832 [root@amd-pike-07 perf]# ./perf test 18 18: Test breakpoint overflow signal handler : FAILED! [root@amd-pike-07 ~]# cat /proc/cpuinfo processor : 7 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD Opteron(tm) Processor 3380 stepping: 0 microcode : 0x6000832 SNIP AMD description of RF flag (SDM 3.1.6): === Resume Flag (RF) Bit. Bit 16. The RF bit allows an instruction to be restarted following an instruction breakpoint resulting in a debug exception (#DB). This bit prevents multiple debug exceptions from occurring on the same instruction. The processor clears the RF bit after every instruction is successfully executed, except when the instruction is: • • An IRET that sets the RF bit. JMP, CALL, or INTn through a task gate. In both of the above cases, RF is not cleared to 0 until the next instruction successfully executes. When an exception occurs (or when a string instruction is interrupted), the processor normally sets RF=1 in the RFLAGS image saved on the interrupt stack. However, when a #DB exception occurs as a result of an instruction breakpoint, the processor clears the RF bit to 0 in the interrupt-stack RFLAGS image. That's a little weird, I think. Shouldn't RF be zero on #DB due to a *watchpoint* so that a watchpoint followed immediately by a breakpoint works? the AMD description looked to be more vague (compared to Intels) • For other cases, the value pushed for RF is the value that was in EFLAG.RF at the time the event handler was called. This includes: — Debug exceptions generated in response to instruction breakpoints — Hardware-generated interrupts arriving between instructions (including those arriving after the last iteration of a repeated string instruction) This appears to be why it works on Intel. Does AMD not do that? We could probably work around this in software (by not using irq work for this), but yuck. yep, but hopefuly it's the issue microcode ;-) Cc-ing guys from linux-firmware git Sherry, Suravee, any idea? thanks, jirka Jiri, I have duplicated your problem and asked the HW architect that wrote 832 to review the diff between
Re: [PATCH 1/1] memhp: Add hot-added memory ranges to memblock before allocate node_data for a node.
On 2015/8/24 17:22, Xishi Qiu wrote: On 2015/8/24 1:06, Tang Chen wrote: The commit below adds hot-added memory range to memblock, after creating pgdat for new node. commit f9126ab9241f66562debf69c2c9d8fee32ddcc53 Author: Xishi Qiu qiuxi...@huawei.com Date: Fri Aug 14 15:35:16 2015 -0700 memory-hotplug: fix wrong edge when hot add a new node But there is a problem: add_memory() |-- hotadd_new_pgdat() |-- free_area_init_node() |-- get_pfn_range_for_nid() |-- find start_pfn and end_pfn in memblock |-- .. |-- memblock_add_node(start, size, nid)Here, just too late. get_pfn_range_for_nid() will find that start_pfn and end_pfn are both 0. As a result, when adding memory, dmesg will give the following wrong message. Hi Tang, Another question, if we add cpu first, there will be print error too. cpu_up() try_online_node() hotadd_new_pgdat() So how about just skip the print if the size is empty or just print node xx is empty now, will update when online memory? Thanks, Xishi Qiu [ 2007.577000] Initmem setup node 5 [mem 0x-0x] [ 2007.584000] On node 5 totalpages: 0 [ 2007.585000] Built 5 zonelists in Node order, mobility grouping on. Total pages: 32588823 [ 2007.594000] Policy zone: Normal [ 2007.598000] init_memory_mapping: [mem 0x600-0x607] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v2 03/11] soc/fsl: Introduce the DPAA BMan portal driver
On Wed, Aug 12, 2015 at 04:14:49PM -0400, Roy Pledge wrote:
diff --git a/drivers/soc/fsl/qbman/bman.c b/drivers/soc/fsl/qbman/bman.c
index 9a500ce..d6e2204 100644
--- a/drivers/soc/fsl/qbman/bman.c
+++ b/drivers/soc/fsl/qbman/bman.c
@@ -165,11 +165,11 @@ static struct bman *bm_create(void *regs)
static inline u32 __bm_in(struct bman *bm, u32 offset)
{
- return in_be32((void *)bm + offset);
+ return ioread32be((void *)bm + offset);
}
static inline void __bm_out(struct bman *bm, u32 offset, u32 val)
{
- out_be32((void *)bm + offset, val);
+ iowrite32be(val, (void*) bm + offset);
}
Don't introduce a problem in one patch and then fix it in another. What
does this change have to do with introducing the portal driver?
#define bm_in(reg) __bm_in(bm, REG_##reg)
#define bm_out(reg, val) __bm_out(bm, REG_##reg, val)
@@ -341,6 +341,7 @@ u32 bm_pool_free_buffers(u32 bpid)
{
return bm_in(POOL_CONTENT(bpid));
}
+EXPORT_SYMBOL(bm_pool_free_buffers);
If you're exporting this (or even making it global), where's the
documentation?
+/* BTW, the drivers (and h/w programming model) already obtain the required
+ * synchronisation for portal accesses via lwsync(), hwsync(), and
+ * data-dependencies. Use of barrier()s or other order-preserving primitives
+ * simply degrade performance. Hence the use of the __raw_*() interfaces,
which
+ * simply ensure that the compiler treats the portal registers as volatile
(ie.
+ * non-coherent). */
volatile does not mean non-coherent.
Be careful with this regarding endian, e.g. on ARM we can run the CPU in
big or little endian on the same chip, and the raw accessors also
unfortunately bypass endian conversion.
+
+/* Cache-inhibited register access. */
+#define __bm_in(bm, o) __raw_readl((bm)-addr_ci + (o))
+#define __bm_out(bm, o, val) __raw_writel((val), (bm)-addr_ci + (o))
+#define bm_in(reg) __bm_in(portal-addr, BM_REG_##reg)
+#define bm_out(reg, val) __bm_out(portal-addr, BM_REG_##reg, val)
Don't have multiple implementations of bm_in/out, with the same name,
where bm in both refers to bman, but which have different functions.
+/* Cache-enabled (index) register access */
+#define __bm_cl_touch_ro(bm, o) dcbt_ro((bm)-addr_ce + (o))
+#define __bm_cl_touch_rw(bm, o) dcbt_rw((bm)-addr_ce + (o))
+#define __bm_cl_in(bm, o)__raw_readl((bm)-addr_ce + (o))
+#define __bm_cl_out(bm, o, val) \
+ do { \
+ u32 *__tmpclout = (bm)-addr_ce + (o); \
+ __raw_writel((val), __tmpclout); \
+ dcbf(__tmpclout); \
+ } while (0)
+#define __bm_cl_invalidate(bm, o) dcbi((bm)-addr_ce + (o))
+#define bm_cl_touch_ro(reg) __bm_cl_touch_ro(portal-addr,
BM_CL_##reg##_CENA)
+#define bm_cl_touch_rw(reg) __bm_cl_touch_rw(portal-addr,
BM_CL_##reg##_CENA)
+#define bm_cl_in(reg)__bm_cl_in(portal-addr,
BM_CL_##reg##_CENA)
+#define bm_cl_out(reg, val) __bm_cl_out(portal-addr, BM_CL_##reg##_CENA,
val)
+#define bm_cl_invalidate(reg)\
+ __bm_cl_invalidate(portal-addr, BM_CL_##reg##_CENA)
Define these using functions to operate on pointers, and pass the pointer
in without all the token-pasting. Some extra explanation of the cache
manipulation would also be helpful.
+/* --- RCR API --- */
+
+/* Bit-wise logic to wrap a ring pointer by clearing the carry bit */
+#define RCR_CARRYCLEAR(p) \
+ (void *)((unsigned long)(p) (~(unsigned long)(BM_RCR_SIZE 6)))
This could be a function.
Where does 6 come from? You use it again in the next function. Please
define it symbolically.
+
+/* Bit-wise logic to convert a ring pointer to a ring index */
+static inline u8 RCR_PTR2IDX(struct bm_rcr_entry *e)
+{
+ return ((uintptr_t)e 6) (BM_RCR_SIZE - 1);
+}
This is a function, so don't use ALLCAPS.
+/* Increment the 'cursor' ring pointer, taking 'vbit' into account */
+static inline void RCR_INC(struct bm_rcr *rcr)
+{
+ /* NB: this is odd-looking, but experiments show that it generates
+ * fast code with essentially no branching overheads. We increment to
+ * the next RCR pointer and handle overflow and 'vbit'. */
+ struct bm_rcr_entry *partial = rcr-cursor + 1;
+
+ rcr-cursor = RCR_CARRYCLEAR(partial);
+ if (partial != rcr-cursor)
+ rcr-vbit ^= BM_RCR_VERB_VBIT;
+}
+
+static inline int bm_rcr_init(struct bm_portal *portal, enum bm_rcr_pmode
pmode,
+ __maybe_unused enum bm_rcr_cmode cmode)
+{
+ /* This use of 'register', as well as all other occurrences, is because
+ * it has been observed to generate much faster code with gcc than is
+ * otherwise the case. */
+ register struct bm_rcr *rcr = portal-rcr;
What version of GCC? Normal optimization settings?
Has the seemingly excessive use of inline also been benchmarked against
not doing so?
+/* Buffer Pool Cleanup */
+static inline int bm_shutdown_pool(struct bm_portal
Re: [PATCH] SCSI: DTC: Removed 0 initialization for statics
On Mon, 29 Jun 2015, Rudhresh wrote:
Removed unneccessary initialization of zero to a static variable
Signed-off-by: Rudhresh Kumar J rudhre...@cdac.in
---
drivers/scsi/dtc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/dtc.c b/drivers/scsi/dtc.c
index 4c74c7b..99164d6 100644
--- a/drivers/scsi/dtc.c
+++ b/drivers/scsi/dtc.c
@@ -150,7 +150,7 @@ static const struct signature {
static int __init dtc_setup(char *str)
{
- static int commandline_current = 0;
+ static int commandline_current;
int i;
int ints[10];
@@ -188,7 +188,7 @@ __setup(dtc=, dtc_setup);
static int __init dtc_detect(struct scsi_host_template * tpnt)
{
- static int current_override = 0, current_base = 0;
+ static int current_override, current_base;
struct Scsi_Host *instance;
unsigned int addr;
void __iomem *base;
This issue affects all four copies of this code in the NCR5380 drivers:
drivers/scsi/t128.c:static int commandline_current = 0;
drivers/scsi/t128.c:static int current_override = 0, current_base = 0;
drivers/scsi/dtc.c: static int commandline_current = 0;
drivers/scsi/dtc.c: static int current_override = 0, current_base = 0;
drivers/scsi/g_NCR5380.c: static int commandline_current = 0;
drivers/scsi/g_NCR5380.c: static int current_override = 0;
drivers/scsi/pas16.c:static int commandline_current = 0;
drivers/scsi/pas16.c:static int current_override = 0;
drivers/scsi/pas16.c:static unsigned short current_base = 0;
And there are more instances of redundant initialization in pas16.c,
NCR5380.c and sun3_scsi.c.
All of these drivers have the same maintainers, so I'd prefer a single
patch to fix this.
You must address your patches to all of the interested parties (see
scripts/get_maintainer.pl).
--
--
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] SCSI: dtc: Fixed a brace issue on return 0
On Sun, 28 Jun 2015, Rudhresh wrote: From: rudhresh rudhresh...@gmail.com Return is not a function so parenthesis is not required Signed-off-by: Rudhresh rudhresh...@gmail.com Can you put your full name here? You must address your patches to all of the interested parties (see scripts/get_maintainer.pl). Please read Documentation/SubmittingPatches and adhere to the instructions therein. -- --- drivers/scsi/dtc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/dtc.c b/drivers/scsi/dtc.c index 4c74c7b..c793ecf 100644 --- a/drivers/scsi/dtc.c +++ b/drivers/scsi/dtc.c @@ -363,7 +363,7 @@ static inline int NCR5380_pread(struct Scsi_Host *instance, unsigned char *dst, NCR5380_read(RESET_PARITY_INTERRUPT_REG); if (i hostdata-spin_max_r) hostdata-spin_max_r = i; - return (0); + return 0; } / @@ -417,7 +417,7 @@ static inline int NCR5380_pwrite(struct Scsi_Host *instance, unsigned char *src, rtrc(0); if (i hostdata-spin_max_w) hostdata-spin_max_w = i; - return (0); + return 0; } MODULE_LICENSE(GPL); -- 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] SCSI: DTC: Adding KERN_ facility level
On Tue, 30 Jun 2015, Rudhresh Kumar J wrote:
Fixed coding style issue by adding KERN_ facility level to some of
the printk functions.
Signed-off-by: Rudhresh Kumar J rudhresh...@gmail.com
---
drivers/scsi/dtc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/dtc.c b/drivers/scsi/dtc.c
index 4c74c7b..a3a2a71 100644
--- a/drivers/scsi/dtc.c
+++ b/drivers/scsi/dtc.c
@@ -156,7 +156,7 @@ static int __init dtc_setup(char *str)
get_options(str, ARRAY_SIZE(ints), ints);
if (ints[0] != 2)
- printk(dtc_setup: usage dtc=address,irq\n);
+ printk(KERN_DEBUG dtc_setup: usage dtc=address,irq\n);
No, that is an error message that the user needs to see.
else if (commandline_current NO_OVERRIDES) {
overrides[commandline_current].address = ints[1];
overrides[commandline_current].irq = ints[2];
@@ -272,7 +272,7 @@ found:
instance-irq = NO_IRQ;
#endif
#if defined(DTCDEBUG) (DTCDEBUG DTCDEBUG_INIT)
- printk(scsi%d : irq = %d\n, instance-host_no, instance-irq);
+ printk(KERN_DEBUG scsi%d : irq = %d\n, instance-host_no,
instance-irq);
#endif
++current_override;
I have a better patch for this, which makes use of the dprintk macro to
replace {DTC,P,T}DEBUG_INIT with NDEBUG_INIT. Thanks anyway.
--
--
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 6/7] ARM: dts: add SROM device node for exynos5
On 24.08.2015 17:02, Pankaj Dubey wrote: Add SROM controller device node for exynos5. CC: Rob Herring robh...@kernel.org CC: Mark Rutland mark.rutl...@arm.com CC: Ian Campbell ijc+devicet...@hellion.org.uk Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- arch/arm/boot/dts/exynos5.dtsi | 5 + 1 file changed, 5 insertions(+) Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com Best regards, Krzysztof -- 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: [PATCHv2 2/4] zsmalloc: use page-private instead of page-first_page
On (08/17/15 18:09), Kirill A. Shutemov wrote: [..] @@ -980,7 +979,7 @@ static struct page *alloc_zspage(struct size_class *class, gfp_t flags) if (i == 1) set_page_private(first_page, (unsigned long)page); if (i = 1) - page-first_page = first_page; + set_page_private(first_page, (unsigned long)first_page); This patch breaks zram/zsmalloc. Shouldn't it be `page-private = first_page' instead of `first_page-private = first_page'? IOW: - set_page_private(first_page, (unsigned long)first_page); + set_page_private(page, (unsigned long)first_page); ? -ss -- 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 06/10] mm: make vmstat.c explicitly non-modular
The Makefile currently controlling compilation of this code is obj-y meaning that it currently is not being built as a module by anyone. Lets remove the couple traces of modularity so that when reading the code there is no doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. However one could argue that subsys_initcall might make more sense here. Cc: Andrew Morton a...@linux-foundation.org Cc: Christoph Lameter c...@linux.com Cc: Johannes Weiner han...@cmpxchg.org Cc: Mel Gorman mgor...@suse.de Cc: Michal Hocko mho...@suse.cz Cc: Davidlohr Bueso d...@stgolabs.net Cc: Minchan Kim minc...@kernel.org Cc: Joonsoo Kim iamjoonsoo@lge.com Cc: linux...@kvack.org Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- mm/vmstat.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/mm/vmstat.c b/mm/vmstat.c index 1fd0886a389f..e6cd18cc4d75 100644 --- a/mm/vmstat.c +++ b/mm/vmstat.c @@ -12,7 +12,7 @@ #include linux/fs.h #include linux/mm.h #include linux/err.h -#include linux/module.h +#include linux/init.h #include linux/slab.h #include linux/cpu.h #include linux/cpumask.h @@ -1536,7 +1536,7 @@ static int __init setup_vmstat(void) #endif return 0; } -module_init(setup_vmstat) +device_initcall(setup_vmstat) #if defined(CONFIG_DEBUG_FS) defined(CONFIG_COMPACTION) @@ -1695,6 +1695,5 @@ fail: debugfs_remove_recursive(extfrag_debug_root); return -ENOMEM; } - -module_init(extfrag_debug_init); +device_initcall(extfrag_debug_init); #endif -- 2.5.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/
[PATCH 09/10] mm: make frontswap.c explicitly non-modular
The Kconfig currently controlling compilation of this code is: config FRONTSWAP bool Enable frontswap to cache swap pages if tmem is present ...meaning that it currently is not being built as a module by anyone. Lets remove the couple traces of modularity so that when reading the driver there is no doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. However one could argue that subsys_initcall might make more sense here. Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com Cc: Andrew Morton a...@linux-foundation.org Cc: linux...@kvack.org Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- mm/frontswap.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/mm/frontswap.c b/mm/frontswap.c index 27a9924caf61..b36409766831 100644 --- a/mm/frontswap.c +++ b/mm/frontswap.c @@ -15,7 +15,7 @@ #include linux/swap.h #include linux/swapops.h #include linux/security.h -#include linux/module.h +#include linux/init.h #include linux/debugfs.h #include linux/frontswap.h #include linux/swapfile.h @@ -500,5 +500,4 @@ static int __init init_frontswap(void) #endif return 0; } - -module_init(init_frontswap); +device_initcall(init_frontswap); -- 2.5.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 v4 13/52] PCI, acpiphp: Add missing realloc list checking after resource allocation
On Mon, Aug 24, 2015 at 3:09 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Thursday, August 20, 2015 11:20:28 PM Yinghai Lu wrote:
We check the realloc list, as list must be empty after allocation.
Add missing one acpiphp driver.
Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Len Brown l...@kernel.org
Cc: linux-a...@vger.kernel.org
---
drivers/pci/hotplug/acpiphp_glue.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/hotplug/acpiphp_glue.c
b/drivers/pci/hotplug/acpiphp_glue.c
index ff53856..1c7c1d7 100644
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -507,6 +507,7 @@ static void enable_slot(struct acpiphp_slot *slot)
}
}
__pci_bus_assign_resources(bus, add_list, NULL);
+ BUG_ON(!list_empty(add_list));
Is crashing the kernel the best we can do here?
What about bailing out with a WARN_ON() instead? Surely, the kernel can work
without the new device?
That should not happen.
If that list is not empty, we could have broken the assign logic for
optional or additional
resource allocation.
We have other two BUG_ON checking in drivers/pci/setup-bus.c.
Do we need to change them all to WARN_ON()?
or you prefer this version instead:
---
Subject: [PATCH] PCI: Separate realloc list checking after allocation
We check the realloc list, as list must be empty after allocation.
Separate the realloc list checking to another function.
Add checking that is missed in acpiphp driver.
-v2: change to WARN_ON addording to Rafael.
Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Len Brown l...@kernel.org
Cc: linux-a...@vger.kernel.org
---
drivers/pci/hotplug/acpiphp_glue.c |1 +
drivers/pci/pci.h |1 +
drivers/pci/setup-bus.c| 12 +---
3 files changed, 11 insertions(+), 3 deletions(-)
Index: linux-2.6/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-2.6.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-2.6/drivers/pci/hotplug/acpiphp_glue.c
@@ -507,6 +507,7 @@ static void enable_slot(struct acpiphp_s
}
}
__pci_bus_assign_resources(bus, add_list, NULL);
+pci_bus_check_realloc(add_list);
acpiphp_sanitize_bus(bus);
pcie_bus_configure_settings(bus);
Index: linux-2.6/drivers/pci/pci.h
===
--- linux-2.6.orig/drivers/pci/pci.h
+++ linux-2.6/drivers/pci/pci.h
@@ -237,6 +237,7 @@ void __pci_bus_size_bridges(struct pci_b
void __pci_bus_assign_resources(const struct pci_bus *bus,
struct list_head *realloc_head,
struct list_head *fail_head);
+void pci_bus_check_realloc(struct list_head *realloc_head);
bool pci_bus_clip_resource(struct pci_dev *dev, int idx);
void pci_reassigndev_resource_alignment(struct pci_dev *dev);
Index: linux-2.6/drivers/pci/setup-bus.c
===
--- linux-2.6.orig/drivers/pci/setup-bus.c
+++ linux-2.6/drivers/pci/setup-bus.c
@@ -349,6 +349,12 @@ out:
}
}
+void pci_bus_check_realloc(struct list_head *realloc_head)
+{
+if (WARN_ON(!list_empty(realloc_head)))
+free_list(realloc_head);
+}
+
/**
* assign_requested_resources_sorted() - satisfy resource requests
*
@@ -1860,7 +1866,7 @@ again:
/* Depth last, allocate resources and update the hardware. */
__pci_bus_assign_resources(bus, add_list, fail_head);
if (add_list)
-BUG_ON(!list_empty(add_list));
+pci_bus_check_realloc(add_list);
tried_times++;
/* any device complain? */
@@ -1935,7 +1941,7 @@ void pci_assign_unassigned_bridge_resour
again:
__pci_bus_size_bridges(parent, add_list);
__pci_bridge_assign_resources(bridge, add_list, fail_head);
-BUG_ON(!list_empty(add_list));
+pci_bus_check_realloc(add_list);
tried_times++;
if (list_empty(fail_head))
@@ -1994,6 +2000,6 @@ void pci_assign_unassigned_bus_resources
add_list);
up_read(pci_bus_sem);
__pci_bus_assign_resources(bus, add_list, NULL);
-BUG_ON(!list_empty(add_list));
+pci_bus_check_realloc(add_list);
}
EXPORT_SYMBOL_GPL(pci_assign_unassigned_bus_resources);
--
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 00/10] mm: fix instances of non-modular code using modular fcns
In the previous merge window, we made changes to allow better delineation between modular and non-modular code in commit 0fd972a7d91d6e15393c449492a04d94c0b89351 (module: relocate module_init from init.h to module.h). This allows us to now ensure module code looks modular and non-modular code does not accidentally look modular without suffering build breakage from header entanglement. Here we target mm code that is, by nature of their Kconfig/Makefile, only available to be built-in, but implicitly presenting itself as being possibly modular by way of using modular headers and macros. The goal here is to remove that illusion of modularity from these files, but in a way that leaves the actual runtime unchanged. We also get the side benefit of a reduced CPP overhead, since the removal of module.h from a file can reduce the number of lines emitted by 20k. In all but the hugetlb change, the change is the trivial remapping of module_init onto device_initcall -- which is what module_init becomes in the non-modular case. In the hugetlb case, there was also an unused/orphaned module_exit chunk of code that got removed. I considered using an alternate level (i.e. earlier) initcall but since we don't have an mm initcall category, there wasn't a clear choice. And staying with device initcall reduces this patch series to zero risk by keeping the status quo on init order processing, which is I think preferable as we approach the merge window in a week. Paul. --- Cc: Andrew Morton a...@linux-foundation.org Cc: Andrey Konovalov adech...@gmail.com Cc: Andrey Ryabinin a.ryabi...@samsung.com Cc: Christoph Lameter c...@linux.com Cc: Davidlohr Bueso d...@stgolabs.net Cc: David Rientjes rient...@google.com Cc: Hillf Danton hillf...@alibaba-inc.com Cc: Johannes Weiner han...@cmpxchg.org Cc: Joonsoo Kim iamjoonsoo@lge.com Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com Cc: Mel Gorman mgor...@suse.de Cc: Michal Hocko mho...@suse.cz Cc: Mike Kravetz mike.krav...@oracle.com Cc: Minchan Kim minc...@kernel.org Cc: Naoya Horiguchi n-horigu...@ah.jp.nec.com Cc: Pekka Enberg penb...@kernel.org Cc: Rob Jones rob.jo...@codethink.co.uk Cc: Roman Pen r.peni...@gmail.com Cc: Sasha Levin sasha.le...@oracle.com Cc: Toshi Kani toshi.k...@hp.com Cc: Vladimir Davydov vdavy...@parallels.com Cc: Vlastimil Babka vba...@suse.cz Cc: WANG Chao chaow...@redhat.com Cc: linux...@kvack.org Paul Gortmaker (10): mm: make cleancache.c explicitly non-modular mm: make slab_common.c explicitly non-modular mm: make hugetlb.c explicitly non-modular mm: make vmscan.c explicitly non-modular mm: make page_alloc.c explicitly non-modular mm: make vmstat.c explicitly non-modular mm: make workingset.c explicitly non-modular mm: make vmalloc.c explicitly non-modular mm: make frontswap.c explicitly non-modular mm: make kasan.c explicitly non-modular mm/cleancache.c | 4 ++-- mm/frontswap.c | 5 ++--- mm/hugetlb.c | 39 +-- mm/kasan/kasan.c | 4 +--- mm/page_alloc.c | 2 +- mm/slab_common.c | 4 ++-- mm/vmalloc.c | 4 ++-- mm/vmscan.c | 4 +--- mm/vmstat.c | 7 +++ mm/workingset.c | 4 ++-- 10 files changed, 17 insertions(+), 60 deletions(-) -- 2.5.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 block/for-linus] writeback: fix syncing of I_DIRTY_TIME inodes
On Mon, Aug 24, 2015 at 02:10:38PM -0400, Tejun Heo wrote: Hello, Dave. On Fri, Aug 21, 2015 at 09:04:51AM +1000, Dave Chinner wrote: Maybe I'm misunderstanding the code but all xfs_writepage() calls are from unbound workqueues - the writeback workers - while xfs_setfilesize() are from bound workqueues, so I wondered why that was and looked at the code and the setsize functions are run off of a separate work item which is queued from the end_bio callback and I can't tell who would be waiting for them. Dave, what am I missing? xfs_setfilesize runs transactions, so it can't be run from IO completion context as it needs to block (i.e. on log space or inode locks). It also can't block log IO completion, nor metadata Io completion, as only log IO completion can free log space, and the inode lock might be waiting on metadata buffer IO completion (e.g. during delayed allocation). Hence we have multiple IO completion workqueues to keep these things separated and deadlock free. i.e. they all get punted to a workqueue where they are then processed in a context that can block safely. I'm still a bit confused. What prevents the following from happening? 1. io completion of last dirty page of an inode and work item for xfs_setfilesize() is queued. 2. inode removed from dirty list. The inode has already been removed from the dirty list - that happens at inode writeback submission time, not IO completion. 3. __sync_filesystem() invokes sync_inodes_sb(). There are no dirty pages, so it finishes. There are no dirty pages, but the pages aren't clean, either. i.e they are still under writeback. Hence we need to invoke wait_inodes_sb() to wait for writeback on all pages to complete before returning. 4. xfs_fs_sync_fs() is called which calls _xfs_log_force() but the work item from #1 hasn't run yet, so the size update isn't written out. The bug here is that wait_inodes_sb() has not been run, therefore -syncfs is being run before IO completions have been processed and pages marked clean. 5. Crash. Is it that _xfs_log_force() waits for the setfilesize transaction created during writepage? No, it's wait_inodes_sb() that does the waiting for data IO completion for sync. Cheers, Dave. -- Dave Chinner da...@fromorbit.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 v4 4/4] Use 2GB memory block size on large-memory x86-64 systems
On Mon, Aug 24, 2015 at 2:25 PM, Yinghai Lu ying...@kernel.org wrote:
Can you boot with debug ignore_loglevel so we can see following print out
for vmemmap?
See attached. There are a few extra messages from my own debug printk()
calls. It seems that we successfully deal with node 0 from topology_init()
but die walking node 1. I see that the NODE_DATA limits for memory
on node 1 were from 1d7 to 3a0. But when we get into
register_mem_sect_under_node() we have rounded the start pfn down to
1d0 ... and we panic processing that range (which is in a hole in e820).
We seem to die here:
for (pfn = sect_start_pfn; pfn = sect_end_pfn; pfn++) {
int page_nid;
page_nid = get_nid_for_pfn(pfn);
-Tony
dmesg2
Description: Binary data
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy
On Mon, Aug 24, 2015 at 3:19 PM, Tejun Heo t...@kernel.org wrote: Hey, On Mon, Aug 24, 2015 at 02:58:23PM -0700, Paul Turner wrote: Why isn't it? Because the programs themselves might try to override it? The major reasons are: 1) Isolation. Doing everything with sched_setaffinity means that programs can use arbitrary resources if they desire. 1a) These restrictions need to also apply to threads created by library code. Which may be 3rd party. 2) Interaction between cpusets and sched_setaffinity. For necessary reasons, a cpuset update always overwrites all extant sched_setaffinity values. ...And we need some cpusets for (1)And we need periodic updates for access to shared cores. This is an erratic behavior on cpuset's part tho. Nothing else behaves this way and it's borderline buggy. It's actually the only sane possible interaction here. If you don't overwrite the masks you can no longer manage cpusets with a multi-threaded application. If you partially overwrite the masks you can create a host of inconsistent behaviors where an application suddenly loses parallelism. The *only* consistent way is to clobber all masks uniformly. Then either arrange for some notification to the application to re-sync, or use sub-sub-containers within the cpuset hierarchy to advertise finer-partitions. (Generally speaking, there is no real way to mate these APIs and part of the reason we use sub-containers here. What's being proposed will make this worse rather than better.) 3) Virtualization of CPU ids. (Multiple applications all binding to core 1 is a bad thing.) This is about who's setting the affinity, right? As long as an agent which knows system details sets it, which mechanism doesn't really matter. Yes, there are other ways to implement this. Let me try to restate: I think that we can specify the usage is specifically niche that it will *typically* be used by higher level management daemons which I really don't think that's the case. Can you provide examples of non-exceptional usage in this fashion? I heard of two use cases. One is sytem-partitioning that you're talking about and the other is preventing threads of the same process from stepping on each other's toes. There was a fancy word for the cacheline cannibalizing behavior which shows up in those scenarios. So this is a single example right, since the system partitioning case is the one in which it's exclusively used by a higher level management daemon. The case of an process with specifically identified threads in conflict certainly seems exceptional in the level of optimization both in implementation and analysis present. I would expect in this case that either they are comfortable with the more technical API, or they can coordinate with an external controller. Which is much less overloaded both by number of callers and by number of interfaces than it is in the cpuset case. It's more like there are two niche sets of use cases. If a programmable interface or cgroups has to be picked as an exclusive alternative, it's pretty clear that programmable interface is the way to go. I strongly disagree here: The *major obvious use* is partitioning of a system, which must act I don't know. Why is that more major obvious use? This is super duper fringe to begin with. It's like tallying up beans. Sure, some may be taller than others but they're all still beans and I'm not even sure there's a big difference between the two use cases here. I don't think the case of having a large compute farm with unimportant and important work is particularly fringe. Reducing the impact on the important work so that we can scavenge more cycles for the latency insensitive unimportant is very real. on groups of processes. Cgroups is the only interface we have which satisfies this today. Well, not really. cgroups is more convenient / better at these things but not the only way to do it. People have been doing isolation to varying degrees with other mechanisms for ages. Right, but it's exactly because of _how bad_ those other mechanisms _are_ that cgroups was originally created.Its growth was not managed well from there, but let's not step away from the fact that this interface was created to solve this problem. Ditto. Wouldn't it be better to implement something which resemables conventional programming interface rather than contorting the filesystem semantics? Maybe? This is a trade-off, some of which is built on the assumptions we're now debating. There is also value, cost-wise, in iterative improvement of what we have today rather than trying to nuke it from orbit. I do not know which of these is the right choice, it likely depends strongly on where we end up for sub-process interfaces. If we do support those I'm not sure it makes sense for them to have an entirely different API from process-level coordination, at which point the file-system
Re: [PATCH 3.12 00/82] 3.12.47-stable review
On 08/24/2015 03:09 AM, Jiri Slaby wrote: This is the start of the stable review cycle for the 3.12.47 release. There are 82 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Aug 26 11:08:59 CEST 2015. Anything received after that time might be too late. The whole patch series can be found in one patch at: http://kernel.org/pub/linux/kernel/people/jirislaby/stable-review/patch-3.12.47-rc1.xz and the diffstat can be found below. thanks, js Compiled and booted on my test system. No dmesg regressions. 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/
Re: [RFC PATCH 1/7] DMA: tegra-apb: Correct runtime-pm usage
On Monday, August 24, 2015 07:51:43 PM Vinod Koul wrote: On Mon, Aug 24, 2015 at 02:22:49PM +0100, Jon Hunter wrote: On 24/08/15 10:22, Vinod Koul wrote: On Mon, Aug 24, 2015 at 09:47:13AM +0100, Jon Hunter wrote: On 23/08/15 15:17, Vinod Koul wrote: On Tue, Aug 18, 2015 at 02:49:09PM +0100, Jon Hunter wrote: @@ -1543,7 +1531,7 @@ static int tegra_dma_pm_suspend(struct device *dev) int ret; /* Enable clock before accessing register */ - ret = tegra_dma_runtime_resume(dev); + ret = pm_runtime_get_sync(dev); why is this required ? Because the clock could be disabled when this function is called. This function saves the DMA context so that if the context is lost during suspend, it can be restored. Have you verified this? Coz my understanding is that when PM does suspend it will esnure you are runtime resume if runtime suspended and then will do suspend. So you do not need to do above I see what you are saying. I did some testing with ftrace today to trace rpm and suspend/resume calls. If the dma controller is runtime suspended and I do not call pm_runtime_get_sync() above then I do not see any runtime resume of the dma controller prior to suspend. Now I was hoping that this would cause a complete kernel crash but it did not and so the DMA clock did not appear to be needed here (at least on the one board I tested). However, I would not go as far as to remove this and prefer to keep as above. Okay am adding Rafael here for his recommendations. Well, and what is the question I'm supposed to answer, exactly? I was in Seattle last week, so haven't been following this closely. I have tested in past and if my driver was runtime suspended we were resumed prior to being suspended. So I am not sure why you did not see that behaviour, and if that is right we don't need to force resume here We're adding code for skipping runtime-resume-before-system-suspend, because it is not desirable in general. The rule of thumb is that if you know you need to change the device's settings (eg. because of wakeup being enabled or not) for system suspend and that requires the device to be resumed, resume it. It can stay suspended otherwise. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] arch/x86: make mm/pageattr[-test].c explicitly non-modular
The file pageattr.c is obj-y and it includes pageattr-test.c based on CPA_DEBUG (a bool), meaning that no code here is currently being built as a module by anyone. Lets remove the couple traces of modularity so that when reading the code there is no doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. Cc: Thomas Gleixner t...@linutronix.de Cc: Ingo Molnar mi...@redhat.com Cc: H. Peter Anvin h...@zytor.com Cc: x...@kernel.org Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- arch/x86/mm/pageattr-test.c | 4 ++-- arch/x86/mm/pageattr.c | 1 - 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/x86/mm/pageattr-test.c b/arch/x86/mm/pageattr-test.c index 8ff686aa7e8c..5f169d5d76a8 100644 --- a/arch/x86/mm/pageattr-test.c +++ b/arch/x86/mm/pageattr-test.c @@ -8,6 +8,7 @@ #include linux/kthread.h #include linux/random.h #include linux/kernel.h +#include linux/init.h #include linux/mm.h #include linux/vmalloc.h @@ -256,5 +257,4 @@ static int start_pageattr_test(void) return 0; } - -module_init(start_pageattr_test); +device_initcall(start_pageattr_test); diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c index 727158cb3b3c..2c44c0792301 100644 --- a/arch/x86/mm/pageattr.c +++ b/arch/x86/mm/pageattr.c @@ -4,7 +4,6 @@ */ #include linux/highmem.h #include linux/bootmem.h -#include linux/module.h #include linux/sched.h #include linux/mm.h #include linux/interrupt.h -- 2.5.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 v2 0/8] Fix error message and present UFS variant
Hi Yaniv, 2015-08-23 22:09 GMT+09:00 Yaniv Gardi yga...@codeaurora.org: V3: fixes a few minor issues. V2: fixes a few issues of unnecessary EXPORT_SYMBOL, types of parameters in routine definition, build errors in case CONFIG_PM is not defined and some other minor fixes. I've checked outstanding issues I reported for v1 and v2 are fixed in this version of series. So please feel free to add: Reviewed-by: Akinobu Mita akinobu.m...@gmail.com I still think that we should introduce print_hex_dump_io() or something simpler for dumping __iomem pointer instead of casting 'void __force *'. But it is only used for debug dump function, so I don't too much worry about it. -- 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] ARM: probes: Don't stop the machine if we're in the debugger
If we're in kgdb then the machine is already stopped. Trying to stop it again will cause us to try to sleep, which is not allowed while in kgdb. To avoid this problem, only stop the machine when we're not in kgdb. Reported-by: Aapo Vienamo avien...@nvidia.com Suggested-by: Kees Cook keesc...@chromium.org Signed-off-by: Douglas Anderson diand...@chromium.org --- arch/arm/kernel/patch.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/arm/kernel/patch.c b/arch/arm/kernel/patch.c index 69bda1a..abf30ec 100644 --- a/arch/arm/kernel/patch.c +++ b/arch/arm/kernel/patch.c @@ -1,5 +1,6 @@ #include linux/kernel.h #include linux/spinlock.h +#include linux/kgdb.h #include linux/kprobes.h #include linux/mm.h #include linux/stop_machine.h @@ -124,6 +125,9 @@ void __kprobes patch_text(void *addr, unsigned int insn) .insn = insn, }; - stop_machine(patch_text_stop_machine, patch, NULL); + /* Stop machine before patching; but not if in the debugger */ + if (unlikely(in_dbg_master())) + patch_text_stop_machine(patch); + else + stop_machine(patch_text_stop_machine, patch, NULL); } -- 2.5.0.457.gab17608 -- 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 4/4] Use 2GB memory block size on large-memory x86-64 systems
On Mon, Aug 24, 2015 at 4:41 PM, Yinghai Lu ying...@kernel.org wrote:
On Mon, Aug 24, 2015 at 3:39 PM, Tony Luck tony.l...@gmail.com wrote:
On Mon, Aug 24, 2015 at 2:25 PM, Yinghai Lu ying...@kernel.org wrote:
Can you boot with debug ignore_loglevel so we can see following print out
for vmemmap?
See attached. There are a few extra messages from my own debug printk()
calls. It seems that we successfully deal with node 0 from topology_init()
but die walking node 1. I see that the NODE_DATA limits for memory
on node 1 were from 1d7 to 3a0. But when we get into
register_mem_sect_under_node() we have rounded the start pfn down to
1d0 ... and we panic processing that range (which is in a hole in e820).
We seem to die here:
for (pfn = sect_start_pfn; pfn = sect_end_pfn; pfn++) {
int page_nid;
page_nid = get_nid_for_pfn(pfn);
oh, no.
register_mem_sect_under_node() is assuming:
first section in the block is present and first page in that section is
present.
attached should fix the problem:
diff --git a/drivers/base/node.c b/drivers/base/node.c
index 31df474d..cc910ad 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -390,8 +390,14 @@ int register_mem_sect_under_node(struct memory_block *mem_blk, int nid)
sect_end_pfn = section_nr_to_pfn(mem_blk-end_section_nr);
sect_end_pfn += PAGES_PER_SECTION - 1;
for (pfn = sect_start_pfn; pfn = sect_end_pfn; pfn++) {
- int page_nid;
+ int page_nid, scn_nr;
+ scn_nr = pfn_to_section_nr(pfn);
+ if (!present_section_nr(scn_nr)) {
+ pfn = round_down(pfn + PAGES_PER_SECTION,
+ PAGES_PER_SECTION) - 1;
+ continue;
+ }
page_nid = get_nid_for_pfn(pfn);
if (page_nid 0)
continue;
@@ -426,10 +432,18 @@ int unregister_mem_sect_under_nodes(struct memory_block *mem_blk,
return -ENOMEM;
nodes_clear(*unlinked_nodes);
- sect_start_pfn = section_nr_to_pfn(phys_index);
- sect_end_pfn = sect_start_pfn + PAGES_PER_SECTION - 1;
+ sect_start_pfn = section_nr_to_pfn(mem_blk-start_section_nr);
+ sect_end_pfn = section_nr_to_pfn(mem_blk-end_section_nr);
+ sect_end_pfn += PAGES_PER_SECTION - 1;
for (pfn = sect_start_pfn; pfn = sect_end_pfn; pfn++) {
- int nid;
+ int nid, scn_nr;
+
+ scn_nr = pfn_to_section_nr(pfn);
+ if (!present_section_nr(scn_nr)) {
+ pfn = round_down(pfn + PAGES_PER_SECTION,
+ PAGES_PER_SECTION) - 1;
+ continue;
+ }
nid = get_nid_for_pfn(pfn);
if (nid 0)
Re: [PATCH v4 1/3] ARM: qcom: add SFPB nodes to IPQ806x dts
On 08/18, Mathieu Olivari wrote: Add one new node to the ipq806x.dtsi file to declare register the hardware spinlock devices. This mechanism is required to be used by other drivers such as SMEM. Signed-off-by: Mathieu Olivari math...@codeaurora.org --- Reviewed-by: Stephen Boyd sb...@codeaurora.org -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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/
[PATCHv5 net-next 00/10] OVS conntrack support
The goal of this series is to allow OVS to send packets through the Linux kernel connection tracker, and subsequently match on fields populated by conntrack. This version addresses the feedback from v4, mostly minor fixes, including shifting the conntrack init into the per-namespace functions rather than per-datapath and ensuring the ct_mark/ct_label attributes are re-serialized when userspace dumps the actions. Users attempting to specify actions that set ct_labels with a length longer than the supported length will now get flow rejections. This series also rebases against the latest conntrack zone changes. This functionality is enabled through the CONFIG_OPENVSWITCH_CONNTRACK option. The branch below has been updated with the corresponding userspace pieces: https://github.com/joestringer/ovs dev/ct_20150818 Joe Stringer (10): openvswitch: Serialize acts with original netlink len openvswitch: Move MASKED* macros to datapath.h ipv6: Export nf_ct_frag6_gather() dst: Add __skb_dst_copy() variation openvswitch: Add conntrack action openvswitch: Allow matching on conntrack mark netfilter: Always export nf_connlabels_replace() netfilter: connlabels: Export setting connlabel length openvswitch: Allow matching on conntrack label openvswitch: Allow attaching helpers to ct action include/net/dst.h | 9 +- include/net/netfilter/nf_conntrack_labels.h | 4 + include/uapi/linux/openvswitch.h| 58 +++ net/ipv6/netfilter/nf_conntrack_reasm.c | 1 + net/netfilter/nf_conntrack_labels.c | 34 +- net/netfilter/xt_connlabel.c| 16 +- net/openvswitch/Kconfig | 11 + net/openvswitch/Makefile| 2 + net/openvswitch/actions.c | 229 +++-- net/openvswitch/conntrack.c | 723 net/openvswitch/conntrack.h | 78 +++ net/openvswitch/datapath.c | 86 +++- net/openvswitch/datapath.h | 13 + net/openvswitch/flow.c | 6 +- net/openvswitch/flow.h | 11 +- net/openvswitch/flow_netlink.c | 129 - net/openvswitch/flow_netlink.h | 13 +- net/openvswitch/vport.c | 1 + 18 files changed, 1317 insertions(+), 107 deletions(-) create mode 100644 net/openvswitch/conntrack.c create mode 100644 net/openvswitch/conntrack.h -- 2.1.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/
[PATCHv5 net-next 03/10] ipv6: Export nf_ct_frag6_gather()
Signed-off-by: Joe Stringer joestrin...@nicira.com
Acked-by: Thomas Graf tg...@suug.ch
Acked-by: Pravin B Shelar pshe...@nicira.com
---
v4: Add ack.
v5: No change.
---
net/ipv6/netfilter/nf_conntrack_reasm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c
b/net/ipv6/netfilter/nf_conntrack_reasm.c
index 6d02498..701cd2b 100644
--- a/net/ipv6/netfilter/nf_conntrack_reasm.c
+++ b/net/ipv6/netfilter/nf_conntrack_reasm.c
@@ -633,6 +633,7 @@ ret_orig:
kfree_skb(clone);
return skb;
}
+EXPORT_SYMBOL_GPL(nf_ct_frag6_gather);
void nf_ct_frag6_consume_orig(struct sk_buff *skb)
{
--
2.1.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 v5 1/3] clk: bcm2835: Add binding docs for the Raspberry Pi clock provider
Eric Anholt e...@anholt.net writes: The hardware clocks are not controllable by the ARM, so we have to make requests to the firmware to do so from the VPU side. This will let us replace fixed clocks in our DT with actual clock control (and correct frequency information). Gordon from the Raspberry Pi Foundation just asked me what do you mean, you can't access the clocks from the ARM? I'd been assured I couldn't by another developer (who was originally going to write a Linux driver for this), and my own testing had also indicated I couldn't, but after a new round of hacking together some tests, I see things that look a lot like clockman registers. Looks like we're going to get a native driver, instead. signature.asc Description: PGP signature
[PATCHv5 net-next 04/10] dst: Add __skb_dst_copy() variation
This variation on skb_dst_copy() doesn't require two skbs.
Signed-off-by: Joe Stringer joestrin...@nicira.com
Acked-by: Pravin B Shelar pshe...@nicira.com
---
v4: Add ack.
v5: No change.
---
include/net/dst.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/net/dst.h b/include/net/dst.h
index 0a9a723..6f282e7 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -286,13 +286,18 @@ static inline void skb_dst_drop(struct sk_buff *skb)
}
}
-static inline void skb_dst_copy(struct sk_buff *nskb, const struct sk_buff
*oskb)
+static inline void __skb_dst_copy(struct sk_buff *nskb, unsigned long refdst)
{
- nskb-_skb_refdst = oskb-_skb_refdst;
+ nskb-_skb_refdst = refdst;
if (!(nskb-_skb_refdst SKB_DST_NOREF))
dst_clone(skb_dst(nskb));
}
+static inline void skb_dst_copy(struct sk_buff *nskb, const struct sk_buff
*oskb)
+{
+ __skb_dst_copy(nskb, oskb-_skb_refdst);
+}
+
/**
* skb_dst_force - makes sure skb dst is refcounted
* @skb: buffer
--
2.1.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/
[PATCHv5 net-next 01/10] openvswitch: Serialize acts with original netlink len
Previously, we used the kernel-internal netlink actions length to
calculate the size of messages to serialize back to userspace.
However,the sw_flow_actions may not be formatted exactly the same as the
actions on the wire, so store the original actions length when
de-serializing and re-use the original length when serializing.
Signed-off-by: Joe Stringer joestrin...@nicira.com
Acked-by: Pravin B Shelar pshe...@nicira.com
---
v2: No change.
v3: Preserve original length across buffer resize.
v4: Add ack.
v5: No change.
---
net/openvswitch/datapath.c | 2 +-
net/openvswitch/flow.h | 1 +
net/openvswitch/flow_netlink.c | 2 ++
3 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index ffe984f..d5b5473 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -713,7 +713,7 @@ static size_t ovs_flow_cmd_msg_size(const struct
sw_flow_actions *acts,
/* OVS_FLOW_ATTR_ACTIONS */
if (should_fill_actions(ufid_flags))
- len += nla_total_size(acts-actions_len);
+ len += nla_total_size(acts-orig_len);
return len
+ nla_total_size(sizeof(struct ovs_flow_stats)) /*
OVS_FLOW_ATTR_STATS */
diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h
index b62cdb3..082a87b 100644
--- a/net/openvswitch/flow.h
+++ b/net/openvswitch/flow.h
@@ -144,6 +144,7 @@ struct sw_flow_id {
struct sw_flow_actions {
struct rcu_head rcu;
+ size_t orig_len;/* From flow_cmd_new netlink actions size */
u32 actions_len;
struct nlattr actions[];
};
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index 4e7a3f7..c182b28 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -1619,6 +1619,7 @@ static struct nlattr *reserve_sfa_size(struct
sw_flow_actions **sfa,
memcpy(acts-actions, (*sfa)-actions, (*sfa)-actions_len);
acts-actions_len = (*sfa)-actions_len;
+ acts-orig_len = (*sfa)-orig_len;
kfree(*sfa);
*sfa = acts;
@@ -2223,6 +2224,7 @@ int ovs_nla_copy_actions(const struct nlattr *attr,
if (IS_ERR(*sfa))
return PTR_ERR(*sfa);
+ (*sfa)-orig_len = nla_len(attr);
err = __ovs_nla_copy_actions(attr, key, 0, sfa, key-eth.type,
key-eth.tci, log);
if (err)
--
2.1.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/
linux-next: build failure after merge of the i2c tree
Hi Wolfram, After merging the i2c tree, today's linux-next build (x86_64 allmodconfig) failed like this: ERROR: of_irq_get_byname [drivers/i2c/i2c-core.ko] undefined! Caused by commit efb6a10b761e (i2c: allow specifying separate wakeup interrupt in device tree) I have used the i2c tree from next-20150824 for today. -- Cheers, Stephen Rothwells...@canb.auug.org.au -- 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 06/14] Documentation: drm/bridge: add document for analogix_dp
On 25.08.2015 10:33, Yakir Yang wrote:
Hi Krzysztof,
在 2015/8/25 7:49, Krzysztof Kozlowski 写道:
On 24.08.2015 21:48, Yakir Yang wrote:
Hi Krzysztof,
在 08/24/2015 12:20 PM, Krzysztof Kozlowski 写道:
On 24.08.2015 11:42, Yakir Yang wrote:
Hi Krzysztof,
在 08/23/2015 07:43 PM, Krzysztof Kozlowski 写道:
2015-08-24 8:23 GMT+09:00 Rob Herring robherri...@gmail.com:
On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang y...@rock-chips.com
wrote:
Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.
You can't just change the exynos bindings and break
compatibility. Is
there some agreement with exynos folks to do this?
No, there is no agreement. This wasn't even sent to Exynos
maintainers.
Sorry about this one, actually I have add Exynos maintainers in
version
1 version 2,
but lose some maintainers in version 3, I would fix it in bellow
versions.
Additionally the patchset did not look interesting to me because of
misleading subject - Documentation instead of ARM: dts:.
Yakir, please:
1. Provide backward compatibility. Mark old properties as deprecated
but still support them.
Do you mean that I should keep the old properties declare in
exynos-dp.txt,
but just mark them as deprecated flag.
That is one of ways how to do this. However more important is that
driver should still support old bindings so such code:
- if (of_property_read_u32(dp_node, samsung,color-space,
+ if (of_property_read_u32(dp_node, analogix,color-space,
is probably wrong. Will the driver support old DTB in the same way
as it
was supporting before the change?
Okay, I got your means. So document is not the focus, the most important
is that
driver should support the old dts prop.
Right, the focus is on the driver.
If so the new analogix dp driver
should keep
the samsung,color-space, rather then just mark it with [DEPRECATED]
flag.
If you are replacing a binding/property then it should be marked
deprecated. This means that the old property is still working but new
users of it should not be added.
Okay, so just quote Heiko's reply, such code would be need in analogix
dp driver.
if (of_property_read_u32(dp_node, analogix,color-space,
dp_video_config-color_space))
if (of_property_read_u32(dp_node, samsung,color-space,
dp_video_config-color_space)) {
dev_err(dev, failed to get color-space\n);
return ERR_PTR(-EINVAL);
}
Yes. It does not look pretty but something like this is needed.
Best regards,
Krzysztof
--
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 00/18] ARM: use const and __initconst for smp_operations
Hi Russell, Olof, 2015-08-25 6:44 GMT+09:00 Olof Johansson o...@lixom.net: On Mon, Aug 24, 2015 at 2:21 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Aug 24, 2015 at 02:12:06PM -0700, Olof Johansson wrote: Easiest of all would probably be to get the sub-arch patches into one release, then switch the prototypes and function definitions in the next. If you switch prototypes first you'll get a bunch of warnings, right? Wrong way around. :) If you change the sub-arches to declare the smp operations as const, and try and pass them into a function which doesn't take a const-pointer, you'll get a warning. The core bits need to go in first before the sub-arch patches. Ah yes, my bad. I think the series has limited value - it allows us to (a) check that a small quantity of code doesn't write to these things, and (b) allows us to move the SMP operations structure from __initdata to __initconstdata. It's still going to end up in the init region which is read/write in any case, and still gets thrown away. Given where we are, I don't think we need to rush this in during the last week before the merge window opens, even though it's trivial. Agreed. So if you pick it up for 4.4, we'll get the rest for 4.5. OK. I will put 01 and 02 to Russell's patch tracker (after waiting for a bit more comments just in case). I will do the rest later. -- Best Regards Masahiro Yamada -- 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 5/7] ARM: dts: add SROM device node for exynos4
On 24.08.2015 17:02, Pankaj Dubey wrote: Add device node of SROM controller for exynos4. CC: Rob Herring robh...@kernel.org CC: Mark Rutland mark.rutl...@arm.com CC: Ian Campbell ijc+devicet...@hellion.org.uk Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- arch/arm/boot/dts/exynos4.dtsi | 5 + 1 file changed, 5 insertions(+) Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com Best regards, Krzysztof -- 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] xen/blkfront: convert to blk-mq APIs
Hi Rafal, Please have a try adding --iodepth_batch=32 --iodepth_batch_complete=32 to the fio command line. I didn't see this issue any more, neither for domU. Thanks, -Bob On 08/21/2015 04:46 PM, Rafal Mielniczuk wrote: On 19/08/15 12:12, Bob Liu wrote: Hi Jens Christoph, Rafal reported an issue about this patch, that's after this patch no more merges happen and the performance dropped if modprobe null_blk irqmode=2 completion_nsec=100, but works fine if modprobe null_blk. I'm not sure whether it's as expect or not. Do you have any suggestions? Thank you! Here is the test result: fio --name=test --ioengine=libaio --rw=read --numjobs=8 --iodepth=32 \ --time_based=1 --runtime=30 --bs=4KB --filename=/dev/xvdb \ --direct=1 --group_reporting=1 --iodepth_batch=16 modprobe null_blk *no patch* (avgrq-sz = 8.00 avgqu-sz=5.00) READ: io=10655MB, aggrb=363694KB/s, minb=363694KB/s, maxb=363694KB/s, mint=30001msec, maxt=30001msec Disk stats (read/write): xvdb: ios=2715852/0, merge=1089/0, ticks=126572/0, in_queue=127456, util=100.00% *with patch* (avgrq-sz = 8.00 avgqu-sz=8.00) READ: io=20655MB, aggrb=705010KB/s, minb=705010KB/s, maxb=705010KB/s, mint=30001msec, maxt=30001msec Disk stats (read/write): xvdb: ios=5274633/0, merge=22/0, ticks=243208/0, in_queue=242908, util=99.98% modprobe null_blk irqmode=2 completion_nsec=100 *no patch* (avgrq-sz = 34.00 avgqu-sz=38.00) READ: io=10372MB, aggrb=354008KB/s, minb=354008KB/s, maxb=354008KB/s, mint=30003msec, maxt=30003msec Disk stats (read/write): xvdb: ios=621760/0, *merge=1988170/0*, ticks=1136700/0, in_queue=1146020, util=99.76% *with patch* (avgrq-sz = 8.00 avgqu-sz=28.00) READ: io=2876.8MB, aggrb=98187KB/s, minb=98187KB/s, maxb=98187KB/s, mint=30002msec, maxt=30002msec Disk stats (read/write): xvdb: ios=734048/0, merge=0/0, ticks=843584/0, in_queue=843080, util=99.72% Regards, -Bob Hello, We got a problem with the lack of merges also when we tested on null_blk device in dom0 directly. When we enabled multi queue block-layer we got no merges, even when we set the number of submission queues to 1. If I don't miss anything, that could suggest the problem lays somewhere in the blk-mq layer itself? Please take a look at the results below: fio --name=test --ioengine=libaio --rw=read --numjobs=8 --iodepth=32 \ --time_based=1 --runtime=30 --bs=4KB --filename=/dev/nullb0 \ --direct=1 --group_reporting=1 modprobe null_blk irqmode=2 completion_nsec=100 queue_mode=1 submit_queues=1 READ: io=13692MB, aggrb=467320KB/s, minb=467320KB/s, maxb=467320KB/s, mint=30002msec, maxt=30002msec Disk stats (read/write): nullb0: ios=991026/0, merge=2499524/0, ticks=1846952/0, in_queue=900012, util=100.00% modprobe null_blk irqmode=2 completion_nsec=100 queue_mode=2 submit_queues=1 READ: io=6839.1MB, aggrb=233452KB/s, minb=233452KB/s, maxb=233452KB/s, mint=30002msec, maxt=30002msec Disk stats (read/write): nullb0: ios=1743967/0, merge=0/0, ticks=1712900/0, in_queue=1839072, util=100.00% Thanks, Rafal On 07/13/2015 05:55 PM, Bob Liu wrote: Note: This patch is based on original work of Arianna's internship for GNOME's Outreach Program for Women. Only one hardware queue is used now, so there is no performance change. The legacy non-mq code is deleted completely which is the same as other drivers like virtio, mtip, and nvme. Also dropped one unnecessary holding of info-io_lock when calling blk_mq_stop_hw_queues(). Changes in v2: - Reorganized blk_mq_queue_rq() - Restored most io_locks in place Change in v3: - Rename blk_mq_queue_rq to blkif_queue_rq Signed-off-by: Arianna Avanzini avanzini.aria...@gmail.com Signed-off-by: Bob Liu
Re: [PATCH v6 3/3] qe_common: add qe_muram_ functions to manage muram
On 08/24/2015 02:31 AM, Zhao Qiang wrote:
diff --git a/drivers/soc/fsl/qe/qe_common.c b/drivers/soc/fsl/qe/qe_common.c
new file mode 100644
index 000..7f1762c
--- /dev/null
+++ b/drivers/soc/fsl/qe/qe_common.c
@@ -0,0 +1,193 @@
+/*
+ * common qe code
+ *
+ * author: scott wood scottw...@freescale.com
+ *
+ * copyright 2007-2008,2010 freescale Semiconductor, Inc.
+ *
+ * some parts derived from commproc.c/qe2_common.c, which is:
+ * copyright (c) 1997 dan error_act (dma...@jlc.net)
+ * copyright (c) 1999-2001 dan Malek d...@embeddedalley.com
+ * copyright (c) 2000 montavista Software, Inc (sou...@mvista.com)
+ * 2006 (c) montavista software, Inc.
+ * vitaly bordug vbor...@ru.mvista.com
+ *
+ * this program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the free software Foundation.
+ */
+
+#include linux/genalloc.h
+#include linux/list.h
+#include linux/init.h
+#include linux/of_device.h
+#include linux/spinlock.h
+#include linux/export.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/slab.h
+
+#include linux/io.h
+#include soc/fsl/qe/qe.h
+
+static struct gen_pool *muram_pool;
+static struct genpool_data_align muram_pool_data;
+static spinlock_t qe_muram_lock;
+static u8 __iomem *muram_vbase;
+static phys_addr_t muram_pbase;
+
+struct muram_block {
+ struct list_head head;
+ unsigned long start;
+ int size;
+};
+
+static LIST_HEAD(muram_block_list);
+
+/* max address size we deal with */
+#define OF_MAX_ADDR_CELLS 4
+
+int qe_muram_init(void)
+{
+ struct device_node *np;
+ struct resource r;
+ u32 zero[OF_MAX_ADDR_CELLS] = {};
+ resource_size_t max = 0;
+ int i = 0;
+ int ret = 0;
+
+ if (muram_pbase)
+ return 0;
+
+ muram_pool = gen_pool_create(1, -1);
+ gen_pool_set_algo(muram_pool, gen_pool_first_fit_align,
+ muram_pool_data);
+
+ np = of_find_compatible_node(NULL, NULL, fsl,qe-muram-data);
+ if (!np) {
+ /* try legacy bindings */
+ np = of_find_node_by_name(NULL, data-only);
+ if (!np) {
+ pr_err(Cannot find CPM muram data node);
+ ret = -ENODEV;
+ goto out;
+ }
+ }
+
+ muram_pbase = of_translate_address(np, zero);
+ if (muram_pbase == (phys_addr_t)OF_BAD_ADDR) {
+ pr_err(Cannot translate zero through CPM muram node);
+ ret = -ENODEV;
+ goto out;
+ }
+
+ while (of_address_to_resource(np, i++, r) == 0) {
+ if (r.end max)
+ max = r.end;
+ ret = gen_pool_add(muram_pool, r.start - muram_pbase,
+ resource_size(r), -1);
+ if (ret) {
+ pr_err(QE MURAM: could not add muram );
+ pr_err(remainder to pool!\n);
Don't split the error string over two lines
+ return ret;
returning here misses the error path
+ }
+
+ }
+
+ muram_vbase = ioremap(muram_pbase, max - muram_pbase + 1);
+ if (!muram_vbase) {
+ pr_err(Cannot map CPM muram);
+ ret = -ENOMEM;
+ }
+
gen_pool_destroy on the error path
+out:
+ of_node_put(np);
+ return ret;
+}
+
+/**
+ * qe_muram_alloc - allocate the requested size worth of multi-user ram
+ * @size: number of bytes to allocate
+ * @align: requested alignment, in bytes
+ *
+ * This function returns an offset into the muram area.
+ * Use qe_dpram_addr() to get the virtual address of the area.
+ * Use qe_muram_free() to free the allocation.
+ */
+unsigned long qe_muram_alloc(unsigned long size, unsigned long align)
+{
+ unsigned long start;
+ unsigned long flags;
+ struct muram_block *entry;
+
+ spin_lock_irqsave(qe_muram_lock, flags);
+ muram_pool_data.align = align;
+ start = gen_pool_alloc(muram_pool, size);
The advantage of creating gen_pool_alloc_data was so that you could
pass in the align automatically without having to modify the structure.
Is there a reason you aren't using that?
+ memset(qe_muram_addr(start), 0, size);
There doesn't seem to be a check for allocation failure from the
gen_alloc.
+ entry = kmalloc(sizeof(*entry), GFP_KERNEL);
+ if (!entry)
+ goto out;
+ entry-start = start;
+ entry-size = size;
+ list_add(entry-head, muram_block_list);
What's the point of keeping the block list anyway? It's used only in
this file and it only seems to duplicate what gen_alloc is doing internally.
Is there some lookup functionality you still need? Could you use a gen_alloc
API to do so?
+ spin_unlock_irqrestore(qe_muram_lock, flags);
+
+ return start;
+out:
+
Warning in irq_work_queue_on()
Hello, Tejun, As discussed last week, I am getting an occasional warning out of irq_work_queue_on() WARN_ON_ONCE(cpu_is_offline(cpu)). The repeat-by seems to be a week or so of rcutorture runs on 16-CPU KVM instances on x86. So please see below on the off-chance that this is of use. I have also attached a .config file. Thoughts? Thanx, Paul [ 875.702254] [ cut here ] [ 875.703111] WARNING: CPU: 0 PID: 768 at /home/paulmck/public_git/bisect-linux-rcu/kernel/irq_work.c:69 irq_work_queue_on+0xd4/0x110() [ 875.703227] Modules linked in: [ 875.703227] CPU: 0 PID: 768 Comm: rcu_torture_rea Tainted: GW 4.1.0-rc4+ #1 [ 875.703227] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 [ 875.703227] 81baadd8 88001dc5fce8 81895418 00aa [ 875.703227] 88001dc5fd28 810517d5 00015bc0 [ 875.703227] 0004 0004 88001fc8f980 88001fc8d500 [ 875.703227] Call Trace: [ 875.703227] [81895418] dump_stack+0x45/0x57 [ 875.703227] [810517d5] warn_slowpath_common+0x85/0xc0 [ 875.703227] [810518b5] warn_slowpath_null+0x15/0x20 [ 875.703227] [89a4] irq_work_queue_on+0xd4/0x110 [ 875.703227] [810c2d74] tick_nohz_full_kick_cpu+0x44/0x50 [ 875.703227] [81076384] wake_up_nohz_cpu+0xb4/0x100 [ 875.703227] [810b1196] internal_add_timer+0x86/0xa0 [ 875.703227] [810b30f1] mod_timer+0xf1/0x1e0 [ 875.703227] [810a63a4] rcu_torture_reader+0x2a4/0x2e0 [ 875.703227] [810a63e0] ? rcu_torture_reader+0x2e0/0x2e0 [ 875.703227] [810a6100] ? rcutorture_trace_dump.part.10+0x20/0x20 [ 875.703227] [8106d75d] kthread+0xcd/0xf0 [ 875.703227] [8106d690] ? kthread_create_on_node+0x180/0x180 [ 875.703227] [8189fb92] ret_from_fork+0x42/0x70 [ 875.703227] [8106d690] ? kthread_create_on_node+0x180/0x180 [ 875.703227] ---[ end trace 74175128740d0113 ]--- # # Automatically generated file; DO NOT EDIT. # Linux/x86 4.1.0-rc4 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_PERF_EVENTS_INTEL_UNCORE=y CONFIG_OUTPUT_FORMAT=elf64-x86-64 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_HAVE_INTEL_TXT=y CONFIG_X86_64_SMP=y CONFIG_X86_HT=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_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= # CONFIG_COMPILE_TEST is not set 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_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y CONFIG_USELIB=y CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_IRQ_DOMAIN=y CONFIG_GENERIC_MSI_IRQ=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_BROADCAST=y
Re: [PATCH 1/2] dmaengine: OF DMAEngine API based on CONFIG_DMA_OF instead of CONFIG_OF
Hi Vinod 5fa422c (dmaengine: move drivers/of/dma.c - drivers/dma/of-dma.c) moved OF base DMAEngine code to of-dma.c, then it based on CONFIG_DMA_OF. But, OF base DMAEngine API on of_dma.h still based on CONFIG_OF now. So, current kernel can't find OF base DMAEngine API if .config has CONFIG_OF, but not have CONFIG_DMA_OF. This patch tidyup it. I did a quick build with arm config, but didn't see any failures. But still am worried about random config and other builds may find. So I think it would be safer to merge this patch after merge window so that we have ample time to fix any issue OK, 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] kernel/sysctl.c: If count including the terminating byte '\0' the write system call should retrun success.
An application from HuaWei which works fine on 2.6 encounters this
issue on 3.0 or later kernel.
Test code:
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include unistd.h
#include stdio.h
#include string.h
#include errno.h
#define MAXLEN (100)
int main(int argc, char** argv)
{
int fd = 0;
int len = 0;
char pathname[MAXLEN] = {0};
char buf[2] = {0};
int ret = 0xF;
int value = 0xF;
if (argc 2)
{
printf(Input param error, less 2 param: %s, %s.\n,
argv[0], argv[1]);
return 1;
}
printf(Input: %s, %s \n, argv[0], argv[1]);
ret = sprintf(pathname,
/proc/sys/net/ipv4/conf/%s/rp_filter, argv[1]);
if (ret 0)
printf(sprintf error, errno %d, %s\n, errno, strerror(errno));
printf(file is: %s. \n, pathname);
fd = open(pathname, O_RDWR, S_IRUSR);
if (fd =0 )
{
printf(open %s failed, errno=%d, %s.\n, pathname,
errno, strerror(errno));
return 1;
}
printf(open %s ok, fd=%d\n, pathname, fd);
len = write(fd, 0\0, 2);
printf(write %d: len=%d, errno=%d, %s\n, fd, len, errno,
strerror(errno));
close(fd);
return 0;
}
On Tue, Aug 25, 2015 at 12:59 AM, Steven Rostedt rost...@goodmis.org wrote:
On Mon, 24 Aug 2015 16:56:13 +0800
Sean Fu fxinr...@gmail.com wrote:
when the input argument count including the terminating byte \0,
The write system call return EINVAL on proc file.
But it return success on regular file.
E.g. Writting two bytes (1\0) to /proc/sys/net/ipv4/conf/eth0/rp_filter.
write(fd, 1\0, 2) return EINVAL.
And what would do that? What tool broke because of this?
echo 1 /proc/sys/net/ipv4/conf/eth0/rp_filter
works just fine. strlen(string) would not include the nul character.
The only thing I could think of would be a sizeof(str), but then that
would include someone hardcoding an integer in a string, like:
char val[] = 1
write(fd, val, sizeof(val));
Again, what tool does that?
If there is a tool out in the wild that use to work on 2.6 (and was
running on 2.6 then, and not something that was created after that
change), then we can consider this fix.
-- Steve
--
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 06/14] Documentation: drm/bridge: add document for analogix_dp
Hi Krzysztof,
在 2015/8/25 7:49, Krzysztof Kozlowski 写道:
On 24.08.2015 21:48, Yakir Yang wrote:
Hi Krzysztof,
在 08/24/2015 12:20 PM, Krzysztof Kozlowski 写道:
On 24.08.2015 11:42, Yakir Yang wrote:
Hi Krzysztof,
在 08/23/2015 07:43 PM, Krzysztof Kozlowski 写道:
2015-08-24 8:23 GMT+09:00 Rob Herring robherri...@gmail.com:
On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang y...@rock-chips.com
wrote:
Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.
You can't just change the exynos bindings and break compatibility. Is
there some agreement with exynos folks to do this?
No, there is no agreement. This wasn't even sent to Exynos maintainers.
Sorry about this one, actually I have add Exynos maintainers in version
1 version 2,
but lose some maintainers in version 3, I would fix it in bellow
versions.
Additionally the patchset did not look interesting to me because of
misleading subject - Documentation instead of ARM: dts:.
Yakir, please:
1. Provide backward compatibility. Mark old properties as deprecated
but still support them.
Do you mean that I should keep the old properties declare in
exynos-dp.txt,
but just mark them as deprecated flag.
That is one of ways how to do this. However more important is that
driver should still support old bindings so such code:
- if (of_property_read_u32(dp_node, samsung,color-space,
+ if (of_property_read_u32(dp_node, analogix,color-space,
is probably wrong. Will the driver support old DTB in the same way as it
was supporting before the change?
Okay, I got your means. So document is not the focus, the most important
is that
driver should support the old dts prop.
Right, the focus is on the driver.
If so the new analogix dp driver
should keep
the samsung,color-space, rather then just mark it with [DEPRECATED] flag.
If you are replacing a binding/property then it should be marked
deprecated. This means that the old property is still working but new
users of it should not be added.
Okay, so just quote Heiko's reply, such code would be need in analogix
dp driver.
if (of_property_read_u32(dp_node, analogix,color-space,
dp_video_config-color_space))
if (of_property_read_u32(dp_node, samsung,color-space,
dp_video_config-color_space)) {
dev_err(dev, failed to get color-space\n);
return ERR_PTR(-EINVAL);
}
But from your follow suggest, I think you agree to update driver code,
and just mark
old prop with deprecated flag. If so I think such code would not be wrong
- if (of_property_read_u32(dp_node, samsung,color-space,
+ if (of_property_read_u32(dp_node, analogix,color-space,
It looks wrong because it breaks backward compatibility with existing
DTB. As I said before:
1. Provide backward compatibility. Mark old properties
as deprecated but still support them.
And actually @Rob have suggest me to remove the prefix, just use
color-space here.
For new bindings I don't mind. But please remember about existing users,
existing DTB and bisectability.
Let me show same examples, make
me understand your suggest rightly.
exynos-dp already contains deprecated properties. Other ways of doing
this would be:
Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
Documentation/devicetree/bindings/rtc/s3c-rtc.txt
It depends up to you. The touchscreen looks good because it organizes
old properties in a common section. In case of exynos-dp.txt you can add
at beginning of file information about new bindings and mark everything
deprecated.
Whoops, thanks for your remind, I prefer the touchscreen style.
1. samsung,ycbcr-coeff is abandoned in latest analogix-dp driver,
absolutely
I should not carry this to analogix-dp.txt document. But I should
keep this in
exynos-dp.txt document, and mark them with an little
deprecated flag.
[Documentation/devicetree/bindings/video/exynos_dp.txt]
Required properties for dp-controller:
[...]
-samsung,ycbcr-coeff (DEPRECATED):
YCbCr co-efficients for input video.
COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
Is it right ?
Yes, this is right.
2. Separate all DTS changes to a separate patch, unless bisectability
would be hurt. Anyway you should prepare it in a such way that
separation would be possible without breaking bisectability.
So I should separate this patch into two parts, one is name Document:,
the other is ARM: dts: .
Yes.
Honestly, I don't understand what the bisectability means in this
case.
I was referring to bisectability in general. The patchset should be
fully bisectable which means that it does not introduce any issues
during git bisect. This effectively means that at each intermediate
step (after applying
Re: parse_args() is too unforgivable?
Oleg Nesterov o...@redhat.com writes: On 08/24, Oleg Nesterov wrote: I booted the kernel with the additional patch below, and nothing bad has happened, Until I tried reboot it once with locktorture.verbose=true paramater. It didn't boot. This is because parse_args() just aborts after it hits the error, so other arguments at the same initcall level are simply ignored. Fixed by the patch below, but I simply can't believe nobody hit this (imo) bug before. Why does parse_args() do this?? I simply can't understand why parse_args() adds more random and hard-to-understand problems if one of the args (=true in this particular case) is wrong. Yes, the patch below is probably oversimplified / incomplete but imho the current behaviour is confusing. At least I was greatly confused ;) At least (I think) it makes sense to let the user know that the rest of command line was probably ignored. This is nice, but please save and return the error properly; modules need this too. I think nobody hit this before because they notice that they screwed up the commandline and it didn't boot. Thanks, Rusty. -- 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 linux-next v4 5/5] mtd: atmel-quadspi: add driver for Atmel QSPI controller
+ nor-read_reg = atmel_qspi_read_reg;
+ nor-write_reg = atmel_qspi_write_reg;
+ nor-read = atmel_qspi_read;
+ nor-write = atmel_qspi_write;
+ nor-erase = atmel_qspi_erase;
+ nor-set_protocol = atmel_qspi_set_protocol;
This is very good, the structure of spi_nor should add a hook function to
notify spi controller
That spi nor transfer protocol already changed.
+
+ if (of_modalias_node(child, modalias, sizeof(modalias)) 0) {
+ err = -ENODEV;
+ goto release_channel;
+ }
+
+ err = of_property_read_u32(child, spi-max-frequency, aq-clk_rate);
+ if (err 0)
+ goto release_channel;
+
+ err = atmel_qspi_init(aq);
+ if (err)
+ goto release_channel;
+
+ nor-dev-of_node = child;
+ err = spi_nor_scan(nor, modalias, SPI_NOR_QUAD);
goto release_channel;
+
...
static inline struct spi_nor *mtd_to_spi_nor(struct mtd_info *mtd) {
return mtd-priv;
@@ -944,6 +960,11 @@ static int micron_quad_enable(struct spi_nor *nor)
return ret;
}
+ /* switch protocol to Quad CMD 4-4-4 */
+ ret = spi_nor_set_protocol(nor, SPI_PROTO_4_4_4);
+ if (ret)
+ return ret;
+
This make sense,from spi nor side,once its protocol being changed,
Mtd layer must notify this status to spi nor controller immediately,
And spi nor controller also should re-adjust its protocol.
Otherwise, following reading SR operation will fail.
ret = spi_nor_wait_till_ready(nor);
if (ret)
return ret;
If my ack has any value in here, feel free to add it.
Acked-by: Bean Huo bean...@micron.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] [v2] x86, suspend: Save/restore extra MSR registers for suspend
Hi, Boris,thanks for your review
-Original Message-
From: Borislav Petkov [mailto:b...@alien8.de]
Sent: Monday, August 24, 2015 4:50 PM
To: Chen, Yu C
Cc: r...@rjwysocki.net; pa...@ucw.cz; t...@linutronix.de;
mi...@redhat.com; h...@zytor.com; Zhang, Rui; l...@kernel.org;
x...@kernel.org; linux...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [v2] x86, suspend: Save/restore extra MSR registers for
suspend
On Fri, Aug 21, 2015 at 07:53:34PM +0800, Chen Yu wrote:
+struct msr_type {
+ unsigned int msr_id;
+ bool msr_saved;
+ u64 msr_value;
+};
These definitions look awfully close to struct msr_info in include/asm/msr.h
Maybe reuse them instead of growing yet another type...
OK, I'll use msr_info instead of msr_id and msr_value:
struct msr_type {
bool msr_saved;
struct msr_info rv;
};
+static void msr_save_context(struct saved_context *ctxt) {
+ int i = 0;
+
+ for (i = 0; i ctxt-msr_for_save.num; i++) {
+ struct msr_type *msr =
+ ctxt-msr_for_save.msr_array[i];
No need for the line breaks here, let them stick out for better readability.
OK, will do.
+ msr-msr_saved = !rdmsrl_safe(msr-msr_id,
+ msr-msr_value);
+ }
+ struct msr_type *msr =
+ ctxt-msr_for_save.msr_array[i];
+ if (msr-msr_saved)
+ wrmsrl(msr-msr_id, msr-msr_value);
Ditto.
OK, will do.
Best Regards,
Yu
[PATCH] mmc: sdhci: fix dma memory leak in sdhci_pre_req()
Currently one mrq-data maybe execute dma_map_sg() twice
when mmc subsystem prepare over one new request, and the
following log show up:
sdhci[sdhci_pre_dma_transfer] invalid cookie: 24, next-cookie 25
In this condition, mrq-date map a dma-memory(1) in sdhci_pre_req
for the first time, and map another dma-memory(2) in sdhci_prepare_data
for the second time. But driver only unmap the dma-memory(2), and
dma-memory(1) never unmapped, which cause the dma memory leak issue.
This patch use another method to map the dma memory for the mrq-data
which can fix this dma memory leak issue.
Fixes: commit 348487cb28e66b0 (mmc: sdhci: use pipeline mmc requests to
improve performance)
Cc: sta...@vger.kernel.org # 4.0+
Reported-and-tested-by: Jiri Slaby jsl...@suse.cz
Signed-off-by: Haibo Chen haibo.c...@freescale.com
---
drivers/mmc/host/sdhci.c | 67 ++--
drivers/mmc/host/sdhci.h | 8 +++---
2 files changed, 29 insertions(+), 46 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index c83d110..8d2864b 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -54,8 +54,7 @@ static void sdhci_finish_command(struct sdhci_host *);
static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode);
static void sdhci_enable_preset_value(struct sdhci_host *host, bool enable);
static int sdhci_pre_dma_transfer(struct sdhci_host *host,
- struct mmc_data *data,
- struct sdhci_host_next *next);
+ struct mmc_data *data);
static int sdhci_do_get_cd(struct sdhci_host *host);
#ifdef CONFIG_PM
@@ -495,7 +494,7 @@ static int sdhci_adma_table_pre(struct sdhci_host *host,
goto fail;
BUG_ON(host-align_addr host-align_mask);
- host-sg_count = sdhci_pre_dma_transfer(host, data, NULL);
+ host-sg_count = sdhci_pre_dma_transfer(host, data);
if (host-sg_count 0)
goto unmap_align;
@@ -634,9 +633,11 @@ static void sdhci_adma_table_post(struct sdhci_host *host,
}
}
- if (!data-host_cookie)
+ if (data-host_cookie == COOKIE_MAPPED) {
dma_unmap_sg(mmc_dev(host-mmc), data-sg,
data-sg_len, direction);
+ data-host_cookie = COOKIE_UNMAPPED;
+ }
}
static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_command *cmd)
@@ -832,7 +833,7 @@ static void sdhci_prepare_data(struct sdhci_host *host,
struct mmc_command *cmd)
} else {
int sg_cnt;
- sg_cnt = sdhci_pre_dma_transfer(host, data, NULL);
+ sg_cnt = sdhci_pre_dma_transfer(host, data);
if (sg_cnt = 0) {
/*
* This only happens when someone fed
@@ -948,11 +949,13 @@ static void sdhci_finish_data(struct sdhci_host *host)
if (host-flags SDHCI_USE_ADMA)
sdhci_adma_table_post(host, data);
else {
- if (!data-host_cookie)
+ if (data-host_cookie == COOKIE_MAPPED) {
dma_unmap_sg(mmc_dev(host-mmc),
data-sg, data-sg_len,
(data-flags MMC_DATA_READ) ?
DMA_FROM_DEVICE : DMA_TO_DEVICE);
+ data-host_cookie = COOKIE_UNMAPPED;
+ }
}
}
@@ -2105,49 +2108,36 @@ static void sdhci_post_req(struct mmc_host *mmc, struct
mmc_request *mrq,
struct mmc_data *data = mrq-data;
if (host-flags SDHCI_REQ_USE_DMA) {
- if (data-host_cookie)
+ if (data-host_cookie == COOKIE_GIVEN ||
+ data-host_cookie == COOKIE_MAPPED)
dma_unmap_sg(mmc_dev(host-mmc), data-sg, data-sg_len,
data-flags MMC_DATA_WRITE ?
DMA_TO_DEVICE : DMA_FROM_DEVICE);
- mrq-data-host_cookie = 0;
+ data-host_cookie = COOKIE_UNMAPPED;
}
}
static int sdhci_pre_dma_transfer(struct sdhci_host *host,
- struct mmc_data *data,
- struct sdhci_host_next *next)
+ struct mmc_data *data)
{
int sg_count;
- if (!next data-host_cookie
- data-host_cookie != host-next_data.cookie) {
- pr_debug(DRIVER_NAME [%s] invalid cookie: %d, next-cookie
%d\n,
- __func__, data-host_cookie, host-next_data.cookie);
- data-host_cookie = 0;
+ if (data-host_cookie == COOKIE_MAPPED) {
+ data-host_cookie
Re: [PATCH 2/3] KVM: dynamise halt_poll_ns adjustment
Hi David，
On 8/25/15 1:00 AM, David Matlack wrote:
On Mon, Aug 24, 2015 at 5:53 AM, Wanpeng Li wanpeng...@hotmail.com wrote:
There are two new kernel parameters for changing the halt_poll_ns:
halt_poll_ns_grow and halt_poll_ns_shrink. halt_poll_ns_grow affects
halt_poll_ns when an interrupt arrives and halt_poll_ns_shrink
does it when idle VCPU is detected.
halt_poll_ns_shrink/ |
halt_poll_ns_grow| interrupt arrives| idle VCPU is detected
-+--+---
1 | = halt_poll_ns | = 0
halt_poll_ns | *= halt_poll_ns_grow | /= halt_poll_ns_shrink
otherwise| += halt_poll_ns_grow | -= halt_poll_ns_shrink
A third new parameter, halt_poll_ns_max, controls the maximal halt_poll_ns;
it is internally rounded down to a closest multiple of halt_poll_ns_grow.
I like the idea of growing and shrinking halt_poll_ns, but I'm not sure
we grow and shrink in the right places here. For example, if vcpu-halt_poll_ns
gets down to 0, I don't see how it can then grow back up.
This has already done in __grow_halt_poll_ns().
This might work better:
if (poll successfully for interrupt): stay the same
else if (length of kvm_vcpu_block is longer than halt_poll_ns_max): shrink
else if (length of kvm_vcpu_block is less than halt_poll_ns_max): grow
where halt_poll_ns_max is something reasonable, like 2 millisecond.
You get diminishing returns from halt polling as the length of the
halt gets longer (halt polling only reduces halt latency by 10-15 us).
So there's little benefit to polling longer than a few milliseconds.
Great idea, David! Thanks for your review and I will implement it in
next version. :-)
Regards,
Wanpeng Li
Signed-off-by: Wanpeng Li wanpeng...@hotmail.com
---
virt/kvm/kvm_main.c | 81 -
1 file changed, 80 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index a122b52..bcfbd35 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -66,9 +66,28 @@
MODULE_AUTHOR(Qumranet);
MODULE_LICENSE(GPL);
-static unsigned int halt_poll_ns;
+#define KVM_HALT_POLL_NS 50
+#define KVM_HALT_POLL_NS_GROW 2
+#define KVM_HALT_POLL_NS_SHRINK 0
+#define KVM_HALT_POLL_NS_MAX \
+ INT_MAX / KVM_HALT_POLL_NS_GROW
+
+static unsigned int halt_poll_ns = KVM_HALT_POLL_NS;
module_param(halt_poll_ns, uint, S_IRUGO | S_IWUSR);
+/* Default doubles per-vcpu halt_poll_ns. */
+static int halt_poll_ns_grow = KVM_HALT_POLL_NS_GROW;
+module_param(halt_poll_ns_grow, int, S_IRUGO);
+
+/* Default resets per-vcpu halt_poll_ns . */
+int halt_poll_ns_shrink = KVM_HALT_POLL_NS_SHRINK;
+module_param(halt_poll_ns_shrink, int, S_IRUGO);
+
+/* Default is to compute the maximum so we can never overflow. */
+unsigned int halt_poll_ns_actual_max = KVM_HALT_POLL_NS_MAX;
+unsigned int halt_poll_ns_max = KVM_HALT_POLL_NS_MAX;
+module_param(halt_poll_ns_max, int, S_IRUGO);
+
/*
* Ordering of locks:
*
@@ -1907,6 +1926,62 @@ void kvm_vcpu_mark_page_dirty(struct kvm_vcpu *vcpu,
gfn_t gfn)
}
EXPORT_SYMBOL_GPL(kvm_vcpu_mark_page_dirty);
+static unsigned int __grow_halt_poll_ns(unsigned int val)
+{
+ if (halt_poll_ns_grow 1)
+ return halt_poll_ns;
+
+ val = min(val, halt_poll_ns_actual_max);
+
+ if (val == 0)
+ return halt_poll_ns;
+
+ if (halt_poll_ns_grow halt_poll_ns)
+ val *= halt_poll_ns_grow;
+ else
+ val += halt_poll_ns_grow;
+
+ return val;
+}
+
+static unsigned int __shrink_halt_poll_ns(int val, int modifier, int minimum)
+{
+ if (modifier 1)
+ return 0;
+
+ if (modifier halt_poll_ns)
+ val /= modifier;
+ else
+ val -= modifier;
+
+ return val;
+}
+
+static void grow_halt_poll_ns(struct kvm_vcpu *vcpu)
+{
+ vcpu-halt_poll_ns = __grow_halt_poll_ns(vcpu-halt_poll_ns);
+}
+
+static void shrink_halt_poll_ns(struct kvm_vcpu *vcpu)
+{
+ vcpu-halt_poll_ns = __shrink_halt_poll_ns(vcpu-halt_poll_ns,
+ halt_poll_ns_shrink, halt_poll_ns);
+}
+
+/*
+ * halt_poll_ns_actual_max is computed to be one grow_halt_poll_ns() below
+ * halt_poll_ns_max. (See __grow_halt_poll_ns for the reason.)
+ * This prevents overflows, because ple_halt_poll_ns is int.
+ * halt_poll_ns_max effectively rounded down to a multiple of
halt_poll_ns_grow in
+ * this process.
+ */
+static void update_halt_poll_ns_actual_max(void)
+{
+ halt_poll_ns_actual_max =
+ __shrink_halt_poll_ns(max(halt_poll_ns_max, halt_poll_ns),
+ halt_poll_ns_grow, INT_MIN);
+}
+
static int kvm_vcpu_check_block(struct kvm_vcpu *vcpu)
{
if (kvm_arch_vcpu_runnable(vcpu)) {
@@ -1941,6 +2016,7 @@ void kvm_vcpu_block(struct kvm_vcpu *vcpu)
*/
if (kvm_vcpu_check_block(vcpu)
Re: [PATCH v3] qcom: ipq40xx: Add basic board/dts support for IPQ40XX SoC
On 08/24, Varadarajan Narayanan wrote:
Add initial dts files and SoC support for IPQ40XX
So far we haven't added any Xs in the model names for our SoC
support. Even for IPQ806X, we have it as IPQ8064 as the config
name with IPQ806x in the help text because there's IPQ8062 out
there. So I guess it should be IPQ4019 or something?
Signed-off-by: Varadarajan Narayanan var...@codeaurora.org
---
diff --git a/Documentation/devicetree/bindings/qcom.txt
b/Documentation/devicetree/bindings/qcom.txt
new file mode 100644
index 000..7d56bd0
--- /dev/null
+++ b/Documentation/devicetree/bindings/qcom.txt
@@ -0,0 +1,16 @@
+Qualcomm IPQ device tree bindings
+-
+
+System on Chip
+
+Device tree must specify which SoC it uses, with one of the
+following compatible strings
+
+ qcom,ipq40xx
+
+Platform
+
+Device tree must specify which Platform it uses, with one of the
+following compatible strings
+
+ qcom,ipq40xx-r3pc
This file is not complete and I don't see any other silicon
vendors doing this, so please drop the entire file.
diff --git a/arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts
b/arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts
new file mode 100644
index 000..7e4e629
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts
@@ -0,0 +1,33 @@
+/* Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include qcom-ipq40xx.dtsi
+
+/ {
+ model = Qualcomm Technologies, Inc. IPQ40XX R3PC;
Same here, we should know what model number is on the board.
+ compatible = qcom,ipq40xx-r3pc, qcom,ipq40xx;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x2000; /* 512MB */
+ };
Doesn't the bootloader fill the memory node for us? Why do we
need this?
+
+ chosen {
+ bootargs = root=/dev/ram rw init=/init
console=ttyMSM0,115200n8 initrd=0x8200,0x000E2246;
+ };
Please don't add bootargs. Use stdout-path for the console part
and everything else should be done by the bootloader or is the
defaults.
+
+ soc {
+ serial@78b {
+ status = ok;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/qcom-ipq40xx.dtsi
b/arch/arm/boot/dts/qcom-ipq40xx.dtsi
new file mode 100644
index 000..f572f38
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq40xx.dtsi
@@ -0,0 +1,81 @@
+/*
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/dts-v1/;
+
+#include skeleton.dtsi
+
+/ {
+ model = Qualcomm Technologies, Inc. IPQ40XX;
+ compatible = qcom,ipq40xx;
These two should also be specific and drop the Xs. Same goes for
the file name.
+ interrupt-parent = intc;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+ cpu@0 {
+ device_type = cpu;
+ compatible = arm,cortex-a7;
+ reg = 0x0;
+ };
+
+ cpu@1 {
+ device_type = cpu;
+ compatible = arm,cortex-a7;
+ reg = 0x1;
+ };
+
+ cpu@2 {
+ device_type = cpu;
+ compatible = arm,cortex-a7;
+ reg = 0x2;
+ };
+
+ cpu@3 {
+ device_type = cpu;
+ compatible = arm,cortex-a7;
+ reg = 0x3;
+ };
+ };
+
+ soc {
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ compatible = simple-bus;
+
+ intc: interrupt-controller@b00 {
+ compatible = qcom,msm-qgic2;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ reg = 0x0b00 0x1000,
+ 0x0b002000 0x1000;
+ };
+
+ timer {
This node is not a child of the SoC
Re: [PATCH 3/3] sched: Implement interface for cgroup unified hierarchy
Hello, On Mon, Aug 24, 2015 at 03:03:05PM -0700, Paul Turner wrote: Hmm... I was hoping for an actual configurations and usage scenarios. Preferably something people can set up and play with. This is much easier to set up and play with synthetically. Just create the 10 threads and 100 threads above then experiment with configurations designed at guaranteeing the set of 100 threads relatively uniform throughput regardless of how many are active. I don't think trying to run a VM stack adds anything except complexity of reproduction here. Well, but that loses most of details and why such use cases matter to begin with. We can imagine up stuff to induce arbitrary set of requirements. I take that the CPU intensive helper threads are usually IO workers? Is the scenario where the VM is set up with a lot of IO devices and different ones may consume large amount of CPU cycles at any given point? Yes, generally speaking there are a few major classes of IO (flash, disk, network) that a guest may invoke. Each of these backends is separate and chooses its own threading. Hmmm... if that's the case, would limiting iops on those IO devices (or classes of them) work? qemu already implements IO limit mechanism after all. Anyways, a point here is that threads of the same process competing isn't a new problem. There are many ways to make those threads play nice as the application itself often has to be involved anyway, especially for something like qemu which is heavily involved in provisioning resources. cgroups can be a nice brute-force add-on which lets sysadmins do wild things but it's inherently hacky and incomplete for coordinating threads. For example, what is it gonna do if qemu cloned vcpus and IO helpers dynamically off of the same parent thread? It requires application's cooperation anyway but at the same time is painful to actually interact from those applications. Thanks. -- tejun -- 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 05/10] mm: make page_alloc.c explicitly non-modular
The Makefile currently controlling compilation of this code is obj-y meaning that it currently is not being built as a module by anyone. Lets remove the couple traces of modularity so that when reading the driver there is no doubt it is builtin-only. We have to leave the module.h include though, as the file uses print_modules(). Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. However one could argue that subsys_initcall() would make more sense. Cc: Andrew Morton a...@linux-foundation.org Cc: Mel Gorman mgor...@suse.de Cc: Vlastimil Babka vba...@suse.cz Cc: David Rientjes rient...@google.com Cc: Michal Hocko mho...@suse.cz Cc: Joonsoo Kim iamjoonsoo@lge.com Cc: Johannes Weiner han...@cmpxchg.org Cc: Sasha Levin sasha.le...@oracle.com Cc: linux...@kvack.org Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- mm/page_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index c1024db4ac5f..b02c511320fa 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -6327,7 +6327,7 @@ int __meminit init_per_zone_wmark_min(void) setup_per_zone_inactive_ratio(); return 0; } -module_init(init_per_zone_wmark_min) +device_initcall(init_per_zone_wmark_min) /* * min_free_kbytes_sysctl_handler - just a wrapper around proc_dointvec() so -- 2.5.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/
[PATCH 08/10] mm: make vmalloc.c explicitly non-modular
The Kconfig currently controlling compilation of this code is CONFIG_MMU
which is per arch, but in all cases it is bool or def_bool meaning that
it currently is not being built as a module by anyone.
Lets remove the couple traces of modularity so that when reading the
code there is no doubt it is builtin-only.
Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit. However
one could argue that subsys_initcall might make more sense here.
Cc: Andrew Morton a...@linux-foundation.org
Cc: Joonsoo Kim iamjoonsoo@lge.com
Cc: Roman Pen r.peni...@gmail.com
Cc: Andrey Ryabinin a.ryabi...@samsung.com
Cc: Toshi Kani toshi.k...@hp.com
Cc: David Rientjes rient...@google.com
Cc: Rob Jones rob.jo...@codethink.co.uk
Cc: WANG Chao chaow...@redhat.com
Cc: linux...@kvack.org
Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com
---
mm/vmalloc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 2faaa2976447..a27e6b3d58f4 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -10,7 +10,7 @@
#include linux/vmalloc.h
#include linux/mm.h
-#include linux/module.h
+#include linux/init.h
#include linux/highmem.h
#include linux/sched.h
#include linux/slab.h
@@ -2686,7 +2686,7 @@ static int __init proc_vmalloc_init(void)
proc_create(vmallocinfo, S_IRUSR, NULL, proc_vmalloc_operations);
return 0;
}
-module_init(proc_vmalloc_init);
+device_initcall(proc_vmalloc_init);
void get_vmalloc_info(struct vmalloc_info *vmi)
{
--
2.5.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] Input: edt-ft5x06 - Switch to newer gpio framework
On 08/24/2015 03:56 PM, Dmitry Torokhov wrote:
On Mon, Aug 24, 2015 at 03:23:43PM -0500, Franklin S Cooper Jr. wrote:
On 08/24/2015 03:16 PM, Franklin S Cooper Jr. wrote:
On 08/24/2015 03:01 PM, Dmitry Torokhov wrote:
On Mon, Aug 24, 2015 at 02:48:36PM -0500, Franklin S Cooper Jr. wrote:
On 08/24/2015 02:41 PM, Dmitry Torokhov wrote:
On Fri, Aug 21, 2015 at 02:08:32PM -0500, Franklin S Cooper Jr wrote:
The current/old gpio framework used doesn't properly listen to
ACTIVE_LOW and ACTIVE_HIGH flags. The newer gpio framework takes into
account these flags when setting gpio values.
Also use gpiod_set_value_cansleep since wake and reset pins can be
provided by bus based io expanders.
Signed-off-by: Franklin S Cooper Jr fcoo...@ti.com
---
.../bindings/input/touchscreen/edt-ft5x06.txt | 4 +-
drivers/input/touchscreen/edt-ft5x06.c | 115
+++--
include/linux/input/edt-ft5x06.h | 4 +-
3 files changed, 43 insertions(+), 80 deletions(-)
diff --git
a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
index 76db967..9330d4d 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
@@ -50,6 +50,6 @@ Example:
pinctrl-0 = edt_ft5x06_pins;
interrupt-parent = gpio2;
interrupts = 5 0;
- reset-gpios = gpio2 6 1;
- wake-gpios = gpio4 9 0;
+ reset-gpios = gpio2 6 GPIO_ACTIVE_LOW;
+ wake-gpios = gpio4 9 GPIO_ACTIVE_HIGH;
};
diff --git a/drivers/input/touchscreen/edt-ft5x06.c
b/drivers/input/touchscreen/edt-ft5x06.c
index 394b1de..6b128b3 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -91,9 +91,9 @@ struct edt_ft5x06_ts_data {
u16 num_x;
u16 num_y;
- int reset_pin;
- int irq_pin;
- int wake_pin;
+ struct gpio_desc *reset_pin;
+ struct gpio_desc *wake_pin;
+ struct gpio_desc *irq_pin;
#if defined(CONFIG_DEBUG_FS)
struct dentry *debug_dir;
@@ -755,36 +755,14 @@ edt_ft5x06_ts_teardown_debugfs(struct
edt_ft5x06_ts_data *tsdata)
static int edt_ft5x06_ts_reset(struct i2c_client *client,
struct edt_ft5x06_ts_data *tsdata)
{
- int error;
-
- if (gpio_is_valid(tsdata-wake_pin)) {
- error = devm_gpio_request_one(client-dev,
- tsdata-wake_pin,
GPIOF_OUT_INIT_LOW,
- edt-ft5x06 wake);
- if (error) {
- dev_err(client-dev,
- Failed to request GPIO %d as wake pin,
error %d\n,
- tsdata-wake_pin, error);
- return error;
- }
-
+ if (tsdata-wake_pin) {
msleep(5);
- gpio_set_value(tsdata-wake_pin, 1);
+ gpiod_set_value_cansleep(tsdata-wake_pin, 1);
}
- if (gpio_is_valid(tsdata-reset_pin)) {
- /* this pulls reset down, enabling the low active reset
*/
- error = devm_gpio_request_one(client-dev,
- tsdata-reset_pin,
GPIOF_OUT_INIT_LOW,
- edt-ft5x06 reset);
- if (error) {
- dev_err(client-dev,
- Failed to request GPIO %d as reset
pin, error %d\n,
- tsdata-reset_pin, error);
- return error;
- }
+ if (tsdata-reset_pin) {
msleep(5);
- gpio_set_value(tsdata-reset_pin, 1);
+ gpiod_set_value_cansleep(tsdata-reset_pin, 1);
So this leaves the reset pin active. How exactly was this tested?
Normally if the output gpio connected to the reset pin is ACTIVE_HIGH
then this will take the tsc out of reset since
the reset pin is active low. However, I have a board that has an inverter
between the gpio and reset pin. So if I leave
the gpio as ACTIVE_HIGH then the inverter would cause the reset pin to go
low which will keep it in reset. So instead
I set the gpio to ACTIVE_LOW which gives me the expected result.
I do not really care about particular board. Assuming that polarity of
the GPIO in DTS is specified correctly the effect of:
gpiod_set_value_cansleep(tsdata-reset_pin, 1);
is reset pin being _active_, i.e. the chip is staying in reset state.
Setting the reset pin to 1/high will take the tsc out of reset. Setting the
pin to 0/low will put the tsc into reset mode.
It seems you are not quite getting gpiod API. Consider:
For gpios described as GPIO_ACTIVE_LOW:
[PATCH 10/10] mm: make kasan.c explicitly non-modular
The Makefile currently controlling compilation of this code is obj-y meaning that it currently is not being built as a module by anyone. Lets remove the couple traces of modularity so that when reading the code there is no doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. However one could argue that subsys_initcall might make more sense here. We don't replace module.h with init.h since the file already has that. Cc: Andrey Ryabinin a.ryabi...@samsung.com Cc: Andrew Morton a...@linux-foundation.org Cc: Andrey Konovalov adech...@gmail.com Cc: linux...@kvack.org Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- mm/kasan/kasan.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c index 7b28e9cdf1c7..19786018f172 100644 --- a/mm/kasan/kasan.c +++ b/mm/kasan/kasan.c @@ -22,7 +22,6 @@ #include linux/memblock.h #include linux/memory.h #include linux/mm.h -#include linux/module.h #include linux/printk.h #include linux/sched.h #include linux/slab.h @@ -532,6 +531,5 @@ static int __init kasan_memhotplug_init(void) return 0; } - -module_init(kasan_memhotplug_init); +device_initcall(kasan_memhotplug_init); #endif -- 2.5.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/
[PATCH 07/10] mm: make workingset.c explicitly non-modular
The Makefile currently controlling compilation of this code is obj-y meaning that it currently is not being built as a module by anyone. Lets remove the couple traces of modularity so that when reading the code there is no doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. However one could argue that subsys_initcall might make more sense here. Cc: Vladimir Davydov vdavy...@parallels.com Cc: Andrew Morton a...@linux-foundation.org Cc: linux...@kvack.org Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- mm/workingset.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/workingset.c b/mm/workingset.c index aa017133744b..c2c59f599610 100644 --- a/mm/workingset.c +++ b/mm/workingset.c @@ -8,7 +8,7 @@ #include linux/writeback.h #include linux/pagemap.h #include linux/atomic.h -#include linux/module.h +#include linux/init.h #include linux/swap.h #include linux/fs.h #include linux/mm.h @@ -412,4 +412,4 @@ err_list_lru: err: return ret; } -module_init(workingset_init); +device_initcall(workingset_init); -- 2.5.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/
[PATCH 03/10] mm: make hugetlb.c explicitly non-modular
The Kconfig currently controlling compilation of this code is:
config HUGETLBFS
bool HugeTLB file system support
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when reading the file there is no doubt it is builtin-only.
Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit. However
one could argue that fs_initcall() would make more sense here.
Cc: Andrew Morton a...@linux-foundation.org
Cc: Naoya Horiguchi n-horigu...@ah.jp.nec.com
Cc: Mike Kravetz mike.krav...@oracle.com
Cc: David Rientjes rient...@google.com
Cc: Hillf Danton hillf...@alibaba-inc.com
Cc: Davidlohr Bueso d...@stgolabs.net
Cc: linux...@kvack.org
Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com
---
mm/hugetlb.c | 39 +--
1 file changed, 1 insertion(+), 38 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 586aa69df900..1154152c8b99 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -4,7 +4,6 @@
*/
#include linux/list.h
#include linux/init.h
-#include linux/module.h
#include linux/mm.h
#include linux/seq_file.h
#include linux/sysctl.h
@@ -2439,25 +2438,6 @@ static void hugetlb_unregister_node(struct node *node)
nhs-hugepages_kobj = NULL;
}
-/*
- * hugetlb module exit: unregister hstate attributes from node devices
- * that have them.
- */
-static void hugetlb_unregister_all_nodes(void)
-{
- int nid;
-
- /*
-* disable node device registrations.
-*/
- register_hugetlbfs_with_node(NULL, NULL);
-
- /*
-* remove hstate attributes from any nodes that have them.
-*/
- for (nid = 0; nid nr_node_ids; nid++)
- hugetlb_unregister_node(node_devices[nid]);
-}
/*
* Register hstate attributes for a single node device.
@@ -2522,27 +2502,10 @@ static struct hstate *kobj_to_node_hstate(struct
kobject *kobj, int *nidp)
return NULL;
}
-static void hugetlb_unregister_all_nodes(void) { }
-
static void hugetlb_register_all_nodes(void) { }
#endif
-static void __exit hugetlb_exit(void)
-{
- struct hstate *h;
-
- hugetlb_unregister_all_nodes();
-
- for_each_hstate(h) {
- kobject_put(hstate_kobjs[hstate_index(h)]);
- }
-
- kobject_put(hugepages_kobj);
- kfree(hugetlb_fault_mutex_table);
-}
-module_exit(hugetlb_exit);
-
static int __init hugetlb_init(void)
{
int i;
@@ -2580,7 +2543,7 @@ static int __init hugetlb_init(void)
mutex_init(hugetlb_fault_mutex_table[i]);
return 0;
}
-module_init(hugetlb_init);
+device_initcall(hugetlb_init);
/* Should be called on processing a hugepagesz=... option */
void __init hugetlb_add_hstate(unsigned order)
--
2.5.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 3/3] sched: Implement interface for cgroup unified hierarchy
Hey, On Mon, Aug 24, 2015 at 02:58:23PM -0700, Paul Turner wrote: Why isn't it? Because the programs themselves might try to override it? The major reasons are: 1) Isolation. Doing everything with sched_setaffinity means that programs can use arbitrary resources if they desire. 1a) These restrictions need to also apply to threads created by library code. Which may be 3rd party. 2) Interaction between cpusets and sched_setaffinity. For necessary reasons, a cpuset update always overwrites all extant sched_setaffinity values. ...And we need some cpusets for (1)And we need periodic updates for access to shared cores. This is an erratic behavior on cpuset's part tho. Nothing else behaves this way and it's borderline buggy. 3) Virtualization of CPU ids. (Multiple applications all binding to core 1 is a bad thing.) This is about who's setting the affinity, right? As long as an agent which knows system details sets it, which mechanism doesn't really matter. Let me try to restate: I think that we can specify the usage is specifically niche that it will *typically* be used by higher level management daemons which I really don't think that's the case. Can you provide examples of non-exceptional usage in this fashion? I heard of two use cases. One is sytem-partitioning that you're talking about and the other is preventing threads of the same process from stepping on each other's toes. There was a fancy word for the cacheline cannibalizing behavior which shows up in those scenarios. It's more like there are two niche sets of use cases. If a programmable interface or cgroups has to be picked as an exclusive alternative, it's pretty clear that programmable interface is the way to go. I strongly disagree here: The *major obvious use* is partitioning of a system, which must act I don't know. Why is that more major obvious use? This is super duper fringe to begin with. It's like tallying up beans. Sure, some may be taller than others but they're all still beans and I'm not even sure there's a big difference between the two use cases here. on groups of processes. Cgroups is the only interface we have which satisfies this today. Well, not really. cgroups is more convenient / better at these things but not the only way to do it. People have been doing isolation to varying degrees with other mechanisms for ages. Ditto. Wouldn't it be better to implement something which resemables conventional programming interface rather than contorting the filesystem semantics? Maybe? This is a trade-off, some of which is built on the assumptions we're now debating. There is also value, cost-wise, in iterative improvement of what we have today rather than trying to nuke it from orbit. I do not know which of these is the right choice, it likely depends strongly on where we end up for sub-process interfaces. If we do support those I'm not sure it makes sense for them to have an entirely different API from process-level coordination, at which point the file-system overload is a trade-off rather than a cost. Yeah, I understand the similarity part but don't buy that the benefit there is big enough to introduce a kernel API which is expected to be used by individual programs which is radically different from how processes / threads are organized and applications interact with the kernel. These are a lot more grave issues and if we end up paying some complexity from kernel side internally, so be it. So, except for cpuset, this doesn't matter for controllers. All limits are hierarchical and that's it. Well no, it still matters because I might want to lower the limit below what children have set. All controllers only get what their ancestors can hand down to them. That's basic hierarchical behavior. For cpuset, it's tricky because a nested cgroup might end up with no intersecting execution resource. The kernel can't have threads which don't have any execution resources and the solution has been assuming the resources from higher-ups till there's some. Application control has always behaved the same way. If the configured affinity becomes empty, the scheduler ignored it. Actually no, any configuration change that would result in this state is rejected. It's not possible to configure an empty cpuset once tasks are in it, or attach tasks to an empty set. It's also not possible to create this state using setaffinity, these restrictions are always over-ridden by updates, even if they do not need to be. So, even in traditional hierarchies, this isn't true. You can get to no-resource config through cpu hot-unplug and cpuset currently ejects tasks to the closest ancestor with execution resources. Because the details on this particular issue can be hashed out in the future? There's nothing permanently blocking any direction that we might choose in the future and what's working today will keep working.
Re: [PATCH 1/3] KVM: make halt_poll_ns per-VCPU
On 8/25/15 12:59 AM, David Matlack wrote:
On Mon, Aug 24, 2015 at 5:53 AM, Wanpeng Li wanpeng...@hotmail.com wrote:
Change halt_poll_ns into per-VCPU variable, seeded from module parameter,
to allow greater flexibility.
You should also change kvm_vcpu_block to read halt_poll_ns from
the vcpu instead of the module parameter.
Indeed, thanks for your review. :-)
Regards,
Wanpeng Li
Signed-off-by: Wanpeng Li wanpeng...@hotmail.com
---
include/linux/kvm_host.h | 1 +
virt/kvm/kvm_main.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 81089cf..1bef9e2 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -242,6 +242,7 @@ struct kvm_vcpu {
int sigset_active;
sigset_t sigset;
struct kvm_vcpu_stat stat;
+ unsigned int halt_poll_ns;
#ifdef CONFIG_HAS_IOMEM
int mmio_needed;
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index d8db2f8f..a122b52 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -217,6 +217,7 @@ int kvm_vcpu_init(struct kvm_vcpu *vcpu, struct kvm *kvm,
unsigned id)
vcpu-kvm = kvm;
vcpu-vcpu_id = id;
vcpu-pid = NULL;
+ vcpu-halt_poll_ns = halt_poll_ns;
init_waitqueue_head(vcpu-wq);
kvm_async_pf_vcpu_init(vcpu);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [v2 00/11] Freescale DPAA QBMan Drivers
On Wed, 2015-08-12 at 16:14 -0400, Roy Pledge wrote: The Freescale Data Path Acceleration Architecture (DPAA) is a set of hardware components on specific QorIQ multicore processors. This architecture provides the infrastructure to support simplified sharing of networking interfaces and accelerators by multiple CPU cores and the accelerators. The Queue Manager (QMan) is a hardware queue management block that allows software and accelerators on the datapath to enqueue and dequeue frames in order to communicate. The Buffer Manager (BMan) is a hardware buffer pool management block that allows software and accelerators on the datapath to acquire and release buffers in order to build frames. This patch set introduces the QBMan driver code that configures initializes the QBMan hardware and provides APIs for software to use the frame queues and buffer pools the blocks provide. These drivers provide the base fuctionality for software to communicate with the other DPAA accelerators on Freescale QorIQ processors. Changes from v1: - Cleanup Kconfig options - Changed base QMan and BMan drivers to only be buit in. Will add loadable support in future patch CONFIG_FSL_BMAN is tristate -- is it not expected to work if you select 'm'? - Replace panic() call with WARN_ON() panic() is still there. - Replaced PowerPC specific IO accessors with platform independent versions PowerPC accessors, and other PPC-specfic things like cache flushing and memory barriers, are still there. -Scott -- 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] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands) DMA leaks]
Hi Laura,
You can find the patch here:
http://patchwork.kernerl.xyz/patch/6967161/
I will send this patch again and cc to you.
Best regards
Haibo
-Original Message-
From: Laura Abbott [mailto:labb...@redhat.com]
Sent: Tuesday, August 25, 2015 12:27 AM
To: Chen Haibo-B51421; Jiri Slaby; Ulf Hansson
Cc: linux-...@vger.kernel.org; Linux kernel mailing list
Subject: Re: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy (thousands)
DMA leaks]
On 08/06/2015 02:17 AM, Chen Bough wrote:
I will format a patch based on your diff file firstly. I will test
this on my side, If any issue, like dma issue or performance issue, I
will add some modification.
Then I will send the patch for review, and you can test the patch on
your platform.
Best Regards
Haibo Chen
Did I miss the follow up patch or is this still pending? If it's still
pending, would you mind Ccing me when it's available for testing?
Thanks,
Laura
-Original Message-
From: Jiri Slaby [mailto:jsl...@suse.cz]
Sent: Thursday, August 06, 2015 5:07 PM
To: Chen Haibo-B51421; Ulf Hansson
Cc: linux-...@vger.kernel.org; Linux kernel mailing list
Subject: Re: [RFC] sdhci: fix DMA leaks [was: [SHDCI] Heavy
(thousands) DMA leaks]
On 08/06/2015, 09:42 AM, Chen Bough wrote:
I read your attached log and patch, yes, dma memory leak will happen
when more than one pre_request execute. The method of ++next-cookie
is not good, your patch seems good, but I still need some time to
test the patch, because you unmap the dma in sdhci_finish_data
rather than
the sdhci_post_req.
Hi,
yes, this is not correct. We can perhaps differentiate according to
the COOKIE value. Should I fix it or are you going to prepare a patch
based on my RFC?
thanks,
--
js
suse labs
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 0/3] ARM: uniphier: add outer cache support and rework SMP operations
Hi Olof, 2015-08-25 6:47 GMT+09:00 Olof Johansson o...@lixom.net: Hi, On Sun, Aug 23, 2015 at 7:18 PM, Masahiro Yamada yamada.masah...@socionext.com wrote: 1/3: add outer cache support 2/3: rework SMP operations 3/3: add device tree nodes Timing of this is unfortunate, please resend after 4.3-rc1 is out and we can queue it up. Given that rc8 is out and the merge window has been delayed, is it still too late for 4.3-rc1? Because 2/3 highly depends on 1/3, I hope whole of this series is applied to ARM-SOC tree. Review or acked-by from Russell would be appreciated in that case. Olof, From this series, I am using ARM: uniphier: rather than ARM: UniPhier: for the subject prefixes because I noticed you often rephased so when you applied my patches. Are sub-arch names in lower cases preferable in subject prefixes? If you look at git log --no-merges --oneline arch/arm/mach-* you'll see that most platforms use either all-caps or all-lowercase. I see. But, we use UniPhier (with only U and P capitalized) in our official documents. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] cgroup: get a ref to source csses when migrating
Have you verified that the scenario you're describing can actually happen? AFAICS, cgroup_migrate_add_src() already does the pinning. Hmmm. Looking at it, group_migrate_add_src() does grab a ref on the css_set which contains the css, and the comments mention that grabbing a ref on the css_set will stop the css from being dropped. I must've misunderstood one of your previous emails (where you said that such code was not safe in the -can_fork(), -cancel_fork() and -fork()) path. You also mentioned that depending on the css_set's ref being bumped to protect the contained csses is sort of implementation detail. It can be implemented in different ways. Which made me think that depending on that is not a good idea. But if it's safe to depend on the cgroup_migrate_add_src() pinning the ref on the css_set, I'll drop this patch and fix up the other one accordingly. -- Aleksa Sarai (cyphar) www.cyphar.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] kernel/sysctl.c: If count including the terminating byte '\0' the write system call should retrun success.
On August 24, 2015 6:57:57 PM MDT, Sean Fu fxinr...@gmail.com wrote: An application from HuaWei which works fine on 2.6 encounters this issue on 3.0 or later kernel. My sympathies. Being stuck with a 3rd party application you can barely talk about that has been broken for 5years and no one reported it. Ordinarily we would fix a regression like this. As it has been 5years the challenge now is how do we tell if there are applications that depend on the current behavior. Before we can change the behavior back we need a convincing argument that we won't cause a regression in another application by making the change. I do not see how such an argument can be made. So you have my sympathies but I do not see how we can help you. Eric -- 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 v6 3/3] qe_common: add qe_muram_ functions to manage muram
On 08/24/2015 08:03 PM, Zhao Qiang wrote:
-Original Message-
From: Laura Abbott [mailto:labb...@redhat.com]
Sent: Tuesday, August 25, 2015 7:32 AM
To: Zhao Qiang-B45475; Wood Scott-B07421
Cc: linux-kernel@vger.kernel.org; linuxppc-...@lists.ozlabs.org;
lau...@codeaurora.org; Xie Xiaobo-R63061; b...@kernel.crashing.org; Li
Yang-Leo-R58472; pau...@samba.org
Subject: Re: [PATCH v6 3/3] qe_common: add qe_muram_ functions to manage
muram
On 08/24/2015 02:31 AM, Zhao Qiang wrote:
+out:
+ of_node_put(np);
+ return ret;
+}
+
+/**
+ * qe_muram_alloc - allocate the requested size worth of multi-user
+ram
+ * @size: number of bytes to allocate
+ * @align: requested alignment, in bytes
+ *
+ * This function returns an offset into the muram area.
+ * Use qe_dpram_addr() to get the virtual address of the area.
+ * Use qe_muram_free() to free the allocation.
+ */
+unsigned long qe_muram_alloc(unsigned long size, unsigned long align)
+{
+ unsigned long start;
+ unsigned long flags;
+ struct muram_block *entry;
+
+ spin_lock_irqsave(qe_muram_lock, flags);
+ muram_pool_data.align = align;
+ start = gen_pool_alloc(muram_pool, size);
The advantage of creating gen_pool_alloc_data was so that you could pass
in the align automatically without having to modify the structure.
Is there a reason you aren't using that?
+ memset(qe_muram_addr(start), 0, size);
There doesn't seem to be a check for allocation failure from the
gen_alloc.
gen_pool_alloc will return 0 if there is error, but if the address returned is
just 0x0, it can't distinguish it is address or error.
Yes, that's a bad limitation of gen_pool. Maybe one day that will get fixed.
In a previous out of tree driver, I worked around this by offsetting the
gen_pool_add by a constant so any return value was non-zero and out of memory
was zero and then subtracting the constant off of the return value. Not sure
if that's better or worse than just fixing gen_alloc.
+ entry = kmalloc(sizeof(*entry), GFP_KERNEL);
+ if (!entry)
+ goto out;
+ entry-start = start;
+ entry-size = size;
+ list_add(entry-head, muram_block_list);
What's the point of keeping the block list anyway? It's used only in this
file and it only seems to duplicate what gen_alloc is doing internally.
Is there some lookup functionality you still need? Could you use a
gen_alloc API to do so?
I need to record the size when allocation, so when free the block, I can get
The right size for the block, and pass the right size to
gen_pool_free(struct gen_pool *pool, unsigned long addr, size_t size).
Yes, I see now what you are doing.
Thanks,
Laura
Thanks
Zhao
Thanks,
Laura
--
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: [PATCHv2] Input: xpad - Fix double URB submission races
On 08/21/2015 09:50 AM, Dmitry Torokhov wrote: Hi Laura, On Mon, Aug 10, 2015 at 05:26:12PM -0700, Laura Abbott wrote: v2: Created a proper queue for events instead of just dropping them How long does it take for the queue to exhaust your memory if you keep bombarding the driver with requests? My script which changes the LEDs as fast as possible ran for 7+ hours on my machine with 16GB of RAM without exhausting all of it. This is also a very extreme case as almost any kind of delay between sending commands will drain the queue. I do not think you need a queue. I believe the nature of LEDs and rumble force feedback effect is such that you can discard all requests but the latest that arrived between the moment you submitted a request to the device and the moment you are ready submit a new one. So your suggestion is to only keep a single item in the queue? Thanks. Thanks, Laura -- 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] zswap: update docs for runtime-changeable attributes
On (08/19/15 11:56), Dan Streetman wrote: [..] Ugh that's madness. Still, a documented madness is better than an undocumented one. heh, i'm not sure why it's madness, the alternative of uncompressing/recompressing all pages into the new zpool and/or with the new compressor seems much worse ;-) Well, I sort of still think that 'change compressor and reboot' is OK. 5cents. The zsmalloc type zpool has a more +complex compressed page storage method, and it can achieve greater storage +densities. However, zsmalloc does not implement compressed page eviction, so +once zswap fills it cannot evict the oldest page, it can only reject new pages. I still wonder why anyone would use zsmalloc with zswap given this limitation. It seems only fine for zram which has no real swap as fallback. And even zbud doesn't have any shrinker interface that would react to memory pressure, so there's a possibility of premature OOM... sigh. for situations where zswap isn't expected to ever fill up, zsmalloc will outperform zbud, since it has higher density. But then you could just use zram? :) well not *expected* to fill up doesn't mean it *won't* fill up :) i'd argue that neither zbud nor zsmalloc are responsible for reacting to memory pressure, they just store the pages. It's zswap that has to limit its size, which it does with max_percent_pool. Yeah but it's zbud that tracks the aging via LRU and reacts to reclaim requests from zswap when zswap hits the limit. Zswap could easily add a shrinker that would relay this requests in response to memory pressure as well. However, zsmalloc doesn't implement the reclaim, or LRU tracking. I wrote a patch for zsmalloc reclaim a while ago: https://lwn.net/Articles/611713/ however it didn't make it in, due to the lack of zsmalloc LRU, or any proven benefit to zsmalloc reclaim. It's not really possible to add LRU to zsmalloc, by the nature of its design, using the struct page fields directly; there's no extra field to use as a lru entry. Just for information, zsmalloc now registers shrinker callbacks https://lkml.org/lkml/2015/7/8/497 -ss -- 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] ARM: OMAP: Change all cpu_is_* occurences to soc_is_*
On Tuesday 25 August 2015 02:54 AM, Russell King - ARM Linux wrote: On Tue, Aug 18, 2015 at 03:40:01PM +0530, Keerthy wrote: Currently apart from dra7, omap5 and amx3 all the other SoCs are identified using cpu_is_* functions which is not right since they are all SoCs(System on Chips). Hence changing the SoC identificätion code to use soc_is instead of cpu_is and keeping ^ typo I will correct and send a v2. defines for cpu_is where needed. This allows us to replace the rest of cpu_is usage along with other fixes as needed. Good to see this change to a more sensible naming of these, despite the obvious churn. Acked-by: Russell King rmk+ker...@arm.linux.org.uk Thanks Russel. I will fix the above typo and add your Ack in the next version. -- 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 11/20] ACPICA: Table handling: Cleanup and update debug output for tools.
From: Bob Moore robert.mo...@intel.com
ACPICA commit 93862bd7a227543bc617d822ef5c4f8a5d68b519
Add output of table OEM ID along with signature to support lots
of SSDTs.
Cleanup use of table pointers.
Link: https://github.com/acpica/acpica/commit/93862bd7
Signed-off-by: Bob Moore robert.mo...@intel.com
Signed-off-by: Lv Zheng lv.zh...@intel.com
---
drivers/acpi/acpica/dsinit.c | 11 +
drivers/acpi/acpica/tbxfload.c | 53 ++--
2 files changed, 30 insertions(+), 34 deletions(-)
diff --git a/drivers/acpi/acpica/dsinit.c b/drivers/acpi/acpica/dsinit.c
index bbf52f0..920f1b1 100644
--- a/drivers/acpi/acpica/dsinit.c
+++ b/drivers/acpi/acpica/dsinit.c
@@ -247,11 +247,12 @@ acpi_ds_initialize_objects(u32 table_index,
/* Summary of objects initialized */
ACPI_DEBUG_PRINT_RAW((ACPI_DB_INIT,
- Table [%4.4s] (id %4.4X) - %4u Objects with %3u
Devices,
- %3u Regions, %3u Methods (%u/%u/%u
Serial/Non/Cvt)\n,
- table-signature, owner_id, info.object_count,
- info.device_count, info.op_region_count,
- info.method_count, info.serial_method_count,
+ Table [%4.4s:%8.8s] (id %.2X) - %4u Objects with
%3u Devices,
+ %3u Regions, %4u Methods (%u/%u/%u
Serial/Non/Cvt)\n,
+ table-signature, table-oem_table_id, owner_id,
+ info.object_count, info.device_count,
+ info.op_region_count, info.method_count,
+ info.serial_method_count,
info.non_serial_method_count,
info.serialized_method_count));
diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
index 96b82a8..55ee14c 100644
--- a/drivers/acpi/acpica/tbxfload.c
+++ b/drivers/acpi/acpica/tbxfload.c
@@ -105,6 +105,7 @@ acpi_status acpi_tb_load_namespace(void)
acpi_status status;
u32 i;
struct acpi_table_header *new_dsdt;
+ struct acpi_table_desc *table;
u32 tables_loaded = 0;
u32 tables_failed = 0;
@@ -116,15 +117,11 @@ acpi_status acpi_tb_load_namespace(void)
* Load the namespace. The DSDT is required, but any SSDT and
* PSDT tables are optional. Verify the DSDT.
*/
+ table = acpi_gbl_root_table_list.tables[acpi_gbl_dsdt_index];
+
if (!acpi_gbl_root_table_list.current_table_count ||
- !ACPI_COMPARE_NAME(
- (acpi_gbl_root_table_list.
- tables[acpi_gbl_dsdt_index].signature),
- ACPI_SIG_DSDT)
- ||
- ACPI_FAILURE(acpi_tb_validate_table
-(acpi_gbl_root_table_list.
- tables[acpi_gbl_dsdt_index]))) {
+ !ACPI_COMPARE_NAME(table-signature.ascii, ACPI_SIG_DSDT) ||
+ ACPI_FAILURE(acpi_tb_validate_table(table))) {
status = AE_NO_ACPI_TABLES;
goto unlock_and_exit;
}
@@ -135,8 +132,7 @@ acpi_status acpi_tb_load_namespace(void)
* array can change dynamically as tables are loaded at run-time. Note:
* .Pointer field is not validated until after call to
acpi_tb_validate_table.
*/
- acpi_gbl_DSDT =
- acpi_gbl_root_table_list.tables[acpi_gbl_dsdt_index].pointer;
+ acpi_gbl_DSDT = table-pointer;
/*
* Optionally copy the entire DSDT to local memory (instead of simply
@@ -174,21 +170,15 @@ acpi_status acpi_tb_load_namespace(void)
(void)acpi_ut_acquire_mutex(ACPI_MTX_TABLES);
for (i = 0; i acpi_gbl_root_table_list.current_table_count; ++i) {
+ table = acpi_gbl_root_table_list.tables[i];
+
if (!acpi_gbl_root_table_list.tables[i].address ||
- (!ACPI_COMPARE_NAME
-((acpi_gbl_root_table_list.tables[i].signature),
- ACPI_SIG_SSDT)
-
-!ACPI_COMPARE_NAME(
- (acpi_gbl_root_table_list.tables[i].
-signature), ACPI_SIG_PSDT)
-
-!ACPI_COMPARE_NAME(
- (acpi_gbl_root_table_list.tables[i].
-signature), ACPI_SIG_OSDT))
- ||
- ACPI_FAILURE(acpi_tb_validate_table
-(acpi_gbl_root_table_list.tables[i]))) {
+ (!ACPI_COMPARE_NAME(table-signature.ascii, ACPI_SIG_SSDT)
+ !ACPI_COMPARE_NAME(table-signature.ascii,
+ ACPI_SIG_PSDT)
+ !ACPI_COMPARE_NAME(table-signature.ascii,
+
[PATCH 12/20] ACPICA: Add additional debug info/statements.
From: Bob Moore robert.mo...@intel.com
ACPICA commit 74094ca9f51e2652a9b5f01722d8640a653cc75a
For _REG methods and module-level code blocks.
For acpiexec, add deletion of module-level blocks in case
of an early abort.
Link: https://github.com/acpica/acpica/commit/74094ca9
Signed-off-by: Bob Moore robert.mo...@intel.com
Signed-off-by: Lv Zheng lv.zh...@intel.com
---
drivers/acpi/acpica/aclocal.h |7 +++
drivers/acpi/acpica/evregion.c | 22 ++
drivers/acpi/acpica/nseval.c |3 ++-
drivers/acpi/acpica/nsutils.c | 17 +
drivers/acpi/acpica/psloop.c | 14 +-
5 files changed, 57 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index 92cbaee..acbf68b 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -406,6 +406,13 @@ struct acpi_simple_repair_info {
#define ACPI_NUM_RTYPES 5 /* Number of actual object
types */
+/* Info for running the _REG methods */
+
+struct acpi_reg_walk_info {
+ acpi_adr_space_type space_id;
+ u32 reg_run_count;
+};
+
/*
*
* Event typedefs and structs
diff --git a/drivers/acpi/acpica/evregion.c b/drivers/acpi/acpica/evregion.c
index 2ba28a6..5ee79a1 100644
--- a/drivers/acpi/acpica/evregion.c
+++ b/drivers/acpi/acpica/evregion.c
@@ -626,9 +626,17 @@ acpi_ev_execute_reg_methods(struct acpi_namespace_node
*node,
acpi_adr_space_type space_id)
{
acpi_status status;
+ struct acpi_reg_walk_info info;
ACPI_FUNCTION_TRACE(ev_execute_reg_methods);
+ info.space_id = space_id;
+ info.reg_run_count = 0;
+
+ ACPI_DEBUG_PRINT_RAW((ACPI_DB_NAMES,
+ Running _REG methods for SpaceId %s\n,
+ acpi_ut_get_region_name(info.space_id)));
+
/*
* Run all _REG methods for all Operation Regions for this space ID.
This
* is a separate walk in order to handle any interdependencies between
@@ -637,7 +645,7 @@ acpi_ev_execute_reg_methods(struct acpi_namespace_node
*node,
*/
status = acpi_ns_walk_namespace(ACPI_TYPE_ANY, node, ACPI_UINT32_MAX,
ACPI_NS_WALK_UNLOCK, acpi_ev_reg_run,
- NULL, space_id, NULL);
+ NULL, info, NULL);
/* Special case for EC: handle orphan _REG methods with no region */
@@ -645,6 +653,11 @@ acpi_ev_execute_reg_methods(struct acpi_namespace_node
*node,
acpi_ev_orphan_ec_reg_method(node);
}
+ ACPI_DEBUG_PRINT_RAW((ACPI_DB_NAMES,
+ Executed %u _REG methods for SpaceId %s\n,
+ info.reg_run_count,
+ acpi_ut_get_region_name(info.space_id)));
+
return_ACPI_STATUS(status);
}
@@ -664,10 +677,10 @@ acpi_ev_reg_run(acpi_handle obj_handle,
{
union acpi_operand_object *obj_desc;
struct acpi_namespace_node *node;
- acpi_adr_space_type space_id;
acpi_status status;
+ struct acpi_reg_walk_info *info;
- space_id = *ACPI_CAST_PTR(acpi_adr_space_type, context);
+ info = ACPI_CAST_PTR(struct acpi_reg_walk_info, context);
/* Convert and validate the device handle */
@@ -696,13 +709,14 @@ acpi_ev_reg_run(acpi_handle obj_handle,
/* Object is a Region */
- if (obj_desc-region.space_id != space_id) {
+ if (obj_desc-region.space_id != info-space_id) {
/* This region is for a different address space, just ignore it
*/
return (AE_OK);
}
+ info-reg_run_count++;
status = acpi_ev_execute_reg_method(obj_desc, ACPI_REG_CONNECT);
return (status);
}
diff --git a/drivers/acpi/acpica/nseval.c b/drivers/acpi/acpica/nseval.c
index 88822b7a..7eba578 100644
--- a/drivers/acpi/acpica/nseval.c
+++ b/drivers/acpi/acpica/nseval.c
@@ -465,7 +465,8 @@ acpi_ns_exec_module_code(union acpi_operand_object
*method_obj,
status = acpi_ns_evaluate(info);
- ACPI_DEBUG_PRINT((ACPI_DB_INIT, Executed module-level code at %p\n,
+ ACPI_DEBUG_PRINT((ACPI_DB_INIT_NAMES,
+ Executed module-level code at %p\n,
method_obj-method.aml_start));
/* Delete a possible implicit return value (in slack mode) */
diff --git a/drivers/acpi/acpica/nsutils.c b/drivers/acpi/acpica/nsutils.c
index 9a34c5f..d1261fe 100644
--- a/drivers/acpi/acpica/nsutils.c
+++ b/drivers/acpi/acpica/nsutils.c
@@ -596,6 +596,23 @@ void acpi_ns_terminate(void)
ACPI_FUNCTION_TRACE(ns_terminate);
+#ifdef ACPI_EXEC_APP
+ {
+ union acpi_operand_object *prev;
+ union acpi_operand_object *next;
+
+ /*
[PATCH 10/20] ACPICA: acpiexec/acpinames: Support very large number of ACPI tables.
From: Bob Moore robert.mo...@intel.com
ACPICA commit ca3bd4c5cdc39a9009280032adbbc20f34e94c47
Fix a couple of issues with 40 ACPI tables.
Return exit error for acpinames to enable use with BIOS builds.
The new exported function is used by acpinames. For Linux kernel, this
change is a no-op.
Link: https://github.com/acpica/acpica/commit/ca3bd4c5
Signed-off-by: Bob Moore robert.mo...@intel.com
Signed-off-by: Lv Zheng lv.zh...@intel.com
---
drivers/acpi/acpica/actables.h |5 +
drivers/acpi/acpica/tbxfload.c | 17 -
drivers/acpi/acpica/utfileio.c |2 +-
3 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/acpi/acpica/actables.h b/drivers/acpi/acpica/actables.h
index ab7f3a0..f7731f2 100644
--- a/drivers/acpi/acpica/actables.h
+++ b/drivers/acpi/acpica/actables.h
@@ -165,4 +165,9 @@ acpi_status acpi_tb_parse_root_table(acpi_physical_address
rsdp_address);
u8 acpi_is_valid_signature(char *signature);
+/*
+ * tbxfload
+ */
+acpi_status acpi_tb_load_namespace(void);
+
#endif /* __ACTABLES_H__ */
diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
index fb4d4e6..96b82a8 100644
--- a/drivers/acpi/acpica/tbxfload.c
+++ b/drivers/acpi/acpica/tbxfload.c
@@ -51,9 +51,6 @@
#define _COMPONENT ACPI_TABLES
ACPI_MODULE_NAME(tbxfload)
-/* Local prototypes */
-static acpi_status acpi_tb_load_namespace(void);
-
/***
*
* FUNCTION:acpi_load_tables
@@ -65,7 +62,6 @@ static acpi_status acpi_tb_load_namespace(void);
* DESCRIPTION: Load the ACPI tables from the RSDT/XSDT
*
**/
-
acpi_status __init acpi_load_tables(void)
{
acpi_status status;
@@ -75,6 +71,13 @@ acpi_status __init acpi_load_tables(void)
/* Load the namespace from the tables */
status = acpi_tb_load_namespace();
+
+ /* Don't let single failures abort the load */
+
+ if (status == AE_CTRL_TERMINATE) {
+ status = AE_OK;
+ }
+
if (ACPI_FAILURE(status)) {
ACPI_EXCEPTION((AE_INFO, status,
While loading namespace from ACPI tables));
@@ -97,7 +100,7 @@ ACPI_EXPORT_SYMBOL_INIT(acpi_load_tables)
* the RSDT/XSDT.
*
**/
-static acpi_status acpi_tb_load_namespace(void)
+acpi_status acpi_tb_load_namespace(void)
{
acpi_status status;
u32 i;
@@ -214,6 +217,10 @@ static acpi_status acpi_tb_load_namespace(void)
ACPI_ERROR((AE_INFO,
%u ACPI AML tables successfully acquired and
loaded, %u failed,
tables_loaded, tables_failed));
+
+ /* Indicate at least one failure */
+
+ status = AE_CTRL_TERMINATE;
}
unlock_and_exit:
diff --git a/drivers/acpi/acpica/utfileio.c b/drivers/acpi/acpica/utfileio.c
index 857af82..75a94f5 100644
--- a/drivers/acpi/acpica/utfileio.c
+++ b/drivers/acpi/acpica/utfileio.c
@@ -312,7 +312,7 @@ acpi_ut_read_table_from_file(char *filename, struct
acpi_table_header ** table)
/* Get the entire file */
fprintf(stderr,
- Reading ACPI table from file %10s - Length %.8u (0x%06X)\n,
+ Reading ACPI table from file %12s - Length %.8u (0x%06X)\n,
filename, file_size, file_size);
status = acpi_ut_read_table(file, table, table_length);
--
1.7.10
--
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 13/20] ACPICA: Debugger: Add option to display namespace summary/counts.
From: Bob Moore robert.mo...@intel.com
ACPICA commit bba222c15c2ce79076eb3a5e9d4d5f7120db8a00
If Objects command is invoked with no arguments, the counts
for each object type are displayed.
Linux kernel is not affected by this commit as currently debugger is
not enabled in the Linux kernel.
Link: https://github.com/acpica/acpica/commit/bba222c1
Signed-off-by: Bob Moore robert.mo...@intel.com
Signed-off-by: Lv Zheng lv.zh...@intel.com
---
drivers/acpi/acpica/acglobal.h |4 ++--
drivers/acpi/acpica/aclocal.h |4
include/acpi/actypes.h |2 ++
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
index 95ed861..c597192 100644
--- a/drivers/acpi/acpica/acglobal.h
+++ b/drivers/acpi/acpica/acglobal.h
@@ -346,8 +346,8 @@ ACPI_GLOBAL(char,
acpi_gbl_db_debug_filename[ACPI_DB_LINE_BUFFER_SIZE]);
/*
* Statistic globals
*/
-ACPI_GLOBAL(u16, acpi_gbl_obj_type_count[ACPI_TYPE_NS_NODE_MAX + 1]);
-ACPI_GLOBAL(u16, acpi_gbl_node_type_count[ACPI_TYPE_NS_NODE_MAX + 1]);
+ACPI_GLOBAL(u16, acpi_gbl_obj_type_count[ACPI_TOTAL_TYPES]);
+ACPI_GLOBAL(u16, acpi_gbl_node_type_count[ACPI_TOTAL_TYPES]);
ACPI_GLOBAL(u16, acpi_gbl_obj_type_count_misc);
ACPI_GLOBAL(u16, acpi_gbl_node_type_count_misc);
ACPI_GLOBAL(u32, acpi_gbl_num_nodes);
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index acbf68b..6f70826 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -1131,6 +1131,10 @@ struct acpi_integrity_info {
#define ACPI_DB_CONSOLE_OUTPUT 0x02
#define ACPI_DB_DUPLICATE_OUTPUT0x03
+struct acpi_object_info {
+ u32 types[ACPI_TOTAL_TYPES];
+};
+
/*
*
* Debug
diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h
index 531eca4..f914958 100644
--- a/include/acpi/actypes.h
+++ b/include/acpi/actypes.h
@@ -662,6 +662,7 @@ typedef u32 acpi_object_type;
#define ACPI_TYPE_DEBUG_OBJECT 0x10
#define ACPI_TYPE_EXTERNAL_MAX 0x10
+#define ACPI_NUM_TYPES (ACPI_TYPE_EXTERNAL_MAX + 1)
/*
* These are object types that do not map directly to the ACPI
@@ -683,6 +684,7 @@ typedef u32 acpi_object_type;
#define ACPI_TYPE_LOCAL_SCOPE 0x1B /* 1 Name, multiple object_list
Nodes */
#define ACPI_TYPE_NS_NODE_MAX 0x1B /* Last typecode used within a
NS Node */
+#define ACPI_TOTAL_TYPES(ACPI_TYPE_NS_NODE_MAX + 1)
/*
* These are special object types that never appear in
--
1.7.10
--
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 08/20] ACPICA: Headers: Fix some comments, no functional change.
From: Bob Moore robert.mo...@intel.com ACPICA commit 539f8c03fe64305725bd85343e42f3b6c42aad14 A couple typos and long lines. Link: https://github.com/acpica/acpica/commit/539f8c03 Signed-off-by: Bob Moore robert.mo...@intel.com Signed-off-by: Lv Zheng lv.zh...@intel.com --- include/acpi/platform/acenv.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/include/acpi/platform/acenv.h b/include/acpi/platform/acenv.h index 3cedd43..1332537 100644 --- a/include/acpi/platform/acenv.h +++ b/include/acpi/platform/acenv.h @@ -89,8 +89,8 @@ #endif /* - * acpi_bin/acpi_dump/acpi_help/acpi_names/acpi_src/acpi_xtract/Example configuration. - * All single threaded. + * acpi_bin/acpi_dump/acpi_help/acpi_names/acpi_src/acpi_xtract/Example + * configuration. All single threaded. */ #if (defined ACPI_BIN_APP) || \ (defined ACPI_DUMP_APP) || \ @@ -123,7 +123,7 @@ #define ACPI_USE_NATIVE_RSDP_POINTER #endif -/* acpi_dump configuration. Native mapping used if provied by OSPMs */ +/* acpi_dump configuration. Native mapping used if provided by the host */ #ifdef ACPI_DUMP_APP #define ACPI_USE_NATIVE_MEMORY_MAPPING @@ -323,8 +323,8 @@ * ACPI_USE_STANDARD_HEADERS - Define this if linking to a C library and * the standard header files may be used. * - * The ACPICA subsystem only uses low level C library functions that do not call - * operating system services and may therefore be inlined in the code. + * The ACPICA subsystem only uses low level C library functions that do not + * call operating system services and may therefore be inlined in the code. * * It may be necessary to tailor these include files to the target * generation environment. -- 1.7.10 -- 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 20/20] ACPICA: Update version to 20150818.
From: Bob Moore robert.mo...@intel.com ACPICA commit d93470de8febeecdc20633fde11cb0b200fa773b Version 20150818. Link: https://github.com/acpica/acpica/commit/d93470de Signed-off-by: Bob Moore robert.mo...@intel.com Signed-off-by: Lv Zheng lv.zh...@intel.com --- include/acpi/acpixf.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h index d3d7ea0..c33eeab 100644 --- a/include/acpi/acpixf.h +++ b/include/acpi/acpixf.h @@ -46,7 +46,7 @@ /* Current ACPICA subsystem version in MMDD format */ -#define ACPI_CA_VERSION 0x20150717 +#define ACPI_CA_VERSION 0x20150818 #include acpi/acconfig.h #include acpi/actypes.h -- 1.7.10 -- 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 17/20] ACPICA: Disassembler: Cleanup acpi_gbl_db_opt_disasm.
ACPICA commit 969989cf7f85e2a2a0cd048cd25fc706246a48a2 This patch cleans up the following global variable - acpi_gbl_db_opt_disasm: The setting is used to control the full disassembly feature for iasl. ACPI debugger (acpiexec) shall have nothing to do with it. Actually, acpiexec never links to ad_aml_disassemble(). This patch thus renames this global option to acpi_gbl_dm_opt_disasm and removes all acpiexec and debugger references on it. Lv Zheng. This patch doesn't affect Linux kernel. Link: https://github.com/acpica/acpica/commit/969989cf Signed-off-by: Lv Zheng lv.zh...@intel.com Signed-off-by: Bob Moore robert.mo...@intel.com --- drivers/acpi/acpica/acglobal.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h index 03c443b..0007eb7 100644 --- a/drivers/acpi/acpica/acglobal.h +++ b/drivers/acpi/acpica/acglobal.h @@ -313,7 +313,7 @@ ACPI_INIT_GLOBAL(u8, acpi_gbl_ignore_noop_operator, FALSE); ACPI_INIT_GLOBAL(u8, acpi_gbl_cstyle_disassembly, TRUE); ACPI_INIT_GLOBAL(u8, acpi_gbl_force_aml_disassembly, FALSE); -ACPI_GLOBAL(u8, acpi_gbl_db_opt_disasm); +ACPI_GLOBAL(u8, acpi_gbl_dm_opt_disasm); ACPI_GLOBAL(u8, acpi_gbl_dm_opt_listing); ACPI_GLOBAL(u8, acpi_gbl_db_opt_verbose); ACPI_GLOBAL(u8, acpi_gbl_num_external_methods); -- 1.7.10 -- 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 19/20] ACPICA: Debugger: Cleanup debugging outputs to dump name path without trailing underscores.
ACPICA commit 51a49c2fb4a73f302a6df2b8ddc1350dd261684d
It is better to use unified ASL path name to interact with the developers.
There are following acpi_ns_build_normalized_pathname() users invoking it for
debugging purposes (acpiexec test results are attached):
1. acpi_ut_display_init_pathname (acpi_ns_handle_to_pathname):
-
Initializing Region\_SB.H_EC.ECF2
-
2. acpi_ns_print_node_pathname (acpi_ns_handle_to_pathname):
-
- ex \_SB.H_EC._STA
Evaluating \_SB.H_EC._STA
-
3. acpi_ds_print_node_pathname (acpi_ns_handle_to_pathname):
-
- level 211b console
- execute \M1
...
Exception AE_AML_UNINITIALIZED_ARG during execution of method [\M1]
(Node 009CB6B8)
-
4. acpi_ex_dump_reference_obj (acpi_ns_handle_to_pathname):
-
- dump \_TZ.FAN4._PR0
...
[00] 00835E98 [Object Reference] Type [Named Object] 05 00828878 \_TZ.FN04
-
5. acpi_db_bus_walk (acpi_ns_handle_to_pathname):
-
- businfo
\_SB.PCI0Type 6
...
-
6. acpi_db_walk_and_match_name (acpi_ns_handle_to_pathname):
-
- find _PR0
\_TZ.FAN4._PR0 Package 002D8DF8 01 Elements 01
-
7. acpi_db_walk_for_specific_objects (acpi_ns_handle_to_pathname):
-
- methods
...
\_SB.PCI0._PRT Method 0026D918 01 Args 0 Len 0005
Aml 0026B199
...
-
8. acpi_db_decode_and_dispaly_object (acpi_get_name):
-
- gpes
Block 0 - Info 003AC7B0 device_node 003A0E08 [\_GPE] - FADT-defined GPE
block
...
-
9. acpi_db_display_gpes (acpi_get_name):
-
- dump \_GPE
Object (003A0E08) Pathname: \_GPE
-
10.ae_miscellaneous_tests (acpi_get_name):
No output available
This patch cleans up all of the above usages. ACPICA BZ 1178, Lv Zheng.
Linux kernel's ACPICA debugging messages may also be changed.
Link: https://github.com/acpica/acpica/commit/51a49c2f
Signed-off-by: Lv Zheng lv.zh...@intel.com
Signed-off-by: Bob Moore robert.mo...@intel.com
---
drivers/acpi/acpica/dsdebug.c |2 +-
drivers/acpi/acpica/exdump.c |2 +-
drivers/acpi/acpica/nsutils.c |2 +-
drivers/acpi/acpica/utmisc.c |2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/acpica/dsdebug.c b/drivers/acpi/acpica/dsdebug.c
index a651d30..309556e 100644
--- a/drivers/acpi/acpica/dsdebug.c
+++ b/drivers/acpi/acpica/dsdebug.c
@@ -89,7 +89,7 @@ acpi_ds_print_node_pathname(struct acpi_namespace_node *node,
buffer.length = ACPI_ALLOCATE_LOCAL_BUFFER;
- status = acpi_ns_handle_to_pathname(node, buffer, FALSE);
+ status = acpi_ns_handle_to_pathname(node, buffer, TRUE);
if (ACPI_SUCCESS(status)) {
if (message) {
ACPI_DEBUG_PRINT_RAW((ACPI_DB_DISPATCH, %s ,
diff --git a/drivers/acpi/acpica/exdump.c b/drivers/acpi/acpica/exdump.c
index b6495fb..d836f88 100644
--- a/drivers/acpi/acpica/exdump.c
+++ b/drivers/acpi/acpica/exdump.c
@@ -996,7 +996,7 @@ static void acpi_ex_dump_reference_obj(union
acpi_operand_object *obj_desc)
acpi_os_printf( %p , obj_desc-reference.node);
status = acpi_ns_handle_to_pathname(obj_desc-reference.node,
- ret_buf, FALSE);
+ ret_buf, TRUE);
if (ACPI_FAILURE(status)) {
acpi_os_printf( Could not convert name to pathname\n);
} else {
diff --git a/drivers/acpi/acpica/nsutils.c b/drivers/acpi/acpica/nsutils.c
index d1261fe..de325ae 100644
--- a/drivers/acpi/acpica/nsutils.c
+++ b/drivers/acpi/acpica/nsutils.c
@@ -83,7 +83,7 @@ acpi_ns_print_node_pathname(struct acpi_namespace_node *node,
buffer.length = ACPI_ALLOCATE_LOCAL_BUFFER;
- status = acpi_ns_handle_to_pathname(node, buffer, FALSE);
+ status = acpi_ns_handle_to_pathname(node, buffer, TRUE);
if (ACPI_SUCCESS(status)) {
if (message) {
acpi_os_printf(%s , message);
diff --git a/drivers/acpi/acpica/utmisc.c
[PATCH 18/20] ACPICA: Disassembler: Cleanup acpi_gbl_db_opt_verbose acpiexec usage.
ACPICA commit 42d7ad7bfb1cfb95183c1386c77509f2036f521d
When acpi_gbl_db_opt_verbose is used in acpi_dm_descending_op() (invoked by
acpi_dm_disassemble()), it is actually exported by the disassembler but used
by the debugger to distinguish the output of the disassembler for different
debugger commands. It is by default TRUE but is set to FALSE for control
method disassembly command - disassemble. So it's initialization should
be a part of the ACPI_DISASSEMBLER conditioned code. This patch uses
ACPI_INIT_GLOBAL to achieve a clean manner so that when ACPI_DISASSEMBLER
is not defined, ACPI_DEBUGGER conditioned code needn't link to this option.
Since it is a disassembler exported variable, it is renamed to
acpi_gbl_dm_opt_Verbose in this patch.
As VERBOSE_PRINT() macro has only one user, this patch also removes the
definition of this macro. Lv Zheng.
This patch doesn't affect Linux kernel.
Link: https://github.com/acpica/acpica/commit/42d7ad7b
Signed-off-by: Lv Zheng lv.zh...@intel.com
Signed-off-by: Bob Moore robert.mo...@intel.com
---
drivers/acpi/acpica/acdebug.h |3 ---
drivers/acpi/acpica/acglobal.h |2 +-
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/acpi/acpica/acdebug.h b/drivers/acpi/acpica/acdebug.h
index 447f6d3..eb2e926 100644
--- a/drivers/acpi/acpica/acdebug.h
+++ b/drivers/acpi/acpica/acdebug.h
@@ -67,9 +67,6 @@ struct acpi_db_execute_walk {
};
#define PARAM_LIST(pl) pl
-#define DBTEST_OUTPUT_LEVEL(lvl)if (acpi_gbl_db_opt_verbose)
-#define VERBOSE_PRINT(fp) DBTEST_OUTPUT_LEVEL(lvl) {\
- acpi_os_printf PARAM_LIST(fp);}
#define EX_NO_SINGLE_STEP 1
#define EX_SINGLE_STEP 2
diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
index 0007eb7..09f37b5 100644
--- a/drivers/acpi/acpica/acglobal.h
+++ b/drivers/acpi/acpica/acglobal.h
@@ -312,10 +312,10 @@ ACPI_INIT_GLOBAL(u8, acpi_gbl_no_resource_disassembly,
FALSE);
ACPI_INIT_GLOBAL(u8, acpi_gbl_ignore_noop_operator, FALSE);
ACPI_INIT_GLOBAL(u8, acpi_gbl_cstyle_disassembly, TRUE);
ACPI_INIT_GLOBAL(u8, acpi_gbl_force_aml_disassembly, FALSE);
+ACPI_INIT_GLOBAL(u8, acpi_gbl_dm_opt_verbose, TRUE);
ACPI_GLOBAL(u8, acpi_gbl_dm_opt_disasm);
ACPI_GLOBAL(u8, acpi_gbl_dm_opt_listing);
-ACPI_GLOBAL(u8, acpi_gbl_db_opt_verbose);
ACPI_GLOBAL(u8, acpi_gbl_num_external_methods);
ACPI_GLOBAL(u32, acpi_gbl_resolved_external_methods);
ACPI_GLOBAL(struct acpi_external_list *, acpi_gbl_external_list);
--
1.7.10
--
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 14/20] ACPICA: Make the max-number-of-loops runtime configurable.
From: Bob Moore robert.mo...@intel.com
ACPICA commit a9d9c2d0c2d077bb3175ec9c252cf0e5da3efd45
Was previously compile-time only.
Add support option for acpiexec.
Link: https://github.com/acpica/acpica/commit/a9d9c2d0
Signed-off-by: Bob Moore robert.mo...@intel.com
Signed-off-by: Lv Zheng lv.zh...@intel.com
---
drivers/acpi/acpica/acglobal.h |4
drivers/acpi/acpica/dscontrol.c |2 +-
drivers/acpi/acpica/utinit.c|1 +
include/acpi/acconfig.h |4
4 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
index c597192..03c443b 100644
--- a/drivers/acpi/acpica/acglobal.h
+++ b/drivers/acpi/acpica/acglobal.h
@@ -236,6 +236,10 @@ ACPI_INIT_GLOBAL(u32, acpi_gbl_nesting_level, 0);
ACPI_GLOBAL(struct acpi_thread_state *, acpi_gbl_current_walk_list);
+/* Maximum number of While() loop iterations before forced abort */
+
+ACPI_GLOBAL(u16, acpi_gbl_max_loop_iterations);
+
/* Control method single step flag */
ACPI_GLOBAL(u8, acpi_gbl_cm_single_step);
diff --git a/drivers/acpi/acpica/dscontrol.c b/drivers/acpi/acpica/dscontrol.c
index 39da9da..435fc16 100644
--- a/drivers/acpi/acpica/dscontrol.c
+++ b/drivers/acpi/acpica/dscontrol.c
@@ -212,7 +212,7 @@ acpi_ds_exec_end_control_op(struct acpi_walk_state *
walk_state,
*/
control_state-control.loop_count++;
if (control_state-control.loop_count
- ACPI_MAX_LOOP_ITERATIONS) {
+ acpi_gbl_max_loop_iterations) {
status = AE_AML_INFINITE_LOOP;
break;
}
diff --git a/drivers/acpi/acpica/utinit.c b/drivers/acpi/acpica/utinit.c
index 7f897c6..28ab3a1 100644
--- a/drivers/acpi/acpica/utinit.c
+++ b/drivers/acpi/acpica/utinit.c
@@ -207,6 +207,7 @@ acpi_status acpi_ut_init_globals(void)
acpi_gbl_debugger_configuration = DEBUGGER_THREADING;
acpi_gbl_osi_mutex = NULL;
acpi_gbl_reg_methods_executed = FALSE;
+ acpi_gbl_max_loop_iterations = 0x;
/* Hardware oriented */
diff --git a/include/acpi/acconfig.h b/include/acpi/acconfig.h
index 03aacfb..e11611c 100644
--- a/include/acpi/acconfig.h
+++ b/include/acpi/acconfig.h
@@ -136,10 +136,6 @@
#define ACPI_ROOT_TABLE_SIZE_INCREMENT 4
-/* Maximum number of While() loop iterations before forced abort */
-
-#define ACPI_MAX_LOOP_ITERATIONS0x
-
/* Maximum sleep allowed via Sleep() operator */
#define ACPI_MAX_SLEEP 2000 /* 2000 millisec == two seconds
*/
--
1.7.10
--
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 15/20] ACPICA: Header support to improve compatibility with MSVC.
From: Bob Moore robert.mo...@intel.com ACPICA commit 5b4087fba991d8383046b550bbe22f3d8d9b9c8f Needed to improve MSVC editor support for symbols. For Linux kernel, this change is a no-op. Link: https://github.com/acpica/acpica/commit/5b4087fb Signed-off-by: Bob Moore robert.mo...@intel.com Signed-off-by: Lv Zheng lv.zh...@intel.com --- include/acpi/platform/acenv.h |9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/include/acpi/platform/acenv.h b/include/acpi/platform/acenv.h index 1332537..ec00e2b 100644 --- a/include/acpi/platform/acenv.h +++ b/include/acpi/platform/acenv.h @@ -70,13 +70,14 @@ #ifdef ACPI_ASL_COMPILER #define ACPI_APPLICATION -#define ACPI_DISASSEMBLER #define ACPI_DEBUG_OUTPUT #define ACPI_CONSTANT_EVAL_ONLY #define ACPI_LARGE_NAMESPACE_NODE #define ACPI_DATA_TABLE_DISASSEMBLY #define ACPI_SINGLE_THREADED #define ACPI_32BIT_PHYSICAL_ADDRESS + +#define ACPI_DISASSEMBLER 1 #endif /* acpi_exec configuration. Multithreaded with full AML debugger */ @@ -151,12 +152,12 @@ #define ACPI_USE_LOCAL_CACHE #endif -/* Common debug support */ +/* Common debug/disassembler support */ #ifdef ACPI_FULL_DEBUG -#define ACPI_DEBUGGER #define ACPI_DEBUG_OUTPUT -#define ACPI_DISASSEMBLER +#define ACPI_DEBUGGER 1 +#define ACPI_DISASSEMBLER 1 #endif -- 1.7.10 -- 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/2] pinctrl: digicolor: convert null test to IS_ERR test
Hi Julia,
On Mon, Aug 24, 2015 at 11:12:27PM +0200, Julia Lawall wrote:
Since commit 323de9efdf3e (pinctrl: make pinctrl_register() return proper
error code), pinctrl_register returns an error code rather than NULL on
failure. Update a driver that was introduced more recently.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@@
expression e,e1,e2;
@@
e = pinctrl_register(...)
... when != e = e1
if (
- e == NULL
+ IS_ERR(e)
) {
...
return
- e2
+ PTR_ERR(e)
;
}
// /smpl
Signed-off-by: Julia Lawall julia.law...@lip6.fr
Acked-by: Baruch Siach bar...@tkos.co.il
Thanks,
baruch
drivers/pinctrl/pinctrl-digicolor.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-digicolor.c
b/drivers/pinctrl/pinctrl-digicolor.c
index 461fffc..11f8b83 100644
--- a/drivers/pinctrl/pinctrl-digicolor.c
+++ b/drivers/pinctrl/pinctrl-digicolor.c
@@ -337,9 +337,9 @@ static int dc_pinctrl_probe(struct platform_device *pdev)
pmap-dev = pdev-dev;
pmap-pctl = pinctrl_register(pctl_desc, pdev-dev, pmap);
- if (!pmap-pctl) {
+ if (IS_ERR(pmap-pctl)) {
dev_err(pdev-dev, pinctrl driver registration failed\n);
- return -EINVAL;
+ return PTR_ERR(pmap-pctl);
}
ret = dc_gpiochip_add(pmap, pdev-dev.of_node);
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
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] regulator: 88pm800: Add support for configuration of dual phase on BUCK1
On 24.08.2015 21:40, Vaibhav Hiremath wrote:
88PM860 device supports dual phase mode on BUCK1 output.
In normal usecase, BUCK1A and BUCK1B operates independently with 3A
capacity. And they both can work as a dual phase providing 6A capacity.
This patch updates the regulator driver to read the respective
DT property and enable dual-phase mode on BUCK1.
Note that if dual phase mode is enabled, then BUCK1B will not be
registered to the regulator framework and the current capacity of
BUCK1(A) would be set to 6A [3A of BUCK1A + 3A of BUCK1B].
Signed-off-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
---
drivers/regulator/88pm800.c | 40
include/linux/mfd/88pm80x.h | 3 +++
2 files changed, 43 insertions(+)
diff --git a/drivers/regulator/88pm800.c b/drivers/regulator/88pm800.c
index 365a154..7aca6d17 100644
--- a/drivers/regulator/88pm800.c
+++ b/drivers/regulator/88pm800.c
@@ -267,6 +267,37 @@ static struct pm800_regulator_info
pm860_regulator_info[] = {
PM800_LDO(ldo20, LDO20, LDO_ENA1_3, 3, 1, ldo_volt_table2),
};
+static int pm800_regulator_init(struct platform_device *pdev,
+ struct pm800_regulator_info *info)
+{
+ struct pm800_regulators *pm800_data = platform_get_drvdata(pdev);
+ struct pm80x_chip *chip = pm800_data-chip;
+ int ret = 0;
+
+ /* Currently only supported on 88pm860 device */
+ if (chip-type != CHIP_PM860)
+ return 0;
+
+ if (of_property_read_bool(pdev-dev.of_node,
+ marvell,88pm860-buck1-dualphase-en)) {
+ /* Update the constraint to [3A (BUCK1A) + 3A (BUCK1B)] */
+ info[PM800_ID_BUCK1].max_ua = 600;
+ /* Remove BUCK1B from the list, as we are in dual phase mode */
+ memset(info[PM800_ID_BUCK1B], 0, sizeof(*info));
+ /* Enable dual phase mode */
+ ret = regmap_update_bits(chip-subchip-regmap_power,
+ PM860_BUCK1_MISC,
+ BUCK1_DUAL_PHASE_SEL,
+ BUCK1_DUAL_PHASE_SEL);
+ if (ret) {
+ dev_err(chip-dev, failed to set dual-pase mode %d\n,
ret);
+ return ret;
+ }
+ }
+
+ return ret;
+}
+
static int pm800_regulator_probe(struct platform_device *pdev)
{
struct pm80x_chip *chip = dev_get_drvdata(pdev-dev.parent);
@@ -311,11 +342,20 @@ static int pm800_regulator_probe(struct platform_device
*pdev)
return -ENODEV;
}
+ ret = pm800_regulator_init(pdev, info);
+ if (ret) {
+ dev_err(pdev-dev, failed to init 88pm800 regulator
device\n);
+ return ret;
+ }
+
config.dev = chip-dev;
config.regmap = pm800_data-map;
for (i = 0; i PM800_ID_RG_MAX; i++) {
struct regulator_dev *regulator;
+ if (!info[i].desc.name)
+ continue;
How the driver was working without this on 88PM800? There is a gap in
pm800_regulator_info - three regulators are not set.
The patch itself looks good
Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Best regards,
Krzysztof
--
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: [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7
On 2015/8/25 12:03, Alex Deucher wrote: On Thu, Aug 13, 2015 at 6:13 PM, Alex Deucher alexdeuc...@gmail.com wrote: Any ideas? I'll see if I can find the time to bisect this. I attempted to bisect this, however the regression happened prior to my driver being merged upstream: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=099bfbfc7fbbe22356c02f0caf709ac32e1126ea So I can't easily bisect it further without backporting the driver to each commit before that. This may take a while... Just a heads up, this ended up being an alignment issue in the driver and was not a regression. Thanks for confirmation:) -- 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 0/1] i2c: acpi: revert setting a stable device name
On Mon Aug 17 11:00, Jarkko Nikula wrote: If I remember correctly ACPI ID should not ever change and instance id :xy after INTABCD:xy should also be visible and keep the order even if device is disabled or not plugged. But I'm not absolute sure about this. At least on a test platform that allow disable devices will show those devices off-line (/sys/bus/acpi/devices/INTABCD:xy/status == 0). I'm always surprised how hard it is to tell what *can't* happen in ACPI. How about a conditional call to LoadTable()? Seems like that would mess up the :xy. Moot point, I think you're on the right track in your RFC patch. --Dustin -- 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 1/3] tools: restore export.h
Commit 3f735377b (tools: Copy lib/rbtree.c to tools/lib/) has removed export.h, which was still in use by liblockdep. Restore it. Signed-off-by: Sasha Levin sasha.le...@oracle.com --- tools/include/linux/export.h | 10 ++ 1 file changed, 10 insertions(+) create mode 100644 tools/include/linux/export.h diff --git a/tools/include/linux/export.h b/tools/include/linux/export.h new file mode 100644 index 000..d07e586 --- /dev/null +++ b/tools/include/linux/export.h @@ -0,0 +1,10 @@ +#ifndef _TOOLS_LINUX_EXPORT_H_ +#define _TOOLS_LINUX_EXPORT_H_ + +#define EXPORT_SYMBOL(sym) +#define EXPORT_SYMBOL_GPL(sym) +#define EXPORT_SYMBOL_GPL_FUTURE(sym) +#define EXPORT_UNUSED_SYMBOL(sym) +#define EXPORT_UNUSED_SYMBOL_GPL(sym) + +#endif -- 2.1.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 1/7] phy: exynos-usb2: add vbus regulator support
Hello, On 2015-08-21 14:44, Kishon Vijay Abraham I wrote: On Friday 21 August 2015 06:08 PM, Marek Szyprowski wrote: Exynos USB2 PHY has separate power supply, which is usually provided by VBUS regulator. This patch adds support for it. VBUS regulator is optional, to keep compatibility with boards, which have VBUS provided from some always-on power source. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com --- .../devicetree/bindings/phy/samsung-phy.txt| 3 +++ drivers/phy/phy-samsung-usb2.c | 25 -- drivers/phy/phy-samsung-usb2.h | 2 ++ 3 files changed, 28 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index 60c6f2a633e0..0289d3b07853 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -44,6 +44,9 @@ Required properties: - the ref clock is used to get the rate of the clock provided to the PHY module +Optional properties: +- vbus-supply: power-supply phandle for vbus power source how about using phy-supply? I wanted to make it a bit more descriptive (vbus-supply is rather self explaining name) and keep it in line with Exynos usb3-drd phy, which already supports vbus-supply. If you think that this is a bad idea, a will use phy-supply then. Best regards -- Marek Szyprowski, PhD Samsung RD Institute Poland -- 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/20] ACPICA: Disassembler: Update for new listing mode.
From: Bob Moore robert.mo...@intel.com ACPICA commit 2ed09bb7619d25f5a5c065c33a8a775a6db3a856 ACPICA commit 2fefacf73825b0ec96bbfc4f70a256735b715d6c This mode emits AML code along with the ASL code. A new global was needed to ensure the listing mode is completely separate from the debugger verbose mode. Emits the correct AML offset for the AML code. The -l option now works for both the compiler and disassembler. Linux kernel is not affected by this commit. Link: https://github.com/acpica/acpica/commit/2fefacf7 Link: https://github.com/acpica/acpica/commit/2ed09bb7 Signed-off-by: Bob Moore robert.mo...@intel.com Signed-off-by: Lv Zheng lv.zh...@intel.com --- drivers/acpi/acpica/acglobal.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h index 79eb35d..1283b19 100644 --- a/drivers/acpi/acpica/acglobal.h +++ b/drivers/acpi/acpica/acglobal.h @@ -307,9 +307,9 @@ ACPI_INIT_GLOBAL(u8, acpi_gbl_no_resource_disassembly, FALSE); ACPI_INIT_GLOBAL(u8, acpi_gbl_ignore_noop_operator, FALSE); ACPI_INIT_GLOBAL(u8, acpi_gbl_cstyle_disassembly, TRUE); ACPI_INIT_GLOBAL(u8, acpi_gbl_force_aml_disassembly, FALSE); -ACPI_INIT_GLOBAL(union acpi_parse_object *, acpi_gbl_previous_op, NULL); ACPI_GLOBAL(u8, acpi_gbl_db_opt_disasm); +ACPI_GLOBAL(u8, acpi_gbl_dm_opt_listing); ACPI_GLOBAL(u8, acpi_gbl_db_opt_verbose); ACPI_GLOBAL(u8, acpi_gbl_num_external_methods); ACPI_GLOBAL(u32, acpi_gbl_resolved_external_methods); -- 1.7.10 -- 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 06/20] ACPICA: Tables: Fix global table list issues by removing fixed table indexes.
ACPICA commit c0b38b4c3982c2336ee92a2a14716107248bd941
The fixed table indexes leave holes in the global table list:
1. One hole can be seen when there is only 1 FACS provided by the BIOS.
2. Tow holes can be seen when it is a reduced hardware platform.
The holes do not break OSPMs but have broken ACPI debugger tables
command.
Also the fixed table indexes mechanism may make the descriptors of the
standard tables installed earlier than DSDT to be overwritten by the
descriptors of the fixed tables. For example, FACP disappears from the
global table list after DSDT is installed.
This patch fixes all above issues by removing the fixed table indexes
mechanism which is too complicated to be maintained in a regression safe
manner. After removal, the table loader will determine the indexes of the
fixed tables. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/c0b38b4c
Cc: sta...@vger.kernel.org
Signed-off-by: Lv Zheng lv.zh...@intel.com
Signed-off-by: Bob Moore robert.mo...@intel.com
---
drivers/acpi/acpica/acglobal.h |3 +++
drivers/acpi/acpica/aclocal.h |6 ++
drivers/acpi/acpica/actables.h |7 +++
drivers/acpi/acpica/tbfadt.c |6 +++---
drivers/acpi/acpica/tbinstal.c | 40 +---
drivers/acpi/acpica/tbutils.c | 37 ++---
drivers/acpi/acpica/tbxfload.c | 10 +-
7 files changed, 51 insertions(+), 58 deletions(-)
diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
index 1283b19..e78667e 100644
--- a/drivers/acpi/acpica/acglobal.h
+++ b/drivers/acpi/acpica/acglobal.h
@@ -58,6 +58,9 @@ ACPI_GLOBAL(struct acpi_table_list, acpi_gbl_root_table_list);
ACPI_GLOBAL(struct acpi_table_header *, acpi_gbl_DSDT);
ACPI_GLOBAL(struct acpi_table_header, acpi_gbl_original_dsdt_header);
+ACPI_INIT_GLOBAL(u32, acpi_gbl_dsdt_index, ACPI_INVALID_TABLE_INDEX);
+ACPI_INIT_GLOBAL(u32, acpi_gbl_facs_index, ACPI_INVALID_TABLE_INDEX);
+ACPI_INIT_GLOBAL(u32, acpi_gbl_xfacs_index, ACPI_INVALID_TABLE_INDEX);
#if (!ACPI_REDUCED_HARDWARE)
ACPI_GLOBAL(struct acpi_table_facs *, acpi_gbl_FACS);
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index a6b6887..92cbaee 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -213,11 +213,9 @@ struct acpi_table_list {
#define ACPI_ROOT_ORIGIN_ALLOCATED (1)
#define ACPI_ROOT_ALLOW_RESIZE (2)
-/* Predefined (fixed) table indexes */
+/* Predefined table indexes */
-#define ACPI_TABLE_INDEX_DSDT (0)
-#define ACPI_TABLE_INDEX_FACS (1)
-#define ACPI_TABLE_INDEX_X_FACS (2)
+#define ACPI_INVALID_TABLE_INDEX(0x)
struct acpi_find_context {
char *search_for;
diff --git a/drivers/acpi/acpica/actables.h b/drivers/acpi/acpica/actables.h
index 58497b7..ab7f3a0 100644
--- a/drivers/acpi/acpica/actables.h
+++ b/drivers/acpi/acpica/actables.h
@@ -154,13 +154,12 @@ void acpi_tb_check_dsdt_header(void);
struct acpi_table_header *acpi_tb_copy_dsdt(u32 table_index);
void
-acpi_tb_install_table_with_override(u32 table_index,
- struct acpi_table_desc *new_table_desc,
- u8 override);
+acpi_tb_install_table_with_override(struct acpi_table_desc *new_table_desc,
+ u8 override, u32 *table_index);
acpi_status
acpi_tb_install_fixed_table(acpi_physical_address address,
- char *signature, u32 table_index);
+ char *signature, u32 *table_index);
acpi_status acpi_tb_parse_root_table(acpi_physical_address rsdp_address);
diff --git a/drivers/acpi/acpica/tbfadt.c b/drivers/acpi/acpica/tbfadt.c
index 6253001..455a070 100644
--- a/drivers/acpi/acpica/tbfadt.c
+++ b/drivers/acpi/acpica/tbfadt.c
@@ -345,7 +345,7 @@ void acpi_tb_parse_fadt(u32 table_index)
/* Obtain the DSDT and FACS tables via their addresses within the FADT
*/
acpi_tb_install_fixed_table((acpi_physical_address) acpi_gbl_FADT.Xdsdt,
- ACPI_SIG_DSDT, ACPI_TABLE_INDEX_DSDT);
+ ACPI_SIG_DSDT, acpi_gbl_dsdt_index);
/* If Hardware Reduced flag is set, there is no FACS */
@@ -354,13 +354,13 @@ void acpi_tb_parse_fadt(u32 table_index)
acpi_tb_install_fixed_table((acpi_physical_address)
acpi_gbl_FADT.facs,
ACPI_SIG_FACS,
- ACPI_TABLE_INDEX_FACS);
+ acpi_gbl_facs_index);
}
if (acpi_gbl_FADT.Xfacs) {
acpi_tb_install_fixed_table((acpi_physical_address)
acpi_gbl_FADT.Xfacs,
[PATCH 05/20] ACPICA: Update info messages during ACPICA init.
From: Bob Moore robert.mo...@intel.com
ACPICA commit 4ccf8a1cc499ec8f00345f662a5887483980e1dd
Small cleanup of messages.
Link: https://github.com/acpica/acpica/commit/4ccf8a1c
Signed-off-by: Bob Moore robert.mo...@intel.com
Signed-off-by: Lv Zheng lv.zh...@intel.com
---
drivers/acpi/acpica/dsinit.c |9 +
drivers/acpi/acpica/tbxfload.c |4 ++--
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/acpica/dsinit.c b/drivers/acpi/acpica/dsinit.c
index 95779e8..bbf52f0 100644
--- a/drivers/acpi/acpica/dsinit.c
+++ b/drivers/acpi/acpica/dsinit.c
@@ -237,6 +237,15 @@ acpi_ds_initialize_objects(u32 table_index,
return_ACPI_STATUS(status);
}
+ /* DSDT is always the first AML table */
+
+ if (ACPI_COMPARE_NAME(table-signature, ACPI_SIG_DSDT)) {
+ ACPI_DEBUG_PRINT_RAW((ACPI_DB_INIT,
+ \nInitializing Namespace objects:\n));
+ }
+
+ /* Summary of objects initialized */
+
ACPI_DEBUG_PRINT_RAW((ACPI_DB_INIT,
Table [%4.4s] (id %4.4X) - %4u Objects with %3u
Devices,
%3u Regions, %3u Methods (%u/%u/%u
Serial/Non/Cvt)\n,
diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
index 7862cf0..6cbb2f7 100644
--- a/drivers/acpi/acpica/tbxfload.c
+++ b/drivers/acpi/acpica/tbxfload.c
@@ -208,11 +208,11 @@ static acpi_status acpi_tb_load_namespace(void)
if (!tables_failed) {
ACPI_INFO((AE_INFO,
- All (%u) ACPI AML tables successfully loaded,
+ %u ACPI AML tables successfully acquired and
loaded,
tables_loaded));
} else {
ACPI_ERROR((AE_INFO,
- %u ACPI AML tables loaded, %u failed,
+ %u ACPI AML tables successfully acquired and
loaded, %u failed,
tables_loaded, tables_failed));
}
--
1.7.10
--
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 09/20] ACPICA: acpinames: Add new options and wildcard support.
From: Bob Moore robert.mo...@intel.com ACPICA commit 0ecf5b5a41c3d2e09af48f0fdbc9ae784f631788 - Add wilcard support for input filenames. - Add -l option to load tables and exit, no display. This is useful for validation of the namespace during BIOS generation. - Add -x option for specifying debug level. Linux kernel is not affected by this commit. Link: https://github.com/acpica/acpica/commit/0ecf5b5a Signed-off-by: Bob Moore robert.mo...@intel.com Signed-off-by: Lv Zheng lv.zh...@intel.com --- drivers/acpi/acpica/acutils.h |2 +- drivers/acpi/acpica/utmisc.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/acpica/acutils.h b/drivers/acpi/acpica/acutils.h index 566ff4df..fb2aa50 100644 --- a/drivers/acpi/acpica/acutils.h +++ b/drivers/acpi/acpica/acutils.h @@ -517,7 +517,7 @@ const struct acpi_exception_info *acpi_ut_validate_exception(acpi_status u8 acpi_ut_is_pci_root_bridge(char *id); -#if (defined ACPI_ASL_COMPILER || defined ACPI_EXEC_APP) +#if (defined ACPI_ASL_COMPILER || defined ACPI_EXEC_APP || defined ACPI_NAMES_APP) u8 acpi_ut_is_aml_table(struct acpi_table_header *table); #endif diff --git a/drivers/acpi/acpica/utmisc.c b/drivers/acpi/acpica/utmisc.c index 98087ea..517a5ec 100644 --- a/drivers/acpi/acpica/utmisc.c +++ b/drivers/acpi/acpica/utmisc.c @@ -75,7 +75,7 @@ u8 acpi_ut_is_pci_root_bridge(char *id) return (FALSE); } -#if (defined ACPI_ASL_COMPILER || defined ACPI_EXEC_APP) +#if (defined ACPI_ASL_COMPILER || defined ACPI_EXEC_APP || defined ACPI_NAMES_APP) /*** * * FUNCTION:acpi_ut_is_aml_table -- 1.7.10 -- 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 07/20] ACPICA: Tables: Cleanup to reduce FACS globals.
ACPICA commit 3f42ba76e2a0453976d3108296d5f656fdf2bd6e
In this patch, FACS table mapping is also tuned a bit so that only the
selected FACS table will be mapped by the OSPM (mapped on demand) and the
FACS related global variables can be reduced. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/3f42ba76
Signed-off-by: Lv Zheng lv.zh...@intel.com
Signed-off-by: Bob Moore robert.mo...@intel.com
---
drivers/acpi/acpica/acglobal.h |2 --
drivers/acpi/acpica/hwxfsleep.c | 15 ++-
drivers/acpi/acpica/tbutils.c |9 +
3 files changed, 7 insertions(+), 19 deletions(-)
diff --git a/drivers/acpi/acpica/acglobal.h b/drivers/acpi/acpica/acglobal.h
index e78667e..95ed861 100644
--- a/drivers/acpi/acpica/acglobal.h
+++ b/drivers/acpi/acpica/acglobal.h
@@ -64,8 +64,6 @@ ACPI_INIT_GLOBAL(u32, acpi_gbl_xfacs_index,
ACPI_INVALID_TABLE_INDEX);
#if (!ACPI_REDUCED_HARDWARE)
ACPI_GLOBAL(struct acpi_table_facs *, acpi_gbl_FACS);
-ACPI_GLOBAL(struct acpi_table_facs *, acpi_gbl_facs32);
-ACPI_GLOBAL(struct acpi_table_facs *, acpi_gbl_facs64);
#endif /* !ACPI_REDUCED_HARDWARE */
diff --git a/drivers/acpi/acpica/hwxfsleep.c b/drivers/acpi/acpica/hwxfsleep.c
index 52dfd0d..d62a616 100644
--- a/drivers/acpi/acpica/hwxfsleep.c
+++ b/drivers/acpi/acpica/hwxfsleep.c
@@ -160,19 +160,8 @@ acpi_set_firmware_waking_vectors(acpi_physical_address
physical_address,
ACPI_FUNCTION_TRACE(acpi_set_firmware_waking_vectors);
- /* If Hardware Reduced flag is set, there is no FACS */
-
- if (acpi_gbl_reduced_hardware) {
- return_ACPI_STATUS (AE_OK);
- }
-
- if (acpi_gbl_facs32) {
- (void)acpi_hw_set_firmware_waking_vectors(acpi_gbl_facs32,
- physical_address,
- physical_address64);
- }
- if (acpi_gbl_facs64) {
- (void)acpi_hw_set_firmware_waking_vectors(acpi_gbl_facs64,
+ if (acpi_gbl_FACS) {
+ (void)acpi_hw_set_firmware_waking_vectors(acpi_gbl_FACS,
physical_address,
physical_address64);
}
diff --git a/drivers/acpi/acpica/tbutils.c b/drivers/acpi/acpica/tbutils.c
index b1d500e..4337990 100644
--- a/drivers/acpi/acpica/tbutils.c
+++ b/drivers/acpi/acpica/tbutils.c
@@ -68,6 +68,7 @@ acpi_tb_get_root_table_entry(u8 *table_entry, u32
table_entry_size);
acpi_status acpi_tb_initialize_facs(void)
{
+ struct acpi_table_facs *facs;
/* If Hardware Reduced flag is set, there is no FACS */
@@ -80,14 +81,14 @@ acpi_status acpi_tb_initialize_facs(void)
(void)acpi_get_table_by_index(acpi_gbl_xfacs_index,
ACPI_CAST_INDIRECT_PTR(struct
acpi_table_header,
-
acpi_gbl_facs32));
- acpi_gbl_FACS = acpi_gbl_facs32;
+facs));
+ acpi_gbl_FACS = facs;
} else if (acpi_gbl_FADT.facs) {
(void)acpi_get_table_by_index(acpi_gbl_facs_index,
ACPI_CAST_INDIRECT_PTR(struct
acpi_table_header,
-
acpi_gbl_facs64));
- acpi_gbl_FACS = acpi_gbl_facs64;
+facs));
+ acpi_gbl_FACS = facs;
}
/* If there is no FACS, just continue. There was already an error msg */
--
1.7.10
--
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] arch/sh: provide unified syscall trap compatible with all SH models
From: Rich Felker dal...@libc.org Historically SH-2 Linux (and originally uClinux) used a syscall calling convention incompatible with the established SH-3/4 Linux ABI. This choice was made because the trap range used by the existing ABI, 0x10-0x17, overlaps with the hardware exception/interrupt trap range reserved by SH-2, and in particular, with the SH-2A divide-by-zero and division-overflow exceptions. Despite the documented syscall convention using the low bits of the trap number to signal the number of arguments the kernel should expect, no version of the kernel has ever used this information, nor is it useful; all of the registers need to be saved anyway. Therefore, it is possible to pick a new trap number, 0x1f, that is both supported by all existing SH-3/4 kernels and unassigned as a hardware trap in the SH-2 range. This makes it possible to produce SH-2 application binaries that are forwards-compatible with running on SH-3/4 kernels and to treat SH as a unified platform with varying ISA support levels rather than multiple gratuitously-incompatible platforms. This patch adjusts the range checking SH-2 and SH-2A kernels make for the syscall trap to accept the range 0x1f-0x2f rather than just 0x20-0x2f. As a result, trap 0x1f now acts as a syscall for all SH models. Signed-off-by: Rich Felker dal...@libc.org --- The original proposal for using 0x1f as a unified syscall trap was reviewed by Jeff Dionne, Yoshinori Sato, and Shumpei Kawasaki for conflicts with existing trap number assignments, and none were found. I introduced this proposal as a way to add SH-2 support to musl libc in a forwards-compatible way, treating SH as a unified architecture, with the particular intent of supporting the Open Processor Foundation's J2 Core (SH-2 ISA plus some extensions) and providing a smooth upgrade path to the future J4 Core (SH-4 equivalent) and other full-fledged SH platforms with MMU. There is also some interest in having glibc's SH port support SH-2/J2, which is more practical with a common syscall ABI; whether this will actually happen remains uncertain. Rich diff -urp ../linux-4.2-rc6.orig/arch/sh/kernel/cpu/sh2/entry.S ./arch/sh/kernel/cpu/sh2/entry.S --- ../linux-4.2-rc6.orig/arch/sh/kernel/cpu/sh2/entry.S2015-08-09 19:54:30.0 + +++ ./arch/sh/kernel/cpu/sh2/entry.S2015-08-24 03:23:34.159387924 + @@ -144,9 +144,9 @@ ENTRY(exception_handler) mov #64,r8 cmp/hs r8,r9 bt interrupt_entry ! vec = 64 is interrupt - mov #32,r8 + mov #31,r8 cmp/hs r8,r9 - bt trap_entry ! 64 vec = 32 is trap + bt trap_entry ! 64 vec = 31 is trap mov.l 4f,r8 mov r9,r4 @@ -178,9 +178,9 @@ interrupt_entry: trap_entry: mov #0x30,r8 - cmp/ge r8,r9 ! vector 0x20-0x2f is systemcall + cmp/ge r8,r9 ! vector 0x1f-0x2f is systemcall bt 1f - add #-0x10,r9 ! convert SH2 to SH3/4 ABI + mov #0x1f,r9! convert to unified SH2/3/4 trap number 1: shll2 r9 ! TRA bra system_call ! jump common systemcall entry diff -urp ../linux-4.2-rc6.orig/arch/sh/kernel/cpu/sh2a/entry.S ./arch/sh/kernel/cpu/sh2a/entry.S --- ../linux-4.2-rc6.orig/arch/sh/kernel/cpu/sh2a/entry.S 2015-08-09 19:54:30.0 + +++ ./arch/sh/kernel/cpu/sh2a/entry.S 2015-08-24 03:23:58.849386418 + @@ -109,9 +109,9 @@ ENTRY(exception_handler) mov #64,r8 cmp/hs r8,r9 bt interrupt_entry ! vec = 64 is interrupt - mov #32,r8 + mov #31,r8 cmp/hs r8,r9 - bt trap_entry ! 64 vec = 32 is trap + bt trap_entry ! 64 vec = 31 is trap mov.l 4f,r8 mov r9,r4 @@ -143,9 +143,9 @@ interrupt_entry: trap_entry: mov #0x30,r8 - cmp/ge r8,r9 ! vector 0x20-0x2f is systemcall + cmp/ge r8,r9 ! vector 0x1f-0x2f is systemcall bt 1f - add #-0x10,r9 ! convert SH2 to SH3/4 ABI + mov #0x1f,r9! convert to unified SH2/3/4 trap number 1: shll2 r9 ! TRA bra system_call ! jump common systemcall entry diff -urp ../linux-4.2-rc6.orig/arch/sh/kernel/entry-common.S ./arch/sh/kernel/entry-common.S --- ../linux-4.2-rc6.orig/arch/sh/kernel/entry-common.S 2015-08-09 19:54:30.0 + +++ ./arch/sh/kernel/entry-common.S 2015-08-24 03:33:50.062683702 + @@ -268,19 +268,20 @@ debug_trap: * Syscall #: R3 * Arguments #0 to #3: R4--R7 * Arguments #4 to #6: R0, R1, R2 - * TRA: (number of arguments + ABI revision) x 4 + * TRA2: 0x1f, or one of a model-specific set of legacy values: * - * This code also handles delegating other traps to the BIOS/gdb stub - * according to: - * - * Trap number * (TRA2)
Re: [PATCH v6 0/6] mmc: imx: a few fixes and new feature
On Thu, Aug 13, 2015 at 04:58:56PM +0800, Dong Aisheng wrote: On Tue, Aug 11, 2015 at 07:38:25PM +0800, Haibo Chen wrote: Changes for v6: -remove duplicate code in esdhc_set_uhs_signaling(). -fix a typo for patch-2. -make commit log of patch-3 more specific. Haibo Chen (6): mmc: sdhci-esdhc-imx: add imx7d support and support HS400 mmc: sdhci-esdhc-imx: add tuning-step setting support mmc: sdhci-esdhc-imx: add imx7d support in bingding doc ARM: dts: imx7d-sdb: add eMMC5.0 support mmc: sdhci-esdhc-imx: set back the burst_length_enable bit to 1 mmc: sdhci-esdhc-imx: change default watermark level and burst length .../devicetree/bindings/mmc/fsl-imx-esdhc.txt | 6 ++ arch/arm/boot/dts/imx7d-sdb.dts| 13 +++ drivers/mmc/host/sdhci-esdhc-imx.c | 114 - include/linux/platform_data/mmc-esdhc-imx.h| 1 + 4 files changed, 130 insertions(+), 4 deletions(-) -- 1.9.1 The patch set looks good to me. Acked-by: Dong Aisheng aisheng.d...@freescale.com Regards Dong Aisheng Hi Ulf, Can you help pull these patches into your branch? Best regards Haibo -- -- 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 4/5] clk: 88pm800: Add clk provider driver for 88pm800 family of devices
On 25.08.2015 03:56, Vaibhav Hiremath wrote:
88PM800 family of devices supports buffered 32KHz clock output,
for example,
88PM800: CLK32k_1, CLK32k_2 and CLK32k_3
88PM860: CLK32K_1 and CLK32K_2
This patch adds new clk provider driver to support enable/disable
of the 32KHz clock output from 88PM800 family of devices.
Signed-off-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
---
drivers/clk/Kconfig | 8 ++
drivers/clk/Makefile | 1 +
drivers/clk/clk-88pm800.c | 341
++
3 files changed, 350 insertions(+)
create mode 100644 drivers/clk/clk-88pm800.c
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 42f7120..c34c14d 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -167,6 +167,14 @@ config COMMON_CLK_CDCE706
---help---
This driver supports TI CDCE706 programmable 3-PLL clock synthesizer.
+config COMMON_CLK_88PM800
+ tristate Clock driver for 88PM800 MFD
+ depends on MFD_88PM800
+ ---help---
+ This driver supports 88PM800 88PM860 crystal oscillator
+ clock. These multi-function devices have two (88PM860) or three
+ (88PM800) fixed-rate output, clocked at 32KHz each.
+
source drivers/clk/bcm/Kconfig
source drivers/clk/hisilicon/Kconfig
source drivers/clk/qcom/Kconfig
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index c4cf075..5248cd3 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -80,3 +80,4 @@ obj-$(CONFIG_X86) += x86/
obj-$(CONFIG_ARCH_ZX)+= zte/
obj-$(CONFIG_ARCH_ZYNQ) += zynq/
obj-$(CONFIG_H8300) += h8300/
+obj-$(CONFIG_COMMON_CLK_88PM800) += clk-88pm800.o
diff --git a/drivers/clk/clk-88pm800.c b/drivers/clk/clk-88pm800.c
new file mode 100644
index 000..4c045e1
--- /dev/null
+++ b/drivers/clk/clk-88pm800.c
@@ -0,0 +1,341 @@
+/*
+ * clk-88pm800.c - Clock driver for 88PM800 family of devices
+ *
+ * This driver is created based on clk-s2mps11.c
+ *
+ * Copyright (C) 2015 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/module.h
+#include linux/err.h
+#include linux/of.h
+#include linux/clkdev.h
+#include linux/regmap.h
+#include linux/clk-provider.h
+#include linux/platform_device.h
+#include linux/mfd/88pm80x.h
+
+/* Number of clocks output from 88pm800 family of device */
+enum {
+ PM800_CLK32K_1 = 0,
+ PM800_CLK32K_2,
+ PM800_CLK32K_3,
+ PM800_CLKS_NUM,
+};
+
+struct pm800_clk {
+ struct pm80x_chip *chip;
+ struct device_node *clk_np;
+ struct clk_hw hw;
+ struct clk *clk;
+ struct clk_lookup *lookup;
+ u32 mask;
+ u32 shift;
+ unsigned int reg;
+};
+
+static struct pm800_clk *to_pm800_clk(struct clk_hw *hw)
+{
+ return container_of(hw, struct pm800_clk, hw);
+}
+
+static int pm800_clk_prepare(struct clk_hw *hw)
+{
+ struct pm800_clk *pm800 = to_pm800_clk(hw);
+
+ /* We always want to use XO clock */
+ return regmap_update_bits(pm800-chip-regmap,
+ pm800-reg,
+ pm800-mask,
+ PM800_32K_OUTX_SEL_XO_32KHZ pm800-shift);
+}
+
+static void pm800_clk_unprepare(struct clk_hw *hw)
+{
+ struct pm800_clk *pm800 = to_pm800_clk(hw);
+
+ regmap_update_bits(pm800-chip-regmap, pm800-reg,
+ pm800-mask, ~pm800-mask);
+}
+
+static int pm800_clk_is_prepared(struct clk_hw *hw)
+{
+ int ret;
+ u32 val;
+ struct pm800_clk *pm800 = to_pm800_clk(hw);
+
+ ret = regmap_read(pm800-chip-regmap,
+ pm800-reg, val);
+ if (ret 0)
+ return -EINVAL;
+
+ return (val pm800-mask) pm800-shift;
+}
+
+static unsigned long pm800_clk_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ return 32768;
+}
+
+static const struct clk_ops pm800_clk_ops = {
+ .prepare= pm800_clk_prepare,
+ .unprepare = pm800_clk_unprepare,
+ .is_prepared= pm800_clk_is_prepared,
+ .recalc_rate= pm800_clk_recalc_rate,
+};
+
+static struct clk_init_data pm800_clks_init[PM800_CLKS_NUM] = {
+ [PM800_CLK32K_1] = {
+ .name = pm800_clk32k_1,
+ .ops= pm800_clk_ops,
+ .flags = CLK_IS_ROOT,
+
Re: [PATCH 1/1] of: to support binding numa node to root subnode(non-bus)
On 2015/8/24 21:25, Rob Herring wrote: +benh On Mon, Aug 24, 2015 at 7:30 AM, Zhen Lei thunder.leiz...@huawei.com wrote: If use of_platform_populate to scan dt-nodes and add devices, the subnode of root(such as /smmu), when being scanned and invoke You should have a bus as the sub-node of root rather than devices directly off of root. You still have a problem though... But actually the parent of bus is also platform_bus if we didn't have special initialization. For example: The function of_platform_device_create_pdata invoke of_device_alloc first, then invoke of_device_add. But in of_device_alloc, we can find that: dev-dev.parent = parent ? : platform_bus; of_device_add, the ofdev-dev.parent is always equal platform_bus. So that, function set_dev_node will not be called. And in device_add, dev_to_node(parent) always return NUMA_NO_NODE. Signed-off-by: Zhen Lei thunder.leiz...@huawei.com --- drivers/base/core.c | 2 +- drivers/of/device.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/base/core.c b/drivers/base/core.c index dafae6d..5df4f46b 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -1017,7 +1017,7 @@ int device_add(struct device *dev) dev-kobj.parent = kobj; /* use parent numa_node */ - if (parent) + if (parent (parent != platform_bus)) This is only fixing one specific case, but I think things are broken for any case where the NUMA associativity if not set at the top level bus node. I think this should be something like: if (parent (dev_to_node(dev) != NO_NUMA_NODE)) It seems a mistake, we should use equal sign. if (parent (dev_to_node(dev) == NUMA_NO_NODE)) Then the OF code can set the node however it wants. OK. I will send patch v2 base upon your advice. Thank you. set_dev_node(dev, dev_to_node(parent)); /* first, register with generic layer. */ diff --git a/drivers/of/device.c b/drivers/of/device.c index 8b91ea2..96ebece 100644 --- a/drivers/of/device.c +++ b/drivers/of/device.c @@ -63,7 +63,7 @@ int of_device_add(struct platform_device *ofdev) /* device_add will assume that this device is on the same node as * the parent. If there is no parent defined, set the node * explicitly */ - if (!ofdev-dev.parent) + if (!ofdev-dev.parent || (ofdev-dev.parent == platform_bus)) And then remove the if here. OK. I also think remove this statement will be better. Althouth set_dev_node maybe called two times, but it only spends very little time, and this almost happened at initialization phase. set_dev_node(ofdev-dev, of_node_to_nid(ofdev-dev.of_node)); return device_add(ofdev-dev); -- 2.5.0 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html . -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/20] ACPICA: Update parameter validation for data_table_region and load_table.
From: Bob Moore robert.mo...@intel.com
ACPICA commit 51ab555e60b4a3de3cc4a846e86d0de255be441a
Add additional validation for the table signature and
the OEM strings. Eliminates buffer read overrun in data_table_region.
ACPICA BZ 1184.
Link: https://bugs.acpica.org/show_bug.cgi?id=1184
Link: https://github.com/acpica/acpica/commit/51ab555e
Signed-off-by: Bob Moore robert.mo...@intel.com
Signed-off-by: Lv Zheng lv.zh...@intel.com
---
drivers/acpi/acpica/actables.h |2 ++
drivers/acpi/acpica/dsopcode.c | 31 ---
drivers/acpi/acpica/exconfig.c |8
drivers/acpi/acpica/tbfind.c | 15 ++-
drivers/acpi/acpica/tbutils.c | 33 +
5 files changed, 69 insertions(+), 20 deletions(-)
diff --git a/drivers/acpi/acpica/actables.h b/drivers/acpi/acpica/actables.h
index 7e0b6f1..58497b7 100644
--- a/drivers/acpi/acpica/actables.h
+++ b/drivers/acpi/acpica/actables.h
@@ -164,4 +164,6 @@ acpi_tb_install_fixed_table(acpi_physical_address address,
acpi_status acpi_tb_parse_root_table(acpi_physical_address rsdp_address);
+u8 acpi_is_valid_signature(char *signature);
+
#endif /* __ACTABLES_H__ */
diff --git a/drivers/acpi/acpica/dsopcode.c b/drivers/acpi/acpica/dsopcode.c
index ea0cc4e..81d7b986 100644
--- a/drivers/acpi/acpica/dsopcode.c
+++ b/drivers/acpi/acpica/dsopcode.c
@@ -480,8 +480,8 @@ acpi_ds_eval_table_region_operands(struct acpi_walk_state
*walk_state,
union acpi_operand_object **operand;
struct acpi_namespace_node *node;
union acpi_parse_object *next_op;
- u32 table_index;
struct acpi_table_header *table;
+ u32 table_index;
ACPI_FUNCTION_TRACE_PTR(ds_eval_table_region_operands, op);
@@ -504,6 +504,8 @@ acpi_ds_eval_table_region_operands(struct acpi_walk_state
*walk_state,
return_ACPI_STATUS(status);
}
+ operand = walk_state-operands[0];
+
/*
* Resolve the Signature string, oem_id string,
* and oem_table_id string operands
@@ -511,32 +513,34 @@ acpi_ds_eval_table_region_operands(struct acpi_walk_state
*walk_state,
status = acpi_ex_resolve_operands(op-common.aml_opcode,
ACPI_WALK_OPERANDS, walk_state);
if (ACPI_FAILURE(status)) {
- return_ACPI_STATUS(status);
+ goto cleanup;
}
- operand = walk_state-operands[0];
-
/* Find the ACPI table */
status = acpi_tb_find_table(operand[0]-string.pointer,
operand[1]-string.pointer,
operand[2]-string.pointer, table_index);
if (ACPI_FAILURE(status)) {
- return_ACPI_STATUS(status);
+ if (status == AE_NOT_FOUND) {
+ ACPI_ERROR((AE_INFO,
+ ACPI Table [%4.4s] OEM:(%s, %s) not found
in RSDT/XSDT,
+ operand[0]-string.pointer,
+ operand[1]-string.pointer,
+ operand[2]-string.pointer));
+ }
+ goto cleanup;
}
- acpi_ut_remove_reference(operand[0]);
- acpi_ut_remove_reference(operand[1]);
- acpi_ut_remove_reference(operand[2]);
-
status = acpi_get_table_by_index(table_index, table);
if (ACPI_FAILURE(status)) {
- return_ACPI_STATUS(status);
+ goto cleanup;
}
obj_desc = acpi_ns_get_attached_object(node);
if (!obj_desc) {
- return_ACPI_STATUS(AE_NOT_EXIST);
+ status = AE_NOT_EXIST;
+ goto cleanup;
}
obj_desc-region.address = ACPI_PTR_TO_PHYSADDR(table);
@@ -551,6 +555,11 @@ acpi_ds_eval_table_region_operands(struct acpi_walk_state
*walk_state,
obj_desc-region.flags |= AOPOBJ_DATA_VALID;
+cleanup:
+ acpi_ut_remove_reference(operand[0]);
+ acpi_ut_remove_reference(operand[1]);
+ acpi_ut_remove_reference(operand[2]);
+
return_ACPI_STATUS(status);
}
diff --git a/drivers/acpi/acpica/exconfig.c b/drivers/acpi/acpica/exconfig.c
index 24a4c5c..b540913 100644
--- a/drivers/acpi/acpica/exconfig.c
+++ b/drivers/acpi/acpica/exconfig.c
@@ -162,14 +162,6 @@ acpi_ex_load_table_op(struct acpi_walk_state *walk_state,
ACPI_FUNCTION_TRACE(ex_load_table_op);
- /* Validate lengths for the Signature, oem_id, and oem_table_id strings
*/
-
- if ((operand[0]-string.length ACPI_NAME_SIZE) ||
- (operand[1]-string.length ACPI_OEM_ID_SIZE) ||
- (operand[2]-string.length ACPI_OEM_TABLE_ID_SIZE)) {
- return_ACPI_STATUS(AE_AML_STRING_LIMIT);
- }
-
/* Find the ACPI table in the RSDT/XSDT */
status = acpi_tb_find_table(operand[0]-string.pointer,
diff --git a/drivers/acpi/acpica/tbfind.c
[PATCH 01/20] ACPICA: Correctly cleanup after a ACPI table load failure.
From: Bob Moore robert.mo...@intel.com
ACPICA commit ed7769e832de6c7ba90615480d916c85fd100422
If a table load fails, delete all namespace objects created by the
table, otherwise these objects will be uninitialized, causing
problems later. This appears to be a very rare problem.
Also handle the unitialized node problem to prevent possible
faults. ACPICA BZ 1185.
Link: https://github.com/acpica/acpica/commit/ed7769e8
Signed-off-by: Bob Moore robert.mo...@intel.com
Signed-off-by: Lv Zheng lv.zh...@intel.com
---
drivers/acpi/acpica/exresnte.c |2 +-
drivers/acpi/acpica/exresolv.c | 16 +++-
drivers/acpi/acpica/nseval.c |1 +
drivers/acpi/acpica/nsload.c | 16 +++-
drivers/acpi/acpica/tbxfload.c | 29 ++---
include/acpi/acexcep.h |7 +--
6 files changed, 59 insertions(+), 12 deletions(-)
diff --git a/drivers/acpi/acpica/exresnte.c b/drivers/acpi/acpica/exresnte.c
index c7e3b92..1b372ef 100644
--- a/drivers/acpi/acpica/exresnte.c
+++ b/drivers/acpi/acpica/exresnte.c
@@ -126,7 +126,7 @@ acpi_ex_resolve_node_to_value(struct acpi_namespace_node
**object_ptr,
if (!source_desc) {
ACPI_ERROR((AE_INFO, No object attached to node [%4.4s] %p,
node-name.ascii, node));
- return_ACPI_STATUS(AE_AML_NO_OPERAND);
+ return_ACPI_STATUS(AE_AML_UNINITIALIZED_NODE);
}
/*
diff --git a/drivers/acpi/acpica/exresolv.c b/drivers/acpi/acpica/exresolv.c
index b6b7f3a..7b10912 100644
--- a/drivers/acpi/acpica/exresolv.c
+++ b/drivers/acpi/acpica/exresolv.c
@@ -337,8 +337,9 @@ acpi_ex_resolve_multiple(struct acpi_walk_state *walk_state,
acpi_object_type * return_type,
union acpi_operand_object **return_desc)
{
- union acpi_operand_object *obj_desc = (void *)operand;
- struct acpi_namespace_node *node;
+ union acpi_operand_object *obj_desc = ACPI_CAST_PTR(void, operand);
+ struct acpi_namespace_node *node =
+ ACPI_CAST_PTR(struct acpi_namespace_node, operand);
acpi_object_type type;
acpi_status status;
@@ -355,9 +356,7 @@ acpi_ex_resolve_multiple(struct acpi_walk_state *walk_state,
case ACPI_DESC_TYPE_NAMED:
type = ((struct acpi_namespace_node *)obj_desc)-type;
- obj_desc =
- acpi_ns_get_attached_object((struct acpi_namespace_node *)
- obj_desc);
+ obj_desc = acpi_ns_get_attached_object(node);
/* If we had an Alias node, use the attached object for type
info */
@@ -368,6 +367,13 @@ acpi_ex_resolve_multiple(struct acpi_walk_state
*walk_state,
acpi_namespace_node *)
obj_desc);
}
+
+ if (!obj_desc) {
+ ACPI_ERROR((AE_INFO,
+ [%4.4s] Node is unresolved or
uninitialized,
+ acpi_ut_get_node_name(node)));
+ return_ACPI_STATUS(AE_AML_UNINITIALIZED_NODE);
+ }
break;
default:
diff --git a/drivers/acpi/acpica/nseval.c b/drivers/acpi/acpica/nseval.c
index 80670cb..88822b7a 100644
--- a/drivers/acpi/acpica/nseval.c
+++ b/drivers/acpi/acpica/nseval.c
@@ -274,6 +274,7 @@ acpi_status acpi_ns_evaluate(struct acpi_evaluate_info
*info)
acpi_ex_exit_interpreter();
if (ACPI_FAILURE(status)) {
+ info-return_object = NULL;
goto cleanup;
}
diff --git a/drivers/acpi/acpica/nsload.c b/drivers/acpi/acpica/nsload.c
index bd6cd4a..14ab836 100644
--- a/drivers/acpi/acpica/nsload.c
+++ b/drivers/acpi/acpica/nsload.c
@@ -111,7 +111,21 @@ acpi_ns_load_table(u32 table_index, struct
acpi_namespace_node *node)
if (ACPI_SUCCESS(status)) {
acpi_tb_set_table_loaded_flag(table_index, TRUE);
} else {
- (void)acpi_tb_release_owner_id(table_index);
+ /*
+* On error, delete any namespace objects created by this table.
+* We cannot initialize these objects, so delete them. There are
+* a couple of expecially bad cases:
+* AE_ALREADY_EXISTS - namespace collision.
+* AE_NOT_FOUND - the target of a Scope operator does not
+* exist. This target of Scope must already exist in the
+* namespace, as per the ACPI specification.
+*/
+ (void)acpi_ut_release_mutex(ACPI_MTX_NAMESPACE);
+ acpi_ns_delete_namespace_by_owner(acpi_gbl_root_table_list.
+ tables[table_index].owner_id);
+
[PATCH 00/20] ACPICA: 20150818 Release
The 20150818 ACPICA kernel-resident subsystem updates are linuxized based on the linux-pm/linux-next branch. The patchset has passed the following build/boot tests. Build tests are performed as follows: 1. i386 + default + COFNIG_ACPI=y 2. i386 + allyes + CONFIG_ACPI=y 3. i386 + default + COFNIG_ACPI=n 4. i386 + allyes + CONFIG_ACPI=n 5. x86_64 + default + COFNIG_ACPI=y 6. x86_64 + allyes + CONFIG_ACPI=y 7. x86_64 + default + COFNIG_ACPI=n 8. x86_64 + allyes + CONFIG_ACPI=n Boot tests are performed as follows: 1. i386 + default + COFNIG_ACPI=y 2. x86_64 + default + COFNIG_ACPI=y Where: 1. i386: machine named as Dell Inspiron Mini 1010 2. x86_64: machine named as HP Compaq 8200 Elite SFF PC 3. default: kernel configuration with following items enabled: All hardware drivers related to the machines of i386/x86_64 All drivers/acpi configurations All drivers/platform drivers All other drivers that link the APIs provided by ACPICA subsystem The divergences checking result: Before applying (20150717 Release): 518 lines After applying (20150818 Release): 517 lines Bob Moore (14): ACPICA: Correctly cleanup after a ACPI table load failure. ACPICA: Disassembler: Remove duplicate code in _PLD processing. ACPICA: Update parameter validation for data_table_region and load_table. ACPICA: Disassembler: Update for new listing mode. ACPICA: Update info messages during ACPICA init. ACPICA: Headers: Fix some comments, no functional change. ACPICA: acpinames: Add new options and wildcard support. ACPICA: acpiexec/acpinames: Support very large number of ACPI tables. ACPICA: Table handling: Cleanup and update debug output for tools. ACPICA: Add additional debug info/statements. ACPICA: Debugger: Add option to display namespace summary/counts. ACPICA: Make the max-number-of-loops runtime configurable. ACPICA: Header support to improve compatibility with MSVC. ACPICA: Update version to 20150818. Lv Zheng (6): ACPICA: Tables: Fix global table list issues by removing fixed table indexes. ACPICA: Tables: Cleanup to reduce FACS globals. ACPICA: Debugger: Split debugger initialization/termination APIs. ACPICA: Disassembler: Cleanup acpi_gbl_db_opt_disasm. ACPICA: Disassembler: Cleanup acpi_gbl_db_opt_verbose acpiexec usage. ACPICA: Debugger: Cleanup debugging outputs to dump name path without trailing underscores. drivers/acpi/acpica/acdebug.h |7 --- drivers/acpi/acpica/acglobal.h | 19 +--- drivers/acpi/acpica/aclocal.h | 17 +-- drivers/acpi/acpica/actables.h | 14 -- drivers/acpi/acpica/acutils.h |2 +- drivers/acpi/acpica/dscontrol.c |2 +- drivers/acpi/acpica/dsdebug.c |2 +- drivers/acpi/acpica/dsinit.c| 20 ++--- drivers/acpi/acpica/dsopcode.c | 31 - drivers/acpi/acpica/evregion.c | 22 +++-- drivers/acpi/acpica/exconfig.c |8 drivers/acpi/acpica/exdump.c|2 +- drivers/acpi/acpica/exresnte.c |2 +- drivers/acpi/acpica/exresolv.c | 16 --- drivers/acpi/acpica/hwxfsleep.c | 15 +-- drivers/acpi/acpica/nseval.c|4 +- drivers/acpi/acpica/nsload.c| 16 ++- drivers/acpi/acpica/nsutils.c | 19 +++- drivers/acpi/acpica/psloop.c| 14 +- drivers/acpi/acpica/tbfadt.c|6 +-- drivers/acpi/acpica/tbfind.c| 15 ++- drivers/acpi/acpica/tbinstal.c | 40 + drivers/acpi/acpica/tbutils.c | 73 -- drivers/acpi/acpica/tbxfload.c | 93 +-- drivers/acpi/acpica/utfileio.c |2 +- drivers/acpi/acpica/utinit.c|1 + drivers/acpi/acpica/utmisc.c|4 +- drivers/acpi/acpica/utxface.c | 12 ++--- drivers/acpi/acpica/utxfinit.c | 11 - include/acpi/acbuffer.h |1 + include/acpi/acconfig.h |4 -- include/acpi/acexcep.h |7 ++- include/acpi/acpixf.h |5 ++- include/acpi/actypes.h |2 + include/acpi/platform/acenv.h | 19 35 files changed, 330 insertions(+), 197 deletions(-) -- 1.7.10 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] cgroup: pids: fix invalid get/put usage
Fix incorrect usage of css_get and css_put to put a different css in
pids_{cancel_,}attach() than the one grabbed in pids_can_attach(). This
could lead to quite serious memory leakage (and unsafe operations on the
putted css).
Signed-off-by: Aleksa Sarai cyp...@cyphar.com
---
kernel/cgroup_pids.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/kernel/cgroup_pids.c b/kernel/cgroup_pids.c
index d75488824ae2..056564f8dd85 100644
--- a/kernel/cgroup_pids.c
+++ b/kernel/cgroup_pids.c
@@ -173,11 +173,11 @@ static int pids_can_attach(struct cgroup_subsys_state
*css,
struct pids_cgroup *old_pids;
/*
-* Grab a ref to each task's css. We don't drop the ref until
-* we either fail and hit -cancel_attach() or succeed and hit
-* -attach().
+* We don't need to grab a ref between here and cancel_attach()
+* because cgroup_migrate_prepare_src() protects the task's css
+* from being freed before the migration completed or failed.
*/
- old_css = task_get_css(task, pids_cgrp_id);
+ old_css = task_css(task, pids_cgrp_id);
old_pids = css_pids(old_css);
pids_charge(pids, 1);
@@ -202,19 +202,9 @@ static void pids_cancel_attach(struct cgroup_subsys_state
*css,
pids_charge(old_pids, 1);
pids_uncharge(pids, 1);
- css_put(old_css);
}
}
-static void pids_attach(struct cgroup_subsys_state *css,
- struct cgroup_taskset *tset)
-{
- struct task_struct *task;
-
- cgroup_taskset_for_each(task, tset)
- css_put(task_css(task, pids_cgrp_id));
-}
-
static int pids_can_fork(struct task_struct *task, void **priv_p)
{
struct cgroup_subsys_state *css;
@@ -354,7 +344,6 @@ static struct cftype pids_files[] = {
struct cgroup_subsys pids_cgrp_subsys = {
.css_alloc = pids_css_alloc,
.css_free = pids_css_free,
- .attach = pids_attach,
.can_attach = pids_can_attach,
.cancel_attach = pids_cancel_attach,
.can_fork = pids_can_fork,
--
2.5.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 v3] dmaengine: hdmac: Add memset capabilities
On Mon, Aug 24, 2015 at 07:54:25PM +0530, Vinod Koul wrote: On Mon, Aug 24, 2015 at 11:21:15AM +0200, Maxime Ripard wrote: Just like for the XDMAC, the SoCs that embed the HDMAC don't have any kind of GPU, and need to accelerate a few framebuffer-related operations through their DMA controller. However, unlike the XDMAC, the HDMAC doesn't have the memset capability built-in. That can be easily emulated though, by doing a transfer with a fixed address on the variable that holds the value we want to set. Applied, thanks Thanks for merging it so quickly, and sorry for the silent conflict. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[PATCH 2/2] regulator:lp872x: handle error case
If memory allocation gets failed on parsing the DT, then it returns error
'-ENOMEM' explicitly. Then, the driver exists from the _probe().
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Milo Kim milo@ti.com
---
drivers/regulator/lp872x.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/lp872x.c b/drivers/regulator/lp872x.c
index 9142c1a..8702e73 100644
--- a/drivers/regulator/lp872x.c
+++ b/drivers/regulator/lp872x.c
@@ -849,7 +849,7 @@ static struct lp872x_platform_data
pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
- goto out;
+ return ERR_PTR(-ENOMEM);
of_property_read_u8(np, ti,general-config, pdata-general_config);
if (of_find_property(np, ti,update-config, NULL))
@@ -857,7 +857,7 @@ static struct lp872x_platform_data
pdata-dvs = devm_kzalloc(dev, sizeof(struct lp872x_dvs), GFP_KERNEL);
if (!pdata-dvs)
- goto out;
+ return ERR_PTR(-ENOMEM);
pdata-dvs-gpio = of_get_named_gpio(np, ti,dvs-gpio, 0);
of_property_read_u8(np, ti,dvs-vsel, (u8 *)pdata-dvs-vsel);
@@ -910,11 +910,14 @@ static int lp872x_probe(struct i2c_client *cl, const
struct i2c_device_id *id)
[LP8725] = LP8725_NUM_REGULATORS,
};
- if (cl-dev.of_node)
+ if (cl-dev.of_node) {
pdata = lp872x_populate_pdata_from_dt(cl-dev,
(enum lp872x_id)id-driver_data);
- else
+ if (IS_ERR(pdata))
+ return PTR_ERR(pdata);
+ } else {
pdata = dev_get_platdata(cl-dev);
+ }
lp = devm_kzalloc(cl-dev, sizeof(struct lp872x), GFP_KERNEL);
if (!lp)
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] regulator:lp872x: use the private data instead of updating I2C device platform data
Currently, lp872x driver parses the DT and copies values into the
'cl-dev.platform_data' if 'of_node' exists.
This may have architectural issue. Platform data is configurable through
the DT or I2C board info inside the platform area.
However, lp872x driver changes this configuration when it is loaded.
The lp872x driver should get data from the platform side and use the private
data, 'lp872x-pdata' instead of changing the original platform data.
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Milo Kim milo@ti.com
---
drivers/regulator/lp872x.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/lp872x.c b/drivers/regulator/lp872x.c
index 3de328a..9142c1a 100644
--- a/drivers/regulator/lp872x.c
+++ b/drivers/regulator/lp872x.c
@@ -903,6 +903,7 @@ static struct lp872x_platform_data
static int lp872x_probe(struct i2c_client *cl, const struct i2c_device_id *id)
{
struct lp872x *lp;
+ struct lp872x_platform_data *pdata;
int ret;
const int lp872x_num_regulators[] = {
[LP8720] = LP8720_NUM_REGULATORS,
@@ -910,8 +911,10 @@ static int lp872x_probe(struct i2c_client *cl, const
struct i2c_device_id *id)
};
if (cl-dev.of_node)
- cl-dev.platform_data = lp872x_populate_pdata_from_dt(cl-dev,
+ pdata = lp872x_populate_pdata_from_dt(cl-dev,
(enum lp872x_id)id-driver_data);
+ else
+ pdata = dev_get_platdata(cl-dev);
lp = devm_kzalloc(cl-dev, sizeof(struct lp872x), GFP_KERNEL);
if (!lp)
@@ -927,7 +930,7 @@ static int lp872x_probe(struct i2c_client *cl, const struct
i2c_device_id *id)
}
lp-dev = cl-dev;
- lp-pdata = dev_get_platdata(cl-dev);
+ lp-pdata = pdata;
lp-chipid = id-driver_data;
i2c_set_clientdata(cl, lp);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
