Commit graph

932,869 commits

Author SHA1 Message Date
YueHaibing
0b17159de2 clk: mediatek: mt6797: use devm_platform_ioremap_resource() to simplify code
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lkml.kernel.org/r/20191015124728.25072-1-yuehaibing@huawei.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-10-16 16:17:46 -07:00
YueHaibing
aa136002ae clk: mediatek: mt7629: use devm_platform_ioremap_resource() to simplify code
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lkml.kernel.org/r/20191015124226.25792-1-yuehaibing@huawei.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-10-16 16:17:44 -07:00
YueHaibing
ed4e1bbb44 clk: mediatek: mt7622: use devm_platform_ioremap_resource() to simplify code
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lkml.kernel.org/r/20191015121735.26228-1-yuehaibing@huawei.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-10-16 16:17:42 -07:00
YueHaibing
067de0a647 clk: mediatek: mt8183: use devm_platform_ioremap_resource() to simplify code
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lkml.kernel.org/r/20191015121421.26144-1-yuehaibing@huawei.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-10-16 16:17:40 -07:00
YueHaibing
71ae814181 clk: mediatek: mt6779: use devm_platform_ioremap_resource() to simplify code
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lkml.kernel.org/r/20191015121035.24736-1-yuehaibing@huawei.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-10-16 16:17:37 -07:00
YueHaibing
73c3bf70b3 clk: mediatek: mt2712: use devm_platform_ioremap_resource() to simplify code
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lkml.kernel.org/r/20191015112644.19816-1-yuehaibing@huawei.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-10-16 16:17:32 -07:00
YueHaibing
1f8f3c6b35 clk: davinci: use devm_platform_ioremap_resource() to simplify code
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lkml.kernel.org/r/20191014144407.23264-1-yuehaibing@huawei.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-10-16 16:17:14 -07:00
YueHaibing
75cc0a123c clk: hisilicon: use devm_platform_ioremap_resource() to simplify code
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lkml.kernel.org/r/20191014144014.20644-1-yuehaibing@huawei.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-10-16 16:17:06 -07:00
YueHaibing
4d3a369510 clk: bcm2835: use devm_platform_ioremap_resource() to simplify code
Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lkml.kernel.org/r/20191014143642.24552-1-yuehaibing@huawei.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-10-16 16:16:50 -07:00
Florian Fainelli
aa76f25e37 This pull request clarifies maintainership of the BCM2711 and adds a replacement
mail address for a former contributor.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iQIcBAABCAAGBQJdpfsHAAoJEFXEMs9xUwyNEYQP/i3whN/ZhCIQypmxvfnbbIgZ
 hzQER1Bj7GxuVLsIm9lPU9RjutYPDSRyx1fA71yDcIN7Cn4rcZfMi1CkQgjfhS3Y
 AtER1WVSv59bFJh0mfARe1ok5oUVjI9Ft4E59KzLhjk5t6xvInbw+08sqx7P8ovN
 BIfM4+TBvBHQZmptI7GQMiIjx85Ydo4y7FcOwZzmzDuUqE4JV3fDLOUQz2c7vgZE
 Xd0mMfDB0p+83XWjSwjO7iK1kbiCeRik/UpFYc6CEmIGAznaol+wunb4Oo1C/8Sn
 Eg62OcROgbn+Q1NVtadcuBgNMJ1n7v76cED6e3t2mYwE2S7MT1c/OC4/O3By4m+2
 fPYPkE32pf0W4vyqBFbG8t8z3ksaxCFU3x9JJxGwYiT7+6xSzQF0HqnUK739LWeh
 6mCCKfG4GQjdqOy32vAEq0i4UAF+lwBuhe/J2wTgo+7uRbESnW9oa8PYNY/KDWNo
 ebCUW1gKAZgHwjK8ZTVJU/67dnlW0M2OAbnkUFjdHUZ24n7VAp7yv6kTYMfJLhPR
 R+2K721QG+1YFrZX7sVp5tRKrfRnEbxNg0qnDM2VsvkmOD8fLd6Ua+Il0AmpS8xP
 1uvUI6bvVOk+ps657Ce383LLU/MCZaDCoEwRhq2QRrwqEX5AWdKHoLV0dWxbUcnq
 K0idmPqykDvQ3A8s/96g
 =o3QU
 -----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAl2nlroACgkQh9CWnEQH
 BwSx3g//U9BjmFZWOXMwFwv17m2laWWxOdbIyDs3tzHhBAVNLzkk6H1s3eqOZOeo
 zKc8xdZ6MxkzWA+qEfn1O8OSmI7UTrEioGe5ljZ3pNQPJc+OOauLxaEcnp5Yho1l
 dRwPQVbvBaIGuCOJqVnnLLsfQ6Gf7xMKR269GYr1JSPFs0ddNxFLUBCtZqeKSPUX
 BPEFLaTXvcFgaonUOicuxUc2jVWaDdvxSY8+ztbvJRZWLVg4IrPNk+da85FxXm7j
 VuYEizrwSLRUd5rjwBEw7vsGdEecALHQZdTZMddgV5KXl+hZCWdgq47H3IGqw/i7
 4Kq0nVlLW5mkjoE73+Ym1AQnXu/M75V6Z0RA525zVmLQni9R588atBwTRkSE1qSN
 2A3FoltoaYIjMIMIVLgktvpK85M4J22AM9nYWoyRiUc0WDezWQIIjmZSv1Npa8Pf
 CnpglP/Tt9iMTr+O5f9vFHJxM3F9KQfQA+7Vk0z9+zh/IauqtNPQ+KecDCqcA/mA
 KvWkjaYYJiAzV1iLiM/ICA3ZruccRjFCYddSX4ZgXCIwRYZ95Q9zW3hAiTEhCWGt
 +WkDp/tD8gLEeFY9tRLLilxYuUe8AN3OsIInwIjtbZHIEgYoxoNl94Y255+k2X+2
 LWOKkl1xRwDThiTM5E1SixVkJ5494xlcvUHtP0FxmVN2CRYq5rc=
 =uPG1
 -----END PGP SIGNATURE-----

