[PATCH v3 2/3] powerpc/fadump: Use the correct VMCOREINFO_NOTE_SIZE for phdr

vmcoreinfo_max_size stands for the vmcoreinfo_data, the correct one we should use is vmcoreinfo_note whose total size is VMCOREINFO_NOTE_SIZE. Like explained in commit 77019967f06b ("kdump: fix exported size of vmcoreinfo note"), it does not affect the actual function, we better fix it, also

[PATCH v3 2/3] powerpc/fadump: Use the correct VMCOREINFO_NOTE_SIZE for phdr

vmcoreinfo_max_size stands for the vmcoreinfo_data, the correct one we should use is vmcoreinfo_note whose total size is VMCOREINFO_NOTE_SIZE. Like explained in commit 77019967f06b ("kdump: fix exported size of vmcoreinfo note"), it does not affect the actual function, we better fix it, also

[PATCH v3 3/3] kdump: Relocate vmcoreinfo to the crash memory range

Currently vmcoreinfo data is updated at boot time subsys_initcall(), it has the risk of being modified by some wrong code during system is running. As a result, vmcore dumped may contain the wrong vmcoreinfo. Later on, when using "crash", "makedumpfile", etc utility to parse this vmcore, we

[PATCH v3 3/3] kdump: Relocate vmcoreinfo to the crash memory range

Currently vmcoreinfo data is updated at boot time subsys_initcall(), it has the risk of being modified by some wrong code during system is running. As a result, vmcore dumped may contain the wrong vmcoreinfo. Later on, when using "crash", "makedumpfile", etc utility to parse this vmcore, we

