Linux-Next discussions
 help / color / mirror / Atom feed
* Re: next-20160225 build: 2 failures 44 warnings (next-20160225)
From: Thomas Petazzoni @ 2016-02-26  8:08 UTC (permalink / raw)
  To: Mark Brown
  Cc: Gregory CLEMENT, Olof Johansson, Arnd Bergmann,
	kernel-build-reports, linaro-kernel, linux-next, linux-arm-kernel,
	Bjorn Helgaas
In-Reply-To: <20160226030411.GK18327@sirena.org.uk>

Mark,

On Fri, 26 Feb 2016 12:04:11 +0900, Mark Brown wrote:

> Today's -next fails to build an arm64 allmodconfig due to:
> 
> > 	arm64-allmodconfig
> > ../drivers/pci/host/pci-mvebu.c:755:12: error: dereferencing pointer to incomplete type 'struct pci_sys_data'
> > ../drivers/pci/host/pci-mvebu.c:855:31: error: dereferencing pointer to incomplete type 'struct pci_sys_data'
> > ../drivers/pci/host/pci-mvebu.c:904:16: error: storage size of 'hw' isn't known
> > ../drivers/pci/host/pci-mvebu.c:919:2: error: implicit declaration of function 'pci_common_init_dev' [-Werror=implicit-function-declaration]
> > ../drivers/pci/host/pci-mvebu.c:1282:3: error: implicit declaration of function 'pci_ioremap_io' [-Werror=implicit-function-declaration]
> 
> caused by b4f596b19624 (arm64: add mvebu architecture entry) which
> enables MVBEU on arm64, the commit was present for a little while and
> the error cropped up but didn't get reported due to other things masking
> it.  This looks like the driver needs modernization and probably ought
> to have a !ARM64 dependency for now.

This has already been fixed by:

	[PATCH] PCI: mvebu: Restrict build to 32-bit ARM

submitted by Thierry Redding. I'm Cc'ing Bjorn, who is the one in
charge of merging this fix.

Thanks for reporting!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply

* Re: next-20160225 build: 2 failures 44 warnings (next-20160225)
From: Thomas Petazzoni @ 2016-02-26  8:14 UTC (permalink / raw)
  To: Mark Brown
  Cc: Gregory CLEMENT, Olof Johansson, Arnd Bergmann, Wim Van Sebroeck,
	Guenter Roeck, kernel-build-reports-cunTk1MwBs8s++Sfvej+rw,
	linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
	linux-next-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-watchdog-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20160226030949.GL18327-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>

Mark,

On Fri, 26 Feb 2016 12:09:49 +0900, Mark Brown wrote:

> also caused by b4f596b19624 (arm64: add mvebu architecture entry) which
> enables MVBEU on arm64, the commit was present for a little while and
> the error cropped up but didn't get reported due to other things masking
> it.  atomic_io_modify() is only available on ARM, I'm unsure if this
> needs a driver change or if the driver is just specific to older
> hardware anyway.  The code is only used in the init path accessing what
> look to be device specific registers so I'm not 100% clear why it
> specifically needs to be an atomic modify.

atomic_io_modify() is also used in the ->start() and ->stop() hooks, so
not only during initialization. The reason we use atomic_io_modify()
here is because this TIMER_CTRL register is shared with the clocksource
drivers (time-orion.c, time-armada-370-xp.c). Indeed, the timers and
watchdogs share a single register that allows to enable/disable all
timers/watchdogs. Somewhat unfortunate choice, but that's how the HW is.

By far the easiest solution is to add "depends on ARM" to
ORION_WATCHDOG.

Another solution would be to provide an implementation of
atomic_io_modify() on arm64, though that would need the ACK from the
ARM64 maintainers.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: next-20160225 build: 2 failures 44 warnings (next-20160225)
From: Thomas Petazzoni @ 2016-02-26  8:21 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Mark Brown, Gregory CLEMENT, Olof Johansson, Arnd Bergmann,
	Wim Van Sebroeck, kernel-build-reports-cunTk1MwBs8s++Sfvej+rw,
	linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
	linux-next-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-watchdog-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <56D001BE.2090209-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>

Guenter,

On Thu, 25 Feb 2016 23:41:50 -0800, Guenter Roeck wrote:

> > also caused by b4f596b19624 (arm64: add mvebu architecture entry) which
> > enables MVBEU on arm64, the commit was present for a little while and
> > the error cropped up but didn't get reported due to other things masking
> > it.  atomic_io_modify() is only available on ARM, I'm unsure if this
> > needs a driver change or if the driver is just specific to older
> > hardware anyway.  The code is only used in the init path accessing what
> > look to be device specific registers so I'm not 100% clear why it
> > specifically needs to be an atomic modify.
> >
> Thierry already submitted a patch yesterday to restrict the driver to only
> build on ARM. We can revisit if/when the driver is needed on ARM64.

Ah, good, thanks. It isn't clear yet whether the driver will be needed
on ARM64 for the Marvell platforms. For Armada 7K/8K, there is a SBSA
compliant watchdog. For Armada 3700, I have only briefly looked, but it
seems to be a different IP than the one used on the 32 bits SoCs.

Thanks Thierry for fixing the issue!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: next-20160225 build: 2 failures 44 warnings (next-20160225)
From: Kirill A. Shutemov @ 2016-02-26 10:37 UTC (permalink / raw)
  To: Stephen Rothwell, Sudeep Holla
  Cc: Build bot for Mark Brown, kernel-build-reports, linaro-kernel,
	linux-next, Andrew Morton
In-Reply-To: <20160226094928.608520d4@canb.auug.org.au>

On Fri, Feb 26, 2016 at 09:49:28AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> On Thu, 25 Feb 2016 10:04:29 +0000 Build bot for Mark Brown <broonie@kernel.org> wrote:
> >
> > 	arm64-allmodconfig
> > ../arch/arm64/mm/hugetlbpage.c:127:42: error: macro "pte_alloc_map" passed 4 arguments, but takes just 3
> > ../arch/arm64/mm/hugetlbpage.c:127:9: error: 'pte_alloc_map' undeclared (first use in this function)
> 
> Caused by an interaction between commit
> 
>   b9c9252f278d ("mm: cleanup *pte_alloc* interfaces")
> 
> from the akpm-current tree and commit
> 
>   66b3923a1a0f ("arm64: hugetlb: add support for PTE contiguous bit")
> 
> from Linus' tree (added before v4.5-rc1).
> 
> I will add a fix patch today that removes the second argument from the
> new pte_alloc_map() call added by the latter commit.

Sudeep Holla has posted patch for this.

http://lkml.kernel.org/r/1456414385-13775-1-git-send-email-sudeep.holla@arm.com

> 
> Again, grep is your friend ... (yes, I realise that the akpm-current
> tree patch was probably written against v4.4 (or some such)).
> -- 
> Cheers,
> Stephen Rothwell

-- 
 Kirill A. Shutemov

^ permalink raw reply

* next-20160226 build: 2 failures 44 warnings (next-20160226)
From: Build bot for Mark Brown @ 2016-02-26 12:00 UTC (permalink / raw)
  To: kernel-build-reports, linaro-kernel, linux-next

Tree/Branch: next-20160226
Git describe: next-20160226
Commit: 4639ea604f Add linux-next specific files for 20160226

Build Time: 137 min 43 sec

Passed:    7 / 9   ( 77.78 %)
Failed:    2 / 9   ( 22.22 %)

Errors: 7
Warnings: 44
Section Mismatches: 0

Failed defconfigs:
	arm64-allmodconfig

Errors:

	arm64-allmodconfig
../drivers/pci/host/pci-mvebu.c:755:12: error: dereferencing pointer to incomplete type 'struct pci_sys_data'
../drivers/pci/host/pci-mvebu.c:855:31: error: dereferencing pointer to incomplete type 'struct pci_sys_data'
../drivers/pci/host/pci-mvebu.c:904:16: error: storage size of 'hw' isn't known
../drivers/pci/host/pci-mvebu.c:919:2: error: implicit declaration of function 'pci_common_init_dev' [-Werror=implicit-function-declaration]
../drivers/pci/host/pci-mvebu.c:1282:3: error: implicit declaration of function 'pci_ioremap_io' [-Werror=implicit-function-declaration]
../drivers/watchdog/orion_wdt.c:109:2: error: implicit declaration of function 'atomic_io_modify' [-Werror=implicit-function-declaration]

