Re: [PATCH v2 1/2] Documentation: DT: bindings: Add Broadcom STB PCIe bindings

On Tuesday 10 May 2016 10:00:12 Florian Fainelli wrote: > > The two critical pieces of information that the PCIe RC needs are: > > - number of memory controllers present in the system to avoid > configuring a window to a non-existing or non-populated memory controller > > - size of the memory

Re: [PATCH v2 1/2] Documentation: DT: bindings: Add Broadcom STB PCIe bindings

On Tuesday 10 May 2016 10:00:12 Florian Fainelli wrote: > > The two critical pieces of information that the PCIe RC needs are: > > - number of memory controllers present in the system to avoid > configuring a window to a non-existing or non-populated memory controller > > - size of the memory

Re: [PATCH v4 6/6] block: Update blkdev_dax_capable() for consistency

On Tue, May 10, 2016 at 9:23 AM, Toshi Kani wrote: > blkdev_dax_capable() is similar to bdev_dax_supported(), but needs > to remain as a separate interface for checking dax capability of > a raw block device. > > Rename and relocate blkdev_dax_capable() to keep them maintained

Re: [PATCH v4 6/6] block: Update blkdev_dax_capable() for consistency

On Tue, May 10, 2016 at 9:23 AM, Toshi Kani wrote: > blkdev_dax_capable() is similar to bdev_dax_supported(), but needs > to remain as a separate interface for checking dax capability of > a raw block device. > > Rename and relocate blkdev_dax_capable() to keep them maintained > consistently, and

Re: [PATCH v6 4/5] dax: for truncate/hole-punch, do zeroing through the driver if possible

On Tue, 2016-05-10 at 12:25 -0700, Christoph Hellwig wrote: > Hi Vishal, > > can you also pick up the my patch to add a low-level __dax_zero_range > that I cced you on?  That way we can avoid a nasty merge conflict with > my xfs/iomap changes. Good idea - I'll do that for the next posting. I'll

Re: [PATCH v6 4/5] dax: for truncate/hole-punch, do zeroing through the driver if possible

On Tue, 2016-05-10 at 12:25 -0700, Christoph Hellwig wrote: > Hi Vishal, > > can you also pick up the my patch to add a low-level __dax_zero_range > that I cced you on?  That way we can avoid a nasty merge conflict with > my xfs/iomap changes. Good idea - I'll do that for the next posting. I'll

Re: [PATCH] ARM: dts: exynos: Only Odroid XU3-family boards use DTSI with CPU thermal nodes

Hi Krzysztof, On 10 May 2016 at 19:33, Krzysztof Kozlowski wrote: > On 05/10/2016 04:00 PM, Anand Moon wrote: >> Hi Krzysztof, >> >> On 10 May 2016 at 18:13, Krzysztof Kozlowski wrote: >>> On 05/10/2016 11:29 AM, Anand Moon wrote: > > I

Re: [PATCH] ARM: dts: exynos: Only Odroid XU3-family boards use DTSI with CPU thermal nodes

Hi Krzysztof, On 10 May 2016 at 19:33, Krzysztof Kozlowski wrote: > On 05/10/2016 04:00 PM, Anand Moon wrote: >> Hi Krzysztof, >> >> On 10 May 2016 at 18:13, Krzysztof Kozlowski wrote: >>> On 05/10/2016 11:29 AM, Anand Moon wrote: > > I am sorry but I do not understand. > 1. Are you

Re: [PATCH] arm64/sunxi: 4.6-rc1: Add dependency on generic irq chip

On Tuesday 10 May 2016 21:10:45 Maxime Ripard wrote: > > Fixes: commit ce3dd55b99b1 ("arm64: Introduce Allwinner SoC config option") > > Cc: Andre Przywara > > Signed-off-by: Suzuki K Poulose > > Signed-off-by: Andre Przywara

[PATCH net-next 1/2] net: dsa: mv88e6xxx: abstract VTU/STU data access

Both VTU and STU operations use the same routine to access their (common) data registers, with a different offset. Add VTU and STU specific read and write functions to the data registers to abstract the required offset. Signed-off-by: Vivien Didelot ---

