Commit Graph

1054275 Commits

Author SHA1 Message Date
084952feaa arm64: dts: qcom: sdm845: Update support for AYN Odin
Update working features:
- GPU (with wayland)
- WLAN (not yet)
- Bluetooth

Signed-off-by: BigfootACA <bigfoot@classfun.cn>
2021-10-16 11:52:00 +08:00
41fd6c8733 add Innolux PD060JC DSI cmd mode panel
Signed-off-by: BigfootACA <bigfoot@classfun.cn>
2021-10-16 11:50:54 +08:00
09ad356800 arm64: dts: qcom: sdm845: Create sdm845-xiaomi-common.dtsi to avoid code duplication
WARNING: This commit is UNTESTED
It is yet to be tested by BigfootACA

Signed-off-by: Xilin Wu <strongtz@yeah.net>
2021-10-13 18:46:23 +08:00
77a9731666 drm/msm/dsi: rename dual DSI to bonded DSI
We are preparing to support two independent DSI hosts in the DSI/DPU
code. To remove possible confusion (as both configurations can be
referenced as dual DSI) let's rename old "dual DSI" (two DSI hosts
driving single device, with clocks being locked) to "bonded DSI".

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Link: https://lore.kernel.org/r/20210717124016.316020-2-dmitry.baryshkov@linaro.org
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
[DB: add one extra hunk added by one previous patches]
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-03 22:55:30 +08:00
Dmitry Baryshkov
87e518116b drm/msm/kms: drop set_encoder_mode callback
set_encoder_mode callback is completely unused now. Drop it from
msm_kms_func().

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Link: https://lore.kernel.org/r/20210717124016.316020-8-dmitry.baryshkov@linaro.org
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-03 22:20:54 +08:00
Dmitry Baryshkov
d41b589164 drm/msm/dsi: stop calling set_encoder_mode callback
None of the display drivers now implement set_encoder_mode callback.
Stop calling it from the modeset init code.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Link: https://lore.kernel.org/r/20210717124016.316020-7-dmitry.baryshkov@linaro.org
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-03 22:20:48 +08:00
Dmitry Baryshkov
2d4afdd483 drm/msm/dp: stop calling set_encoder_mode callback
None of the display drivers now implement set_encoder_mode callback.
Stop calling it from the modeset init code.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Link: https://lore.kernel.org/r/20210717124016.316020-6-dmitry.baryshkov@linaro.org
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-03 22:20:39 +08:00
Dmitry Baryshkov
a7ef6ef0be drm/msm/mdp5: move mdp5_encoder_set_intf_mode after msm_dsi_modeset_init
Move a call to mdp5_encoder_set_intf_mode() after
msm_dsi_modeset_init(), removing set_encoder_mode callback.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Link: https://lore.kernel.org/r/20210717124016.316020-5-dmitry.baryshkov@linaro.org
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-03 22:20:33 +08:00
Dmitry Baryshkov
22ccfe6b02 drm/msm/dpu: support setting up two independent DSI connectors
Move setting up encoders from set_encoder_mode to
_dpu_kms_initialize_dsi() / _dpu_kms_initialize_displayport(). This
allows us to support not only "single DSI" and "bonded DSI" but also "two
independent DSI" configurations. In future this would also help adding
support for multiple DP connectors.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Link: https://lore.kernel.org/r/20210717124016.316020-4-dmitry.baryshkov@linaro.org
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-03 22:20:28 +08:00
Dmitry Baryshkov
9ff1af8fa3 drm/msm/dsi: add three helper functions
Add three helper functions to be used by display drivers for setting up
encoders.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Link: https://lore.kernel.org/r/20210717124016.316020-3-dmitry.baryshkov@linaro.org
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
2021-10-03 22:20:21 +08:00
646a581efb arm64: dts: qcom: sdm845: Add support for AYN Odin
This commit adds support for AYN Odin based on the SDA845 SoC

Currently working features:
- dmesg output to bootloader preconfigured display
- UFS
- Synatics touchscreen
- Power button
- USB 3.0

Signed-off-by: Xilin Wu <strongtz@yeah.net>
2021-09-30 15:47:24 +08:00
cc076dcd93 Fix gpi-dma node conflicts 2021-09-30 15:24:33 +08:00
c9e0a49682 Merge branch 'mainline/linux-rolling-stable' into linux-rolling-stable
Signed-off-by: BigfootACA <bigfoot@classfun.cn>
2021-09-30 11:54:59 +08:00
f1882a5553 This is the 5.13.18 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmFDHL0ACgkQONu9yGCS
 aT5JmRAAvevbweEtpMpGPo9fhqv6T8xzKmiJZM4iJ8rb+J6/RA7qm6tls4w4kpbg
 w3xaVgYUERGxdbcOI/sI8DPBLttUXuJA+FWQoQ1dpKOtdn1KZTNAtB4h0Wq+tFE8
 IgHQ/PR7PmJtkz4BFkxXEuN0qlhZGnSQMXdMzbEVKuj62ZWjchZKQi80TvGuTAbj
 BuxIBapRkRVfFAxbxGEfx6fPWEvREM7kgmmFHCFB9X6YDPu63f7NljxgDsOQhoKE
 T9MCpSFKnjfMgYhlDziXbiAOMuIR7VVaA3iYdaG7bUI2xUBnwAmS/WPRiIGECmdb
 NynuTEhstKTlCTor5lomhKArkcITlzGJX/j8/BOnhD4fo1lTd0bWYGz3HfIIwPZ1
 jlLktCzGOUlhWzF08v+iFWUyMPN5pALef28k9fAzKJ1P65wzdZbklpiJznAwM7Tp
 6ALrWVt0+fmN2gl02TPY5e/gWYsNGgH8pMQuo3jcZe8R7ovMiFkeO3kyrgdU4esA
 xz5RhTi9POoAiGhoT6H6I7Hy/AYquda48Qq3uWfsrwHkZTSj4wgJAI0NaHaIiXk2
 kI7Kei7I+wiXvK176z7qgtQyCl/Zs8oSNckquUqcWBxRegSIMrpGCzmRQsWLqgiz
 21KJGDa2FS4IVf63H4SS2iPEMq5NitKWfFRRIA3GJMR/K0Wy3Qs=
 =H+l8
 -----END PGP SIGNATURE-----

Merge tag 'v5.13.18' into linux-rolling-stable

This is the 5.13.18 stable release