-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
     74 warnings    0 mismatches  : arm64-allmodconfig
      2 warnings    0 mismatches  : arm-multi_v5_defconfig
      2 warnings    0 mismatches  : arm-multi_v7_defconfig
     10 warnings    0 mismatches  : arm-allmodconfig
      1 warnings    0 mismatches  : arm-allnoconfig

-------------------------------------------------------------------------------

Errors summary: 7
	  4 drivers/gpio/Kconfig:34:error: recursive dependency detected!
	  1 ../drivers/watchdog/orion_wdt.c:109:2: error: implicit declaration of function 'atomic_io_modify' [-Werror=implicit-function-declaration]
	  1 ../drivers/pci/host/pci-mvebu.c:919:2: error: implicit declaration of function 'pci_common_init_dev' [-Werror=implicit-function-declaration]
	  1 ../drivers/pci/host/pci-mvebu.c:904:16: error: storage size of 'hw' isn't known
	  1 ../drivers/pci/host/pci-mvebu.c:855:31: error: dereferencing pointer to incomplete type 'struct pci_sys_data'
	  1 ../drivers/pci/host/pci-mvebu.c:755:12: error: dereferencing pointer to incomplete type 'struct pci_sys_data'
	  1 ../drivers/pci/host/pci-mvebu.c:1282:3: error: implicit declaration of function 'pci_ioremap_io' [-Werror=implicit-function-declaration]

Warnings Summary: 44
	  7 <stdin>:1310:2: warning: #warning syscall madvisev not implemented [-Wcpp]
	  6 ../include/trace/events/page_ref.h:97:18: warning: 'struct page' declared inside parameter list
	  6 ../include/trace/events/page_ref.h:54:18: warning: 'struct page' declared inside parameter list
	  6 ../include/trace/events/page_ref.h:47:18: warning: 'struct page' declared inside parameter list
	  6 ../include/trace/events/page_ref.h:125:18: warning: 'struct page' declared inside parameter list
	  6 ../include/trace/events/page_ref.h:118:18: warning: 'struct page' declared inside parameter list
	  6 ../include/trace/events/page_ref.h:111:18: warning: 'struct page' declared inside parameter list
	  6 ../include/trace/events/page_ref.h:104:18: warning: 'struct page' declared inside parameter list
	  4 ../include/linux/kern_levels.h:4:18: warning: field width specifier '*' expects argument of type 'int', but argument 2 has type 'long unsigned int' [-Wformat=]
	  2 ../drivers/platform/goldfish/goldfish_pipe.c:312:3: warning: 'get_user_pages8' is deprecated [-Wdeprecated-declarations]
	  1 ../mm/debug_page_ref.c:8:21: warning: passing argument 1 of 'trace_page_ref_set' from incompatible pointer type [-Wincompatible-pointer-types]
	  1 ../mm/debug_page_ref.c:50:26: warning: passing argument 1 of 'trace_page_ref_unfreeze' from incompatible pointer type [-Wincompatible-pointer-types]
	  1 ../mm/debug_page_ref.c:43:24: warning: passing argument 1 of 'trace_page_ref_freeze' from incompatible pointer type [-Wincompatible-pointer-types]
	  1 ../mm/debug_page_ref.c:36:28: warning: passing argument 1 of 'trace_page_ref_mod_unless' from incompatible pointer type [-Wincompatible-pointer-types]
	  1 ../mm/debug_page_ref.c:29:32: warning: passing argument 1 of 'trace_page_ref_mod_and_return' from incompatible pointer type [-Wincompatible-pointer-types]
	  1 ../mm/debug_page_ref.c:22:30: warning: passing argument 1 of 'trace_page_ref_mod_and_test' from incompatible pointer type [-Wincompatible-pointer-types]
	  1 ../mm/debug_page_ref.c:15:21: warning: passing argument 1 of 'trace_page_ref_mod' from incompatible pointer type [-Wincompatible-pointer-types]
	  1 ../lib/lz4/lz4hc_compress.c:514:1: warning: the frame size of 1472 bytes is larger than 1024 bytes [-Wframe-larger-than=]
	  1 ../include/trace/trace_events.h:703:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_unfreeze' from incompatible pointer type [-Wincompatible-pointer-types]
	  1 ../include/trace/trace_events.h:703:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_set' from incompatible pointer type [-Wincompatible-pointer-types]
	  1 ../include/trace/trace_events.h:703:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_mod_unless' from incompatible pointer type [-Wincompatible-pointer-types]
	  1 ../include/trace/trace_events.h:703:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_mod_and_test' from incompatible pointer type [-Wincompatible-pointer-types]
	  1 ../include/trace/trace_events.h:703:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_mod_and_return' from incompatible pointer type [-Wincompatible-pointer-types]
	  1 ../include/trace/trace_events.h:703:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_mod' from incompatible pointer type [-Wincompatible-pointer-types]
	  1 ../include/trace/trace_events.h:703:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_freeze' from incompatible pointer type [-Wincompatible-pointer-types]
	  1 ../include/trace/perf.h:83:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_unfreeze' from incompatible pointer type [-Wincompatible-pointer-types]
	  1 ../include/trace/perf.h:83:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_set' from incompatible pointer type [-Wincompatible-pointer-types]
	  1 ../include/trace/perf.h:83:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_mod_unless' from incompatible pointer type [-Wincompatible-pointer-types]
	  1 ../include/trace/perf.h:83:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_mod_and_test' from incompatible pointer type [-Wincompatible-pointer-types]
	  1 ../include/trace/perf.h:83:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_mod_and_return' from incompatible pointer type [-Wincompatible-pointer-types]
	  1 ../include/trace/perf.h:83:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_mod' from incompatible pointer type [-Wincompatible-pointer-types]
	  1 ../include/trace/perf.h:83:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_freeze' from incompatible pointer type [-Wincompatible-pointer-types]
	  1 ../include/trace/events/page_ref.h:47:18: warning: its scope is only this definition or declaration, which is probably not what you want
	  1 ../include/asm-generic/div64.h:224:22: warning: passing argument 1 of '__div64_32' from incompatible pointer type [-Wincompatible-pointer-types]
	  1 ../include/asm-generic/div64.h:220:25: warning: right shift count >= width of type [-Wshift-count-overflow]
	  1 ../include/asm-generic/div64.h:207:28: warning: comparison of distinct pointer types lacks a cast
	  1 ../drivers/pci/host/pci-mvebu.c:904:16: warning: unused variable 'hw' [-Wunused-variable]
	  1 ../drivers/pci/host/pci-mvebu.c:841:40: warning: passing argument 1 of 'sys_to_pcie' from incompatible pointer type [-Wincompatible-pointer-types]
	  1 ../drivers/pci/host/pci-mvebu.c:839:44: warning: 'struct pci_sys_data' declared inside parameter list
	  1 ../drivers/pci/host/pci-mvebu.c:753:53: warning: its scope is only this definition or declaration, which is probably not what you want
	  1 ../drivers/pci/host/pci-mvebu.c:753:53: warning: 'struct pci_sys_data' declared inside parameter list
	  1 ../drivers/ntb/test/ntb_perf.c:214:14: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
	  1 ../drivers/ntb/test/ntb_perf.c:213:10: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
	  1 ../drivers/mtd/chips/cfi_cmdset_0020.c:651:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]



===============================================================================
Detailed per-defconfig build reports below:


-------------------------------------------------------------------------------
arm64-allmodconfig : FAIL, 6 errors, 74 warnings, 0 section mismatches

Errors:
	../drivers/pci/host/pci-mvebu.c:755:12: error: dereferencing pointer to incomplete type 'struct pci_sys_data'
	../drivers/pci/host/pci-mvebu.c:855:31: error: dereferencing pointer to incomplete type 'struct pci_sys_data'
	../drivers/pci/host/pci-mvebu.c:904:16: error: storage size of 'hw' isn't known
	../drivers/pci/host/pci-mvebu.c:919:2: error: implicit declaration of function 'pci_common_init_dev' [-Werror=implicit-function-declaration]
	../drivers/pci/host/pci-mvebu.c:1282:3: error: implicit declaration of function 'pci_ioremap_io' [-Werror=implicit-function-declaration]
	../drivers/watchdog/orion_wdt.c:109:2: error: implicit declaration of function 'atomic_io_modify' [-Werror=implicit-function-declaration]

