Applied "ASoC: es8328: Fix ADC format setup" to the asoc tree

The patch ASoC: es8328: Fix ADC format setup has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus

Applied "ASoC: es8328: Fix ADC format setup" to the asoc tree

The patch ASoC: es8328: Fix ADC format setup has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus

Applied "ASoC: rockchip-max98090: Fix NULL pointer dereference while accessing to jack." to the asoc tree

The patch ASoC: rockchip-max98090: Fix NULL pointer dereference while accessing to jack. has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime

Applied "ASoC: rockchip-max98090: Fix NULL pointer dereference while accessing to jack." to the asoc tree

The patch ASoC: rockchip-max98090: Fix NULL pointer dereference while accessing to jack. has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime

Applied "ASoC: rockchip-max98090: Fix jack detection and event reporting." to the asoc tree

The patch ASoC: rockchip-max98090: Fix jack detection and event reporting. has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "ASoC: rockchip-max98090: Fix jack detection and event reporting." to the asoc tree

The patch ASoC: rockchip-max98090: Fix jack detection and event reporting. has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "ASoC: rockchip-max98090: Fix the Headset Mic route." to the asoc tree

The patch ASoC: rockchip-max98090: Fix the Headset Mic route. has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Re: [PATCH v2 4/8] powerpc: add io{read,write}64 accessors

On 05/09/2016 03:20 AM, Horia Ioan Geanta Neag wrote: > On 5/5/2016 6:37 PM, Horia Geantă wrote: >> This will allow device drivers to consistently use io{read,write}XX >> also for 64-bit accesses. >> >> Signed-off-by: Horia Geantă > > It would be great if PPC maintainers

Applied "ASoC: rockchip-max98090: Fix the Headset Mic route." to the asoc tree

The patch ASoC: rockchip-max98090: Fix the Headset Mic route. has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Re: [PATCH v2 4/8] powerpc: add io{read,write}64 accessors

On 05/09/2016 03:20 AM, Horia Ioan Geanta Neag wrote: > On 5/5/2016 6:37 PM, Horia Geantă wrote: >> This will allow device drivers to consistently use io{read,write}XX >> also for 64-bit accesses. >> >> Signed-off-by: Horia Geantă > > It would be great if PPC maintainers could Ack this patch. >

Applied "ASoC: es8328: Fix mask for VMIDSEL" to the asoc tree

The patch ASoC: es8328: Fix mask for VMIDSEL has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus

Applied "ASoC: es8328: Move clock setup to hw_params" to the asoc tree

The patch ASoC: es8328: Move clock setup to hw_params has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to

[PATCH v6 1/5] dax: fallback from pmd to pte on error

From: Dan Williams In preparation for consulting a badblocks list in pmem_direct_access(), teach dax_pmd_fault() to fallback rather than fail immediately upon encountering an error. The thought being that reducing the span of the dax request may avoid the error region.

[PATCH v6 1/5] dax: fallback from pmd to pte on error

From: Dan Williams In preparation for consulting a badblocks list in pmem_direct_access(), teach dax_pmd_fault() to fallback rather than fail immediately upon encountering an error. The thought being that reducing the span of the dax request may avoid the error region. Reviewed-by: Jeff Moyer

Applied "ASoC: es8328: Fix mask for VMIDSEL" to the asoc tree

The patch ASoC: es8328: Fix mask for VMIDSEL has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus

Applied "ASoC: es8328: Move clock setup to hw_params" to the asoc tree

The patch ASoC: es8328: Move clock setup to hw_params has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to

Re: [PATCH v3 4/4] x86, boot: Memory hotplug support for KASLR memory randomization

On Tue, May 10, 2016 at 11:24 AM, Kees Cook wrote: > On Tue, May 3, 2016 at 12:31 PM, Thomas Garnier wrote: >> Add a new option (CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING) to define >> the padding used for the physical memory mapping section when KASLR

Applied "ASoC: es8328: Set symmetric rates" to the asoc tree

The patch ASoC: es8328: Set symmetric rates has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during

Re: [PATCH v3 4/4] x86, boot: Memory hotplug support for KASLR memory randomization

On Tue, May 10, 2016 at 11:24 AM, Kees Cook wrote: > On Tue, May 3, 2016 at 12:31 PM, Thomas Garnier wrote: >> Add a new option (CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING) to define >> the padding used for the physical memory mapping section when KASLR >> memory is enabled. It ensures there is

