Re: [PATCH] edac:Fix kernel panic regression in edac_mc_reset_delay_period

On Thu, May 19, 2016 at 06:10:37PM -0400, nick wrote: > Here is the issue though it does not happen on v4.4 but on newer > kernels. I bisected it and it does work if the commit I stated is > reverted, and working at that commit the only line changed in any > function is in my patch. Here we can

Re: [PATCH] edac:Fix kernel panic regression in edac_mc_reset_delay_period

On Thu, May 19, 2016 at 06:10:37PM -0400, nick wrote: > Here is the issue though it does not happen on v4.4 but on newer > kernels. I bisected it and it does work if the commit I stated is > reverted, and working at that commit the only line changed in any > function is in my patch. Here we can

Re: [PATCH] fbcon: use default if cursor blink interval is not valid

On Thu, 19 May 2016, David Daney wrote: > On 05/18/2016 09:21 PM, Scot Doyle wrote: > > Two current [1] and three previous [2] systems locked during boot > > because the cursor flash timer was set using an ops->cur_blink_jiffies > > value of 0. Previous patches attempted to solve the problem by

Re: [PATCH] fbcon: use default if cursor blink interval is not valid

On Thu, 19 May 2016, David Daney wrote: > On 05/18/2016 09:21 PM, Scot Doyle wrote: > > Two current [1] and three previous [2] systems locked during boot > > because the cursor flash timer was set using an ops->cur_blink_jiffies > > value of 0. Previous patches attempted to solve the problem by

[PATCH 10/11] perf trace: Only auto set call-graph to "dwarf" when syscalls are being traced

From: Arnaldo Carvalho de Melo When --min-stack or --max-stack is passwd but --no-syscalls is also in effect, there is no point in automatically setting '--call-graph dwarf'. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa

[PATCH 10/11] perf trace: Only auto set call-graph to "dwarf" when syscalls are being traced

From: Arnaldo Carvalho de Melo When --min-stack or --max-stack is passwd but --no-syscalls is also in effect, there is no point in automatically setting '--call-graph dwarf'. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Milian Wolff Cc: Namhyung Kim Cc: Wang Nan Link:

[PATCH 08/11] perf annotate: Fix identification of ARM blt and bls instructions

From: Chris Ryder The ARM blt and bls instructions are not correctly identified when parsing assembly because the list of recognised instructions must be sorted by name. Swap the ordering of blt and bls. Signed-off-by: Chris Ryder Acked-by: Pawel Moll

[PATCH 05/11] perf trace: Fix exit_group() formatting

From: Arnaldo Carvalho de Melo This doesn't return, so there is no raw_syscalls:sys_exit for it, add the ending ')', without any return value, since it is void. Reported-by: Ingo Molnar Cc: Adrian Hunter Cc: David Ahern

[PATCH 01/11] perf tools: Find vdso supporting cross-platform analysis

From: He Kuang There's a problem in machine__findnew_vdso(), vdso buildid generated by a 32-bit machine stores it with the name 'vdso', but when processing buildid on a 64-bit machine with the same 'perf.data', perf will search for vdso named as 'vdso32' and get failed. This

[PATCH 08/11] perf annotate: Fix identification of ARM blt and bls instructions

From: Chris Ryder The ARM blt and bls instructions are not correctly identified when parsing assembly because the list of recognised instructions must be sorted by name. Swap the ordering of blt and bls. Signed-off-by: Chris Ryder Acked-by: Pawel Moll Cc: Alexander Shishkin Cc: Mark Rutland

[PATCH 05/11] perf trace: Fix exit_group() formatting

From: Arnaldo Carvalho de Melo This doesn't return, so there is no raw_syscalls:sys_exit for it, add the ending ')', without any return value, since it is void. Reported-by: Ingo Molnar Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Milian Wolff Cc: Namhyung Kim Cc: Wang Nan Link:

[PATCH 01/11] perf tools: Find vdso supporting cross-platform analysis

From: He Kuang There's a problem in machine__findnew_vdso(), vdso buildid generated by a 32-bit machine stores it with the name 'vdso', but when processing buildid on a 64-bit machine with the same 'perf.data', perf will search for vdso named as 'vdso32' and get failed. This patch tries to find

[GIT PULL 00/11] perf/core improvements and fixes

-05-16 23:11:54 -0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-20160519 for you to fetch changes up to f978a7b47e5a31d4057187153f71e95b24455e54: perf tools: Set buildid dir under symfs when --symfs

[PATCH 07/11] perf tools: Fix usage of max_stack sysctl

From: Arnaldo Carvalho de Melo We cannot limit processing stacks from the current value of the sysctl, as we may be processing perf.data files, possibly from other machines. Instead use the old PERF_MAX_STACK_DEPTH, the sysctl default, that can be overriden using --max-stack or

[PATCH 04/11] perf top: Use machine->kptr_restrict_warned