Signed-off-by: BigfootACA <bigfoot@classfun.cn>
2021-09-30 11:50:24 +08:00
c54c31e000 This is the 5.13.17 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmFBqEUACgkQONu9yGCS
 aT4+Ng//RI56RQ/XwlRBLM3Tv02a9+IaPG0o+Sb6DPWFTuw9pTVHjocIA4fpEQvB
 lP4xsOmg3X98IydDL9yC0K8KFMdafzpCMrQeMlBc1uC2GVYRGUWfyr7yKnQh3AOB
 E+fSbFiC0gJCT1/jiXbviyNu8+VCzztJtqtjjrc4rxduLqqQPgOHVxJo1m3HgQTZ
 fkLYOWDBeCc2mRExgwJG7gqISYj3yUA15PNV9TbXznD4o/AfRHtjIh3yBNyVJ4nf
 68oTtySvICq14I3ApjFx0fU3/fd9lSs+F3GwGbxbmtxkmZAuH5JD2v0fbQ3m62y6
 ysWkwjfdjom9UCmSNG3/N7V6vChxFbDpKCzg1hOsG0qJOO9ZIInaqwgU+Tu3qhvD
 E6ADNIHJ84dulIrPM7QBRY/cpNo3TEkyAnFrSxDUpQFRRHdsRgWdieLzEDn1FBkM
 GWfaUylty7RURq2rN6svMwDxJEmTwZS+HVCmoIVNHMy26LrZehjgHYxKeAc06nYp
 MoxDzj84RxYbrnRSgBKOMZwG1rLUCuuoia3qFG8j2lZKxMXwNNQMrTghzKKrBE+2
 IpqsDDxDrjNKsV4loz3wSrFRUN0hVRsY7qXLCf9xBaejYzBz8E7dsJZLfJtO6Jdb
 VAZYonHIAxRR2Zzyu4Y8LNd0V72HNnrEOCcokLictdmE3oap5Gw=
 =gG10
 -----END PGP SIGNATURE-----

Merge tag 'v5.13.17' into linux-rolling-stable

This is the 5.13.17 stable release

Signed-off-by: BigfootACA <bigfoot@classfun.cn>
2021-09-30 11:50:15 +08:00
f3a6d411ac This is the 5.13.16 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmE9pXcACgkQONu9yGCS
 aT7aNA//axqwLO2TpAVCryfFTduvdnQDy9nNjzRlR48VB/MNhJkf8YfbWyWQDelS
 9ZxQZ4CYHjag0F/Cp7Hfd6GrXZpYcdxDhnQ9QTS2krF24WnfwtMeVMQQBJ+3j1D5
 oSPmUNI7ONsXTcfocSvSP+GXxZTWIv6Bk5eAyQ6UtMXGvxBAGT43zn/STcYbGAgh
 zUz+l++qzHG/uR19oyVWpx4bPDw5Q5Nlz/bfRg7cMLNGHNbWOsjne4CujAE2kEUU
 dF/ouaEtSOyHwzgCLseCDsissd+xJItk3w6Ew7D1yDkxFaixB7ee/Llb8SDHxveo
 EKlKW9XXq8ETXkezjnrdasXi/z8kUDPp7gz/LNSbksYtzpcpBaSHpONlwRrW70m6
 xRdE+LOGgk8jCOWgHlBNOfCvUXOnTUhlH7CdY5TzWiG50jXA19JLMucMa9yErYEU
 dEr0yp4S6Ucc2NDcdHfeLkF/yxjQkFs3PlMUPNvhTgxpN2uk+PvOS4OzULdyTCzy
 mEV9xM/Wd+uXshATSOGRuudeo8ysg2+uhVvC7WaYv4dfU71o1hcGVsYUL1k7T/lH
 NsJ+cQZUHs4aXY4C9kOxC0pfq6lcHgXZ6A5rs7O00iuPwqEy2sP9ejjbl2MOIZ8R
 Yd56vjkYHkyTQWA8Dzk5q6UV/FbPd+L/iIO9aS0s54xQmTxTkn4=
 =Hwtx
 -----END PGP SIGNATURE-----

Merge tag 'v5.13.16' into linux-rolling-stable

This is the 5.13.16 stable release

Signed-off-by: BigfootACA <bigfoot@classfun.cn>
2021-09-30 11:50:09 +08:00
e57cca91c4 This is the 5.13.15 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmE4XXUACgkQONu9yGCS
 aT4xbg//Re1CdehMKx7DQQyHiVfQ+Em4+qlr6eQr9mMDQOUb/IJbG7+0ufiWF5ug
 UhG1M9jA/Y6FK9XnmPvArTgOqahoP3B0TiKfhnK53tOSlZMy5yAs81uyMI0Vs6RA
 VePIi5vwjcuJfwwjHRd+Kh2RW3adkswAIr0aRaFlpg24Dv3kZhlEDsvGu7uoOCD6
 Bcw+dWg7iMy5L44eaKjoTfJcBhxaGVCgqY75XAje8QbJ/nx+QkyZl34iw8DlhVih
 VcsW+kWydHYrBcN1jQ6PPDrWUIq1HBXlEukErXarNWwt7rwfkpdYn2NytUSb8Sjk
 rUeSOAsKQrwSf8wqXBXiOfKvgLZPQa0h7/TxUOvHGJJOjg3cirZmBdpFH3xYD7FI
 TN/VgqZbHnDTh4C66NP4teGwIuPAnMUSNIvgrM2lXuTZa57on3OTwYWzSjdRqynY
 BnieAMfBUNPWrXIUJXjjm8FuqrpwD5bSOvpM/BbrEpWPg+b9nWPoh+Iho3Qtyr2V
 rYeeBswQCgYJLDIzCoTM653zqW7YLZu2H4D5ygcYp0IcdUEU2LXbGDJQ5kmuzUp7
 9nrbONlaWvnkEi768pG6YrmxkgpvvIRxWWXroFahfYjPMA+cuWLzu6B7g4jQhOPw
 hySg9EiFA9SKIohO/qyYzsXPq8Rl+zItHdhLnONZYvzGfHEHnVw=
 =Rnyr
 -----END PGP SIGNATURE-----

Merge tag 'v5.13.15' into linux-rolling-stable

This is the 5.13.15 stable release

Signed-off-by: BigfootACA <bigfoot@classfun.cn>
2021-09-30 11:49:56 +08:00
0c928e5c95 This is the 5.13.14 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmEx3LoACgkQONu9yGCS
 aT7k6A//f6bfwNQy1hDjm3bmX3hrKBJuzHKaypLRJcB7q6UMFRxN47lSIdHdESLa
 gwtTDOoJOXTL3gR2i8+aOjew0Z8ceyrkiqditC0vnaU4LInV58cDDFA1JekmSn2X
 Iv56UYTi/itygs75E0lX9BbE8nUBWBNQ77LFCi3iUKqgT7anxtnn3TJ7pl916cIO
 IyOYAyyLnQVmlKzox54Nmz9BGD4Jn6ef2c6sqYePqbszD2sYQI6P9ankwS6p0PgG
 6RXqh7b4zJE96XH8LpBAKfd+9vO8yOMeKAVGShLIbYJu/I595ARhj21dOSPw6avt
 3QQjb8dyhVf1b9L24IDT+MXrfCvKxY3eAY2tsZRC2NERHhtpUFq7Mn4CeDMHqwQ/
 TJkY2p9ZfLD1U+rmCObfY6bjAiUJoDEmP4X08Tq0Md4QX8IgGefvvqIFKTPc0OaC
 UXuL5o4noZmgRADUba2dDoR0u3QGPcg8PZ6m6rd6blWijcDeBgE08aKqrTbGGiee
 B5osM4KuhWFqp/nGRiAtqGHXxhGl6iz1f+7SVzgvyprwIRRfWNh69VQrG+HeD62Z
 b43VaCoTgpbQI1+ekQbudE9RY6RpMYlGiaVlEWm6n2NWgL843hyeoEQY5B+kSSJW
 5VCu5hdV1oph6Yeypt8hur6AKhnO6QothdxcH8VALAmVPD06iuY=
 =7fp1
 -----END PGP SIGNATURE-----

