Re: [RESEND][PATCH] cpuidle/powernv : Restore different PSSCR for idle and hotplug

* Benjamin Herrenschmidt [2018-03-01 08:40:22]: > On Thu, 2018-03-01 at 01:03 +0530, Akshay Adiga wrote: > > commit 1e1601b38e6e ("powerpc/powernv/idle: Restore SPRs for deep idle > > states via stop API.") uses stop-api provided by the firmware to restore > > PSSCR. PSSCR

Re: [RESEND][PATCH] cpuidle/powernv : Restore different PSSCR for idle and hotplug

* Benjamin Herrenschmidt [2018-03-01 08:40:22]: > On Thu, 2018-03-01 at 01:03 +0530, Akshay Adiga wrote: > > commit 1e1601b38e6e ("powerpc/powernv/idle: Restore SPRs for deep idle > > states via stop API.") uses stop-api provided by the firmware to restore > > PSSCR. PSSCR restore is required

Re: KASAN: use-after-free Read in __list_del_entry_valid (3)

On Tue, Mar 6, 2018 at 9:30 AM, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > 094b58e1040a44f991d7ab628035e69c4d6b79c9 (Mon Mar 5 19:57:06 2018 +) > Merge tag 'linux-kselftest-4.16-rc5' of >

Re: KASAN: use-after-free Read in __list_del_entry_valid (3)

On Tue, Mar 6, 2018 at 9:30 AM, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > 094b58e1040a44f991d7ab628035e69c4d6b79c9 (Mon Mar 5 19:57:06 2018 +) > Merge tag 'linux-kselftest-4.16-rc5' of > git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest

[PATCH v5 4/7] x86: Align x86_64 PCI_MMCONFIG with 32-bit variant

From: Jan Kiszka Allow to enable PCI_MMCONFIG when only SFI is present and make this option default on. This will help consolidating both into one Kconfig statement. Signed-off-by: Jan Kiszka --- arch/x86/Kconfig | 3 ++- 1 file changed, 2

[PATCH v5 4/7] x86: Align x86_64 PCI_MMCONFIG with 32-bit variant

From: Jan Kiszka Allow to enable PCI_MMCONFIG when only SFI is present and make this option default on. This will help consolidating both into one Kconfig statement. Signed-off-by: Jan Kiszka --- arch/x86/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[PATCH v5 3/7] x86/jailhouse: Enable PCI mmconfig access in inmates