Applied "ASoC: es8328: Set symmetric rates" to the asoc tree

The patch ASoC: es8328: Set symmetric rates has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during

Applied "ASoC: da7213: Update PLL ranges to improve locking at frequency boundary" to the asoc tree

The patch ASoC: da7213: Update PLL ranges to improve locking at frequency boundary has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the

Applied "ASoC: da7213: Update PLL ranges to improve locking at frequency boundary" to the asoc tree

The patch ASoC: da7213: Update PLL ranges to improve locking at frequency boundary has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the

Re: [PATCH 2/5] remoteproc: core: Add rproc OF look-up functions

On Tue 10 May 07:16 PDT 2016, Lee Jones wrote: > On Fri, 06 May 2016, Bjorn Andersson wrote: > > > On Thu 05 May 06:29 PDT 2016, Lee Jones wrote: > > > > > - of_rproc_byindex(): look-up and obtain a reference to a rproc > > > using the DT phandle "rprocs" and a index. >

Re: [PATCH 2/5] remoteproc: core: Add rproc OF look-up functions

On Tue 10 May 07:16 PDT 2016, Lee Jones wrote: > On Fri, 06 May 2016, Bjorn Andersson wrote: > > > On Thu 05 May 06:29 PDT 2016, Lee Jones wrote: > > > > > - of_rproc_byindex(): look-up and obtain a reference to a rproc > > > using the DT phandle "rprocs" and a index. >

Re: [PATCH] [media] v4l2-async: Pass the v4l2_async_subdev to the unbind callback

Hi Alban, On Tue, May 10, 2016 at 03:19:14PM +0200, Alban Bedel wrote: > v4l2_async_cleanup() is always called before before calling the s/before // > unbind() callback. However v4l2_async_cleanup() clear the asd member, s/clear/clears/ > so when calling the unbind() callback the

Re: [PATCH] [media] v4l2-async: Pass the v4l2_async_subdev to the unbind callback

Hi Alban, On Tue, May 10, 2016 at 03:19:14PM +0200, Alban Bedel wrote: > v4l2_async_cleanup() is always called before before calling the s/before // > unbind() callback. However v4l2_async_cleanup() clear the asd member, s/clear/clears/ > so when calling the unbind() callback the

Re: [PATCH V7 07/11] pci, acpi: Handle ACPI companion assignment.

On Tue, May 10, 2016 at 8:37 PM, Rafael J. Wysocki wrote: > On Tue, May 10, 2016 at 5:19 PM, Tomasz Nowicki wrote: >> This patch provides a way to set the ACPI companion in PCI code. >> We define acpi_pci_set_companion() to set the ACPI companion pointer and

Re: [PATCH V7 07/11] pci, acpi: Handle ACPI companion assignment.

On Tue, May 10, 2016 at 8:37 PM, Rafael J. Wysocki wrote: > On Tue, May 10, 2016 at 5:19 PM, Tomasz Nowicki wrote: >> This patch provides a way to set the ACPI companion in PCI code. >> We define acpi_pci_set_companion() to set the ACPI companion pointer and >> call it from PCI core code. The

Re: [PATCH v3 0/2] Net driver bugs fix

From: Elad Kanfi Date: Mon, 9 May 2016 20:13:18 +0300 > Summary: > 1. Bug description: TX done interrupts that arrives while interrupts > are masked, during NAPI poll, will not trigger an interrupt handling. > Since TX interrupt is of level edge we will lose the TX

Re: [PATCH v3 0/2] Net driver bugs fix

From: Elad Kanfi Date: Mon, 9 May 2016 20:13:18 +0300 > Summary: > 1. Bug description: TX done interrupts that arrives while interrupts > are masked, during NAPI poll, will not trigger an interrupt handling. > Since TX interrupt is of level edge we will lose the TX done interrupt. >

Re: linux-next: build failure after merge of the net-next tree

On Mon 09 May 18:29 PDT 2016, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > net/qrtr/smd.c:106:14: error: initialization from incompatible pointer type > [-Werror=incompatible-pointer-types] >

Re: linux-next: build failure after merge of the net-next tree

On Mon 09 May 18:29 PDT 2016, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > net/qrtr/smd.c:106:14: error: initialization from incompatible pointer type > [-Werror=incompatible-pointer-types] >

