Re: [PATCH] Add kernel parameter to blacklist modules

Prarit Bhargava writes: > Blacklisting a module in linux has long been a problem. The process of > blacklisting a module has changed over time, and it seems that every OS > does it slightly differently and depends on the age of the init system > used on that OS. Hi Prarit,

Re: [PATCH] Add kernel parameter to blacklist modules

Prarit Bhargava writes: > Blacklisting a module in linux has long been a problem. The process of > blacklisting a module has changed over time, and it seems that every OS > does it slightly differently and depends on the age of the init system > used on that OS. Hi Prarit, I don't mind

Re: [linux-sunxi] [PATCH v3 10/13] spi: sunxi: merge sun4i and sun6i SPI driver

Hi Michal, On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek wrote: > The drivers are very similar and share multiple flaws which needed > separate fixes for both drivers. > > Signed-off-by: Michal Suchanek > --- > drivers/spi/Kconfig | 8 +- >

Re: [linux-sunxi] [PATCH v3 10/13] spi: sunxi: merge sun4i and sun6i SPI driver

Hi Michal, On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek wrote: > The drivers are very similar and share multiple flaws which needed > separate fixes for both drivers. > > Signed-off-by: Michal Suchanek > --- > drivers/spi/Kconfig | 8 +- > drivers/spi/Makefile| 1 - >

[PATCH] drm/i915: Fix missing unlock on error in i915_ppgtt_info()

From: Wei Yongjun Add the missing unlock before return from function i915_ppgtt_info() in the error handling case. Fixes: 1d2ac403ae3b(drm: Protect dev->filelist with its own mutex) Signed-off-by: Wei Yongjun ---

[PATCH] drm/i915: Fix missing unlock on error in i915_ppgtt_info()

From: Wei Yongjun Add the missing unlock before return from function i915_ppgtt_info() in the error handling case. Fixes: 1d2ac403ae3b(drm: Protect dev->filelist with its own mutex) Signed-off-by: Wei Yongjun --- drivers/gpu/drm/i915/i915_debugfs.c | 4 ++-- 1 file changed, 2 insertions(+), 2

linux-next: duplicate patches in the kspp and kbuild trees