Merge tag 'tags/bcm2835-maintainers-next-2019-10-15' into maintainers/next

This pull request clarifies maintainership of the BCM2711 and adds a replacement
mail address for a former contributor.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2019-10-16 15:16:14 -07:00
Florian Fainelli
72c630020b This pull request introduces the machine board code for the BCM2711,
which is placed on the Raspberry Pi 4.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iQIcBAABCAAGBQJdpfhTAAoJEFXEMs9xUwyNDIIP/36IpTcRnrRF4haLvXoxAQfP
 VxmENCy8l+RfY6ybuMkFBMr12fa6dgTIIL/6q3ZG/TR2pISQF2kzDxsb1toT2J4i
 YsgPEcTC2SZaiPR0WKkzUtlnTvEBoTAVWRj5o4lXtfIlUUGcfje9MqlA4gnwOj3V
 x62bnLdzBWKLfz9cBmysK4Zy/6prYMe6vYAWiCWhAZDVE78yrB807rtwStXHbd2J
 hppeARb9XK17CDqHDd0GWCebi8C9Lta78OfBwjK7Q2bffK9fxVXj9fYrIl91y2ZT
 HGWgjV3NWH7x7zfZYDviTiws+unx7+dw/DZUTb+ykjU8g1UXgtn+qxasv/qmlJFD
 9GBE9vvlT9TF3Pvums4wJ0qXag6NyBbqXUZgTYcNCsFmoK52UZjuECjd6gl8chX1
 GYhi3OrnrWATvYpJEfNud3JkaF/Wlgq/x0n4Y75hatW9AIWCsXB0oaB9mPdWuUAI
 AKRYwvTP19z7NpyE3vbidXVKpZiyxUvnmhMZaAYZLt0aC153219YaDM3qspHGetD
 A3Pw6MCP5yP+ebAFq3CV+jjkuYYyk52rBlPjX0Bnf73+KT10lB5h7Pf+c3uy5gsB
 vh9mRGoXc5Fpacv1je68lT4JStV0fxVXCNfmlUc8RUur9pHHxDwlH7zQ/FL3FEdf
 mW5ZxpM5gVk776MJzcnP
 =Phsw
 -----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAl2nlnIACgkQh9CWnEQH
 BwSLsBAA4DEtm14Z0po2wqo054psm4t2Tott1G5Ivlt+ML68biFIF5zcdvtSP0i/
 nG9ZiN/KDt+cRpHd8xJVZWzAPcy83JTXvJFDWcG7fZ1rM6rajTltIRcv1bYekHxt
 zTnlpQWs1yUSortpP0RGgiicI5x5AxJwUk0jnSVTSu8Sz4j3eYZjMsQeXZZM81fh
 5vQnBvvsq4Qu3F40MaAjmW8roV+YIYaWEH3DC0a1ErKWMJlJ/xtdpQRRCW4eZT88
 UMv+JkLEg19SAE2nFqyXZ1+ifD4Ot3AvMWmn4xTdQXw9MFFwx/bu6dYh3RXeNrnF
 pSN4zzT11YaHeCGMsyvk30ECZdzRr9qvCFnFtm5oHUpJ1IsO3CuOE1+V887JX+KW
 tHBjb593wLfU9W66KIipYGJOmUXzKBiaTwcmfEcEE8tdkAcngd08aBI3xbOUaKeX
 /F1Lcg7ZbCuJYWT+Srbd+lqG9eb5E1ZWaIE6As6U1mW8/i/YzbtH3gm0z3+Utrqt
 019LSfqeFjLA2LzYMOOZ3Jsas3JPkE7uckmJevzoQtMTTGNVnpYwP6L9+lyWOP/Q
 dxc8b/opyIibh6amhjvoNooINoFKjSjtynZzZ4+w4fYL1+cIYD8GBd4llIozgpEB
 w3QWDmtLAo5oUbVbz3AdryKSeZj0Ar0i/KLl87Rzg65X+8aHq6Q=
 =/AKh
 -----END PGP SIGNATURE-----

Merge tag 'tags/bcm2835-soc-next-2019-10-15' into soc/next