[PATCH v3 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

As Eric said, "what we need to do is move the variable vmcoreinfo_note out of the kernel's .bss section. And modify the code to regenerate and keep this information in something like the control page. Definitely something like this needs a page all to itself, and ideally far away from any other

[PATCH v3 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

As Eric said, "what we need to do is move the variable vmcoreinfo_note out of the kernel's .bss section. And modify the code to regenerate and keep this information in something like the control page. Definitely something like this needs a page all to itself, and ideally far away from any other

linux-next: build failure after merge of the akpm tree

Hi Andrew, After merging the akpm tree, today's linux-next build (x86_64 allmodconfig) failed like this: fs/f2fs/node.c: In function 'init_free_nid_cache': fs/f2fs/node.c:2634:25: error: implicit declaration of function 'f2fs_kvzalloc' [-Werror=implicit-function-declaration]

linux-next: build failure after merge of the akpm tree

Hi Andrew, After merging the akpm tree, today's linux-next build (x86_64 allmodconfig) failed like this: fs/f2fs/node.c: In function 'init_free_nid_cache': fs/f2fs/node.c:2634:25: error: implicit declaration of function 'f2fs_kvzalloc' [-Werror=implicit-function-declaration]

[PATCH v2] xfs: Honor FALLOC_FL_KEEP_SIZE when punching ends of files

When punching past EOF on XFS, fallocate(mode=PUNCH_HOLE|KEEP_SIZE) will round the file size up to the nearest multiple of PAGE_SIZE: calvinow@vm-disks/generic-xfs-1 ~$ dd if=/dev/urandom of=test bs=2048 count=1 calvinow@vm-disks/generic-xfs-1 ~$ stat test Size: 2048Blocks: 8

[PATCH v2] xfs: Honor FALLOC_FL_KEEP_SIZE when punching ends of files

When punching past EOF on XFS, fallocate(mode=PUNCH_HOLE|KEEP_SIZE) will round the file size up to the nearest multiple of PAGE_SIZE: calvinow@vm-disks/generic-xfs-1 ~$ dd if=/dev/urandom of=test bs=2048 count=1 calvinow@vm-disks/generic-xfs-1 ~$ stat test Size: 2048Blocks: 8

Re: [Patch v2 02/11] s5p-mfc: Adding initial support for MFC v10.10

On Wed, 2017-03-15 at 14:52 -0500, Rob Herring wrote: > On Fri, Mar 03, 2017 at 02:37:07PM +0530, Smitha T Murthy wrote: > > Adding the support for MFC v10.10, with new register file and > > necessary hw control, decoder, encoder and structural changes. > > > > Signed-off-by: Smitha T Murthy

Re: [Patch v2 02/11] s5p-mfc: Adding initial support for MFC v10.10

On Wed, 2017-03-15 at 14:52 -0500, Rob Herring wrote: > On Fri, Mar 03, 2017 at 02:37:07PM +0530, Smitha T Murthy wrote: > > Adding the support for MFC v10.10, with new register file and > > necessary hw control, decoder, encoder and structural changes. > > > > Signed-off-by: Smitha T Murthy > >

linux-next: build warnings after merge of the akpm-current tree

Hi Andrew, After merging the akpm-current tree, today's linux-next build (x86_64 allmodconfig) produced these warnings: drivers/crypto/cavium/zip/zip_main.c: In function 'zip_show_stats': drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but

linux-next: build warnings after merge of the akpm-current tree

Hi Andrew, After merging the akpm-current tree, today's linux-next build (x86_64 allmodconfig) produced these warnings: drivers/crypto/cavium/zip/zip_main.c: In function 'zip_show_stats': drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects argument of type 'long int', but

Re: [PATCH 09/15] power: supply: bq24190_charger: Add voltage_max_design prop to battery

Hi, On Fri, Mar 17, 2017 at 10:55:21AM +0100, Hans de Goede wrote: > When combined with an external fuel-gauge, upower needs voltage_max_design > as it internally does all its calculations in Watts and converts the > charge_foo properties from A to Watts by using voltage_max_design. > >

Re: [PATCH 09/15] power: supply: bq24190_charger: Add voltage_max_design prop to battery

Hi, On Fri, Mar 17, 2017 at 10:55:21AM +0100, Hans de Goede wrote: > When combined with an external fuel-gauge, upower needs voltage_max_design > as it internally does all its calculations in Watts and converts the > charge_foo properties from A to Watts by using voltage_max_design. > >

linux-next: manual merge of the akpm tree with the net-next tree

Hi Andrew, Today's linux-next merge of the akpm tree got a conflict in: Documentation/devicetree/bindings/net/brcm,unimac-mdio.txt between commit: 0ce5aa1d6c97 ("dt-bindings: net: update bcmgenet binding for GENETv5") from the net-next tree and patch: "scripts/spelling.txt: Add

linux-next: manual merge of the akpm tree with the net-next tree

Hi Andrew, Today's linux-next merge of the akpm tree got a conflict in: Documentation/devicetree/bindings/net/brcm,unimac-mdio.txt between commit: 0ce5aa1d6c97 ("dt-bindings: net: update bcmgenet binding for GENETv5") from the net-next tree and patch: "scripts/spelling.txt: Add

Re: [PATCH 26/26] x86/mm: allow to have userspace mappings above 47-bits

"Kirill A. Shutemov" writes: @@ -168,6 +182,10 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0, > unsigned long addr = addr0; > struct vm_unmapped_area_info info; > > + addr = mpx_unmapped_area_check(addr, len,

Re: [PATCH 26/26] x86/mm: allow to have userspace mappings above 47-bits

"Kirill A. Shutemov" writes: @@ -168,6 +182,10 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0, > unsigned long addr = addr0; > struct vm_unmapped_area_info info; > > + addr = mpx_unmapped_area_check(addr, len, flags); > + if

Re: [PATCH v21 00/13] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

Hi Mark, On 18 March 2017 at 04:03, Mark Rutland wrote: > On Thu, Mar 09, 2017 at 11:47:16PM +0100, Fu Wei wrote: >> Hi Mark, Marc, > > Hi, > >> I have tried to rebase all the 19(6+13) patches on 4.11-rc1, >> all the patchse can directly apply on 4.11-rc1, >> >> Could you

Re: [PATCH v21 00/13] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer

Hi Mark, On 18 March 2017 at 04:03, Mark Rutland wrote: > On Thu, Mar 09, 2017 at 11:47:16PM +0100, Fu Wei wrote: >> Hi Mark, Marc, > > Hi, > >> I have tried to rebase all the 19(6+13) patches on 4.11-rc1, >> all the patchse can directly apply on 4.11-rc1, >> >> Could you help to review the

Re: [PATCH 14/15] power: supply: Add driver for Cherry Trail Whiskey Cove PMIC Fuel Gauge

Hi, On Fri, Mar 17, 2017 at 10:55:26AM +0100, Hans de Goede wrote: > Add a driver for the Cherry Trail Whiskey Cove PMIC Fuel Gauge, note > the Cherry Trail Whiskey Cove PMIC Fuel Gauge block is purely a fuel gauge > and not a full battery controller. As such it offers a platform_data > callback

Re: [PATCH 14/15] power: supply: Add driver for Cherry Trail Whiskey Cove PMIC Fuel Gauge

Hi, On Fri, Mar 17, 2017 at 10:55:26AM +0100, Hans de Goede wrote: > Add a driver for the Cherry Trail Whiskey Cove PMIC Fuel Gauge, note > the Cherry Trail Whiskey Cove PMIC Fuel Gauge block is purely a fuel gauge > and not a full battery controller. As such it offers a platform_data > callback

Re: [PATCH] Input: synaptics-rmi4 - Report slot as inactive when contact is a palm

On Thu, Mar 16, 2017 at 05:52:07PM -0700, Andrew Duggan wrote: > On 03/16/2017 05:04 PM, Dmitry Torokhov wrote: > > On Thu, Mar 16, 2017 at 04:56:31PM -0700, Andrew Duggan wrote: > > > When the firmware identifies a contact as a palm the driver sets the tool > > > type to MT_TOOL_PALM, but sets

Re: [PATCH] Input: synaptics-rmi4 - Report slot as inactive when contact is a palm

On Thu, Mar 16, 2017 at 05:52:07PM -0700, Andrew Duggan wrote: > On 03/16/2017 05:04 PM, Dmitry Torokhov wrote: > > On Thu, Mar 16, 2017 at 04:56:31PM -0700, Andrew Duggan wrote: > > > When the firmware identifies a contact as a palm the driver sets the tool > > > type to MT_TOOL_PALM, but sets

Re: Synaptics RMI4 touchpad regression in 4.11-rc1

On Fri, Mar 17, 2017 at 12:23:36PM -0700, Andrew Duggan wrote: > On 03/17/2017 09:57 AM, Benjamin Tissoires wrote: > > On Wed, Mar 15, 2017 at 2:19 AM, Andrew Duggan > > wrote: > > > On 03/13/2017 10:10 PM, Cameron Gutman wrote: > > > > > > > > On 03/13/2017 06:35 PM,

Re: Synaptics RMI4 touchpad regression in 4.11-rc1

On Fri, Mar 17, 2017 at 12:23:36PM -0700, Andrew Duggan wrote: > On 03/17/2017 09:57 AM, Benjamin Tissoires wrote: > > On Wed, Mar 15, 2017 at 2:19 AM, Andrew Duggan > > wrote: > > > On 03/13/2017 10:10 PM, Cameron Gutman wrote: > > > > > > > > On 03/13/2017 06:35 PM, Andrew Duggan wrote: > > >

Re: [PATCH 10/15] power: supply: bq24190_charger: Use extcon to determine ilimit, 5v boost

Hi, On Fri, Mar 17, 2017 at 10:55:22AM +0100, Hans de Goede wrote: > Add support for monitoring an extcon device with SDP/CDP/DCP and HOST > cables and adjust ilimit and enable/disable the 5v boost converter > accordingly. This is necessary on systems where the PSEL pin is hardwired > high and

Re: [PATCH 10/15] power: supply: bq24190_charger: Use extcon to determine ilimit, 5v boost

Hi, On Fri, Mar 17, 2017 at 10:55:22AM +0100, Hans de Goede wrote: > Add support for monitoring an extcon device with SDP/CDP/DCP and HOST > cables and adjust ilimit and enable/disable the 5v boost converter > accordingly. This is necessary on systems where the PSEL pin is hardwired > high and

Re: [PATCH v2] kexec: Introduce vmcoreinfo signature verification

On 03/20/2017 at 11:55 AM, Baoquan He wrote: > On 03/20/17 at 10:39am, Xunlei Pang wrote: >> On 03/20/2017 at 10:13 AM, Baoquan He wrote: >>> On 03/17/17 at 12:22pm, Eric W. Biederman wrote: Xunlei Pang writes: > Currently vmcoreinfo data is updated at boot time

Re: [PATCH v2] kexec: Introduce vmcoreinfo signature verification

On 03/20/2017 at 11:55 AM, Baoquan He wrote: > On 03/20/17 at 10:39am, Xunlei Pang wrote: >> On 03/20/2017 at 10:13 AM, Baoquan He wrote: >>> On 03/17/17 at 12:22pm, Eric W. Biederman wrote: Xunlei Pang writes: > Currently vmcoreinfo data is updated at boot time subsys_initcall(),

Re: [PATCH 06/15] power: supply: bq24190_charger: Use i2c-core irq-mapping code

Hi, On Fri, Mar 17, 2017 at 07:24:14PM +0200, Andy Shevchenko wrote: > On Fri, 2017-03-17 at 10:55 +0100, Hans de Goede wrote: > > The i2c-core already maps of irqs before calling the driver's probe > > function and there are no in tree users of > > bq24190_platform_data->gpio_int. > > > >

Re: [PATCH 06/15] power: supply: bq24190_charger: Use i2c-core irq-mapping code

Hi, On Fri, Mar 17, 2017 at 07:24:14PM +0200, Andy Shevchenko wrote: > On Fri, 2017-03-17 at 10:55 +0100, Hans de Goede wrote: > > The i2c-core already maps of irqs before calling the driver's probe > > function and there are no in tree users of > > bq24190_platform_data->gpio_int. > > > >

linux-next: manual merge of the gpio tree with the input tree

Hi Linus, Today's linux-next merge of the gpio tree got a conflict in: drivers/input/misc/soc_button_array.c between commit: a01cd17000a4 ("Input: soc_button_array - use NULL for GPIO connection ID") from the input tree and commit: c5097538c86a ("Input: soc_button_array - Propagate

linux-next: manual merge of the gpio tree with the input tree

Hi Linus, Today's linux-next merge of the gpio tree got a conflict in: drivers/input/misc/soc_button_array.c between commit: a01cd17000a4 ("Input: soc_button_array - use NULL for GPIO connection ID") from the input tree and commit: c5097538c86a ("Input: soc_button_array - Propagate

Re: [PATCH v2] kexec: Introduce vmcoreinfo signature verification

On 03/20/17 at 10:39am, Xunlei Pang wrote: > On 03/20/2017 at 10:13 AM, Baoquan He wrote: > > On 03/17/17 at 12:22pm, Eric W. Biederman wrote: > >> Xunlei Pang writes: > >> > >>> Currently vmcoreinfo data is updated at boot time subsys_initcall(), > >>> it has the risk of being

Re: [PATCH v2] kexec: Introduce vmcoreinfo signature verification

On 03/20/17 at 10:39am, Xunlei Pang wrote: > On 03/20/2017 at 10:13 AM, Baoquan He wrote: > > On 03/17/17 at 12:22pm, Eric W. Biederman wrote: > >> Xunlei Pang writes: > >> > >>> Currently vmcoreinfo data is updated at boot time subsys_initcall(), > >>> it has the risk of being modified by some

[PATCH v3] ASoC: rt286: fix headphone click/crack noise on Dell XPS 9343 I2S mode

HDA mode fixed the issue by these two commits: '9476d369d7b3 ALSA: hda - Mute headphone pin on suspend on XPS13 9333' '3e1b0c4a9d56 ALSA: hda - Fix click noise at start on Dell XPS13' Apply the same workarounds to rt286 can solve the issue. When jack is plugged, it rapidly generates I2C

[PATCH v3] ASoC: rt286: fix headphone click/crack noise on Dell XPS 9343 I2S mode

HDA mode fixed the issue by these two commits: '9476d369d7b3 ALSA: hda - Mute headphone pin on suspend on XPS13 9333' '3e1b0c4a9d56 ALSA: hda - Fix click noise at start on Dell XPS13' Apply the same workarounds to rt286 can solve the issue. When jack is plugged, it rapidly generates I2C

Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs

On 19-03-17, 14:34, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The PELT metric used by the schedutil governor underestimates the > CPU utilization in some cases. The reason for that may be time spent > in interrupt handlers and similar which is not

Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs

On 19-03-17, 14:34, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > The PELT metric used by the schedutil governor underestimates the > CPU utilization in some cases. The reason for that may be time spent > in interrupt handlers and similar which is not accounted for by PELT. > > That

Re: [PATCH v5 3/7] perf/sdt: Directly record SDT events with 'perf record'

Thanks Masami for detailed review. Please see my comments below. On Friday 17 March 2017 02:35 PM, Masami Hiramatsu wrote: > Hi Ravi, > > (I avoided to review parser part since it may go to yacc in next version) > > On Tue, 14 Mar 2017 20:36:54 +0530 > Ravi Bangoria

Re: [PATCH v5 3/7] perf/sdt: Directly record SDT events with 'perf record'

Thanks Masami for detailed review. Please see my comments below. On Friday 17 March 2017 02:35 PM, Masami Hiramatsu wrote: > Hi Ravi, > > (I avoided to review parser part since it may go to yacc in next version) > > On Tue, 14 Mar 2017 20:36:54 +0530 > Ravi Bangoria wrote: > > [SNIP] >> @@

[PATCH v6] drm/rockchip: Refactor the component match logic.

Currently we are adding all components from the dts, if one of their drivers been disabled, we would not be able to bring up others. Refactor component match logic, follow exynos drm. Signed-off-by: Jeffy Chen Reviewed-by: Andrzej Hajda Acked-by:

[PATCH v6] drm/rockchip: Refactor the component match logic.

Currently we are adding all components from the dts, if one of their drivers been disabled, we would not be able to bring up others. Refactor component match logic, follow exynos drm. Signed-off-by: Jeffy Chen Reviewed-by: Andrzej Hajda Acked-by: Mark Yao --- Changes in v6: Add Mark Yao 's

Re: [PATCH 1/2] cpufreq: schedutil: Fix per-CPU structure initialization in sugov_start()

On 19-03-17, 14:30, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > sugov_start() only initializes struct sugov_cpu per-CPU structures > for shared policies, but it should do that for single-CPU policies too. > > That in particular makes the IO-wait boost

Re: [PATCH 1/2] cpufreq: schedutil: Fix per-CPU structure initialization in sugov_start()

On 19-03-17, 14:30, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > sugov_start() only initializes struct sugov_cpu per-CPU structures > for shared policies, but it should do that for single-CPU policies too. > > That in particular makes the IO-wait boost mechanism work in the > cases

Re: [PATCH] cpufreq: Restore policy min/max limits on CPU online

On 17-03-17, 18:40, Rafael J. Wysocki wrote: > On Fri, Mar 17, 2017 at 5:43 PM, Viresh Kumar wrote: > > On 17 March 2017 at 22:01, Rafael J. Wysocki wrote: > > > >> IMO if we are not going to restore the governor, we also should not > >> restore the

Re: [PATCH] cpufreq: Restore policy min/max limits on CPU online

On 17-03-17, 18:40, Rafael J. Wysocki wrote: > On Fri, Mar 17, 2017 at 5:43 PM, Viresh Kumar wrote: > > On 17 March 2017 at 22:01, Rafael J. Wysocki wrote: > > > >> IMO if we are not going to restore the governor, we also should not > >> restore the limits as those things are related. Now, the

Re: Still OOM problems with 4.9er/4.10er kernels

On Sun, 2017-03-19 at 17:02 +0100, Gerhard Wiesinger wrote: > mount | grep cgroup Just because controllers are mounted doesn't mean they're populated. To check that, you want to look for directories under the mount points with a non-empty 'tasks'. You will find some, but memory cgroup

Re: Still OOM problems with 4.9er/4.10er kernels

On Sun, 2017-03-19 at 17:02 +0100, Gerhard Wiesinger wrote: > mount | grep cgroup Just because controllers are mounted doesn't mean they're populated. To check that, you want to look for directories under the mount points with a non-empty 'tasks'. You will find some, but memory cgroup

[PATCH v2] drm/bridge: dw_hdmi: support i2c extended read mode

"I2C Master Interface Extended Read Mode" implements a segment pointer-based read operation using the Special Register configuration. This patch fix https://patchwork.kernel.org/patch/7098101/ mentioned "The current implementation does not support "I2C Master Interface Extended Read Mode" to read

[PATCH v2] drm/bridge: dw_hdmi: support i2c extended read mode

"I2C Master Interface Extended Read Mode" implements a segment pointer-based read operation using the Special Register configuration. This patch fix https://patchwork.kernel.org/patch/7098101/ mentioned "The current implementation does not support "I2C Master Interface Extended Read Mode" to read

[PATCH 2/4] perf annotate: Avoid division by zero when calculating percent

Currently perf-annotate with --print-line can print -nan(0x8) because of division by zero when calculating percent. So if a sum of samples is zero, skip calculating percent. Before: $ perf annotate --stdio -l Sorted summary for file /home/taeung/workspace/a.out

[PATCH 2/4] perf annotate: Avoid division by zero when calculating percent

Currently perf-annotate with --print-line can print -nan(0x8) because of division by zero when calculating percent. So if a sum of samples is zero, skip calculating percent. Before: $ perf annotate --stdio -l Sorted summary for file /home/taeung/workspace/a.out

[PATCH 3/4] perf annotate: Fix missing setting nr samples on source_line

If using --show-total-period with -l, disasm__calc_percent() use a 'samples' array of source_line. But samples[evidx].nr is always zero so print 0 values as below. Before: $ perf annotate --stdio -l --show-total-period ... 0 :400816: push %rbp 0 :400817:

[PATCH 1/4] perf annotate: Use build-id dir when reading link name

In dso__disassemble_filename() when reading link name from a build-id file, it is failed each time because a build-id file gotten from dso__build_id_filename() is not symbolic link. So use build-id directory path instead of a build-id file name. For example, if build-id file name gotten from

[PATCH 3/4] perf annotate: Fix missing setting nr samples on source_line

If using --show-total-period with -l, disasm__calc_percent() use a 'samples' array of source_line. But samples[evidx].nr is always zero so print 0 values as below. Before: $ perf annotate --stdio -l --show-total-period ... 0 :400816: push %rbp 0 :400817:

[PATCH 1/4] perf annotate: Use build-id dir when reading link name

In dso__disassemble_filename() when reading link name from a build-id file, it is failed each time because a build-id file gotten from dso__build_id_filename() is not symbolic link. So use build-id directory path instead of a build-id file name. For example, if build-id file name gotten from

[PATCH 0/4] perf annotate: Bugfixes

Hi, perf-annotate has little bugs so I fix them. I'd appreciate some feedback on this patchset. :) Thanks, Taeung Taeung Song (4): perf annotate: Use build-id dir when reading link name perf annotate: Avoid division by zero when calculating percent perf annotate: Fix missing setting nr

[PATCH 0/4] perf annotate: Bugfixes

Hi, perf-annotate has little bugs so I fix them. I'd appreciate some feedback on this patchset. :) Thanks, Taeung Taeung Song (4): perf annotate: Use build-id dir when reading link name perf annotate: Avoid division by zero when calculating percent perf annotate: Fix missing setting nr

[PATCH 4/4] perf annotate: More exactly grep -v of the objdump command

grep -v "file name" in the objdump command cause a side effect eliminating filename:linenr of output of 'objdump -l' if the object file name and source file name are about the same so fix it. The objdump command in symbol__disassemble() can be as below $ objdump -l -d -S -C

[PATCH 4/4] perf annotate: More exactly grep -v of the objdump command

grep -v "file name" in the objdump command cause a side effect eliminating filename:linenr of output of 'objdump -l' if the object file name and source file name are about the same so fix it. The objdump command in symbol__disassemble() can be as below $ objdump -l -d -S -C

Re: [PATCH v2 3/4] watchdog: iTCO_wdt: Fix PMC GCR memory mapping failure

Hi Kuppuswamy, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc3 next-20170310] [cannot apply to platform-drivers-x86/for-next tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v2 3/4] watchdog: iTCO_wdt: Fix PMC GCR memory mapping failure

Hi Kuppuswamy, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc3 next-20170310] [cannot apply to platform-drivers-x86/for-next tip/x86/core] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH 2/2 v2] clk: qoriq: Separate root input clock for core PLLs on ls1012a

