Re: [PATCH 08/31] mm, vmscan: simplify the logic deciding whether kswapd sleeps

On Fri, Jul 01, 2016 at 09:01:16PM +0100, Mel Gorman wrote: > kswapd goes through some complex steps trying to figure out if it should > stay awake based on the classzone_idx and the requested order. It is > unnecessarily complex and passes in an invalid classzone_idx to > balance_pgdat(). What

Re: [PATCH 08/31] mm, vmscan: simplify the logic deciding whether kswapd sleeps

On Fri, Jul 01, 2016 at 09:01:16PM +0100, Mel Gorman wrote: > kswapd goes through some complex steps trying to figure out if it should > stay awake based on the classzone_idx and the requested order. It is > unnecessarily complex and passes in an invalid classzone_idx to > balance_pgdat(). What

Re: [RFC RESEND PATCH] swap: choose swap device according to numa node

On Tue, Jul 5, 2016 at 11:19 AM, Aaron Lu wrote: > Resend: > This is a resend, the original patch doesn't catch much attention. > It may not be a big deal for swap devices that used to be hosted on > HDD but with devices like 3D Xpoint to be used as swap device, it could >

Re: [RFC RESEND PATCH] swap: choose swap device according to numa node

On Tue, Jul 5, 2016 at 11:19 AM, Aaron Lu wrote: > Resend: > This is a resend, the original patch doesn't catch much attention. > It may not be a big deal for swap devices that used to be hosted on > HDD but with devices like 3D Xpoint to be used as swap device, it could > make a real difference

[PATCH 2/2] ACPICA: Namespace: Fix lock order issue for namespace/interpreter

There is a lock order issue in acpi_load_tables(). The namespace lock is held before holding the interpreter lock. With ACPI_MUTEX_DEBUG enabled in kernel, we can reproduce this during boot: [0.885699] ACPI Error: Invalid acquire order: Thread 405884224 owns [ACPI_MTX_Namespace], wants

[PATCH 1/2] ACPICA: Linux: Enable ACPI_MUTEX_DEBUG for Linux kernel

This patch enables ACPI_MUTEX_DEBUG for Linux kernel so that the ACPICA lock order issues can be captured by ACPICA itself. Signed-off-by: Lv Zheng --- include/acpi/platform/aclinux.h |4 1 file changed, 4 insertions(+) diff --git a/include/acpi/platform/aclinux.h

[PATCH 2/2] ACPICA: Namespace: Fix lock order issue for namespace/interpreter

There is a lock order issue in acpi_load_tables(). The namespace lock is held before holding the interpreter lock. With ACPI_MUTEX_DEBUG enabled in kernel, we can reproduce this during boot: [0.885699] ACPI Error: Invalid acquire order: Thread 405884224 owns [ACPI_MTX_Namespace], wants

[PATCH 1/2] ACPICA: Linux: Enable ACPI_MUTEX_DEBUG for Linux kernel

This patch enables ACPI_MUTEX_DEBUG for Linux kernel so that the ACPICA lock order issues can be captured by ACPICA itself. Signed-off-by: Lv Zheng --- include/acpi/platform/aclinux.h |4 1 file changed, 4 insertions(+) diff --git a/include/acpi/platform/aclinux.h

Re: [PATCH 3/5] mmu: don't set the present bit unconditionally