Merge tag 'v5.13.14' into linux-rolling-stable

This is the 5.13.14 stable release

Signed-off-by: BigfootACA <bigfoot@classfun.cn>
2021-09-30 11:49:50 +08:00
5ae80018b8 Linux 5.13.13
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEE4n5dijQDou9mhzu83qZv95d3LNwFAmEnjhYACgkQ3qZv95d3
 LNyQig/8DC76FNZ+LJbh5zv4mpvS301Vuk4xqxmGiDnPpbglYYCdE9nl4GcgPIoM
 zNvMLeVXWnMrq8K84KskqdGJoPhpH197yU/lbirWIfGORHOvUoJCKSxXA1T6yFWX
 GCf34YxtHaxPH3Olt1FIm/VwM/KsS+Rp9/Am85kc2Ramv0/f3ZIkKrQ/UVkno8IE
 gC4M/HKOafox+GJ7lLlU/4FL7dVCTtnFsaDv7eUczrPE8WBtV1I9pef/EvHiD+j7
 DA6wcCh/mtgOijwnHMRnlHlDQKH52pIVBZks6WwjxpbEmDtVOvLHUPw0QZSy6ZYw
 4w0jwU3rkvnEw5sy/z7s1y3R5NBEUx1UT0Ze7fqn7qRKEIGdb1g9NLl3gYy5w1Ew
 yApRuhNMY0sKPPahtyz8vFUTxiMDSpg8AfaXZOAJArCqXw3acgNmLQLcd9nLHCQq
 DiB9+PIwoux/Q4LLC/0pMnF7K82EecWZ159fTAYwtxZ+EpJWF5BYwODh39jZM6Qz
 kreOkSPMufu3xYSLT7Vjt5ol+yjYvMPKrGkNsw+VemZ6rxgiH/RGUiGcSdc1v7eG
 LnpObqLB3bTRSGgVTqIOloRiEQHJVsuD/5eYd4BKp09n0K2f4W5jJOSANpNoB+C0
 lIry4ZCQr/Ap28vnjoyahFcMfiHiKaAO3Wqfgb8v4odNxujcXo0=
 =Pxf/
 -----END PGP SIGNATURE-----

Merge tag 'v5.13.13' into linux-rolling-stable

Linux 5.13.13

Signed-off-by: BigfootACA <bigfoot@classfun.cn>
2021-09-30 11:49:44 +08:00
4910387f8b This is the 5.13.12 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmEcsbYACgkQONu9yGCS
 aT76VhAA0DYQgKRXfgBW7G4aI5klmahaGq0xCf/yJy/agSytU4Z+aYSXWQRCnL3v
 52kI17O6XhwsTk1Zj9S6TX0sU7fo4SvF5P9Ee6G4N321P+Mp1atmDmTCutcmHrFx
 19j5b1jLyQ21MrU7t2wHK1zMoNzJzNOYjHRLBqYRsxt/GZM3KDvFRo3aL0w7Sr5V
 JynC9ZKKeh/0d/loF/St0Z6aWi3HtRRGZDgPdXM/M/D07ePapIXDdrlT7jkxIbAs
 b5h0X35PV2t+P+ooGDtaoIWXCLhg3/hH69b4WESj5hyYU0TxvRdHVe5/MQC0/hOY
 FQhu/JX+y/x5SsgUJiUz9gV52WPp0B3pK3t3RGoiV6vI92A4J0lppP7UsY0eeNyd
 O26ys1of/4dk2CNsVcCFCaBBtasjVMgppDM7JciFu+BqkQv9MSeMqvqw6zgxFYff
 oklpEnTrb8Jc9BcyqKNgqIG0DTclVnb0VugiTp+Ta0DHTiqwysHWx5TatbPbXKsr
 FLPnSRljDReqDnQz5nITvcGJXedZP0fslStgEp7n+Kpa4lj7WkQPiJZjT3i+cSTl
 lQjtuH8jz7eb3L7zuq7cymByOfKH4EwEXtwwTvaUgh32kEt4Hjk+tpwDtnerdLll
 O51D7IGM0ZsdYBMtmsaOHwafrsuw5uduTCokRu5D/73nM3u2jgw=
 =qn7/
 -----END PGP SIGNATURE-----

Merge tag 'v5.13.12' into linux-rolling-stable

This is the 5.13.12 stable release

Signed-off-by: BigfootACA <bigfoot@classfun.cn>
2021-09-30 11:49:38 +08:00
bf3b626cc3 This is the 5.13.11 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmEZAkYACgkQONu9yGCS
 aT7XLA//fSkhH1BxJhUTiIRCwd1jv0Y5kvzPQmjaRu5t5VUWd/46A4sqy824DM67
 eeNYVNzwQ0DwwhU+IyVgMLcvShMiaPhiNBTzeU+izfsaCMrKp2svqiCkBuedBMKG
 20rhKwUtFHH8OcbfyO44RshqDcOa7s+37hHB+k83DF5wns1PP3t3nAvDuAFFd2i7
 pjjSiZNUYgKqozq0F1LEIQZauvDuU1jejmBde9uEAx1jTKBCye3jEN/HzE/d50qh
 r+8MJftGB6YhVLsMA6V3C/WrqFbVHjZSCRC2M2cvUK2yx/bDrrZ73Igw5n3LCe9/
 smXuqGFFnbTkleUlHg+mSUfzG3GxNWr7NRZjRJGGts2QbofgI3LfTKWodblIFr98
 fvl03OhV+blKcMSzntYoKokYr87d1SB+/+MAtnVklpdygvUHgVQZGxQ/wgQPezso
 7voW+/pDbWUBXuBwmio1L2dulKII/rokyFxdKoRxapjHhoVLXoc/kfNvZni7gHOH
 pqQVjeOGLvcspsFWKNqe8YgaJZNzhBpd8IKXuzH6LLBXqgo1KtP9pobELna9irdx
 skkJqsZozyotzbRsJgVyqB3/9GUDDJuB/zDl7gi3ocxMEYDfSRUrfbBUEvnWFxi+
 fQ55AfM+g/9KNr4jly3R9PITF5Y3v2DgL+Uiamxs7KqboemWmOc=
 =wzEN
 -----END PGP SIGNATURE-----

Merge tag 'v5.13.11' into linux-rolling-stable

This is the 5.13.11 stable release