From: Arnaldo Carvalho de Melo Its now there, no need to have it too. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Milian Wolff Cc: Namhyung Kim Cc: Wang Nan

[PATCH 11/11] perf tools: Set buildid dir under symfs when --symfs is provided

From: He Kuang This patch moves the reference of buildid dir to 'symfs/.debug' and skips the local buildid dir when '--symfs' is given, so that every single file opened by perf is relative to symfs directory now. Signed-off-by: He Kuang Acked-by: David

[PATCH 04/11] perf top: Use machine->kptr_restrict_warned

From: Arnaldo Carvalho de Melo Its now there, no need to have it too. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Milian Wolff Cc: Namhyung Kim Cc: Wang Nan Link: http://lkml.kernel.org/n/tip-y18oeou494uy11im7u9to...@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo ---

[PATCH 11/11] perf tools: Set buildid dir under symfs when --symfs is provided

From: He Kuang This patch moves the reference of buildid dir to 'symfs/.debug' and skips the local buildid dir when '--symfs' is given, so that every single file opened by perf is relative to symfs directory now. Signed-off-by: He Kuang Acked-by: David Ahern Acked-by: Jiri Olsa Cc: Adrian

[GIT PULL 00/11] perf/core improvements and fixes

-05-16 23:11:54 -0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo-20160519 for you to fetch changes up to f978a7b47e5a31d4057187153f71e95b24455e54: perf tools: Set buildid dir under symfs when --symfs

[PATCH 07/11] perf tools: Fix usage of max_stack sysctl

From: Arnaldo Carvalho de Melo We cannot limit processing stacks from the current value of the sysctl, as we may be processing perf.data files, possibly from other machines. Instead use the old PERF_MAX_STACK_DEPTH, the sysctl default, that can be overriden using --max-stack or equivalent. Cc:

[PATCH 03/11] perf trace: Warn when trying to resolve kernel addresses with kptr_restrict=1

From: Arnaldo Carvalho de Melo Hook into the libtraceevent plugin kernel symbol resolver to warn the user that that can't happen with kptr_restrict=1. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Milian

[PATCH 03/11] perf trace: Warn when trying to resolve kernel addresses with kptr_restrict=1

From: Arnaldo Carvalho de Melo Hook into the libtraceevent plugin kernel symbol resolver to warn the user that that can't happen with kptr_restrict=1. Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Milian Wolff Cc: Namhyung Kim Cc: Wang Nan Link:

[PATCH 09/11] perf annotate: Sort list of recognised instructions

From: Chris Ryder Currently the list of instructions recognised by perf annotate has to be explicitly written in sorted order. This makes it easy to make mistakes when adding new instructions. Sort the list of instructions on first access. Signed-off-by: Chris Ryder

[PATCH 09/11] perf annotate: Sort list of recognised instructions

From: Chris Ryder Currently the list of instructions recognised by perf annotate has to be explicitly written in sorted order. This makes it easy to make mistakes when adding new instructions. Sort the list of instructions on first access. Signed-off-by: Chris Ryder Acked-by: Pawel Moll Cc:

[PATCH 06/11] perf callchain: Stop validating callchains by the max_stack sysctl

From: Arnaldo Carvalho de Melo As thread__resolve_callchain_sample can be used for handling perf.data files, that could've been recorded with a large max_stack sysctl setting than what the system used for analysis has set. Cc: Adrian Hunter Cc:

[PATCH 02/11] perf machine: Do not bail out if not managing to read ref reloc symbol

From: Arnaldo Carvalho de Melo This means the user can't access /proc/kallsyms, for instance, because /proc/sys/kernel/kptr_restrict is set to 1. Instead leave the ref_reloc_sym as NULL and code using it will cope. This allows 'perf trace' to work on such systems for !root,

[PATCH 06/11] perf callchain: Stop validating callchains by the max_stack sysctl

From: Arnaldo Carvalho de Melo As thread__resolve_callchain_sample can be used for handling perf.data files, that could've been recorded with a large max_stack sysctl setting than what the system used for analysis has set. Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Alexei Starovoitov Cc:

[PATCH 02/11] perf machine: Do not bail out if not managing to read ref reloc symbol

From: Arnaldo Carvalho de Melo This means the user can't access /proc/kallsyms, for instance, because /proc/sys/kernel/kptr_restrict is set to 1. Instead leave the ref_reloc_sym as NULL and code using it will cope. This allows 'perf trace' to work on such systems for !root, the only issue

Re: pull-request: wireless-drivers-next 2016-05-13 (take two)

On Thu, May 19, 2016 at 6:45 AM, Kalle Valo wrote: > Hi Dave, > > this the second version of the last pull request to net-next for 4.7, > which got postponed due to the recent iwlwifi merge conflict. Now that > Linus fixed the merge problem in his tree I actually didn't have