Re: [PATCH V7 07/11] pci, acpi: Handle ACPI companion assignment.

On Tue, May 10, 2016 at 5:19 PM, Tomasz Nowicki wrote: > This patch provides a way to set the ACPI companion in PCI code. > We define acpi_pci_set_companion() to set the ACPI companion pointer and > call it from PCI core code. The function is stub for now. > > Signed-off-by:

Re: [PATCH V7 07/11] pci, acpi: Handle ACPI companion assignment.

On Tue, May 10, 2016 at 5:19 PM, Tomasz Nowicki wrote: > This patch provides a way to set the ACPI companion in PCI code. > We define acpi_pci_set_companion() to set the ACPI companion pointer and > call it from PCI core code. The function is stub for now. > > Signed-off-by: Jayachandran C >

Re: [PATCH v2 1/2] net: nps_enet: Sync access to packet sent flag

Hi Elad, On 08.05.2016 15:44, Elad Kanfi wrote: > > After reviewing the code and your suggestion, it seems that we can do without > the flag tx_packet_sent and therefor the first issue becomes irrelevant. > The indication that a packet was sent is (tx_skb != NULL) , and the sequence > will

Re: [PATCH v2 1/2] net: nps_enet: Sync access to packet sent flag

Hi Elad, On 08.05.2016 15:44, Elad Kanfi wrote: > > After reviewing the code and your suggestion, it seems that we can do without > the flag tx_packet_sent and therefor the first issue becomes irrelevant. > The indication that a packet was sent is (tx_skb != NULL) , and the sequence > will

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On 04/28/2016 03:12 PM, Sergei Shtylyov wrote: > The PHY devices sometimes do have their reset signal (maybe even power > supply?) tied to some GPIO and sometimes it also does happen that a boot > loader does not leave it deasserted. So far this issue has been attacked > from (as I believe) a

Re: [PATCH RFT 1/2] phylib: add device reset GPIO support

On 04/28/2016 03:12 PM, Sergei Shtylyov wrote: > The PHY devices sometimes do have their reset signal (maybe even power > supply?) tied to some GPIO and sometimes it also does happen that a boot > loader does not leave it deasserted. So far this issue has been attacked > from (as I believe) a

Re: [PATCH net] drivers: net: Don't print unpopulated net_device name

On Tue, 10 May 2016 17:43:21 +0100 Harvey Hunt wrote: > For ethernet devices, net_device.name will be eth%d before > register_netdev() is called. Don't print the net_device name until > the format string is replaced. > > Cc: Robert Jarzmik > Cc:

Re: [PATCH net] drivers: net: Don't print unpopulated net_device name

On Tue, 10 May 2016 17:43:21 +0100 Harvey Hunt wrote: > For ethernet devices, net_device.name will be eth%d before > register_netdev() is called. Don't print the net_device name until > the format string is replaced. > > Cc: Robert Jarzmik > Cc: Barry Song > Cc: Marcel Ziswiler > Cc:

[PATCH] ARM: dts: exynos: Replace deprecated hsi2c compatible on Exynos5420

Since commit 218e1496135e ("i2c: exynos5: add support for HSI2C on Exynos5260 SoC") the "samsung,exynos5-hsi2c" is deprecated in favor of SoC version specific: "samsung,exynos5250-hsi2c". Signed-off-by: Krzysztof Kozlowski --- arch/arm/boot/dts/exynos5420.dtsi | 14

[PATCH] ARM: dts: exynos: Replace deprecated hsi2c compatible on Exynos5420

Since commit 218e1496135e ("i2c: exynos5: add support for HSI2C on Exynos5260 SoC") the "samsung,exynos5-hsi2c" is deprecated in favor of SoC version specific: "samsung,exynos5250-hsi2c". Signed-off-by: Krzysztof Kozlowski --- arch/arm/boot/dts/exynos5420.dtsi | 14 +++--- 1 file

[PATCH 1/1] arm64: Add ARM64 optimized IP checksum routine

This change implements an optimized checksum for arm64, based loosely on the original arch/arm implementation. Load-pair is used for the initial 16B load, reducing the overall number of loads to two for packets without IP options. Instruction count is reduced by ~3x compared to generic C

[PATCH 1/1] arm64: Add ARM64 optimized IP checksum routine

This change implements an optimized checksum for arm64, based loosely on the original arch/arm implementation. Load-pair is used for the initial 16B load, reducing the overall number of loads to two for packets without IP options. Instruction count is reduced by ~3x compared to generic C