Signed-off-by: BigfootACA <bigfoot@classfun.cn>
2021-09-30 11:49:34 +08:00
eda41a0e39 This is the 5.13.10 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmEVBtEACgkQONu9yGCS
 aT7irw//eyysdC7LRlKLZ+w5MSy5jqlMmE6aQPagghojnUMGLhfTBQw7kt6EsQ9k
 goHmM/itzPwhFm5MWou+0T4pFCaxKBLIQ5nhPWJZUnFZOqKmvQTVVsS2GClmQ/MC
 Dq8OcjeE1lpBIZmR98QFJC2sTCA6+vrXiwej3J+pYbe8BIjdclvT7ogGEDFvmq6G
 CT7bULQIhc3E3Bsnk8aTzKHmSCg0ZpqcDTbNcD3DsRhVU7l9gdtKAvc5SQ/9R7pp
 9FBc7DBsm7bA3Dq1obZOA0cJoWtO1Fd7J+PXYLf7u0K0rYYM8L4fEJD2vPSaZzzM
 9J12ba+Rd2rcssfvMhHkgbrRynduFLk/kyrotSv5H/wFb8xDhHSyI2z1neKaqqW2
 2PJUSh4h/D/VDJVBAaUs1uzsOiUT2Y4AkA4s2dWK7C8irOyp8TbxxlPs6s7IgXyE
 O2ry6jx4mufkdNyKw3eK0hloOmFGIBZ9buzo9HQsngGDs0cruIMKxvY+16HLSd7p
 8kn5ga52kApetXVeI4ujr/C+iK9JrkEanVGu2m1KdQScKDO6OjZQEP4rm0/R7mxh
 IBsS+rVpQQJqHCTN+ohb/zZ27map3UtUEU+cIA1lFfiUyBAC6xu7BNmiR8NoV3Uv
 Ei+Imgsjp04Zc9SmQaibX273Ld4nwqeyzSncLZQoUot9a3v5smM=
 =3iE8
 -----END PGP SIGNATURE-----

Merge tag 'v5.13.10' into linux-rolling-stable

This is the 5.13.10 stable release

Signed-off-by: BigfootACA <bigfoot@classfun.cn>
2021-09-30 11:49:27 +08:00
1367edea57 This is the 5.13.9 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmEPgpYACgkQONu9yGCS
 aT7r6g/+Nd5Lnv6LkuNoKqyVxZ/Z3/CpZoWTYJHlFE84AmNN5WIXae1NTlPeCy+A
 +Kse0TtsXNAzgJw3VQmsy6xteELUAG4BOLKpbKeMGSgrf6a/IsBf7uzSSOJHLrzH
 yKyg8sJizyK95uPPNBPaQ8nCo6xYeNs/1i351ndW1tGF6ONXDkamUZwLpTOKHHjW
 FXAUu86YcVyH3+1pMZqGhPfZbT2tgVf7YMhp9ME++Sg4MCBjZwaXoTX1tF3c//yl
 u3xyDEjFhabAX4x/uGXJ/2XbJBelw8m8fNswH9w3wTQ7KKllaDzZ/UJDpa56h/38
 pB1JwB19kmIfSZNZp9gFXxGbm/J6ZUY7kk5Rk09MxgFiZFjJZGoT+ZBa7PL4D4/4
 ggP3lKtj+u5NGg/E9BaRNjldktu1O36ATaN61iY3SQ+UMcnqLqYvTHD7Px3FLD8r
 WYGyuDpbrLSFFOq9LbRvLfCTKeLmr/meirneTPURx/FlL8cbGkoN6H1dNlflhvFe
 LXXGcnZO64lyQMo3f/eMRaZgy+UIR9RgxvZGhEZXr/IepgaMW1JcUKgBC+9utkp2
 Fa2Ktm3C0UXC1U9+QY0uWGw9BdsQYbMTbcQg+UhibUVwN/4x7C3pnhGLLyAqRNn9
 MVmXubpeUn2TjD5ReIlaxClOl1kU5K5UcBYrxbA8Q0DyqO2QAPc=
 =XnZO
 -----END PGP SIGNATURE-----

Merge tag 'v5.13.9' into linux-rolling-stable

This is the 5.13.9 stable release

Signed-off-by: BigfootACA <bigfoot@classfun.cn>
2021-09-30 11:48:54 +08:00
85e535558d This is the 5.13.8 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmEKcGkACgkQONu9yGCS
 aT5wSBAArP7gE7uhR0i66USsd7Csfb4+M90DZ0HRej86ao4llFa7dRst/b3EEJdM
 0zeaZFRGGte/dRKOoOWOUPKD1L4qnxltgTT7+6YtL4Yw+Sj3apA+2Gt/Z+t6WL2l
 Oo7kCzfPhl6wo4YWt4rDk6hLQOKMh3xWlOQ2tlZ0tv8xReNC/IziMTWqrJWWLJHW
 3sPJGUiL5DO/6IXwBu48232I5OWl1aCB+BBcdKOWq5cIQjkVMW9Jy4T17ZqmaKbC
 M5hqI7n/TbBsldTRUYNkucv+bHvflwSFVAW9azCHDAMHY+3v+/6ixZ0sAJWCWZ+M
 XteWN5vZAJCZ2XIPgtZ/AZGQaB/dtUOV6j/T6EWrIL7Ten4InBQmQjn/UOCP/ebT
 6SrO3dScuwiF/vqSYSzLBSEGW531HrApX6IR1JmtW4QZ02WASuH2Cl8G/YFjvMkj
 JdPTI5t5hyzQIinsWtaFVupj8k7H3E/q6u1G2cvFsEIV1uJuOVujavEELQMTNAmx
 8+/INIWeqeHR/3zhTO1SVIlPnKiMjrGUz0N6I9yF4HAg8UzWsZgQ2DF40xq40V0m
 ePb+27x0YJya4SfJ1Z6EkedEQ0Qqm93ku50HR07I0641tvLBoqXt9PPlsj5mrQAP
 xUCzbYEzhQQBd6Jp6qg7flT3YxGFljff4Ww50rIq+uaDXO8ITXg=
 =5c+e
 -----END PGP SIGNATURE-----

Merge tag 'v5.13.8' into linux-rolling-stable

This is the 5.13.8 stable release

Signed-off-by: BigfootACA <bigfoot@classfun.cn>
2021-09-30 11:48:46 +08:00
c6637b12dd This is the 5.13.7 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmEE6iwACgkQONu9yGCS
 aT53qQ//dpVsphi5ycqUVB742vYxNqsa/Lx1gdAfFLobxPbcnhed4YrZGcbgyq3U
 m1NpVg/JDXL8DqN/Sqd9Vullow24XVJHd/rr2FEgRcIpb2DbyF3N47zCFIEIAzAT
 DOkzBk052NJdWMdZDgZkeAkaLGI4KnLaeTLCwDMVYE7zzL2t+L4aUaIFhE8mK9wB
 tIvqk47huLWPJ3je9Wst84YeajRmwGJ9J1s2togckzIDoK37nUDupeLYISfwqWp5
 mm1vBWMj7N3JGunz68ULtcLkgmP9pP/OIIJl/p8o8iVvnL1AoOA1SVrVFOEsXbv2
 nMAztQfit24AqbxcBvAcTcHfayuP1t6Yj2N6xeNrsipvYs2QX2B/oiiRnl9EuQsv
 zLS0Z0A04NHIFsq73QPx9XRjXaXON6s1LM5tWtgKnZMirPOxU+FVfZzB1zBj1owy
 ejj8LBmNz6Ie55i95FxgxC+NtNv3nE4OJfflnCjDpOTsTFO3sb+3U6KeB0r0K8pL
 fJaIbBvceP7tfk7A3BhUCpQ9Vipnx65iycD44+sOTJKwNqXG36EXmN0OIoA6H7ru
 YzDlg7jo4ANOmS61TFgQ19JzUN2NXUxMRFwBWA5viJvMRWoGXwk0rIUrcDeOx5yj
 Uy0qUfSwA6UFLZDqc9HlMzD/1kMXwdxsqv91/HPl4k05WvEnQ2Q=
 =X+Ov
 -----END PGP SIGNATURE-----

