* [linux-4.19 test] 135420: regressions - FAIL
@ 2019-04-30 11:34 ` osstest service owner
0 siblings, 0 replies; 27+ messages in thread
From: osstest service owner @ 2019-04-30 11:34 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 135420 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135420/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail REGR. vs. 129313
test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 129313
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
Tests which did not succeed, but are not blocking:
test-armhf-armhf-examine 1 build-check(1) blocked n/a
test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a
test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a
test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a
test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a
test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a
test-armhf-armhf-xl 1 build-check(1) blocked n/a
test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a
test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt 1 build-check(1) blocked n/a
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-xl-pvshim 12 guest-start fail never pass
test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass
test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-xl 13 migrate-support-check fail never pass
test-arm64-arm64-xl 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass
test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemut-win10-i386 10 windows-install fail never pass
test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
version targeted for testing:
linux 19bb613acb9ad8e57593cad5118acaee117cc303
baseline version:
linux 84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d
Last test of basis 129313 2018-11-02 05:39:08 Z 179 days
Failing since 129412 2018-11-04 14:10:15 Z 176 days 112 attempts
Testing same since 135420 2019-04-29 12:28:24 Z 0 days 1 attempts
------------------------------------------------------------
1853 people touched revisions under test,
not listing them all
jobs:
build-amd64-xsm pass
build-arm64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-arm64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-arm64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-arm64-pvops pass
build-armhf-pvops fail
build-i386-pvops pass
test-amd64-amd64-xl pass
test-arm64-arm64-xl pass
test-armhf-armhf-xl blocked
test-amd64-i386-xl pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass
test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-arm64-arm64-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-arm64-arm64-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvhv2-amd pass
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-qemut-ws16-amd64 fail
test-amd64-i386-xl-qemut-ws16-amd64 fail
test-amd64-amd64-xl-qemuu-ws16-amd64 fail
test-amd64-i386-xl-qemuu-ws16-amd64 fail
test-armhf-armhf-xl-arndale blocked
test-amd64-amd64-xl-credit1 pass
test-arm64-arm64-xl-credit1 pass
test-armhf-armhf-xl-credit1 blocked
test-amd64-amd64-xl-credit2 pass
test-arm64-arm64-xl-credit2 pass
test-armhf-armhf-xl-credit2 blocked
test-armhf-armhf-xl-cubietruck blocked
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass
test-amd64-amd64-examine pass
test-arm64-arm64-examine pass
test-armhf-armhf-examine blocked
test-amd64-i386-examine pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-amd64-xl-qemut-win10-i386 fail
test-amd64-i386-xl-qemut-win10-i386 fail
test-amd64-amd64-xl-qemuu-win10-i386 fail
test-amd64-i386-xl-qemuu-win10-i386 fail
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvhv2-intel pass
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt blocked
test-amd64-i386-libvirt pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu blocked
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-xl-pvshim pass
test-amd64-i386-xl-pvshim fail
test-amd64-amd64-pygrub pass
test-amd64-amd64-xl-qcow2 fail
test-armhf-armhf-libvirt-raw blocked
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds pass
test-armhf-armhf-xl-rtds blocked
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-amd64-xl-shadow pass
test-amd64-i386-xl-shadow pass
test-amd64-amd64-libvirt-vhd fail
test-armhf-armhf-xl-vhd blocked
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
(No revision log; it would be 131444 lines long.)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 27+ messages in thread* [Xen-devel] [linux-4.19 test] 135420: regressions - FAIL @ 2019-04-30 11:34 ` osstest service owner 0 siblings, 0 replies; 27+ messages in thread From: osstest service owner @ 2019-04-30 11:34 UTC (permalink / raw) To: xen-devel, osstest-admin flight 135420 linux-4.19 real [real] http://logs.test-lab.xenproject.org/osstest/logs/135420/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail REGR. vs. 129313 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 129313 build-armhf-pvops 6 kernel-build fail REGR. vs. 129313 Tests which did not succeed, but are not blocking: test-armhf-armhf-examine 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit1 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt 13 migrate-support-check fail never pass test-amd64-i386-xl-pvshim 12 guest-start fail never pass test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass test-arm64-arm64-xl 13 migrate-support-check fail never pass test-arm64-arm64-xl 14 saverestore-support-check fail never pass test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemut-win10-i386 10 windows-install fail never pass test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass version targeted for testing: linux 19bb613acb9ad8e57593cad5118acaee117cc303 baseline version: linux 84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d Last test of basis 129313 2018-11-02 05:39:08 Z 179 days Failing since 129412 2018-11-04 14:10:15 Z 176 days 112 attempts Testing same since 135420 2019-04-29 12:28:24 Z 0 days 1 attempts ------------------------------------------------------------ 1853 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops pass build-armhf-pvops fail build-i386-pvops pass test-amd64-amd64-xl pass test-arm64-arm64-xl pass test-armhf-armhf-xl blocked test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm pass test-amd64-i386-libvirt-xsm pass test-amd64-amd64-xl-xsm pass test-arm64-arm64-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-qemuu-nested-amd fail test-amd64-amd64-xl-pvhv2-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64 pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-qemut-ws16-amd64 fail test-amd64-i386-xl-qemut-ws16-amd64 fail test-amd64-amd64-xl-qemuu-ws16-amd64 fail test-amd64-i386-xl-qemuu-ws16-amd64 fail test-armhf-armhf-xl-arndale blocked test-amd64-amd64-xl-credit1 pass test-arm64-arm64-xl-credit1 pass test-armhf-armhf-xl-credit1 blocked test-amd64-amd64-xl-credit2 pass test-arm64-arm64-xl-credit2 pass test-armhf-armhf-xl-credit2 blocked test-armhf-armhf-xl-cubietruck blocked test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass test-amd64-amd64-examine pass test-arm64-arm64-examine pass test-armhf-armhf-examine blocked test-amd64-i386-examine pass test-amd64-i386-freebsd10-i386 pass test-amd64-amd64-xl-qemut-win10-i386 fail test-amd64-i386-xl-qemut-win10-i386 fail test-amd64-amd64-xl-qemuu-win10-i386 fail test-amd64-i386-xl-qemuu-win10-i386 fail test-amd64-amd64-qemuu-nested-intel pass test-amd64-amd64-xl-pvhv2-intel pass test-amd64-i386-qemut-rhel6hvm-intel pass test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt pass test-amd64-amd64-xl-multivcpu pass test-armhf-armhf-xl-multivcpu blocked test-amd64-amd64-pair pass test-amd64-i386-pair pass test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair pass test-amd64-amd64-amd64-pvgrub pass test-amd64-amd64-i386-pvgrub pass test-amd64-amd64-xl-pvshim pass test-amd64-i386-xl-pvshim fail test-amd64-amd64-pygrub pass test-amd64-amd64-xl-qcow2 fail test-armhf-armhf-libvirt-raw blocked test-amd64-i386-xl-raw pass test-amd64-amd64-xl-rtds pass test-armhf-armhf-xl-rtds blocked test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass test-amd64-amd64-xl-shadow pass test-amd64-i386-xl-shadow pass test-amd64-amd64-libvirt-vhd fail test-armhf-armhf-xl-vhd blocked ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 131444 lines long.) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 27+ messages in thread
* linux 4.19 does not build on armhf Re: [linux-4.19 test] 135420: regressions - FAIL @ 2019-04-30 12:44 ` Ian Jackson 0 siblings, 0 replies; 27+ messages in thread From: Ian Jackson @ 2019-04-30 12:44 UTC (permalink / raw) To: Julien Grall, Stefano Stabellini; +Cc: xen-devel osstest service owner writes ("[linux-4.19 test] 135420: regressions - FAIL"): > flight 135420 linux-4.19 real [real] > http://logs.test-lab.xenproject.org/osstest/logs/135420/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > build-armhf-pvops 6 kernel-build fail REGR. vs. 129313 http://logs.test-lab.xenproject.org/osstest/logs/135420/build-armhf-pvops/6.ts-kernel-build.log drivers/firmware/qcom_scm.c: In function ‘qcom_scm_assign_mem’: drivers/firmware/qcom_scm.c:469:47: error: passing argument 3 of ‘dma_alloc_coherent’ from incompatible pointer type [-Werror=incompatible-pointer-types] ptr = dma_alloc_coherent(__scm->dev, ptr_sz, &ptr_phys, GFP_KERNEL); ^ In file included from drivers/firmware/qcom_scm.c:21:0: ./include/linux/dma-mapping.h:560:21: note: expected ‘dma_addr_t * {aka long long unsigned int *}’ but argument is of type ‘phys_addr_t * {aka unsigned int *}’ static inline void *dma_alloc_coherent(struct device *dev, size_t size, ^~~~~~~~~~~~~~~~~~ cc1: some warnings being treated as errors scripts/Makefile.build:303: recipe for target 'drivers/firmware/qcom_scm.o' failed make[2]: *** [drivers/firmware/qcom_scm.o] Error 1 scripts/Makefile.build:544: recipe for target 'drivers/firmware' failed make[1]: *** [drivers/firmware] Error 2 make[1]: *** Waiting for unfinished jobs.... I think this build failure is probably a regression; rather it is due to the stretch update which brings in a new compiler. However, I would prefer to avoid a force push because this build failure means that the armhf tests didn't run. > test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail REGR. vs. 129313 This is a known regression with the stretch upgrade and is nothing to do with linux-4.19 (or Xen, I think). > test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 129313 This is another bug, which looks like it is actually a bug in Linux 4.19. I will send another mail about it. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Xen-devel] linux 4.19 does not build on armhf Re: [linux-4.19 test] 135420: regressions - FAIL @ 2019-04-30 12:44 ` Ian Jackson 0 siblings, 0 replies; 27+ messages in thread From: Ian Jackson @ 2019-04-30 12:44 UTC (permalink / raw) To: Julien Grall, Stefano Stabellini; +Cc: xen-devel osstest service owner writes ("[linux-4.19 test] 135420: regressions - FAIL"): > flight 135420 linux-4.19 real [real] > http://logs.test-lab.xenproject.org/osstest/logs/135420/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > build-armhf-pvops 6 kernel-build fail REGR. vs. 129313 http://logs.test-lab.xenproject.org/osstest/logs/135420/build-armhf-pvops/6.ts-kernel-build.log drivers/firmware/qcom_scm.c: In function ‘qcom_scm_assign_mem’: drivers/firmware/qcom_scm.c:469:47: error: passing argument 3 of ‘dma_alloc_coherent’ from incompatible pointer type [-Werror=incompatible-pointer-types] ptr = dma_alloc_coherent(__scm->dev, ptr_sz, &ptr_phys, GFP_KERNEL); ^ In file included from drivers/firmware/qcom_scm.c:21:0: ./include/linux/dma-mapping.h:560:21: note: expected ‘dma_addr_t * {aka long long unsigned int *}’ but argument is of type ‘phys_addr_t * {aka unsigned int *}’ static inline void *dma_alloc_coherent(struct device *dev, size_t size, ^~~~~~~~~~~~~~~~~~ cc1: some warnings being treated as errors scripts/Makefile.build:303: recipe for target 'drivers/firmware/qcom_scm.o' failed make[2]: *** [drivers/firmware/qcom_scm.o] Error 1 scripts/Makefile.build:544: recipe for target 'drivers/firmware' failed make[1]: *** [drivers/firmware] Error 2 make[1]: *** Waiting for unfinished jobs.... I think this build failure is probably a regression; rather it is due to the stretch update which brings in a new compiler. However, I would prefer to avoid a force push because this build failure means that the armhf tests didn't run. > test-amd64-amd64-xl-qcow2 17 guest-localmigrate/x10 fail REGR. vs. 129313 This is a known regression with the stretch upgrade and is nothing to do with linux-4.19 (or Xen, I think). > test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 129313 This is another bug, which looks like it is actually a bug in Linux 4.19. I will send another mail about it. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: linux 4.19 does not build on armhf Re: [linux-4.19 test] 135420: regressions - FAIL @ 2019-04-30 14:05 ` Jan Beulich 0 siblings, 0 replies; 27+ messages in thread From: Jan Beulich @ 2019-04-30 14:05 UTC (permalink / raw) To: Ian Jackson; +Cc: xen-devel, Julien Grall, Stefano Stabellini >>> On 30.04.19 at 14:44, <ian.jackson@citrix.com> wrote: > osstest service owner writes ("[linux-4.19 test] 135420: regressions - FAIL"): >> flight 135420 linux-4.19 real [real] >> http://logs.test-lab.xenproject.org/osstest/logs/135420/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, >> including tests which could not be run: >> build-armhf-pvops 6 kernel-build fail REGR. vs. 129313 > > http://logs.test-lab.xenproject.org/osstest/logs/135420/build-armhf-pvops/6.ts-kernel-build.log > > drivers/firmware/qcom_scm.c: In function ‘qcom_scm_assign_mem’: > drivers/firmware/qcom_scm.c:469:47: error: passing argument 3 of > ‘dma_alloc_coherent’ from incompatible pointer type > [-Werror=incompatible-pointer-types] > ptr = dma_alloc_coherent(__scm->dev, ptr_sz, &ptr_phys, GFP_KERNEL); > ^ > In file included from drivers/firmware/qcom_scm.c:21:0: > ./include/linux/dma-mapping.h:560:21: note: expected ‘dma_addr_t * {aka > long long unsigned int *}’ but argument is of type ‘phys_addr_t * {aka > unsigned int *}’ > static inline void *dma_alloc_coherent(struct device *dev, size_t size, > ^~~~~~~~~~~~~~~~~~ > cc1: some warnings being treated as errors The code is still the same in 5.1-rc7, so presumably the problem went unnoticed till now. While it looks like it's straightforward to fix (thanks to the 32-bit variant of __qcom_scm_assign_mem() doing nothing with the passed in values, so it being "fine" for them to get truncated during the call) the aspect that puzzles me is - where does this -Werror=incompatible-pointer-types come from? Was the prior gcc version indeed 4.9.x or older (which seems pretty old to me)? The specific warning control (which Linux converts to an error) was introduced for gcc 5.x. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xen-devel] linux 4.19 does not build on armhf Re: [linux-4.19 test] 135420: regressions - FAIL @ 2019-04-30 14:05 ` Jan Beulich 0 siblings, 0 replies; 27+ messages in thread From: Jan Beulich @ 2019-04-30 14:05 UTC (permalink / raw) To: Ian Jackson; +Cc: xen-devel, Julien Grall, Stefano Stabellini >>> On 30.04.19 at 14:44, <ian.jackson@citrix.com> wrote: > osstest service owner writes ("[linux-4.19 test] 135420: regressions - FAIL"): >> flight 135420 linux-4.19 real [real] >> http://logs.test-lab.xenproject.org/osstest/logs/135420/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, >> including tests which could not be run: >> build-armhf-pvops 6 kernel-build fail REGR. vs. 129313 > > http://logs.test-lab.xenproject.org/osstest/logs/135420/build-armhf-pvops/6.ts-kernel-build.log > > drivers/firmware/qcom_scm.c: In function ‘qcom_scm_assign_mem’: > drivers/firmware/qcom_scm.c:469:47: error: passing argument 3 of > ‘dma_alloc_coherent’ from incompatible pointer type > [-Werror=incompatible-pointer-types] > ptr = dma_alloc_coherent(__scm->dev, ptr_sz, &ptr_phys, GFP_KERNEL); > ^ > In file included from drivers/firmware/qcom_scm.c:21:0: > ./include/linux/dma-mapping.h:560:21: note: expected ‘dma_addr_t * {aka > long long unsigned int *}’ but argument is of type ‘phys_addr_t * {aka > unsigned int *}’ > static inline void *dma_alloc_coherent(struct device *dev, size_t size, > ^~~~~~~~~~~~~~~~~~ > cc1: some warnings being treated as errors The code is still the same in 5.1-rc7, so presumably the problem went unnoticed till now. While it looks like it's straightforward to fix (thanks to the 32-bit variant of __qcom_scm_assign_mem() doing nothing with the passed in values, so it being "fine" for them to get truncated during the call) the aspect that puzzles me is - where does this -Werror=incompatible-pointer-types come from? Was the prior gcc version indeed 4.9.x or older (which seems pretty old to me)? The specific warning control (which Linux converts to an error) was introduced for gcc 5.x. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 27+ messages in thread
* qcom_scm: Incompatible pointer type build failure 2019-04-30 12:44 ` [Xen-devel] " Ian Jackson (?) (?) @ 2019-04-30 14:06 ` Julien Grall -1 siblings, 0 replies; 27+ messages in thread From: Julien Grall @ 2019-04-30 14:06 UTC (permalink / raw) To: Ian Jackson, Stefano Stabellini Cc: andy.gross, xen-devel, linux-arm-msm, linux-kernel, david.brown Hi Ian, Thank you for the report. On 30/04/2019 13:44, Ian Jackson wrote: > osstest service owner writes ("[linux-4.19 test] 135420: regressions - FAIL"): >> flight 135420 linux-4.19 real [real] >> http://logs.test-lab.xenproject.org/osstest/logs/135420/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, >> including tests which could not be run: >> build-armhf-pvops 6 kernel-build fail REGR. vs. 129313 > > http://logs.test-lab.xenproject.org/osstest/logs/135420/build-armhf-pvops/6.ts-kernel-build.log > > drivers/firmware/qcom_scm.c: In function ‘qcom_scm_assign_mem’: > drivers/firmware/qcom_scm.c:469:47: error: passing argument 3 of ‘dma_alloc_coherent’ from incompatible pointer type [-Werror=incompatible-pointer-types] > ptr = dma_alloc_coherent(__scm->dev, ptr_sz, &ptr_phys, GFP_KERNEL); > ^ > In file included from drivers/firmware/qcom_scm.c:21:0: > ./include/linux/dma-mapping.h:560:21: note: expected ‘dma_addr_t * {aka long long unsigned int *}’ but argument is of type ‘phys_addr_t * {aka unsigned int *}’ > static inline void *dma_alloc_coherent(struct device *dev, size_t size, > ^~~~~~~~~~~~~~~~~~ > cc1: some warnings being treated as errors > scripts/Makefile.build:303: recipe for target 'drivers/firmware/qcom_scm.o' failed > make[2]: *** [drivers/firmware/qcom_scm.o] Error 1 > scripts/Makefile.build:544: recipe for target 'drivers/firmware' failed > make[1]: *** [drivers/firmware] Error 2 > make[1]: *** Waiting for unfinished jobs.... > > I think this build failure is probably a regression; rather it is due > to the stretch update which brings in a new compiler. The bug has always been present (and still present in master), it is possible the compiler became smarter with the upgrade to stretch. The problem is similar to [1] and happen when the size of phys_addr_t is different to dma_addr_t. I have CCed the maintainers of this file. Cheers, [1] https://lists.xenproject.org/archives/html/xen-devel/2019-04/msg00940.html -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 27+ messages in thread
* qcom_scm: Incompatible pointer type build failure 2019-04-30 12:44 ` [Xen-devel] " Ian Jackson @ 2019-04-30 14:06 ` Julien Grall -1 siblings, 0 replies; 27+ messages in thread From: Julien Grall @ 2019-04-30 14:06 UTC (permalink / raw) To: Ian Jackson, Stefano Stabellini Cc: xen-devel, andy.gross, david.brown, linux-arm-msm, linux-kernel Hi Ian, Thank you for the report. On 30/04/2019 13:44, Ian Jackson wrote: > osstest service owner writes ("[linux-4.19 test] 135420: regressions - FAIL"): >> flight 135420 linux-4.19 real [real] >> http://logs.test-lab.xenproject.org/osstest/logs/135420/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, >> including tests which could not be run: >> build-armhf-pvops 6 kernel-build fail REGR. vs. 129313 > > http://logs.test-lab.xenproject.org/osstest/logs/135420/build-armhf-pvops/6.ts-kernel-build.log > > drivers/firmware/qcom_scm.c: In function ‘qcom_scm_assign_mem’: > drivers/firmware/qcom_scm.c:469:47: error: passing argument 3 of ‘dma_alloc_coherent’ from incompatible pointer type [-Werror=incompatible-pointer-types] > ptr = dma_alloc_coherent(__scm->dev, ptr_sz, &ptr_phys, GFP_KERNEL); > ^ > In file included from drivers/firmware/qcom_scm.c:21:0: > ./include/linux/dma-mapping.h:560:21: note: expected ‘dma_addr_t * {aka long long unsigned int *}’ but argument is of type ‘phys_addr_t * {aka unsigned int *}’ > static inline void *dma_alloc_coherent(struct device *dev, size_t size, > ^~~~~~~~~~~~~~~~~~ > cc1: some warnings being treated as errors > scripts/Makefile.build:303: recipe for target 'drivers/firmware/qcom_scm.o' failed > make[2]: *** [drivers/firmware/qcom_scm.o] Error 1 > scripts/Makefile.build:544: recipe for target 'drivers/firmware' failed > make[1]: *** [drivers/firmware] Error 2 > make[1]: *** Waiting for unfinished jobs.... > > I think this build failure is probably a regression; rather it is due > to the stretch update which brings in a new compiler. The bug has always been present (and still present in master), it is possible the compiler became smarter with the upgrade to stretch. The problem is similar to [1] and happen when the size of phys_addr_t is different to dma_addr_t. I have CCed the maintainers of this file. Cheers, [1] https://lists.xenproject.org/archives/html/xen-devel/2019-04/msg00940.html -- Julien Grall ^ permalink raw reply [flat|nested] 27+ messages in thread
* [Xen-devel] qcom_scm: Incompatible pointer type build failure @ 2019-04-30 14:06 ` Julien Grall 0 siblings, 0 replies; 27+ messages in thread From: Julien Grall @ 2019-04-30 14:06 UTC (permalink / raw) To: Ian Jackson, Stefano Stabellini Cc: andy.gross, xen-devel, linux-arm-msm, linux-kernel, david.brown Hi Ian, Thank you for the report. On 30/04/2019 13:44, Ian Jackson wrote: > osstest service owner writes ("[linux-4.19 test] 135420: regressions - FAIL"): >> flight 135420 linux-4.19 real [real] >> http://logs.test-lab.xenproject.org/osstest/logs/135420/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, >> including tests which could not be run: >> build-armhf-pvops 6 kernel-build fail REGR. vs. 129313 > > http://logs.test-lab.xenproject.org/osstest/logs/135420/build-armhf-pvops/6.ts-kernel-build.log > > drivers/firmware/qcom_scm.c: In function ‘qcom_scm_assign_mem’: > drivers/firmware/qcom_scm.c:469:47: error: passing argument 3 of ‘dma_alloc_coherent’ from incompatible pointer type [-Werror=incompatible-pointer-types] > ptr = dma_alloc_coherent(__scm->dev, ptr_sz, &ptr_phys, GFP_KERNEL); > ^ > In file included from drivers/firmware/qcom_scm.c:21:0: > ./include/linux/dma-mapping.h:560:21: note: expected ‘dma_addr_t * {aka long long unsigned int *}’ but argument is of type ‘phys_addr_t * {aka unsigned int *}’ > static inline void *dma_alloc_coherent(struct device *dev, size_t size, > ^~~~~~~~~~~~~~~~~~ > cc1: some warnings being treated as errors > scripts/Makefile.build:303: recipe for target 'drivers/firmware/qcom_scm.o' failed > make[2]: *** [drivers/firmware/qcom_scm.o] Error 1 > scripts/Makefile.build:544: recipe for target 'drivers/firmware' failed > make[1]: *** [drivers/firmware] Error 2 > make[1]: *** Waiting for unfinished jobs.... > > I think this build failure is probably a regression; rather it is due > to the stretch update which brings in a new compiler. The bug has always been present (and still present in master), it is possible the compiler became smarter with the upgrade to stretch. The problem is similar to [1] and happen when the size of phys_addr_t is different to dma_addr_t. I have CCed the maintainers of this file. Cheers, [1] https://lists.xenproject.org/archives/html/xen-devel/2019-04/msg00940.html -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: qcom_scm: Incompatible pointer type build failure 2019-04-30 14:06 ` [Xen-devel] " Julien Grall (?) @ 2019-05-17 16:10 ` Ian Jackson -1 siblings, 0 replies; 27+ messages in thread From: Ian Jackson @ 2019-05-17 16:10 UTC (permalink / raw) To: Julien Grall Cc: Stefano Stabellini, xen-devel, andy.gross, david.brown, linux-arm-msm, linux-kernel Julien Grall writes ("qcom_scm: Incompatible pointer type build failure"): > Thank you for the report. ...> > On 30/04/2019 13:44, Ian Jackson wrote: > > osstest service owner writes ("[linux-4.19 test] 135420: regressions - FAIL"): > > drivers/firmware/qcom_scm.c: In function ‘qcom_scm_assign_mem’: > > drivers/firmware/qcom_scm.c:469:47: error: passing argument 3 of ‘dma_alloc_coherent’ from incompatible pointer type [-Werror=incompatible-pointer-types] ... > > I think this build failure is probably a regression; rather it is due > > to the stretch update which brings in a new compiler. > > The bug has always been present (and still present in master), it is possible > the compiler became smarter with the upgrade to stretch. > > The problem is similar to [1] and happen when the size of phys_addr_t is > different to dma_addr_t. > > I have CCed the maintainers of this file. That was several weeks ago and osstest is still blocked on this. Can you please advise what CONFIG_* to disable to work around this ? Ian. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xen-devel] qcom_scm: Incompatible pointer type build failure @ 2019-05-17 16:10 ` Ian Jackson 0 siblings, 0 replies; 27+ messages in thread From: Ian Jackson @ 2019-05-17 16:10 UTC (permalink / raw) To: Julien Grall Cc: Stefano Stabellini, linux-arm-msm, linux-kernel, david.brown, andy.gross, xen-devel Julien Grall writes ("qcom_scm: Incompatible pointer type build failure"): > Thank you for the report. ...> > On 30/04/2019 13:44, Ian Jackson wrote: > > osstest service owner writes ("[linux-4.19 test] 135420: regressions - FAIL"): > > drivers/firmware/qcom_scm.c: In function ‘qcom_scm_assign_mem’: > > drivers/firmware/qcom_scm.c:469:47: error: passing argument 3 of ‘dma_alloc_coherent’ from incompatible pointer type [-Werror=incompatible-pointer-types] ... > > I think this build failure is probably a regression; rather it is due > > to the stretch update which brings in a new compiler. > > The bug has always been present (and still present in master), it is possible > the compiler became smarter with the upgrade to stretch. > > The problem is similar to [1] and happen when the size of phys_addr_t is > different to dma_addr_t. > > I have CCed the maintainers of this file. That was several weeks ago and osstest is still blocked on this. Can you please advise what CONFIG_* to disable to work around this ? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: qcom_scm: Incompatible pointer type build failure @ 2019-05-17 16:10 ` Ian Jackson 0 siblings, 0 replies; 27+ messages in thread From: Ian Jackson @ 2019-05-17 16:10 UTC (permalink / raw) To: Julien Grall Cc: Stefano Stabellini, linux-arm-msm, linux-kernel, david.brown, andy.gross, xen-devel Julien Grall writes ("qcom_scm: Incompatible pointer type build failure"): > Thank you for the report. ...> > On 30/04/2019 13:44, Ian Jackson wrote: > > osstest service owner writes ("[linux-4.19 test] 135420: regressions - FAIL"): > > drivers/firmware/qcom_scm.c: In function ‘qcom_scm_assign_mem’: > > drivers/firmware/qcom_scm.c:469:47: error: passing argument 3 of ‘dma_alloc_coherent’ from incompatible pointer type [-Werror=incompatible-pointer-types] ... > > I think this build failure is probably a regression; rather it is due > > to the stretch update which brings in a new compiler. > > The bug has always been present (and still present in master), it is possible > the compiler became smarter with the upgrade to stretch. > > The problem is similar to [1] and happen when the size of phys_addr_t is > different to dma_addr_t. > > I have CCed the maintainers of this file. That was several weeks ago and osstest is still blocked on this. Can you please advise what CONFIG_* to disable to work around this ? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 0/3] qcom_scm: Fix some dma mapping things 2019-05-17 16:10 ` Ian Jackson (?) (?) @ 2019-05-17 21:09 ` Stephen Boyd -1 siblings, 0 replies; 27+ messages in thread From: Stephen Boyd @ 2019-05-17 21:09 UTC (permalink / raw) To: Andy Gross; +Cc: linux-kernel, linux-arm-msm This patch series fixes some DMA mapping problems reported in the qcom SCM driver. I haven't tested these patches at all so it could be totally broken. If someone can test them for me I'd appreciate it. Otherwise, I'll spend some time dusting off modem loading code to see if it works. Stephen Boyd (3): firmware: qcom_scm: Use proper types for dma mappings firmware: qcom_scm: Cleanup code in qcom_scm_assign_mem() firmware: qcom_scm: Fix some typos in docs and printks drivers/firmware/qcom_scm.c | 47 +++++++++++++++++++------------------ include/linux/qcom_scm.h | 9 +++---- 2 files changed, 29 insertions(+), 27 deletions(-) base-commit: e93c9c99a629c61837d5a7fc2120cd2b6c70dbdd -- Sent by a computer through tubes ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 1/3] firmware: qcom_scm: Use proper types for dma mappings 2019-05-17 16:10 ` Ian Jackson ` (2 preceding siblings ...) (?) @ 2019-05-17 21:09 ` Stephen Boyd 2019-05-20 9:41 ` Ian Jackson -1 siblings, 1 reply; 27+ messages in thread From: Stephen Boyd @ 2019-05-17 21:09 UTC (permalink / raw) To: Andy Gross Cc: linux-kernel, linux-arm-msm, Ian Jackson, Julien Grall, Bjorn Andersson, Avaneesh Kumar Dwivedi We need to use the proper types and convert between physical addresses and dma addresses here to avoid mismatch warnings. This is especially important on systems with a different size for dma addresses and physical addresses. Otherwise, we get the following warning: drivers/firmware/qcom_scm.c: In function "qcom_scm_assign_mem": drivers/firmware/qcom_scm.c:469:47: error: passing argument 3 of "dma_alloc_coherent" from incompatible pointer type [-Werror=incompatible-pointer-types] We also fix the size argument to dma_free_coherent() because that size doesn't need to be aligned after it's already aligned on the allocation size. In fact, dma debugging expects the same arguments to be passed to both the allocation and freeing sides of the functions so changing the size is incorrect regardless. Reported-by: Ian Jackson <ian.jackson@citrix.com> Cc: Ian Jackson <ian.jackson@citrix.com> Cc: Julien Grall <julien.grall@arm.com> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Avaneesh Kumar Dwivedi <akdwived@codeaurora.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> --- drivers/firmware/qcom_scm.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c index af4eee86919d..0c63495cf269 100644 --- a/drivers/firmware/qcom_scm.c +++ b/drivers/firmware/qcom_scm.c @@ -18,6 +18,7 @@ #include <linux/init.h> #include <linux/cpumask.h> #include <linux/export.h> +#include <linux/dma-direct.h> #include <linux/dma-mapping.h> #include <linux/module.h> #include <linux/types.h> @@ -449,6 +450,7 @@ int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, phys_addr_t mem_to_map_phys; phys_addr_t dest_phys; phys_addr_t ptr_phys; + dma_addr_t ptr_dma; size_t mem_to_map_sz; size_t dest_sz; size_t src_sz; @@ -466,9 +468,10 @@ int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, ptr_sz = ALIGN(src_sz, SZ_64) + ALIGN(mem_to_map_sz, SZ_64) + ALIGN(dest_sz, SZ_64); - ptr = dma_alloc_coherent(__scm->dev, ptr_sz, &ptr_phys, GFP_KERNEL); + ptr = dma_alloc_coherent(__scm->dev, ptr_sz, &ptr_dma, GFP_KERNEL); if (!ptr) return -ENOMEM; + ptr_phys = dma_to_phys(__scm->dev, ptr_dma); /* Fill source vmid detail */ src = ptr; @@ -498,7 +501,7 @@ int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, ret = __qcom_scm_assign_mem(__scm->dev, mem_to_map_phys, mem_to_map_sz, ptr_phys, src_sz, dest_phys, dest_sz); - dma_free_coherent(__scm->dev, ALIGN(ptr_sz, SZ_64), ptr, ptr_phys); + dma_free_coherent(__scm->dev, ptr_sz, ptr, ptr_dma); if (ret) { dev_err(__scm->dev, "Assign memory protection call failed %d.\n", ret); -- Sent by a computer through tubes ^ permalink raw reply related [flat|nested] 27+ messages in thread
* [PATCH 1/3] firmware: qcom_scm: Use proper types for dma mappings 2019-05-17 21:09 ` [PATCH 1/3] firmware: qcom_scm: Use proper types for dma mappings Stephen Boyd @ 2019-05-20 9:41 ` Ian Jackson 2019-05-20 13:20 ` Julien Grall 0 siblings, 1 reply; 27+ messages in thread From: Ian Jackson @ 2019-05-20 9:41 UTC (permalink / raw) To: Stephen Boyd Cc: Andy Gross, linux-kernel, linux-arm-msm, Julien Grall, Bjorn Andersson, Avaneesh Kumar Dwivedi Stephen Boyd writes ("[PATCH 1/3] firmware: qcom_scm: Use proper types for dma mappings"): > We need to use the proper types and convert between physical addresses > and dma addresses here to avoid mismatch warnings. This is especially > important on systems with a different size for dma addresses and > physical addresses. Otherwise, we get the following warning: Thanks. Do you expect this to be a backport candidate and if so how far back do you think it will go ? To be honest, I am not really convinced that backporting this would be a service to users. The situation I have, where I changed the compiler but kept the old kernel code and old configuration, is going to be fairly rare. I think I should probably therefore disable this driver in the config on stable branches of Linux, at least. Thanks, Ian. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 1/3] firmware: qcom_scm: Use proper types for dma mappings 2019-05-20 9:41 ` Ian Jackson @ 2019-05-20 13:20 ` Julien Grall 2019-05-30 16:51 ` Ian Jackson 0 siblings, 1 reply; 27+ messages in thread From: Julien Grall @ 2019-05-20 13:20 UTC (permalink / raw) To: Ian Jackson, Stephen Boyd Cc: Andy Gross, linux-kernel, linux-arm-msm, Bjorn Andersson, Avaneesh Kumar Dwivedi Hi Ian, On 20/05/2019 10:41, Ian Jackson wrote: > Stephen Boyd writes ("[PATCH 1/3] firmware: qcom_scm: Use proper types for dma mappings"): >> We need to use the proper types and convert between physical addresses >> and dma addresses here to avoid mismatch warnings. This is especially >> important on systems with a different size for dma addresses and >> physical addresses. Otherwise, we get the following warning: > > Thanks. Do you expect this to be a backport candidate and if so how > far back do you think it will go ? To be honest, I am not really > convinced that backporting this would be a service to users. The > situation I have, where I changed the compiler but kept the old kernel > code and old configuration, is going to be fairly rare. I will leave the maintainers answering to that. > > I think I should probably therefore disable this driver in the config > on stable branches of Linux, at least. If we decide to disable the driver, then we would need to add in our .config, then we would need to disable completely the support for Qualcomm (i.e CONFIG_ARCH_QCOM=n) on Arm32. This should not be an issue in osstest as we don't test any qualcomm board so far. Cheers, -- Julien Grall ^ permalink raw reply [flat|nested] 27+ messages in thread
* [OSSTEST PATCH] ts-kernel-build: Disable CONFIG_ARCH_QCOM in Xen Project CI 2019-05-20 13:20 ` Julien Grall 2019-05-30 16:51 ` Ian Jackson @ 2019-05-30 16:51 ` Ian Jackson 0 siblings, 0 replies; 27+ messages in thread From: Ian Jackson @ 2019-05-30 16:51 UTC (permalink / raw) To: xen-devel Cc: Ian Jackson, Julien Grall, Stefano Stabellini, linux-arm-msm, linux-kernel, Stephen Boyd, Andy Gross, Bjorn Andersson, Avaneesh Kumar Dwivedi drivers/firmware/qcom_scm.c:469:47: error: passing argument 3 of `dma_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types] This is fixed by firmware: qcom_scm: Use proper types for dma mappings but this is not present in all relevant stable branches. We currently have no Qualcomm hardware in the Xen Project test lab so we do not need this enabled. CC: Julien Grall <julien.grall@arm.com CC: Stefano Stabellini <sstabellini@kernel.org> CC: linux-arm-msm@vger.kernel.org CC: linux-kernel@vger.kernel.org CC: Stephen Boyd <swboyd@chromium.org> CC: Andy Gross <agross@kernel.org> CC: Bjorn Andersson <bjorn.andersson@linaro.org> CC: Avaneesh Kumar Dwivedi <akdwived@codeaurora.org> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> --- ts-kernel-build | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/ts-kernel-build b/ts-kernel-build index f7d059b0..5536586f 100755 --- a/ts-kernel-build +++ b/ts-kernel-build @@ -274,6 +274,10 @@ setopt CONFIG_MDIO_THUNDER=m setopt CONFIG_I2C_THUNDERX=m setopt CONFIG_SPI_THUNDERX=m +# Some Linux branches we care about, including 4.19, still lack +# firmware: qcom_scm: Use proper types for dma mappings +CONFIG_ARCH_QCOM=n + #### END -- 2.11.0 ^ permalink raw reply related [flat|nested] 27+ messages in thread
* [Xen-devel] [OSSTEST PATCH] ts-kernel-build: Disable CONFIG_ARCH_QCOM in Xen Project CI @ 2019-05-30 16:51 ` Ian Jackson 0 siblings, 0 replies; 27+ messages in thread From: Ian Jackson @ 2019-05-30 16:51 UTC (permalink / raw) To: xen-devel Cc: Stefano Stabellini, linux-arm-msm, Ian Jackson, linux-kernel, Stephen Boyd, Julien Grall, Andy Gross, Bjorn Andersson, Avaneesh Kumar Dwivedi drivers/firmware/qcom_scm.c:469:47: error: passing argument 3 of `dma_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types] This is fixed by firmware: qcom_scm: Use proper types for dma mappings but this is not present in all relevant stable branches. We currently have no Qualcomm hardware in the Xen Project test lab so we do not need this enabled. CC: Julien Grall <julien.grall@arm.com CC: Stefano Stabellini <sstabellini@kernel.org> CC: linux-arm-msm@vger.kernel.org CC: linux-kernel@vger.kernel.org CC: Stephen Boyd <swboyd@chromium.org> CC: Andy Gross <agross@kernel.org> CC: Bjorn Andersson <bjorn.andersson@linaro.org> CC: Avaneesh Kumar Dwivedi <akdwived@codeaurora.org> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> --- ts-kernel-build | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/ts-kernel-build b/ts-kernel-build index f7d059b0..5536586f 100755 --- a/ts-kernel-build +++ b/ts-kernel-build @@ -274,6 +274,10 @@ setopt CONFIG_MDIO_THUNDER=m setopt CONFIG_I2C_THUNDERX=m setopt CONFIG_SPI_THUNDERX=m +# Some Linux branches we care about, including 4.19, still lack +# firmware: qcom_scm: Use proper types for dma mappings +CONFIG_ARCH_QCOM=n + #### END -- 2.11.0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply related [flat|nested] 27+ messages in thread
* [OSSTEST PATCH] ts-kernel-build: Disable CONFIG_ARCH_QCOM in Xen Project CI @ 2019-05-30 16:51 ` Ian Jackson 0 siblings, 0 replies; 27+ messages in thread From: Ian Jackson @ 2019-05-30 16:51 UTC (permalink / raw) To: xen-devel Cc: Stefano Stabellini, linux-arm-msm, Ian Jackson, linux-kernel, Stephen Boyd, Julien Grall, Andy Gross, Bjorn Andersson, Avaneesh Kumar Dwivedi drivers/firmware/qcom_scm.c:469:47: error: passing argument 3 of `dma_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types] This is fixed by firmware: qcom_scm: Use proper types for dma mappings but this is not present in all relevant stable branches. We currently have no Qualcomm hardware in the Xen Project test lab so we do not need this enabled. CC: Julien Grall <julien.grall@arm.com CC: Stefano Stabellini <sstabellini@kernel.org> CC: linux-arm-msm@vger.kernel.org CC: linux-kernel@vger.kernel.org CC: Stephen Boyd <swboyd@chromium.org> CC: Andy Gross <agross@kernel.org> CC: Bjorn Andersson <bjorn.andersson@linaro.org> CC: Avaneesh Kumar Dwivedi <akdwived@codeaurora.org> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> --- ts-kernel-build | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/ts-kernel-build b/ts-kernel-build index f7d059b0..5536586f 100755 --- a/ts-kernel-build +++ b/ts-kernel-build @@ -274,6 +274,10 @@ setopt CONFIG_MDIO_THUNDER=m setopt CONFIG_I2C_THUNDERX=m setopt CONFIG_SPI_THUNDERX=m +# Some Linux branches we care about, including 4.19, still lack +# firmware: qcom_scm: Use proper types for dma mappings +CONFIG_ARCH_QCOM=n + #### END -- 2.11.0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [OSSTEST PATCH] ts-kernel-build: Disable CONFIG_ARCH_QCOM in Xen Project CI 2019-05-30 16:51 ` Ian Jackson (?) (?) @ 2019-05-31 15:52 ` Julien Grall -1 siblings, 0 replies; 27+ messages in thread From: Julien Grall @ 2019-05-31 15:52 UTC (permalink / raw) To: Ian Jackson, xen-devel Cc: Stefano Stabellini, linux-arm-msm, linux-kernel, Bjorn Andersson, Andy Gross, Stephen Boyd, Avaneesh Kumar Dwivedi Hi Ian, On 30/05/2019 17:51, Ian Jackson wrote: > drivers/firmware/qcom_scm.c:469:47: error: passing argument 3 of `dma_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types] > > This is fixed by > > firmware: qcom_scm: Use proper types for dma mappings > > but this is not present in all relevant stable branches. > > We currently have no Qualcomm hardware in the Xen Project test lab so > we do not need this enabled. > > CC: Julien Grall <julien.grall@arm.com > CC: Stefano Stabellini <sstabellini@kernel.org> > CC: linux-arm-msm@vger.kernel.org > CC: linux-kernel@vger.kernel.org > CC: Stephen Boyd <swboyd@chromium.org> > CC: Andy Gross <agross@kernel.org> > CC: Bjorn Andersson <bjorn.andersson@linaro.org> > CC: Avaneesh Kumar Dwivedi <akdwived@codeaurora.org> > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> FWIW: Acked-by: Julien Grall <julien.grall@arm.com> > --- > ts-kernel-build | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/ts-kernel-build b/ts-kernel-build > index f7d059b0..5536586f 100755 > --- a/ts-kernel-build > +++ b/ts-kernel-build > @@ -274,6 +274,10 @@ setopt CONFIG_MDIO_THUNDER=m > setopt CONFIG_I2C_THUNDERX=m > setopt CONFIG_SPI_THUNDERX=m > > +# Some Linux branches we care about, including 4.19, still lack > +# firmware: qcom_scm: Use proper types for dma mappings > +CONFIG_ARCH_QCOM=n > + > #### > > END > -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [OSSTEST PATCH] ts-kernel-build: Disable CONFIG_ARCH_QCOM in Xen Project CI 2019-05-30 16:51 ` Ian Jackson @ 2019-05-31 15:52 ` Julien Grall -1 siblings, 0 replies; 27+ messages in thread From: Julien Grall @ 2019-05-31 15:52 UTC (permalink / raw) To: Ian Jackson, xen-devel Cc: Stefano Stabellini, linux-arm-msm, linux-kernel, Stephen Boyd, Andy Gross, Bjorn Andersson, Avaneesh Kumar Dwivedi Hi Ian, On 30/05/2019 17:51, Ian Jackson wrote: > drivers/firmware/qcom_scm.c:469:47: error: passing argument 3 of `dma_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types] > > This is fixed by > > firmware: qcom_scm: Use proper types for dma mappings > > but this is not present in all relevant stable branches. > > We currently have no Qualcomm hardware in the Xen Project test lab so > we do not need this enabled. > > CC: Julien Grall <julien.grall@arm.com > CC: Stefano Stabellini <sstabellini@kernel.org> > CC: linux-arm-msm@vger.kernel.org > CC: linux-kernel@vger.kernel.org > CC: Stephen Boyd <swboyd@chromium.org> > CC: Andy Gross <agross@kernel.org> > CC: Bjorn Andersson <bjorn.andersson@linaro.org> > CC: Avaneesh Kumar Dwivedi <akdwived@codeaurora.org> > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> FWIW: Acked-by: Julien Grall <julien.grall@arm.com> > --- > ts-kernel-build | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/ts-kernel-build b/ts-kernel-build > index f7d059b0..5536586f 100755 > --- a/ts-kernel-build > +++ b/ts-kernel-build > @@ -274,6 +274,10 @@ setopt CONFIG_MDIO_THUNDER=m > setopt CONFIG_I2C_THUNDERX=m > setopt CONFIG_SPI_THUNDERX=m > > +# Some Linux branches we care about, including 4.19, still lack > +# firmware: qcom_scm: Use proper types for dma mappings > +CONFIG_ARCH_QCOM=n > + > #### > > END > -- Julien Grall ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [Xen-devel] [OSSTEST PATCH] ts-kernel-build: Disable CONFIG_ARCH_QCOM in Xen Project CI @ 2019-05-31 15:52 ` Julien Grall 0 siblings, 0 replies; 27+ messages in thread From: Julien Grall @ 2019-05-31 15:52 UTC (permalink / raw) To: Ian Jackson, xen-devel Cc: Stefano Stabellini, linux-arm-msm, linux-kernel, Bjorn Andersson, Andy Gross, Stephen Boyd, Avaneesh Kumar Dwivedi Hi Ian, On 30/05/2019 17:51, Ian Jackson wrote: > drivers/firmware/qcom_scm.c:469:47: error: passing argument 3 of `dma_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types] > > This is fixed by > > firmware: qcom_scm: Use proper types for dma mappings > > but this is not present in all relevant stable branches. > > We currently have no Qualcomm hardware in the Xen Project test lab so > we do not need this enabled. > > CC: Julien Grall <julien.grall@arm.com > CC: Stefano Stabellini <sstabellini@kernel.org> > CC: linux-arm-msm@vger.kernel.org > CC: linux-kernel@vger.kernel.org > CC: Stephen Boyd <swboyd@chromium.org> > CC: Andy Gross <agross@kernel.org> > CC: Bjorn Andersson <bjorn.andersson@linaro.org> > CC: Avaneesh Kumar Dwivedi <akdwived@codeaurora.org> > Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> FWIW: Acked-by: Julien Grall <julien.grall@arm.com> > --- > ts-kernel-build | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/ts-kernel-build b/ts-kernel-build > index f7d059b0..5536586f 100755 > --- a/ts-kernel-build > +++ b/ts-kernel-build > @@ -274,6 +274,10 @@ setopt CONFIG_MDIO_THUNDER=m > setopt CONFIG_I2C_THUNDERX=m > setopt CONFIG_SPI_THUNDERX=m > > +# Some Linux branches we care about, including 4.19, still lack > +# firmware: qcom_scm: Use proper types for dma mappings > +CONFIG_ARCH_QCOM=n > + > #### > > END > -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 2/3] firmware: qcom_scm: Cleanup code in qcom_scm_assign_mem() 2019-05-17 16:10 ` Ian Jackson ` (3 preceding siblings ...) (?) @ 2019-05-17 21:09 ` Stephen Boyd 2019-07-22 23:27 ` Bjorn Andersson -1 siblings, 1 reply; 27+ messages in thread From: Stephen Boyd @ 2019-05-17 21:09 UTC (permalink / raw) To: Andy Gross Cc: linux-kernel, linux-arm-msm, Ian Jackson, Julien Grall, Bjorn Andersson, Avaneesh Kumar Dwivedi There are some questionable coding styles in this function. It looks quite odd to deref a pointer with array indexing that only uses the first element. Also, destroying an input/output variable halfway through the function and then overwriting it on success is not clear. It's better to use a local variable and the kernel macros to step through each bit set in a bitmask and clearly show where outputs are set. Cc: Ian Jackson <ian.jackson@citrix.com> Cc: Julien Grall <julien.grall@arm.com> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Avaneesh Kumar Dwivedi <akdwived@codeaurora.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> --- drivers/firmware/qcom_scm.c | 34 ++++++++++++++++------------------ include/linux/qcom_scm.h | 9 +++++---- 2 files changed, 21 insertions(+), 22 deletions(-) diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c index 0c63495cf269..153f13f72bac 100644 --- a/drivers/firmware/qcom_scm.c +++ b/drivers/firmware/qcom_scm.c @@ -443,7 +443,8 @@ EXPORT_SYMBOL(qcom_scm_set_remote_state); */ int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, unsigned int *srcvm, - struct qcom_scm_vmperm *newvm, int dest_cnt) + const struct qcom_scm_vmperm *newvm, + unsigned int dest_cnt) { struct qcom_scm_current_perm_info *destvm; struct qcom_scm_mem_map_info *mem_to_map; @@ -458,11 +459,10 @@ int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, int next_vm; __le32 *src; void *ptr; - int ret; - int len; - int i; + int ret, i, b; + unsigned long srcvm_bits = *srcvm; - src_sz = hweight_long(*srcvm) * sizeof(*src); + src_sz = hweight_long(srcvm_bits) * sizeof(*src); mem_to_map_sz = sizeof(*mem_to_map); dest_sz = dest_cnt * sizeof(*destvm); ptr_sz = ALIGN(src_sz, SZ_64) + ALIGN(mem_to_map_sz, SZ_64) + @@ -475,28 +475,26 @@ int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, /* Fill source vmid detail */ src = ptr; - len = hweight_long(*srcvm); - for (i = 0; i < len; i++) { - src[i] = cpu_to_le32(ffs(*srcvm) - 1); - *srcvm ^= 1 << (ffs(*srcvm) - 1); - } + i = 0; + for_each_set_bit(b, &srcvm_bits, sizeof(srcvm_bits)) + src[i++] = cpu_to_le32(b); /* Fill details of mem buff to map */ mem_to_map = ptr + ALIGN(src_sz, SZ_64); mem_to_map_phys = ptr_phys + ALIGN(src_sz, SZ_64); - mem_to_map[0].mem_addr = cpu_to_le64(mem_addr); - mem_to_map[0].mem_size = cpu_to_le64(mem_sz); + mem_to_map->mem_addr = cpu_to_le64(mem_addr); + mem_to_map->mem_size = cpu_to_le64(mem_sz); next_vm = 0; /* Fill details of next vmid detail */ destvm = ptr + ALIGN(mem_to_map_sz, SZ_64) + ALIGN(src_sz, SZ_64); dest_phys = ptr_phys + ALIGN(mem_to_map_sz, SZ_64) + ALIGN(src_sz, SZ_64); - for (i = 0; i < dest_cnt; i++) { - destvm[i].vmid = cpu_to_le32(newvm[i].vmid); - destvm[i].perm = cpu_to_le32(newvm[i].perm); - destvm[i].ctx = 0; - destvm[i].ctx_size = 0; - next_vm |= BIT(newvm[i].vmid); + for (i = 0; i < dest_cnt; i++, destvm++, newvm++) { + destvm->vmid = cpu_to_le32(newvm->vmid); + destvm->perm = cpu_to_le32(newvm->perm); + destvm->ctx = 0; + destvm->ctx_size = 0; + next_vm |= BIT(newvm->vmid); } ret = __qcom_scm_assign_mem(__scm->dev, mem_to_map_phys, mem_to_map_sz, diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h index d0aecc04c54b..1d406403c843 100644 --- a/include/linux/qcom_scm.h +++ b/include/linux/qcom_scm.h @@ -57,8 +57,9 @@ extern int qcom_scm_pas_mem_setup(u32 peripheral, phys_addr_t addr, extern int qcom_scm_pas_auth_and_reset(u32 peripheral); extern int qcom_scm_pas_shutdown(u32 peripheral); extern int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, - unsigned int *src, struct qcom_scm_vmperm *newvm, - int dest_cnt); + unsigned int *src, + const struct qcom_scm_vmperm *newvm, + unsigned int dest_cnt); extern void qcom_scm_cpu_power_down(u32 flags); extern u32 qcom_scm_get_version(void); extern int qcom_scm_set_remote_state(u32 state, u32 id); @@ -95,8 +96,8 @@ qcom_scm_pas_auth_and_reset(u32 peripheral) { return -ENODEV; } static inline int qcom_scm_pas_shutdown(u32 peripheral) { return -ENODEV; } static inline int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, unsigned int *src, - struct qcom_scm_vmperm *newvm, - int dest_cnt) { return -ENODEV; } + const struct qcom_scm_vmperm *newvm, + unsigned int dest_cnt) { return -ENODEV; } static inline void qcom_scm_cpu_power_down(u32 flags) {} static inline u32 qcom_scm_get_version(void) { return 0; } static inline u32 -- Sent by a computer through tubes ^ permalink raw reply related [flat|nested] 27+ messages in thread
* Re: [PATCH 2/3] firmware: qcom_scm: Cleanup code in qcom_scm_assign_mem() 2019-05-17 21:09 ` [PATCH 2/3] firmware: qcom_scm: Cleanup code in qcom_scm_assign_mem() Stephen Boyd @ 2019-07-22 23:27 ` Bjorn Andersson 2019-07-23 0:04 ` Stephen Boyd 0 siblings, 1 reply; 27+ messages in thread From: Bjorn Andersson @ 2019-07-22 23:27 UTC (permalink / raw) To: Stephen Boyd Cc: Andy Gross, linux-kernel, linux-arm-msm, Ian Jackson, Julien Grall, Avaneesh Kumar Dwivedi On Fri 17 May 14:09 PDT 2019, Stephen Boyd wrote: > There are some questionable coding styles in this function. It looks > quite odd to deref a pointer with array indexing that only uses the > first element. Also, destroying an input/output variable halfway through > the function and then overwriting it on success is not clear. It's > better to use a local variable and the kernel macros to step through > each bit set in a bitmask and clearly show where outputs are set. > > Cc: Ian Jackson <ian.jackson@citrix.com> > Cc: Julien Grall <julien.grall@arm.com> > Cc: Bjorn Andersson <bjorn.andersson@linaro.org> > Cc: Avaneesh Kumar Dwivedi <akdwived@codeaurora.org> > Signed-off-by: Stephen Boyd <swboyd@chromium.org> > --- > drivers/firmware/qcom_scm.c | 34 ++++++++++++++++------------------ > include/linux/qcom_scm.h | 9 +++++---- > 2 files changed, 21 insertions(+), 22 deletions(-) > > diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c > index 0c63495cf269..153f13f72bac 100644 > --- a/drivers/firmware/qcom_scm.c > +++ b/drivers/firmware/qcom_scm.c > @@ -443,7 +443,8 @@ EXPORT_SYMBOL(qcom_scm_set_remote_state); > */ > int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, > unsigned int *srcvm, > - struct qcom_scm_vmperm *newvm, int dest_cnt) > + const struct qcom_scm_vmperm *newvm, > + unsigned int dest_cnt) > { > struct qcom_scm_current_perm_info *destvm; > struct qcom_scm_mem_map_info *mem_to_map; > @@ -458,11 +459,10 @@ int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, > int next_vm; > __le32 *src; > void *ptr; > - int ret; > - int len; > - int i; > + int ret, i, b; > + unsigned long srcvm_bits = *srcvm; > > - src_sz = hweight_long(*srcvm) * sizeof(*src); > + src_sz = hweight_long(srcvm_bits) * sizeof(*src); > mem_to_map_sz = sizeof(*mem_to_map); > dest_sz = dest_cnt * sizeof(*destvm); > ptr_sz = ALIGN(src_sz, SZ_64) + ALIGN(mem_to_map_sz, SZ_64) + > @@ -475,28 +475,26 @@ int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, > > /* Fill source vmid detail */ > src = ptr; > - len = hweight_long(*srcvm); > - for (i = 0; i < len; i++) { > - src[i] = cpu_to_le32(ffs(*srcvm) - 1); > - *srcvm ^= 1 << (ffs(*srcvm) - 1); > - } > + i = 0; > + for_each_set_bit(b, &srcvm_bits, sizeof(srcvm_bits)) The modem is sad that you only pass 8 here. Changed it to BITS_PER_LONG to include the modem's permission bit and applied all three patches. Thanks, Bjorn > + src[i++] = cpu_to_le32(b); > > /* Fill details of mem buff to map */ > mem_to_map = ptr + ALIGN(src_sz, SZ_64); > mem_to_map_phys = ptr_phys + ALIGN(src_sz, SZ_64); > - mem_to_map[0].mem_addr = cpu_to_le64(mem_addr); > - mem_to_map[0].mem_size = cpu_to_le64(mem_sz); > + mem_to_map->mem_addr = cpu_to_le64(mem_addr); > + mem_to_map->mem_size = cpu_to_le64(mem_sz); > > next_vm = 0; > /* Fill details of next vmid detail */ > destvm = ptr + ALIGN(mem_to_map_sz, SZ_64) + ALIGN(src_sz, SZ_64); > dest_phys = ptr_phys + ALIGN(mem_to_map_sz, SZ_64) + ALIGN(src_sz, SZ_64); > - for (i = 0; i < dest_cnt; i++) { > - destvm[i].vmid = cpu_to_le32(newvm[i].vmid); > - destvm[i].perm = cpu_to_le32(newvm[i].perm); > - destvm[i].ctx = 0; > - destvm[i].ctx_size = 0; > - next_vm |= BIT(newvm[i].vmid); > + for (i = 0; i < dest_cnt; i++, destvm++, newvm++) { > + destvm->vmid = cpu_to_le32(newvm->vmid); > + destvm->perm = cpu_to_le32(newvm->perm); > + destvm->ctx = 0; > + destvm->ctx_size = 0; > + next_vm |= BIT(newvm->vmid); > } > > ret = __qcom_scm_assign_mem(__scm->dev, mem_to_map_phys, mem_to_map_sz, > diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h > index d0aecc04c54b..1d406403c843 100644 > --- a/include/linux/qcom_scm.h > +++ b/include/linux/qcom_scm.h > @@ -57,8 +57,9 @@ extern int qcom_scm_pas_mem_setup(u32 peripheral, phys_addr_t addr, > extern int qcom_scm_pas_auth_and_reset(u32 peripheral); > extern int qcom_scm_pas_shutdown(u32 peripheral); > extern int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, > - unsigned int *src, struct qcom_scm_vmperm *newvm, > - int dest_cnt); > + unsigned int *src, > + const struct qcom_scm_vmperm *newvm, > + unsigned int dest_cnt); > extern void qcom_scm_cpu_power_down(u32 flags); > extern u32 qcom_scm_get_version(void); > extern int qcom_scm_set_remote_state(u32 state, u32 id); > @@ -95,8 +96,8 @@ qcom_scm_pas_auth_and_reset(u32 peripheral) { return -ENODEV; } > static inline int qcom_scm_pas_shutdown(u32 peripheral) { return -ENODEV; } > static inline int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, > unsigned int *src, > - struct qcom_scm_vmperm *newvm, > - int dest_cnt) { return -ENODEV; } > + const struct qcom_scm_vmperm *newvm, > + unsigned int dest_cnt) { return -ENODEV; } > static inline void qcom_scm_cpu_power_down(u32 flags) {} > static inline u32 qcom_scm_get_version(void) { return 0; } > static inline u32 > -- > Sent by a computer through tubes > ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/3] firmware: qcom_scm: Cleanup code in qcom_scm_assign_mem() 2019-07-22 23:27 ` Bjorn Andersson @ 2019-07-23 0:04 ` Stephen Boyd 2019-07-23 0:21 ` Bjorn Andersson 0 siblings, 1 reply; 27+ messages in thread From: Stephen Boyd @ 2019-07-23 0:04 UTC (permalink / raw) To: Bjorn Andersson Cc: Andy Gross, linux-kernel, linux-arm-msm, Ian Jackson, Julien Grall, Avaneesh Kumar Dwivedi Quoting Bjorn Andersson (2019-07-22 16:27:19) > On Fri 17 May 14:09 PDT 2019, Stephen Boyd wrote: > > > There are some questionable coding styles in this function. It looks > > quite odd to deref a pointer with array indexing that only uses the > > first element. Also, destroying an input/output variable halfway through > > the function and then overwriting it on success is not clear. It's > > better to use a local variable and the kernel macros to step through > > each bit set in a bitmask and clearly show where outputs are set. > > > > Cc: Ian Jackson <ian.jackson@citrix.com> > > Cc: Julien Grall <julien.grall@arm.com> > > Cc: Bjorn Andersson <bjorn.andersson@linaro.org> > > Cc: Avaneesh Kumar Dwivedi <akdwived@codeaurora.org> > > Signed-off-by: Stephen Boyd <swboyd@chromium.org> > > --- > > drivers/firmware/qcom_scm.c | 34 ++++++++++++++++------------------ > > include/linux/qcom_scm.h | 9 +++++---- > > 2 files changed, 21 insertions(+), 22 deletions(-) > > > > diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c > > index 0c63495cf269..153f13f72bac 100644 > > --- a/drivers/firmware/qcom_scm.c > > +++ b/drivers/firmware/qcom_scm.c > > @@ -443,7 +443,8 @@ EXPORT_SYMBOL(qcom_scm_set_remote_state); > > */ > > int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, > > unsigned int *srcvm, > > - struct qcom_scm_vmperm *newvm, int dest_cnt) > > + const struct qcom_scm_vmperm *newvm, > > + unsigned int dest_cnt) > > { > > struct qcom_scm_current_perm_info *destvm; > > struct qcom_scm_mem_map_info *mem_to_map; > > @@ -458,11 +459,10 @@ int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, > > int next_vm; > > __le32 *src; > > void *ptr; > > - int ret; > > - int len; > > - int i; > > + int ret, i, b; > > + unsigned long srcvm_bits = *srcvm; > > > > - src_sz = hweight_long(*srcvm) * sizeof(*src); > > + src_sz = hweight_long(srcvm_bits) * sizeof(*src); > > mem_to_map_sz = sizeof(*mem_to_map); > > dest_sz = dest_cnt * sizeof(*destvm); > > ptr_sz = ALIGN(src_sz, SZ_64) + ALIGN(mem_to_map_sz, SZ_64) + > > @@ -475,28 +475,26 @@ int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, > > > > /* Fill source vmid detail */ > > src = ptr; > > - len = hweight_long(*srcvm); > > - for (i = 0; i < len; i++) { > > - src[i] = cpu_to_le32(ffs(*srcvm) - 1); > > - *srcvm ^= 1 << (ffs(*srcvm) - 1); > > - } > > + i = 0; > > + for_each_set_bit(b, &srcvm_bits, sizeof(srcvm_bits)) > > The modem is sad that you only pass 8 here. Changed it to BITS_PER_LONG > to include the modem's permission bit and applied all three patches. > Ah of course. Thanks. BTW, srcvm is an unsigned int, but then we do a bunch of unsigned long operations on them. Maybe the whole API should be changed to be more explicit about the size of the type, i.e. u64? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [PATCH 2/3] firmware: qcom_scm: Cleanup code in qcom_scm_assign_mem() 2019-07-23 0:04 ` Stephen Boyd @ 2019-07-23 0:21 ` Bjorn Andersson 0 siblings, 0 replies; 27+ messages in thread From: Bjorn Andersson @ 2019-07-23 0:21 UTC (permalink / raw) To: Stephen Boyd Cc: Andy Gross, linux-kernel, linux-arm-msm, Ian Jackson, Julien Grall, Avaneesh Kumar Dwivedi On Mon 22 Jul 17:04 PDT 2019, Stephen Boyd wrote: > Quoting Bjorn Andersson (2019-07-22 16:27:19) > > On Fri 17 May 14:09 PDT 2019, Stephen Boyd wrote: > > > > > There are some questionable coding styles in this function. It looks > > > quite odd to deref a pointer with array indexing that only uses the > > > first element. Also, destroying an input/output variable halfway through > > > the function and then overwriting it on success is not clear. It's > > > better to use a local variable and the kernel macros to step through > > > each bit set in a bitmask and clearly show where outputs are set. > > > > > > Cc: Ian Jackson <ian.jackson@citrix.com> > > > Cc: Julien Grall <julien.grall@arm.com> > > > Cc: Bjorn Andersson <bjorn.andersson@linaro.org> > > > Cc: Avaneesh Kumar Dwivedi <akdwived@codeaurora.org> > > > Signed-off-by: Stephen Boyd <swboyd@chromium.org> > > > --- > > > drivers/firmware/qcom_scm.c | 34 ++++++++++++++++------------------ > > > include/linux/qcom_scm.h | 9 +++++---- > > > 2 files changed, 21 insertions(+), 22 deletions(-) > > > > > > diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c > > > index 0c63495cf269..153f13f72bac 100644 > > > --- a/drivers/firmware/qcom_scm.c > > > +++ b/drivers/firmware/qcom_scm.c > > > @@ -443,7 +443,8 @@ EXPORT_SYMBOL(qcom_scm_set_remote_state); > > > */ > > > int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, > > > unsigned int *srcvm, > > > - struct qcom_scm_vmperm *newvm, int dest_cnt) > > > + const struct qcom_scm_vmperm *newvm, > > > + unsigned int dest_cnt) > > > { > > > struct qcom_scm_current_perm_info *destvm; > > > struct qcom_scm_mem_map_info *mem_to_map; > > > @@ -458,11 +459,10 @@ int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, > > > int next_vm; > > > __le32 *src; > > > void *ptr; > > > - int ret; > > > - int len; > > > - int i; > > > + int ret, i, b; > > > + unsigned long srcvm_bits = *srcvm; > > > > > > - src_sz = hweight_long(*srcvm) * sizeof(*src); > > > + src_sz = hweight_long(srcvm_bits) * sizeof(*src); > > > mem_to_map_sz = sizeof(*mem_to_map); > > > dest_sz = dest_cnt * sizeof(*destvm); > > > ptr_sz = ALIGN(src_sz, SZ_64) + ALIGN(mem_to_map_sz, SZ_64) + > > > @@ -475,28 +475,26 @@ int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, > > > > > > /* Fill source vmid detail */ > > > src = ptr; > > > - len = hweight_long(*srcvm); > > > - for (i = 0; i < len; i++) { > > > - src[i] = cpu_to_le32(ffs(*srcvm) - 1); > > > - *srcvm ^= 1 << (ffs(*srcvm) - 1); > > > - } > > > + i = 0; > > > + for_each_set_bit(b, &srcvm_bits, sizeof(srcvm_bits)) > > > > The modem is sad that you only pass 8 here. Changed it to BITS_PER_LONG > > to include the modem's permission bit and applied all three patches. > > > > Ah of course. Thanks. > > BTW, srcvm is an unsigned int, but then we do a bunch of unsigned long > operations on them. Maybe the whole API should be changed to be more > explicit about the size of the type, i.e. u64? > It's a bitmap of vmids currently with access to the region and the space has expanded since I looked at this list time, so the now highest defined id in the downstream kernel is 42. So it sounds very reasonable to expand this to a u64. Regards, Bjorn ^ permalink raw reply [flat|nested] 27+ messages in thread
* [PATCH 3/3] firmware: qcom_scm: Fix some typos in docs and printks 2019-05-17 16:10 ` Ian Jackson ` (4 preceding siblings ...) (?) @ 2019-05-17 21:09 ` Stephen Boyd -1 siblings, 0 replies; 27+ messages in thread From: Stephen Boyd @ 2019-05-17 21:09 UTC (permalink / raw) To: Andy Gross Cc: linux-kernel, linux-arm-msm, Ian Jackson, Julien Grall, Bjorn Andersson, Avaneesh Kumar Dwivedi Some words are misspelled and we put a full stop after a return value integer. Fix these things up so it doesn't look so odd. Cc: Ian Jackson <ian.jackson@citrix.com> Cc: Julien Grall <julien.grall@arm.com> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Avaneesh Kumar Dwivedi <akdwived@codeaurora.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> --- drivers/firmware/qcom_scm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c index 153f13f72bac..e300cc272847 100644 --- a/drivers/firmware/qcom_scm.c +++ b/drivers/firmware/qcom_scm.c @@ -435,11 +435,11 @@ EXPORT_SYMBOL(qcom_scm_set_remote_state); * @mem_sz: size of the region. * @srcvm: vmid for current set of owners, each set bit in * flag indicate a unique owner - * @newvm: array having new owners and corrsponding permission + * @newvm: array having new owners and corresponding permission * flags * @dest_cnt: number of owners in next set. * - * Return negative errno on failure, 0 on success, with @srcvm updated. + * Return negative errno on failure or 0 on success with @srcvm updated. */ int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, unsigned int *srcvm, @@ -502,7 +502,7 @@ int qcom_scm_assign_mem(phys_addr_t mem_addr, size_t mem_sz, dma_free_coherent(__scm->dev, ptr_sz, ptr, ptr_dma); if (ret) { dev_err(__scm->dev, - "Assign memory protection call failed %d.\n", ret); + "Assign memory protection call failed %d\n", ret); return -EINVAL; } -- Sent by a computer through tubes ^ permalink raw reply related [flat|nested] 27+ messages in thread
end of thread, other threads:[~2019-07-23 0:21 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-04-30 11:34 [linux-4.19 test] 135420: regressions - FAIL osstest service owner 2019-04-30 11:34 ` [Xen-devel] " osstest service owner 2019-04-30 12:44 ` linux 4.19 does not build on armhf " Ian Jackson 2019-04-30 12:44 ` [Xen-devel] " Ian Jackson 2019-04-30 14:05 ` Jan Beulich 2019-04-30 14:05 ` [Xen-devel] " Jan Beulich 2019-04-30 14:06 ` qcom_scm: Incompatible pointer type build failure Julien Grall 2019-04-30 14:06 ` Julien Grall 2019-04-30 14:06 ` [Xen-devel] " Julien Grall 2019-05-17 16:10 ` Ian Jackson 2019-05-17 16:10 ` [Xen-devel] " Ian Jackson 2019-05-17 16:10 ` Ian Jackson 2019-05-17 21:09 ` [PATCH 0/3] qcom_scm: Fix some dma mapping things Stephen Boyd 2019-05-17 21:09 ` [PATCH 1/3] firmware: qcom_scm: Use proper types for dma mappings Stephen Boyd 2019-05-20 9:41 ` Ian Jackson 2019-05-20 13:20 ` Julien Grall 2019-05-30 16:51 ` [OSSTEST PATCH] ts-kernel-build: Disable CONFIG_ARCH_QCOM in Xen Project CI Ian Jackson 2019-05-30 16:51 ` [Xen-devel] " Ian Jackson 2019-05-30 16:51 ` Ian Jackson 2019-05-31 15:52 ` Julien Grall 2019-05-31 15:52 ` Julien Grall 2019-05-31 15:52 ` [Xen-devel] " Julien Grall 2019-05-17 21:09 ` [PATCH 2/3] firmware: qcom_scm: Cleanup code in qcom_scm_assign_mem() Stephen Boyd 2019-07-22 23:27 ` Bjorn Andersson 2019-07-23 0:04 ` Stephen Boyd 2019-07-23 0:21 ` Bjorn Andersson 2019-05-17 21:09 ` [PATCH 3/3] firmware: qcom_scm: Fix some typos in docs and printks Stephen Boyd
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.