Warnings:
	../include/trace/events/page_ref.h:47:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:47:18: warning: its scope is only this definition or declaration, which is probably not what you want
	../include/trace/events/page_ref.h:47:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:47:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:47:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:47:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:47:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:54:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:54:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:54:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:54:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:54:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:54:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:97:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:97:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:97:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:97:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:97:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:97:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:104:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:104:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:104:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:104:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:104:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:104:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:111:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:111:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:111:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:111:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:111:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:111:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:118:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:118:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:118:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:118:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:118:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:118:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:125:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:125:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:125:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:125:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:125:18: warning: 'struct page' declared inside parameter list
	../include/trace/events/page_ref.h:125:18: warning: 'struct page' declared inside parameter list
	../include/trace/trace_events.h:703:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_set' from incompatible pointer type [-Wincompatible-pointer-types]
	../include/trace/trace_events.h:703:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_mod' from incompatible pointer type [-Wincompatible-pointer-types]
	../include/trace/trace_events.h:703:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_mod_and_test' from incompatible pointer type [-Wincompatible-pointer-types]
	../include/trace/trace_events.h:703:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_mod_and_return' from incompatible pointer type [-Wincompatible-pointer-types]
	../include/trace/trace_events.h:703:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_mod_unless' from incompatible pointer type [-Wincompatible-pointer-types]
	../include/trace/trace_events.h:703:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_freeze' from incompatible pointer type [-Wincompatible-pointer-types]
	../include/trace/trace_events.h:703:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_unfreeze' from incompatible pointer type [-Wincompatible-pointer-types]
	../include/trace/perf.h:83:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_set' from incompatible pointer type [-Wincompatible-pointer-types]
	../include/trace/perf.h:83:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_mod' from incompatible pointer type [-Wincompatible-pointer-types]
	../include/trace/perf.h:83:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_mod_and_test' from incompatible pointer type [-Wincompatible-pointer-types]
	../include/trace/perf.h:83:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_mod_and_return' from incompatible pointer type [-Wincompatible-pointer-types]
	../include/trace/perf.h:83:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_mod_unless' from incompatible pointer type [-Wincompatible-pointer-types]
	../include/trace/perf.h:83:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_freeze' from incompatible pointer type [-Wincompatible-pointer-types]
	../include/trace/perf.h:83:35: warning: passing argument 1 of 'check_trace_callback_type_page_ref_unfreeze' from incompatible pointer type [-Wincompatible-pointer-types]
	../mm/debug_page_ref.c:8:21: warning: passing argument 1 of 'trace_page_ref_set' from incompatible pointer type [-Wincompatible-pointer-types]
	../mm/debug_page_ref.c:15:21: warning: passing argument 1 of 'trace_page_ref_mod' from incompatible pointer type [-Wincompatible-pointer-types]
	../mm/debug_page_ref.c:22:30: warning: passing argument 1 of 'trace_page_ref_mod_and_test' from incompatible pointer type [-Wincompatible-pointer-types]
	../mm/debug_page_ref.c:29:32: warning: passing argument 1 of 'trace_page_ref_mod_and_return' from incompatible pointer type [-Wincompatible-pointer-types]
	../mm/debug_page_ref.c:36:28: warning: passing argument 1 of 'trace_page_ref_mod_unless' from incompatible pointer type [-Wincompatible-pointer-types]
	../mm/debug_page_ref.c:43:24: warning: passing argument 1 of 'trace_page_ref_freeze' from incompatible pointer type [-Wincompatible-pointer-types]
	../mm/debug_page_ref.c:50:26: warning: passing argument 1 of 'trace_page_ref_unfreeze' from incompatible pointer type [-Wincompatible-pointer-types]
	../include/linux/kern_levels.h:4:18: warning: field width specifier '*' expects argument of type 'int', but argument 2 has type 'long unsigned int' [-Wformat=]
	../include/linux/kern_levels.h:4:18: warning: field width specifier '*' expects argument of type 'int', but argument 2 has type 'long unsigned int' [-Wformat=]
	../include/linux/kern_levels.h:4:18: warning: field width specifier '*' expects argument of type 'int', but argument 2 has type 'long unsigned int' [-Wformat=]
	../include/linux/kern_levels.h:4:18: warning: field width specifier '*' expects argument of type 'int', but argument 2 has type 'long unsigned int' [-Wformat=]
	../drivers/platform/goldfish/goldfish_pipe.c:312:3: warning: 'get_user_pages8' is deprecated [-Wdeprecated-declarations]
	../drivers/pci/host/pci-mvebu.c:753:53: warning: 'struct pci_sys_data' declared inside parameter list
	../drivers/pci/host/pci-mvebu.c:753:53: warning: its scope is only this definition or declaration, which is probably not what you want
	../drivers/pci/host/pci-mvebu.c:839:44: warning: 'struct pci_sys_data' declared inside parameter list
	../drivers/pci/host/pci-mvebu.c:841:40: warning: passing argument 1 of 'sys_to_pcie' from incompatible pointer type [-Wincompatible-pointer-types]
	../drivers/pci/host/pci-mvebu.c:904:16: warning: unused variable 'hw' [-Wunused-variable]

-------------------------------------------------------------------------------
arm-multi_v5_defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches

Warnings:
	<stdin>:1310:2: warning: #warning syscall madvisev not implemented [-Wcpp]
	<stdin>:1310:2: warning: #warning syscall madvisev not implemented [-Wcpp]

-------------------------------------------------------------------------------
arm-multi_v7_defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches

Warnings:
	<stdin>:1310:2: warning: #warning syscall madvisev not implemented [-Wcpp]
	<stdin>:1310:2: warning: #warning syscall madvisev not implemented [-Wcpp]

-------------------------------------------------------------------------------
x86_64-defconfig : PASS, 2 errors, 0 warnings, 0 section mismatches

Errors:
	drivers/gpio/Kconfig:34:error: recursive dependency detected!
	drivers/gpio/Kconfig:34:error: recursive dependency detected!

-------------------------------------------------------------------------------
arm-allmodconfig : PASS, 0 errors, 10 warnings, 0 section mismatches

Warnings:
	<stdin>:1310:2: warning: #warning syscall madvisev not implemented [-Wcpp]
	../lib/lz4/lz4hc_compress.c:514:1: warning: the frame size of 1472 bytes is larger than 1024 bytes [-Wframe-larger-than=]
	../include/asm-generic/div64.h:207:28: warning: comparison of distinct pointer types lacks a cast
	../include/asm-generic/div64.h:220:25: warning: right shift count >= width of type [-Wshift-count-overflow]
	../include/asm-generic/div64.h:224:22: warning: passing argument 1 of '__div64_32' from incompatible pointer type [-Wincompatible-pointer-types]
	../drivers/mtd/chips/cfi_cmdset_0020.c:651:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]
	../drivers/ntb/test/ntb_perf.c:213:10: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
	../drivers/ntb/test/ntb_perf.c:214:14: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
	../drivers/platform/goldfish/goldfish_pipe.c:312:3: warning: 'get_user_pages8' is deprecated [-Wdeprecated-declarations]
	<stdin>:1310:2: warning: #warning syscall madvisev not implemented [-Wcpp]

-------------------------------------------------------------------------------
arm-allnoconfig : PASS, 0 errors, 1 warnings, 0 section mismatches

Warnings:
	<stdin>:1310:2: warning: #warning syscall madvisev not implemented [-Wcpp]

-------------------------------------------------------------------------------
x86_64-allnoconfig : PASS, 2 errors, 0 warnings, 0 section mismatches

Errors:
	drivers/gpio/Kconfig:34:error: recursive dependency detected!
	drivers/gpio/Kconfig:34:error: recursive dependency detected!
-------------------------------------------------------------------------------

Passed with no errors, warnings or mismatches:

arm64-allnoconfig
arm64-defconfig
close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr

^ permalink raw reply