From: Scott Wood ls1012a has separate input root clocks for core PLLs versus the platform PLL, with the latter described as sysclk in the hw docs. If a second input clock, named "coreclk", is present, this clock will be used for the core PLLs. Signed-off-by: Scott Wood

[PATCH 2/2 v2] clk: qoriq: Separate root input clock for core PLLs on ls1012a

From: Scott Wood ls1012a has separate input root clocks for core PLLs versus the platform PLL, with the latter described as sysclk in the hw docs. If a second input clock, named "coreclk", is present, this clock will be used for the core PLLs. Signed-off-by: Scott Wood Signed-off-by: Tang

[PATCH 1/2 v2] dt-bindings: qoriq-clock: Add coreclk

From: Scott Wood ls1012a has separate input root clocks for core PLLs versus the platform PLL, with the latter described as sysclk in the hw docs. Update the qoriq-clock binding to allow a second input clock, named "coreclk". If present, this clock will be used for the core

[PATCH 1/2 v2] dt-bindings: qoriq-clock: Add coreclk

From: Scott Wood ls1012a has separate input root clocks for core PLLs versus the platform PLL, with the latter described as sysclk in the hw docs. Update the qoriq-clock binding to allow a second input clock, named "coreclk". If present, this clock will be used for the core PLLs.