Re: [PATCH] arm64/sunxi: 4.6-rc1: Add dependency on generic irq chip

On Tuesday 10 May 2016 21:10:45 Maxime Ripard wrote: > > Fixes: commit ce3dd55b99b1 ("arm64: Introduce Allwinner SoC config option") > > Cc: Andre Przywara > > Signed-off-by: Suzuki K Poulose > > Signed-off-by: Andre Przywara > > Acked-by: Maxime Ripard > Applied to fixes, thanks!

[PATCH net-next 1/2] net: dsa: mv88e6xxx: abstract VTU/STU data access

Both VTU and STU operations use the same routine to access their (common) data registers, with a different offset. Add VTU and STU specific read and write functions to the data registers to abstract the required offset. Signed-off-by: Vivien Didelot --- drivers/net/dsa/mv88e6xxx.c | 32

[PATCH net-next 2/2] net: dsa: mv88e6xxx: add STU capability

Some switch models have a STU (per VLAN port state database). Add a new capability flag to switches info, instead of checking their family. Also if the 6165 family has an STU, it must have a VTU, so add the MV88E6XXX_FLAG_VTU to its family flags. Signed-off-by: Vivien Didelot

[PATCH net-next 2/2] net: dsa: mv88e6xxx: add STU capability

Some switch models have a STU (per VLAN port state database). Add a new capability flag to switches info, instead of checking their family. Also if the 6165 family has an STU, it must have a VTU, so add the MV88E6XXX_FLAG_VTU to its family flags. Signed-off-by: Vivien Didelot ---

Re: [BISECTED] Regression v4.6-rc1 : nanosleep doesn't return on AT91SAM9

2016-05-10 17:18 GMT+02:00 Nicolas Ferre : > Le 10/05/2016 16:59, Richard Genoud a écrit : >> 2016-05-10 16:47 GMT+02:00 Boris Brezillon >> : >>> Hi Richard, >>> >>> On Tue, 10 May 2016 16:25:25 +0200 >>> Richard Genoud

Re: [BISECTED] Regression v4.6-rc1 : nanosleep doesn't return on AT91SAM9

2016-05-10 17:18 GMT+02:00 Nicolas Ferre : > Le 10/05/2016 16:59, Richard Genoud a écrit : >> 2016-05-10 16:47 GMT+02:00 Boris Brezillon >> : >>> Hi Richard, >>> >>> On Tue, 10 May 2016 16:25:25 +0200 >>> Richard Genoud wrote: >>> 2016-05-10 15:58 GMT+02:00 Richard Genoud : > Hi, >

Re: [Drbd-dev] [PATCH net-next v3] block/drbd: align properly u64 in nl messages

From: Lars Ellenberg Date: Tue, 10 May 2016 21:09:03 +0200 > On Tue, May 10, 2016 at 11:39:49AM -0400, David Miller wrote: >> From: Lars Ellenberg >> Date: Tue, 10 May 2016 11:40:23 +0200 > > excuse me for reordering the original: > >>

Re: [Drbd-dev] [PATCH net-next v3] block/drbd: align properly u64 in nl messages

From: Lars Ellenberg Date: Tue, 10 May 2016 21:09:03 +0200 > On Tue, May 10, 2016 at 11:39:49AM -0400, David Miller wrote: >> From: Lars Ellenberg >> Date: Tue, 10 May 2016 11:40:23 +0200 > > excuse me for reordering the original: > >> Anyways, back to the topic, can you please just relent

[PATCH 0/2] ARM: dts: sunxi: Add display clocks to sun[47]i.dtsi