Re: pull-request: wireless-drivers-next 2016-05-13 (take two)

On Thu, May 19, 2016 at 6:45 AM, Kalle Valo wrote: > Hi Dave, > > this the second version of the last pull request to net-next for 4.7, > which got postponed due to the recent iwlwifi merge conflict. Now that > Linus fixed the merge problem in his tree I actually didn't have to fix > anything in

Re: ioatdma(Intel(R) I/OAT DMA Engine init failed)

On Thu, May 19, 2016 at 1:17 PM, Jiang, Dave wrote: >> > > And I checked the config and found the CONFIG_PCI_MMCONFIG=y. The >> > > following string also can be observed in the dmesg: >> > > >> > > [1.419853] PCI: MMCONFIG for domain [bus 00-ff] at >> > >

Re: ioatdma(Intel(R) I/OAT DMA Engine init failed)

On Thu, May 19, 2016 at 1:17 PM, Jiang, Dave wrote: >> > > And I checked the config and found the CONFIG_PCI_MMCONFIG=y. The >> > > following string also can be observed in the dmesg: >> > > >> > > [1.419853] PCI: MMCONFIG for domain [bus 00-ff] at >> > > [mem0x8000-0x8fff] (base

[patch] mm, migrate: increment fail count on ENOMEM

If page migration fails due to -ENOMEM, nr_failed should still be incremented for proper statistics. This was encountered recently when all page migration vmstats showed 0, and inferred that migrate_pages() was never called, although in reality the first page migration failed because

[patch] mm, migrate: increment fail count on ENOMEM

If page migration fails due to -ENOMEM, nr_failed should still be incremented for proper statistics. This was encountered recently when all page migration vmstats showed 0, and inferred that migrate_pages() was never called, although in reality the first page migration failed because

[RFC] iio: Add driver for Silabs si1132, si1141/2/3 and si1145/6/7 ambient light, uv index and proximity sensors

From: Peter Meerwald The si114x supports x=1,2,3 IR LEDs for proximity sensing together with visible and IR ambient light sensing (ALS). Newer parts (si1132, si1145/6/7) can measure UV light and compute an UV index Arranging 3 IR LEDs in a triangular shape can be used for

[RFC] iio: Add driver for Silabs si1132, si1141/2/3 and si1145/6/7 ambient light, uv index and proximity sensors

From: Peter Meerwald The si114x supports x=1,2,3 IR LEDs for proximity sensing together with visible and IR ambient light sensing (ALS). Newer parts (si1132, si1145/6/7) can measure UV light and compute an UV index Arranging 3 IR LEDs in a triangular shape can be used for detection of swipe

[PATCH] mm: move page_ext_init after all struct pages are initialized

When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot are initialized, then the rest are initialized in parallel by starting one-off "pgdatinitX" kernel thread for each node X. If page_ext_init is called before it, some pages will not have valid extension, so move

[PATCH] mm: move page_ext_init after all struct pages are initialized

When DEFERRED_STRUCT_PAGE_INIT is enabled, just a subset of memmap at boot are initialized, then the rest are initialized in parallel by starting one-off "pgdatinitX" kernel thread for each node X. If page_ext_init is called before it, some pages will not have valid extension, so move

[PATCH] ARM: dts: exynos: Remove unneded always-on for regulators on Peach boards

The regulator always-on property should only be used for regulators that either can't be disabled or the drivers for the client devices are not enabling the regulator and so being disabled due to unused. There are some max77802 regulators in the Peach Pit and Pi boards that are always-on but

[PATCH] ARM: dts: exynos: Remove unneded always-on for regulators on Peach boards

The regulator always-on property should only be used for regulators that either can't be disabled or the drivers for the client devices are not enabling the regulator and so being disabled due to unused. There are some max77802 regulators in the Peach Pit and Pi boards that are always-on but

Re: [PATCH] edac:Fix kernel panic regression in edac_mc_reset_delay_period

On Thu, May 19, 2016 at 03:44:57PM -0400, Nicholas Krause wrote: > This fixes a kernel panic regression in the function, > edac_mc_reset_delay_period as show by this kernel panic > trace: > [ 58.402137] BUG: unable to handle kernel paging request at 00015d10 > [ 58.410564] IP: []

Re: [PATCH] edac:Fix kernel panic regression in edac_mc_reset_delay_period

On Thu, May 19, 2016 at 03:44:57PM -0400, Nicholas Krause wrote: > This fixes a kernel panic regression in the function, > edac_mc_reset_delay_period as show by this kernel panic > trace: > [ 58.402137] BUG: unable to handle kernel paging request at 00015d10 > [ 58.410564] IP: []

[PATCH v3 2/2] i2c: qup: support SMBus block read

From: Naveen Kaje I2C QUP driver relies on SMBus emulation support from the framework. To handle SMBus block reads, the driver should check I2C_M_RECV_LEN flag and should read the first byte received as the message length. The driver configures the QUP hardware to read one

[PATCH v3 1/2] i2c: qup: add ACPI support

From: Naveen Kaje Add support to get the device parameters from ACPI. Assume that the clocks are managed by firmware. Signed-off-by: Naveen Kaje Signed-off-by: Austin Christ --- drivers/i2c/busses/i2c-qup.c | 60

[PATCH v3 2/2] i2c: qup: support SMBus block read

From: Naveen Kaje I2C QUP driver relies on SMBus emulation support from the framework. To handle SMBus block reads, the driver should check I2C_M_RECV_LEN flag and should read the first byte received as the message length. The driver configures the QUP hardware to read one byte. Once the

[PATCH v3 1/2] i2c: qup: add ACPI support

From: Naveen Kaje Add support to get the device parameters from ACPI. Assume that the clocks are managed by firmware. Signed-off-by: Naveen Kaje Signed-off-by: Austin Christ --- drivers/i2c/busses/i2c-qup.c | 60 1 file changed, 44 insertions(+),

Re: [RFC][PATCH 8/7] sched/fair: Use utilization distance to filter affine sync wakeups

On Wed, 2016-05-18 at 07:51 +0200, Mike Galbraith wrote: > On Mon, 2016-05-09 at 12:48 +0200, Peter Zijlstra wrote: > > Hai, > > (got some of the frozen variety handy?:) > > > here be a semi coherent patch series for the recent > > select_idle_siblings() > > tinkering. Happy benchmarking.. > >

Re: [RFC][PATCH 8/7] sched/fair: Use utilization distance to filter affine sync wakeups

On Wed, 2016-05-18 at 07:51 +0200, Mike Galbraith wrote: > On Mon, 2016-05-09 at 12:48 +0200, Peter Zijlstra wrote: > > Hai, > > (got some of the frozen variety handy?:) > > > here be a semi coherent patch series for the recent > > select_idle_siblings() > > tinkering. Happy benchmarking.. > >

Re: [PATCH] serial: 8250_early: Add earlycon support for Synopsys DesignWare ABP UART

On Thu, May 19, 2016 at 09:45:33AM +0800, Kefeng Wang wrote: > +Cc Jon and arm-kernel mailist > > Any comments, thanks. It works for me. Please feel free to add Tested-by: Jon Mason Thanks, Jon > > Kefeng > > On 2016/5/11 14:06, Kefeng Wang wrote: > > Some board

Re: [PATCH] serial: 8250_early: Add earlycon support for Synopsys DesignWare ABP UART

On Thu, May 19, 2016 at 09:45:33AM +0800, Kefeng Wang wrote: > +Cc Jon and arm-kernel mailist > > Any comments, thanks. It works for me. Please feel free to add Tested-by: Jon Mason Thanks, Jon > > Kefeng > > On 2016/5/11 14:06, Kefeng Wang wrote: > > Some board like Hisilicon D02 uses

[PULL REQUEST] i2c for 4.7

Linus, I2C updates for 4.7: * Peter Rosin did some major rework on the locking of i2c muxes by seperating parent-locked muxes and mux-locked muxes. This avoids deadlocks/workarounds when the mux itself needs i2c commands for muxing. And as a side-effect, other workarounds in the media

[PULL REQUEST] i2c for 4.7

Linus, I2C updates for 4.7: * Peter Rosin did some major rework on the locking of i2c muxes by seperating parent-locked muxes and mux-locked muxes. This avoids deadlocks/workarounds when the mux itself needs i2c commands for muxing. And as a side-effect, other workarounds in the media

Re: [PATCH v2 0/5] ACPI: ARM64: support for ACPI_TABLE_UPGRADE

4 > > It was first sent by Jon Masters [3] to linaro-acpi in December 2015 > > Tested on QEMU (arm64 and x86) and ThunderX > Should be applied to next-20160519 > > v2: > - add Acked-by: Lv Zheng <lv.zh...@intel.com> > - replace the original patch "ACPI: table

Re: [PATCH v2 0/5] ACPI: ARM64: support for ACPI_TABLE_UPGRADE

Masters [3] to linaro-acpi in December 2015 > > Tested on QEMU (arm64 and x86) and ThunderX > Should be applied to next-20160519 > > v2: > - add Acked-by: Lv Zheng > - replace the original patch "ACPI: table upgrade: move > early_initrd_acpi_init() > to header f

Re: [PATCH] usb: echi-hcd: Add ehci_setup check before echi_shutdown

On 19 May 2016 at 05:12, Srinivas Kandagatla wrote: > +++ b/drivers/usb/host/ehci-hcd.c > @@ -368,6 +368,15 @@ static void ehci_shutdown(struct usb_hcd *hcd) > { > struct ehci_hcd *ehci = hcd_to_ehci(hcd); > > + /** > +* Protect the system

Re: [PATCH] usb: echi-hcd: Add ehci_setup check before echi_shutdown

On 19 May 2016 at 05:12, Srinivas Kandagatla wrote: > +++ b/drivers/usb/host/ehci-hcd.c > @@ -368,6 +368,15 @@ static void ehci_shutdown(struct usb_hcd *hcd) > { > struct ehci_hcd *ehci = hcd_to_ehci(hcd); > > + /** > +* Protect the system from crashing at system

Re: [PATCH] ACPI / tables: Return error from table parse handler

On Thu, May 19, 2016 at 6:51 PM, Matthias Brugger wrote: > The handler called in acpi_table_parse may return an error. > This patch returns this error instead of ignoring it. And does it address any particular practical problem or is it just a code cleanup? > Signed-off-by:

Re: [PATCH] ACPI / tables: Return error from table parse handler

On Thu, May 19, 2016 at 6:51 PM, Matthias Brugger wrote: > The handler called in acpi_table_parse may return an error. > This patch returns this error instead of ignoring it. And does it address any particular practical problem or is it just a code cleanup? > Signed-off-by: Matthias Brugger >

Re: [PATCH v2 2/2] i2c: qup: support SMBus block read

Hi Timur, Sricharan, On 5/19/2016 2:21 PM, Timur Tabi wrote: Naveen Kaje wrote: +tags[len++] = QUP_TAG_V2_DATARD; +/* 0 implies 256 bytes */ +if (data_len == QUP_READ_LIMIT) +tags[len++] = 0; +else +tags[len++] = data_len; +}

Re: [PATCH v2 2/2] i2c: qup: support SMBus block read

Hi Timur, Sricharan, On 5/19/2016 2:21 PM, Timur Tabi wrote: Naveen Kaje wrote: +tags[len++] = QUP_TAG_V2_DATARD; +/* 0 implies 256 bytes */ +if (data_len == QUP_READ_LIMIT) +tags[len++] = 0; +else +tags[len++] = data_len; +}

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