Merge tag 'v5.13.7' into linux-rolling-stable

This is the 5.13.7 stable release

Signed-off-by: BigfootACA <bigfoot@classfun.cn>
2021-09-30 11:48:32 +08:00
8560331d1a This is the 5.13.6 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmEBUFMACgkQONu9yGCS
 aT6UVw//bTkipihT/4NEX1oVNwUKnjRO6mJ1FUcWJzfiSZlDVLP8gi5FNWQ1Y0XL
 TEuZmIzxq2nZMwMC+VldE1fBDJ/hT8NOK4FUWz9e64qdrodttubEFtsFRbLdou7B
 nynYFxbPlcEHLj3MQ7SLir93H4B2D1RpSrzXEISrqQvyWE4gtObo2VKesvfioIKP
 RPNwntDjynJt7jtFFTNqlWpBb26L0RG3rpQlxZmB53g4u6LKg9MT6Kcwndx9G903
 uIEn8TXJshDJZP8ZQ9V/vi6DvFprsChC+6m90x0NmwqO35nQ6WewmOM4n3rXkPX5
 NrKf4mS1OK3DEkUUuEXwj/15ll5hIh1lyRTApeoY9H6sLTFo6/8EIEh4hpRed9Aa
 GlYblzeXuEJ7nwtMTFZWqqJLLjltd981rPxw1v6tyRs0GBgrnt7ggJdCs7azRRQQ
 ueM/bIqPCVisvno6FyWEIM/TrngYnWGv10y2mQN6f0xDVpyk97A9sejXB0Vd124K
 +eVStH74ixPdK+ChITelAQoVIKgcIw4x3U3TvQrT0deyx3kx+R6rbwdfV41zdq8P
 vlBpWQ8xnp3UQEEsvNnGH7sFXvJvIJUUNBPy/aRRyNXfqrbSaE+i9DzFZkyNhNoP
 CYskgxieIZvz+ahD7oDH6ul9AapjiaJhB8qDNPXcdU09tFoV0q0=
 =LzFp
 -----END PGP SIGNATURE-----

Merge tag 'v5.13.6' into linux-rolling-stable

This is the 5.13.6 stable release

Signed-off-by: BigfootACA <bigfoot@classfun.cn>
2021-09-30 11:47:05 +08:00
Sasha Levin
de7659ca66 This is the 5.14.8 stable release
-----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmFQZD4ACgkQONu9yGCS
 aT7Qtg/9EWfDNt36lDNLeToHu7tBI8+4q007xnAhTSTLnMwWPBCOpDmupMvgXc+2
 HbECAOGgynpU/qGwqZL1p80n8FzZkbn+IJxK9aOYGsTNhw1IkZsKn6Z5FoKAXirZ
 wDT/a0mRbp836j8u8vCLlb5FEXceuZ2FHNJSpz/P9rLavghaYYnMfNxmT7TUM7G0
 LaW+MFtzSn1xUhERuRa8ndzfbUN0dl+mVO9ZhP0TnYOuIvUgVgLANLH4KK+cTx7A
 6kjJ04iUPwyTaKU5oou1c8vyUkgSMXSi+6FhV9/HYzeTOXADpxdVZCRHJYLBnwb3
 MOxF2Q6Xyo8+u8SutZHGkshUQvdNWR2TmGIyHGDGm63w+E6BFLv5nt1vSJ4IVCzz
 /goHNnFKYZdABPx4WzkCcjQ2Nt09o7V94FizLoZzYKbChTyy93RrYGjBHEcKQP54
 SiByu0dzgGsNltjT8GFG04XJH5umjqUYAqBphYQxbnhIgsySPwA7szXiLGvcUrPG
 A+AUMXDcIPw/qi+RwHFvxIGN83dpjpYpdmLhcqWeH54Xd+G1P0LGpgWldCFLpZ+s
 wpp1xAvU+A31+AhppTAop0ntex41rDS1sluaSnqW8oKy2OTfWk0S54Z4RG+o7SlD
 F/OS3yzYqXxTUR8zs8wzwh6qTeeNtU6PoiSBEdFalWKshk+tT04=
 =/qdq
 -----END PGP SIGNATURE-----

Merge v5.14.8

Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-26 14:10:25 +02:00
Greg Kroah-Hartman
c34892e199 Linux 5.14.8
Link: https://lore.kernel.org/r/20210924124341.214446495@linuxfoundation.org
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Fox Chen <foxhlchen@gmail.com>
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
Tested-by: Salvatore Bonaccorso <carnil@debian.org>
Link: https://lore.kernel.org/r/20210925120755.238551529@linuxfoundation.org
Tested-by: Fox Chen <foxhlchen@gmail.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Rudi Heitbaum <rudi@heitbaum.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-26 14:10:25 +02:00
Guenter Roeck
1236431c85 drm/nouveau/nvkm: Replace -ENOSYS with -ENODEV
commit e8f71f89236ef82d449991bfbc237e3cb6ea584f upstream.

nvkm test builds fail with the following error.

  drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c: In function 'nvkm_control_mthd_pstate_info':
  drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c:60:35: error: overflow in conversion from 'int' to '__s8' {aka 'signed char'} changes value from '-251' to '5'

The code builds on most architectures, but fails on parisc where ENOSYS
is defined as 251.

Replace the error code with -ENODEV (-19).  The actual error code does
not really matter and is not passed to userspace - it just has to be
negative.

Fixes: 7238eca4cf ("drm/nouveau: expose pstate selection per-power source in sysfs")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-26 14:10:25 +02:00
Paul Moore
bef2b32a14 selinux,smack: fix subjective/objective credential use mixups
commit a3727a8bac0a9e77c70820655fd8715523ba3db7 upstream.

