drivers/regulator/lp872x.c:773: undefined reference to `devm_gpio_request_one'

Hi Linus, It's probably a bug fix that unveils the link errors. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: bc33b0ca11e3df46a4fa7639ba488c9d4911 commit: 2527ecc9195e9c66252af24c4689e8a67cd4ccb9 gpio: Fix OF build problem on UM date: 3 months

drivers/regulator/lp872x.c:773: undefined reference to `devm_gpio_request_one'

Hi Linus, It's probably a bug fix that unveils the link errors. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: bc33b0ca11e3df46a4fa7639ba488c9d4911 commit: 2527ecc9195e9c66252af24c4689e8a67cd4ccb9 gpio: Fix OF build problem on UM date: 3 months

[PATCH] net: amd: pcnet32: use new api ethtool_{get|set}_link_ksettings

The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/amd/pcnet32.c | 14 -- 1 files changed, 8 insertions(+), 6 deletions(-) diff --git

[PATCH] net: amd: pcnet32: use new api ethtool_{get|set}_link_ksettings

The ethtool api {get|set}_settings is deprecated. We move this driver to new api {get|set}_link_ksettings. Signed-off-by: Philippe Reynes --- drivers/net/ethernet/amd/pcnet32.c | 14 -- 1 files changed, 8 insertions(+), 6 deletions(-) diff --git

Re: [PATCH] perf thread: cleanup with list_first_entry_or_null()

Em Sun, Nov 06, 2016 at 12:00:22PM +0900, Masahiro Yamada escreveu: > Hi maintainers, > > Does this patch look good? >From a quick look it seems ok, I'll try and process it when back home. - Arnaldo > 2016-09-13 3:29 GMT+09:00 Masahiro Yamada : > > The combo of

Re: [PATCH] perf thread: cleanup with list_first_entry_or_null()

Em Sun, Nov 06, 2016 at 12:00:22PM +0900, Masahiro Yamada escreveu: > Hi maintainers, > > Does this patch look good? >From a quick look it seems ok, I'll try and process it when back home. - Arnaldo > 2016-09-13 3:29 GMT+09:00 Masahiro Yamada : > > The combo of list_empty() check and return

cc1: error: '-march=r3000' requires '-mfp32'

Hi James, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: bc33b0ca11e3df46a4fa7639ba488c9d4911 commit: 034827c727f7f3946a18355b63995b402c226c82 MIPS: Fix -mabi=64 build of vdso.lds date: 4 weeks ago config:

cc1: error: '-march=r3000' requires '-mfp32'

Hi James, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: bc33b0ca11e3df46a4fa7639ba488c9d4911 commit: 034827c727f7f3946a18355b63995b402c226c82 MIPS: Fix -mabi=64 build of vdso.lds date: 4 weeks ago config:

[PATCH 1/2] s390: delete unneeded #include from facilities_src.h

The header facilities_src.h is only included from gen_facilities.c and the tool is compiled with the following extra options: HOSTCFLAGS_gen_facilities.o += -Wall $(LINUXINCLUDE) Please note $(LINUXINCLUDE) is expanded into build options including: -include

[PATCH 1/2] s390: delete unneeded #include from facilities_src.h

The header facilities_src.h is only included from gen_facilities.c and the tool is compiled with the following extra options: HOSTCFLAGS_gen_facilities.o += -Wall $(LINUXINCLUDE) Please note $(LINUXINCLUDE) is expanded into build options including: -include

[PATCH 2/2] s390: squash facilities_src.h into gen_facilities.c

We generally expect headers in arch/$(ARCH)/include/asm directory are included from kernel sources, but facilities_src.h is not; it is included from the arch/s390/tools/gen_facilities.c tool. There is no reason to expose this header to the public include path. Furthermore, facilities_src.h makes

[PATCH 2/2] s390: squash facilities_src.h into gen_facilities.c

We generally expect headers in arch/$(ARCH)/include/asm directory are included from kernel sources, but facilities_src.h is not; it is included from the arch/s390/tools/gen_facilities.c tool. There is no reason to expose this header to the public include path. Furthermore, facilities_src.h makes

Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

On Sat, 05 Nov 2016, Pavel Machek wrote: > On Sat 2016-11-05 15:46:12, Henrique de Moraes Holschuh wrote: > > On Sat, 05 Nov 2016, Pavel Machek wrote: > > > Hmm, thanks for the pointer. But it seems like I'll have to build my > > > own, as /proc/acpi/ibm does not follow the usual infrastructure...

Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