On Thu, May 19, 2016 at 9:46 PM, Steve Muckle wrote: > On Thu, May 19, 2016 at 01:44:36AM +0200, Rafael J. Wysocki wrote: >> On Mon, May 9, 2016 at 11:20 PM, Steve Muckle >> wrote: >> > The rate limit timestamp (last_freq_update_time) is

Re: [PATCH 5/5] cpufreq: schedutil: do not update rate limit ts when freq is unchanged

On Thu, May 19, 2016 at 9:46 PM, Steve Muckle wrote: > On Thu, May 19, 2016 at 01:44:36AM +0200, Rafael J. Wysocki wrote: >> On Mon, May 9, 2016 at 11:20 PM, Steve Muckle >> wrote: >> > The rate limit timestamp (last_freq_update_time) is currently advanced >> > anytime schedutil re-evaluates

Re: [PATCH 4/5] cpufreq: schedutil: map raw required frequency to CPU-supported frequency

On Thu, May 19, 2016 at 9:35 PM, Steve Muckle wrote: > On Thu, May 19, 2016 at 01:37:40AM +0200, Rafael J. Wysocki wrote: >> On Mon, May 9, 2016 at 11:20 PM, Steve Muckle >> wrote: >> > The mechanisms for remote CPU updates and slow-path