Re: [PATCH v3 4/4] x86, boot: Memory hotplug support for KASLR memory randomization

On Tue, May 3, 2016 at 12:31 PM, Thomas Garnier wrote: > Add a new option (CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING) to define > the padding used for the physical memory mapping section when KASLR > memory is enabled. It ensures there is enough virtual address space when >

Re: [PATCH v3 4/4] x86, boot: Memory hotplug support for KASLR memory randomization

On Tue, May 3, 2016 at 12:31 PM, Thomas Garnier wrote: > Add a new option (CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING) to define > the padding used for the physical memory mapping section when KASLR > memory is enabled. It ensures there is enough virtual address space when > CONFIG_MEMORY_HOTPLUG

Re: [PATCH 2/5] ASoC: da7213: Add checking of SRM lock status before enabling DAI

On Tue, May 10, 2016 at 07:21:43PM +0100, Mark Brown wrote: > On Tue, May 10, 2016 at 04:11:05PM +0100, Adam Thomson wrote: > > > + /* Slave mode, if SRM not enabled no need for status checks */ > > + pll_ctrl = snd_soc_read(codec, DA7213_PLL_CTRL); > > + if

Re: [PATCH 2/5] ASoC: da7213: Add checking of SRM lock status before enabling DAI

On Tue, May 10, 2016 at 07:21:43PM +0100, Mark Brown wrote: > On Tue, May 10, 2016 at 04:11:05PM +0100, Adam Thomson wrote: > > > + /* Slave mode, if SRM not enabled no need for status checks */ > > + pll_ctrl = snd_soc_read(codec, DA7213_PLL_CTRL); > > + if

Re: [PATCH 2/5] ASoC: da7213: Add checking of SRM lock status before enabling DAI

On Tue, May 10, 2016 at 04:11:05PM +0100, Adam Thomson wrote: > + /* Slave mode, if SRM not enabled no need for status checks */ > + pll_ctrl = snd_soc_read(codec, DA7213_PLL_CTRL); > + if (!(pll_ctrl & DA7213_PLL_SRM_EN)) > + return 0;

Re: [PATCH 2/5] ASoC: da7213: Add checking of SRM lock status before enabling DAI

On Tue, May 10, 2016 at 04:11:05PM +0100, Adam Thomson wrote: > + /* Slave mode, if SRM not enabled no need for status checks */ > + pll_ctrl = snd_soc_read(codec, DA7213_PLL_CTRL); > + if (!(pll_ctrl & DA7213_PLL_SRM_EN)) > + return 0;

Re: Getting rid of dynamic TASK_SIZE (on x86, at least)

On 05/10, Andy Lutomirski wrote: > > - xol_add_vma: This one is weird: uprobes really is doing something > behind the task's back, and the addresses need to be consistent with > the address width. I'm not quite sure what to do here. It can use mm->task_size instead, plus this is just a hint.

Re: [PATCH V7 05/11] acpi, pci: Support IO resources when parsing PCI host bridge resources.

On Tue, May 10, 2016 at 5:19 PM, Tomasz Nowicki wrote: > Platforms that have memory mapped IO port (such as ARM64) need special > handling for PCI I/O resources. For host bridge's resource probing case > these resources need to be fixed up with >

Re: Getting rid of dynamic TASK_SIZE (on x86, at least)

On 05/10, Andy Lutomirski wrote: > > - xol_add_vma: This one is weird: uprobes really is doing something > behind the task's back, and the addresses need to be consistent with > the address width. I'm not quite sure what to do here. It can use mm->task_size instead, plus this is just a hint.

Re: [PATCH V7 05/11] acpi, pci: Support IO resources when parsing PCI host bridge resources.

On Tue, May 10, 2016 at 5:19 PM, Tomasz Nowicki wrote: > Platforms that have memory mapped IO port (such as ARM64) need special > handling for PCI I/O resources. For host bridge's resource probing case > these resources need to be fixed up with > pci_register_io_range/pci_remap_iospace etc. > >

Re: [PATCH] sched/fair: Fix the wrong throttled clock time for cfs_rq_clock_task()

Xunlei Pang writes: > Two minor fixes for cfs_rq_clock_task(). > 1) If cfs_rq is currently being throttled, we need to subtract the cfs >throttled clock time. > > 2) Make "throttled_clock_task_time" update SMP unrelated. Now UP cases >need it as well. > >