* Re: next-20160225 build: 2 failures 44 warnings (next-20160225)
From: Mark Brown @ 2016-02-26 12:12 UTC (permalink / raw)
  To: Thomas Petazzoni
  Cc: Gregory CLEMENT, Olof Johansson, Arnd Bergmann, Wim Van Sebroeck,
	Guenter Roeck, kernel-build-reports-cunTk1MwBs8s++Sfvej+rw,
	linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
	linux-next-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-watchdog-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20160226091410.5dad4306-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 896 bytes --]

On Fri, Feb 26, 2016 at 09:14:10AM +0100, Thomas Petazzoni wrote:

> atomic_io_modify() is also used in the ->start() and ->stop() hooks, so
> not only during initialization. The reason we use atomic_io_modify()
> here is because this TIMER_CTRL register is shared with the clocksource
> drivers (time-orion.c, time-armada-370-xp.c). Indeed, the timers and
> watchdogs share a single register that allows to enable/disable all
> timers/watchdogs. Somewhat unfortunate choice, but that's how the HW is.

> By far the easiest solution is to add "depends on ARM" to
> ORION_WATCHDOG.

> Another solution would be to provide an implementation of
> atomic_io_modify() on arm64, though that would need the ACK from the
> ARM64 maintainers.

It also sounds like a more modern solution might be to use syscon for
the shared register, but perhaps I'm missing something about how the IP
is set up so ICBW.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

^ permalink raw reply

* Re: linux-next: build failure after merge of the akpm-current tree
From: Dave Hansen @ 2016-02-26 16:14 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Helge Deller
In-Reply-To: <20160226164406.065a1ffc@canb.auug.org.au>

On 02/25/2016 09:44 PM, Stephen Rothwell wrote:
> The addition of the "u64 _pkey" has presumably changed the alignment of
> the enclosing union on (some) 32 bit platforms and so added padding
> after the si_code field.  This is a user API issue. :-(
> 
> [As an aside, I am pretty sure that we should not be using "u64" in a
> uapi header in any case.]

Ahh, so if _addr_bnd wasn't 64-bit-aligned, the compiler is free to
align it and enlarge the structure.  But, this only applied to
architectures where _addr_bnd wasn't 64-bit-aligned:

Would anybody object to _pkey being an 'unsigned long'?  It would at
least keep existing 64-bit userspace (mostly my tests) from having to
change.

Here's the snippet of the struct in question:

>                         union {
>                                 /* used when si_code=SEGV_BNDERR */
>                                 struct {
>                                         void __user *_lower;
>                                         void __user *_upper;
>                                 } _addr_bnd;
>                                 /* used when si_code=SEGV_PKUERR */
>                                 u64 _pkey;
>                         };

^ permalink raw reply

* [PATCH] x86, pkeys: fix siginfo ABI breakage from new field
From: Dave Hansen @ 2016-02-26 17:34 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dave Hansen, dave.hansen, sfr, akpm, tglx, mingo, hpa, peterz,
	linux-next, deller


From: Dave Hansen <dave.hansen@linux.intel.com>

Stephen Rothwell reported:

	http://lkml.kernel.org/r/20160226164406.065a1ffc@canb.auug.org.au

that the Memory Protection Keys patches from the tip tree broke
a build-time check on an ARM build because they changed the ABI
of siginfo.

A u64 was used for the protection key field in siginfo.  When the
containing union was aligned, this u64 unioned nicely with the
two 'void *'s in _addr_bnd.  But, on 32-bit, if the union was
unaligned, the u64 might grow the size of the union, breaking the
ABI for subsequent fields.

To fix this, we replace the u64 with an 'unsigned long'.  The long
is guaranteed to union well with the pointers from _addr_bnd.  It
is also plenty large enough to store the 16-bit pkey we have today
on x86.  This also has the advantage that it allows existing 64-bit
userspace to keep working without modification.

I also shouldn't have been using a u64 in a userspace API to begin
with.

Fixes: cd0ea35ff551 ("signals, pkeys: Notify userspace about protection key faults")
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linux-next@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Helge Deller <deller@gmx.de>
---

 b/arch/ia64/include/uapi/asm/siginfo.h |    2 +-
 b/arch/mips/include/uapi/asm/siginfo.h |    2 +-
 b/include/uapi/asm-generic/siginfo.h   |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff -puN include/uapi/asm-generic/siginfo.h~pkeys-101-fix-siginfo include/uapi/asm-generic/siginfo.h
--- a/include/uapi/asm-generic/siginfo.h~pkeys-101-fix-siginfo	2016-02-26 08:50:47.760659292 -0800
+++ b/include/uapi/asm-generic/siginfo.h	2016-02-26 08:52:08.591330838 -0800
@@ -98,7 +98,7 @@ typedef struct siginfo {
 					void __user *_upper;
 				} _addr_bnd;
 				/* used when si_code=SEGV_PKUERR */
-				u64 _pkey;
+				unsigned long _pkey;
 			};
 		} _sigfault;
 
diff -puN arch/mips/include/uapi/asm/siginfo.h~pkeys-101-fix-siginfo arch/mips/include/uapi/asm/siginfo.h
--- a/arch/mips/include/uapi/asm/siginfo.h~pkeys-101-fix-siginfo	2016-02-26 08:51:50.357502608 -0800
+++ b/arch/mips/include/uapi/asm/siginfo.h	2016-02-26 08:51:55.206722873 -0800
@@ -93,7 +93,7 @@ typedef struct siginfo {
 					void __user *_upper;
 				} _addr_bnd;
 				/* used when si_code=SEGV_PKUERR */
-				u64 _pkey;
+				unsigned long _pkey;
 			};
 		} _sigfault;
 
diff -puN arch/ia64/include/uapi/asm/siginfo.h~pkeys-101-fix-siginfo arch/ia64/include/uapi/asm/siginfo.h
--- a/arch/ia64/include/uapi/asm/siginfo.h~pkeys-101-fix-siginfo	2016-02-26 08:51:50.413505152 -0800
+++ b/arch/ia64/include/uapi/asm/siginfo.h	2016-02-26 08:52:00.806977252 -0800
@@ -70,7 +70,7 @@ typedef struct siginfo {
 					void __user *_upper;
 				} _addr_bnd;
 				/* used when si_code=SEGV_PKUERR */
-				u64 _pkey;
+				unsigned long _pkey;
 			};
 		} _sigfault;
 
_

^ permalink raw reply

* Re: [PATCH] x86, pkeys: fix siginfo ABI breakage from new field
From: H. Peter Anvin @ 2016-02-26 17:44 UTC (permalink / raw)
  To: Dave Hansen, linux-kernel
  Cc: dave.hansen, sfr, akpm, tglx, mingo, peterz, linux-next, deller
In-Reply-To: <20160226173427.54A6949F@viggo.jf.intel.com>