On Sat, 05 Nov 2016, Pavel Machek wrote: > On Sat 2016-11-05 15:46:12, Henrique de Moraes Holschuh wrote: > > On Sat, 05 Nov 2016, Pavel Machek wrote: > > > Hmm, thanks for the pointer. But it seems like I'll have to build my > > > own, as /proc/acpi/ibm does not follow the usual infrastructure...

Re: [PATCH v3] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines

On 10/27/2016 10:52 AM, Eric Anholt wrote: From: Linus Walleij The idea is to give useful names to GPIO lines that an implementer will be using from userspace, e.g. for maker type projects. These are user-visible using tools/gpio/lsgpio.c

Re: [PATCH v3] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines

On 10/27/2016 10:52 AM, Eric Anholt wrote: From: Linus Walleij The idea is to give useful names to GPIO lines that an implementer will be using from userspace, e.g. for maker type projects. These are user-visible using tools/gpio/lsgpio.c arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 65

arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3000' requires '-mfp32'

Hi Guenter, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: bc33b0ca11e3df46a4fa7639ba488c9d4911 commit: 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e MIPS: VDSO: Fix build error with binutils 2.24 and earlier

arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3000' requires '-mfp32'

Hi Guenter, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: bc33b0ca11e3df46a4fa7639ba488c9d4911 commit: 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e MIPS: VDSO: Fix build error with binutils 2.24 and earlier

Re: [PATCH v2 1/3] thinkpad_acpi: Move tablet detection into separate function

On Sat, 05 Nov 2016, Darren Hart wrote: > On Mon, Oct 31, 2016 at 07:56:40PM -0400, Lyude wrote: > > Suggested by Daniel Martin > > > > Lenovo's having a bit of fun randomly changing what hotkey events and > > acpi handles they use for reporting tablet mode, so

Re: [PATCH v2 1/3] thinkpad_acpi: Move tablet detection into separate function

On Sat, 05 Nov 2016, Darren Hart wrote: > On Mon, Oct 31, 2016 at 07:56:40PM -0400, Lyude wrote: > > Suggested by Daniel Martin > > > > Lenovo's having a bit of fun randomly changing what hotkey events and > > acpi handles they use for reporting tablet mode, so unfortunately this > > means we're

arch/mips/vdso/elf.S:1:0: error: '-march=r3000' requires '-mfp32'

Hi Alex, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: bc33b0ca11e3df46a4fa7639ba488c9d4911 commit: ebb5e78cc63417a35254a791de66e1cc84f963cc MIPS: Initial implementation of a VDSO date: 12 months ago

arch/mips/vdso/elf.S:1:0: error: '-march=r3000' requires '-mfp32'

Hi Alex, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: bc33b0ca11e3df46a4fa7639ba488c9d4911 commit: ebb5e78cc63417a35254a791de66e1cc84f963cc MIPS: Initial implementation of a VDSO date: 12 months ago

Re: [PATCH] perf thread: cleanup with list_first_entry_or_null()

Hi maintainers, Does this patch look good? 2016-09-13 3:29 GMT+09:00 Masahiro Yamada : > The combo of list_empty() check and return list_first_entry() > can be replaced with list_first_entry_or_null(). > > Signed-off-by: Masahiro Yamada

Re: [PATCH] perf thread: cleanup with list_first_entry_or_null()

Hi maintainers, Does this patch look good? 2016-09-13 3:29 GMT+09:00 Masahiro Yamada : > The combo of list_empty() check and return list_first_entry() > can be replaced with list_first_entry_or_null(). > > Signed-off-by: Masahiro Yamada > --- > > tools/perf/util/thread.c | 5 + > 1 file

Re: [PATCH v2] platform/x86/asus-nb-wmi.c: Add X45U quirk

Hi Darren, On Sat, Nov 05, 2016 at 11:24:04AM -0700, Darren Hart wrote: > On Mon, Oct 31, 2016 at 11:56:10PM -0200, Marcos Paulo de Souza wrote: > > Without this patch, the Asus X45U wireless card can't be turned > > on (hard-blocked), but after a suspend/resume it just starts working. > > > >

Re: [PATCH v2] platform/x86/asus-nb-wmi.c: Add X45U quirk