RE: [PATCH] HV: properly delay KVP packets when negotiation is in progress

> -Original Message- > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > Sent: Friday, March 17, 2017 9:16 AM > To: Long Li > Cc: KY Srinivasan ; Haiyang Zhang > ; Stephen Hemminger > ;

RE: [PATCH] HV: properly delay KVP packets when negotiation is in progress

> -Original Message- > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > Sent: Friday, March 17, 2017 9:16 AM > To: Long Li > Cc: KY Srinivasan ; Haiyang Zhang > ; Stephen Hemminger > ; de...@linuxdriverproject.org; linux- > ker...@vger.kernel.org > Subject: Re: [PATCH] HV: properly

linux-next: build failure after merge of the char-misc tree

Hi all, After merging the char-misc tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/misc/aspeed-lpc-ctrl.c: In function 'aspeed_lpc_ctrl_mmap': drivers/misc/aspeed-lpc-ctrl.c:51:9: error: implicit declaration of function 'pgprot_dmacoherent'

linux-next: build failure after merge of the char-misc tree

Hi all, After merging the char-misc tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/misc/aspeed-lpc-ctrl.c: In function 'aspeed_lpc_ctrl_mmap': drivers/misc/aspeed-lpc-ctrl.c:51:9: error: implicit declaration of function 'pgprot_dmacoherent'