On February 26, 2016 9:34:27 AM PST, Dave Hansen <dave@sr71.net> wrote:
>
>From: Dave Hansen <dave.hansen@linux.intel.com>
>
>Stephen Rothwell reported:
>
>	http://lkml.kernel.org/r/20160226164406.065a1ffc@canb.auug.org.au
>
>that the Memory Protection Keys patches from the tip tree broke
>a build-time check on an ARM build because they changed the ABI
>of siginfo.
>
>A u64 was used for the protection key field in siginfo.  When the
>containing union was aligned, this u64 unioned nicely with the
>two 'void *'s in _addr_bnd.  But, on 32-bit, if the union was
>unaligned, the u64 might grow the size of the union, breaking the
>ABI for subsequent fields.
>
>To fix this, we replace the u64 with an 'unsigned long'.  The long
>is guaranteed to union well with the pointers from _addr_bnd.  It
>is also plenty large enough to store the 16-bit pkey we have today
>on x86.  This also has the advantage that it allows existing 64-bit
>userspace to keep working without modification.
>
>I also shouldn't have been using a u64 in a userspace API to begin
>with.
>
>Fixes: cd0ea35ff551 ("signals, pkeys: Notify userspace about protection
>key faults")
>Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
>Cc: Stephen Rothwell <sfr@canb.auug.org.au>
>Cc: Andrew Morton <akpm@linux-foundation.org>
>Cc: Thomas Gleixner <tglx@linutronix.de>
>Cc: Ingo Molnar <mingo@elte.hu>
>Cc: "H. Peter Anvin" <hpa@zytor.com>
>Cc: Peter Zijlstra <peterz@infradead.org>
>Cc: linux-next@vger.kernel.org
>Cc: linux-kernel@vger.kernel.org
>Cc: Helge Deller <deller@gmx.de>
>---
>
> b/arch/ia64/include/uapi/asm/siginfo.h |    2 +-
> b/arch/mips/include/uapi/asm/siginfo.h |    2 +-
> b/include/uapi/asm-generic/siginfo.h   |    2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
>diff -puN include/uapi/asm-generic/siginfo.h~pkeys-101-fix-siginfo
>include/uapi/asm-generic/siginfo.h
>---
>a/include/uapi/asm-generic/siginfo.h~pkeys-101-fix-siginfo	2016-02-26
>08:50:47.760659292 -0800
>+++ b/include/uapi/asm-generic/siginfo.h	2016-02-26 08:52:08.591330838
>-0800
>@@ -98,7 +98,7 @@ typedef struct siginfo {
> 					void __user *_upper;
> 				} _addr_bnd;
> 				/* used when si_code=SEGV_PKUERR */
>-				u64 _pkey;
>+				unsigned long _pkey;
> 			};
> 		} _sigfault;
> 
>diff -puN arch/mips/include/uapi/asm/siginfo.h~pkeys-101-fix-siginfo
>arch/mips/include/uapi/asm/siginfo.h
>---
>a/arch/mips/include/uapi/asm/siginfo.h~pkeys-101-fix-siginfo	2016-02-26
>08:51:50.357502608 -0800
>+++ b/arch/mips/include/uapi/asm/siginfo.h	2016-02-26
>08:51:55.206722873 -0800
>@@ -93,7 +93,7 @@ typedef struct siginfo {
> 					void __user *_upper;
> 				} _addr_bnd;
> 				/* used when si_code=SEGV_PKUERR */
>-				u64 _pkey;
>+				unsigned long _pkey;
> 			};
> 		} _sigfault;
> 
>diff -puN arch/ia64/include/uapi/asm/siginfo.h~pkeys-101-fix-siginfo
>arch/ia64/include/uapi/asm/siginfo.h
>---
>a/arch/ia64/include/uapi/asm/siginfo.h~pkeys-101-fix-siginfo	2016-02-26
>08:51:50.413505152 -0800
>+++ b/arch/ia64/include/uapi/asm/siginfo.h	2016-02-26
>08:52:00.806977252 -0800
>@@ -70,7 +70,7 @@ typedef struct siginfo {
> 					void __user *_upper;
> 				} _addr_bnd;
> 				/* used when si_code=SEGV_PKUERR */
>-				u64 _pkey;
>+				unsigned long _pkey;
> 			};
> 		} _sigfault;
> 
>_

__u64 is okay, "unsigned long" is really messy in the presence of 32-on-64 bit ABIs...
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

^ permalink raw reply

* Re: [PATCH] PCI: mvebu: Restrict build to 32-bit ARM
From: Bjorn Helgaas @ 2016-02-26 19:31 UTC (permalink / raw)
  To: Thierry Reding
  Cc: Bjorn Helgaas, Jason Cooper, Andrew Lunn, Gregory Clement,
	Sebastian Hesselbarth, linux-pci, linux-arm-kernel, linux-kernel,
	linux-next
In-Reply-To: <1455802330-17565-1-git-send-email-thierry.reding@gmail.com>

On Thu, Feb 18, 2016 at 02:32:10PM +0100, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
> 
> This driver uses PCI glue that is only available on 32-bit ARM. This
> used to work fine as long as ARCH_MVEBU and ARCH_DOVE were exclusively
> 32-bit, but that's changed now, with ARCH_MVEBU also being available
> on 64-bit ARM.
> 
> Signed-off-by: Thierry Reding <treding@nvidia.com>

I applied this with Thomas' ack to my for-linus branch for v4.5, thanks
Thierry!

> ---
>  drivers/pci/host/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index 75a605426538..d1cdd9c992ac 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -14,6 +14,7 @@ config PCI_DRA7XX
>  config PCI_MVEBU
>  	bool "Marvell EBU PCIe controller"
>  	depends on ARCH_MVEBU || ARCH_DOVE
> +	depends on ARM
>  	depends on OF
>  
>  config PCIE_DW
> -- 
> 2.7.1
> 

^ permalink raw reply

* Re: next-20160225 build: 2 failures 44 warnings (next-20160225)
From: Bjorn Helgaas @ 2016-02-26 19:34 UTC (permalink / raw)
  To: Thomas Petazzoni
  Cc: Mark Brown, Gregory CLEMENT, Olof Johansson, Arnd Bergmann,
	kernel-build-reports, linaro-kernel, linux-next list, linux-arm
In-Reply-To: <20160226090830.41a63a86@free-electrons.com>

On Fri, Feb 26, 2016 at 2:08 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Mark,
>
> On Fri, 26 Feb 2016 12:04:11 +0900, Mark Brown wrote:
>
>> Today's -next fails to build an arm64 allmodconfig due to:
>>
>> >     arm64-allmodconfig
>> > ../drivers/pci/host/pci-mvebu.c:755:12: error: dereferencing pointer to incomplete type 'struct pci_sys_data'
>> > ../drivers/pci/host/pci-mvebu.c:855:31: error: dereferencing pointer to incomplete type 'struct pci_sys_data'
>> > ../drivers/pci/host/pci-mvebu.c:904:16: error: storage size of 'hw' isn't known
>> > ../drivers/pci/host/pci-mvebu.c:919:2: error: implicit declaration of function 'pci_common_init_dev' [-Werror=implicit-function-declaration]
>> > ../drivers/pci/host/pci-mvebu.c:1282:3: error: implicit declaration of function 'pci_ioremap_io' [-Werror=implicit-function-declaration]
>>
>> caused by b4f596b19624 (arm64: add mvebu architecture entry) which
>> enables MVBEU on arm64, the commit was present for a little while and
>> the error cropped up but didn't get reported due to other things masking
>> it.  This looks like the driver needs modernization and probably ought
>> to have a !ARM64 dependency for now.
>
> This has already been fixed by:
>
>         [PATCH] PCI: mvebu: Restrict build to 32-bit ARM
>
> submitted by Thierry Redding. I'm Cc'ing Bjorn, who is the one in
> charge of merging this fix.

I applied Thierry's patch ("PCI: mvebu: Restrict build to 32-bit ARM")
to my for-linus branch, so it should appear in Linus' tree before
v4.5.

Bjorn

^ permalink raw reply

* Re: linux-next: build failure after merge of the akpm-current tree
From: Dave Hansen @ 2016-02-26 20:10 UTC (permalink / raw)
  To: Stephen Rothwell, Andrew Morton, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Helge Deller
In-Reply-To: <20160226164406.065a1ffc@canb.auug.org.au>

On 02/25/2016 09:44 PM, Stephen Rothwell wrote:
> Fixes: cd0ea35ff551 ("signals, pkeys: Notify userspace about protection key faults")
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/ia64/include/uapi/asm/siginfo.h | 2 +-
>  arch/mips/include/uapi/asm/siginfo.h | 2 +-
>  include/uapi/asm-generic/siginfo.h   | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/ia64/include/uapi/asm/siginfo.h b/arch/ia64/include/uapi/asm/siginfo.h
> index 0151cfab929d..0c660bbccd3f 100644
> --- a/arch/ia64/include/uapi/asm/siginfo.h
> +++ b/arch/ia64/include/uapi/asm/siginfo.h
> @@ -70,7 +70,7 @@ typedef struct siginfo {
>  					void __user *_upper;
>  				} _addr_bnd;
>  				/* used when si_code=SEGV_PKUERR */
> -				u64 _pkey;
> +				int _pkey;
>  			};
>  		} _sigfault;

Considering Peter's feedback on my 'unsigned long' approach, I'm fine
with your patch, Stephen.  Can it just be picked up in to the tip tree?

Acked-by: Dave Hansen <dave.hansen@linux.intel.com>

^ permalink raw reply