Hi Kees, As of today, there are four duplicate patches (different commits) in the kspp and kbuild trees. Shared library support GCC plugin infrastructure Add Cyclomatic complexity GCC plugin Add sancov plugin are in both trees as different commits :-( They have been in the kbuild tree

linux-next: duplicate patches in the kspp and kbuild trees

Hi Kees, As of today, there are four duplicate patches (different commits) in the kspp and kbuild trees. Shared library support GCC plugin infrastructure Add Cyclomatic complexity GCC plugin Add sancov plugin are in both trees as different commits :-( They have been in the kbuild tree

Re: [linux-sunxi] [PATCH v3 07/13] spi: sunxi: rename constants to match between sun4i and sun6i

Hi Michal, On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek wrote: > SUNXI_CTL_ -> SUNXI_TFR_CTL_ > SUNXI_TFR_CTL_LMTF -> SUNXI_TFR_CTL_FBS I don't know these abbreviations, are they both referring to the same thing? > SUNXI_TFR_CTL_CS_ACTIVE_LOW -> SUNXI_TFR_CTL_SPOL It

[PATCH] phy: rockchip-dp: fix return value check in rockchip_dp_phy_probe()

From: Wei Yongjun In case of error, the function devm_kzalloc() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Signed-off-by: Wei Yongjun ---

Re: [linux-sunxi] [PATCH v3 07/13] spi: sunxi: rename constants to match between sun4i and sun6i

Hi Michal, On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek wrote: > SUNXI_CTL_ -> SUNXI_TFR_CTL_ > SUNXI_TFR_CTL_LMTF -> SUNXI_TFR_CTL_FBS I don't know these abbreviations, are they both referring to the same thing? > SUNXI_TFR_CTL_CS_ACTIVE_LOW -> SUNXI_TFR_CTL_SPOL It looks like you're

[PATCH] phy: rockchip-dp: fix return value check in rockchip_dp_phy_probe()

From: Wei Yongjun In case of error, the function devm_kzalloc() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Signed-off-by: Wei Yongjun --- drivers/phy/phy-rockchip-dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH tip/master] [BUGFIX] kprobes/x86: Fix to clear TF bit in fault-on-single-stepping

On Mon, 13 Jun 2016 19:13:45 -0400 Steven Rostedt wrote: > > # cd /sys/kernel/debug/tracing > > # echo p copy_user_enhanced_fast_string+5 > kprobe_events > > # echo 1 > events/kprobes/enable > > > > And you'll see a kernel panic on do_debug(), since the debug > >

Re: [PATCH tip/master] [BUGFIX] kprobes/x86: Fix to clear TF bit in fault-on-single-stepping

On Mon, 13 Jun 2016 19:13:45 -0400 Steven Rostedt wrote: > > # cd /sys/kernel/debug/tracing > > # echo p copy_user_enhanced_fast_string+5 > kprobe_events > > # echo 1 > events/kprobes/enable > > > > And you'll see a kernel panic on do_debug(), since the debug > > trap is not handled by

Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices

Thanks Toshi! On Mon, Jun 13, 2016 at 3:21 PM, Toshi Kani wrote: > This patch-set adds DAX support to device-mapper dm-linear devices > used by LVM. It works with LVM commands as follows: > - Creation of a logical volume with all DAX capable devices (such >as pmem) sets

Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices

Thanks Toshi! On Mon, Jun 13, 2016 at 3:21 PM, Toshi Kani wrote: > This patch-set adds DAX support to device-mapper dm-linear devices > used by LVM. It works with LVM commands as follows: > - Creation of a logical volume with all DAX capable devices (such >as pmem) sets the logical volume

Re: [PATCH] ARM: mm: fix location of _etext

On Mon, Jun 13, 2016 at 2:25 PM, Russell King - ARM Linux wrote: > On Mon, Jun 13, 2016 at 01:23:29PM -0700, Kees Cook wrote: >> On Wed, Jun 8, 2016 at 4:11 PM, Kees Cook wrote: >> > The _etext position is defined to be the end of the kernel text

Re: [PATCH] ARM: mm: fix location of _etext

On Mon, Jun 13, 2016 at 2:25 PM, Russell King - ARM Linux wrote: > On Mon, Jun 13, 2016 at 01:23:29PM -0700, Kees Cook wrote: >> On Wed, Jun 8, 2016 at 4:11 PM, Kees Cook wrote: >> > The _etext position is defined to be the end of the kernel text code, >> > and should not include any part of the

Re: [PATCH tip/master] [BUGFIX] kprobes/x86: Fix to clear TF bit in fault-on-single-stepping

On Sat, 11 Jun 2016 23:06:53 +0900 Masami Hiramatsu wrote: > Fix kprobe_fault_handler to clear TF (trap flag) bit of > flags register in the case of fault fixup on single-stepping. > > If we put a kprobe on the instruction which can cause a > page fault (e.g. actual mov

Re: [PATCH tip/master] [BUGFIX] kprobes/x86: Fix to clear TF bit in fault-on-single-stepping

On Sat, 11 Jun 2016 23:06:53 +0900 Masami Hiramatsu wrote: > Fix kprobe_fault_handler to clear TF (trap flag) bit of > flags register in the case of fault fixup on single-stepping. > > If we put a kprobe on the instruction which can cause a > page fault (e.g. actual mov instructions in

[PATCH v2 01/11] phy: rockchip-emmc: Increase lock time allowance

Previous PHY code waited a fixed amount of time for the DLL to lock at power on time. Unfortunately, the time for the DLL to lock is actually a bit more dynamic and can be longer if the card clock is slower. Instead of waiting a fixed 30 us, let's now dynamically wait until the lock bit gets

[PATCH v2 01/11] phy: rockchip-emmc: Increase lock time allowance

Previous PHY code waited a fixed amount of time for the DLL to lock at power on time. Unfortunately, the time for the DLL to lock is actually a bit more dynamic and can be longer if the card clock is slower. Instead of waiting a fixed 30 us, let's now dynamically wait until the lock bit gets

[PATCH v2 03/11] Documentation: mmc: sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs

As can be seen in Arasan's datasheet [1] there are several "corecfg" settings in their SDHCI IP Block that are supposed to be controlled by software. Although the datasheet referenced is a bit vague about how to access corecfg, in Figure 5 you can see that for Arasan's PHY (a separate component

[PATCH v2 03/11] Documentation: mmc: sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs

As can be seen in Arasan's datasheet [1] there are several "corecfg" settings in their SDHCI IP Block that are supposed to be controlled by software. Although the datasheet referenced is a bit vague about how to access corecfg, in Figure 5 you can see that for Arasan's PHY (a separate component

[PATCH v2 05/11] arm64: dts: rockchip: Add soc-ctl-syscon to sdhci for rk3399

On rk3399 we'd like to be able to properly set corecfg registers in the Arasan SDHCI component. Specify the syscon to enable that. Signed-off-by: Douglas Anderson --- Changes in v2: None arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1 + 1 file changed, 1 insertion(+)

[PATCH v2 05/11] arm64: dts: rockchip: Add soc-ctl-syscon to sdhci for rk3399

On rk3399 we'd like to be able to properly set corecfg registers in the Arasan SDHCI component. Specify the syscon to enable that. Signed-off-by: Douglas Anderson --- Changes in v2: None arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v2 10/11] phy: rockchip-emmc: Set phyctrl_frqsel based on card clock

The "phyctrl_frqsel" is described in the Arasan datasheet [1] as "the frequency range of DLL operation". Although the Rockchip variant of this PHY has different ranges than the reference Arasan PHY it appears as if the functionality is similar. We should set this phyctrl field properly. Note:

[PATCH v2 06/11] Documentation: mmc: sdhci-of-arasan: Add ability to export card clock

Some SD/eMMC PHYs (like the PHY from Arasan that is designed to work with arasan,sdhci-5.1) need to know the card clock frequency in order to function properly. Physically in a SoC this clock is exported from the SDHCI IP block to the PHY IP block and the PHY needs to know the speed. Let's export

[PATCH v2 11/11] arm64: dts: rockchip: Provide emmcclk to PHY for rk3399

Previous changes in this series allowed exposing the card clock from the rk3399 SDHCI device and allowed consuming the card clock in the rk3399 eMMC PHY. Hook things up in the main rk3399 dtsi file. Signed-off-by: Douglas Anderson --- Changes in v2: None

[PATCH v2 10/11] phy: rockchip-emmc: Set phyctrl_frqsel based on card clock

The "phyctrl_frqsel" is described in the Arasan datasheet [1] as "the frequency range of DLL operation". Although the Rockchip variant of this PHY has different ranges than the reference Arasan PHY it appears as if the functionality is similar. We should set this phyctrl field properly. Note:

[PATCH v2 06/11] Documentation: mmc: sdhci-of-arasan: Add ability to export card clock

Some SD/eMMC PHYs (like the PHY from Arasan that is designed to work with arasan,sdhci-5.1) need to know the card clock frequency in order to function properly. Physically in a SoC this clock is exported from the SDHCI IP block to the PHY IP block and the PHY needs to know the speed. Let's export

[PATCH v2 11/11] arm64: dts: rockchip: Provide emmcclk to PHY for rk3399

Previous changes in this series allowed exposing the card clock from the rk3399 SDHCI device and allowed consuming the card clock in the rk3399 eMMC PHY. Hook things up in the main rk3399 dtsi file. Signed-off-by: Douglas Anderson --- Changes in v2: None

[PATCH v2 08/11] Documentation: phy: Let the rockchip eMMC PHY get an exported card clock

As of an earlier change in this series ("Documentation: mmc: sdhci-of-arasan: Add ability to export card clock") the SDHCI driver used on Rockchip SoCs can now expose its clock. Let's now specify that the PHY can use it. Letting the PHY get access to this clock means it can adjust phyctrl_frqsel

[PATCH v2 08/11] Documentation: phy: Let the rockchip eMMC PHY get an exported card clock

As of an earlier change in this series ("Documentation: mmc: sdhci-of-arasan: Add ability to export card clock") the SDHCI driver used on Rockchip SoCs can now expose its clock. Let's now specify that the PHY can use it. Letting the PHY get access to this clock means it can adjust phyctrl_frqsel

[PATCH v2 09/11] phy: rockchip-emmc: Minor code cleanup in rockchip_emmc_phy_power_on/off()

There's no reason to store the return value of rockchip_emmc_phy_power() in a variable nor to check it. Just return it. Signed-off-by: Douglas Anderson --- Changes in v2: - Move code cleanup before set phyctrl_frqsel based on card clock (Shawn)

Re: [PATCH 02/11] mmc: sdhci-of-arasan: Always power the PHY off/on when clock changes

Hi, On Mon, Jun 13, 2016 at 1:08 AM, Shawn Lin wrote: > 在 2016/6/8 6:44, Douglas Anderson 写道: >> >> In commit 802ac39a5566 ("mmc: sdhci-of-arasan: fix set_clock when a phy >> is supported") we added code to power the PHY off and on whenever the >> clock was changed but

Re: [PATCH 01/11] phy: rockchip-emmc: Increase lock time allowance

Shawn, On Mon, Jun 13, 2016 at 12:58 AM, Shawn Lin wrote: > On 2016/6/8 6:44, Douglas Anderson wrote: >> >> Previous PHY code waited a fixed amount of time for the DLL to lock at >> power on time. Unfortunately, the time for the DLL to lock is actually >> a bit more

Re: [PATCH 03/11] Documentation: mmc: sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs

Hi, On Mon, Jun 13, 2016 at 1:18 AM, Shawn Lin wrote: > On 2016/6/8 6:44, Douglas Anderson wrote: >> >> As can be seen in Arasan's datasheet [1] there are several "corecfg" >> settings in their SDHCI IP Block that are supposed to be controlled by >> software. Although

[PATCH v2 09/11] phy: rockchip-emmc: Minor code cleanup in rockchip_emmc_phy_power_on/off()

There's no reason to store the return value of rockchip_emmc_phy_power() in a variable nor to check it. Just return it. Signed-off-by: Douglas Anderson --- Changes in v2: - Move code cleanup before set phyctrl_frqsel based on card clock (Shawn) drivers/phy/phy-rockchip-emmc.c | 14

Re: [PATCH 02/11] mmc: sdhci-of-arasan: Always power the PHY off/on when clock changes

Hi, On Mon, Jun 13, 2016 at 1:08 AM, Shawn Lin wrote: > 在 2016/6/8 6:44, Douglas Anderson 写道: >> >> In commit 802ac39a5566 ("mmc: sdhci-of-arasan: fix set_clock when a phy >> is supported") we added code to power the PHY off and on whenever the >> clock was changed but we avoided doing the power

Re: [PATCH 01/11] phy: rockchip-emmc: Increase lock time allowance

Shawn, On Mon, Jun 13, 2016 at 12:58 AM, Shawn Lin wrote: > On 2016/6/8 6:44, Douglas Anderson wrote: >> >> Previous PHY code waited a fixed amount of time for the DLL to lock at >> power on time. Unfortunately, the time for the DLL to lock is actually >> a bit more dynamic and can be longer if

Re: [PATCH 03/11] Documentation: mmc: sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs

Hi, On Mon, Jun 13, 2016 at 1:18 AM, Shawn Lin wrote: > On 2016/6/8 6:44, Douglas Anderson wrote: >> >> As can be seen in Arasan's datasheet [1] there are several "corecfg" >> settings in their SDHCI IP Block that are supposed to be controlled by >> software. Although the datasheet referenced

Re: [PATCH 10/11] phy: rockchip-emmc: Minor code cleanup in rockchip_emmc_phy_power_off()

Hi, On Mon, Jun 13, 2016 at 1:56 AM, Shawn Lin wrote: > On 2016/6/8 6:44, Douglas Anderson wrote: >> >> There's no reason to store the return value of rockchip_emmc_phy_power() >> in a variable nor to check it. Just return it. >> >> Signed-off-by: Douglas Anderson

Re: [PATCH 04/11] mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399

Shawn, On Mon, Jun 13, 2016 at 1:36 AM, Shawn Lin wrote: > 在 2016/6/8 6:44, Douglas Anderson 写道: >> >> In the the earlier change in this series ("Documentation: mmc: >> sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs") we can see the >> mechansim for specifying a

[PATCH v2 07/11] mmc: sdhci-of-arasan: Add ability to export card clock

Some SD/eMMC PHYs (like the PHY from Arasan that is designed to work with arasan,sdhci-5.1) need to know the card clock in order to function properly. Let's add the ability to expose this clock. Any PHY that needs to know the clock rate can add a reference and query the clock rate. At the

Re: [PATCH 06/11] Documentation: mmc: sdhci-of-arasan: Add ability to export card clock

Rob, On Fri, Jun 10, 2016 at 6:10 AM, Rob Herring wrote: > On Wed, Jun 08, 2016 at 01:52:20PM -0700, Doug Anderson wrote: >> Rob, >> >> On Wed, Jun 8, 2016 at 1:19 PM, Rob Herring wrote: >> > On Tue, Jun 07, 2016 at 03:44:39PM -0700, Douglas Anderson wrote: >>

Re: [PATCH 10/11] phy: rockchip-emmc: Minor code cleanup in rockchip_emmc_phy_power_off()

Hi, On Mon, Jun 13, 2016 at 1:56 AM, Shawn Lin wrote: > On 2016/6/8 6:44, Douglas Anderson wrote: >> >> There's no reason to store the return value of rockchip_emmc_phy_power() >> in a variable nor to check it. Just return it. >> >> Signed-off-by: Douglas Anderson >> --- >>

Re: [PATCH 04/11] mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399

Shawn, On Mon, Jun 13, 2016 at 1:36 AM, Shawn Lin wrote: > 在 2016/6/8 6:44, Douglas Anderson 写道: >> >> In the the earlier change in this series ("Documentation: mmc: >> sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs") we can see the >> mechansim for specifying a syscon to properly set

[PATCH v2 07/11] mmc: sdhci-of-arasan: Add ability to export card clock

Some SD/eMMC PHYs (like the PHY from Arasan that is designed to work with arasan,sdhci-5.1) need to know the card clock in order to function properly. Let's add the ability to expose this clock. Any PHY that needs to know the clock rate can add a reference and query the clock rate. At the

Re: [PATCH 06/11] Documentation: mmc: sdhci-of-arasan: Add ability to export card clock

Rob, On Fri, Jun 10, 2016 at 6:10 AM, Rob Herring wrote: > On Wed, Jun 08, 2016 at 01:52:20PM -0700, Doug Anderson wrote: >> Rob, >> >> On Wed, Jun 8, 2016 at 1:19 PM, Rob Herring wrote: >> > On Tue, Jun 07, 2016 at 03:44:39PM -0700, Douglas Anderson wrote: >> >> Some SD/eMMC PHYs (like the PHY

Re: [PATCH 08/11] Documentation: phy: Let the rockchip eMMC PHY get an exported card clock

Rob, On Fri, Jun 10, 2016 at 6:36 AM, Rob Herring wrote: > On Tue, Jun 07, 2016 at 03:44:41PM -0700, Douglas Anderson wrote: >> As of an earlier change in this series ("Documentation: mmc: >> sdhci-of-arasan: Add ability to export card clock") the SDHCI driver >> used on

Re: [PATCH 09/11] phy: rockchip-emmc: Set phyctrl_frqsel based on card clock

Shawn, On Mon, Jun 13, 2016 at 1:54 AM, Shawn Lin wrote: > On 2016/6/8 6:44, Douglas Anderson wrote: >> >> The "phyctrl_frqsel" is described in the Arasan datasheet [1] as "the >> frequency range of DLL operation". Although the Rockchip variant of >> this PHY has

Re: [PATCH 08/11] Documentation: phy: Let the rockchip eMMC PHY get an exported card clock

Rob, On Fri, Jun 10, 2016 at 6:36 AM, Rob Herring wrote: > On Tue, Jun 07, 2016 at 03:44:41PM -0700, Douglas Anderson wrote: >> As of an earlier change in this series ("Documentation: mmc: >> sdhci-of-arasan: Add ability to export card clock") the SDHCI driver >> used on Rockchip SoCs can now

Re: [PATCH 09/11] phy: rockchip-emmc: Set phyctrl_frqsel based on card clock

Shawn, On Mon, Jun 13, 2016 at 1:54 AM, Shawn Lin wrote: > On 2016/6/8 6:44, Douglas Anderson wrote: >> >> The "phyctrl_frqsel" is described in the Arasan datasheet [1] as "the >> frequency range of DLL operation". Although the Rockchip variant of >> this PHY has different ranges than the

[PATCH v2 04/11] mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399

In the the earlier change in this series ("Documentation: mmc: sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs") we can see the mechansim for specifying a syscon to properly set corecfg registers in sdhci-of-arasan. Now let's use this mechanism to properly set corecfg_baseclkfreq on rk3399.

[PATCH v2 02/11] mmc: sdhci-of-arasan: Always power the PHY off/on when clock changes

In commit 802ac39a5566 ("mmc: sdhci-of-arasan: fix set_clock when a phy is supported") we added code to power the PHY off and on whenever the clock was changed but we avoided doing the power cycle code when the clock was low speed. Let's now do it always. Although there may be other reasons for

[PATCH v2 0/11] Changes to support 150 MHz eMMC on rk3399

The theme of this series of patches is to try to allow running the eMMC at 150 MHz on the rk3399 SoC, though the changes should still be correct and have merit on their own. The motivation for running at 150 MHz is that doing so improves signal integrity and (with some eMMC devices) doesn't

[PATCH v2 04/11] mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399

In the the earlier change in this series ("Documentation: mmc: sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs") we can see the mechansim for specifying a syscon to properly set corecfg registers in sdhci-of-arasan. Now let's use this mechanism to properly set corecfg_baseclkfreq on rk3399.

[PATCH v2 02/11] mmc: sdhci-of-arasan: Always power the PHY off/on when clock changes

In commit 802ac39a5566 ("mmc: sdhci-of-arasan: fix set_clock when a phy is supported") we added code to power the PHY off and on whenever the clock was changed but we avoided doing the power cycle code when the clock was low speed. Let's now do it always. Although there may be other reasons for

[PATCH v2 0/11] Changes to support 150 MHz eMMC on rk3399

The theme of this series of patches is to try to allow running the eMMC at 150 MHz on the rk3399 SoC, though the changes should still be correct and have merit on their own. The motivation for running at 150 MHz is that doing so improves signal integrity and (with some eMMC devices) doesn't

Re: [PATCH v2 0/4] ACPI 2.0: Enable TermList interpretion for table loading

On 6/12/2016 3:02 AM, Zheng, Lv wrote: Hi, From: Wysocki, Rafael J Subject: Re: [PATCH v2 0/4] ACPI 2.0: Enable TermList interpretion for table loading On 5/20/2016 2:57 AM, Zheng, Lv wrote: Hi, Rafael From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of Rafael J. Wysocki

Re: [PATCH v2 0/4] ACPI 2.0: Enable TermList interpretion for table loading

On 6/12/2016 3:02 AM, Zheng, Lv wrote: Hi, From: Wysocki, Rafael J Subject: Re: [PATCH v2 0/4] ACPI 2.0: Enable TermList interpretion for table loading On 5/20/2016 2:57 AM, Zheng, Lv wrote: Hi, Rafael From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of Rafael J. Wysocki

Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices

On Mon, Jun 13 2016 at 6:21pm -0400, Toshi Kani wrote: > This patch-set adds DAX support to device-mapper dm-linear devices > used by LVM. It works with LVM commands as follows: > - Creation of a logical volume with all DAX capable devices (such >as pmem) sets the

Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices

On Mon, Jun 13 2016 at 6:21pm -0400, Toshi Kani wrote: > This patch-set adds DAX support to device-mapper dm-linear devices > used by LVM. It works with LVM commands as follows: > - Creation of a logical volume with all DAX capable devices (such >as pmem) sets the logical volume DAX

Re: [PATCH] x86 / hibernate: Fix 64-bit code passing control to image kernel

On Mon, Jun 13, 2016 at 3:15 PM, Rafael J. Wysocki wrote: > On Monday, June 13, 2016 02:58:57 PM Kees Cook wrote: >> On Mon, Jun 13, 2016 at 6:42 AM, Rafael J. Wysocki >> wrote: >> > From: Rafael J. Wysocki >> > >> > Logan

Re: [PATCH] x86 / hibernate: Fix 64-bit code passing control to image kernel

On Mon, Jun 13, 2016 at 3:15 PM, Rafael J. Wysocki wrote: > On Monday, June 13, 2016 02:58:57 PM Kees Cook wrote: >> On Mon, Jun 13, 2016 at 6:42 AM, Rafael J. Wysocki >> wrote: >> > From: Rafael J. Wysocki >> > >> > Logan Gunthorpe reports that hibernation stopped working reliably for >> >

Re: [PATCH 3.16 046/114] batman-adv: Fix broadcast/ogm queue limit on a removed interface

On Mon, 2016-06-13 at 21:33 +0200, Sven Eckelmann wrote: > Hi, > > looks like the patch is broken (at least it does something different than the  > non-stable patch does). > > On Monday 13 June 2016 19:36:37 Ben Hutchings wrote: > > 3.16.36-rc1 review patch.  If anyone has any objections, please

Re: [PATCH 3.16 046/114] batman-adv: Fix broadcast/ogm queue limit on a removed interface

On Mon, 2016-06-13 at 21:33 +0200, Sven Eckelmann wrote: > Hi, > > looks like the patch is broken (at least it does something different than the  > non-stable patch does). > > On Monday 13 June 2016 19:36:37 Ben Hutchings wrote: > > 3.16.36-rc1 review patch.  If anyone has any objections, please

RE: linux-4.7-rc3/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:4836: wierd condition ?

> -Original Message- > From: David Binderman [mailto:linuxdev.baldr...@gmail.com] > Sent: Monday, June 13, 2016 4:16 AM > To: Deucher, Alexander; Koenig, Christian; airl...@linux.ie; dri- > de...@lists.freedesktop.org; linux-kernel@vger.kernel.org; > dcb...@hotmail.com > Subject:

RE: linux-4.7-rc3/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:4836: wierd condition ?

> -Original Message- > From: David Binderman [mailto:linuxdev.baldr...@gmail.com] > Sent: Monday, June 13, 2016 4:16 AM > To: Deucher, Alexander; Koenig, Christian; airl...@linux.ie; dri- > de...@lists.freedesktop.org; linux-kernel@vger.kernel.org; > dcb...@hotmail.com > Subject:

Re: [PATCH] clk: rockchip: add flag CLK_SET_RATE_PARENT for dclk_vop0_div on RK3399

Am Sonntag, 12. Juni 2016, 17:48:48 schrieb Xing Zheng: > The functions and features VOP0 more complete than VOP1's, we need to > use it dclk_vop0_div operate VPLLI, and let VOP0 as the default primary > screen. > > Signed-off-by: Xing Zheng > --- > >

Re: [PATCH 2/3] Kbuild: don't add obj tree in additional includes

Hi, [auto build test ERROR on kbuild/for-next] [also build test ERROR on v4.7-rc3 next-20160609] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] clk: rockchip: add flag CLK_SET_RATE_PARENT for dclk_vop0_div on RK3399

Am Sonntag, 12. Juni 2016, 17:48:48 schrieb Xing Zheng: > The functions and features VOP0 more complete than VOP1's, we need to > use it dclk_vop0_div operate VPLLI, and let VOP0 as the default primary > screen. > > Signed-off-by: Xing Zheng > --- > > drivers/clk/rockchip/clk-rk3399.c |2

Re: [PATCH 2/3] Kbuild: don't add obj tree in additional includes

Hi, [auto build test ERROR on kbuild/for-next] [also build test ERROR on v4.7-rc3 next-20160609] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 2/3] Kbuild: don't add obj tree in additional includes

Hi, [auto build test ERROR on kbuild/for-next] [also build test ERROR on v4.7-rc3 next-20160609] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 2/3] Kbuild: don't add obj tree in additional includes

Hi, [auto build test ERROR on kbuild/for-next] [also build test ERROR on v4.7-rc3 next-20160609] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] gpio: add Intel WhiskeyCove GPIO driver

On Mon, Jun 13, 2016 at 02:43:16PM +0200, Linus Walleij wrote: > On Sat, Jun 11, 2016 at 8:01 AM, Bin Gao wrote: > > > This patch introduces a separate GPIO driver for Intel WhiskeyCove PMIC. > > This driver is based on gpio-crystalcove.c. > > > > Signed-off-by: Ajay

[PATCH 07/30] drbd: adjust assert in w_bitmap_io to account for BM_LOCKED_CHANGE_ALLOWED

From: Lars Ellenberg Signed-off-by: Philipp Reisner Signed-off-by: Lars Ellenberg --- drivers/block/drbd/drbd_main.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git

[PATCH] writeback: inode cgroup wb switch should skip inode with zero i_count

Asynchronous wb switching of inodes takes an additional ref count on an inode to make sure inode remains valid until switchover is completed. However, it is possible that inode->i_count has already reached zero while inode is in writeback queue: [ cut here ] WARNING: CPU:

Re: [PATCH] gpio: add Intel WhiskeyCove GPIO driver

On Mon, Jun 13, 2016 at 02:43:16PM +0200, Linus Walleij wrote: > On Sat, Jun 11, 2016 at 8:01 AM, Bin Gao wrote: > > > This patch introduces a separate GPIO driver for Intel WhiskeyCove PMIC. > > This driver is based on gpio-crystalcove.c. > > > > Signed-off-by: Ajay Thomas > > Signed-off-by:

[PATCH 07/30] drbd: adjust assert in w_bitmap_io to account for BM_LOCKED_CHANGE_ALLOWED

From: Lars Ellenberg Signed-off-by: Philipp Reisner Signed-off-by: Lars Ellenberg --- drivers/block/drbd/drbd_main.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/block/drbd/drbd_main.c b/drivers/block/drbd/drbd_main.c index b0891c3..64e9525 100644 ---

[PATCH] writeback: inode cgroup wb switch should skip inode with zero i_count

Asynchronous wb switching of inodes takes an additional ref count on an inode to make sure inode remains valid until switchover is completed. However, it is possible that inode->i_count has already reached zero while inode is in writeback queue: [ cut here ] WARNING: CPU:

[PATCH 04/30] drbd: Implement handling of thinly provisioned storage on resync target nodes

If during resync we read only zeroes for a range of sectors assume that these secotors can be discarded on the sync target node. Signed-off-by: Philipp Reisner Signed-off-by: Lars Ellenberg --- drivers/block/drbd/drbd_int.h | 5 +++

[PATCH 04/30] drbd: Implement handling of thinly provisioned storage on resync target nodes

If during resync we read only zeroes for a range of sectors assume that these secotors can be discarded on the sync target node. Signed-off-by: Philipp Reisner Signed-off-by: Lars Ellenberg --- drivers/block/drbd/drbd_int.h | 5 +++ drivers/block/drbd/drbd_main.c | 18

[PATCH 08/30] drbd: fix regression: protocol A sometimes synchronous, C sometimes double-latency

From: Lars Ellenberg Regression introduced with 8.4.5 drbd: application writes may set-in-sync in protocol != C Overwriting the same block (LBA) while a former version is still "in-flight" to the peer (to be exact: we did not receive the P_BARRIER_ACK for its epoch

Re: [PATCH] clocksource: kona: avoid bogus warning

Hi Arnd, On 6/13/2016 1:40 PM, Arnd Bergmann wrote: I could not figure out why, but gcc cannot prove that the kona_timer_init function always initializes its two outputs, and we get a warning for the use of the 'lsw' variable later, which is obviously correct.

[PATCH 08/30] drbd: fix regression: protocol A sometimes synchronous, C sometimes double-latency

From: Lars Ellenberg Regression introduced with 8.4.5 drbd: application writes may set-in-sync in protocol != C Overwriting the same block (LBA) while a former version is still "in-flight" to the peer (to be exact: we did not receive the P_BARRIER_ACK for its epoch yet) would wait for the full

Re: [PATCH] clocksource: kona: avoid bogus warning

Hi Arnd, On 6/13/2016 1:40 PM, Arnd Bergmann wrote: I could not figure out why, but gcc cannot prove that the kona_timer_init function always initializes its two outputs, and we get a warning for the use of the 'lsw' variable later, which is obviously correct.

[PATCH 26/30] drbd: code cleanups without semantic changes

From: Fabian Frederick This contains various cosmetic fixes ranging from simple typos to const-ifying, and using booleans properly. Original commit messages from Fabian's patch set: drbd: debugfs: constify drbd_version_fops drbd: use seq_put instead of seq_print where possible

[PATCH 27/30] drbd: get rid of empty statement in is_valid_state

From: Roland Kammerer This should silence a warning about an empty statement. Thanks to Fabian Frederick who sent a patch I modified to be smaller and avoids an additional indent level. Signed-off-by: Roland Kammerer

[PATCH 28/30] drbd: finally report ms, not jiffies, in log message

From: Lars Ellenberg Also skip the message unless bitmap IO took longer than 5 ms. Signed-off-by: Philipp Reisner Signed-off-by: Lars Ellenberg --- drivers/block/drbd/drbd_bitmap.c | 12 1 file

[PATCH 24/30] drbd: disallow promotion during resync handshake, avoid deadlock and hard reset

From: Lars Ellenberg We already serialize connection state changes, and other, non-connection state changes (role changes) while we are establishing a connection. But if we have an established connection, then trigger a resync handshake (by primary --force or

[PATCH 25/30] drbd: bump current uuid when resuming IO with diskless peer

From: Lars Ellenberg Scenario, starting with normal operation Connected Primary/Secondary UpToDate/UpToDate NetworkFailure Primary/Unknown UpToDate/DUnknown (frozen) ... more failures happen, secondary loses it's disk, but eventually is able to re-establish the

[PATCH 27/30] drbd: get rid of empty statement in is_valid_state

From: Roland Kammerer This should silence a warning about an empty statement. Thanks to Fabian Frederick who sent a patch I modified to be smaller and avoids an additional indent level. Signed-off-by: Roland Kammerer Signed-off-by: Philipp Reisner --- drivers/block/drbd/drbd_state.c | 3 ++-

[PATCH 28/30] drbd: finally report ms, not jiffies, in log message

From: Lars Ellenberg Also skip the message unless bitmap IO took longer than 5 ms. Signed-off-by: Philipp Reisner Signed-off-by: Lars Ellenberg --- drivers/block/drbd/drbd_bitmap.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git

[PATCH 24/30] drbd: disallow promotion during resync handshake, avoid deadlock and hard reset

From: Lars Ellenberg We already serialize connection state changes, and other, non-connection state changes (role changes) while we are establishing a connection. But if we have an established connection, then trigger a resync handshake (by primary --force or similar), until now we just had to

[PATCH 25/30] drbd: bump current uuid when resuming IO with diskless peer

From: Lars Ellenberg Scenario, starting with normal operation Connected Primary/Secondary UpToDate/UpToDate NetworkFailure Primary/Unknown UpToDate/DUnknown (frozen) ... more failures happen, secondary loses it's disk, but eventually is able to re-establish the replication link ...

[PATCH 26/30] drbd: code cleanups without semantic changes

From: Fabian Frederick This contains various cosmetic fixes ranging from simple typos to const-ifying, and using booleans properly. Original commit messages from Fabian's patch set: drbd: debugfs: constify drbd_version_fops drbd: use seq_put instead of seq_print where possible drbd: include

[PATCH 22/30] drbd: introduce WRITE_SAME support

From: Lars Ellenberg We will support WRITE_SAME, if * all peers support WRITE_SAME (both in kernel and DRBD version), * all peer devices support WRITE_SAME * logical_block_size is identical on all peers. We may at some point introduce a fallback on the receiving side for

Re: [RFC 11/18] limits: track and present RLIMIT_NPROC actual max

On Mon, Jun 13, 2016 at 10:44:18PM +0300, Topi Miettinen wrote: > Track maximum number of processes per user and present it > in /proc/self/limits. > > Signed-off-by: Topi Miettinen > --- > fs/proc/base.c| 4 > include/linux/sched.h | 1 + > kernel/fork.c

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