Re: [PATCH] sched/fair: Fix the wrong throttled clock time for cfs_rq_clock_task()

Xunlei Pang writes: > Two minor fixes for cfs_rq_clock_task(). > 1) If cfs_rq is currently being throttled, we need to subtract the cfs >throttled clock time. > > 2) Make "throttled_clock_task_time" update SMP unrelated. Now UP cases >need it as well. > > Signed-off-by: Xunlei Pang >

Re: [PATCH V7 08/11] pci, acpi: Support for ACPI based generic PCI host controller

On Tue, May 10, 2016 at 5:19 PM, Tomasz Nowicki wrote: > This patch is going to implement generic PCI host controller for > ACPI world, similar to what pci-host-generic.c driver does for DT world. > > All such drivers, which we have seen so far, were implemented within > arch/

Re: [PATCH V7 08/11] pci, acpi: Support for ACPI based generic PCI host controller

On Tue, May 10, 2016 at 5:19 PM, Tomasz Nowicki wrote: > This patch is going to implement generic PCI host controller for > ACPI world, similar to what pci-host-generic.c driver does for DT world. > > All such drivers, which we have seen so far, were implemented within > arch/ directory since

Re: [PATCH 2/7] net: ircomm, cleanup TIOCGSERIAL

From: Jiri Slaby Date: Mon, 9 May 2016 09:11:54 +0200 > In ircomm_tty_get_serial_info, struct serial_struct is memset to 0 and > then some members set to 0 explicitly. > > Remove the latter as it is obviously superfluous. > > And remove the retinfo check against NULL.

Re: [PATCH 2/7] net: ircomm, cleanup TIOCGSERIAL

From: Jiri Slaby Date: Mon, 9 May 2016 09:11:54 +0200 > In ircomm_tty_get_serial_info, struct serial_struct is memset to 0 and > then some members set to 0 explicitly. > > Remove the latter as it is obviously superfluous. > > And remove the retinfo check against NULL. copy_to_user will take

[PATCH] mmc: dw_mmc: rockchip: Set the drive phase to 180 degrees

Historically for Rockchip devices we've relied on the power-on default (or perhaps the firmware setting) to get the correct drive phase for dw_mmc devices. This worked OK for the most part, but: * Relying on the setting just "being right" is a bit fragile. * As soon as there is an instance

[PATCH] mmc: dw_mmc: rockchip: Set the drive phase to 180 degrees

Historically for Rockchip devices we've relied on the power-on default (or perhaps the firmware setting) to get the correct drive phase for dw_mmc devices. This worked OK for the most part, but: * Relying on the setting just "being right" is a bit fragile. * As soon as there is an instance

Re: [PATCH 2/3] memory-hotplug: more general validation of zone during online

On Mon, 9 May 2016 12:53:38 -0500 Reza Arbab wrote: > When memory is onlined, we are only able to rezone from ZONE_MOVABLE to > ZONE_KERNEL, or from (ZONE_MOVABLE - 1) to ZONE_MOVABLE. > > To be more flexible, use the following criteria instead; to online memory >

Re: [PATCH 2/3] memory-hotplug: more general validation of zone during online

On Mon, 9 May 2016 12:53:38 -0500 Reza Arbab wrote: > When memory is onlined, we are only able to rezone from ZONE_MOVABLE to > ZONE_KERNEL, or from (ZONE_MOVABLE - 1) to ZONE_MOVABLE. > > To be more flexible, use the following criteria instead; to online memory > from zone X into zone Y, >

Re: [PATCH 02/11] irqdomain: Warn if we fail to set the IRQ type

On 10/05/16 19:00, Jon Hunter wrote: > > On 10/05/16 18:25, Marc Zyngier wrote: >> On 10/05/16 16:14, Jon Hunter wrote: >>> When setting the IRQ type we don't check the return value to see if it >>> is set correctly. Due to this, failures to set the IRQ type have gone >>> unnoticed and because

Re: [PATCH 02/11] irqdomain: Warn if we fail to set the IRQ type

On 10/05/16 19:00, Jon Hunter wrote: > > On 10/05/16 18:25, Marc Zyngier wrote: >> On 10/05/16 16:14, Jon Hunter wrote: >>> When setting the IRQ type we don't check the return value to see if it >>> is set correctly. Due to this, failures to set the IRQ type have gone >>> unnoticed and because