[PATCH] kvmgt: Hold struct kvm reference

The kvmgt code keeps a pointer to the struct kvm associated with the device, but doesn't actually hold a reference to it. If we do unclean shutdown testing (ie. killing the user process), then we can see the kvm association to the device unset, which causes kvmgt to trigger a device release via a

[PATCH] kvmgt: Hold struct kvm reference

The kvmgt code keeps a pointer to the struct kvm associated with the device, but doesn't actually hold a reference to it. If we do unclean shutdown testing (ie. killing the user process), then we can see the kvm association to the device unset, which causes kvmgt to trigger a device release via a

Re: [PATCH v2] kexec: Introduce vmcoreinfo signature verification

On 03/20/2017 at 10:13 AM, Baoquan He wrote: > On 03/17/17 at 12:22pm, Eric W. Biederman wrote: >> Xunlei Pang writes: >> >>> Currently vmcoreinfo data is updated at boot time subsys_initcall(), >>> it has the risk of being modified by some wrong code during system >>> is

[PATCH] vfio: Rework group release notifier warning

The intent of the original warning is make sure that the mdev vendor driver has removed any group notifiers at the point where the group is closed by the user. Theoretically this would be through an orderly shutdown where any devices are release prior to the group release. We can't always count

Re: [PATCH v6 5/8] dt-bindings: input: touchscreen: Add max11801-ts binding