This pull request introduces the machine board code for the BCM2711,
which is placed on the Raspberry Pi 4.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2019-10-16 15:15:00 -07:00
Florian Fainelli
c0c7d81e0a This pull request introduce initial Raspberry Pi 4 support. But all the fancy
stuff like GENET, PCIe, xHCI, 40 bit DMA and V3D is missing.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iQIcBAABCAAGBQJdpfaSAAoJEFXEMs9xUwyNbBsP/1iWo57lN/XmxuaOdIJEQRzj
 CgWDykNnra17qPVJpJX2VdSkr6maQoxhC6F0gq33X8sW6a5kdChXUOs2iRlKJcjh
 alWXqev5RapkCuK9mLdWL4Rt7F2qNg6c+sv4Ha4QACHPq/roWzYevlgChxU8X/7T
 Ojh1/QXYfbEihmp0KQ+rN/dwItm7r5Nb40WvIuJT0O/WMwc3OyZpGqjTAzaP9dPk
 IfTSty7iHQRrWet2DHEOxG0oKBRV0OFIRfupPLnv85ixBXT0kxsTN3ZT3rgF9AFn
 00ND5o5nJQLuxEoJfNqAPhRinxxzazRHR3QLrfIAA75Lg16NFo9vmSon/XOwowIm
 GHrmSAW9v4eMD1DS9onLBYqRPL/XdMcdRstAWJnwHU77bWJtK3FXG2BJdJby89sJ
 NshFt5TSnoKXSNvluudyDv4ocvD6mj9TyuSQ9ZvnGc+sYbA+L7LgMkpHgLQYwham
 62Z1I/uYFBaYTMsei++t4lHWRlXeqpKlDXe2enIj69FT+vqep8mgoYA/08adjfcq
 xV0K8EHTn8/XYSKhFb6NIZFLVPLWwEcoBn48AQalL9+W1chXFMH0rdhkssDOiA12
 ULrrQsZasJ8fL9ROeyho+4PfGsdVBj5evG6vKz9xeAEQPOncCUcLTTfwtODAjvMh
 jCDlqaBmfeV4x2LLjhJA
 =7VNA
 -----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAl2nlksACgkQh9CWnEQH
 BwTRBRAAhg966nDzrT0klRg2I19L01hW65VJ7/n6htA8a5rx+KUR4PXqzdIU/Alk
 A6cKzFHgPOTXuc90l8F6svPHfjQ7QBO94/ojmznofnOBOMIU3mMV5dxD9bjiJ/yI
 Lc+uKgBCpdBjyClvKHD8ZEDHh0CbfQaqQ+rKs9mrHKdMXtQShXPaiy0Oe2fVSOBc
 fYJ47rpNwCHcWgLeM+285dhdFNeTD/LkQV6QAYmSnWlLuceHAipzpvpNBHfEb0nZ
 UbYOCxsJPIvlWHg4KVWse5R1PAgEE/HVdEP9GUW1KrGH6S/KRMgyu2EC2Bx3+ctp
 68ckDYJtW4Ou+6seh8Gpn8u8TsoNVLYHAhl08aJR+QQodkooZvOAExSXzGyI8Gm3
 tC21efWrlGxzh4VKZHr3/NaQIhvoXLFfKZ9ZoHI52Lz0GjFRsPd50JjDCO17pL6N
 R/7vhA4xsYKMkWsCgVGK5OYLO/7aY92V54/ND3DAx+6TAix7/M/eoH1e2BpMiuws
 e7Oame/anvtvlMM5hRWeNXQGn0VplgoJjAIBKPs1TCAQ7DbJrw2oYTCqUKos4Hqr
 H19nuqft7eSZiFmVcowFiYcy5IutDD7NdbHsUiKo1NwQWtMCd2kdRRQFqDbImStI
 KbkEs6OEy3pUa9EZ1Gv6H030M7FIpuZkify8Rl4Fp6LxsZdghk8=
 =44nd
 -----END PGP SIGNATURE-----

Merge tag 'tags/bcm2835-dt-next-2019-10-15' into devicetree/next

This pull request introduce initial Raspberry Pi 4 support. But all the fancy
stuff like GENET, PCIe, xHCI, 40 bit DMA and V3D is missing.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2019-10-16 15:14:25 -07:00
Ben Dooks
b47879aa85 ARM: bcm: fix missing __iomem in bcm_kona_smc.c
Fix the following sparse warnings from a missing __iomem
in __bcm_kona_smc() function by adding __iomem attriubte.

arch/arm/mach-bcm/bcm_kona_smc.c:143:21: warning: incorrect type in initializer (different address spaces)
arch/arm/mach-bcm/bcm_kona_smc.c:143:21:    expected unsigned int [usertype] *args
arch/arm/mach-bcm/bcm_kona_smc.c:143:21:    got void [noderef] <asn:2> *static [toplevel] [assigned] bcm_smc
_buffer
arch/arm/mach-bcm/bcm_kona_smc.c:149:9: warning: incorrect type in argument 2 (different address spaces)
arch/arm/mach-bcm/bcm_kona_smc.c:149:9:    expected void volatile [noderef] <asn:2> *addr
arch/arm/mach-bcm/bcm_kona_smc.c:149:9:    got unsigned int [usertype] *
arch/arm/mach-bcm/bcm_kona_smc.c:150:9: warning: incorrect type in argument 2 (different address spaces)
arch/arm/mach-bcm/bcm_kona_smc.c:150:9:    expected void volatile [noderef] <asn:2> *addr
arch/arm/mach-bcm/bcm_kona_smc.c:150:9:    got unsigned int [usertype] *
arch/arm/mach-bcm/bcm_kona_smc.c:151:9: warning: incorrect type in argument 2 (different address spaces)
arch/arm/mach-bcm/bcm_kona_smc.c:151:9:    expected void volatile [noderef] <asn:2> *addr
arch/arm/mach-bcm/bcm_kona_smc.c:151:9:    got unsigned int [usertype] *
arch/arm/mach-bcm/bcm_kona_smc.c:152:9: warning: incorrect type in argument 2 (different address spaces)
arch/arm/mach-bcm/bcm_kona_smc.c:152:9:    expected void volatile [noderef] <asn:2> *addr
arch/arm/mach-bcm/bcm_kona_smc.c:152:9:    got unsigned int [usertype] *[assigned] args

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Acked-by: Scott Branden <scott.branden@broadcom.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2019-10-16 15:05:35 -07:00
Ben Dooks
d67fa6caae ARM: bcm: include local platsmp.h for bcm2836_smp_ops
Include platsmp.h for the definition of bcm2836_smp_ops to fix
the following warning:

arch/arm/mach-bcm/platsmp.c:334:29: warning: symbol 'bcm2836_smp_ops' was not declared. Should it be static?

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Acked-by: Scott Branden <scott.branden@broadcom.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
2019-10-16 15:05:26 -07:00
Christophe Leroy
d10f60ae27 powerpc/32s: fix allow/prevent_user_access() when crossing segment boundaries.
Make sure starting addr is aligned to segment boundary so that when
incrementing the segment, the starting address of the new segment is
below the end address. Otherwise the last segment might get  missed.