Re: [PATCH 02/11] irqdomain: Warn if we fail to set the IRQ type

On 10/05/16 18:25, Marc Zyngier wrote: > On 10/05/16 16:14, Jon Hunter wrote: >> When setting the IRQ type we don't check the return value to see if it >> is set correctly. Due to this, failures to set the IRQ type have gone >> unnoticed and because these failures were not catastrophic have not

Re: [PATCH 02/11] irqdomain: Warn if we fail to set the IRQ type

On 10/05/16 18:25, Marc Zyngier wrote: > On 10/05/16 16:14, Jon Hunter wrote: >> When setting the IRQ type we don't check the return value to see if it >> is set correctly. Due to this, failures to set the IRQ type have gone >> unnoticed and because these failures were not catastrophic have not

Re: [PATCH V7 03/11] pci, of: Move the PCI I/O space management to PCI core code.

On Tue, May 10, 2016 at 5:19 PM, Tomasz Nowicki wrote: > No functional changes in this patch. > > PCI I/O space mapping code does not depend on OF, therefore it can be > moved to PCI core code. This way we will be able to use it > e.g. in ACPI PCI code. > > Suggested-by:

Re: [PATCH V7 03/11] pci, of: Move the PCI I/O space management to PCI core code.

On Tue, May 10, 2016 at 5:19 PM, Tomasz Nowicki wrote: > No functional changes in this patch. > > PCI I/O space mapping code does not depend on OF, therefore it can be > moved to PCI core code. This way we will be able to use it > e.g. in ACPI PCI code. > > Suggested-by: Lorenzo Pieralisi >

Re: [PATCH 5/9] ASoC: es8328: Use more suitable definition for mic bias