Hi Darren, On Sat, Nov 05, 2016 at 11:24:04AM -0700, Darren Hart wrote: > On Mon, Oct 31, 2016 at 11:56:10PM -0200, Marcos Paulo de Souza wrote: > > Without this patch, the Asus X45U wireless card can't be turned > > on (hard-blocked), but after a suspend/resume it just starts working. > > > >

fs/xfs/xfs_ondisk.h:96:2: error: call to '__compiletime_assert_96' declared with attribute error: XFS: sizeof(xfs_dir2_sf_entry_t) is wrong, expected 3

Hi Dave, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: bc33b0ca11e3df46a4fa7639ba488c9d4911 commit: ab9d1e4f7b0217948a3b35a64178602ab30ff45d Merge branch 'xfs-misc-fixes-4.6-3' into for-next date: 8 months

fs/xfs/xfs_ondisk.h:96:2: error: call to '__compiletime_assert_96' declared with attribute error: XFS: sizeof(xfs_dir2_sf_entry_t) is wrong, expected 3

Hi Dave, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: bc33b0ca11e3df46a4fa7639ba488c9d4911 commit: ab9d1e4f7b0217948a3b35a64178602ab30ff45d Merge branch 'xfs-misc-fixes-4.6-3' into for-next date: 8 months

Re: [PATCH 13/22] mtd: nand: lpc32xx: return error code of nand_scan_ident/tail() on error

On 11/04/2016 12:43 PM, Masahiro Yamada wrote: The nand_scan_ident/tail() returns an appropriate error value when it fails. Use it instead of the fixed error code -ENXIO. Signed-off-by: Masahiro Yamada --- Acked-by: Vladimir Zapolskiy Thank

Re: [PATCH 13/22] mtd: nand: lpc32xx: return error code of nand_scan_ident/tail() on error

On 11/04/2016 12:43 PM, Masahiro Yamada wrote: The nand_scan_ident/tail() returns an appropriate error value when it fails. Use it instead of the fixed error code -ENXIO. Signed-off-by: Masahiro Yamada --- Acked-by: Vladimir Zapolskiy Thank you for the change. -- With best wishes,

arch/ia64/kernel/fsys.S:67: Error: Operand 3 of `add' should be a general register r0-r3

Hi Will, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: ffbcbfca846ed117e3d4009acfbf1e1590c56b2f commit: da48d094ce5d7c7dcdad9011648a81c42fd1c2ef Kconfig: remove HAVE_LATENCYTOP_SUPPORT date: 10 months ago

arch/ia64/kernel/fsys.S:67: Error: Operand 3 of `add' should be a general register r0-r3

Hi Will, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: ffbcbfca846ed117e3d4009acfbf1e1590c56b2f commit: da48d094ce5d7c7dcdad9011648a81c42fd1c2ef Kconfig: remove HAVE_LATENCYTOP_SUPPORT date: 10 months ago

cc1: error: '-march=r3900' requires '-mfp32'

Hi James, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: fb415f222c26d0d1fa19615af1d102bf5f5b3ca2 commit: 034827c727f7f3946a18355b63995b402c226c82 MIPS: Fix -mabi=64 build of vdso.lds date: 4 weeks ago config:

cc1: error: '-march=r3900' requires '-mfp32'

Hi James, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: fb415f222c26d0d1fa19615af1d102bf5f5b3ca2 commit: 034827c727f7f3946a18355b63995b402c226c82 MIPS: Fix -mabi=64 build of vdso.lds date: 4 weeks ago config:

arch/ia64/kernel/entry.S:621: Error: Operand 2 of `adds' should be a 14-bit integer (-8192-8191)

Hi Will, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: fb415f222c26d0d1fa19615af1d102bf5f5b3ca2 commit: da48d094ce5d7c7dcdad9011648a81c42fd1c2ef Kconfig: remove HAVE_LATENCYTOP_SUPPORT date: 10 months ago

arch/ia64/kernel/entry.S:621: Error: Operand 2 of `adds' should be a 14-bit integer (-8192-8191)

Hi Will, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: fb415f222c26d0d1fa19615af1d102bf5f5b3ca2 commit: da48d094ce5d7c7dcdad9011648a81c42fd1c2ef Kconfig: remove HAVE_LATENCYTOP_SUPPORT date: 10 months ago

drivers/gpu/drm/i915/i915_gem_gtt.c:2367: error: 'gtt_entry' may be used uninitialized in this function