Fixes: a68c31fc01 ("powerpc/32s: Implement Kernel Userspace Access Protection")
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/067a1b09f15f421d40797c2d04c22d4049a1cee8.1571071875.git.christophe.leroy@c-s.fr
2019-10-17 08:57:43 +11:00
Stephen Boyd
3d883e8969 First round of amlogic clock fixes for v5.4.
This fixes the clock rate propagation for the g12a cpu clocks and
 the gxbb adc clock.
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEE9OFZrhjz9W1fG7cb5vwPHDfy2oUFAl2cMrUACgkQ5vwPHDfy
 2oW58g/+MG2D0vayigtblMRp2+wW6Lk2wmjTqqwdhS0pcw9Z3KG395hP3iMAI3fP
 K4Z5VpSHKumz0/Z/4W8cRwN/W4nrnVr1fm7GJUL19CdmfEFYUtkc3eAdZ4RcXohF
 y8tTMZ+kb5vgHb6xDCUD4GR6GOH9X5YHSIrAj4UCfW4XSRttXYopoyAuTVYhPChG
 cmW1fykWwriqgze+oaluXRaoFPgxViucYU2FWgTQD7Lrfftc0KKKoAhiv2XW3cUC
 9E9c5FOmA/XP0LXx9t8WtnoG5nO8l6oI/J90SsbyeBeyALxjJHTifAIi67Qjqei/
 tb+br6rbK8kWypU6rLBu60UNjbGZhKHpOE+gbYM8NHElgi5fLpa+2fNBfgOz8tuf
 Fqiz/f0lKjceVFz18XJFjfJSBjW6VLa6MaOOM63kkcWmd4jMSmvyhKxrgA0xMRlT
 +HY5pu/6YWXlNjK6kMI5FREti+JJbUZamJtf+YIu1Jg6KFFCCMUJpt1Hai4ySeEa
 jYkBqqbWXROmmvtE/sMSK04XUK74iVpJujn0jbbTEE2VNsMcQW0RmmSqS+7/Na7c
 LJdi7nTj/VKY55pxX/EjkMzXgE4GRbRxnQi9gETM0nSrklvRIAh7m1ePI0oh9K7Y
 2gHT0Zk0B9oKHFXOFPMKSjwwhf/WFW3Y/epcbnIqBfQWWd1+afc=
 =QSFw
 -----END PGP SIGNATURE-----

Merge tag 'clk-meson-fixes-v5.4-1' of https://github.com/BayLibre/clk-meson into clk-fixes

Pull first round of amlogic clock fixes from Jerome Brunet:

 - This fixes the clock rate propagation for the g12a cpu and gxbb adc clocks.

* tag 'clk-meson-fixes-v5.4-1' of https://github.com/BayLibre/clk-meson:
  clk: meson: g12a: set CLK_MUX_ROUND_CLOSEST on the cpu clock muxes
  clk: meson: g12a: fix cpu clock rate setting
  clk: meson: gxbb: let sar_adc_clk_div set the parent clock rate
2019-10-16 14:01:19 -07:00
Biao Huang
e497c20e20 net: stmmac: disable/enable ptp_ref_clk in suspend/resume flow
disable ptp_ref_clk in suspend flow, and enable it in resume flow.

Fixes: f573c0b9c4 ("stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst to platform structure")
Signed-off-by: Biao Huang <biao.huang@mediatek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-16 13:25:39 -07:00
Yonglong Liu
3de5ae5471 net: phy: Fix "link partner" information disappear issue
Some drivers just call phy_ethtool_ksettings_set() to set the
links, for those phy drivers that use genphy_read_status(), if
autoneg is on, and the link is up, than execute "ethtool -s
ethx autoneg on" will cause "link partner" information disappear.

The call trace is phy_ethtool_ksettings_set()->phy_start_aneg()
->linkmode_zero(phydev->lp_advertising)->genphy_read_status(),
the link didn't change, so genphy_read_status() just return, and
phydev->lp_advertising is zero now.

This patch moves the clear operation of lp_advertising from
phy_start_aneg() to genphy_read_lpa()/genphy_c45_read_lpa(), and
if autoneg on and autoneg not complete, just clear what the
generic functions care about.

Fixes: 88d6272aca ("net: phy: avoid unneeded MDIO reads in genphy_read_status")
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-16 13:17:01 -07:00
Peng Fan
727e12cde9 clk: imx: imx8mn: drop unused pll enum
The PLL enum definition is not used, so drop it.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lkml.kernel.org/r/1571122989-29361-1-git-send-email-peng.fan@nxp.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-10-16 13:08:06 -07:00
YueHaibing
b8cb1ef95b clk: ast2600: remove unused variable 'eclk_parent_names'
drivers/clk/clk-ast2600.c:119:27: warning:
 eclk_parent_names defined but not used [-Wunused-const-variable=]

It is never used, so can be removed.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lkml.kernel.org/r/20191015115117.23504-1-yuehaibing@huawei.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2019-10-16 13:05:19 -07:00
Sebastian Andrzej Siewior
f86cf71944 drm/i810: Refer to `PREEMPTION' in comment
The dependency has been changed from `PREEMPT' to `PREEMPTION'. Reflect
this change in the comment.

