[PATCH 5/6] apalis-tk1: working sd card detect on v1.1 hw

Add sd card detect SD1_CD# applicable for V1.1 modules using GPIO_PV2. Signed-off-by: Marcel Ziswiler --- arch/arm/boot/dts/tegra124-apalis-eval.dts | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/arch/arm/boot/dts/tegra124-apalis-eval.dts

[PATCH 2/6] apalis-tk1: temp alert pull-up

Pull-up GPIO_PI6 connected to TMP451's ALERT#/THERM2#. Signed-off-by: Marcel Ziswiler --- arch/arm/boot/dts/tegra124-apalis.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/tegra124-apalis.dtsi b/arch/arm/boot/dts/tegra124-apalis.dtsi index

[PATCH 0/6] apalis-tk1: updates for v1.1 hw

This series updates the device tree for the upcoming V1.1 HW samples. All changes are purely opportunistic meaning they fix stuff which on older HW was anyway broken so there should be no backwards compatibility issues. Marcel Ziswiler (6): apalis-tk1: remove spurious new lines apalis-tk1:

[PATCH 3/6] apalis-tk1: optional displayport hot-plug detect

Configure DP_HPD_PFF0 pin as optional DisplayPort hot-plug detect. Signed-off-by: Marcel Ziswiler --- arch/arm/boot/dts/tegra124-apalis.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/tegra124-apalis.dtsi

[PATCH 6/6] apalis-tk1: update compatibility comment

Now with the new V1.1A HW card detect being implemented update resp. compatibility information. Signed-off-by: Marcel Ziswiler --- arch/arm/boot/dts/tegra124-apalis.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 0/6] apalis-tk1: updates for v1.1 hw

This series updates the device tree for the upcoming V1.1 HW samples. All changes are purely opportunistic meaning they fix stuff which on older HW was anyway broken so there should be no backwards compatibility issues. Marcel Ziswiler (6): apalis-tk1: remove spurious new lines apalis-tk1:

[PATCH 3/6] apalis-tk1: optional displayport hot-plug detect

Configure DP_HPD_PFF0 pin as optional DisplayPort hot-plug detect. Signed-off-by: Marcel Ziswiler --- arch/arm/boot/dts/tegra124-apalis.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/tegra124-apalis.dtsi b/arch/arm/boot/dts/tegra124-apalis.dtsi

[PATCH 6/6] apalis-tk1: update compatibility comment

Now with the new V1.1A HW card detect being implemented update resp. compatibility information. Signed-off-by: Marcel Ziswiler --- arch/arm/boot/dts/tegra124-apalis.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/tegra124-apalis.dtsi

Re: [PATCH] zram: Fix unbalanced idr management at hot removal

On Mon, Nov 21, 2016 at 02:21:40PM +0100, Takashi Iwai wrote: > The zram hot removal code calls idr_remove() even when zram_remove() > returns an error (typically -EBUSY). This results in a leftover at > the device release, eventually leading to a crash when the module is > reloaded. > > As

Re: [PATCH] zram: Fix unbalanced idr management at hot removal

On Mon, Nov 21, 2016 at 02:21:40PM +0100, Takashi Iwai wrote: > The zram hot removal code calls idr_remove() even when zram_remove() > returns an error (typically -EBUSY). This results in a leftover at > the device release, eventually leading to a crash when the module is > reloaded. > > As

RE: [PATCH v3] cpufreq: intel_pstate: Generic governors support