Hi Dave, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: ffbcbfca846ed117e3d4009acfbf1e1590c56b2f commit: 85d1225ec066b2ef46fbd0ed1bae78ae1f3e6c91 drm/i915: Introduce & use new lightweight SGL iterators date: 6

drivers/gpu/drm/i915/i915_gem_gtt.c:2367: error: 'gtt_entry' may be used uninitialized in this function

Hi Dave, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: ffbcbfca846ed117e3d4009acfbf1e1590c56b2f commit: 85d1225ec066b2ef46fbd0ed1bae78ae1f3e6c91 drm/i915: Introduce & use new lightweight SGL iterators date: 6

arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3900' requires '-mfp32'

Hi Guenter, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: fb415f222c26d0d1fa19615af1d102bf5f5b3ca2 commit: 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e MIPS: VDSO: Fix build error with binutils 2.24 and earlier

arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3900' requires '-mfp32'

Hi Guenter, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: fb415f222c26d0d1fa19615af1d102bf5f5b3ca2 commit: 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e MIPS: VDSO: Fix build error with binutils 2.24 and earlier

Linux 4.9-rc4

So it's once again a Saturday afternoon rather than Sunday, this time because I felt this rc was already big enough. Part of the size likely comes just from the fact that 4.9 is big and has some fundamental changes: we have various fixups for drivers and filesystems that triggered the whole

Linux 4.9-rc4

So it's once again a Saturday afternoon rather than Sunday, this time because I felt this rc was already big enough. Part of the size likely comes just from the fact that 4.9 is big and has some fundamental changes: we have various fixups for drivers and filesystems that triggered the whole

Re: console issue since 3.6, console=ttyS1 hangs

On Fri, 4 Nov 2016, Peter Hurley wrote: > > These bios screens do not have any mention of PNP settings. > > I am getting output over the console (via ipmi) until the boot hangs. > > Yeah, probably the device actually decodes io address access anyway, > but in the disabled state probably has not

Re: console issue since 3.6, console=ttyS1 hangs

On Fri, 4 Nov 2016, Peter Hurley wrote: > > These bios screens do not have any mention of PNP settings. > > I am getting output over the console (via ipmi) until the boot hangs. > > Yeah, probably the device actually decodes io address access anyway, > but in the disabled state probably has not

DO YOU NEED A LOAN?

We offer loan at 3% if interested reply us with your email for full info

DO YOU NEED A LOAN?

We offer loan at 3% if interested reply us with your email for full info

Re: [PATCH/RFC] z3fold: use per-page read/write lock