Re: [PATCH 4/5] cpufreq: schedutil: map raw required frequency to CPU-supported frequency

On Thu, May 19, 2016 at 9:35 PM, Steve Muckle wrote: > On Thu, May 19, 2016 at 01:37:40AM +0200, Rafael J. Wysocki wrote: >> On Mon, May 9, 2016 at 11:20 PM, Steve Muckle >> wrote: >> > The mechanisms for remote CPU updates and slow-path frequency >> > transitions are relatively expensive - the

Re: [PATCH 3/5] sched: cpufreq: call cpufreq hook from remote CPUs

On Thu, May 19, 2016 at 9:19 PM, Steve Muckle wrote: > On Thu, May 19, 2016 at 02:00:54PM +0200, Rafael J. Wysocki wrote: >> On Thu, May 19, 2016 at 1:33 AM, Rafael J. Wysocki wrote: >> > On Mon, May 9, 2016 at 11:20 PM, Steve Muckle

Re: [PATCH 3/5] sched: cpufreq: call cpufreq hook from remote CPUs

On Thu, May 19, 2016 at 9:19 PM, Steve Muckle wrote: > On Thu, May 19, 2016 at 02:00:54PM +0200, Rafael J. Wysocki wrote: >> On Thu, May 19, 2016 at 1:33 AM, Rafael J. Wysocki wrote: >> > On Mon, May 9, 2016 at 11:20 PM, Steve Muckle >> > wrote: >> >> Without calling the cpufreq hook for a

Re: [PATCH] vfio: platform: use vfio_iommu_group_get/put