2016-06-28 16:57 GMT+08:00 Paolo Bonzini : > > > On 28/06/2016 06:32, Bandan Das wrote: >> + bool execonly = !(context->guest_rsvd_check.bad_mt_xwr & >> + (1ull << VMX_EPT_EXECUTABLE_MASK)); >> >> if (set_mmio_spte(vcpu, sptep, gfn, pfn,

Re: [PATCH 3/5] mmu: don't set the present bit unconditionally

2016-06-28 16:57 GMT+08:00 Paolo Bonzini : > > > On 28/06/2016 06:32, Bandan Das wrote: >> + bool execonly = !(context->guest_rsvd_check.bad_mt_xwr & >> + (1ull << VMX_EPT_EXECUTABLE_MASK)); >> >> if (set_mmio_spte(vcpu, sptep, gfn, pfn, pte_access)) >>

Re: [RESEND, v2] powerpc: Export thread_struct.used_vr/used_vsr to user space

On Wed, 2016-06-04 at 07:00:12 UTC, Simon Guo wrote: > These 2 fields track whether user process has used Altivec/VSX > registers or not. They are used by kernel to setup signal frame > on user stack correctly regarding vector part. > > CRIU(Checkpoint and Restore In User space) builds signal

Re: [RESEND, v2] powerpc: Export thread_struct.used_vr/used_vsr to user space

On Wed, 2016-06-04 at 07:00:12 UTC, Simon Guo wrote: > These 2 fields track whether user process has used Altivec/VSX > registers or not. They are used by kernel to setup signal frame > on user stack correctly regarding vector part. > > CRIU(Checkpoint and Restore In User space) builds signal

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

On Thu, Jun 30, 2016 at 03:01:49PM +0200, Paolo Bonzini wrote: > The vGPU folks would like to trap the first access to a BAR by setting > vm_ops on the VMAs produced by mmap-ing a VFIO device. The fault handler > then can use remap_pfn_range to place some non-reserved pages in the VMA. > > KVM

Re: [PATCH] ARM: uniphier: remove empty DT machine descriptor

On Tue, Jun 28, 2016 at 06:25:10PM +0900, Masahiro Yamada wrote: > Since the initial support of mach-uniphier, this has always been > just empty. > > Signed-off-by: Masahiro Yamada Applied, thanks. -Olof

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

On Thu, Jun 30, 2016 at 03:01:49PM +0200, Paolo Bonzini wrote: > The vGPU folks would like to trap the first access to a BAR by setting > vm_ops on the VMAs produced by mmap-ing a VFIO device. The fault handler > then can use remap_pfn_range to place some non-reserved pages in the VMA. > > KVM

Re: [PATCH] ARM: uniphier: remove empty DT machine descriptor

On Tue, Jun 28, 2016 at 06:25:10PM +0900, Masahiro Yamada wrote: > Since the initial support of mach-uniphier, this has always been > just empty. > > Signed-off-by: Masahiro Yamada Applied, thanks. -Olof

Re: [RFC PATCH v3 2/2] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller

On Mon, Jun 20, 2016 at 10:17 AM, Christopher Covington wrote: > Hi Duc, > > On 06/20/2016 05:42 AM, Lorenzo Pieralisi wrote: >> On Fri, Jun 17, 2016 at 02:37:02PM -0700, Duc Dang wrote: >>> On Thu, Jun 16, 2016 at 10:48 AM, Lorenzo Pieralisi >>>

Re: [RFC PATCH v3 2/2] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller

On Mon, Jun 20, 2016 at 10:17 AM, Christopher Covington wrote: > Hi Duc, > > On 06/20/2016 05:42 AM, Lorenzo Pieralisi wrote: >> On Fri, Jun 17, 2016 at 02:37:02PM -0700, Duc Dang wrote: >>> On Thu, Jun 16, 2016 at 10:48 AM, Lorenzo Pieralisi >>> wrote: On Wed, Jun 15, 2016 at 11:34:11AM

Re: [linux-sunxi] [PATCH 2/4] power: add axp20x-battery driver

Hi, nice work! Is this in any way related to Bruno Prémonts driver for the axp20x? I've got a reworked version of that lying around, but it's not quite ready for submission. Do you know what pieces are missing in your driver for axp20x support - as opposed to axp22x, which is already

Re: [linux-sunxi] [PATCH 2/4] power: add axp20x-battery driver

Hi, nice work! Is this in any way related to Bruno Prémonts driver for the axp20x? I've got a reworked version of that lying around, but it's not quite ready for submission. Do you know what pieces are missing in your driver for axp20x support - as opposed to axp22x, which is already

[PATCH 09/10] phy: rockhip-usb: use devm_add_action_or_reset()

From: Sudip Mukherjee If devm_add_action() fails we are explicitly calling the cleanup to free the resources allocated. Lets use the helper devm_add_action_or_reset() and return directly in case of error, as we know that the cleanup function has been already called

[PATCH 09/10] phy: rockhip-usb: use devm_add_action_or_reset()

From: Sudip Mukherjee If devm_add_action() fails we are explicitly calling the cleanup to free the resources allocated. Lets use the helper devm_add_action_or_reset() and return directly in case of error, as we know that the cleanup function has been already called by the helper if there was

[PATCH 04/10] phy: da8xx-usb: new driver for DA8xx SoC USB PHY

From: David Lechner This is a new phy driver for the SoC USB controllers on the TI DA8xx family of microcontrollers. The USB 1.1 PHY is just a simple on/off. The USB 2.0 PHY also allows overriding the VBUS and ID pins. Signed-off-by: David Lechner

[PATCH 04/10] phy: da8xx-usb: new driver for DA8xx SoC USB PHY

From: David Lechner This is a new phy driver for the SoC USB controllers on the TI DA8xx family of microcontrollers. The USB 1.1 PHY is just a simple on/off. The USB 2.0 PHY also allows overriding the VBUS and ID pins. Signed-off-by: David Lechner Signed-off-by: Kishon Vijay Abraham I ---

[PATCH 06/10] phy: phy-qcom-ufs-qmp-20nm: Remove site specific OOM error message

From: Peter Griffin kzalloc will issue its own error message including a dump_stack() so remote the site specific message. Signed-off-by: Peter Griffin Signed-off-by: Kishon Vijay Abraham I ---

[PATCH 10/10] phy: rcar-gen3-usb2: fix mutex_lock calling in interrupt

From: Yoshihiro Shimoda This patch fixes an issue that the extcon_set_cable_state_() is possible to cause "BUG: scheduling while atomic" because this driver calls extcon_set_cable_state_() in the interrupt handler and mutex_lock() is possible to be called by

[PATCH 06/10] phy: phy-qcom-ufs-qmp-20nm: Remove site specific OOM error message

From: Peter Griffin kzalloc will issue its own error message including a dump_stack() so remote the site specific message. Signed-off-by: Peter Griffin Signed-off-by: Kishon Vijay Abraham I --- drivers/phy/phy-qcom-ufs-qmp-20nm.c |1 - 1 file changed, 1 deletion(-) diff --git

[PATCH 10/10] phy: rcar-gen3-usb2: fix mutex_lock calling in interrupt

From: Yoshihiro Shimoda This patch fixes an issue that the extcon_set_cable_state_() is possible to cause "BUG: scheduling while atomic" because this driver calls extcon_set_cable_state_() in the interrupt handler and mutex_lock() is possible to be called by like the following call trace. So,

[PATCH 05/10] phy: rockchip-usb: should be a child device of the GRF

From: Heiko Stuebner The usb-phy is fully enclosed in the general register files (GRF). Therefore as seen from the device-tree it shouldn't be a separate platform-device but instead a sub-device of the GRF - using the simply-mfd mechanism. As the usb-phy is part of the kernel

[PATCH 07/10] phy: phy-qcom-ufs-qmp-14nm: Remove site specific OOM error message

From: Peter Griffin kzalloc will issue its own error message including a dump_stack() so remote the site specific message. Signed-off-by: Peter Griffin Signed-off-by: Kishon Vijay Abraham I ---

[PATCH 08/10] phy-sun4i-usb: Add workaround for missing Vbus det interrupts on A31

From: Hans de Goede The A31 companion pmic (axp221) does not generate vbus change interrupts when the board is driving vbus, so we must poll when using the pmic for vbus-det _and_ we're driving vbus. Signed-off-by: Hans de Goede Acked-by: Kishon Vijay

[PATCH 07/10] phy: phy-qcom-ufs-qmp-14nm: Remove site specific OOM error message

From: Peter Griffin kzalloc will issue its own error message including a dump_stack() so remote the site specific message. Signed-off-by: Peter Griffin Signed-off-by: Kishon Vijay Abraham I --- drivers/phy/phy-qcom-ufs-qmp-14nm.c |1 - 1 file changed, 1 deletion(-) diff --git

[PATCH 08/10] phy-sun4i-usb: Add workaround for missing Vbus det interrupts on A31

From: Hans de Goede The A31 companion pmic (axp221) does not generate vbus change interrupts when the board is driving vbus, so we must poll when using the pmic for vbus-det _and_ we're driving vbus. Signed-off-by: Hans de Goede Acked-by: Kishon Vijay Abraham I Signed-off-by: Kishon Vijay

[PATCH 05/10] phy: rockchip-usb: should be a child device of the GRF

From: Heiko Stuebner The usb-phy is fully enclosed in the general register files (GRF). Therefore as seen from the device-tree it shouldn't be a separate platform-device but instead a sub-device of the GRF - using the simply-mfd mechanism. As the usb-phy is part of the kernel for some releases

[PATCH 03/10] dt-bindings: Add bindings for phy-da8xx-usb

From: David Lechner Device tree binding for new phy-da8xx-usb driver. Signed-off-by: David Lechner Acked-by: Rob Herring Signed-off-by: Kishon Vijay Abraham I --- .../devicetree/bindings/phy/phy-da8xx-usb.txt |

[GIT PULL] phy: for 4.8 merge window

Hi Greg, Please find the pull request for 4.8 merge window below. Now the controller can configure the mode in which the PHY should work using the new phy_set_mode API. This was added by David Lechner required for da8xx-usb phy (used by MUSB). For this I created a signed tag 'phy-set-mode-v2'

[PATCH 03/10] dt-bindings: Add bindings for phy-da8xx-usb

From: David Lechner Device tree binding for new phy-da8xx-usb driver. Signed-off-by: David Lechner Acked-by: Rob Herring Signed-off-by: Kishon Vijay Abraham I --- .../devicetree/bindings/phy/phy-da8xx-usb.txt | 40 1 file changed, 40 insertions(+) create mode

[GIT PULL] phy: for 4.8 merge window

Hi Greg, Please find the pull request for 4.8 merge window below. Now the controller can configure the mode in which the PHY should work using the new phy_set_mode API. This was added by David Lechner required for da8xx-usb phy (used by MUSB). For this I created a signed tag 'phy-set-mode-v2'

[PATCH 01/10] phy: xgene: rename "enum phy_mode" to "enum xgene_phy_mode"

No functional change. Rename "enum phy_mode" to "enum xgene_phy_mode" in xgene phy driver in preparation for adding set_mode callback in phy core. Signed-off-by: Kishon Vijay Abraham I Reviewed-by: Loc Ho --- drivers/phy/phy-xgene.c |4 ++-- 1 file changed, 2

[PATCH 02/10] phy: Add set_mode callback

From: David Lechner The initial use for this is for PHYs that have a mode related to USB OTG. There are several SoCs (e.g. TI OMAP and DA8xx) that have a mode setting in the USB PHY to override OTG VBUS and ID signals. Of course, the enum can be expaned in the future to

[PATCH 01/10] phy: xgene: rename "enum phy_mode" to "enum xgene_phy_mode"

No functional change. Rename "enum phy_mode" to "enum xgene_phy_mode" in xgene phy driver in preparation for adding set_mode callback in phy core. Signed-off-by: Kishon Vijay Abraham I Reviewed-by: Loc Ho --- drivers/phy/phy-xgene.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

[PATCH 02/10] phy: Add set_mode callback

From: David Lechner The initial use for this is for PHYs that have a mode related to USB OTG. There are several SoCs (e.g. TI OMAP and DA8xx) that have a mode setting in the USB PHY to override OTG VBUS and ID signals. Of course, the enum can be expaned in the future to include modes for other

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

On Tue, Jul 05, 2016 at 12:02:42PM +0800, Xiao Guangrong wrote: > > > On 07/05/2016 09:35 AM, Neo Jia wrote: > >On Tue, Jul 05, 2016 at 09:19:40AM +0800, Xiao Guangrong wrote: > >> > >> > >>On 07/04/2016 11:33 PM, Neo Jia wrote: > >> > > > >Sorry, I think I misread the "allocation" as

Re: [PATCH 0/2] KVM: MMU: support VMAs that got remap_pfn_range-ed

On Tue, Jul 05, 2016 at 12:02:42PM +0800, Xiao Guangrong wrote: > > > On 07/05/2016 09:35 AM, Neo Jia wrote: > >On Tue, Jul 05, 2016 at 09:19:40AM +0800, Xiao Guangrong wrote: > >> > >> > >>On 07/04/2016 11:33 PM, Neo Jia wrote: > >> > > > >Sorry, I think I misread the "allocation" as

Re: [GIT PULL] ARM: at91: drivers for 4.8 #2

On Tue, Jun 21, 2016 at 07:03:06PM +0200, Alexandre Belloni wrote: > Arnd, Olof, Kevin, > > Here are two simple fixes for our memory drivers. > > The following changes since commit 1fdab21d1d52a85c31f932844242fec5fb81daac: > > memory: atmel-ebi: add DT bindings documentation (2016-06-02

Re: [GIT PULL] ARM: at91: dt for 4.8 #2 bis

On Mon, Jul 04, 2016 at 04:16:54PM +0200, Alexandre Belloni wrote: > Hi, > > Please disregard the previous DT pull request, it had an issue... > I'm including the corrected change in this one with two fixes for the > sam9_l9260 and on fix for the sama5d2 xplained. > Also, adding the PMU node to

Re: [GIT PULL] ARM: at91: drivers for 4.8 #2

On Tue, Jun 21, 2016 at 07:03:06PM +0200, Alexandre Belloni wrote: > Arnd, Olof, Kevin, > > Here are two simple fixes for our memory drivers. > > The following changes since commit 1fdab21d1d52a85c31f932844242fec5fb81daac: > > memory: atmel-ebi: add DT bindings documentation (2016-06-02

Re: [GIT PULL] ARM: at91: dt for 4.8 #2 bis

On Mon, Jul 04, 2016 at 04:16:54PM +0200, Alexandre Belloni wrote: > Hi, > > Please disregard the previous DT pull request, it had an issue... > I'm including the corrected change in this one with two fixes for the > sam9_l9260 and on fix for the sama5d2 xplained. > Also, adding the PMU node to

Re: [GIT PULL] ARM: at91: soc for 4.8 #2

On Tue, Jun 21, 2016 at 07:04:54PM +0200, Alexandre Belloni wrote: > Arnd, Olof, Kevin, > > Here are more compilation warning fixes and the final documentation for the > sama5d2 that we forgot about. > > The following changes since commit 8b2f2d0356184cc7c409b2f046c550ce00ca8f70: > > ARM:

Re: [GIT PULL] ARM: at91: soc for 4.8 #2

On Tue, Jun 21, 2016 at 07:04:54PM +0200, Alexandre Belloni wrote: > Arnd, Olof, Kevin, > > Here are more compilation warning fixes and the final documentation for the > sama5d2 that we forgot about. > > The following changes since commit 8b2f2d0356184cc7c409b2f046c550ce00ca8f70: > > ARM:

[PATCH] ACPI: CPPC: Return error if _CPC is invalid on a CPU

Based on 8.4.7.1 section of ACPI 6.1 specification, if the platform supports CPPC, the _CPC object must exist under all processor objects. If cpc_desc_ptr pointer is invalid on any CPUs, acpi_get_psd_map() should return error and CPPC cpufreq driver can not be registered. Signed-off-by: Hoan Tran

[PATCH] ACPI: CPPC: Return error if _CPC is invalid on a CPU

Based on 8.4.7.1 section of ACPI 6.1 specification, if the platform supports CPPC, the _CPC object must exist under all processor objects. If cpc_desc_ptr pointer is invalid on any CPUs, acpi_get_psd_map() should return error and CPPC cpufreq driver can not be registered. Signed-off-by: Hoan Tran

Re: [RFC PATCH v3 2/2] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller

On Mon, Jun 20, 2016 at 12:12 PM, Duc Dang wrote: > On Mon, Jun 20, 2016 at 10:17 AM, Christopher Covington > wrote: >> Hi Duc, >> >> On 06/20/2016 05:42 AM, Lorenzo Pieralisi wrote: >>> On Fri, Jun 17, 2016 at 02:37:02PM -0700, Duc Dang wrote: On Thu,

Re: [RFC PATCH v3 2/2] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller

On Mon, Jun 20, 2016 at 12:12 PM, Duc Dang wrote: > On Mon, Jun 20, 2016 at 10:17 AM, Christopher Covington > wrote: >> Hi Duc, >> >> On 06/20/2016 05:42 AM, Lorenzo Pieralisi wrote: >>> On Fri, Jun 17, 2016 at 02:37:02PM -0700, Duc Dang wrote: On Thu, Jun 16, 2016 at 10:48 AM, Lorenzo

Re: [PATCH] mailbox: pcc: Add PCC request and free channel declarations

Hi Prashanth, On Wed, Jun 15, 2016 at 8:55 AM, Prakash, Prashanth wrote: > Hi Hoan, > > On 6/14/2016 5:12 PM, Hoan Tran wrote: >> As PCC will be used by other clients not only CPPC. >> This change exports pcc_mbox_request_channel() and pcc_mbox_free_channel() >>

Re: [PATCH] mailbox: pcc: Add PCC request and free channel declarations

Hi Prashanth, On Wed, Jun 15, 2016 at 8:55 AM, Prakash, Prashanth wrote: > Hi Hoan, > > On 6/14/2016 5:12 PM, Hoan Tran wrote: >> As PCC will be used by other clients not only CPPC. >> This change exports pcc_mbox_request_channel() and pcc_mbox_free_channel() >> declarations >> >> Signed-off-by:

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

On Mon, Jun 13, 2016 at 8:59 AM, Jeffrey Hugo wrote: > On 6/13/2016 9:12 AM, ok...@codeaurora.org wrote: >> >> On 2016-06-13 10:29, Gabriele Paoloni wrote: >>> >>> Hi Sinan >>> -Original Message- From: Sinan Kaya [mailto:ok...@codeaurora.org] Sent: 13

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

On Mon, Jun 13, 2016 at 8:59 AM, Jeffrey Hugo wrote: > On 6/13/2016 9:12 AM, ok...@codeaurora.org wrote: >> >> On 2016-06-13 10:29, Gabriele Paoloni wrote: >>> >>> Hi Sinan >>> -Original Message- From: Sinan Kaya [mailto:ok...@codeaurora.org] Sent: 13 June 2016 15:03

Re: [PATCH v5 3/3] gpio: lp873x: Add support for General Purpose Outputs

On Monday 04 July 2016 04:52 PM, Linus Walleij wrote: On Wed, Jun 29, 2016 at 5:44 PM, Keerthy wrote: Add driver for lp873x PMIC family GPOs. Two GPOs are supported and can be configured in Open-drain output or Push-pull output. Signed-off-by: Keerthy

Re: [PATCH v5 3/3] gpio: lp873x: Add support for General Purpose Outputs

On Monday 04 July 2016 04:52 PM, Linus Walleij wrote: On Wed, Jun 29, 2016 at 5:44 PM, Keerthy wrote: Add driver for lp873x PMIC family GPOs. Two GPOs are supported and can be configured in Open-drain output or Push-pull output. Signed-off-by: Keerthy Looks all right to me. +#include

Re: [PATCH v3] mailbox: pcc: Support HW-Reduced Communication Subspace type 2

Hi Prashanth, On Thu, Jun 9, 2016 at 3:25 PM, Prakash, Prashanth wrote: > > > On 6/9/2016 2:47 PM, Hoan Tran wrote: >> Hi Ashwin and Prashanth, >> >> On Wed, Jun 8, 2016 at 5:41 PM, Hoan Tran wrote: >>> Hi Prashanth, >>> >>> >>> On Wed, Jun 8, 2016 at

Re: [PATCH v3] mailbox: pcc: Support HW-Reduced Communication Subspace type 2

Hi Prashanth, On Thu, Jun 9, 2016 at 3:25 PM, Prakash, Prashanth wrote: > > > On 6/9/2016 2:47 PM, Hoan Tran wrote: >> Hi Ashwin and Prashanth, >> >> On Wed, Jun 8, 2016 at 5:41 PM, Hoan Tran wrote: >>> Hi Prashanth, >>> >>> >>> On Wed, Jun 8, 2016 at 5:32 PM, Prakash, Prashanth >>> wrote:

Re: [PATCH V9 09/11] ARM64/PCI: ACPI support for legacy IRQs parsing and consolidation with DT code

On Mon, Jun 13, 2016 at 3:40 AM, Lorenzo Pieralisi wrote: > > On Fri, Jun 10, 2016 at 06:36:12PM -0500, Bjorn Helgaas wrote: > > On Fri, Jun 10, 2016 at 09:55:17PM +0200, Tomasz Nowicki wrote: > > > To enable PCI legacy IRQs on platforms booting with ACPI, arch code > >

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington wrote: > Hi Dongdong, > > On 06/13/2016 09:02 AM, Dongdong Liu wrote: >> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c >> index d3c3e85..49612b3 100644 >> --- a/drivers/acpi/pci_mcfg.c >> +++

Re: More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes.

On Jul 4, 2016, at 10:28 PM, Oleg Drokin wrote: > > On Jul 3, 2016, at 2:29 AM, Al Viro wrote: > >> On Sat, Jun 25, 2016 at 12:38:40PM -0400, Oleg Drokin wrote: >> >>> Sorry to nag you about this, but did any of those pan out? >>> >>> d_alloc_parallel() sounds like a bit too heavy there,

Re: More parallel atomic_open/d_splice_alias fun with NFS and possibly more FSes.

On Jul 4, 2016, at 10:28 PM, Oleg Drokin wrote: > > On Jul 3, 2016, at 2:29 AM, Al Viro wrote: > >> On Sat, Jun 25, 2016 at 12:38:40PM -0400, Oleg Drokin wrote: >> >>> Sorry to nag you about this, but did any of those pan out? >>> >>> d_alloc_parallel() sounds like a bit too heavy there,

Re: [PATCH V9 09/11] ARM64/PCI: ACPI support for legacy IRQs parsing and consolidation with DT code

On Mon, Jun 13, 2016 at 3:40 AM, Lorenzo Pieralisi wrote: > > On Fri, Jun 10, 2016 at 06:36:12PM -0500, Bjorn Helgaas wrote: > > On Fri, Jun 10, 2016 at 09:55:17PM +0200, Tomasz Nowicki wrote: > > > To enable PCI legacy IRQs on platforms booting with ACPI, arch code > > > should include ACPI

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington wrote: > Hi Dongdong, > > On 06/13/2016 09:02 AM, Dongdong Liu wrote: >> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c >> index d3c3e85..49612b3 100644 >> --- a/drivers/acpi/pci_mcfg.c >> +++ b/drivers/acpi/pci_mcfg.c >> @@

Re: [PATCH v3] mailbox: pcc: Support HW-Reduced Communication Subspace type 2

Hi Ashwin and Prashanth, On Wed, Jun 8, 2016 at 5:41 PM, Hoan Tran wrote: > Hi Prashanth, > > > On Wed, Jun 8, 2016 at 5:32 PM, Prakash, Prashanth > wrote: >> >> >> On 6/8/2016 10:24 AM, Hoan Tran wrote: >>> Hi Ashwin, >>> >>> On Wed, Jun 8, 2016 at 5:18

Re: [PATCH v3] mailbox: pcc: Support HW-Reduced Communication Subspace type 2

Hi Ashwin and Prashanth, On Wed, Jun 8, 2016 at 5:41 PM, Hoan Tran wrote: > Hi Prashanth, > > > On Wed, Jun 8, 2016 at 5:32 PM, Prakash, Prashanth > wrote: >> >> >> On 6/8/2016 10:24 AM, Hoan Tran wrote: >>> Hi Ashwin, >>> >>> On Wed, Jun 8, 2016 at 5:18 AM, Ashwin Chaugule >>> wrote: +

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

On Tue, Jun 14, 2016 at 4:52 AM, Tomasz Nowicki wrote: > On 14.06.2016 11:45, Dongdong Liu wrote: >> >> Hi Duc >> >> 在 2016/6/14 17:00, Duc Dang 写道: >>> >>> On Mon, Jun 13, 2016 at 10:51 PM, Dongdong Liu >>> wrote: Hi Duc 在

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

On Tue, Jun 14, 2016 at 4:52 AM, Tomasz Nowicki wrote: > On 14.06.2016 11:45, Dongdong Liu wrote: >> >> Hi Duc >> >> 在 2016/6/14 17:00, Duc Dang 写道: >>> >>> On Mon, Jun 13, 2016 at 10:51 PM, Dongdong Liu >>> wrote: Hi Duc 在 2016/6/14 4:57, Duc Dang 写道: > > > On

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

On Mon, Jun 13, 2016 at 10:51 PM, Dongdong Liu wrote: > Hi Duc > > 在 2016/6/14 4:57, Duc Dang 写道: >> >> On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington >> wrote: >>> >>> Hi Dongdong, >>> >>> On 06/13/2016 09:02 AM, Dongdong Liu wrote:

Re: [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

On Mon, Jun 13, 2016 at 10:51 PM, Dongdong Liu wrote: > Hi Duc > > 在 2016/6/14 4:57, Duc Dang 写道: >> >> On Mon, Jun 13, 2016 at 8:47 AM, Christopher Covington >> wrote: >>> >>> Hi Dongdong, >>> >>> On 06/13/2016 09:02 AM, Dongdong Liu wrote: diff --git a/drivers/acpi/pci_mcfg.c

Re: [Linaro-acpi] [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

On Wed, Jun 15, 2016 at 11:31 PM, Jon Masters wrote: > On 06/13/2016 09:54 AM, Gabriele Paoloni wrote: >> Hi Tomasz, Jon > > Hi Gab, > > Sorry for the lag in following up. > > > >> As you can see here Liudongdong has replaced oem_revision with >> oem_table_id. >> >> Now it seems

Re: [Linaro-acpi] [RFC PATCH V2 1/2] ACPI/PCI: Match PCI config space accessors against platfrom specific ECAM quirks

On Wed, Jun 15, 2016 at 11:31 PM, Jon Masters wrote: > On 06/13/2016 09:54 AM, Gabriele Paoloni wrote: >> Hi Tomasz, Jon > > Hi Gab, > > Sorry for the lag in following up. > > > >> As you can see here Liudongdong has replaced oem_revision with >> oem_table_id. >> >> Now it seems that there are

[PATCH] mailbox: pcc: Add PCC request and free channel declarations

As PCC will be used by other clients not only CPPC. This change exports pcc_mbox_request_channel() and pcc_mbox_free_channel() declarations Signed-off-by: Hoan Tran --- include/acpi/cppc_acpi.h | 4 include/linux/mailbox_client.h | 4 2 files changed, 4

[PATCH] mailbox: pcc: Add PCC request and free channel declarations

As PCC will be used by other clients not only CPPC. This change exports pcc_mbox_request_channel() and pcc_mbox_free_channel() declarations Signed-off-by: Hoan Tran --- include/acpi/cppc_acpi.h | 4 include/linux/mailbox_client.h | 4 2 files changed, 4 insertions(+), 4

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

On Mon, Jun 6, 2016 at 4:04 PM, Bjorn Helgaas wrote: > Several host bridge drivers (designware and all derivatives, iproc, > xgene, xilinx, and xilinx-nwl) don't request the MMIO and I/O port > windows they forward downstream to the PCI bus. > > That means the PCI core can't

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

On Mon, Jun 6, 2016 at 4:04 PM, Bjorn Helgaas wrote: > Several host bridge drivers (designware and all derivatives, iproc, > xgene, xilinx, and xilinx-nwl) don't request the MMIO and I/O port > windows they forward downstream to the PCI bus. > > That means the PCI core can't request resources for

Re: [PATCH v3 1/2] clocksource/arm_arch_timer: Force per-CPU interrupt to be level-triggered

On Fri, Jun 10, 2016 at 12:29 AM, Marc Zyngier wrote: > On Thu, 09 Jun 2016 14:10:48 -0700 > David Daney wrote: > >> On 06/06/2016 10:56 AM, Marc Zyngier wrote: >> > The ARM architected timer produces level-triggered interrupts (this >> > is mandated

Re: [PATCH v3 2/2] arm64: dts: Fix broken architected timer interrupt trigger

On Mon, Jun 6, 2016 at 10:56 AM, Marc Zyngier wrote: > The ARM architected timer specification mandates that the interrupt > associated with each timer is level triggered (which corresponds to > the "counter >= comparator" condition). > > A number of DTs are being remarkably

Re: [PATCH v3 1/2] clocksource/arm_arch_timer: Force per-CPU interrupt to be level-triggered

On Fri, Jun 10, 2016 at 12:29 AM, Marc Zyngier wrote: > On Thu, 09 Jun 2016 14:10:48 -0700 > David Daney wrote: > >> On 06/06/2016 10:56 AM, Marc Zyngier wrote: >> > The ARM architected timer produces level-triggered interrupts (this >> > is mandated by the architecture). Unfortunately, most

Re: [PATCH v3 2/2] arm64: dts: Fix broken architected timer interrupt trigger

On Mon, Jun 6, 2016 at 10:56 AM, Marc Zyngier wrote: > The ARM architected timer specification mandates that the interrupt > associated with each timer is level triggered (which corresponds to > the "counter >= comparator" condition). > > A number of DTs are being remarkably creative, declaring

Re: [RFC PATCH v3 2/2] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller

On Tue, Jun 21, 2016 at 2:26 AM, Lorenzo Pieralisi wrote: > On Mon, Jun 20, 2016 at 12:12:24PM -0700, Duc Dang wrote: >> On Mon, Jun 20, 2016 at 10:17 AM, Christopher Covington >> wrote: >> > Hi Duc, >> > >> > On 06/20/2016 05:42 AM, Lorenzo

Re: [RFC PATCH v3 2/2] ARM64/PCI: Start using quirks handling for ACPI based PCI host controller

On Tue, Jun 21, 2016 at 2:26 AM, Lorenzo Pieralisi wrote: > On Mon, Jun 20, 2016 at 12:12:24PM -0700, Duc Dang wrote: >> On Mon, Jun 20, 2016 at 10:17 AM, Christopher Covington >> wrote: >> > Hi Duc, >> > >> > On 06/20/2016 05:42 AM, Lorenzo Pieralisi wrote: >> >> On Fri, Jun 17, 2016 at

Re: [PATCH v3] mailbox: pcc: Support HW-Reduced Communication Subspace type 2

Hi Jassi and Rafael, On Wed, Jun 15, 2016 at 9:19 AM, Prakash, Prashanth wrote: > > > On 6/9/2016 4:43 PM, Hoan Tran wrote: >> Hi Prashanth, >> >> On Thu, Jun 9, 2016 at 3:25 PM, Prakash, Prashanth >> wrote: >>> >>> On 6/9/2016 2:47 PM, Hoan

Re: [PATCH] kasan: make depot_fetch_stack more robust

On Mon, Jul 4, 2016 at 8:11 PM, Andrey Ryabinin wrote: > 2016-07-01 20:38 GMT+03:00 Dmitry Vyukov : >> I've hit a GPF in depot_fetch_stack when it was given >> bogus stack handle. I think it was caused by a distant >> out-of-bounds that hit a different

Re: [PATCH v3] mailbox: pcc: Support HW-Reduced Communication Subspace type 2

Hi Jassi and Rafael, On Wed, Jun 15, 2016 at 9:19 AM, Prakash, Prashanth wrote: > > > On 6/9/2016 4:43 PM, Hoan Tran wrote: >> Hi Prashanth, >> >> On Thu, Jun 9, 2016 at 3:25 PM, Prakash, Prashanth >> wrote: >>> >>> On 6/9/2016 2:47 PM, Hoan Tran wrote: Hi Ashwin and Prashanth,

Re: [PATCH] kasan: make depot_fetch_stack more robust

On Mon, Jul 4, 2016 at 8:11 PM, Andrey Ryabinin wrote: > 2016-07-01 20:38 GMT+03:00 Dmitry Vyukov : >> I've hit a GPF in depot_fetch_stack when it was given >> bogus stack handle. I think it was caused by a distant >> out-of-bounds that hit a different object, as the result >> we treated uninit

Re: [RFC PATCH v4 3/5] PCI: Check platform specific ECAM quirks

On Tue, Jun 28, 2016 at 6:04 AM, Christopher Covington wrote: > Hi Tomasz, > > On 06/28/2016 03:54 AM, Tomasz Nowicki wrote: > >> diff --git a/drivers/pci/host/mcfg-quirks.c b/drivers/pci/host/mcfg-quirks.c >> new file mode 100644 >> index 000..fb2b184 >> --- /dev/null >>

Re: [RFC PATCH v4 3/5] PCI: Check platform specific ECAM quirks

On Tue, Jun 28, 2016 at 6:04 AM, Christopher Covington wrote: > Hi Tomasz, > > On 06/28/2016 03:54 AM, Tomasz Nowicki wrote: > >> diff --git a/drivers/pci/host/mcfg-quirks.c b/drivers/pci/host/mcfg-quirks.c >> new file mode 100644 >> index 000..fb2b184 >> --- /dev/null >> +++

Re: [PATCH] acpi: cppc: Prevent cpc_desc_ptr points to the invalid data

On Tue, May 31, 2016 at 12:29 PM, Ashwin Chaugule wrote: > > On 27 May 2016 at 12:41, Hoan Tran wrote: > > Hi Ashwin, > > Hi, > > > > > Yes, I saw kernel crash. > > As cpc_desc_ptr is not NULL, cppc_cpufreq_init() still can pass then > > crash during

Re: [PATCH] acpi: cppc: Prevent cpc_desc_ptr points to the invalid data

On Tue, May 31, 2016 at 12:29 PM, Ashwin Chaugule wrote: > > On 27 May 2016 at 12:41, Hoan Tran wrote: > > Hi Ashwin, > > Hi, > > > > > Yes, I saw kernel crash. > > As cpc_desc_ptr is not NULL, cppc_cpufreq_init() still can pass then > > crash during cppc_get_perf_caps() access CPPC shared

[PATCH v2] mailbox: pcc: Add PCC request and free channel declarations

Exports pcc_mbox_request_channel() and pcc_mbox_free_channel() declarations into a pcc.h header file. v2 * Introduce pcc.h header file for pcc client methods v1 * Initial Signed-off-by: Hoan Tran --- include/acpi/cppc_acpi.h | 7 +-- include/acpi/pcc.h | 29

[PATCH v2] mailbox: pcc: Add PCC request and free channel declarations

Exports pcc_mbox_request_channel() and pcc_mbox_free_channel() declarations into a pcc.h header file. v2 * Introduce pcc.h header file for pcc client methods v1 * Initial Signed-off-by: Hoan Tran --- include/acpi/cppc_acpi.h | 7 +-- include/acpi/pcc.h | 29

RE: [PATCH v14 net-next 1/1] hv_sock: introduce Hyper-V Sockets

> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > ow...@vger.kernel.org] On Behalf Of Dexuan Cui > Sent: Thursday, June 30, 2016 23:59 > diff --git a/include/linux/socket.h b/include/linux/socket.h > index b5cc5a6..0b68b58 100644 > --- a/include/linux/socket.h > +++

RE: [PATCH v14 net-next 1/1] hv_sock: introduce Hyper-V Sockets

> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > ow...@vger.kernel.org] On Behalf Of Dexuan Cui > Sent: Thursday, June 30, 2016 23:59 > diff --git a/include/linux/socket.h b/include/linux/socket.h > index b5cc5a6..0b68b58 100644 > --- a/include/linux/socket.h > +++

Re: [PATCH 2/2] net: ethernet: bcmgenet: use phy_ethtool_{get|set}_link_ksettings

Le 04/07/2016 16:03, David Miller a écrit : > From: Philippe Reynes > Date: Sun, 3 Jul 2016 17:33:57 +0200 > >> There are two generics functions phy_ethtool_{get|set}_link_ksettings, >> so we can use them instead of defining the same code in the driver. >> >> Signed-off-by:

Re: [PATCH 2/2] net: ethernet: bcmgenet: use phy_ethtool_{get|set}_link_ksettings

Le 04/07/2016 16:03, David Miller a écrit : > From: Philippe Reynes > Date: Sun, 3 Jul 2016 17:33:57 +0200 > >> There are two generics functions phy_ethtool_{get|set}_link_ksettings, >> so we can use them instead of defining the same code in the driver. >> >> Signed-off-by: Philippe Reynes >

  1   2   3   4   5   6   7   8   9   10   >