* Re: linux-next: build failure after merge of the akpm-current tree
From: Andrew Morton @ 2016-02-26 21:33 UTC (permalink / raw)
  To: Dave Hansen
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Helge Deller
In-Reply-To: <56D0B11E.2050402@linux.intel.com>

On Fri, 26 Feb 2016 12:10:06 -0800 Dave Hansen <dave.hansen@linux.intel.com> wrote:

> On 02/25/2016 09:44 PM, Stephen Rothwell wrote:
> > Fixes: cd0ea35ff551 ("signals, pkeys: Notify userspace about protection key faults")
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> >  arch/ia64/include/uapi/asm/siginfo.h | 2 +-
> >  arch/mips/include/uapi/asm/siginfo.h | 2 +-
> >  include/uapi/asm-generic/siginfo.h   | 2 +-
> >  3 files changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/ia64/include/uapi/asm/siginfo.h b/arch/ia64/include/uapi/asm/siginfo.h
> > index 0151cfab929d..0c660bbccd3f 100644
> > --- a/arch/ia64/include/uapi/asm/siginfo.h
> > +++ b/arch/ia64/include/uapi/asm/siginfo.h
> > @@ -70,7 +70,7 @@ typedef struct siginfo {
> >  					void __user *_upper;
> >  				} _addr_bnd;
> >  				/* used when si_code=SEGV_PKUERR */
> > -				u64 _pkey;
> > +				int _pkey;
> >  			};
> >  		} _sigfault;
> 
> Considering Peter's feedback on my 'unsigned long' approach, I'm fine
> with your patch, Stephen.  Can it just be picked up in to the tip tree?
> 
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>

I've moved add-compile-time-check-for-__arch_si_preamble_size.patch to
be after linux-next and have added this patch (as
add-compile-time-check-for-__arch_si_preamble_size-fix.patch) to be
folded into add-compile-time-check-for-__arch_si_preamble_size.patch
later on.

So no -tip changes should be needed.

^ permalink raw reply

* Re: linux-next: manual merge of the akpm-current tree with the tip tree
From: Andrew Morton @ 2016-02-26 21:35 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Dave Hansen, Piotr Kwapulinski
In-Reply-To: <20160226160712.754b765c@canb.auug.org.au>