On 2016.11.17 14:34 Rafael J. Wysocki wrote: > v2 -> v3: > The previous iteration didn't work correcty if ondemand was the default > governor, because it didn't set policy->cur during initialization and > that caused cpufreq_dbs_governor_start() to return an error (thanks to > Srinovas for

RE: [PATCH v3] cpufreq: intel_pstate: Generic governors support

On 2016.11.17 14:34 Rafael J. Wysocki wrote: > v2 -> v3: > The previous iteration didn't work correcty if ondemand was the default > governor, because it didn't set policy->cur during initialization and > that caused cpufreq_dbs_governor_start() to return an error (thanks to > Srinovas for

Re: [PATCH 0/5] usb: dwc2: fix parameter handling

On 11/20/2016 1:26 PM, Stefan Wahren wrote: > This patch series fixes several parameter handling issues > found on bcm2835 in gadget mode. It's based on Felipe's USB next. > > Stefan Wahren (5): > usb: dwc2: Do not set host parameter in peripheral mode > usb: dwc2: fix

Re: [PATCH 0/5] usb: dwc2: fix parameter handling

On 11/20/2016 1:26 PM, Stefan Wahren wrote: > This patch series fixes several parameter handling issues > found on bcm2835 in gadget mode. It's based on Felipe's USB next. > > Stefan Wahren (5): > usb: dwc2: Do not set host parameter in peripheral mode > usb: dwc2: fix

Re: crash by cdc_acm driver in kernels 4.8-rc1/5

On 21.11.2016 21:23, Wim Osterholt wrote: > On Mon, Nov 21, 2016 at 04:58:25PM +0100, Wim Osterholt wrote: >> >> I didn't find traces of kernel-4.9-rc5 being ran on any of my laptops, so I >> can't have seen a crash on rc5. It seems rc5 and rc6 is safe now. > > Neither 4.8.10, nor 4.8.9 show the

Re: crash by cdc_acm driver in kernels 4.8-rc1/5

On 21.11.2016 21:23, Wim Osterholt wrote: > On Mon, Nov 21, 2016 at 04:58:25PM +0100, Wim Osterholt wrote: >> >> I didn't find traces of kernel-4.9-rc5 being ran on any of my laptops, so I >> can't have seen a crash on rc5. It seems rc5 and rc6 is safe now. > > Neither 4.8.10, nor 4.8.9 show the

Re: [PATCH v10 04/10] kexec_file: Add support for purgatory built as PIE.

Hello Dave, Thanks for your review. Am Sonntag, 20. November 2016, 10:45:46 BRST schrieb Dave Young: > On 11/10/16 at 01:27am, Thiago Jung Bauermann wrote: > > powerpc's purgatory.ro has 12 relocation types when built as > > a relocatable object. To implement support for them requires > >

Re: [PATCH v10 04/10] kexec_file: Add support for purgatory built as PIE.

Hello Dave, Thanks for your review. Am Sonntag, 20. November 2016, 10:45:46 BRST schrieb Dave Young: > On 11/10/16 at 01:27am, Thiago Jung Bauermann wrote: > > powerpc's purgatory.ro has 12 relocation types when built as > > a relocatable object. To implement support for them requires > >

Re: [PATCH 1/2] ARM64: dts: Add support for Meson GXM

Neil, Neil Armstrong writes: > Following the Amlogic Linux kernel, it seem the only differences > between the GXL and GXM SoCs are the CPU Clusters. > > This commit renames the gxl-s905d-p23x DTSI in a common file for > S905D p20x and S912 q20x boards. s/p20x/p23x/ ??

Re: [PATCH 1/2] ARM64: dts: Add support for Meson GXM

Neil, Neil Armstrong writes: > Following the Amlogic Linux kernel, it seem the only differences > between the GXL and GXM SoCs are the CPU Clusters. > > This commit renames the gxl-s905d-p23x DTSI in a common file for > S905D p20x and S912 q20x boards. s/p20x/p23x/ ?? > Then adds a meson-gxm

Re: linux-next: manual merge of the rockchip tree with the arm-soc tree

Hi, On Mon, Nov 21, 2016 at 3:19 PM, Stephen Rothwell wrote: > Hi Heiko, > > Today's linux-next merge of the rockchip tree got a conflict in: > > arch/arm64/configs/defconfig > > between commit: > > a59294b2f7c7 ("ARM64: defconfig: Enable MMC related configs") > > from

Re: linux-next: manual merge of the rockchip tree with the arm-soc tree

Hi, On Mon, Nov 21, 2016 at 3:19 PM, Stephen Rothwell wrote: > Hi Heiko, > > Today's linux-next merge of the rockchip tree got a conflict in: > > arch/arm64/configs/defconfig > > between commit: > > a59294b2f7c7 ("ARM64: defconfig: Enable MMC related configs") > > from the arm-soc tree and

linux-next: manual merge of the arm64 tree with Linus' tree

Hi Catalin, Today's linux-next merge of the arm64 tree got a conflict in: arch/arm64/include/asm/cpufeature.h between commit: 272d01bd790f ("arm64: Fix circular include of asm/lse.h through linux/jump_label.h") from Linus' tree and commits: a4023f682739 ("arm64: Add hypervisor safe

linux-next: manual merge of the arm64 tree with Linus' tree

Hi Catalin, Today's linux-next merge of the arm64 tree got a conflict in: arch/arm64/include/asm/cpufeature.h between commit: 272d01bd790f ("arm64: Fix circular include of asm/lse.h through linux/jump_label.h") from Linus' tree and commits: a4023f682739 ("arm64: Add hypervisor safe

Re: [PATCH v2 4/4] spi: spi-fsl-dspi: Minor code cleanup and error path fixes

On 2016-11-20 21:54, Sanchayan Maity wrote: > Code cleanup for improving code readability and error path fixes > and cleanup removing use of devm_kfree. Two things in one, not very nice. Especially the dma_free_coherent is really a bug and the other is a cleanup. Can you make a separate patch for

Re: [PATCH v2 4/4] spi: spi-fsl-dspi: Minor code cleanup and error path fixes

On 2016-11-20 21:54, Sanchayan Maity wrote: > Code cleanup for improving code readability and error path fixes > and cleanup removing use of devm_kfree. Two things in one, not very nice. Especially the dma_free_coherent is really a bug and the other is a cleanup. Can you make a separate patch for

Re: [PATCH v2 3/4] spi: spi-fsl-dspi: Fix incorrect DMA setup

On 2016-11-20 21:54, Sanchayan Maity wrote: > Currently dmaengine_prep_slave_single was being called with length > set to the complete DMA buffer size. This resulted in unwanted bytes > being transferred to the SPI register leading to clock and MOSI lines > having unwanted data even after chip

Re: [PATCH v2 3/4] spi: spi-fsl-dspi: Fix incorrect DMA setup

On 2016-11-20 21:54, Sanchayan Maity wrote: > Currently dmaengine_prep_slave_single was being called with length > set to the complete DMA buffer size. This resulted in unwanted bytes > being transferred to the SPI register leading to clock and MOSI lines > having unwanted data even after chip

Re: [PATCH v2 2/4] spi: spi-fsl-dspi: Fix continuous selection format

On 2016-11-20 21:54, Sanchayan Maity wrote: > Current DMA implementation was not handling the continuous selection > format viz. SPI chip select would be deasserted even between sequential > serial transfers. Use the cs_change variable and correctly set or > reset the CONT bit accordingly for case

Re: [PATCH v2 2/4] spi: spi-fsl-dspi: Fix continuous selection format

On 2016-11-20 21:54, Sanchayan Maity wrote: > Current DMA implementation was not handling the continuous selection > format viz. SPI chip select would be deasserted even between sequential > serial transfers. Use the cs_change variable and correctly set or > reset the CONT bit accordingly for case

linux-next: manual merge of the rockchip tree with the arm-soc tree

Hi Heiko, Today's linux-next merge of the rockchip tree got a conflict in: arch/arm64/configs/defconfig between commit: a59294b2f7c7 ("ARM64: defconfig: Enable MMC related configs") from the arm-soc tree and commit: 5295a3157348 ("arm64: defconfig: enable RK808 components") from the

linux-next: manual merge of the rockchip tree with the arm-soc tree

Hi Heiko, Today's linux-next merge of the rockchip tree got a conflict in: arch/arm64/configs/defconfig between commit: a59294b2f7c7 ("ARM64: defconfig: Enable MMC related configs") from the arm-soc tree and commit: 5295a3157348 ("arm64: defconfig: enable RK808 components") from the

Re: [patch 00/12] thermal/x86_pkg_temp: Sanitize yet another hotplug and locking trainwreck

On Mon, 2016-11-21 at 22:34 +0100, Thomas Gleixner wrote: > On Mon, 21 Nov 2016, Pandruvada, Srinivas wrote: [...] > Stupid me. I tested putting a socket offline, which works, but did > not > check what happens on module removal. Delta fix below. That needs to > be > folded into the series as

Re: [patch 00/12] thermal/x86_pkg_temp: Sanitize yet another hotplug and locking trainwreck

On Mon, 2016-11-21 at 22:34 +0100, Thomas Gleixner wrote: > On Mon, 21 Nov 2016, Pandruvada, Srinivas wrote: [...] > Stupid me. I tested putting a socket offline, which works, but did > not > check what happens on module removal. Delta fix below. That needs to > be > folded into the series as

Re: [PATCH 1/2] clk: qcom: clk-smd-rpm: Fix clk_hw_onecell_data references

On 11/21, Georgi Djakov wrote: > The clk_hw_onecell_data struct is missing references to the > actual clocks. Fix this. > > Reported-by: Michael Scott > Signed-off-by: Georgi Djakov > --- > drivers/clk/qcom/clk-smd-rpm.c | 20

Re: [PATCH 1/2] clk: qcom: clk-smd-rpm: Fix clk_hw_onecell_data references

On 11/21, Georgi Djakov wrote: > The clk_hw_onecell_data struct is missing references to the > actual clocks. Fix this. > > Reported-by: Michael Scott > Signed-off-by: Georgi Djakov > --- > drivers/clk/qcom/clk-smd-rpm.c | 20 +--- > 1 file changed, 9 insertions(+), 11

[PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

One Thousand Gnomes wrote: > You need to filter or lock down kernel module options because a lot of > modules let you set the I/O port or similar (eg mmio) which means you can > hack the entire machine with say the 8250 driver just by using it with an > mmio of the

[PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

One Thousand Gnomes wrote: > You need to filter or lock down kernel module options because a lot of > modules let you set the I/O port or similar (eg mmio) which means you can > hack the entire machine with say the 8250 driver just by using it with an > mmio of the right location to patch the

[PATCH 0/2] mmc: sdhci-pci: Use ACPI to set max frequency of sdio host

On some boards, max SDIO frequency is limited by trace lengths and other layout choices. We would like a way to specify this limitation so the driver can behave accordingly. This patch set assumes that the limitation has been reported in an ACPI table which the driver can check to get the max

[PATCH 0/2] mmc: sdhci-pci: Use ACPI to set max frequency of sdio host

On some boards, max SDIO frequency is limited by trace lengths and other layout choices. We would like a way to specify this limitation so the driver can behave accordingly. This patch set assumes that the limitation has been reported in an ACPI table which the driver can check to get the max

[PATCH 2/2] mmc: sdhci-pci: Use ACPI to get max frequency for Intel byt sdio controller sub-vended by NI

On NI 9037 boards the max SDIO frequency is limited by trace lengths and other layout choices. The max SDIO frequency is stored in an ACPI table. The driver reads the ACPI entry MXFQ during sdio_probe_slot and sets the f_max field of the host. Signed-off-by: Nathan Sullivan

[PATCH 2/2] mmc: sdhci-pci: Use ACPI to get max frequency for Intel byt sdio controller sub-vended by NI

On NI 9037 boards the max SDIO frequency is limited by trace lengths and other layout choices. The max SDIO frequency is stored in an ACPI table. The driver reads the ACPI entry MXFQ during sdio_probe_slot and sets the f_max field of the host. Signed-off-by: Nathan Sullivan Reviewed-by: Jaeden

[PATCH 1/2] mmc: sdhci-pci: Add PCI ID for Intel byt sdio host controller sub-vended by NI

Add PCI ID for Intel byt sdio host controller sub-vended by NI. The controller has different behavior because of the board layout NI puts it on. Signed-off-by: Zach Brown --- drivers/mmc/host/sdhci-pci-core.c | 24 1 file changed, 24 insertions(+)

[PATCH 1/2] mmc: sdhci-pci: Add PCI ID for Intel byt sdio host controller sub-vended by NI

Add PCI ID for Intel byt sdio host controller sub-vended by NI. The controller has different behavior because of the board layout NI puts it on. Signed-off-by: Zach Brown --- drivers/mmc/host/sdhci-pci-core.c | 24 1 file changed, 24 insertions(+) diff --git

[PATCH] block,blkcg: use __GFP_NOWARN for best-effort allocations in blkcg

blkcg allocates some per-cgroup data structures with GFP_NOWAIT and when that fails falls back to operations which aren't specific to the cgroup. Occassional failures are expected under pressure and falling back to non-cgroup operation is the right thing to do. Unfortunately, I forgot to add

[PATCH] block,blkcg: use __GFP_NOWARN for best-effort allocations in blkcg

blkcg allocates some per-cgroup data structures with GFP_NOWAIT and when that fails falls back to operations which aren't specific to the cgroup. Occassional failures are expected under pressure and falling back to non-cgroup operation is the right thing to do. Unfortunately, I forgot to add

Re: [PATCH v2 1/9] PCI/PME: Drop unused support for PMEs from Root Complex Event Collectors

On Mon, Nov 21, 2016 at 11:58:09PM +0100, Rafael J. Wysocki wrote: > On Monday, November 21, 2016 04:42:10 PM Bjorn Helgaas wrote: > > On Mon, Nov 21, 2016 at 11:28:56PM +0100, Rafael J. Wysocki wrote: > > > On Monday, November 21, 2016 03:45:19 PM Bjorn Helgaas wrote: > > > > Since we register

Re: [PATCH v2 1/9] PCI/PME: Drop unused support for PMEs from Root Complex Event Collectors

On Mon, Nov 21, 2016 at 11:58:09PM +0100, Rafael J. Wysocki wrote: > On Monday, November 21, 2016 04:42:10 PM Bjorn Helgaas wrote: > > On Mon, Nov 21, 2016 at 11:28:56PM +0100, Rafael J. Wysocki wrote: > > > On Monday, November 21, 2016 03:45:19 PM Bjorn Helgaas wrote: > > > > Since we register

Re: [PATCH 2/2] trace: Add an option for boot clock as trace clock

On Mon, Nov 21, 2016 at 2:48 PM, kbuild test robot wrote: > Hi Joel, > > [auto build test ERROR on tip/timers/core] > [also build test ERROR on v4.9-rc6 next-20161117] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url:

Re: [PATCH 2/2] trace: Add an option for boot clock as trace clock

On Mon, Nov 21, 2016 at 2:48 PM, kbuild test robot wrote: > Hi Joel, > > [auto build test ERROR on tip/timers/core] > [also build test ERROR on v4.9-rc6 next-20161117] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: >

Re: [patch 4/8] x86/tsc: Verify TSC_ADJUST from idle

Thomas Gleixner writes: > When entering idle, it's a good oportunity to verify that the TSC_ADJUST > MSR has not been tampered with (BIOS hiding SMM cycles). If tampering is > detected, emit a warning and restore it to the previous value. idle entry is a time critical code

Re: [patch 4/8] x86/tsc: Verify TSC_ADJUST from idle

Thomas Gleixner writes: > When entering idle, it's a good oportunity to verify that the TSC_ADJUST > MSR has not been tampered with (BIOS hiding SMM cycles). If tampering is > detected, emit a warning and restore it to the previous value. idle entry is a time critical code path too, because

[PATCH] ACPI / property: Hierarchical properties support update

From: Rafael J. Wysocki The definition document of the Hierarchical Properties Extension UUID for _DSD has been changed recently to allow local references to be used as sub-node link targets (previously, it only allowed strings to be used for that purpose). Update

Re: [PATCH v2] iio: adc: New driver for TI ADS7950 chips

> > +static int ti_ads7950_read_raw(struct iio_dev *indio_dev, > > + struct iio_chan_spec const *chan, > > + int *val, int *val2, long m) > > +{ > > + struct ti_ads7950_state *st = iio_priv(indio_dev); > > + int ret; > > + > > + switch (m) {

Re: [PATCH v2] iio: adc: New driver for TI ADS7950 chips

> > +static int ti_ads7950_read_raw(struct iio_dev *indio_dev, > > + struct iio_chan_spec const *chan, > > + int *val, int *val2, long m) > > +{ > > + struct ti_ads7950_state *st = iio_priv(indio_dev); > > + int ret; > > + > > + switch (m) {

[PATCH] ACPI / property: Hierarchical properties support update

From: Rafael J. Wysocki The definition document of the Hierarchical Properties Extension UUID for _DSD has been changed recently to allow local references to be used as sub-node link targets (previously, it only allowed strings to be used for that purpose). Update the code in

Re: [PATCH v5 2/9] IB/core: Replace semaphore sm_sem with an atomic wait

On Monday, November 21, 2016 9:57:51 AM CET Linus Torvalds wrote: > > - semaphores are "old-fashioned mutexes". A mutex is better than a > semaphore, but a semaphore is better than just about all the other > alternatives. There's nothing _wrong_ with using a semaphore per se. > > In this case,

Re: [PATCH v5 2/9] IB/core: Replace semaphore sm_sem with an atomic wait

On Monday, November 21, 2016 9:57:51 AM CET Linus Torvalds wrote: > > - semaphores are "old-fashioned mutexes". A mutex is better than a > semaphore, but a semaphore is better than just about all the other > alternatives. There's nothing _wrong_ with using a semaphore per se. > > In this case,

Re: [PATCH v2 1/9] PCI/PME: Drop unused support for PMEs from Root Complex Event Collectors

On Monday, November 21, 2016 04:42:10 PM Bjorn Helgaas wrote: > On Mon, Nov 21, 2016 at 11:28:56PM +0100, Rafael J. Wysocki wrote: > > On Monday, November 21, 2016 03:45:19 PM Bjorn Helgaas wrote: > > > Since we register pcie_pme_driver only for PCI_EXP_TYPE_ROOT_PORT, the PME > > > driver never

Re: [PATCH v2 1/9] PCI/PME: Drop unused support for PMEs from Root Complex Event Collectors

On Monday, November 21, 2016 04:42:10 PM Bjorn Helgaas wrote: > On Mon, Nov 21, 2016 at 11:28:56PM +0100, Rafael J. Wysocki wrote: > > On Monday, November 21, 2016 03:45:19 PM Bjorn Helgaas wrote: > > > Since we register pcie_pme_driver only for PCI_EXP_TYPE_ROOT_PORT, the PME > > > driver never

Re: [kvm-unit-tests PATCH v10 3/3] arm: pmu: Add CPI checking

On 11/21/2016 03:40 PM, Christopher Covington wrote: > Hi Wei, > > On 11/21/2016 03:24 PM, Wei Huang wrote: >> From: Christopher Covington > > I really appreciate your work on these patches. If for any or all of these > you have more lines added/modified than me (or using

Re: [kvm-unit-tests PATCH v10 3/3] arm: pmu: Add CPI checking

On 11/21/2016 03:40 PM, Christopher Covington wrote: > Hi Wei, > > On 11/21/2016 03:24 PM, Wei Huang wrote: >> From: Christopher Covington > > I really appreciate your work on these patches. If for any or all of these > you have more lines added/modified than me (or using any other better >

Re: [PATCH 2/2] trace: Add an option for boot clock as trace clock

Hi Joel, [auto build test ERROR on tip/timers/core] [also build test ERROR on v4.9-rc6 next-20161117] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: linux-next: unable to fetch the watchdog tree

Hi Wim, On Mon, 14 Nov 2016 16:26:16 +0100 Wim Van Sebroeck wrote: > > This has been fixed. Thanks for notifying me about it. > > Kind regards, > Wim. > > > Hi Wim, > > > > For the past few days (nearly a week, sorry) fetching the watchdog tree > >

Re: [PATCH 2/2] trace: Add an option for boot clock as trace clock

Hi Joel, [auto build test ERROR on tip/timers/core] [also build test ERROR on v4.9-rc6 next-20161117] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: linux-next: unable to fetch the watchdog tree

Hi Wim, On Mon, 14 Nov 2016 16:26:16 +0100 Wim Van Sebroeck wrote: > > This has been fixed. Thanks for notifying me about it. > > Kind regards, > Wim. > > > Hi Wim, > > > > For the past few days (nearly a week, sorry) fetching the watchdog tree > >

Re: [PATCH v2 1/9] PCI/PME: Drop unused support for PMEs from Root Complex Event Collectors

On Mon, Nov 21, 2016 at 11:28:56PM +0100, Rafael J. Wysocki wrote: > On Monday, November 21, 2016 03:45:19 PM Bjorn Helgaas wrote: > > Since we register pcie_pme_driver only for PCI_EXP_TYPE_ROOT_PORT, the PME > > driver never claims Root Complex Event Collectors. > > > > Remove unused code

Re: [PATCH v2 1/9] PCI/PME: Drop unused support for PMEs from Root Complex Event Collectors

On Mon, Nov 21, 2016 at 11:28:56PM +0100, Rafael J. Wysocki wrote: > On Monday, November 21, 2016 03:45:19 PM Bjorn Helgaas wrote: > > Since we register pcie_pme_driver only for PCI_EXP_TYPE_ROOT_PORT, the PME > > driver never claims Root Complex Event Collectors. > > > > Remove unused code

Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On Tue, Nov 22 2016, Mark Brown wrote: > [ Unknown signature status ] > On Thu, Nov 17, 2016 at 05:46:13PM +1100, NeilBrown wrote: >> On Thu, Nov 17 2016, Mark Brown wrote: > >> > To me that's pretty much what's being done here, the code just happens >> > to sit in USB instead but fundamentally

Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On Tue, Nov 22 2016, Mark Brown wrote: > [ Unknown signature status ] > On Thu, Nov 17, 2016 at 05:46:13PM +1100, NeilBrown wrote: >> On Thu, Nov 17 2016, Mark Brown wrote: > >> > To me that's pretty much what's being done here, the code just happens >> > to sit in USB instead but fundamentally

[PATCH V5 05/10] acpi: apei: handle SEA notification type for ARMv8

ARM APEI extension proposal added SEA (Synchrounous External Abort) notification type for ARMv8. Add a new GHES error source handling function for SEA. If an error source's notification type is SEA, then this function can be registered into the SEA exception handler. That way GHES will parse and

[PATCH V5 04/10] arm64: exception: handle Synchronous External Abort

SEA exceptions are often caused by an uncorrected hardware error, and are handled when data abort and instruction abort exception classes have specific values for their Fault Status Code. When SEA occurs, before killing the process, go through the handlers registered in the notification list.

[PATCH V5 03/10] efi: parse ARMv8 processor error

Add support for ARMv8 Common Platform Error Record (CPER). UEFI 2.6 specification adds support for ARMv8 specific processor error information to be reported as part of the CPER records. This provides more detail on for processor error logs. Signed-off-by: Jonathan (Zhixiong) Zhang

[PATCH V5 05/10] acpi: apei: handle SEA notification type for ARMv8

ARM APEI extension proposal added SEA (Synchrounous External Abort) notification type for ARMv8. Add a new GHES error source handling function for SEA. If an error source's notification type is SEA, then this function can be registered into the SEA exception handler. That way GHES will parse and

[PATCH V5 04/10] arm64: exception: handle Synchronous External Abort

SEA exceptions are often caused by an uncorrected hardware error, and are handled when data abort and instruction abort exception classes have specific values for their Fault Status Code. When SEA occurs, before killing the process, go through the handlers registered in the notification list.

[PATCH V5 03/10] efi: parse ARMv8 processor error

Add support for ARMv8 Common Platform Error Record (CPER). UEFI 2.6 specification adds support for ARMv8 specific processor error information to be reported as part of the CPER records. This provides more detail on for processor error logs. Signed-off-by: Jonathan (Zhixiong) Zhang Signed-off-by:

[PATCH V5 07/10] efi: print unrecognized CPER section

UEFI spec allows for non-standard section in Common Platform Error Record. This is defined in section N.2.3 of UEFI version 2.5. Currently if the CPER section's type (UUID) does not match with one of the section types that the kernel knows how to parse, the section is skipped. Therefore, user is

[PATCH V5 07/10] efi: print unrecognized CPER section

UEFI spec allows for non-standard section in Common Platform Error Record. This is defined in section N.2.3 of UEFI version 2.5. Currently if the CPER section's type (UUID) does not match with one of the section types that the kernel knows how to parse, the section is skipped. Therefore, user is

[PATCH V5 10/10] arm/arm64: KVM: add guest SEA support

Currently external aborts are unsupported by the guest abort handling. Add handling for SEAs so that the host kernel reports SEAs which occur in the guest kernel. Signed-off-by: Tyler Baicar --- arch/arm/include/asm/kvm_arm.h | 1 +

[PATCH V5 06/10] acpi: apei: panic OS with fatal error status block

From: "Jonathan (Zhixiong) Zhang" Even if an error status block's severity is fatal, the kernel does not honor the severity level and panic. With the firmware first model, the platform could inform the OS about a fatal hardware error through the non-NMI GHES notification

[PATCH V5 09/10] trace, ras: add ARM processor error trace event

Currently there are trace events for the various RAS errors with the exception of ARM processor type errors. Add a new trace event for such errors so that the user will know when they occur. These trace events are consistent with the ARM processor error section type defined in UEFI 2.6 spec

[PATCH V5 08/10] ras: acpi / apei: generate trace event for unrecognized CPER section

UEFI spec allows for non-standard section in Common Platform Error Record. This is defined in section N.2.3 of UEFI version 2.5. Currently if the CPER section's type (UUID) does not match with any section type that the kernel knows how to parse, trace event is not generated for such section. And

[PATCH V5 10/10] arm/arm64: KVM: add guest SEA support

Currently external aborts are unsupported by the guest abort handling. Add handling for SEAs so that the host kernel reports SEAs which occur in the guest kernel. Signed-off-by: Tyler Baicar --- arch/arm/include/asm/kvm_arm.h | 1 + arch/arm/include/asm/system_misc.h | 5 +

[PATCH V5 06/10] acpi: apei: panic OS with fatal error status block

From: "Jonathan (Zhixiong) Zhang" Even if an error status block's severity is fatal, the kernel does not honor the severity level and panic. With the firmware first model, the platform could inform the OS about a fatal hardware error through the non-NMI GHES notification type. The OS should

[PATCH V5 09/10] trace, ras: add ARM processor error trace event

Currently there are trace events for the various RAS errors with the exception of ARM processor type errors. Add a new trace event for such errors so that the user will know when they occur. These trace events are consistent with the ARM processor error section type defined in UEFI 2.6 spec

[PATCH V5 08/10] ras: acpi / apei: generate trace event for unrecognized CPER section

UEFI spec allows for non-standard section in Common Platform Error Record. This is defined in section N.2.3 of UEFI version 2.5. Currently if the CPER section's type (UUID) does not match with any section type that the kernel knows how to parse, trace event is not generated for such section. And

[PATCH V5 00/10] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64

When a memory error, CPU error, PCIe error, or other type of hardware error that's covered by RAS occurs, firmware should populate the shared GHES memory location with the proper GHES structures to notify the OS of the error. For example, platforms that implement firmware first handling may

[PATCH V5 00/10] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64

When a memory error, CPU error, PCIe error, or other type of hardware error that's covered by RAS occurs, firmware should populate the shared GHES memory location with the proper GHES structures to notify the OS of the error. For example, platforms that implement firmware first handling may

[PATCH V5 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1

Currently when a RAS error is reported it is not timestamped. The ACPI 6.1 spec adds the timestamp field to the generic error data entry v3 structure. The timestamp of when the firmware generated the error is now being reported. Signed-off-by: Jonathan (Zhixiong) Zhang

[PATCH V5 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1

Currently when a RAS error is reported it is not timestamped. The ACPI 6.1 spec adds the timestamp field to the generic error data entry v3 structure. The timestamp of when the firmware generated the error is now being reported. Signed-off-by: Jonathan (Zhixiong) Zhang Signed-off-by: Richard

[PATCH V5 01/10] acpi: apei: read ack upon ghes record consumption

A RAS (Reliability, Availability, Serviceability) controller may be a separate processor running in parallel with OS execution, and may generate error records for consumption by the OS. If the RAS controller produces multiple error records, then they may be overwritten before the OS has consumed

[PATCH V5 01/10] acpi: apei: read ack upon ghes record consumption

A RAS (Reliability, Availability, Serviceability) controller may be a separate processor running in parallel with OS execution, and may generate error records for consumption by the OS. If the RAS controller produces multiple error records, then they may be overwritten before the OS has consumed

Re: [04/20] hwmon/coretemp: Convert to hotplug state machine

On 2016-11-20 14:30:55 [-0800], Guenter Roeck wrote: > Install, modprobe, modprobe -r, modprobe, > > [24078.179118] [ cut here ] > [24078.179124] WARNING: CPU: 0 PID: 14 at fs/sysfs/dir.c:31 > sysfs_warn_dup+0x6e/0x80 > [24078.179125] sysfs: cannot create duplicate

Re: [04/20] hwmon/coretemp: Convert to hotplug state machine

On 2016-11-20 14:30:55 [-0800], Guenter Roeck wrote: > Install, modprobe, modprobe -r, modprobe, > > [24078.179118] [ cut here ] > [24078.179124] WARNING: CPU: 0 PID: 14 at fs/sysfs/dir.c:31 > sysfs_warn_dup+0x6e/0x80 > [24078.179125] sysfs: cannot create duplicate

Re: [PATCH] ACPI: Override rev for DELL Latitude 3350

On Monday, November 21, 2016 10:07:05 AM AceLan Kao wrote: > The ethernet network fails to work on DELL Latitude 3350 after this commit >ea7d521 Revert 'Revert "ACPICA: Permanently set _REV to the value '2'."' > > dmesg shows >r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded >r8169

Re: [PATCH] ACPI: Override rev for DELL Latitude 3350

On Monday, November 21, 2016 10:07:05 AM AceLan Kao wrote: > The ethernet network fails to work on DELL Latitude 3350 after this commit >ea7d521 Revert 'Revert "ACPICA: Permanently set _REV to the value '2'."' > > dmesg shows >r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded >r8169

Re: [PATCH V5 2/2] PCI/ACPI: hisi: Add ACPI support for HiSilicon SoCs Host Controllers

On Mon, Nov 21, 2016 at 09:09:28AM +, Gabriele Paoloni wrote: > > > +config PCI_HISI_ACPI > > > + depends on ACPI && ARM64 > > > + bool "HiSilicon Hip05 and Hip06 and Hip07 SoCs ACPI PCIe > > controllers" > > > + select PNP > > > + help > > > + Say Y here if you want ACPI PCIe controller

Re: [PATCH V5 2/2] PCI/ACPI: hisi: Add ACPI support for HiSilicon SoCs Host Controllers

On Mon, Nov 21, 2016 at 09:09:28AM +, Gabriele Paoloni wrote: > > > +config PCI_HISI_ACPI > > > + depends on ACPI && ARM64 > > > + bool "HiSilicon Hip05 and Hip06 and Hip07 SoCs ACPI PCIe > > controllers" > > > + select PNP > > > + help > > > + Say Y here if you want ACPI PCIe controller

Re: [PATCH v2 2/2] trace: Add an option for boot clock as trace clock

On Mon, 21 Nov 2016 14:12:50 -0800 Joel Fernandes wrote: > Unlike monotonic clock, boot clock as a trace clock will account for > time spent in suspend useful for tracing suspend/resume. This uses > earlier introduced infrastructure for using the fast boot clock. > > Cc:

Re: [PATCH v2 2/2] trace: Add an option for boot clock as trace clock

On Mon, 21 Nov 2016 14:12:50 -0800 Joel Fernandes wrote: > Unlike monotonic clock, boot clock as a trace clock will account for > time spent in suspend useful for tracing suspend/resume. This uses > earlier introduced infrastructure for using the fast boot clock. > > Cc: Steven Rostedt > Cc:

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