On Thu, Mar 16, 2017 at 12:35:38PM +0530, Jagan Teki wrote: > From: Jagan Teki > > Add missing documentation of max11801-ts dt-binding details. > > Cc: Mark Rutland > Cc: Rob Herring > Cc: Shawn Guo >

Re: [PATCH v2] kexec: Introduce vmcoreinfo signature verification

On 03/20/2017 at 10:13 AM, Baoquan He wrote: > On 03/17/17 at 12:22pm, Eric W. Biederman wrote: >> Xunlei Pang writes: >> >>> Currently vmcoreinfo data is updated at boot time subsys_initcall(), >>> it has the risk of being modified by some wrong code during system >>> is running. >>> >>> As a

[PATCH] vfio: Rework group release notifier warning

The intent of the original warning is make sure that the mdev vendor driver has removed any group notifiers at the point where the group is closed by the user. Theoretically this would be through an orderly shutdown where any devices are release prior to the group release. We can't always count

Re: [PATCH v6 5/8] dt-bindings: input: touchscreen: Add max11801-ts binding

On Thu, Mar 16, 2017 at 12:35:38PM +0530, Jagan Teki wrote: > From: Jagan Teki > > Add missing documentation of max11801-ts dt-binding details. > > Cc: Mark Rutland > Cc: Rob Herring > Cc: Shawn Guo > Cc: Michael Trimarchi > Signed-off-by: Jagan Teki > --- > Changes for v6: > - Replace the