Use `PREEMPTION' in the comment.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Sean Paul <sean@poorly.run>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20191015191821.11479-29-bigeasy@linutronix.de
2019-10-16 21:57:59 +02:00
Shuah Khan
303e6218ec selftests: Fix O= and KBUILD_OUTPUT handling for relative paths
Fix O= and KBUILD_OUTPUT handling for relative paths.

export KBUILD_OUTPUT=../kselftest_size
make TARGETS=size kselftest-all

or

make O=../kselftest_size TARGETS=size kselftest-all

In both of these cases, targets get built in ../kselftest_size which is
a one level up from the size test directory.

make[1]: Entering directory '/mnt/data/lkml/kselftest_size'
make --no-builtin-rules INSTALL_HDR_PATH=$BUILD/usr \
        ARCH=x86 -C ../../.. headers_install
  INSTALL ../kselftest_size/usr/include
gcc -static -ffreestanding -nostartfiles -s    get_size.c  -o ../kselftest_size/size/get_size
/usr/bin/ld: cannot open output file ../kselftest_size/size/get_size: No such file or directory
collect2: error: ld returned 1 exit status
make[3]: *** [../lib.mk:138: ../kselftest_size/size/get_size] Error 1
make[2]: *** [Makefile:143: all] Error 2
make[1]: *** [/mnt/data/lkml/linux_5.4/Makefile:1221: kselftest-all] Error 2
make[1]: Leaving directory '/mnt/data/lkml/kselftest_size'
make: *** [Makefile:179: sub-make] Error 2

Use abs_objtree exported by the main Makefile.

Reported-by: Tim Bird <Tim.Bird@sony.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Tested-by: Tim Bird <tim.bird@sony.com>
Acked-by: Tim Bird <tim.bird@sony.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2019-10-16 13:42:01 -06:00
Johan Jonker
d083ce4279 include: dt-bindings: rockchip: mark RK_FUNC defines as deprecated
The defines RK_FUNC_1, RK_FUNC_2, RK_FUNC_3 and RK_FUNC_4
are no longer used. Mark them as "deprecated"
to prevent that someone start using them again.

Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20191015205852.4200-2-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-10-16 21:40:54 +02:00
Johan Jonker
4ff7525371 arm64: dts: rockchip: restyle rockchip,pins on rk3399-rock-pi-4
The define RK_FUNC_1 is no longer used,
so restyle the rockchip,pins definitions.

Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20191015205852.4200-1-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-10-16 21:40:29 +02:00
Hariprasad Kelam
4b1d7c2760 media: staging: media: Make use of devm_platform_ioremap_resource
Fix below issue reported by coccicheck
drivers/staging//media/omap4iss/iss.c:915:1-15: WARNING: Use
devm_platform_ioremap_resource for iss -> regs [ res ]

Signed-off-by: Hariprasad Kelam <hariprasad.kelam@gmail.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-10-16 16:35:15 -03:00
Nachammai Karuppiah
50df3be70a media: staging: media: omap4iss: Replace NULL comparison.
This patch modifies NULL comparison to fix checkpatch.pl warning.

Signed-off-by: Nachammai Karuppiah <nachukannan@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-10-16 16:34:53 -03:00
Christophe JAILLET
ac7dabf140 media: uvcvideo: Fix a typo in UVC_METATADA_BUF_SIZE
It is likely that it should be UVC_METADATA_BUF_SIZE instead.
Fix it and use it.

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-10-16 16:34:34 -03:00
Laurent Pinchart
8c279e9394 media: uvcvideo: Fix error path in control parsing failure
When parsing the UVC control descriptors fails, the error path tries to
cleanup a media device that hasn't been initialised, potentially
resulting in a crash. Fix this by initialising the media device before
the error handling path can be reached.

Fixes: 5a254d751e ("[media] uvcvideo: Register a v4l2_device")
Reported-by: syzbot+c86454eb3af9e8a4da20@syzkaller.appspotmail.com
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-10-16 16:33:58 -03:00
Johan Jonker
a562a8accc ARM: dts: rockchip: remove some tabs and spaces from dtsi files
Cleanup the Rockchip dtsi files a little bit
by removing some tabs and spaces.

Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20191014210619.12778-1-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-10-16 21:26:03 +02:00
Eric Dumazet
2ca4f6ca45 rxrpc: use rcu protection while reading sk->sk_user_data
We need to extend the rcu_read_lock() section in rxrpc_error_report()
and use rcu_dereference_sk_user_data() instead of plain access
to sk->sk_user_data to make sure all rules are respected.

The compiler wont reload sk->sk_user_data at will, and RCU rules
prevent memory beeing freed too soon.

Fixes: f0308fb070 ("rxrpc: Fix possible NULL pointer access in ICMP handling")
Fixes: 17926a7932 ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-16 12:20:17 -07:00
Szymon Janc
4c371bb95c Bluetooth: Workaround directed advertising bug in Broadcom controllers
It appears that some Broadcom controllers (eg BCM20702A0) reject LE Set
Advertising Parameters command if advertising intervals provided are not
within range for undirected and low duty directed advertising.

Workaround this bug by populating min and max intervals with 'valid'
values.

< HCI Command: LE Set Advertising Parameters (0x08|0x0006) plen 15
        Min advertising interval: 0.000 msec (0x0000)
        Max advertising interval: 0.000 msec (0x0000)
        Type: Connectable directed - ADV_DIRECT_IND (high duty cycle) (0x01)
        Own address type: Public (0x00)
        Direct address type: Random (0x01)
        Direct address: E2:F0:7B:9F:DC:F4 (Static)
        Channel map: 37, 38, 39 (0x07)
        Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4
      LE Set Advertising Parameters (0x08|0x0006) ncmd 1
        Status: Invalid HCI Command Parameters (0x12)

Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
Tested-by: Sören Beye <linux@hypfer.de>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-10-16 21:16:13 +02:00
Sebastian Reichel
54976bc700 Bluetooth: btwilink: drop superseded driver
All users of this driver have been converted to the serdev based
hci_ll driver. The unused driver can be safely dropped now.

Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-10-16 21:12:52 +02:00
Chris Wilson
972c646f1c drm/i915: Move swizzle_bit under i915_ggtt
The HW performs swizzling as part of its fence tiling inside the Global
GTT. We already do the probing of the HW settings from the GGTT setup,
complete the picture by storing the information as part of the GGTT. The
primary benefit is the consistency of our probe routines do not break
the i915_ggtt encapsulation.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191016143234.4075-2-chris@chris-wilson.co.uk
2019-10-16 19:42:19 +01:00
Chris Wilson
e9d4c9245f drm/i915: Store i915_ggtt as the backpointer on fence registers
Now that i915_ggtt knows everything about its own paths to perform mmio,
we can use that as our primary backpointer for individual fence
registers. This reduces the amount of pointer dancing we have to perform
on the common paths, but more importantly finishes our fence register
encapsulation.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191016143234.4075-1-chris@chris-wilson.co.uk
2019-10-16 19:41:36 +01:00
Ben Dooks (Codethink)
727ea61a50 Bluetooth: missed cpu_to_le16 conversion in hci_init4_req
It looks like in hci_init4_req() the request is being
initialised from cpu-endian data but the packet is specified
to be little-endian. This causes an warning from sparse due
to __le16 to u16 conversion.

Fix this by using cpu_to_le16() on the two fields in the packet.

net/bluetooth/hci_core.c:845:27: warning: incorrect type in assignment (different base types)
net/bluetooth/hci_core.c:845:27:    expected restricted __le16 [usertype] tx_len
net/bluetooth/hci_core.c:845:27:    got unsigned short [usertype] le_max_tx_len
net/bluetooth/hci_core.c:846:28: warning: incorrect type in assignment (different base types)
net/bluetooth/hci_core.c:846:28:    expected restricted __le16 [usertype] tx_time
net/bluetooth/hci_core.c:846:28:    got unsigned short [usertype] le_max_tx_time

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-10-16 20:37:15 +02:00
Chris Wilson
eca0b72089 drm/i915: Do initial mocs configuration directly
Now that we record the default "goldenstate" context, we do not need to
emit the mocs registers at the start of each context and can simply do
mmio before the first context and capture the registers as part of its
default image. As a consequence, this means that we repeat the mmio
after each engine reset, fixing up any platform and registers that were
zapped by the reset (for those platforms with global not context-saved
settings).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111723
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111645
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com>
Reviewed-by: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191016090749.7092-1-chris@chris-wilson.co.uk
2019-10-16 19:35:37 +01:00
Adam Ford
cef456cd35 Revert "Bluetooth: hci_ll: set operational frequency earlier"
As nice as it would be to update firmware faster, that patch broke
at least two different boards, an OMAP4+WL1285 based Motorola Droid
4, as reported by Sebasian Reichel and the Logic PD i.MX6Q +
WL1837MOD.

This reverts commit a2e02f38ef.

Signed-off-by: Adam Ford <aford173@gmail.com>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: stable@vger.kernel.org
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-10-16 20:33:16 +02:00
Russell King
2203cbf2c8 net: sfp: move fwnode parsing into sfp-bus layer
Rather than parsing the sfp firmware node in phylink, parse it in the
sfp-bus code, so we can re-use this code for PHYs without having to
duplicate the parsing.

Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-16 14:31:59 -04:00
Hayes Wang
9370f2d05a r8152: support request_firmware for RTL8153
This patch supports loading additional firmware file through
request_firmware().

A firmware file may include a header followed by several blocks
which have different types of firmware. Currently, the supported
types are RTL_FW_END, RTL_FW_PLA, and RTL_FW_USB.

The firmware is used to fix some compatible or hardware issues. For
example, the device couldn't be found after rebooting several times.

The supported chips are
	RTL_VER_04 (rtl8153a-2.fw)
	RTL_VER_05 (rtl8153a-3.fw)
	RTL_VER_06 (rtl8153a-4.fw)
	RTL_VER_09 (rtl8153b-2.fw)

Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Reviewed-by: Prashant Malani <pmalani@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-16 14:30:50 -04:00
Chris Wilson
0a544a2a72 drm/i915: Fixup preempt-to-busy vs resubmission of a virtual request
As preempt-to-busy leaves the request on the HW as the resubmission is
processed, that request may complete in the background and even cause a
second virtual request to enter queue. This second virtual request
breaks our "single request in the virtual pipeline" assumptions.
Furthermore, as the virtual request may be completed and retired, we
lose the reference the virtual engine assumes is held. Normally, just
removing the request from the scheduler queue removes it from the
engine, but the virtual engine keeps track of its singleton request via
its ve->request. This pointer needs protecting with a reference.

v2: Drop unnecessary motion of rq->engine = owner

Fixes: 22b7a426bb ("drm/i915/execlists: Preempt-to-busy")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190923152844.8914-1-chris@chris-wilson.co.uk
(cherry picked from commit b647c7df01)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-10-16 10:57:33 -07:00
Chris Wilson
4f2a572eda drm/i915/userptr: Never allow userptr into the mappable GGTT
Daniel Vetter uncovered a nasty cycle in using the mmu-notifiers to
invalidate userptr objects which also happen to be pulled into GGTT
mmaps. That is when we unbind the userptr object (on mmu invalidation),
we revoke all CPU mmaps, which may then recurse into mmu invalidation.

We looked for ways of breaking the cycle, but the revocation on
invalidation is required and cannot be avoided. The only solution we
could see was to not allow such GGTT bindings of userptr objects in the
first place. In practice, no one really wants to use a GGTT mmapping of
a CPU pointer...

Just before Daniel's explosive lockdep patches land in v5.4-rc1, we got
a genuine blip from CI:

<4>[  246.793958] ======================================================
<4>[  246.793972] WARNING: possible circular locking dependency detected
<4>[  246.793989] 5.3.0-gbd6c56f50d15-drmtip_372+ #1 Tainted: G     U
<4>[  246.794003] ------------------------------------------------------
<4>[  246.794017] kswapd0/145 is trying to acquire lock:
<4>[  246.794030] 000000003f565be6 (&dev->struct_mutex/1){+.+.}, at: userptr_mn_invalidate_range_start+0x18f/0x220 [i915]
<4>[  246.794250]
                  but task is already holding lock:
<4>[  246.794263] 000000001799cef9 (&anon_vma->rwsem){++++}, at: page_lock_anon_vma_read+0xe6/0x2a0
<4>[  246.794291]
                  which lock already depends on the new lock.

<4>[  246.794307]
                  the existing dependency chain (in reverse order) is:
<4>[  246.794322]
                  -> #3 (&anon_vma->rwsem){++++}:
<4>[  246.794344]        down_write+0x33/0x70
<4>[  246.794357]        __vma_adjust+0x3d9/0x7b0
<4>[  246.794370]        __split_vma+0x16a/0x180
<4>[  246.794385]        mprotect_fixup+0x2a5/0x320
<4>[  246.794399]        do_mprotect_pkey+0x208/0x2e0
<4>[  246.794413]        __x64_sys_mprotect+0x16/0x20
<4>[  246.794429]        do_syscall_64+0x55/0x1c0
<4>[  246.794443]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[  246.794456]
                  -> #2 (&mapping->i_mmap_rwsem){++++}:
<4>[  246.794478]        down_write+0x33/0x70
<4>[  246.794493]        unmap_mapping_pages+0x48/0x130
<4>[  246.794519]        i915_vma_revoke_mmap+0x81/0x1b0 [i915]
<4>[  246.794519]        i915_vma_unbind+0x11d/0x4a0 [i915]
<4>[  246.794519]        i915_vma_destroy+0x31/0x300 [i915]
<4>[  246.794519]        __i915_gem_free_objects+0xb8/0x4b0 [i915]
<4>[  246.794519]        drm_file_free.part.0+0x1e6/0x290
<4>[  246.794519]        drm_release+0xa6/0xe0
<4>[  246.794519]        __fput+0xc2/0x250
<4>[  246.794519]        task_work_run+0x82/0xb0
<4>[  246.794519]        do_exit+0x35b/0xdb0
<4>[  246.794519]        do_group_exit+0x34/0xb0
<4>[  246.794519]        __x64_sys_exit_group+0xf/0x10
<4>[  246.794519]        do_syscall_64+0x55/0x1c0
<4>[  246.794519]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[  246.794519]
                  -> #1 (&vm->mutex){+.+.}:
<4>[  246.794519]        i915_gem_shrinker_taints_mutex+0x6d/0xe0 [i915]
<4>[  246.794519]        i915_address_space_init+0x9f/0x160 [i915]
<4>[  246.794519]        i915_ggtt_init_hw+0x55/0x170 [i915]
<4>[  246.794519]        i915_driver_probe+0xc9f/0x1620 [i915]
<4>[  246.794519]        i915_pci_probe+0x43/0x1b0 [i915]
<4>[  246.794519]        pci_device_probe+0x9e/0x120
<4>[  246.794519]        really_probe+0xea/0x3d0
<4>[  246.794519]        driver_probe_device+0x10b/0x120
<4>[  246.794519]        device_driver_attach+0x4a/0x50
<4>[  246.794519]        __driver_attach+0x97/0x130
<4>[  246.794519]        bus_for_each_dev+0x74/0xc0
<4>[  246.794519]        bus_add_driver+0x13f/0x210
<4>[  246.794519]        driver_register+0x56/0xe0
<4>[  246.794519]        do_one_initcall+0x58/0x300
<4>[  246.794519]        do_init_module+0x56/0x1f6
<4>[  246.794519]        load_module+0x25bd/0x2a40
<4>[  246.794519]        __se_sys_finit_module+0xd3/0xf0
<4>[  246.794519]        do_syscall_64+0x55/0x1c0
<4>[  246.794519]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[  246.794519]
                  -> #0 (&dev->struct_mutex/1){+.+.}:
<4>[  246.794519]        __lock_acquire+0x15d8/0x1e90
<4>[  246.794519]        lock_acquire+0xa6/0x1c0
<4>[  246.794519]        __mutex_lock+0x9d/0x9b0
<4>[  246.794519]        userptr_mn_invalidate_range_start+0x18f/0x220 [i915]
<4>[  246.794519]        __mmu_notifier_invalidate_range_start+0x85/0x110
<4>[  246.794519]        try_to_unmap_one+0x76b/0x860
<4>[  246.794519]        rmap_walk_anon+0x104/0x280
<4>[  246.794519]        try_to_unmap+0xc0/0xf0
<4>[  246.794519]        shrink_page_list+0x561/0xc10
<4>[  246.794519]        shrink_inactive_list+0x220/0x440
<4>[  246.794519]        shrink_node_memcg+0x36e/0x740
<4>[  246.794519]        shrink_node+0xcb/0x490
<4>[  246.794519]        balance_pgdat+0x241/0x580
<4>[  246.794519]        kswapd+0x16c/0x530
<4>[  246.794519]        kthread+0x119/0x130
<4>[  246.794519]        ret_from_fork+0x24/0x50
<4>[  246.794519]
                  other info that might help us debug this:

<4>[  246.794519] Chain exists of:
                    &dev->struct_mutex/1 --> &mapping->i_mmap_rwsem --> &anon_vma->rwsem

<4>[  246.794519]  Possible unsafe locking scenario:

<4>[  246.794519]        CPU0                    CPU1
<4>[  246.794519]        ----                    ----
<4>[  246.794519]   lock(&anon_vma->rwsem);
<4>[  246.794519]                                lock(&mapping->i_mmap_rwsem);
<4>[  246.794519]                                lock(&anon_vma->rwsem);
<4>[  246.794519]   lock(&dev->struct_mutex/1);
<4>[  246.794519]
                   *** DEADLOCK ***

v2: Say no to mmap_ioctl

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111744
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111870
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190928082546.3473-1-chris@chris-wilson.co.uk
(cherry picked from commit a4311745bb)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-10-16 10:56:50 -07:00
Ville Syrjälä
0336ab5808 drm/i915: Favor last VBT child device with conflicting AUX ch/DDC pin
The first come first served apporoach to handling the VBT
child device AUX ch conflicts has backfired. We have machines
in the wild where the VBT specifies both port A eDP and
port E DP (in that order) with port E being the real one.

So let's try to flip the preference around and let the last
child device win once again.

Cc: stable@vger.kernel.org
Cc: Jani Nikula <jani.nikula@intel.com>
Tested-by: Masami Ichikawa <masami256@gmail.com>
Tested-by: Torsten <freedesktop201910@liggy.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111966
Fixes: 36a0f92020 ("drm/i915/bios: make child device order the priority order")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191011202030.8829-1-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit 41e35ffb38)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-10-16 10:56:50 -07:00
Chris Wilson
128260a41e drm/i915/execlists: Refactor -EIO markup of hung requests
Pull setting -EIO on the hung requests into its own utility function.
Having allowed ourselves to short-circuit submission of completed
requests, we can now do the mark_eio() prior to submission and avoid
some redundant operations.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190923110056.15176-4-chris@chris-wilson.co.uk
(cherry picked from commit 0d7cf7bc15)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-10-16 10:55:36 -07:00
Mahesh Bandewar
bd74708cd9 Revert "blackhole_netdev: fix syzkaller reported issue"
This reverts commit b0818f80c8.

Started seeing weird behavior after this patch especially in
the IPv6 code path. Haven't root caused it, but since this was
applied to net branch, taking a precautionary measure to revert
it and look / analyze those failures

Revert this now and I'll send a better fix after analysing / fixing
the weirdness observed.

CC: Eric Dumazet <edumazet@google.com>
CC: Wei Wang <weiwan@google.com>
CC: David S. Miller <davem@davemloft.net>
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-10-16 13:41:26 -04:00
Song Liu
eac9153f2b bpf/stackmap: Fix deadlock with rq_lock in bpf_get_stack()
bpf stackmap with build-id lookup (BPF_F_STACK_BUILD_ID) can trigger A-A
deadlock on rq_lock():

rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[...]
Call Trace:
 try_to_wake_up+0x1ad/0x590
 wake_up_q+0x54/0x80
 rwsem_wake+0x8a/0xb0
 bpf_get_stack+0x13c/0x150
 bpf_prog_fbdaf42eded9fe46_on_event+0x5e3/0x1000
 bpf_overflow_handler+0x60/0x100
 __perf_event_overflow+0x4f/0xf0
 perf_swevent_overflow+0x99/0xc0
 ___perf_sw_event+0xe7/0x120
 __schedule+0x47d/0x620
 schedule+0x29/0x90
 futex_wait_queue_me+0xb9/0x110
 futex_wait+0x139/0x230
 do_futex+0x2ac/0xa50
 __x64_sys_futex+0x13c/0x180
 do_syscall_64+0x42/0x100
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

This can be reproduced by:
1. Start a multi-thread program that does parallel mmap() and malloc();
2. taskset the program to 2 CPUs;
3. Attach bpf program to trace_sched_switch and gather stackmap with
   build-id, e.g. with trace.py from bcc tools:
   trace.py -U -p <pid> -s <some-bin,some-lib> t:sched:sched_switch

A sample reproducer is attached at the end.

This could also trigger deadlock with other locks that are nested with
rq_lock.

Fix this by checking whether irqs are disabled. Since rq_lock and all
other nested locks are irq safe, it is safe to do up_read() when irqs are
not disable. If the irqs are disabled, postpone up_read() in irq_work.

Fixes: 615755a77b ("bpf: extend stackmap to save binary_build_id+offset instead of address")
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20191014171223.357174-1-songliubraving@fb.com

Reproducer:
============================ 8< ============================

char *filename;

void *worker(void *p)
{
        void *ptr;
        int fd;
        char *pptr;

        fd = open(filename, O_RDONLY);
        if (fd < 0)
                return NULL;
        while (1) {
                struct timespec ts = {0, 1000 + rand() % 2000};

                ptr = mmap(NULL, 4096 * 64, PROT_READ, MAP_PRIVATE, fd, 0);
                usleep(1);
                if (ptr == MAP_FAILED) {
                        printf("failed to mmap\n");
                        break;
                }
                munmap(ptr, 4096 * 64);
                usleep(1);
                pptr = malloc(1);
                usleep(1);
                pptr[0] = 1;
                usleep(1);
                free(pptr);
                usleep(1);
                nanosleep(&ts, NULL);
        }
        close(fd);
        return NULL;
}

int main(int argc, char *argv[])
{
        void *ptr;
        int i;
        pthread_t threads[THREAD_COUNT];

        if (argc < 2)
                return 0;

        filename = argv[1];

        for (i = 0; i < THREAD_COUNT; i++) {
                if (pthread_create(threads + i, NULL, worker, NULL)) {
                        fprintf(stderr, "Error creating thread\n");
                        return 0;
                }
        }

        for (i = 0; i < THREAD_COUNT; i++)
                pthread_join(threads[i], NULL);
        return 0;
}
============================ 8< ============================
2019-10-16 10:37:52 -07:00
Marcel Holtmann
c0a21a5294 Bluetooth: btusb: Use IS_ENABLED instead of #ifdef
For the different hardware support options, it is better to use
IS_ENABLED check. Let the compiler do the needed optimizations.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
2019-10-16 19:26:40 +02:00
Arnd Bergmann
42d2209812 Bluetooth: btusb: avoid unused function warning
The btusb_rtl_cmd_timeout() function is used inside of an
ifdef, leading to a warning when this part is hidden
from the compiler:

drivers/bluetooth/btusb.c:530:13: error: unused function 'btusb_rtl_cmd_timeout' [-Werror,-Wunused-function]

Use an IS_ENABLED() check instead so the compiler can see
the code and then discard it silently.

Fixes: d7ef0d1e39 ("Bluetooth: btusb: Use cmd_timeout to reset Realtek device")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-10-16 19:26:40 +02:00
Amit K Bag
74ffdf22b3 Bluetooth: btusb: print FW version after FW download
After FW download there is no print to confirm the current
FW version. Add print to check FW version incase of FW download.

Signed-off-by: Amit K Bag <amit.k.bag@intel.com>
Signed-off-by: Yoni Shavit <yshavit@chromium.org>
Signed-off-by: Chethan Tumkur Narayan <chethan.tumkur.narayan@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-10-16 19:26:40 +02:00
Max Chou
d171dfb621 Bluetooth: btrtl: Fix an issue for the incorrect error return code.
It does not need the '-' for PTR_ERR(skb) because PTR_ERR(skb) will
return the negative value during errors.

Signed-off-by: Max Chou <max.chou@realtek.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-10-16 19:26:40 +02:00
Christophe JAILLET
088fc633f2 Bluetooth: hci_nokia: Save a few cycles in 'nokia_enqueue()'
'skb_pad()' a few lines above already initializes the "padded" byte to 0.
So there is no need to do it twice.

All what is needed is to increase the len of the skb. So 'skb_put(..., 1)'
is enough here.

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
2019-10-16 19:26:40 +02:00