On Mon, May 09, 2016 at 12:24:33PM +0100, John Keeping wrote: > - SND_SOC_DAPM_SUPPLY("Mic Bias", ES8328_ADCPOWER, > - ES8328_ADCPOWER_MIC_BIAS_OFF, 1, NULL, 0), > + SND_SOC_DAPM_MICBIAS("Mic Bias", ES8328_ADCPOWER, > + ES8328_ADCPOWER_MIC_BIAS_OFF,

Re: [PATCH 5/9] ASoC: es8328: Use more suitable definition for mic bias

On Mon, May 09, 2016 at 12:24:33PM +0100, John Keeping wrote: > - SND_SOC_DAPM_SUPPLY("Mic Bias", ES8328_ADCPOWER, > - ES8328_ADCPOWER_MIC_BIAS_OFF, 1, NULL, 0), > + SND_SOC_DAPM_MICBIAS("Mic Bias", ES8328_ADCPOWER, > + ES8328_ADCPOWER_MIC_BIAS_OFF,

[PATCH] arm64: kernel: Fix incorrect brk randomization

This fixes two issues with the arm64 brk randomziation. First, the STACK_RND_MASK was being used incorrectly. The original code was: unsigned long range_end = base + (STACK_RND_MASK << PAGE_SHIFT) + 1; STACK_RND_MASK is 0x7ff (32-bit) or 0x3 (64-bit), with 4K pages where PAGE_SHIFT

[PATCH] arm64: kernel: Fix incorrect brk randomization

This fixes two issues with the arm64 brk randomziation. First, the STACK_RND_MASK was being used incorrectly. The original code was: unsigned long range_end = base + (STACK_RND_MASK << PAGE_SHIFT) + 1; STACK_RND_MASK is 0x7ff (32-bit) or 0x3 (64-bit), with 4K pages where PAGE_SHIFT

Re: [PATCH V7 08/11] pci, acpi: Support for ACPI based generic PCI host controller

On Tue, May 10, 2016 at 5:19 PM, Tomasz Nowicki wrote: > This patch is going to implement generic PCI host controller for > ACPI world, similar to what pci-host-generic.c driver does for DT world. > > All such drivers, which we have seen so far, were implemented within > arch/

Re: [PATCH V7 08/11] pci, acpi: Support for ACPI based generic PCI host controller

On Tue, May 10, 2016 at 5:19 PM, Tomasz Nowicki wrote: > This patch is going to implement generic PCI host controller for > ACPI world, similar to what pci-host-generic.c driver does for DT world. > > All such drivers, which we have seen so far, were implemented within > arch/ directory since

[PATCH 3/3] sched: Kill sched_class::task_waking

With sched_class::task_waking being called only when we do set_task_cpu(), we can make sched_class::migrate_task_rq() do the work and eliminate sched_class::task_waking entirely. Cc: Pavan Kondeti Cc: Ben Segall Cc: Matt Fleming

Re: [PATCH] mmc: tegra: Disable UHS-I modes for tegra30

On 05/10/2016 11:16 AM, Jon Hunter wrote: On 10/05/16 17:34, Stephen Warren wrote: On 05/10/2016 10:13 AM, Jon Hunter wrote: [snip] Stephen, for your u-boot testing, do you are set the bit in the vendor misc register to enable version 3.0 support for sdhci on tegra30? This is what the

[PATCH 3/3] sched: Kill sched_class::task_waking

With sched_class::task_waking being called only when we do set_task_cpu(), we can make sched_class::migrate_task_rq() do the work and eliminate sched_class::task_waking entirely. Cc: Pavan Kondeti Cc: Ben Segall Cc: Matt Fleming Cc: Mike Galbraith Cc: Morten Rasmussen Cc: Paul Turner Cc:

Re: [PATCH] mmc: tegra: Disable UHS-I modes for tegra30

On 05/10/2016 11:16 AM, Jon Hunter wrote: On 10/05/16 17:34, Stephen Warren wrote: On 05/10/2016 10:13 AM, Jon Hunter wrote: [snip] Stephen, for your u-boot testing, do you are set the bit in the vendor misc register to enable version 3.0 support for sdhci on tegra30? This is what the

[PATCH 2/3] sched,fair: Fix local starvation

Mike reported that the recent commit 3a47d5124a95 ("sched/fair: Fix fairness issue on migration") broke interactivity and the signal starve test. The problem is that I assumed ENQUEUE_WAKING was only set when we do a cross-cpu wakeup (migration), which isn't true. This means we now destroy the

[PATCH 2/3] sched,fair: Fix local starvation

Mike reported that the recent commit 3a47d5124a95 ("sched/fair: Fix fairness issue on migration") broke interactivity and the signal starve test. The problem is that I assumed ENQUEUE_WAKING was only set when we do a cross-cpu wakeup (migration), which isn't true. This means we now destroy the

[PATCH 1/3] sched,fair: Move record_wakee()

Since I want to make ->task_woken() conditional on the task getting migrated, we cannot use it to call record_wakee(). Move it to select_task_rq_fair(), which gets called in almost all the same conditions. The only exception is if the woken task (@p) is cpu-bound (as per the nr_cpus_allowed test

[PATCH 1/3] sched,fair: Move record_wakee()

Since I want to make ->task_woken() conditional on the task getting migrated, we cannot use it to call record_wakee(). Move it to select_task_rq_fair(), which gets called in almost all the same conditions. The only exception is if the woken task (@p) is cpu-bound (as per the nr_cpus_allowed test

[PATCH 0/3] sched: Fix wakeup preemption regression

A recent commit caused an interactivity/starvation issue because we wrecked rq local wakeup preemption. These patches rectify this while also (hopefully) keeping the problem that led to the fault patch fixed. Mike, Pavan, could you guys please confirm?

Re: Getting rid of dynamic TASK_SIZE (on x86, at least)

On Tue, May 10, 2016 at 10:26:05AM -0700, Andy Lutomirski wrote: ... > >> > >> It's annoying and ugly. It also makes the idea of doing 32-bit CRIU > >> restore by starting in 64-bit mode and switching to 32-bit more > >> complicated because it requires switching TASK_SIZE. > > > > Well, you know

Re: Getting rid of dynamic TASK_SIZE (on x86, at least)

On Tue, May 10, 2016 at 10:26:05AM -0700, Andy Lutomirski wrote: ... > >> > >> It's annoying and ugly. It also makes the idea of doing 32-bit CRIU > >> restore by starting in 64-bit mode and switching to 32-bit more > >> complicated because it requires switching TASK_SIZE. > > > > Well, you know

[PATCH 0/3] sched: Fix wakeup preemption regression

A recent commit caused an interactivity/starvation issue because we wrecked rq local wakeup preemption. These patches rectify this while also (hopefully) keeping the problem that led to the fault patch fixed. Mike, Pavan, could you guys please confirm?

Re: [PATCH 00/12] TLB/XPA fixes & cleanups

On 05/10/2016 05:44 AM, Ralf Baechle wrote: > On Fri, Apr 15, 2016 at 11:36:48AM +0100, Paul Burton wrote: > >> This series fixes up a number of issues introduced by commit >> c5b367835cfc ("MIPS: Add support for XPA."), including breakage of the >> MIPS32 with 36 bit physical addressing case &

Re: [PATCH 00/12] TLB/XPA fixes & cleanups

On 05/10/2016 05:44 AM, Ralf Baechle wrote: > On Fri, Apr 15, 2016 at 11:36:48AM +0100, Paul Burton wrote: > >> This series fixes up a number of issues introduced by commit >> c5b367835cfc ("MIPS: Add support for XPA."), including breakage of the >> MIPS32 with 36 bit physical addressing case &

[PATCH 1/3] cpuacct: Merge cpuacct_usage_index and cpuacct_usage_index

These two types have similar function. No need to separate them. Signed-off-by: Zhao Lei --- kernel/sched/cpuacct.c | 47 --- 1 file changed, 20 insertions(+), 27 deletions(-) diff --git a/kernel/sched/cpuacct.c

[PATCH 1/3] cpuacct: Merge cpuacct_usage_index and cpuacct_usage_index

These two types have similar function. No need to separate them. Signed-off-by: Zhao Lei --- kernel/sched/cpuacct.c | 47 --- 1 file changed, 20 insertions(+), 27 deletions(-) diff --git a/kernel/sched/cpuacct.c b/kernel/sched/cpuacct.c index

[PATCH 3/3] cpuacct: Show all detail stats in one file

In current code, we can get cpuacct data from severial files, but each file have its lilmit. For example: we can get cpu usage in user and kernel mode by cpuacct.stat, but we can't get detail data of each cpu in above file. we can get each cpu's kernel mode usage in cpuacct.usage_percpu_sys, but

[PATCH 3/3] cpuacct: Show all detail stats in one file

In current code, we can get cpuacct data from severial files, but each file have its lilmit. For example: we can get cpu usage in user and kernel mode by cpuacct.stat, but we can't get detail data of each cpu in above file. we can get each cpu's kernel mode usage in cpuacct.usage_percpu_sys, but

[PATCH 2/3] cpuacct: Simplify cpuacct_stats_show

Merge code for each cpustat(system/user) into a loop, to avoid clone of code blocks. Only a little cleanup. Signed-off-by: Zhao Lei --- kernel/sched/cpuacct.c | 29 ++--- 1 file changed, 14 insertions(+), 15 deletions(-) diff --git

[PATCH 0/3] cpuacct: Show all detail stats in one file

In current code, we can get cpuacct data from severial files, but each file have its lilmit. For example: we can get cpu usage in user and kernel mode by cpuacct.stat, but we can't get detail data of each cpu in above file. we can get each cpu's kernel mode usage in cpuacct.usage_percpu_sys, but

[PATCH 2/3] cpuacct: Simplify cpuacct_stats_show

Merge code for each cpustat(system/user) into a loop, to avoid clone of code blocks. Only a little cleanup. Signed-off-by: Zhao Lei --- kernel/sched/cpuacct.c | 29 ++--- 1 file changed, 14 insertions(+), 15 deletions(-) diff --git a/kernel/sched/cpuacct.c

[PATCH 0/3] cpuacct: Show all detail stats in one file

In current code, we can get cpuacct data from severial files, but each file have its lilmit. For example: we can get cpu usage in user and kernel mode by cpuacct.stat, but we can't get detail data of each cpu in above file. we can get each cpu's kernel mode usage in cpuacct.usage_percpu_sys, but

Re: [PATCH v8 1/4] x86/KASLR: Clarify identity map interface

On Tue, May 10, 2016 at 10:19:12AM -0700, Kees Cook wrote: > This extracts the call to prepare_level4() into a top-level function > that the user of the pagetable.c interface must call to initialize > the new page tables. For clarity and to match the "finalize" function, > it has been renamed to

Re: [PATCH v8 1/4] x86/KASLR: Clarify identity map interface

On Tue, May 10, 2016 at 10:19:12AM -0700, Kees Cook wrote: > This extracts the call to prepare_level4() into a top-level function > that the user of the pagetable.c interface must call to initialize > the new page tables. For clarity and to match the "finalize" function, > it has been renamed to

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