Vitaly Wool writes: > Most of z3fold operations are in-page, such as modifying z3fold > page header or moving z3fold objects within a page. Taking > per-pool spinlock to protect per-page objects is therefore > suboptimal, and the idea of having a per-page spinlock (or

Re: [PATCH/RFC] z3fold: use per-page read/write lock

Vitaly Wool writes: > Most of z3fold operations are in-page, such as modifying z3fold > page header or moving z3fold objects within a page. Taking > per-pool spinlock to protect per-page objects is therefore > suboptimal, and the idea of having a per-page spinlock (or rwlock) > has been around

arch/mips/vdso/elf.S:1:0: error: '-march=r3900' requires '-mfp32'

Hi Alex, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: fb415f222c26d0d1fa19615af1d102bf5f5b3ca2 commit: ebb5e78cc63417a35254a791de66e1cc84f963cc MIPS: Initial implementation of a VDSO date: 12 months ago

arch/mips/vdso/elf.S:1:0: error: '-march=r3900' requires '-mfp32'

Hi Alex, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: fb415f222c26d0d1fa19615af1d102bf5f5b3ca2 commit: ebb5e78cc63417a35254a791de66e1cc84f963cc MIPS: Initial implementation of a VDSO date: 12 months ago

core.c:undefined reference to `fpu_save'

Hi Andrew, It's probably a bug fix that unveils the link errors. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: ffbcbfca846ed117e3d4009acfbf1e1590c56b2f commit: c60f169202c7643991a8b4bfeea60e06843d5b5a arch/mn10300/kernel/fpu-nofpu.c: needs asm/elf.h

include/linux/unaligned/access_ok.h:37:20: error: redefinition of 'put_unaligned_le16'

Hi Vincent, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: fb415f222c26d0d1fa19615af1d102bf5f5b3ca2 commit: 3194c6870158e305dac2af52f83681e9cb67280f NFC: nfcmrvl: add firmware download support date: 1 year ago

core.c:undefined reference to `fpu_save'

Hi Andrew, It's probably a bug fix that unveils the link errors. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: ffbcbfca846ed117e3d4009acfbf1e1590c56b2f commit: c60f169202c7643991a8b4bfeea60e06843d5b5a arch/mn10300/kernel/fpu-nofpu.c: needs asm/elf.h

include/linux/unaligned/access_ok.h:37:20: error: redefinition of 'put_unaligned_le16'

Hi Vincent, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: fb415f222c26d0d1fa19615af1d102bf5f5b3ca2 commit: 3194c6870158e305dac2af52f83681e9cb67280f NFC: nfcmrvl: add firmware download support date: 1 year ago

include/linux/unaligned/access_ok.h:7:19: error: redefinition of 'get_unaligned_le16'

Hi Vincent, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: ffbcbfca846ed117e3d4009acfbf1e1590c56b2f commit: 3194c6870158e305dac2af52f83681e9cb67280f NFC: nfcmrvl: add firmware download support date: 1 year ago

include/linux/unaligned/access_ok.h:7:19: error: redefinition of 'get_unaligned_le16'

Hi Vincent, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: ffbcbfca846ed117e3d4009acfbf1e1590c56b2f commit: 3194c6870158e305dac2af52f83681e9cb67280f NFC: nfcmrvl: add firmware download support date: 1 year ago

[PATCH] ASoC: fsl: fix fsl_spdif.c build errors

From: Randy Dunlap Fix build errors in sound/soc/fsl/fsl_spdif.c by selecting BITREVERSE. Fixes these build errors: sound/built-in.o: In function `spdif_write_channel_status': fsl_spdif.c:(.text+0xbe39d): undefined reference to `byte_rev_table'

[PATCH] ASoC: fsl: fix fsl_spdif.c build errors

From: Randy Dunlap Fix build errors in sound/soc/fsl/fsl_spdif.c by selecting BITREVERSE. Fixes these build errors: sound/built-in.o: In function `spdif_write_channel_status': fsl_spdif.c:(.text+0xbe39d): undefined reference to `byte_rev_table' fsl_spdif.c:(.text+0xbe3a8): undefined reference

Re: [mm PATCH v2 03/26] swiotlb: Add support for DMA_ATTR_SKIP_CPU_SYNC

On Sat, Nov 5, 2016 at 12:39 PM, Konrad Rzeszutek Wilk wrote: > .. snip.. >> @@ -561,6 +565,7 @@ void swiotlb_tbl_unmap_single(struct device *hwdev, >> phys_addr_t tlb_addr, >>* First, sync the memory before unmapping the entry >>*/ >> if (orig_addr !=

Re: [GIT PULL] overlayfs fixes for 4.9-rc3

> And the thing is, backward incompatibility is less of an issue for > overlayfs than for normal filesystems, because it's usually not > something people store their root filesystems on, and if so they can > simply not turn off this feature. That got my attention. What backwards incompatible

Re: [mm PATCH v2 03/26] swiotlb: Add support for DMA_ATTR_SKIP_CPU_SYNC

On Sat, Nov 5, 2016 at 12:39 PM, Konrad Rzeszutek Wilk wrote: > .. snip.. >> @@ -561,6 +565,7 @@ void swiotlb_tbl_unmap_single(struct device *hwdev, >> phys_addr_t tlb_addr, >>* First, sync the memory before unmapping the entry >>*/ >> if (orig_addr != INVALID_PHYS_ADDR &&

Re: [GIT PULL] overlayfs fixes for 4.9-rc3

> And the thing is, backward incompatibility is less of an issue for > overlayfs than for normal filesystems, because it's usually not > something people store their root filesystems on, and if so they can > simply not turn off this feature. That got my attention. What backwards incompatible

scripts/gcc-plugins/gcc-common.h:4:22: fatal error: bversion.h: No such file or directory

Hi Emese, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: ffbcbfca846ed117e3d4009acfbf1e1590c56b2f commit: 543c37cb165049c3be24a0d4733e67caa2b33eef Add sancov plugin date: 5 months ago config:

scripts/gcc-plugins/gcc-common.h:4:22: fatal error: bversion.h: No such file or directory

Hi Emese, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: ffbcbfca846ed117e3d4009acfbf1e1590c56b2f commit: 543c37cb165049c3be24a0d4733e67caa2b33eef Add sancov plugin date: 5 months ago config:

Linux 4.9-rcX: rcu_preempt detected stalls on CPUs/tasks messages

Hello , I've tested 4.9-rcX and Linus git tree and have on this box the following messages : . Nov 05 20:26:40 zwerg kernel: INFO: rcu_preempt detected stalls on CPUs/tasks: Nov 05 20:26:40 zwerg kernel: Tasks blocked on level-0 rcu_node (CPUs 0-15): P0 Nov 05 20:26:40 zwerg

Linux 4.9-rcX: rcu_preempt detected stalls on CPUs/tasks messages

Hello , I've tested 4.9-rcX and Linus git tree and have on this box the following messages : . Nov 05 20:26:40 zwerg kernel: INFO: rcu_preempt detected stalls on CPUs/tasks: Nov 05 20:26:40 zwerg kernel: Tasks blocked on level-0 rcu_node (CPUs 0-15): P0 Nov 05 20:26:40 zwerg

Re: [PATCH 5/8] block: add code to track actual device queue depth

On Tue 01-11-16 15:08:48, Jens Axboe wrote: > For blk-mq, ->nr_requests does track queue depth, at least at init > time. But for the older queue paths, it's simply a soft setting. > On top of that, it's generally larger than the hardware setting > on purpose, to allow backup of requests for

Re: [PATCH 5/8] block: add code to track actual device queue depth

On Tue 01-11-16 15:08:48, Jens Axboe wrote: > For blk-mq, ->nr_requests does track queue depth, at least at init > time. But for the older queue paths, it's simply a soft setting. > On top of that, it's generally larger than the hardware setting > on purpose, to allow backup of requests for

Re: [PATCH 3/8] writeback: mark background writeback as such

On Tue 01-11-16 15:08:46, Jens Axboe wrote: > If we're doing background type writes, then use the appropriate > background write flags for that. > > Signed-off-by: Jens Axboe Looks good. You can add: Reviewed-by: Jan Kara

Re: [PATCH 1/8] block: add WRITE_BACKGROUND

On Tue 01-11-16 15:08:44, Jens Axboe wrote: > This adds a new request flag, REQ_BACKGROUND, that callers can use to > tell the block layer that this is background (non-urgent) IO. > > Signed-off-by: Jens Axboe Looks good. You can add: Reviewed-by: Jan Kara

Re: [PATCH 3/8] writeback: mark background writeback as such

On Tue 01-11-16 15:08:46, Jens Axboe wrote: > If we're doing background type writes, then use the appropriate > background write flags for that. > > Signed-off-by: Jens Axboe Looks good. You can add: Reviewed-by: Jan Kara Honza

Re: [PATCH 1/8] block: add WRITE_BACKGROUND

On Tue 01-11-16 15:08:44, Jens Axboe wrote: > This adds a new request flag, REQ_BACKGROUND, that callers can use to > tell the block layer that this is background (non-urgent) IO. > > Signed-off-by: Jens Axboe Looks good. You can add: Reviewed-by: Jan Kara

Re: [PATCH] clk: rockchip: Ignore frac divisor for PLL equivalence when it's unused

Am Mittwoch, 2. November 2016, 16:43:24 CET schrieb Julius Werner: > Rockchip RK3399 PLLs can be used in two separate modes: integral and > fractional. We can select between these two modes with the unambiguously > named DSMPD bit. > > During boot, we check all PLL settings to confirm that they

Re: [PATCH] clk: rockchip: Ignore frac divisor for PLL equivalence when it's unused

Am Mittwoch, 2. November 2016, 16:43:24 CET schrieb Julius Werner: > Rockchip RK3399 PLLs can be used in two separate modes: integral and > fractional. We can select between these two modes with the unambiguously > named DSMPD bit. > > During boot, we check all PLL settings to confirm that they

[PULL REQUEST] i2c for 4.9

Linus, here is a bugfix for the I2C core fixing a (rare) race condition. Please pull. Thanks, Wolfram The following changes since commit a909d3e636995ba7c349e2ca5dbb528154d4ac30: Linux 4.9-rc3 (2016-10-29 13:52:02 -0700) are available in the git repository at:

[PULL REQUEST] i2c for 4.9

Linus, here is a bugfix for the I2C core fixing a (rare) race condition. Please pull. Thanks, Wolfram The following changes since commit a909d3e636995ba7c349e2ca5dbb528154d4ac30: Linux 4.9-rc3 (2016-10-29 13:52:02 -0700) are available in the git repository at:

Re: [PATCH] clk: rockchip: remove more CLK_IGNORE_UNUSED for rk3399 clocktree

Am Donnerstag, 3. November 2016, 11:38:53 CET schrieb Jianqun Xu: > Optimize rk3399 clocktree by removing CLK_IGNORE_UNUSED of some clocks. > > clocks will managered by usb: > - clk_usbphy0_480m_src > - clk_usbphy1_480m_src > - clk_usbphy_480m > > clocks will be managered by pvtm: > -

Re: [PATCH] clk: rockchip: remove more CLK_IGNORE_UNUSED for rk3399 clocktree

Am Donnerstag, 3. November 2016, 11:38:53 CET schrieb Jianqun Xu: > Optimize rk3399 clocktree by removing CLK_IGNORE_UNUSED of some clocks. > > clocks will managered by usb: > - clk_usbphy0_480m_src > - clk_usbphy1_480m_src > - clk_usbphy_480m > > clocks will be managered by pvtm: > -

fsl_spdif.c:undefined reference to `byte_rev_table'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: fb415f222c26d0d1fa19615af1d102bf5f5b3ca2 commit: 8cfc8ddc99df9509a46043b14af81f5c6a223eab pstore: add lzo/lz4 compression support date: 5 months ago config: x86_64-randconfig-x001-201645 (attached as

fsl_spdif.c:undefined reference to `byte_rev_table'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: fb415f222c26d0d1fa19615af1d102bf5f5b3ca2 commit: 8cfc8ddc99df9509a46043b14af81f5c6a223eab pstore: add lzo/lz4 compression support date: 5 months ago config: x86_64-randconfig-x001-201645 (attached as

Re: fsnotify_mark_srcu wtf?

On Thu 03-11-16 12:25:13, Amir Goldstein wrote: > On Thu, Nov 3, 2016 at 12:09 AM, Miklos Szeredi wrote: > > We've got a report where a fanotify daemon that implements permission checks > > screws up and doesn't send a reply. This then causes widespread hangs due > > to > >

Re: fsnotify_mark_srcu wtf?

On Thu 03-11-16 12:25:13, Amir Goldstein wrote: > On Thu, Nov 3, 2016 at 12:09 AM, Miklos Szeredi wrote: > > We've got a report where a fanotify daemon that implements permission checks > > screws up and doesn't send a reply. This then causes widespread hangs due > > to > > fsnotify_mark_srcu

Re: fsnotify_mark_srcu wtf?

On Wed 02-11-16 23:09:26, Miklos Szeredi wrote: > We've got a report where a fanotify daemon that implements permission checks > screws up and doesn't send a reply. This then causes widespread hangs due to > fsnotify_mark_srcu read side lock being held and thus causing > synchronize_srcu() >

Re: fsnotify_mark_srcu wtf?

On Wed 02-11-16 23:09:26, Miklos Szeredi wrote: > We've got a report where a fanotify daemon that implements permission checks > screws up and doesn't send a reply. This then causes widespread hangs due to > fsnotify_mark_srcu read side lock being held and thus causing > synchronize_srcu() >

Re: [GIT PULL] overlayfs fixes for 4.9-rc3

On Sat, Nov 5, 2016 at 12:45 PM, Miklos Szeredi wrote: > > The feature that would be introduced is this: allow directory renames > to work without having to recursively copy-up the subtree. Whatever > mechanism is devised to do this will be backward incompatible. Maybe > it's

Re: [GIT PULL] overlayfs fixes for 4.9-rc3

On Sat, Nov 5, 2016 at 12:45 PM, Miklos Szeredi wrote: > > The feature that would be introduced is this: allow directory renames > to work without having to recursively copy-up the subtree. Whatever > mechanism is devised to do this will be backward incompatible. Maybe > it's a misguided idea,

Re: [PATCH v3 0/2] Add TI SCI Reset Driver

On 11/4/16 11:42 AM, Andrew F. Davis wrote: Hello all, This series adds a reset controller driver that uses the TI SCI protocol to manage resets. The TI SCI protocol is used to communicate with power management controllers used by some SoCs. These controllers manage the various power

Re: [PATCH v3 0/2] Add TI SCI Reset Driver

On 11/4/16 11:42 AM, Andrew F. Davis wrote: Hello all, This series adds a reset controller driver that uses the TI SCI protocol to manage resets. The TI SCI protocol is used to communicate with power management controllers used by some SoCs. These controllers manage the various power

Re: [PATCH 1/4] block: add scalable completion tracking of requests

On 11/04/2016 05:13 PM, Ming Lei wrote: Yes, that might be a good idea, since it doesn't cost us anything. For the mq case, I'm hard pressed to think of areas where we could complete IO in parallel on the same software queue. You'll never have a software queue mapped to multiple hardware queues.

Re: [PATCH 1/4] block: add scalable completion tracking of requests

On 11/04/2016 05:13 PM, Ming Lei wrote: Yes, that might be a good idea, since it doesn't cost us anything. For the mq case, I'm hard pressed to think of areas where we could complete IO in parallel on the same software queue. You'll never have a software queue mapped to multiple hardware queues.

Re: [PATCH 1/4] block: add scalable completion tracking of requests

On 11/04/2016 05:13 PM, Ming Lei wrote: Even though it is true, the statistics still may become a mess with rare collisons. How so? Not saying we could not improve it, but we're trading off precision for scalability. My claim is that the existing code is good enough. I've run a TON of testing

Re: [PATCH 1/4] block: add scalable completion tracking of requests

On 11/04/2016 05:13 PM, Ming Lei wrote: Even though it is true, the statistics still may become a mess with rare collisons. How so? Not saying we could not improve it, but we're trading off precision for scalability. My claim is that the existing code is good enough. I've run a TON of testing

Re: [PATCH 1/3] ovl: check fs features

On Tue, Oct 25, 2016 at 2:24 PM, Amir Goldstein wrote: > On Tue, Oct 25, 2016 at 10:34 AM, Miklos Szeredi wrote: >> To allow adding new, backward incompatible features to overlayfs, we need a >> way to store the list of features in the overlay. This is

Re: [PATCH 1/3] ovl: check fs features

On Tue, Oct 25, 2016 at 2:24 PM, Amir Goldstein wrote: > On Tue, Oct 25, 2016 at 10:34 AM, Miklos Szeredi wrote: >> To allow adding new, backward incompatible features to overlayfs, we need a >> way to store the list of features in the overlay. This is done via >> "trusted.overlay.features"

[PATCH] Staging: vme: vme_pio2: Prefer using the BIT macro

Replace all occurences of (1 << x) by BIT(x) in the file vme_pio2.h to get rid of checkpatch.pl "check" output "Prefer using the BIT macro". Signed-off-by: Shiva Kerdel --- drivers/staging/vme/devices/vme_pio2.h | 86 +- 1 file changed, 43

[PATCH] Staging: vme: vme_pio2: Prefer using the BIT macro

Replace all occurences of (1 << x) by BIT(x) in the file vme_pio2.h to get rid of checkpatch.pl "check" output "Prefer using the BIT macro". Signed-off-by: Shiva Kerdel --- drivers/staging/vme/devices/vme_pio2.h | 86 +- 1 file changed, 43 insertions(+), 43

Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

Hi! BTW.. This machine has nasty habit of hanging during kernel boot when it is "hot".. which makes reboots unplesant here. Ideas would be welcome how to debug that. Best regards, Pavel -- (english)

Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

Hi! BTW.. This machine has nasty habit of hanging during kernel boot when it is "hot".. which makes reboots unplesant here. Ideas would be welcome how to debug that. Best regards, Pavel -- (english)

Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

On Sat 2016-11-05 16:04:58, Henrique de Moraes Holschuh wrote: > On Sat, 05 Nov 2016, Pavel Machek wrote: > > [ 825.759661] thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something > > is extremely hot! > > [ 825.761935] thinkpad_acpi: temperatures (Celsius): 101 49 N/A 78 33 N/A > > 33

Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

On Sat 2016-11-05 16:04:58, Henrique de Moraes Holschuh wrote: > On Sat, 05 Nov 2016, Pavel Machek wrote: > > [ 825.759661] thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something > > is extremely hot! > > [ 825.761935] thinkpad_acpi: temperatures (Celsius): 101 49 N/A 78 33 N/A > > 33

  1   2   3   4   >