Enable the display and TCON clocks that are needed to drive the display engine, tcon and TV encoders. Please note that currently the parent handling for clocks using 'allwinner,sun4i-a10-display-clk' compatible with number of parents !=4 is broken (like de_[bf]e[01]_clk clocks present in

[PATCH 0/2] ARM: dts: sunxi: Add display clocks to sun[47]i.dtsi

Enable the display and TCON clocks that are needed to drive the display engine, tcon and TV encoders. Please note that currently the parent handling for clocks using 'allwinner,sun4i-a10-display-clk' compatible with number of parents !=4 is broken (like de_[bf]e[01]_clk clocks present in

Re: [PATCH v6 4/5] dax: for truncate/hole-punch, do zeroing through the driver if possible

Hi Vishal, can you also pick up the my patch to add a low-level __dax_zero_range that I cced you on? That way we can avoid a nasty merge conflict with my xfs/iomap changes.

Re: [PATCH v6 4/5] dax: for truncate/hole-punch, do zeroing through the driver if possible

Hi Vishal, can you also pick up the my patch to add a low-level __dax_zero_range that I cced you on? That way we can avoid a nasty merge conflict with my xfs/iomap changes.

[PATCH 2/2] ARM: sun7i: A20: Add display and TCON clocks

Enable the display and TCON clocks that are needed to drive the display engine, tcon and TV encoders. Signed-off-by: Priit Laes --- arch/arm/boot/dts/sun7i-a20.dtsi | 85 +--- 1 file changed, 80 insertions(+), 5 deletions(-) diff --git

[PATCH 2/2] ARM: sun7i: A20: Add display and TCON clocks

Enable the display and TCON clocks that are needed to drive the display engine, tcon and TV encoders. Signed-off-by: Priit Laes --- arch/arm/boot/dts/sun7i-a20.dtsi | 85 +--- 1 file changed, 80 insertions(+), 5 deletions(-) diff --git

[PATCH 1/2] ARM: sun4i: A10: Add display and TCON clocks

Enable the display and TCON clocks that are needed to drive the display engine, tcon and TV encoders. Signed-off-by: Priit Laes --- arch/arm/boot/dts/sun4i-a10.dtsi | 91 1 file changed, 84 insertions(+), 7 deletions(-) diff --git

[PATCH 1/2] ARM: sun4i: A10: Add display and TCON clocks

Enable the display and TCON clocks that are needed to drive the display engine, tcon and TV encoders. Signed-off-by: Priit Laes --- arch/arm/boot/dts/sun4i-a10.dtsi | 91 1 file changed, 84 insertions(+), 7 deletions(-) diff --git

Re: [PATCH v2] kbuild: fix if_change and friends to consider argument order

On Sat, May 07, 2016 at 03:48:26PM +0900, Masahiro Yamada wrote: > Currently, arg-check is implemented as follows: > > arg-check = $(strip $(filter-out $(cmd_$(1)), $(cmd_$@)) \ > $(filter-out $(cmd_$@), $(cmd_$(1))) ) > > This does not care about the order of arguments

Re: [PATCH v2] kbuild: fix if_change and friends to consider argument order

On Sat, May 07, 2016 at 03:48:26PM +0900, Masahiro Yamada wrote: > Currently, arg-check is implemented as follows: > > arg-check = $(strip $(filter-out $(cmd_$(1)), $(cmd_$@)) \ > $(filter-out $(cmd_$@), $(cmd_$(1))) ) > > This does not care about the order of arguments

[PATCH 1/1] mm: thp: calculate the mapcount correctly for THP pages during WP faults

This will provide fully accuracy to the mapcount calculation in the write protect faults, so page pinning will not get broken by false positive copy-on-writes. total_mapcount() isn't the right calculation needed in reuse_swap_page(), so this introduces a page_trans_huge_mapcount() that is

[PATCH 1/1] mm: thp: calculate the mapcount correctly for THP pages during WP faults

This will provide fully accuracy to the mapcount calculation in the write protect faults, so page pinning will not get broken by false positive copy-on-writes. total_mapcount() isn't the right calculation needed in reuse_swap_page(), so this introduces a page_trans_huge_mapcount() that is

[patch] atmel: potential underflow in atmel_set_freq()

Smatch complains that we cap the upper bound of "fwrq->m" but not the lower bound. I don't know if it can actually happen but it's simple enough to check for negatives. Signed-off-by: Dan Carpenter diff --git a/drivers/net/wireless/atmel/atmel.c

[patch] atmel: potential underflow in atmel_set_freq()

Smatch complains that we cap the upper bound of "fwrq->m" but not the lower bound. I don't know if it can actually happen but it's simple enough to check for negatives. Signed-off-by: Dan Carpenter diff --git a/drivers/net/wireless/atmel/atmel.c b/drivers/net/wireless/atmel/atmel.c index

Re: [PATCH 5/5] remoteproc: core: Clip carveout if it's too big

On Thu 05 May 06:29 PDT 2016, Lee Jones wrote: > Carveout size is primarily extracted from the firmware binary. However, > DT can over-ride this by providing a different (smaller) size. We're > adding protection here to ensure the we only allocate the smaller of the > two provided sizes in

Re: [PATCH 5/5] remoteproc: core: Clip carveout if it's too big

On Thu 05 May 06:29 PDT 2016, Lee Jones wrote: > Carveout size is primarily extracted from the firmware binary. However, > DT can over-ride this by providing a different (smaller) size. We're > adding protection here to ensure the we only allocate the smaller of the > two provided sizes in

Re: [PATCH 1/3] intel_pstate: Clarify average performance computation

On Tue, May 10, 2016 at 3:18 AM, Srinivas Pandruvada wrote: > On Sat, 2016-05-07 at 01:44 +0200, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki >> >> The core_pct_busy field of struct sample actually contains the >> average

Re: [PATCH 1/3] intel_pstate: Clarify average performance computation

On Tue, May 10, 2016 at 3:18 AM, Srinivas Pandruvada wrote: > On Sat, 2016-05-07 at 01:44 +0200, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki >> >> The core_pct_busy field of struct sample actually contains the >> average performace during the last sampling period (in percent) >> and not

Re: [PATCH] fs: befs: use flags field to validate fs state

On Tue, 10 May 2016 19:59:42 +0100 Salah Triki wrote: > flags field records the state of the superblock, so it is > more appropriate to use this field for validating the fs state than > using the fields log_start and log_end. > > Signed-off-by: Salah Triki

Re: [PATCH] fs: befs: use flags field to validate fs state

On Tue, 10 May 2016 19:59:42 +0100 Salah Triki wrote: > flags field records the state of the superblock, so it is > more appropriate to use this field for validating the fs state than > using the fields log_start and log_end. > > Signed-off-by: Salah Triki > --- > fs/befs/super.c | 2 +- > 1

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

On 05/10/2016 12:11 PM, Sergei Shtylyov wrote: > Hello. > > On 05/10/2016 09:32 PM, Florian Fainelli wrote: > >>> The PHY devices sometimes do have their reset signal (maybe even power >>> supply?) tied to some GPIO and sometimes it also does happen that a boot >>> loader does not leave it

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

On 05/10/2016 12:11 PM, Sergei Shtylyov wrote: > Hello. > > On 05/10/2016 09:32 PM, Florian Fainelli wrote: > >>> The PHY devices sometimes do have their reset signal (maybe even power >>> supply?) tied to some GPIO and sometimes it also does happen that a boot >>> loader does not leave it

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

Hello. On 05/10/2016 09:32 PM, Florian Fainelli wrote: The PHY devices sometimes do have their reset signal (maybe even power supply?) tied to some GPIO and sometimes it also does happen that a boot loader does not leave it deasserted. So far this issue has been attacked from (as I believe) a

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

Hello. On 05/10/2016 09:32 PM, Florian Fainelli wrote: The PHY devices sometimes do have their reset signal (maybe even power supply?) tied to some GPIO and sometimes it also does happen that a boot loader does not leave it deasserted. So far this issue has been attacked from (as I believe) a

Re: [PATCH -v2] x86/hweight: Get rid of the special calling convention

On Tue, May 10, 2016 at 12:03:48PM -0700, H. Peter Anvin wrote: > Also, to be fair... if the problem is with these being in C then we > could just do it in assembly easily enough. I thought about converting the __sw_hweight* variants to asm but __sw_hweight32, for example, is 55 bytes here and

Re: [PATCH -v2] x86/hweight: Get rid of the special calling convention

On Tue, May 10, 2016 at 12:03:48PM -0700, H. Peter Anvin wrote: > Also, to be fair... if the problem is with these being in C then we > could just do it in assembly easily enough. I thought about converting the __sw_hweight* variants to asm but __sw_hweight32, for example, is 55 bytes here and

Re: [PATCH] arm64/sunxi: 4.6-rc1: Add dependency on generic irq chip

On Mon, May 09, 2016 at 11:37:35PM +0100, Andre Przywara wrote: > From: Suzuki K Poulose > > Commit ce3dd55b99b1 ("arm64: Introduce Allwinner SoC config option"), > added support for ARCH_SUNXI on arm64, but failed to select > GENERIC_IRQ_CHIP, which is required for

Re: [linux-sunxi] Re: [PATCH v4 01/11] clk: sunxi: Add display and TCON0 clocks driver

On Mon, 2016-05-09 at 15:39 -0700, Stephen Boyd wrote: > On 05/09, Stephen Boyd wrote: > > > > > > Ok I applied this one to clk-next. > > > And I squashed this in to silence the following checker warning. > > drivers/clk/sunxi/clk-sun4i-display.c:110:33: warning: Variable > length array is

Re: [PATCH] arm64/sunxi: 4.6-rc1: Add dependency on generic irq chip

On Mon, May 09, 2016 at 11:37:35PM +0100, Andre Przywara wrote: > From: Suzuki K Poulose > > Commit ce3dd55b99b1 ("arm64: Introduce Allwinner SoC config option"), > added support for ARCH_SUNXI on arm64, but failed to select > GENERIC_IRQ_CHIP, which is required for

Re: [linux-sunxi] Re: [PATCH v4 01/11] clk: sunxi: Add display and TCON0 clocks driver

On Mon, 2016-05-09 at 15:39 -0700, Stephen Boyd wrote: > On 05/09, Stephen Boyd wrote: > > > > > > Ok I applied this one to clk-next. > > > And I squashed this in to silence the following checker warning. > > drivers/clk/sunxi/clk-sun4i-display.c:110:33: warning: Variable > length array is

Re: [Drbd-dev] [PATCH net-next v3] block/drbd: align properly u64 in nl messages

On Tue, May 10, 2016 at 11:39:49AM -0400, David Miller wrote: > From: Lars Ellenberg > Date: Tue, 10 May 2016 11:40:23 +0200 excuse me for reordering the original: > Anyways, back to the topic, can you please just relent and come to > some kind of agreement about the

Re: [Drbd-dev] [PATCH net-next v3] block/drbd: align properly u64 in nl messages

On Tue, May 10, 2016 at 11:39:49AM -0400, David Miller wrote: > From: Lars Ellenberg > Date: Tue, 10 May 2016 11:40:23 +0200 excuse me for reordering the original: > Anyways, back to the topic, can you please just relent and come to > some kind of agreement about the fix for this alignment bug?

Re: [PATCH][RFC] cpufreq: intel_pstate: Avoid time-costly synchronization if schedutil is not enabled

On Tue, May 10, 2016 at 11:24 AM, wrote: > From: Chen Yu First, the subject. It doesn't have anything to do with schedutil, so I'd just use something like "Avoid unnecessary synchronize_sched() during initialization". > Commit bb6ab52f2bef

Re: [PATCH][RFC] cpufreq: intel_pstate: Avoid time-costly synchronization if schedutil is not enabled

On Tue, May 10, 2016 at 11:24 AM, wrote: > From: Chen Yu First, the subject. It doesn't have anything to do with schedutil, so I'd just use something like "Avoid unnecessary synchronize_sched() during initialization". > Commit bb6ab52f2bef ("intel_pstate: Do not set utilization update > hook

Re: [PATCH -v2] x86/hweight: Get rid of the special calling convention

On May 10, 2016 10:23:13 AM PDT, Peter Zijlstra wrote: >On Tue, May 10, 2016 at 06:53:18PM +0200, Borislav Petkov wrote: >> static __always_inline unsigned int __arch_hweight32(unsigned int w) >> { >> -unsigned int res = 0; >> +unsigned int res; >> >> -asm

Re: [PATCH -v2] x86/hweight: Get rid of the special calling convention

On May 10, 2016 10:23:13 AM PDT, Peter Zijlstra wrote: >On Tue, May 10, 2016 at 06:53:18PM +0200, Borislav Petkov wrote: >> static __always_inline unsigned int __arch_hweight32(unsigned int w) >> { >> -unsigned int res = 0; >> +unsigned int res; >> >> -asm (ALTERNATIVE("call

Re: [PATCH v3 0/3] net: phy: add phy_ethtool_{get|set}_link_ksettings

From: Philippe Reynes Date: Tue, 10 May 2016 00:19:40 +0200 > Ethtool callbacks {get|set}_link_ksettings may be the > same for many drivers. So we add two generics callbacks > phy_ethtool_{get|set}_link_ksettings. > > To use those generics callbacks, the ethernet driver must

Re: [PATCH v3 0/3] net: phy: add phy_ethtool_{get|set}_link_ksettings

From: Philippe Reynes Date: Tue, 10 May 2016 00:19:40 +0200 > Ethtool callbacks {get|set}_link_ksettings may be the > same for many drivers. So we add two generics callbacks > phy_ethtool_{get|set}_link_ksettings. > > To use those generics callbacks, the ethernet driver must > use the pointer

Re: [PATCH v3 1/4] x86, boot: Refactor KASLR entropy functions

On Tue, May 3, 2016 at 12:31 PM, Thomas Garnier wrote: > Move the KASLR entropy functions in x86/libray to be used in early > kernel boot for KASLR memory randomization. > > Signed-off-by: Thomas Garnier > --- > Based on next-20160502 > --- >

Re: [PATCH v3 1/4] x86, boot: Refactor KASLR entropy functions

On Tue, May 3, 2016 at 12:31 PM, Thomas Garnier wrote: > Move the KASLR entropy functions in x86/libray to be used in early > kernel boot for KASLR memory randomization. > > Signed-off-by: Thomas Garnier > --- > Based on next-20160502 > --- > arch/x86/boot/compressed/kaslr.c | 76

Re: [PATCH 1/1] simplified security.nscapability xattr

Quoting Serge E. Hallyn (se...@hallyn.com): > Quoting Eric W. Biederman (ebied...@xmission.com): > > "Serge E. Hallyn" writes: > > > > > Quoting Andrew G. Morgan (mor...@kernel.org): > > >> > > >> I guess I'm confused how we have strayed so far that this isn't an > > >>

Re: [PATCH 1/1] simplified security.nscapability xattr

Quoting Serge E. Hallyn (se...@hallyn.com): > Quoting Eric W. Biederman (ebied...@xmission.com): > > "Serge E. Hallyn" writes: > > > > > Quoting Andrew G. Morgan (mor...@kernel.org): > > >> > > >> I guess I'm confused how we have strayed so far that this isn't an > > >> obvious > > >>

Re: [PATCH -v2] x86/hweight: Get rid of the special calling convention

On Tue, May 10, 2016 at 07:23:13PM +0200, Peter Zijlstra wrote: > So what was wrong with using the normal thunk_*.S wrappers for the > calls? That would allow you to use the alternative() stuff which does > generate smaller code. Yeah, so a full allyesconfig vmlinux gives ~22K .text size

Re: [PATCH -v2] x86/hweight: Get rid of the special calling convention

On Tue, May 10, 2016 at 07:23:13PM +0200, Peter Zijlstra wrote: > So what was wrong with using the normal thunk_*.S wrappers for the > calls? That would allow you to use the alternative() stuff which does > generate smaller code. Yeah, so a full allyesconfig vmlinux gives ~22K .text size

Applied "regulator: da9063: Correct module alias prefix to fix module autoloading" to the regulator tree

The patch regulator: da9063: Correct module alias prefix to fix module autoloading has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually

Applied "regulator: da9063: Correct module alias prefix to fix module autoloading" to the regulator tree

The patch regulator: da9063: Correct module alias prefix to fix module autoloading has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually

[PATCH] devicetree: sunxi: Add OLinuXino Lime2 eMMC to the Makefile

ARM: dts: sunxi: Add a olinuxino-lime2-emmc added the new emmc equipped lime2 but forgot its Makefile. This patch adds an entry to the Makefile. Signed-off-by: Olliver Schinagl --- Maxime, I'm sorry for ommitting the Makefile initially, if it is not merged yet, maybe just

[PATCH] devicetree: sunxi: Add OLinuXino Lime2 eMMC to the Makefile

ARM: dts: sunxi: Add a olinuxino-lime2-emmc added the new emmc equipped lime2 but forgot its Makefile. This patch adds an entry to the Makefile. Signed-off-by: Olliver Schinagl --- Maxime, I'm sorry for ommitting the Makefile initially, if it is not merged yet, maybe just squash it with the

Re: [PATCH 1/1] simplified security.nscapability xattr

Quoting Eric W. Biederman (ebied...@xmission.com): > "Andrew G. Morgan" writes: > > > On 2 May 2016 6:04 p.m., "Eric W. Biederman" > > wrote: > >> > >> "Serge E. Hallyn" writes: > >> > >> > On Tue, Apr 26, 2016 at 03:39:54PM -0700,

[PATCH] fs: befs: use flags field to validate fs state

flags field records the state of the superblock, so it is more appropriate to use this field for validating the fs state than using the fields log_start and log_end. Signed-off-by: Salah Triki --- fs/befs/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH] fs: befs: use flags field to validate fs state

flags field records the state of the superblock, so it is more appropriate to use this field for validating the fs state than using the fields log_start and log_end. Signed-off-by: Salah Triki --- fs/befs/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH 1/1] simplified security.nscapability xattr

Quoting Eric W. Biederman (ebied...@xmission.com): > "Andrew G. Morgan" writes: > > > On 2 May 2016 6:04 p.m., "Eric W. Biederman" > > wrote: > >> > >> "Serge E. Hallyn" writes: > >> > >> > On Tue, Apr 26, 2016 at 03:39:54PM -0700, Kees Cook wrote: > >> >> On Tue, Apr 26, 2016 at 3:26 PM,

[PATCH] regulator: da9063: Correct module alias prefix to fix module autoloading

s/paltform/platform/ Signed-off-by: Geert Uytterhoeven --- drivers/regulator/da9063-regulator.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/regulator/da9063-regulator.c b/drivers/regulator/da9063-regulator.c index

[PATCH] regulator: da9063: Correct module alias prefix to fix module autoloading

s/paltform/platform/ Signed-off-by: Geert Uytterhoeven --- drivers/regulator/da9063-regulator.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/regulator/da9063-regulator.c b/drivers/regulator/da9063-regulator.c index ed9e7e96f8777a29..c6af343f54eac5c5 100644 ---

Applied "ASoC: da7213: Default PC counter to free-running when DAI disabled" to the asoc tree

The patch ASoC: da7213: Default PC counter to free-running when DAI disabled has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next

Applied "ASoC: da7213: Default PC counter to free-running when DAI disabled" to the asoc tree

The patch ASoC: da7213: Default PC counter to free-running when DAI disabled has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next

Applied "ASoC: da7213: Add checking of SRM lock status before enabling DAI" to the asoc tree

The patch ASoC: da7213: Add checking of SRM lock status before enabling DAI has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "ASoC: da7213: Add checking of SRM lock status before enabling DAI" to the asoc tree

The patch ASoC: da7213: Add checking of SRM lock status before enabling DAI has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "ASoC: da7213: Allow PLL disable/bypass when using 32KHz sysclk" to the asoc tree

The patch ASoC: da7213: Allow PLL disable/bypass when using 32KHz sysclk has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "ASoC: es8328: Support more sample rates" to the asoc tree

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

Re: [PATCH v3 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On Tue, May 3, 2016 at 12:31 PM, Thomas Garnier wrote: > Randomizes the virtual address space of kernel memory sections (physical > memory mapping, vmalloc & vmemmap) for x86_64. This security feature > mitigates exploits relying on predictable kernel addresses. These >

Applied "ASoC: da7213: Allow PLL disable/bypass when using 32KHz sysclk" to the asoc tree

The patch ASoC: da7213: Allow PLL disable/bypass when using 32KHz sysclk has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "ASoC: es8328: Support more sample rates" to the asoc tree

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

Re: [PATCH v3 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On Tue, May 3, 2016 at 12:31 PM, Thomas Garnier wrote: > Randomizes the virtual address space of kernel memory sections (physical > memory mapping, vmalloc & vmemmap) for x86_64. This security feature > mitigates exploits relying on predictable kernel addresses. These > addresses can be used to

Applied "ASoC: da7213: Add DAI DAPM event to control DAI clocks" to the asoc tree

The patch ASoC: da7213: Add DAI DAPM event to control DAI clocks has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "ASoC: es8328: Support more sample formats" to the asoc tree

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

Applied "ASoC: da7213: Add DAI DAPM event to control DAI clocks" to the asoc tree

The patch ASoC: da7213: Add DAI DAPM event to control DAI clocks has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and

Applied "ASoC: es8328: Support more sample formats" to the asoc tree

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

[PATCH v6 0/5] dax: handling media errors (clear-on-zero only)

Until now, dax has been disabled if media errors were found on any device. This series attempts to address that. The first two patches from Dan re-enable dax even when media errors are present. The third patch from Matthew removes the zeroout path from dax entirely, making zeroout operations

[PATCH v6 0/5] dax: handling media errors (clear-on-zero only)

Until now, dax has been disabled if media errors were found on any device. This series attempts to address that. The first two patches from Dan re-enable dax even when media errors are present. The third patch from Matthew removes the zeroout path from dax entirely, making zeroout operations

[PATCH v6 4/5] dax: for truncate/hole-punch, do zeroing through the driver if possible

In the truncate or hole-punch path in dax, we clear out sub-page ranges. If these sub-page ranges are sector aligned and sized, we can do the zeroing through the driver instead so that error-clearing is handled automatically. For sub-sector ranges, we still have to rely on clear_pmem and have the

[PATCH v6 4/5] dax: for truncate/hole-punch, do zeroing through the driver if possible

In the truncate or hole-punch path in dax, we clear out sub-page ranges. If these sub-page ranges are sector aligned and sized, we can do the zeroing through the driver instead so that error-clearing is handled automatically. For sub-sector ranges, we still have to rely on clear_pmem and have the

[PATCH v6 2/5] dax: enable dax in the presence of known media errors (badblocks)

From: Dan Williams 1/ If a mapping overlaps a bad sector fail the request. 2/ Do not opportunistically report more dax-capable capacity than is requested when errors present. Reviewed-by: Jeff Moyer Reviewed-by: Christoph Hellwig

[PATCH v6 3/5] dax: use sb_issue_zerout instead of calling dax_clear_sectors

From: Matthew Wilcox dax_clear_sectors() cannot handle poisoned blocks. These must be zeroed using the BIO interface instead. Convert ext2 and XFS to use only sb_issue_zerout(). Reviewed-by: Jeff Moyer Reviewed-by: Christoph Hellwig

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

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

[PATCH v6 2/5] dax: enable dax in the presence of known media errors (badblocks)

From: Dan Williams 1/ If a mapping overlaps a bad sector fail the request. 2/ Do not opportunistically report more dax-capable capacity than is requested when errors present. Reviewed-by: Jeff Moyer Reviewed-by: Christoph Hellwig Signed-off-by: Dan Williams [vishal: fix a conflict with

[PATCH v6 3/5] dax: use sb_issue_zerout instead of calling dax_clear_sectors

From: Matthew Wilcox dax_clear_sectors() cannot handle poisoned blocks. These must be zeroed using the BIO interface instead. Convert ext2 and XFS to use only sb_issue_zerout(). Reviewed-by: Jeff Moyer Reviewed-by: Christoph Hellwig Reviewed-by: Jan Kara Signed-off-by: Matthew Wilcox

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

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

Applied "ASoC: es8328: Use single R/W for regmap" to the asoc tree

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

Applied "ASoC: es8328: Use single R/W for regmap" to the asoc tree

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

[PATCH v6 5/5] dax: fix a comment in dax_zero_page_range and dax_truncate_page

The distinction between PAGE_SIZE and PAGE_CACHE_SIZE was removed in 09cbfea mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros The comments for the above functions described a distinction between those, that is now redundant, so remove those paragraphs Cc: Kirill A. Shutemov

[PATCH v6 5/5] dax: fix a comment in dax_zero_page_range and dax_truncate_page

The distinction between PAGE_SIZE and PAGE_CACHE_SIZE was removed in 09cbfea mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros The comments for the above functions described a distinction between those, that is now redundant, so remove those paragraphs Cc: Kirill A. Shutemov

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