Jann Horn reported a problem with commit eb1231f73c ("selinux:
clarify task subjective and objective credentials") where some LSM
hooks were attempting to access the subjective credentials of a task
other than the current task.  Generally speaking, it is not safe to
access another task's subjective credentials and doing so can cause
a number of problems.

Further, while looking into the problem, I realized that Smack was
suffering from a similar problem brought about by a similar commit
1fb057dcde ("smack: differentiate between subjective and objective
task credentials").

This patch addresses this problem by restoring the use of the task's
objective credentials in those cases where the task is other than the
current executing task.  Not only does this resolve the problem
reported by Jann, it is arguably the correct thing to do in these
cases.

Cc: stable@vger.kernel.org
Fixes: eb1231f73c ("selinux: clarify task subjective and objective credentials")
Fixes: 1fb057dcde ("smack: differentiate between subjective and objective task credentials")
Reported-by: Jann Horn <jannh@google.com>
Acked-by: Eric W. Biederman <ebiederm@xmission.com>
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-26 14:10:25 +02:00
Hao Xu
dcd45a08b9 io_uring: fix off-by-one in BUILD_BUG_ON check of __REQ_F_LAST_BIT
[ Upstream commit 32c2d33e0b7c4ea53284d5d9435dd022b582c8cf ]

Build check of __REQ_F_LAST_BIT should be larger than, not equal or larger
than. It's perfectly valid to have __REQ_F_LAST_BIT be 32, as that means
that the last valid bit is 31 which does fit in the type.

Signed-off-by: Hao Xu <haoxu@linux.alibaba.com>
Link: https://lore.kernel.org/r/20210907032243.114190-1-haoxu@linux.alibaba.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-26 14:10:25 +02:00
Enzo Matsumiya
d1217e40d0 cifs: properly invalidate cached root handle when closing it
[ Upstream commit 9351590f51cdda49d0265932a37f099950998504 ]

Cached root file was not being completely invalidated sometimes.

Reproducing:
- With a DFS share with 2 targets, one disabled and one enabled
- start some I/O on the mount
  # while true; do ls /mnt/dfs; done
- at the same time, disable the enabled target and enable the disabled
  one
- wait for DFS cache to expire
- on reconnect, the previous cached root handle should be invalid, but
  open_cached_dir_by_dentry() will still try to use it, but throws a
  use-after-free warning (kref_get())

Make smb2_close_cached_fid() invalidate all fields every time, but only
send an SMB2_close() when the entry is still valid.

Signed-off-by: Enzo Matsumiya <ematsumiya@suse.de>
Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-26 14:10:25 +02:00
Sebastian Andrzej Siewior
cacfce79af sched/idle: Make the idle timer expire in hard interrupt context
[ Upstream commit 9848417926353daa59d2b05eb26e185063dbac6e ]

The intel powerclamp driver will setup a per-CPU worker with RT
priority. The worker will then invoke play_idle() in which it remains in
the idle poll loop until it is stopped by the timer it started earlier.

That timer needs to expire in hard interrupt context on PREEMPT_RT.
Otherwise the timer will expire in ksoftirqd as a SOFT timer but that task
won't be scheduled on the CPU because its priority is lower than the
priority of the worker which is in the idle loop.

Always expire the idle timer in hard interrupt context.

Reported-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20210906113034.jgfxrjdvxnjqgtmc@linutronix.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-26 14:10:25 +02:00
Yu-Tung Chang
affd236df3 rtc: rx8010: select REGMAP_I2C
[ Upstream commit 0c45d3e24ef3d3d87c5e0077b8f38d1372af7176 ]

The rtc-rx8010 uses the I2C regmap but doesn't select it in Kconfig so
depending on the configuration the build may fail. Fix it.

Signed-off-by: Yu-Tung Chang <mtwget@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20210830052532.40356-1-mtwget@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-26 14:10:25 +02:00
Song Liu
46384252a8 blk-mq: allow 4x BLK_MAX_REQUEST_COUNT at blk_plug for multiple_queues
[ Upstream commit 7f2a6a69f7ced6db8220298e0497cf60482a9d4b ]

Limiting number of request to BLK_MAX_REQUEST_COUNT at blk_plug hurts
performance for large md arrays. [1] shows resync speed of md array drops
for md array with more than 16 HDDs.

Fix this by allowing more request at plug queue. The multiple_queue flag
is used to only apply higher limit to multiple queue cases.

[1] https://lore.kernel.org/linux-raid/CAFDAVznS71BXW8Jxv6k9dXc2iR3ysX3iZRBww_rzA8WifBFxGg@mail.gmail.com/
Tested-by: Marcin Wanat <marcin.wanat@gmail.com>
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-26 14:10:25 +02:00
Li Jinlin
a3330c1c83 blk-throttle: fix UAF by deleteing timer in blk_throtl_exit()
[ Upstream commit 884f0e84f1e3195b801319c8ec3d5774e9bf2710 ]

The pending timer has been set up in blk_throtl_init(). However, the
timer is not deleted in blk_throtl_exit(). This means that the timer
handler may still be running after freeing the timer, which would
result in a use-after-free.

Fix by calling del_timer_sync() to delete the timer in blk_throtl_exit().

Signed-off-by: Li Jinlin <lijinlin3@huawei.com>
Link: https://lore.kernel.org/r/20210907121242.2885564-1-lijinlin3@huawei.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-26 14:10:24 +02:00
Tetsuo Handa
2ab96bfe32 block: genhd: don't call blkdev_show() with major_names_lock held
[ Upstream commit dfbb3409b27fa42b96f5727a80d3ceb6a8663991 ]

If CONFIG_BLK_DEV_LOOP && CONFIG_MTD (at least; there might be other
combinations), lockdep complains circular locking dependency at
__loop_clr_fd(), for major_names_lock serves as a locking dependency
aggregating hub across multiple block modules.

 ======================================================
 WARNING: possible circular locking dependency detected
 5.14.0+ #757 Tainted: G            E
 ------------------------------------------------------
 systemd-udevd/7568 is trying to acquire lock:
 ffff88800f334d48 ((wq_completion)loop0){+.+.}-{0:0}, at: flush_workqueue+0x70/0x560

 but task is already holding lock:
 ffff888014a7d4a0 (&lo->lo_mutex){+.+.}-{3:3}, at: __loop_clr_fd+0x4d/0x400 [loop]

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -> #6 (&lo->lo_mutex){+.+.}-{3:3}:
        lock_acquire+0xbe/0x1f0
        __mutex_lock_common+0xb6/0xe10
        mutex_lock_killable_nested+0x17/0x20
        lo_open+0x23/0x50 [loop]
        blkdev_get_by_dev+0x199/0x540
        blkdev_open+0x58/0x90
        do_dentry_open+0x144/0x3a0
        path_openat+0xa57/0xda0
        do_filp_open+0x9f/0x140
        do_sys_openat2+0x71/0x150
        __x64_sys_openat+0x78/0xa0
        do_syscall_64+0x3d/0xb0
        entry_SYSCALL_64_after_hwframe+0x44/0xae

 -> #5 (&disk->open_mutex){+.+.}-{3:3}:
        lock_acquire+0xbe/0x1f0
        __mutex_lock_common+0xb6/0xe10
        mutex_lock_nested+0x17/0x20
        bd_register_pending_holders+0x20/0x100
        device_add_disk+0x1ae/0x390
        loop_add+0x29c/0x2d0 [loop]
        blk_request_module+0x5a/0xb0
        blkdev_get_no_open+0x27/0xa0
        blkdev_get_by_dev+0x5f/0x540
        blkdev_open+0x58/0x90
        do_dentry_open+0x144/0x3a0
        path_openat+0xa57/0xda0
        do_filp_open+0x9f/0x140
        do_sys_openat2+0x71/0x150
        __x64_sys_openat+0x78/0xa0
        do_syscall_64+0x3d/0xb0
        entry_SYSCALL_64_after_hwframe+0x44/0xae

 -> #4 (major_names_lock){+.+.}-{3:3}:
        lock_acquire+0xbe/0x1f0
        __mutex_lock_common+0xb6/0xe10
        mutex_lock_nested+0x17/0x20
        blkdev_show+0x19/0x80
        devinfo_show+0x52/0x60
        seq_read_iter+0x2d5/0x3e0
        proc_reg_read_iter+0x41/0x80
        vfs_read+0x2ac/0x330
        ksys_read+0x6b/0xd0
        do_syscall_64+0x3d/0xb0
        entry_SYSCALL_64_after_hwframe+0x44/0xae

 -> #3 (&p->lock){+.+.}-{3:3}:
        lock_acquire+0xbe/0x1f0
        __mutex_lock_common+0xb6/0xe10
        mutex_lock_nested+0x17/0x20
        seq_read_iter+0x37/0x3e0
        generic_file_splice_read+0xf3/0x170
        splice_direct_to_actor+0x14e/0x350
        do_splice_direct+0x84/0xd0
        do_sendfile+0x263/0x430
        __se_sys_sendfile64+0x96/0xc0
        do_syscall_64+0x3d/0xb0
        entry_SYSCALL_64_after_hwframe+0x44/0xae

 -> #2 (sb_writers#3){.+.+}-{0:0}:
        lock_acquire+0xbe/0x1f0
        lo_write_bvec+0x96/0x280 [loop]
        loop_process_work+0xa68/0xc10 [loop]
        process_one_work+0x293/0x480
        worker_thread+0x23d/0x4b0
        kthread+0x163/0x180
        ret_from_fork+0x1f/0x30

 -> #1 ((work_completion)(&lo->rootcg_work)){+.+.}-{0:0}:
        lock_acquire+0xbe/0x1f0
        process_one_work+0x280/0x480
        worker_thread+0x23d/0x4b0
        kthread+0x163/0x180
        ret_from_fork+0x1f/0x30

 -> #0 ((wq_completion)loop0){+.+.}-{0:0}:
        validate_chain+0x1f0d/0x33e0
        __lock_acquire+0x92d/0x1030
        lock_acquire+0xbe/0x1f0
        flush_workqueue+0x8c/0x560
        drain_workqueue+0x80/0x140
        destroy_workqueue+0x47/0x4f0
        __loop_clr_fd+0xb4/0x400 [loop]
        blkdev_put+0x14a/0x1d0
        blkdev_close+0x1c/0x20
        __fput+0xfd/0x220
        task_work_run+0x69/0xc0
        exit_to_user_mode_prepare+0x1ce/0x1f0
        syscall_exit_to_user_mode+0x26/0x60
        do_syscall_64+0x4c/0xb0
        entry_SYSCALL_64_after_hwframe+0x44/0xae

 other info that might help us debug this:

 Chain exists of:
   (wq_completion)loop0 --> &disk->open_mutex --> &lo->lo_mutex

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(&lo->lo_mutex);
                                lock(&disk->open_mutex);
                                lock(&lo->lo_mutex);
   lock((wq_completion)loop0);

  *** DEADLOCK ***

 2 locks held by systemd-udevd/7568:
  #0: ffff888012554128 (&disk->open_mutex){+.+.}-{3:3}, at: blkdev_put+0x4c/0x1d0
  #1: ffff888014a7d4a0 (&lo->lo_mutex){+.+.}-{3:3}, at: __loop_clr_fd+0x4d/0x400 [loop]

 stack backtrace:
 CPU: 0 PID: 7568 Comm: systemd-udevd Tainted: G            E     5.14.0+ #757
 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020
 Call Trace:
  dump_stack_lvl+0x79/0xbf
  print_circular_bug+0x5d6/0x5e0
  ? stack_trace_save+0x42/0x60
  ? save_trace+0x3d/0x2d0
  check_noncircular+0x10b/0x120
  validate_chain+0x1f0d/0x33e0
  ? __lock_acquire+0x953/0x1030
  ? __lock_acquire+0x953/0x1030
  __lock_acquire+0x92d/0x1030
  ? flush_workqueue+0x70/0x560
  lock_acquire+0xbe/0x1f0
  ? flush_workqueue+0x70/0x560
  flush_workqueue+0x8c/0x560
  ? flush_workqueue+0x70/0x560
  ? sched_clock_cpu+0xe/0x1a0
  ? drain_workqueue+0x41/0x140
  drain_workqueue+0x80/0x140
  destroy_workqueue+0x47/0x4f0
  ? blk_mq_freeze_queue_wait+0xac/0xd0
  __loop_clr_fd+0xb4/0x400 [loop]
  ? __mutex_unlock_slowpath+0x35/0x230
  blkdev_put+0x14a/0x1d0
  blkdev_close+0x1c/0x20
  __fput+0xfd/0x220
  task_work_run+0x69/0xc0
  exit_to_user_mode_prepare+0x1ce/0x1f0
  syscall_exit_to_user_mode+0x26/0x60
  do_syscall_64+0x4c/0xb0
  entry_SYSCALL_64_after_hwframe+0x44/0xae
 RIP: 0033:0x7f0fd4c661f7
 Code: 00 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 13 fc ff ff
 RSP: 002b:00007ffd1c9e9fd8 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
 RAX: 0000000000000000 RBX: 00007f0fd46be6c8 RCX: 00007f0fd4c661f7
 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000006
 RBP: 0000000000000006 R08: 000055fff1eaf400 R09: 0000000000000000
 R10: 00007f0fd46be6c8 R11: 0000000000000246 R12: 0000000000000000
 R13: 0000000000000000 R14: 0000000000002f08 R15: 00007ffd1c9ea050

Commit 1c500ad706383f1a ("loop: reduce the loop_ctl_mutex scope") is for
breaking "loop_ctl_mutex => &lo->lo_mutex" dependency chain. But enabling
a different block module results in forming circular locking dependency
due to shared major_names_lock mutex.

The simplest fix is to call probe function without holding
major_names_lock [1], but Christoph Hellwig does not like such idea.
Therefore, instead of holding major_names_lock in blkdev_show(),
introduce a different lock for blkdev_show() in order to break
"sb_writers#$N => &p->lock => major_names_lock" dependency chain.

Link: https://lkml.kernel.org/r/b2af8a5b-3c1b-204e-7f56-bea0b15848d6@i-love.sakura.ne.jp [1]
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Link: https://lore.kernel.org/r/18a02da2-0bf3-550e-b071-2b4ab13c49f0@i-love.sakura.ne.jp
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-26 14:10:24 +02:00
Hannes Reinecke
e2860e2175 nvmet: fixup buffer overrun in nvmet_subsys_attr_serial()
[ Upstream commit f04064814c2a15c22ed9c803f9b634ef34f91092 ]

The serial number is copied into the buffer via memcpy_and_pad()
with the length NVMET_SN_MAX_SIZE. So when printing out we also
need to take just that length as anything beyond that will be
uninitialized.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-26 14:10:24 +02:00
Uwe Kleine-König
da66431417 pwm: stm32-lp: Don't modify HW state in .remove() callback
[ Upstream commit d44084c93427bb0a9261432db1a8ca76a42d805e ]

A consumer is expected to disable a PWM before calling pwm_put(). And if
they didn't there is hopefully a good reason (or the consumer needs
fixing). Also if disabling an enabled PWM was the right thing to do,
this should better be done in the framework instead of in each low level
driver.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-26 14:10:24 +02:00
Uwe Kleine-König
2c92f9e8e0 pwm: rockchip: Don't modify HW state in .remove() callback
[ Upstream commit 9d768cd7fd42bb0be16f36aec48548fca5260759 ]

A consumer is expected to disable a PWM before calling pwm_put(). And if
they didn't there is hopefully a good reason (or the consumer needs
fixing). Also if disabling an enabled PWM was the right thing to do,
this should better be done in the framework instead of in each low level
driver.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-26 14:10:24 +02:00
Uwe Kleine-König
f53bd7fe1b pwm: img: Don't modify HW state in .remove() callback
[ Upstream commit c68eb29c8e9067c08175dd0414f6984f236f719d ]