On Tue, 10 May 2016 15:40:28 +0800 Peng Fan wrote: > Hi Alex, > > On Mon, May 09, 2016 at 09:32:38AM -0600, Alex Williamson wrote: > >On Mon, 9 May 2016 18:01:43 +0800 > >Peng Fan wrote: > > > >> Use vfio_iommu_group_get and

Re: [PATCH] vfio: platform: use vfio_iommu_group_get/put

On Tue, 10 May 2016 15:40:28 +0800 Peng Fan wrote: > Hi Alex, > > On Mon, May 09, 2016 at 09:32:38AM -0600, Alex Williamson wrote: > >On Mon, 9 May 2016 18:01:43 +0800 > >Peng Fan wrote: > > > >> Use vfio_iommu_group_get and vfio_iommu_group_put, but not > >> iommu_group_get or

Re: [PATCH 1/3] MIPS: ralink: fix MT7628 pinmux typos

On 19/05/2016 22:07, Álvaro Fernández Rojas wrote: > Signed-off-by: Álvaro Fernández Rojas Hi Alvaro, I think my SoB is missing as i am the original author of these 3 patches. John > --- > arch/mips/ralink/mt7620.c | 4 ++-- > 1 file changed, 2 insertions(+), 2

Re: [PATCH 1/3] MIPS: ralink: fix MT7628 pinmux typos

On 19/05/2016 22:07, Álvaro Fernández Rojas wrote: > Signed-off-by: Álvaro Fernández Rojas Hi Alvaro, I think my SoB is missing as i am the original author of these 3 patches. John > --- > arch/mips/ralink/mt7620.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > >

Re: [PATCH 2/5] cpufreq: schedutil: support scheduler cpufreq callbacks on remote CPUs

On Thu, May 19, 2016 at 8:40 PM, Steve Muckle wrote: > On Thu, May 19, 2016 at 01:24:41AM +0200, Rafael J. Wysocki wrote: >> On Mon, May 9, 2016 at 11:20 PM, Steve Muckle >> wrote: >> > In preparation for the scheduler cpufreq callback happening

Re: [PATCH RFC] user-namespaced file capabilities - now with more magic

On Wed, 2016-05-18 at 16:57 -0500, Serge E. Hallyn wrote: > This patch introduces a new security.nscapability xattr. It > is mostly like security.capability, but also lists a 'rootid'. > This is the uid_t (in init_user_ns) of the root id (uid 0 in a > namespace) in whose namespaces the file

Re: [PATCH 2/5] cpufreq: schedutil: support scheduler cpufreq callbacks on remote CPUs

On Thu, May 19, 2016 at 8:40 PM, Steve Muckle wrote: > On Thu, May 19, 2016 at 01:24:41AM +0200, Rafael J. Wysocki wrote: >> On Mon, May 9, 2016 at 11:20 PM, Steve Muckle >> wrote: >> > In preparation for the scheduler cpufreq callback happening on remote >> > CPUs, add support for this in

Re: [PATCH RFC] user-namespaced file capabilities - now with more magic

On Wed, 2016-05-18 at 16:57 -0500, Serge E. Hallyn wrote: > This patch introduces a new security.nscapability xattr. It > is mostly like security.capability, but also lists a 'rootid'. > This is the uid_t (in init_user_ns) of the root id (uid 0 in a > namespace) in whose namespaces the file

Re: [PATCH] usb: echi-hcd: Add ehci_setup check before echi_shutdown

On 19 May 2016 at 05:12, Srinivas Kandagatla wrote: > This patch protects system from crashing at shutdown in > cases where usb host is not added yet from OTG controller driver. > As ehci_setup() not done yet, so stop accessing registers or > variables initialized

Re: [PATCH] usb: echi-hcd: Add ehci_setup check before echi_shutdown

On 19 May 2016 at 05:12, Srinivas Kandagatla wrote: > This patch protects system from crashing at shutdown in > cases where usb host is not added yet from OTG controller driver. > As ehci_setup() not done yet, so stop accessing registers or > variables initialized as part of ehci_setup(). > > The

Re: [PATCH v7 0/3] ASoC: cygnus: Add audio support for Broadcom Cygnus SoC

Looks good Simran. Mark, anything else for us to do before this driver can be accepted upstream? On 16-05-17 12:46 PM, Simran Rai wrote: From: Simran Hi, This patchset contains audio support for Broadcom's Cygnus SoC. It contains DT bindings

Re: [PATCH v7 0/3] ASoC: cygnus: Add audio support for Broadcom Cygnus SoC

Looks good Simran. Mark, anything else for us to do before this driver can be accepted upstream? On 16-05-17 12:46 PM, Simran Rai wrote: From: Simran Hi, This patchset contains audio support for Broadcom's Cygnus SoC. It contains DT bindings and core audio driver. The audio driver

Re: [PATCH v4 01/18] nbd: Fix might_sleep warning on xmit timeout