Linux 4.11-rc3

Another week, another rc. As is our usual pattern after the merge window, rc3 is larger than rc2, but this is hopefully the point where things start to shrink and calm down. We had a late typo in rc2 that affected arm and powerpc (the prep code for the 5-level page tables), and hopefully there

Linux 4.11-rc3

Another week, another rc. As is our usual pattern after the merge window, rc3 is larger than rc2, but this is hopefully the point where things start to shrink and calm down. We had a late typo in rc2 that affected arm and powerpc (the prep code for the 5-level page tables), and hopefully there

linux-next: manual merge of the tty tree with the tty.current tree

Hi Greg, Today's linux-next merge of the tty tree got a conflict in: drivers/tty/tty_ldisc.c between commit: 5362544bebe8 ("tty: don't panic on OOM in tty_set_ldisc()") from the tty.current tree and commit: 71472fa9c52b ("tty: Fix ldisc crash on reopened tty") from the tty tree. I

linux-next: manual merge of the tty tree with the tty.current tree

Hi Greg, Today's linux-next merge of the tty tree got a conflict in: drivers/tty/tty_ldisc.c between commit: 5362544bebe8 ("tty: don't panic on OOM in tty_set_ldisc()") from the tty.current tree and commit: 71472fa9c52b ("tty: Fix ldisc crash on reopened tty") from the tty tree. I

Re: [PATCH] x86/mm: trivial code cleanup for memory_map_top_doown()

Hi, Borislav Do you still have some concern on this change? On Tue, Mar 14, 2017 at 11:56:39AM +0800, Wei Yang wrote: >On Mon, Mar 13, 2017 at 07:50:21PM +0100, Borislav Petkov wrote: >>On Fri, Feb 17, 2017 at 10:30:33PM +0800, Wei Yang wrote: >>> In case (last_start <= step_size), start is for

Re: [PATCH] x86/mm: trivial code cleanup for memory_map_top_doown()

Hi, Borislav Do you still have some concern on this change? On Tue, Mar 14, 2017 at 11:56:39AM +0800, Wei Yang wrote: >On Mon, Mar 13, 2017 at 07:50:21PM +0100, Borislav Petkov wrote: >>On Fri, Feb 17, 2017 at 10:30:33PM +0800, Wei Yang wrote: >>> In case (last_start <= step_size), start is for