A consumer is expected to disable a PWM before calling pwm_put(). And if
they didn't there is hopefully a good reason (or the consumer needs
fixing). Also if disabling an enabled PWM was the right thing to do,
this should better be done in the framework instead of in each low level
driver.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-26 14:10:24 +02:00
farah kassabri
ddd8601dd8 habanalabs: cannot sleep while holding spinlock
[ Upstream commit 607b1468c2263e082d74c1a3e71399a9026b41ce ]

Fix 2 areas in the code where it's possible the code will
go to sleep while holding a spinlock.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: farah kassabri <fkassabri@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-26 14:10:24 +02:00
Omer Shpigelman
f621eeead8 habanalabs: add "in device creation" status
[ Upstream commit 71731090ab17a208a58020e4b342fdfee280458a ]

On init, the disabled state is cleared right before hw_init and that
causes the device to report on "Operational" state before the device
initialization is finished. Although the char device is not yet exposed
to the user at this stage, the sysfs entries are exposed.

This can cause errors in monitoring applications that use the sysfs
entries.

In order to avoid this, a new state "in device creation" is introduced
to ne reported when the device is not disabled but is still in init
flow.

Signed-off-by: Omer Shpigelman <oshpigelman@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-26 14:10:24 +02:00
Yuri Nudelman
836c080650 habanalabs: fix mmu node address resolution in debugfs
[ Upstream commit 09ae43043c748423a5dcdc7bb1e63e4dcabe9bd6 ]