On Thu, May 19, 2016 at 11:52 AM, Markus Pargmann wrote: > Hi, > > On Wed, May 11, 2016 at 11:18:29AM +0300, Pranay Kr. Srivastava wrote: >> This patch fixes the warning generated when a timeout occurs >> on the request and socket is closed from a non-sleep context >> by >>

Re: [PATCH v4 01/18] nbd: Fix might_sleep warning on xmit timeout

On Thu, May 19, 2016 at 11:52 AM, Markus Pargmann wrote: > Hi, > > On Wed, May 11, 2016 at 11:18:29AM +0300, Pranay Kr. Srivastava wrote: >> This patch fixes the warning generated when a timeout occurs >> on the request and socket is closed from a non-sleep context >> by >> >> 1. Moving the

Re: [GIT PULL] ARC updates for 4.7-rc1

On Wed, May 18, 2016 at 11:24 PM, Vineet Gupta wrote: > > The highlight is support for EZChip (now Mellanox) NPS-400 network processor > [..] Oh, and that brought in the drivers/irqchip/irq-eznps.c driver that is compile-test enabled. And that driver is not

Re: [GIT PULL] ARC updates for 4.7-rc1

On Wed, May 18, 2016 at 11:24 PM, Vineet Gupta wrote: > > The highlight is support for EZChip (now Mellanox) NPS-400 network processor > [..] Oh, and that brought in the drivers/irqchip/irq-eznps.c driver that is compile-test enabled. And that driver is not 64-bit clean: In file

Re: [PATCH 3/4] rcutorture: Make -soundhw a x86 specific option

On Thu, May 19, 2016 at 12:38:47PM -0700, Paul E. McKenney wrote: > On Thu, May 19, 2016 at 09:23:39AM -0700, Paul E. McKenney wrote: > > On Thu, May 19, 2016 at 08:40:42AM -0700, Josh Triplett wrote: > > > On Thu, May 19, 2016 at 07:10:13AM -0700, Paul E. McKenney wrote: > > > > On Wed, May 18,

Re: [PATCH 3/4] rcutorture: Make -soundhw a x86 specific option

On Thu, May 19, 2016 at 12:38:47PM -0700, Paul E. McKenney wrote: > On Thu, May 19, 2016 at 09:23:39AM -0700, Paul E. McKenney wrote: > > On Thu, May 19, 2016 at 08:40:42AM -0700, Josh Triplett wrote: > > > On Thu, May 19, 2016 at 07:10:13AM -0700, Paul E. McKenney wrote: > > > > On Wed, May 18,

Re: [PATCH v2 2/2] i2c: qup: support SMBus block read

Naveen Kaje wrote: +tags[len++] = QUP_TAG_V2_DATARD; +/* 0 implies 256 bytes */ +if (data_len == QUP_READ_LIMIT) +tags[len++] = 0; +else +tags[len++] = data_len; +} Even data_len will always be '1' right ? Yes, but here

Re: [PATCH v2 2/2] i2c: qup: support SMBus block read

Naveen Kaje wrote: +tags[len++] = QUP_TAG_V2_DATARD; +/* 0 implies 256 bytes */ +if (data_len == QUP_READ_LIMIT) +tags[len++] = 0; +else +tags[len++] = data_len; +} Even data_len will always be '1' right ? Yes, but here

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

I ran the test given by Joonsoo and it gave me these minimum cycles per size across 20 usage: size,before,after 8,63.00,64.50 (102.38%) 16,64.50,65.00 (100.78%) 32,65.00,65.00 (100.00%) 64,66.00,65.00 (98.48%) 128,66.00,65.00 (98.48%) 256,64.00,64.00 (100.00%) 512,65.00,66.00 (101.54%)

Re: [RFC v1 2/2] mm: SLUB Freelist randomization

I ran the test given by Joonsoo and it gave me these minimum cycles per size across 20 usage: size,before,after 8,63.00,64.50 (102.38%) 16,64.50,65.00 (100.78%) 32,65.00,65.00 (100.00%) 64,66.00,65.00 (98.48%) 128,66.00,65.00 (98.48%) 256,64.00,64.00 (100.00%) 512,65.00,66.00 (101.54%)

Re: [PATCH] iio: light: jsa1212: remove unneeded i2c check functionality test

Reviewed-by: Matt Ranostay On Thu, May 19, 2016 at 11:37 AM, sathyanarayanan kuppuswamy wrote: > Looks Good. > > Reviewed-by:Kuppuswamy Sathyanarayanan > > > > On 05/15/2016 11:37

Re: [PATCH] iio: light: jsa1212: remove unneeded i2c check functionality test