[PATCH] backlight: Add TI LMU backlight driver

This is consolidated driver which supports backlight devices below. LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697. Structure - It consists of two parts - core and data. Core part supports features below. - Backlight subsystem control - Channel configuration from DT

[PATCH] backlight: Add TI LMU backlight driver

This is consolidated driver which supports backlight devices below. LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697. Structure - It consists of two parts - core and data. Core part supports features below. - Backlight subsystem control - Channel configuration from DT

Re: [PATCH v2] kexec: Introduce vmcoreinfo signature verification

On 03/17/17 at 12:22pm, Eric W. Biederman wrote: > Xunlei Pang writes: > > > Currently vmcoreinfo data is updated at boot time subsys_initcall(), > > it has the risk of being modified by some wrong code during system > > is running. > > > > As a result, vmcore dumped may

Re: [PATCH v2] kexec: Introduce vmcoreinfo signature verification

On 03/17/17 at 12:22pm, Eric W. Biederman wrote: > Xunlei Pang writes: > > > Currently vmcoreinfo data is updated at boot time subsys_initcall(), > > it has the risk of being modified by some wrong code during system > > is running. > > > > As a result, vmcore dumped may contain the wrong

Re: [PATCH] x86_64, kexec: Avoid unnecessary identity mappings for kdump

On 03/18/2017 at 01:38 AM, Eric W. Biederman wrote: > Xunlei Pang writes: > >> kexec setups identity mappings for all the memory mapped in 1st kernel, >> this is not necessary for the kdump case. Actually it can cause extra >> memory consumption for paging structures, which is

Re: [PATCH] x86_64, kexec: Avoid unnecessary identity mappings for kdump

On 03/18/2017 at 01:38 AM, Eric W. Biederman wrote: > Xunlei Pang writes: > >> kexec setups identity mappings for all the memory mapped in 1st kernel, >> this is not necessary for the kdump case. Actually it can cause extra >> memory consumption for paging structures, which is quite considerable

Re: [PATCH] kexec: Update vmcoreinfo after crash happened

On 03/19/2017 at 02:23 AM, Petr Tesarik wrote: > On Thu, 16 Mar 2017 21:40:58 +0800 > Xunlei Pang wrote: > >> On 03/16/2017 at 09:18 PM, Baoquan He wrote: >>> On 03/16/17 at 08:36pm, Xunlei Pang wrote: On 03/16/2017 at 08:27 PM, Baoquan He wrote: > Hi Xunlei, >

Re: [PATCH] kexec: Update vmcoreinfo after crash happened

On 03/19/2017 at 02:23 AM, Petr Tesarik wrote: > On Thu, 16 Mar 2017 21:40:58 +0800 > Xunlei Pang wrote: > >> On 03/16/2017 at 09:18 PM, Baoquan He wrote: >>> On 03/16/17 at 08:36pm, Xunlei Pang wrote: On 03/16/2017 at 08:27 PM, Baoquan He wrote: > Hi Xunlei, > > Did you really

Re: kexec regression since 4.9 caused by efi

On 03/17/17 at 01:32pm, Matt Fleming wrote: > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote: > > > > Matt, I think it should be fine although I think the md type checking in > > efi_mem_desc_lookup() is causing confusion and not easy to understand.. > > Could you make that a separate patch if

Re: kexec regression since 4.9 caused by efi

On 03/17/17 at 01:32pm, Matt Fleming wrote: > On Fri, 17 Mar, at 10:09:51AM, Dave Young wrote: > > > > Matt, I think it should be fine although I think the md type checking in > > efi_mem_desc_lookup() is causing confusion and not easy to understand.. > > Could you make that a separate patch if

Re: [PATCH 1/5] mm, swap: Fix comment in __read_swap_cache_async

Hi, Rafeal, Rafael Aquini writes: > On Fri, Mar 17, 2017 at 02:46:19PM +0800, Huang, Ying wrote: >> From: Huang Ying >> >> The commit cbab0e4eec29 ("swap: avoid read_swap_cache_async() race to >> deadlock while waiting on discard I/O completion") fixed

Re: [PATCH 1/5] mm, swap: Fix comment in __read_swap_cache_async

Hi, Rafeal, Rafael Aquini writes: > On Fri, Mar 17, 2017 at 02:46:19PM +0800, Huang, Ying wrote: >> From: Huang Ying >> >> The commit cbab0e4eec29 ("swap: avoid read_swap_cache_async() race to >> deadlock while waiting on discard I/O completion") fixed a deadlock in >>

  1   2   3   4   5   6   >