From: Otavio Pontes Use the PCI mmconfig base address exported by jailhouse in boot parameters in order to access the memory mapped PCI configuration space. Signed-off-by: Otavio Pontes [Jan: rebased, fixed !CONFIG_PCI_MMCONFIG, used

[PATCH v5 3/7] x86/jailhouse: Enable PCI mmconfig access in inmates

From: Otavio Pontes Use the PCI mmconfig base address exported by jailhouse in boot parameters in order to access the memory mapped PCI configuration space. Signed-off-by: Otavio Pontes [Jan: rebased, fixed !CONFIG_PCI_MMCONFIG, used pcibios_last_bus] Signed-off-by: Jan Kiszka Reviewed-by:

[PATCH v5 5/7] x86: Consolidate PCI_MMCONFIG configs

From: Jan Kiszka Since e279b6c1d329 ("x86: start unification of arch/x86/Kconfig.*"), we have two PCI_MMCONFIG entries, one from the original i386 and another from x86_64. This consolidates both entries into a single one. Signed-off-by: Jan Kiszka

[PATCH v5 5/7] x86: Consolidate PCI_MMCONFIG configs

From: Jan Kiszka Since e279b6c1d329 ("x86: start unification of arch/x86/Kconfig.*"), we have two PCI_MMCONFIG entries, one from the original i386 and another from x86_64. This consolidates both entries into a single one. Signed-off-by: Jan Kiszka --- arch/x86/Kconfig | 11 --- 1 file

[PATCH v5 2/7] PCI: Scan all functions when running over Jailhouse

From: Jan Kiszka Per PCIe r4.0, sec 7.5.1.1.9, multi-function devices are required to have a function 0. Therefore, Linux scans for devices at function 0 (devfn 0/8/16/...) and only scans for other functions if function 0 has its Multi-Function Device bit set or ARI or

[PATCH v5 6/7] x86/jailhouse: Allow to use PCI_MMCONFIG without ACPI

From: Jan Kiszka Jailhouse does not use ACPI, but it does support MMCONFIG. Make sure the latter can be built without having to enable ACPI as well. Primarily, we need to make the AMD mmconf-fam10h_64 depend upon MMCONFIG and ACPI, instead of just the former. Saves some

[PATCH v5 2/7] PCI: Scan all functions when running over Jailhouse

From: Jan Kiszka Per PCIe r4.0, sec 7.5.1.1.9, multi-function devices are required to have a function 0. Therefore, Linux scans for devices at function 0 (devfn 0/8/16/...) and only scans for other functions if function 0 has its Multi-Function Device bit set or ARI or SR-IOV indicate there are

[PATCH v5 6/7] x86/jailhouse: Allow to use PCI_MMCONFIG without ACPI

From: Jan Kiszka Jailhouse does not use ACPI, but it does support MMCONFIG. Make sure the latter can be built without having to enable ACPI as well. Primarily, we need to make the AMD mmconf-fam10h_64 depend upon MMCONFIG and ACPI, instead of just the former. Saves some bytes in the Jailhouse

[PATCH v5 0/7] jailhouse: Enhance secondary Jailhouse guest support /wrt PCI

Basic x86 support [1] for running Linux as secondary Jailhouse [2] guest is currently pending in the tip tree. This builds on top and enhances the PCI support for x86 and also ARM guests (ARM[64] does not require platform patches and works already). Key elements of this series are: - detection

[PATCH v5 7/7] MAINTAINERS: Add entry for Jailhouse

From: Jan Kiszka Signed-off-by: Jan Kiszka --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4623caf8d72d..6dc0b8f3ae0e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7523,6 +7523,13 @@ Q:

[PATCH v5 1/7] jailhouse: Provide detection for non-x86 systems

From: Jan Kiszka Implement jailhouse_paravirt() via device tree probing on architectures != x86. Will be used by the PCI core. CC: Rob Herring CC: Mark Rutland CC: Juergen Gross Signed-off-by: Jan Kiszka

[PATCH v5 7/7] MAINTAINERS: Add entry for Jailhouse

From: Jan Kiszka Signed-off-by: Jan Kiszka --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4623caf8d72d..6dc0b8f3ae0e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7523,6 +7523,13 @@ Q:

[PATCH v5 0/7] jailhouse: Enhance secondary Jailhouse guest support /wrt PCI

Basic x86 support [1] for running Linux as secondary Jailhouse [2] guest is currently pending in the tip tree. This builds on top and enhances the PCI support for x86 and also ARM guests (ARM[64] does not require platform patches and works already). Key elements of this series are: - detection

[PATCH v5 1/7] jailhouse: Provide detection for non-x86 systems

From: Jan Kiszka Implement jailhouse_paravirt() via device tree probing on architectures != x86. Will be used by the PCI core. CC: Rob Herring CC: Mark Rutland CC: Juergen Gross Signed-off-by: Jan Kiszka Reviewed-by: Juergen Gross --- Documentation/devicetree/bindings/jailhouse.txt | 8

[PATCH v4 3/3] security: Add an example sample dynamic LSM

This adds an example LSM that utilizes the features added by the dynamically loadable LSMs patch. Once the module is unloaded, the command is once again allowed. It prevents the user from running: date --set="October 21 2015 16:29:00 PDT" Signed-off-by: Sargun Dhillon ---

[PATCH v4 3/3] security: Add an example sample dynamic LSM

This adds an example LSM that utilizes the features added by the dynamically loadable LSMs patch. Once the module is unloaded, the command is once again allowed. It prevents the user from running: date --set="October 21 2015 16:29:00 PDT" Signed-off-by: Sargun Dhillon --- samples/Kconfig

[PATCH v4 2/3] security: Expose a mechanism to load lsm hooks dynamically at runtime

This patch adds dynamic security hooks. These hooks are designed to allow for safe runtime loading. These hooks are only run after all built-in, and major LSMs are run. The LSMs enabled by this feature must be minor LSMs, but they can poke at the security blobs, as the blobs should be initialized

[PATCH v4 0/3] Safe, dynamically loadable LSM hooks

This patchset introduces safe dynamic LSM support. These are currently not unloadable, until we figure out a use case that needs that. Adding an unload hook is trivial given the way the patch is written. This exposes a second mechanism of loading hooks which are in modules. These hooks are behind

[PATCH v4 2/3] security: Expose a mechanism to load lsm hooks dynamically at runtime

This patch adds dynamic security hooks. These hooks are designed to allow for safe runtime loading. These hooks are only run after all built-in, and major LSMs are run. The LSMs enabled by this feature must be minor LSMs, but they can poke at the security blobs, as the blobs should be initialized

[PATCH v4 0/3] Safe, dynamically loadable LSM hooks

This patchset introduces safe dynamic LSM support. These are currently not unloadable, until we figure out a use case that needs that. Adding an unload hook is trivial given the way the patch is written. This exposes a second mechanism of loading hooks which are in modules. These hooks are behind

Re: WARNING: kmalloc bug in memdup_user

On Tue, Mar 06, 2018 at 10:59:02PM -0800, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > ce380619fab99036f5e745c7a865b21c59f005f6 (Tue Mar 6 04:31:14 2018 +) > Merge tag 'please-pull-ia64_misc' of > git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux > > So

[PATCH v4 1/3] security: Refactor LSM hooks into an array and enum

This commit should have no functional change. It changes the security hook list heads struct into an array. Additionally, it exposes all of the hooks via an enum. This loses memory layout randomization as the enum is not randomized. Signed-off-by: Sargun Dhillon ---

Re: WARNING: kmalloc bug in memdup_user

On Tue, Mar 06, 2018 at 10:59:02PM -0800, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > ce380619fab99036f5e745c7a865b21c59f005f6 (Tue Mar 6 04:31:14 2018 +) > Merge tag 'please-pull-ia64_misc' of > git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux > > So

[PATCH v4 1/3] security: Refactor LSM hooks into an array and enum

This commit should have no functional change. It changes the security hook list heads struct into an array. Additionally, it exposes all of the hooks via an enum. This loses memory layout randomization as the enum is not randomized. Signed-off-by: Sargun Dhillon --- include/linux/lsm_hooks.h |

Re: [PATCH 4.4 054/108] mtd: cfi: convert inline functions to macros

On Mon, 05 Mar 2018 02:22:52 + Ben Hutchings wrote: > On Thu, 2018-02-15 at 16:16 +0100, Greg Kroah-Hartman wrote: > > 4.4-stable review patch.  If anyone has any objections, please let me know. > > > > -- > > > > From: Arnd Bergmann

Re: [PATCH 4.4 054/108] mtd: cfi: convert inline functions to macros

On Mon, 05 Mar 2018 02:22:52 + Ben Hutchings wrote: > On Thu, 2018-02-15 at 16:16 +0100, Greg Kroah-Hartman wrote: > > 4.4-stable review patch.  If anyone has any objections, please let me know. > > > > -- > > > > From: Arnd Bergmann > > > > commit

Re: [PATCH V2 1/2] mmc: sdhci-msm: Add support to store supported vdd-io voltages

Hi Dough, Jeremy, On 3/3/2018 4:38 AM, Jeremy McNicoll wrote: On 2018-03-02 10:23 AM, Doug Anderson wrote: Hi, On Sun, Feb 11, 2018 at 10:01 PM, Vijay Viswanath wrote: During probe check whether the vdd-io regulator of sdhc platform device can support 1.8V and 3V

Re: [PATCH V2 1/2] mmc: sdhci-msm: Add support to store supported vdd-io voltages

Hi Dough, Jeremy, On 3/3/2018 4:38 AM, Jeremy McNicoll wrote: On 2018-03-02 10:23 AM, Doug Anderson wrote: Hi, On Sun, Feb 11, 2018 at 10:01 PM, Vijay Viswanath wrote: During probe check whether the vdd-io regulator of sdhc platform device can support 1.8V and 3V and store this information

Re: [PATCH 1/3] vfio/pci: Pull BAR mapping setup from read-write path

On Wed, Feb 28, 2018 at 01:14:46PM -0700, Alex Williamson wrote: > This creates a common helper that we'll use for ioeventfd setup. > > Signed-off-by: Alex Williamson Reviewed-by: Peter Xu -- Peter Xu

Re: [PATCH 1/3] vfio/pci: Pull BAR mapping setup from read-write path

On Wed, Feb 28, 2018 at 01:14:46PM -0700, Alex Williamson wrote: > This creates a common helper that we'll use for ioeventfd setup. > > Signed-off-by: Alex Williamson Reviewed-by: Peter Xu -- Peter Xu

Re: [PATCH v6] mmc: Export host capabilities to debugfs.

On Wednesday 07 March 2018 12:10 PM, Avri Altman wrote: > >> -Original Message- >> From: Harish Jenny K N [mailto:harish_kand...@mentor.com] >> Sent: Wednesday, March 07, 2018 7:38 AM >> To: ulf.hans...@linaro.org; linus.wall...@linaro.org; >> adrian.hun...@intel.com;

Re: [PATCH v6] mmc: Export host capabilities to debugfs.

On Wednesday 07 March 2018 12:10 PM, Avri Altman wrote: > >> -Original Message- >> From: Harish Jenny K N [mailto:harish_kand...@mentor.com] >> Sent: Wednesday, March 07, 2018 7:38 AM >> To: ulf.hans...@linaro.org; linus.wall...@linaro.org; >> adrian.hun...@intel.com;

Re: [PATCHv2 2/5] x86/boot/compressed/64: Find a place for 32-bit trampoline

* Kirill A. Shutemov wrote: > On Tue, Feb 27, 2018 at 06:42:14PM +0300, Kirill A. Shutemov wrote: > > If a bootloader enables 64-bit mode with 4-level paging, we might need to > > switch over to 5-level paging. The switching requires the disabling of > > paging, which

Re: [PATCHv2 2/5] x86/boot/compressed/64: Find a place for 32-bit trampoline

* Kirill A. Shutemov wrote: > On Tue, Feb 27, 2018 at 06:42:14PM +0300, Kirill A. Shutemov wrote: > > If a bootloader enables 64-bit mode with 4-level paging, we might need to > > switch over to 5-level paging. The switching requires the disabling of > > paging, which works fine if kernel

[PATCH] scsi: jazz_esp, sun3x_esp: Pass struct device pointer in dma calls

In jazz_esp and sun3x_esp, the esp_driver_ops methods pass esp->dev in dma api calls as if it was a pointer to a struct device. But it actually points to a struct platform_device. Fix this. Cc: Thomas Bogendoerfer Signed-off-by: Finn Thain

[PATCH] scsi: jazz_esp, sun3x_esp: Pass struct device pointer in dma calls

In jazz_esp and sun3x_esp, the esp_driver_ops methods pass esp->dev in dma api calls as if it was a pointer to a struct device. But it actually points to a struct platform_device. Fix this. Cc: Thomas Bogendoerfer Signed-off-by: Finn Thain --- drivers/scsi/jazz_esp.c | 2 +-

[tip:x86/pti] objtool: Fix 32-bit build

Commit-ID: 63474dc4ac7ed3848a4786b9592dd061901f606d Gitweb: https://git.kernel.org/tip/63474dc4ac7ed3848a4786b9592dd061901f606d Author: Josh Poimboeuf AuthorDate: Tue, 6 Mar 2018 17:58:15 -0600 Committer: Ingo Molnar CommitDate: Wed, 7 Mar 2018

[tip:x86/pti] objtool: Fix 32-bit build

Commit-ID: 63474dc4ac7ed3848a4786b9592dd061901f606d Gitweb: https://git.kernel.org/tip/63474dc4ac7ed3848a4786b9592dd061901f606d Author: Josh Poimboeuf AuthorDate: Tue, 6 Mar 2018 17:58:15 -0600 Committer: Ingo Molnar CommitDate: Wed, 7 Mar 2018 07:50:38 +0100 objtool: Fix 32-bit build

[GIT PULL] s390 patches for 4.16-rc5

Hi Linus, please pull from the 'for-linus' branch of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus to receive the following updates: Nine bug fixes for s390: * Three fixes for the expoline code, one of them is strictly speaking a cleanup but as it relates

[GIT PULL] s390 patches for 4.16-rc5

Hi Linus, please pull from the 'for-linus' branch of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus to receive the following updates: Nine bug fixes for s390: * Three fixes for the expoline code, one of them is strictly speaking a cleanup but as it relates

Re: [pci PATCH v3 0/3] Add support for unmanaged SR-IOV

On Tue, Mar 06, 2018 at 11:29:08AM -0800, Alexander Duyck wrote: > This series is meant to add support for SR-IOV on devices when the VFs are > not managed by the kernel. Examples of recent patches attempting to do this > include: > virto - https://patchwork.kernel.org/patch/10241225/ > pci-stub -

Re: [pci PATCH v3 0/3] Add support for unmanaged SR-IOV

On Tue, Mar 06, 2018 at 11:29:08AM -0800, Alexander Duyck wrote: > This series is meant to add support for SR-IOV on devices when the VFs are > not managed by the kernel. Examples of recent patches attempting to do this > include: > virto - https://patchwork.kernel.org/patch/10241225/ > pci-stub -

RE: [PATCH v6] mmc: Export host capabilities to debugfs.

> -Original Message- > From: Harish Jenny K N [mailto:harish_kand...@mentor.com] > Sent: Wednesday, March 07, 2018 7:38 AM > To: ulf.hans...@linaro.org; linus.wall...@linaro.org; > adrian.hun...@intel.com; shawn@rock-chips.com; Avri Altman > ;

RE: [PATCH v6] mmc: Export host capabilities to debugfs.

> -Original Message- > From: Harish Jenny K N [mailto:harish_kand...@mentor.com] > Sent: Wednesday, March 07, 2018 7:38 AM > To: ulf.hans...@linaro.org; linus.wall...@linaro.org; > adrian.hun...@intel.com; shawn@rock-chips.com; Avri Altman > ; andriy.shevche...@linux.intel.com > Cc:

[PATCH 1/1] iommu/arm-smmu: Add support for qcom,smmu-500 variant

Qualcomm's arm-smmu 500 implementation supports runtime pm so enable the same. Signed-off-by: Vivek Gautam --- Based on iommu/arm-smmu pm runtime support series [1]: [PATCH v8 0/5] iommu/arm-smmu: Add runtime pm/sleep support Tested on sdm845 with necessary

[PATCH 1/1] iommu/arm-smmu: Add support for qcom,smmu-500 variant

Qualcomm's arm-smmu 500 implementation supports runtime pm so enable the same. Signed-off-by: Vivek Gautam --- Based on iommu/arm-smmu pm runtime support series [1]: [PATCH v8 0/5] iommu/arm-smmu: Add runtime pm/sleep support Tested on sdm845 with necessary support to enable the smmu and

Re: [RFC] rcu: Prevent expedite reporting within RCU read-side section

On 3/7/2018 2:55 PM, Byungchul Park wrote: On 3/6/2018 10:42 PM, Boqun Feng wrote: On Tue, Mar 06, 2018 at 02:31:58PM +0900, Byungchul Park wrote: Hello Paul and RCU folks, I am afraid I correctly understand and fix it. But I really wonder why sync_rcu_exp_handler() reports the quiescent

Re: [RFC] rcu: Prevent expedite reporting within RCU read-side section

On 3/7/2018 2:55 PM, Byungchul Park wrote: On 3/6/2018 10:42 PM, Boqun Feng wrote: On Tue, Mar 06, 2018 at 02:31:58PM +0900, Byungchul Park wrote: Hello Paul and RCU folks, I am afraid I correctly understand and fix it. But I really wonder why sync_rcu_exp_handler() reports the quiescent

[PATCH v1 1/9] PCI/PM: Move pcie_clear_root_pme_status() to core

From: Bjorn Helgaas Move pcie_clear_root_pme_status() from the port driver to the PCI core so it will be available even when the port driver isn't present. No functional change intended. Signed-off-by: Bjorn Helgaas --- drivers/pci/pci.c

[PATCH v1 1/9] PCI/PM: Move pcie_clear_root_pme_status() to core

From: Bjorn Helgaas Move pcie_clear_root_pme_status() from the port driver to the PCI core so it will be available even when the port driver isn't present. No functional change intended. Signed-off-by: Bjorn Helgaas --- drivers/pci/pci.c |9 + drivers/pci/pci.h

[PATCH v1 5/9] PCI/portdrv: Remove pcie_port_bus_type link order dependency

From: Bjorn Helgaas The pcie_port_bus_type must be registered before drivers that depend on it can be registered. Those drivers include: pcied_init()# PCIe native hotplug driver aer_service_init() # AER driver dpc_service_init() #

[PATCH v1 5/9] PCI/portdrv: Remove pcie_port_bus_type link order dependency

From: Bjorn Helgaas The pcie_port_bus_type must be registered before drivers that depend on it can be registered. Those drivers include: pcied_init()# PCIe native hotplug driver aer_service_init() # AER driver dpc_service_init() # DPC driver

[PATCH v1 9/9] PCI/portdrv: Remove "pcie_hp=nomsi" kernel parameter

From: Bjorn Helgaas 7570a333d8b0 ("PCI: Add pcie_hp=nomsi to disable MSI/MSI-X for pciehp driver") added the "pcie_hp=nomsi" kernel parameter to work around this error on shutdown: irq 16: nobody cared (try booting with the "irqpoll" option) Pid: 1081, comm: reboot Not

[PATCH v1 9/9] PCI/portdrv: Remove "pcie_hp=nomsi" kernel parameter

From: Bjorn Helgaas 7570a333d8b0 ("PCI: Add pcie_hp=nomsi to disable MSI/MSI-X for pciehp driver") added the "pcie_hp=nomsi" kernel parameter to work around this error on shutdown: irq 16: nobody cared (try booting with the "irqpoll" option) Pid: 1081, comm: reboot Not tainted 3.2.0 #1

[PATCH v1 2/9] PCI/PM: Clear PCIe PME Status bit in core, not PCIe port driver

From: Bjorn Helgaas fe31e69740ed ("PCI/PCIe: Clear Root PME Status bits early during system resume") added a .resume_noirq() callback to the PCIe port driver to clear the PME Status bit during resume to work around a BIOS issue. The BIOS evidently enabled PME interrupts for

[PATCH v1 2/9] PCI/PM: Clear PCIe PME Status bit in core, not PCIe port driver

From: Bjorn Helgaas fe31e69740ed ("PCI/PCIe: Clear Root PME Status bits early during system resume") added a .resume_noirq() callback to the PCIe port driver to clear the PME Status bit during resume to work around a BIOS issue. The BIOS evidently enabled PME interrupts for ACPI-based runtime

[PATCH v1 7/9] PCI/portdrv: Simplify PCIe feature permission checking

From: Bjorn Helgaas Some PCIe features (AER, DPC, hotplug, PME) can be managed by either the platform firmware or the OS, so the host bridge driver may have to request permission from the platform before using them. On ACPI systems, this is done by negotiate_os_control() in

[PATCH v1 4/9] PCI/portdrv: Disable port driver in compat mode

From: Bjorn Helgaas The "pcie_ports=compat" kernel parameter sets pcie_ports_disabled, which is intended to disable the PCIe port driver. But even when it was disabled, we registered pcie_portdriver so we could work around a BIOS PME issue (see fe31e69740ed ("PCI/PCIe:

[PATCH v1 7/9] PCI/portdrv: Simplify PCIe feature permission checking

From: Bjorn Helgaas Some PCIe features (AER, DPC, hotplug, PME) can be managed by either the platform firmware or the OS, so the host bridge driver may have to request permission from the platform before using them. On ACPI systems, this is done by negotiate_os_control() in acpi_pci_root_add().

[PATCH v1 4/9] PCI/portdrv: Disable port driver in compat mode

From: Bjorn Helgaas The "pcie_ports=compat" kernel parameter sets pcie_ports_disabled, which is intended to disable the PCIe port driver. But even when it was disabled, we registered pcie_portdriver so we could work around a BIOS PME issue (see fe31e69740ed ("PCI/PCIe: Clear Root PME Status

[PATCH v1 6/9] PCI/portdrv: Remove unused PCIE_PORT_SERVICE_VC

From: Bjorn Helgaas No driver registers for PCIE_PORT_SERVICE_VC, so remove it. This removes the VC "service" files from /sys/bus/pci_express/devices, e.g., :07:00.0:pcie108, :08:04.0:pcie208 (all the files that contained "8" as the last digit of the "pcieXXX"

[PATCH v1 8/9] PCI/portdrv: Remove unnecessary include of

From: Bjorn Helgaas portdrv_pci.c doesn't use anything from . Remove the include of it. No functional change intended. Signed-off-by: Bjorn Helgaas --- drivers/pci/pcie/portdrv_pci.c |1 - 1 file changed, 1 deletion(-) diff --git

[PATCH v1 3/9] PCI/PM: Clear PCIe PME Status bit for Root Complex Event Collectors

From: Bjorn Helgaas Per PCIe r4.0, sec 6.1.6, Root Complex Event Collectors can generate PME interrupts on behalf of Root Complex Integrated Endpoints. Linux does not currently enable PME interrupts from RC Event Collectors, but fe31e69740ed ("PCI/PCIe: Clear Root PME

[PATCH v1 8/9] PCI/portdrv: Remove unnecessary include of

From: Bjorn Helgaas portdrv_pci.c doesn't use anything from . Remove the include of it. No functional change intended. Signed-off-by: Bjorn Helgaas --- drivers/pci/pcie/portdrv_pci.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/pci/pcie/portdrv_pci.c

[PATCH v1 3/9] PCI/PM: Clear PCIe PME Status bit for Root Complex Event Collectors

From: Bjorn Helgaas Per PCIe r4.0, sec 6.1.6, Root Complex Event Collectors can generate PME interrupts on behalf of Root Complex Integrated Endpoints. Linux does not currently enable PME interrupts from RC Event Collectors, but fe31e69740ed ("PCI/PCIe: Clear Root PME Status bits early during

[PATCH v1 6/9] PCI/portdrv: Remove unused PCIE_PORT_SERVICE_VC

From: Bjorn Helgaas No driver registers for PCIE_PORT_SERVICE_VC, so remove it. This removes the VC "service" files from /sys/bus/pci_express/devices, e.g., :07:00.0:pcie108, :08:04.0:pcie208 (all the files that contained "8" as the last digit of the "pcieXXX" part). The port driver

[PATCH v1 0/9] PCI: Simplify PCIe port driver

This is an attempt to move a few things out of the port driver. Patches 1-2 move a workaround for a BIOS PME issue from the port driver to the PCI core, so it doesn't depend on CONFIG_PCIEPORTBUS. Patch 3 extends that workaround so it works for Root Complex Event Collectors. I haven't seen

[PATCH v1 0/9] PCI: Simplify PCIe port driver

This is an attempt to move a few things out of the port driver. Patches 1-2 move a workaround for a BIOS PME issue from the port driver to the PCI core, so it doesn't depend on CONFIG_PCIEPORTBUS. Patch 3 extends that workaround so it works for Root Complex Event Collectors. I haven't seen

Re: [PATCH v2] xhci: Fix front USB ports on ASUS PRIME B350M-A

Hi Matthias, Do you have any concern about this patch? Hopefully this can get merged for v4.16… Kai-Heng

Re: [PATCH v2] xhci: Fix front USB ports on ASUS PRIME B350M-A

Hi Matthias, Do you have any concern about this patch? Hopefully this can get merged for v4.16… Kai-Heng

Re: [PATCH 3/3] vfio/pci: Add ioeventfd support

On Wed, Feb 28, 2018 at 01:15:20PM -0700, Alex Williamson wrote: [...] > @@ -1174,6 +1206,8 @@ static int vfio_pci_probe(struct pci_dev *pdev, const > struct pci_device_id *id) > vdev->irq_type = VFIO_PCI_NUM_IRQS; > mutex_init(>igate); > spin_lock_init(>irqlock); > +

Re: [PATCH 3/3] vfio/pci: Add ioeventfd support

On Wed, Feb 28, 2018 at 01:15:20PM -0700, Alex Williamson wrote: [...] > @@ -1174,6 +1206,8 @@ static int vfio_pci_probe(struct pci_dev *pdev, const > struct pci_device_id *id) > vdev->irq_type = VFIO_PCI_NUM_IRQS; > mutex_init(>igate); > spin_lock_init(>irqlock); > +

Re: [RFC] rcu: Prevent expedite reporting within RCU read-side section

On 3/6/2018 10:42 PM, Boqun Feng wrote: On Tue, Mar 06, 2018 at 02:31:58PM +0900, Byungchul Park wrote: Hello Paul and RCU folks, I am afraid I correctly understand and fix it. But I really wonder why sync_rcu_exp_handler() reports the quiescent state even in the case that current task is

Re: [RFC] rcu: Prevent expedite reporting within RCU read-side section

On 3/6/2018 10:42 PM, Boqun Feng wrote: On Tue, Mar 06, 2018 at 02:31:58PM +0900, Byungchul Park wrote: Hello Paul and RCU folks, I am afraid I correctly understand and fix it. But I really wonder why sync_rcu_exp_handler() reports the quiescent state even in the case that current task is

[PATCH] ipmi:ssif: Fix double probe from tryacpi and trydmi

IPMI SSIF driver's parameter tryacpi and trydmi both are set to true. The addition of IPMI DMI driver to create platform device for each IPMI device causes SSIF probe to be done twice on the same SMB I2C address for BMC. Fix is to not call trydmi if tryacpi is able to find I2C address for BMC

[PATCH] ipmi:ssif: Fix double probe from tryacpi and trydmi

IPMI SSIF driver's parameter tryacpi and trydmi both are set to true. The addition of IPMI DMI driver to create platform device for each IPMI device causes SSIF probe to be done twice on the same SMB I2C address for BMC. Fix is to not call trydmi if tryacpi is able to find I2C address for BMC

[PATCH] staging: lustre: Remove VLA usage

The kernel would like to remove all VLA usage. This switches to a simple kasprintf() instead. Signed-off-by: Kees Cook --- drivers/staging/lustre/lustre/llite/xattr.c | 19 +-- 1 file changed, 13 insertions(+), 6 deletions(-) diff --git

[PATCH] staging: lustre: Remove VLA usage

The kernel would like to remove all VLA usage. This switches to a simple kasprintf() instead. Signed-off-by: Kees Cook --- drivers/staging/lustre/lustre/llite/xattr.c | 19 +-- 1 file changed, 13 insertions(+), 6 deletions(-) diff --git

[PATCH] staging: iio: meter: Remove reduntant __func__ from debug print

From: HariPrasath Elango dev_dbg includes the function name & line number by default when dynamic debugging is enabled. Hence__func__ is reduntant here and removed. Signed-off-by: HariPrasath Elango ---

[PATCH] staging: iio: meter: Remove reduntant __func__ from debug print

From: HariPrasath Elango dev_dbg includes the function name & line number by default when dynamic debugging is enabled. Hence__func__ is reduntant here and removed. Signed-off-by: HariPrasath Elango --- drivers/staging/iio/meter/ade7758_trigger.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH v6] mmc: Export host capabilities to debugfs.

This patch exports the host capabilities to debugfs This idea of sharing host capabilities over debugfs came up from Abbas Raza Earlier discussions: https://lkml.org/lkml/2018/3/5/357 https://www.spinics.net/lists/linux-mmc/msg48219.html Signed-off-by: Harish Jenny K N

[PATCH v6] mmc: Export host capabilities to debugfs.

This patch exports the host capabilities to debugfs This idea of sharing host capabilities over debugfs came up from Abbas Raza Earlier discussions: https://lkml.org/lkml/2018/3/5/357 https://www.spinics.net/lists/linux-mmc/msg48219.html Signed-off-by: Harish Jenny K N --- Changes in v6: -

[PATCH] security: Fix IMA Kconfig for dependencies on ARM64

TPM_CRB driver is the TPM support for ARM64. If it is built as module, TPM chip is registered after IMA init. tpm_pcr_read() in IMA driver would fail and display the following message even though eventually there is TPM chip on the system: ima: No TPM chip found, activating TPM-bypass! (rc=-19)

[PATCH] security: Fix IMA Kconfig for dependencies on ARM64

TPM_CRB driver is the TPM support for ARM64. If it is built as module, TPM chip is registered after IMA init. tpm_pcr_read() in IMA driver would fail and display the following message even though eventually there is TPM chip on the system: ima: No TPM chip found, activating TPM-bypass! (rc=-19)

Re: [PATCH] staging: iio: adc: Remove reduntant __func__ from debug print

On Wed, Mar 07, 2018 at 10:40:05AM +0530, hariprasath.ela...@gmail.com wrote: > From: HariPrasath Elango > > dev_dbg includes the function name & line number by default when dynamic > debugging is enabled. Hence__func__ is reduntant here and removed. > >

Re: [PATCH] staging: iio: adc: Remove reduntant __func__ from debug print

On Wed, Mar 07, 2018 at 10:40:05AM +0530, hariprasath.ela...@gmail.com wrote: > From: HariPrasath Elango > > dev_dbg includes the function name & line number by default when dynamic > debugging is enabled. Hence__func__ is reduntant here and removed. > > Signed-off-by: HariPrasath Elango > ---

Re: [PATCH v2] arm64: dts: msm8916: Add cpu cooling maps

On Wed, Mar 7, 2018 at 10:30 AM, Amit Kucheria wrote: > From: Rajendra Nayak > > Add cpu cooling maps for cpu passive trip points. The cpu cooling > device states are mapped to cpufreq based scaling frequencies. > > Signed-off-by: Rajendra Nayak

Re: [PATCH v2] arm64: dts: msm8916: Add cpu cooling maps

On Wed, Mar 7, 2018 at 10:30 AM, Amit Kucheria wrote: > From: Rajendra Nayak > > Add cpu cooling maps for cpu passive trip points. The cpu cooling > device states are mapped to cpufreq based scaling frequencies. > > Signed-off-by: Rajendra Nayak > Signed-off-by: Amit Kucheria > --- >

[PATCH] staging: iio: adc: Remove reduntant __func__ from debug print

From: HariPrasath Elango dev_dbg includes the function name & line number by default when dynamic debugging is enabled. Hence__func__ is reduntant here and removed. Signed-off-by: HariPrasath Elango ---

Re: [PATCH v9 14/15] cpufreq: Add module to register cpufreq on Krait CPUs

On 06-03-18, 20:09, Sricharan R wrote: > From: Stephen Boyd > > Register a cpufreq-generic device whenever we detect that a > "qcom,krait" compatible CPU is present in DT. > > Acked-by: Viresh Kumar > [Sricharan: updated to use

[PATCH] staging: iio: adc: Remove reduntant __func__ from debug print

From: HariPrasath Elango dev_dbg includes the function name & line number by default when dynamic debugging is enabled. Hence__func__ is reduntant here and removed. Signed-off-by: HariPrasath Elango --- drivers/staging/iio/meter/ade7758_trigger.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH v9 14/15] cpufreq: Add module to register cpufreq on Krait CPUs

On 06-03-18, 20:09, Sricharan R wrote: > From: Stephen Boyd > > Register a cpufreq-generic device whenever we detect that a > "qcom,krait" compatible CPU is present in DT. > > Acked-by: Viresh Kumar > [Sricharan: updated to use dev_pm_opp_set_prop_name and > nvmem apis] >

[PATCH dts/arm/aspeed-g5 v1] ARM: dts: aspeed-g5: Add IPMI KCS node

The IPMI KCS device part of the LPC interface and is used for communication with the host processor. Signed-off-by: Haiyue Wang --- arch/arm/boot/dts/aspeed-g5.dtsi | 43 +++- 1 file changed, 42 insertions(+), 1 deletion(-) diff

[PATCH dts/arm/aspeed-g5 v1] ARM: dts: aspeed-g5: Add IPMI KCS node

The IPMI KCS device part of the LPC interface and is used for communication with the host processor. Signed-off-by: Haiyue Wang --- arch/arm/boot/dts/aspeed-g5.dtsi | 43 +++- 1 file changed, 42 insertions(+), 1 deletion(-) diff --git

  1   2   3   4   5   6   7   8   9   10   >