On Fri, 26 Feb 2016 16:07:12 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Andrew,
> 
> Today's linux-next merge of the akpm-current tree got a conflict in:
> 
>   mm/mprotect.c
> 
> between commit:
> 
>   62b5f7d013fc ("mm/core, x86/mm/pkeys: Add execute-only protection keys support")
> 
> from the tip tree and commit:
> 
>   aff3915ff831 ("mm/mprotect.c: don't imply PROT_EXEC on non-exec fs")
> 
> from the akpm-current tree.
> 
> I fixed it up (I think - see below) and can carry the fix as necessary
> (no action is required).
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc mm/mprotect.c
> index fa37c4cd973a,6ff5dfa65b33..000000000000
> --- a/mm/mprotect.c
> +++ b/mm/mprotect.c
> @@@ -414,7 -409,11 +411,11 @@@ SYSCALL_DEFINE3(mprotect, unsigned long
>   
>   		/* Here we know that vma->vm_start <= nstart < vma->vm_end. */
>   
> + 		/* Does the application expect PROT_READ to imply PROT_EXEC */
> + 		if (rier && (vma->vm_flags & VM_MAYEXEC))
> + 			prot |= PROT_EXEC;
> + 
>  -		newflags = calc_vm_prot_bits(prot);
>  +		newflags = calc_vm_prot_bits(prot, pkey);
>   		newflags |= (vma->vm_flags & ~(VM_READ | VM_WRITE | VM_EXEC));
>   
>   		/* newflags >> 4 shift VM_MAY% in place of VM_% */

OK, thanks.

I moved this patch
(mm-mprotectc-dont-imply-prot_exec-on-non-exec-fs.patch) into the
"post-linux-next" section and reworked it to accommodate the -tip
changes.



From: Piotr Kwapulinski <kwapulinski.piotr@gmail.com>
Subject: mm/mprotect.c: don't imply PROT_EXEC on non-exec fs

The mprotect(PROT_READ) fails when called by the READ_IMPLIES_EXEC binary
on a memory mapped file located on non-exec fs.  The mprotect does not
check whether fs is _executable_ or not.  The PROT_EXEC flag is set
automatically even if a memory mapped file is located on non-exec fs.  Fix
it by checking whether a memory mapped file is located on a non-exec fs. 
If so the PROT_EXEC is not implied by the PROT_READ.  The implementation
uses the VM_MAYEXEC flag set properly in mmap.  Now it is consistent with
mmap.

I did the isolated tests (PT_GNU_STACK X/NX, multiple VMAs, X/NX fs).  I
also patched the official 3.19.0-47-generic Ubuntu 14.04 kernel and it
seems to work.

Signed-off-by: Piotr Kwapulinski <kwapulinski.piotr@gmail.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/mprotect.c |   13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff -puN mm/mprotect.c~mm-mprotectc-dont-imply-prot_exec-on-non-exec-fs mm/mprotect.c
--- a/mm/mprotect.c~mm-mprotectc-dont-imply-prot_exec-on-non-exec-fs
+++ a/mm/mprotect.c
@@ -359,6 +359,9 @@ SYSCALL_DEFINE3(mprotect, unsigned long,
 	struct vm_area_struct *vma, *prev;
 	int error = -EINVAL;
 	const int grows = prot & (PROT_GROWSDOWN|PROT_GROWSUP);
+	const bool rier = (current->personality & READ_IMPLIES_EXEC) &&
+				(prot & PROT_READ);
+
 	prot &= ~(PROT_GROWSDOWN|PROT_GROWSUP);
 	if (grows == (PROT_GROWSDOWN|PROT_GROWSUP)) /* can't be both */
 		return -EINVAL;
@@ -375,11 +378,6 @@ SYSCALL_DEFINE3(mprotect, unsigned long,
 		return -EINVAL;
 
 	reqprot = prot;
-	/*
-	 * Does the application expect PROT_READ to imply PROT_EXEC:
-	 */
-	if ((prot & PROT_READ) && (current->personality & READ_IMPLIES_EXEC))
-		prot |= PROT_EXEC;
 
 	down_write(&current->mm->mmap_sem);
 
@@ -414,6 +412,10 @@ SYSCALL_DEFINE3(mprotect, unsigned long,
 
 		/* Here we know that vma->vm_start <= nstart < vma->vm_end. */
 
+		/* Does the application expect PROT_READ to imply PROT_EXEC */
+		if (rier && (vma->vm_flags & VM_MAYEXEC))
+			prot |= PROT_EXEC;
+
 		newflags = calc_vm_prot_bits(prot, pkey);
 		newflags |= (vma->vm_flags & ~(VM_READ | VM_WRITE | VM_EXEC));
 
@@ -445,6 +447,7 @@ SYSCALL_DEFINE3(mprotect, unsigned long,
 			error = -ENOMEM;
 			goto out;
 		}
+		prot = reqprot;
 	}
 out:
 	up_write(&current->mm->mmap_sem);
_

^ permalink raw reply

* Re: [PATCH] x86, pkeys: fix siginfo ABI breakage from new field
From: Stephen Rothwell @ 2016-02-26 22:10 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Dave Hansen, linux-kernel, dave.hansen, akpm, tglx, mingo, peterz,
	linux-next, deller
In-Reply-To: <6C5C3B9B-CAD6-4010-9A3E-AFFF7E13FAE3@zytor.com>

Hi,

On Fri, 26 Feb 2016 09:44:00 -0800 "H. Peter Anvin" <hpa@zytor.com> wrote:
>
> 
> __u64 is okay, "unsigned long" is really messy in the presence of 32-on-64 bit ABIs...

Yeah, but unfortunately, any 64 bit scalar type here will change the
alignment of the enclosing unions on (some) 32 bit platforms and thus
break the ABI.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply

* Re: linux-next: build failure after merge of the akpm-current tree
From: Stephen Rothwell @ 2016-02-26 22:49 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Dave Hansen, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Helge Deller
In-Reply-To: <20160226133350.911293e1582f07134febdf48@linux-foundation.org>

Hi Andrew,

On Fri, 26 Feb 2016 13:33:50 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> I've moved add-compile-time-check-for-__arch_si_preamble_size.patch to
> be after linux-next and have added this patch (as
> add-compile-time-check-for-__arch_si_preamble_size-fix.patch) to be
> folded into add-compile-time-check-for-__arch_si_preamble_size.patch
> later on.
> 
> So no -tip changes should be needed.

But the fix should go into the tip tree since the tip tree patch is not
correct even without this new build time check.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply

* Re: [PATCH] x86, pkeys: fix siginfo ABI breakage from new field
From: Ingo Molnar @ 2016-02-27 11:41 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: H. Peter Anvin, Dave Hansen, linux-kernel, dave.hansen, akpm,
	tglx, mingo, peterz, linux-next, deller
In-Reply-To: <20160227091013.6e0606d1@canb.auug.org.au>


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi,
> 
> On Fri, 26 Feb 2016 09:44:00 -0800 "H. Peter Anvin" <hpa@zytor.com> wrote:
> >
> > 
> > __u64 is okay, "unsigned long" is really messy in the presence of 32-on-64 bit ABIs...
> 
> Yeah, but unfortunately, any 64 bit scalar type here will change the
> alignment of the enclosing unions on (some) 32 bit platforms and thus
> break the ABI.

Then a different solution has to be found.

Thanks,

	Ingo

^ permalink raw reply

* Re: next-20160225 build: 2 failures 44 warnings (next-20160225)
From: Thomas Petazzoni @ 2016-02-27 14:40 UTC (permalink / raw)
  To: Mark Brown
  Cc: Gregory CLEMENT, Olof Johansson, Arnd Bergmann, Wim Van Sebroeck,
	Guenter Roeck, kernel-build-reports-cunTk1MwBs8s++Sfvej+rw,
	linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
	linux-next-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-watchdog-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20160226121220.GO18327-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>

Mark,

On Fri, 26 Feb 2016 21:12:20 +0900, Mark Brown wrote:

> > Another solution would be to provide an implementation of
> > atomic_io_modify() on arm64, though that would need the ACK from the
> > ARM64 maintainers.
> 
> It also sounds like a more modern solution might be to use syscon for
> the shared register, but perhaps I'm missing something about how the IP
> is set up so ICBW.

I think back when we implemented this, syscon/simple-mfd was
not available or widely used - I don't really remember. We could indeed
try to switch to a syscon based solution.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH] x86, pkeys: fix siginfo ABI breakage from new field
From: Dave Hansen @ 2016-02-27 19:16 UTC (permalink / raw)
  To: Ingo Molnar, Stephen Rothwell
  Cc: H. Peter Anvin, linux-kernel, dave.hansen, akpm, tglx, mingo,
	peterz, linux-next, deller
In-Reply-To: <20160227114154.GA16200@gmail.com>

On 02/27/2016 03:41 AM, Ingo Molnar wrote:
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> > On Fri, 26 Feb 2016 09:44:00 -0800 "H. Peter Anvin" <hpa@zytor.com> wrote:
>>> > > __u64 is okay, "unsigned long" is really messy in the presence of 32-on-64 bit ABIs...
>> > 
>> > Yeah, but unfortunately, any 64 bit scalar type here will change the
>> > alignment of the enclosing unions on (some) 32 bit platforms and thus
>> > break the ABI.
> Then a different solution has to be found.

I've acked Stephen's initial patch changing the 'u64' to an 'int'.  x86
only needs 4 bits, and in the remote chance that a future implementation
needed more space, we could easily add a second 32-bit field "_pkey_hi"
or something that wouldn't have the alignment issues of a true 64-bit type.

How should we get Stephen's patch in to the tip tree?

^ permalink raw reply

* Re: [PATCH] x86, pkeys: fix siginfo ABI breakage from new field
From: H. Peter Anvin @ 2016-02-27 19:35 UTC (permalink / raw)
  To: Dave Hansen, Ingo Molnar, Stephen Rothwell
  Cc: linux-kernel, dave.hansen, akpm, tglx, mingo, peterz, linux-next,
	deller
In-Reply-To: <56D1F61C.5050308@sr71.net>

On February 27, 2016 11:16:44 AM PST, Dave Hansen <dave@sr71.net> wrote:
>On 02/27/2016 03:41 AM, Ingo Molnar wrote:
>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>> > On Fri, 26 Feb 2016 09:44:00 -0800 "H. Peter Anvin"
><hpa@zytor.com> wrote:
>>>> > > __u64 is okay, "unsigned long" is really messy in the presence
>of 32-on-64 bit ABIs...
>>> > 
>>> > Yeah, but unfortunately, any 64 bit scalar type here will change
>the
>>> > alignment of the enclosing unions on (some) 32 bit platforms and
>thus
>>> > break the ABI.
>> Then a different solution has to be found.
>
>I've acked Stephen's initial patch changing the 'u64' to an 'int'.  x86
>only needs 4 bits, and in the remote chance that a future
>implementation
>needed more space, we could easily add a second 32-bit field "_pkey_hi"
>or something that wouldn't have the alignment issues of a true 64-bit
>type.
>
>How should we get Stephen's patch in to the tip tree?

u32?
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

^ permalink raw reply

* Re: [PATCH] x86, pkeys: fix siginfo ABI breakage from new field
From: Stephen Rothwell @ 2016-02-27 23:26 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Dave Hansen, Ingo Molnar, linux-kernel, dave.hansen, akpm, tglx,
	mingo, peterz, linux-next, deller
In-Reply-To: <9E8119F8-1F37-4084-AE31-34CA6DE8C15E@zytor.com>

Hi H.,

On Sat, 27 Feb 2016 11:35:08 -0800 "H. Peter Anvin" <hpa@zytor.com> wrote:
>
> On February 27, 2016 11:16:44 AM PST, Dave Hansen <dave@sr71.net> wrote:
> >On 02/27/2016 03:41 AM, Ingo Molnar wrote:  
> >> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:  
> >>> > On Fri, 26 Feb 2016 09:44:00 -0800 "H. Peter Anvin"  
> ><hpa@zytor.com> wrote:  
> >>>> > > __u64 is okay, "unsigned long" is really messy in the presence  
> >of 32-on-64 bit ABIs...  
> >>> > 
> >>> > Yeah, but unfortunately, any 64 bit scalar type here will change  
> >the  
> >>> > alignment of the enclosing unions on (some) 32 bit platforms and  
> >thus  
> >>> > break the ABI.  
> >> Then a different solution has to be found.  
> >
> >I've acked Stephen's initial patch changing the 'u64' to an 'int'.  x86
> >only needs 4 bits, and in the remote chance that a future
> >implementation
> >needed more space, we could easily add a second 32-bit field "_pkey_hi"
> >or something that wouldn't have the alignment issues of a true 64-bit
> >type.
> >
> >How should we get Stephen's patch in to the tip tree?  
> 
> u32?

It would have to be __u32, but we already use int and unsigned int
extensively in the siginfo structure (which are both always assumed to
be 32 bits).  So "unsigned int" probably makes most sense.

I will submit that patch - with Dave's Ack.
-- 
Cheers,
Stephen Rothwell

^ permalink raw reply

* [PATCH v2] signals, pkeys: make si_pkey 32 bits
From: Stephen Rothwell @ 2016-02-27 23:40 UTC (permalink / raw)
  To: H. Peter Anvin, Ingo Molnar, tglx, peterz
  Cc: Dave Hansen, linux-kernel, dave.hansen, akpm, mingo, linux-next,
	deller
In-Reply-To: <20160228102629.0ef4ef4f@canb.auug.org.au>

In order to prevent a change of alignment of the _sifields union in the
siginfo structure on (some) 32 bit platforms and an ABI breakage, we
change the type of _pkey to unsigned int.  If more bits are needed in
the future, a second unsigned int could be added.

Fixes: cd0ea35ff551 ("signals, pkeys: Notify userspace about protection key faults")
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/ia64/include/uapi/asm/siginfo.h | 2 +-
 arch/mips/include/uapi/asm/siginfo.h | 2 +-
 include/uapi/asm-generic/siginfo.h   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/ia64/include/uapi/asm/siginfo.h b/arch/ia64/include/uapi/asm/siginfo.h
index 0151cfab929d..19e7db0c9453 100644
--- a/arch/ia64/include/uapi/asm/siginfo.h
+++ b/arch/ia64/include/uapi/asm/siginfo.h
@@ -70,7 +70,7 @@ typedef struct siginfo {
 					void __user *_upper;
 				} _addr_bnd;
 				/* used when si_code=SEGV_PKUERR */
-				u64 _pkey;
+				unsigned int _pkey;
 			};
 		} _sigfault;
 