Reviewed-by: Matt Ranostay On Thu, May 19, 2016 at 11:37 AM, sathyanarayanan kuppuswamy wrote: > Looks Good. > > Reviewed-by:Kuppuswamy Sathyanarayanan > > > > On 05/15/2016 11:37 AM, Alison Schofield wrote: >> >> This driver does not call i2c_smbus_read|write_byte_data(), >> so remove the

Re: [PATCH v3] dell-rbtn: Ignore ACPI notifications if device is suspended

On Thu, May 19, 2016 at 03:30:32PM +0200, Pali Rohár wrote: > On Monday 25 April 2016 22:06:11 Gabriele Mazzotta wrote: > > 2016-04-18 14:35 GMT+02:00 Pali Rohár : > > > On Tuesday 29 March 2016 15:11:35 Rafael J. Wysocki wrote: > > >> On Monday, March 28, 2016 10:33:09 AM

Re: [PATCH v3] dell-rbtn: Ignore ACPI notifications if device is suspended

On Thu, May 19, 2016 at 03:30:32PM +0200, Pali Rohár wrote: > On Monday 25 April 2016 22:06:11 Gabriele Mazzotta wrote: > > 2016-04-18 14:35 GMT+02:00 Pali Rohár : > > > On Tuesday 29 March 2016 15:11:35 Rafael J. Wysocki wrote: > > >> On Monday, March 28, 2016 10:33:09 AM Darren Hart wrote: > >

RE: ioatdma(Intel(R) I/OAT DMA Engine init failed)

> -Original Message- > From: Koul, Vinod > Sent: Thursday, May 19, 2016 10:23 AM > To: Jiang, Dave > Cc: Gavin Guo ; dmaeng...@vger.kernel.org; > linux-kernel@vger.kernel.org; Williams, Dan J > > Subject: Re:

RE: ioatdma(Intel(R) I/OAT DMA Engine init failed)

> -Original Message- > From: Koul, Vinod > Sent: Thursday, May 19, 2016 10:23 AM > To: Jiang, Dave > Cc: Gavin Guo ; dmaeng...@vger.kernel.org; > linux-kernel@vger.kernel.org; Williams, Dan J > > Subject: Re: ioatdma(Intel(R) I/OAT DMA Engine init failed) > > On Thu, May 19, 2016 at

Re: [PATCH v2 1/2] i2c: qup: add ACPI support

Hi Sricharan, On 5/18/2016 12:04 AM, Sricharan wrote: Hi, Add support to get the device parameters from ACPI. Assume that the clocks are managed by firmware. Signed-off-by: Naveen Kaje --- drivers/i2c/busses/i2c-qup.c | 59 +---

Re: [PATCH v2 2/2] i2c: qup: support SMBus block read

Hi Sricharan, On 5/18/2016 1:06 AM, Sricharan wrote: Hi, +static bool qup_i2c_check_msg_len(struct i2c_msg *msg) { + return ((msg->flags & I2C_M_RD) && (msg->flags & I2C_M_RECV_LEN)); } + +static int qup_i2c_set_tags_smb(u16 addr, u8 *tags, struct qup_i2c_dev *qup, +

Re: [PATCH v2 1/2] i2c: qup: add ACPI support

Hi Sricharan, On 5/18/2016 12:04 AM, Sricharan wrote: Hi, Add support to get the device parameters from ACPI. Assume that the clocks are managed by firmware. Signed-off-by: Naveen Kaje --- drivers/i2c/busses/i2c-qup.c | 59 +--- 1 file changed, 44

Re: [PATCH v2 2/2] i2c: qup: support SMBus block read

Hi Sricharan, On 5/18/2016 1:06 AM, Sricharan wrote: Hi, +static bool qup_i2c_check_msg_len(struct i2c_msg *msg) { + return ((msg->flags & I2C_M_RD) && (msg->flags & I2C_M_RECV_LEN)); } + +static int qup_i2c_set_tags_smb(u16 addr, u8 *tags, struct qup_i2c_dev *qup, +

Re: UBSAN whinge in ihci-hub.c

On Thu, 19 May 2016, Andrey Ryabinin wrote: > 2016-05-18 22:28 GMT+03:00 Alan Stern : > > On Wed, 18 May 2016, Andrey Ryabinin wrote: > > > >> 2016-05-18 19:09 GMT+03:00 Alan Stern : > >> > On Wed, 18 May 2016, Andrey Ryabinin wrote: > >> > >

Re: UBSAN whinge in ihci-hub.c

On Thu, 19 May 2016, Andrey Ryabinin wrote: > 2016-05-18 22:28 GMT+03:00 Alan Stern : > > On Wed, 18 May 2016, Andrey Ryabinin wrote: > > > >> 2016-05-18 19:09 GMT+03:00 Alan Stern : > >> > On Wed, 18 May 2016, Andrey Ryabinin wrote: > >> > > >> >> 2016-05-18 17:40 GMT+03:00 Alan Stern : > >> >>

<    1   2   3   4   5   6   7   8   9   10   >