The address resolution via debugfs was not taking into consideration the
page offset, resulting in a wrong address.

Signed-off-by: Yuri Nudelman <ynudelman@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-26 14:10:24 +02:00
Ofir Bitton
46d712b460 habanalabs: add validity check for event ID received from F/W
[ Upstream commit a6c849012b0f51c674f52384bd9a4f3dc0a33c31 ]

Currently there is no validity check for event ID received from F/W,
Thus exposing driver to memory overrun.

Signed-off-by: Ofir Bitton <obitton@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-26 14:10:23 +02:00
Philip Yang
350b2f2b1f drm/amdgpu: fix fdinfo race with process exit
[ Upstream commit d7eff46c214c036606dd3cd305bd5a128aecfe8c ]

Get process vm root BO ref in case process is exiting and root BO is
freed, to avoid NULL pointer dereference backtrace:

BUG: unable to handle kernel NULL pointer dereference at
0000000000000000
Call Trace:
amdgpu_show_fdinfo+0xfe/0x2a0 [amdgpu]
seq_show+0x12c/0x180
seq_read+0x153/0x410
vfs_read+0x91/0x140[ 3427.206183]  ksys_read+0x4f/0xb0
do_syscall_64+0x5b/0x1a0
entry_SYSCALL_64_after_hwframe+0x65/0xca

Signed-off-by: Philip Yang <Philip.Yang@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-26 14:10:23 +02:00
Anson Jacob
25b4e51e23 drm/amd/display: Fix memory leak reported by coverity
[ Upstream commit 03388a347fe7cf7c3bdf68b0823ba316d177d470 ]

Free memory allocated if any of the previous allocations failed.

>>>     CID 1487129:  Resource leaks  (RESOURCE_LEAK)
>>>     Variable "vpg" going out of scope leaks the storage it points to.

Addresses-Coverity-ID: 1487129: ("Resource leaks")

Reviewed-by: Aric Cyr <aric.cyr@amd.com>
Acked-by: Mikita Lipski <mikita.lipski@amd.com>
Signed-off-by: Anson Jacob <Anson.Jacob@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-26 14:10:23 +02:00
Luben Tuikov
6826456597 drm/amdgpu: Fixes to returning VBIOS RAS EEPROM address
[ Upstream commit a6a355a22f7a0efa6a11bc90b5161f394d51fe95 ]

1) Generalize the function--if the user didn't set
   i2c_address, still return true/false to
   indicate whether VBIOS contains the RAS EEPROM
   address.  This function shouldn't evaluate
   whether the user set the i2c_address pointer or
   not.

2) Don't touch the caller's i2c_address, unless
   you have to--this function shouldn't have side
   effects.

3) Correctly set the function comment as a
   kernel-doc comment.

Cc: John Clements <john.clements@amd.com>
Cc: Hawking Zhang <Hawking.Zhang@amd.com>
Cc: Alex Deucher <Alexander.Deucher@amd.com>
Signed-off-by: Luben Tuikov <luben.tuikov@amd.com>
Reviewed-by: Alex Deucher <Alexander.Deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-26 14:10:23 +02:00
Tomer Tayar
d5b10c0b42 habanalabs: fix nullifying of destroyed mmu pgt pool
[ Upstream commit 89aad770d692e4d2d9a604c1674e9dfa69421430 ]

In case of host-resident MMU, when the page tables pool is destroyed,
its pointer is not nullified correctly.
As a result, on a device fini which happens after a failing reset, the
already destroyed pool is accessed, which leads to a kernel panic.
The patch fixes the setting of the pool pointer to NULL.

Signed-off-by: Tomer Tayar <ttayar@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-26 14:10:23 +02:00
Niklas Söderlund
d51100f735 thermal/drivers/rcar_gen3_thermal: Store TSC id as unsigned int
[ Upstream commit d3a2328e741bf6e9e6bda750e0a63832fa365a74 ]

The TSC id and number of TSC ids should be stored as unsigned int as
they can't be negative. Fix the datatype of the loop counter 'i' and
rcar_gen3_thermal_tsc.id to reflect this.

Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20210804091818.2196806-3-niklas.soderlund+renesas@ragnatech.se
Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-26 14:10:23 +02:00