diff --git a/arch/mips/include/uapi/asm/siginfo.h b/arch/mips/include/uapi/asm/siginfo.h
index 6f4edf0d794c..3cc14f4a5936 100644
--- a/arch/mips/include/uapi/asm/siginfo.h
+++ b/arch/mips/include/uapi/asm/siginfo.h
@@ -93,7 +93,7 @@ typedef struct siginfo {
 					void __user *_upper;
 				} _addr_bnd;
 				/* used when si_code=SEGV_PKUERR */
-				u64 _pkey;
+				unsigned int _pkey;
 			};
 		} _sigfault;
 
diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h
index 90384d55225b..f4459dc3d31b 100644
--- a/include/uapi/asm-generic/siginfo.h
+++ b/include/uapi/asm-generic/siginfo.h
@@ -98,7 +98,7 @@ typedef struct siginfo {
 					void __user *_upper;
 				} _addr_bnd;
 				/* used when si_code=SEGV_PKUERR */
-				u64 _pkey;
+				unsigned int _pkey;
 			};
 		} _sigfault;
 
-- 
2.7.0

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply related

* linux-next: manual merge of the arm64 tree with the arm-soc tree
From: Stephen Rothwell @ 2016-02-28 23:51 UTC (permalink / raw)
  To: Catalin Marinas, Olof Johansson, Arnd Bergmann, linux-arm-kernel
  Cc: linux-next, linux-kernel, Jayachandran C, Florian Fainelli,
	Will Deacon

Hi Catalin,

Today's linux-next merge of the arm64 tree got a conflict in:

  arch/arm64/include/asm/cputype.h

between commit:

  9eb8a2cdf65c ("arm64: cputype info for Broadcom Vulcan")

from the arm-soc tree and commit:

  d5370f754875 ("arm64: prefetch: add alternative pattern for CPUs without a prefetcher")

from the arm64 tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/include/asm/cputype.h
index 3dcecdf3d6ee,b3a83da152a7..000000000000
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@@ -76,10 -80,20 +81,22 @@@
  
  #define CAVIUM_CPU_PART_THUNDERX	0x0A1
  
 +#define BRCM_CPU_PART_VULCAN		0x516
 +
+ #define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A53)
+ #define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A57)
+ #define MIDR_THUNDERX	MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)
+ 
  #ifndef __ASSEMBLY__
  
+ #include <asm/sysreg.h>
+ 
+ #define read_cpuid(reg) ({						\
+ 	u64 __val;							\
+ 	asm("mrs_s	%0, " __stringify(reg) : "=r" (__val));		\
+ 	__val;								\
+ })
+ 
  /*
   * The CPU ID never changes at run time, so we might as well tell the
   * compiler that it's constant.  Use this function to read the CPU ID

^ permalink raw reply

* linux-next: manual merge of the net-next tree with the wireless-drivers tree
From: Stephen Rothwell @ 2016-02-29  1:56 UTC (permalink / raw)
  To: David Miller, netdev, Kalle Valo
  Cc: linux-next, linux-kernel, Matti Gottlieb, Emmanuel Grumbach,
	Sara Sharon

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  drivers/net/wireless/intel/iwlwifi/mvm/fw.c

between commit:

  905e36ae172c ("iwlwifi: mvm: Fix paging memory leak")

from the wireless-drivers tree and commit:

  43413a975d06 ("iwlwifi: mvm: support rss queues configuration command")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/net/wireless/intel/iwlwifi/mvm/fw.c
index 0ccc697fef76,070e2af05ca2..000000000000
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
@@@ -107,7 -108,25 +108,25 @@@ static int iwl_send_tx_ant_cfg(struct i
  				    sizeof(tx_ant_cmd), &tx_ant_cmd);
  }
  
+ static int iwl_send_rss_cfg_cmd(struct iwl_mvm *mvm)
+ {
+ 	int i;
+ 	struct iwl_rss_config_cmd cmd = {
+ 		.flags = cpu_to_le32(IWL_RSS_ENABLE),
+ 		.hash_mask = IWL_RSS_HASH_TYPE_IPV4_TCP |
+ 			     IWL_RSS_HASH_TYPE_IPV4_PAYLOAD |
+ 			     IWL_RSS_HASH_TYPE_IPV6_TCP |
+ 			     IWL_RSS_HASH_TYPE_IPV6_PAYLOAD,
+ 	};
+ 
+ 	for (i = 0; i < ARRAY_SIZE(cmd.indirection_table); i++)
+ 		cmd.indirection_table[i] = i % mvm->trans->num_rx_queues;
+ 	memcpy(cmd.secret_key, mvm->secret_key, ARRAY_SIZE(cmd.secret_key));
+ 
+ 	return iwl_mvm_send_cmd_pdu(mvm, RSS_CONFIG_CMD, 0, sizeof(cmd), &cmd);
+ }
+ 
 -static void iwl_free_fw_paging(struct iwl_mvm *mvm)
 +void iwl_free_fw_paging(struct iwl_mvm *mvm)
  {
  	int i;
  

^ permalink raw reply

* linux-next: manual merge of the drm tree with Linus' tree
From: Stephen Rothwell @ 2016-02-29  2:59 UTC (permalink / raw)
  To: Dave Airlie
  Cc: linux-next, linux-kernel, Vitaly Prosyak, Alex Deucher,
	Mario Kleiner

Hi Dave,

Today's linux-next merge of the drm tree got a conflict in:

  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c

between commit:

  e1d09dc0ccc6 ("drm/amdgpu: Don't hang in amdgpu_flip_work_func on disabled crtc.")

from Linus' tree and commit:

  6bd9e877ce53 ("drm/amdgpu: Move MMIO flip out of spinlocked region")

from the drm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 8297bc319369,2cb53c24dec0..000000000000
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@@ -72,13 -70,16 +70,16 @@@ static void amdgpu_flip_work_func(struc
  
  	struct drm_crtc *crtc = &amdgpuCrtc->base;
  	unsigned long flags;
 -	unsigned i;
 -	int vpos, hpos, stat, min_udelay;
 +	unsigned i, repcnt = 4;
 +	int vpos, hpos, stat, min_udelay = 0;
  	struct drm_vblank_crtc *vblank = &crtc->dev->vblank[work->crtc_id];
  
- 	amdgpu_flip_wait_fence(adev, &work->excl);
+ 	if (amdgpu_flip_handle_fence(work, &work->excl))
+ 		return;
+ 
  	for (i = 0; i < work->shared_count; ++i)
- 		amdgpu_flip_wait_fence(adev, &work->shared[i]);
+ 		if (amdgpu_flip_handle_fence(work, &work->shared[i]))
+ 			return;
  
  	/* We borrow the event spin lock for protecting flip_status */
  	spin_lock_irqsave(&crtc->dev->event_lock, flags);
@@@ -123,19 -119,12 +124,19 @@@
  		spin_lock_irqsave(&crtc->dev->event_lock, flags);
  	};
  
 +	if (!repcnt)
 +		DRM_DEBUG_DRIVER("Delay problem on crtc %d: min_udelay %d, "
 +				 "framedur %d, linedur %d, stat %d, vpos %d, "
 +				 "hpos %d\n", work->crtc_id, min_udelay,
 +				 vblank->framedur_ns / 1000,
 +				 vblank->linedur_ns / 1000, stat, vpos, hpos);
 +
- 	/* do the flip (mmio) */
- 	adev->mode_info.funcs->page_flip(adev, work->crtc_id, work->base);
  	/* set the flip status */
  	amdgpuCrtc->pflip_status = AMDGPU_FLIP_SUBMITTED;
- 
  	spin_unlock_irqrestore(&crtc->dev->event_lock, flags);
+ 
+ 	/* Do the flip (mmio) */
+ 	adev->mode_info.funcs->page_flip(adev, work->crtc_id, work->base);
  }
  
  /*

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox