Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lots of W{,void-}pointer-to-int-cast from ToT clang #887

Closed
nathanchance opened this issue Feb 17, 2020 · 15 comments
Closed

Lots of W{,void-}pointer-to-int-cast from ToT clang #887

nathanchance opened this issue Feb 17, 2020 · 15 comments

Comments

@nathanchance
Copy link
Member

@nathanchance nathanchance commented Feb 17, 2020

There are a lot of new instances of the warning in the kernel, which appears to be due to a semantic difference between GCC and clang. I've commented on the Phabricator post about this to see what they say, I'd like not to send a bunch of patches like I did with -Wmisleading-indentation.

https://reviews.llvm.org/D72231#1878528

@nathanchance

This comment has been minimized.

Copy link
Member Author

@nathanchance nathanchance commented Feb 18, 2020

Well they at least agreed to remove the _Bool conversion warnings but the enum ones are still plentiful (97 unique warnings by my count) so this is going to be fun :(

      4 drivers/ata/ahci_brcm.c:445:18: warning: cast to smaller integer type 'enum brcm_ahci_version' from 'const void *' [-Wvoid-pointer-to-int-cast]
      5 drivers/ata/ahci_imx.c:1065:18: warning: cast to smaller integer type 'enum ahci_imx_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      5 drivers/ata/ahci_qoriq.c:277:21: warning: cast to smaller integer type 'enum ahci_qoriq_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      5 drivers/ata/ahci_xgene.c:792:14: warning: cast to smaller integer type 'enum xgene_ahci_version' from 'const void *' [-Wvoid-pointer-to-int-cast]
      5 drivers/ata/sata_rcar.c:905:15: warning: cast to smaller integer type 'enum sata_rcar_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      9 drivers/char/ipmi/ipmi_si_platform.c:274:15: warning: cast to smaller integer type 'enum si_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      6 drivers/crypto/exynos-rng.c:280:14: warning: cast to smaller integer type 'enum exynos_prng_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      6 drivers/crypto/inside-secure/safexcel.c:1692:18: warning: cast to smaller integer type 'enum safexcel_eip_version' from 'const void *' [-Wvoid-pointer-to-int-cast]
      6 drivers/devfreq/event/exynos-ppmu.c:523:21: warning: cast to smaller integer type 'enum exynos_ppmu_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      8 drivers/dma/mmp_tdma.c:640:10: warning: cast to smaller integer type 'enum mmp_tdma_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      9 drivers/dma/qcom/hidma.c:750:8: warning: cast to smaller integer type 'enum hidma_cap' from 'const void *' [-Wvoid-pointer-to-int-cast]
      9 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c:1112:19: warning: cast to smaller integer type 'enum adv7511_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      9 drivers/gpu/drm/lima/lima_drv.c:283:13: warning: cast to smaller integer type 'enum lima_gpu_id' from 'const void *' [-Wvoid-pointer-to-int-cast]
      4 drivers/gpu/drm/mediatek/mtk_drm_drv.c:465:15: warning: cast to smaller integer type 'enum mtk_ddp_comp_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      9 drivers/gpu/drm/pl111/pl111_versatile.c:325:24: warning: cast to smaller integer type 'enum versatile_clcd' from 'const void *' [-Wvoid-pointer-to-int-cast]
      8 drivers/gpu/drm/tiny/repaper.c:1009:11: warning: cast to smaller integer type 'enum repaper_model' from 'const void *' [-Wvoid-pointer-to-int-cast]
      4 drivers/hwmon/ad7418.c:255:16: warning: cast to smaller integer type 'enum chips' from 'const void *' [-Wvoid-pointer-to-int-cast]
      4 drivers/hwmon/ads7828.c:141:10: warning: cast to smaller integer type 'enum ads7828_chips' from 'const void *' [-Wvoid-pointer-to-int-cast]
      4 drivers/hwmon/adt7475.c:1486:10: warning: cast to smaller integer type 'enum chips' from 'const void *' [-Wvoid-pointer-to-int-cast]
      5 drivers/hwmon/ina2xx.c:445:10: warning: cast to smaller integer type 'enum ina2xx_ids' from 'const void *' [-Wvoid-pointer-to-int-cast]
      4 drivers/hwmon/lm63.c:1107:16: warning: cast to smaller integer type 'enum chips' from 'const void *' [-Wvoid-pointer-to-int-cast]
      4 drivers/hwmon/lm75.c:555:10: warning: cast to smaller integer type 'enum lm75_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      4 drivers/hwmon/lm85.c:1560:16: warning: cast to smaller integer type 'enum chips' from 'const void *' [-Wvoid-pointer-to-int-cast]
      5 drivers/hwmon/lm90.c:1780:16: warning: cast to smaller integer type 'enum chips' from 'const void *' [-Wvoid-pointer-to-int-cast]
      4 drivers/hwmon/max6697.c:612:16: warning: cast to smaller integer type 'enum chips' from 'const void *' [-Wvoid-pointer-to-int-cast]
      4 drivers/hwmon/pmbus/ibm-cffps.c:484:8: warning: cast to smaller integer type 'enum versions' from 'const void *' [-Wvoid-pointer-to-int-cast]
      4 drivers/hwmon/pmbus/max20730.c:322:13: warning: cast to smaller integer type 'enum chips' from 'const void *' [-Wvoid-pointer-to-int-cast]
      4 drivers/hwmon/pmbus/tps53679.c:194:13: warning: cast to smaller integer type 'enum chips' from 'const void *' [-Wvoid-pointer-to-int-cast]
      4 drivers/hwmon/pmbus/ucd9000.c:524:10: warning: cast to smaller integer type 'enum chips' from 'const void *' [-Wvoid-pointer-to-int-cast]
      4 drivers/hwmon/pmbus/ucd9200.c:107:10: warning: cast to smaller integer type 'enum chips' from 'const void *' [-Wvoid-pointer-to-int-cast]
      4 drivers/hwmon/tmp513.c:725:14: warning: cast to smaller integer type 'enum tmp51x_ids' from 'const void *' [-Wvoid-pointer-to-int-cast]
      7 drivers/i2c/busses/i2c-bcm-iproc.c:902:3: warning: cast to smaller integer type 'enum bcm_iproc_i2c_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      7 drivers/i2c/busses/i2c-pxa.c:1227:15: warning: cast to smaller integer type 'enum pxa_i2c_types' from 'const void *' [-Wvoid-pointer-to-int-cast]
      7 drivers/i2c/busses/i2c-rcar.c:945:18: warning: cast to smaller integer type 'enum rcar_i2c_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      4 drivers/iio/accel/bma180.c:825:10: warning: cast to smaller integer type 'enum chip_ids' from 'const void *' [-Wvoid-pointer-to-int-cast]
      2 drivers/iio/adc/ina2xx-adc.c:974:10: warning: cast to smaller integer type 'enum ina2xx_ids' from 'const void *' [-Wvoid-pointer-to-int-cast]
      4 drivers/iio/adc/rcar-gyroadc.c:513:16: warning: cast to smaller integer type 'enum rcar_gyroadc_model' from 'const void *' [-Wvoid-pointer-to-int-cast]
      4 drivers/iio/adc/ti-ads1015.c:947:9: warning: cast to smaller integer type 'enum chip_ids' from 'const void *' [-Wvoid-pointer-to-int-cast]
      4 drivers/iio/dac/mcp4725.c:402:14: warning: cast to smaller integer type 'enum chip_id' from 'const void *' [-Wvoid-pointer-to-int-cast]
      4 drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c:144:15: warning: cast to smaller integer type 'enum inv_devices' from 'const void *' [-Wvoid-pointer-to-int-cast]
      4 drivers/iio/magnetometer/ak8975.c:878:13: warning: cast to smaller integer type 'enum asahi_compass_chipset' from 'const void *' [-Wvoid-pointer-to-int-cast]
      6 drivers/input/touchscreen/mms114.c:453:15: warning: cast to smaller integer type 'enum mms_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      7 drivers/media/dvb-core/dvb_frontend.c:2534:7: warning: cast to smaller integer type 'enum fe_sec_mini_cmd' from 'void *' [-Wvoid-pointer-to-int-cast]
      7 drivers/media/dvb-core/dvb_frontend.c:2543:13: warning: cast to smaller integer type 'enum fe_sec_tone_mode' from 'void *' [-Wvoid-pointer-to-int-cast]
      7 drivers/media/dvb-core/dvb_frontend.c:2544:19: warning: cast to smaller integer type 'enum fe_sec_tone_mode' from 'void *' [-Wvoid-pointer-to-int-cast]
      7 drivers/media/dvb-core/dvb_frontend.c:2553:9: warning: cast to smaller integer type 'enum fe_sec_voltage' from 'void *' [-Wvoid-pointer-to-int-cast]
      7 drivers/media/dvb-core/dvb_frontend.c:2554:22: warning: cast to smaller integer type 'enum fe_sec_voltage' from 'void *' [-Wvoid-pointer-to-int-cast]
      6 drivers/media/platform/mtk-mdp/mtk_mdp_core.c:139:15: warning: cast to smaller integer type 'enum mtk_mdp_comp_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      9 drivers/mfd/hi6421-pmic-core.c:63:9: warning: cast to smaller integer type 'enum hi6421_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      8 drivers/mfd/lp87565.c:73:23: warning: cast to smaller integer type 'enum lp87565_device_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      8 drivers/mfd/max14577.c:409:5: warning: cast to smaller integer type 'enum maxim_device_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      8 drivers/mfd/mxs-lradc.c:145:15: warning: cast to smaller integer type 'enum mxs_lradc_id' from 'const void *' [-Wvoid-pointer-to-int-cast]
      6 drivers/mfd/stmpe-i2c.c:89:13: warning: cast to smaller integer type 'enum stmpe_partnum' from 'const void *' [-Wvoid-pointer-to-int-cast]
      6 drivers/mfd/tc3589x.c:343:13: warning: cast to smaller integer type 'enum tc3589x_version' from 'const void *' [-Wvoid-pointer-to-int-cast]
      6 drivers/mfd/wm831x-i2c.c:39:10: warning: cast to smaller integer type 'enum wm831x_parent' from 'const void *' [-Wvoid-pointer-to-int-cast]
      8 drivers/mfd/wm831x-spi.c:36:10: warning: cast to smaller integer type 'enum wm831x_parent' from 'const void *' [-Wvoid-pointer-to-int-cast]
      8 drivers/mfd/wm8994-core.c:639:19: warning: cast to smaller integer type 'enum wm8994_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      5 drivers/mtd/maps/physmap-versatile.c:208:25: warning: cast to smaller integer type 'enum versatile_flashprot' from 'const void *' [-Wvoid-pointer-to-int-cast]
      5 drivers/mtd/nand/raw/vf610_nfc.c:856:17: warning: cast to smaller integer type 'enum vf610_nfc_variant' from 'const void *' [-Wvoid-pointer-to-int-cast]
      4 drivers/mux/adgs1408.c:62:12: warning: cast to smaller integer type 'enum adgs1408_chip_id' from 'const void *' [-Wvoid-pointer-to-int-cast]
      6 drivers/net/can/spi/hi311x.c:874:17: warning: cast to smaller integer type 'enum hi3110_model' from 'const void *' [-Wvoid-pointer-to-int-cast]
      6 drivers/net/can/spi/mcp251x.c:1073:17: warning: cast to smaller integer type 'enum mcp251x_model' from 'const void *' [-Wvoid-pointer-to-int-cast]
      7 drivers/net/ethernet/apm/xgene/xgene_enet_main.c:2042:20: warning: cast to smaller integer type 'enum xgene_enet_id' from 'const void *' [-Wvoid-pointer-to-int-cast]
      7 drivers/net/ethernet/marvell/mvmdio.c:284:9: warning: cast to smaller integer type 'enum orion_mdio_bus_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      6 drivers/net/ethernet/ni/nixge.c:1257:12: warning: cast to smaller integer type 'enum nixge_version' from 'const void *' [-Wvoid-pointer-to-int-cast]
      7 drivers/net/ethernet/renesas/ravb_main.c:2021:12: warning: cast to smaller integer type 'enum ravb_chip_id' from 'const void *' [-Wvoid-pointer-to-int-cast]
      7 drivers/net/phy/mdio-xgene.c:337:13: warning: cast to smaller integer type 'enum xgene_mdio_id' from 'const void *' [-Wvoid-pointer-to-int-cast]
      6 drivers/net/wireless/ath/ath10k/ahb.c:751:11: warning: cast to smaller integer type 'enum ath10k_hw_rev' from 'const void *' [-Wvoid-pointer-to-int-cast]
      6 drivers/net/wireless/ath/ath11k/ahb.c:918:15: warning: cast to smaller integer type 'enum ath11k_hw_rev' from 'const void *' [-Wvoid-pointer-to-int-cast]
      5 drivers/pci/controller/pcie-iproc-platform.c:56:15: warning: cast to smaller integer type 'enum iproc_pcie_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      8 drivers/phy/broadcom/phy-bcm-ns-usb3.c:217:17: warning: cast to smaller integer type 'enum bcm_ns_family' from 'const void *' [-Wvoid-pointer-to-int-cast]
      8 drivers/phy/broadcom/phy-bcm-ns-usb3.c:324:17: warning: cast to smaller integer type 'enum bcm_ns_family' from 'const void *' [-Wvoid-pointer-to-int-cast]
      9 drivers/phy/broadcom/phy-bcm-sr-usb.c:370:13: warning: cast to smaller integer type 'enum bcm_usb_phy_version' from 'const void *' [-Wvoid-pointer-to-int-cast]
      9 drivers/phy/broadcom/phy-brcm-sata.c:767:19: warning: cast to smaller integer type 'enum brcm_sata_phy_version' from 'const void *' [-Wvoid-pointer-to-int-cast]
      8 drivers/phy/marvell/phy-pxa-usb.c:300:26: warning: cast to smaller integer type 'enum pxa_usb_phy_version' from 'const void *' [-Wvoid-pointer-to-int-cast]
      8 drivers/phy/ti/phy-j721e-wiz.c:782:14: warning: cast to smaller integer type 'enum wiz_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      2 drivers/platform/x86/hp-wmi.c:323:24: warning: cast to smaller integer type 'enum hp_wmi_radio' from 'void *' [-Wvoid-pointer-to-int-cast]
      5 drivers/power/reset/vexpress-poweroff.c:124:10: warning: cast to smaller integer type 'enum vexpress_reset_func' from 'const void *' [-Wvoid-pointer-to-int-cast]
      6 drivers/power/supply/ltc2941-battery-gauge.c:476:13: warning: cast to smaller integer type 'enum ltc294x_id' from 'const void *' [-Wvoid-pointer-to-int-cast]
      8 drivers/regulator/lp872x.c:876:5: warning: cast to smaller integer type 'enum lp872x_regulator_id' from 'void *' [-Wvoid-pointer-to-int-cast]
      8 drivers/regulator/ltc3589.c:398:22: warning: cast to smaller integer type 'enum ltc3589_variant' from 'const void *' [-Wvoid-pointer-to-int-cast]
      9 drivers/reset/hisilicon/hi6220_reset.c:107:9: warning: cast to smaller integer type 'enum hi6220_reset_ctrl_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      6 drivers/rtc/rtc-ds1307.c:1605:18: warning: cast to smaller integer type 'enum ds_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      6 drivers/rtc/rtc-jz4740.c:320:15: warning: cast to smaller integer type 'enum jz4740_rtc_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      4 drivers/rtc/rtc-mxc.c:325:20: warning: cast to smaller integer type 'enum imx_rtc_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      6 drivers/rtc/rtc-rs5c372.c:651:19: warning: cast to smaller integer type 'enum rtc_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      6 drivers/rtc/rtc-rv8803.c:545:18: warning: cast to smaller integer type 'enum rv8803_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      8 drivers/scsi/fcoe/fcoe_transport.c:863:27: warning: cast to smaller integer type 'enum fip_mode' from 'void *' [-Wvoid-pointer-to-int-cast]
      8 drivers/soc/renesas/rmobile-sysc.c:206:22: warning: cast to smaller integer type 'enum pd_types' from 'const void *' [-Wvoid-pointer-to-int-cast]
      7 drivers/spi/spi-pxa2xx.c:1547:10: warning: cast to smaller integer type 'enum pxa_ssp_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      7 drivers/spi/spi-sc18is602.c:266:12: warning: cast to smaller integer type 'enum chips' from 'const void *' [-Wvoid-pointer-to-int-cast]
      7 drivers/thermal/samsung/exynos_tmu.c:897:14: warning: cast to smaller integer type 'enum soc_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
     14 mm/rmap.c:1369:25: warning: cast to smaller integer type 'enum ttu_flags' from 'void *' [-Wvoid-pointer-to-int-cast]
      8 sound/soc/codecs/rt5677.c:5582:19: warning: cast to smaller integer type 'enum rt5677_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      8 sound/soc/codecs/wm8904.c:2197:21: warning: cast to smaller integer type 'enum wm8904_type' from 'const void *' [-Wvoid-pointer-to-int-cast]
      8 sound/soc/jz4740/jz4740-i2s.c:504:3: warning: cast to smaller integer type 'enum jz47xx_i2s_version' from 'const void *' [-Wvoid-pointer-to-int-cast]
      8 sound/soc/rockchip/rockchip_pdm.c:490:18: warning: cast to smaller integer type 'enum rk_pdm_version' from 'const void *' [-Wvoid-pointer-to-int-cast]

I'll get cracking on these soon.

@nickdesaulniers

This comment has been minimized.

Copy link
Member

@nickdesaulniers nickdesaulniers commented Feb 18, 2020

Why would you cast a void* to an enum? Is there a commonly used macro that's doing this?

@nathanchance

This comment has been minimized.

Copy link
Member Author

@nathanchance nathanchance commented Feb 18, 2020

No. It looks like most of these warnings are from drivers sticking certain values into a void *data member in certain structs like of_device_id, since any driver supporting device tree can use it so you cannot just have a generic enum for that.

https://elixir.bootlin.com/linux/v5.5.4/source/drivers/ata/ahci_brcm.c#L428

https://elixir.bootlin.com/linux/v5.5.4/source/drivers/ata/ahci_brcm.c#L402

https://elixir.bootlin.com/linux/v5.5.4/source/include/linux/mod_devicetable.h#L264

@m-gupta

This comment has been minimized.

Copy link

@m-gupta m-gupta commented Mar 5, 2020

@nathanchance did you manage to look at the warnings? We have started hitting them with our ToT LLVM builds as well in Chrome OS.

@nathanchance

This comment has been minimized.

Copy link
Member Author

@nathanchance nathanchance commented Mar 5, 2020

I think the general consensus is that the kernel is not going to change these sites to work around the warning and LLVM does not want to match GCC exactly so we need a separate diagnostic like -W{void,}-pointer-to-enum-cast, which would be default on, which we can then disable for the kernel.

https://godbolt.org/z/ahf79P

I want to try and tackle this myself as it would be my first major contribution to clang but unfortunately, I am a little time starved right now. If someone else wants to implement that ahead of me, please feel free.

@m-gupta

This comment has been minimized.

nathanchance added a commit to ClangBuiltLinux/llvm-project that referenced this issue Mar 6, 2020
GCC does not warn on casts from pointers to enumerators, while clang
currently does. This causes a bunch of extra warnings in the Linux
kernel, where certain structs contain a void pointer to avoid using a
gigantic union for all of the various types of driver data, such as
version.

Add a diagnostic that allows the kernel to disable the warning just for
enums, which keeps the compatibility with GCC but allows other people to
catch potential issues in their own code base.

Link: ClangBuiltLinux/linux#887
nathanchance added a commit to ClangBuiltLinux/llvm-project that referenced this issue Mar 6, 2020
GCC does not warn on casts from pointers to enumerators, while clang
currently does. This causes a bunch of extra warnings in the Linux
kernel, where certain structs contain a void pointer to avoid using a
gigantic union for all of the various types of driver data, such as
version.

Add a diagnostic that allows the kernel to disable the warning just for
enums, which keeps the compatibility with GCC but allows other people to
catch potential issues in their own code base.

Link: ClangBuiltLinux/linux#887
nathanchance added a commit to ClangBuiltLinux/llvm-project that referenced this issue Mar 6, 2020
GCC does not warn on casts from pointers to enumerators, while clang
currently does. This causes a bunch of extra warnings in the Linux
kernel, where certain structs contain a void pointer to avoid using a
gigantic union for all of the various types of driver data, such as
version.

Add a diagnostic that allows the kernel to disable the warning just for
enums, which keeps the compatibility with GCC but allows other people to
catch potential issues in their own code base.

Link: ClangBuiltLinux/linux#887
@nathanchance

This comment has been minimized.

Copy link
Member Author

@nathanchance nathanchance commented Mar 6, 2020

Alright, that wasn't too hard: ClangBuiltLinux/llvm-project@4fd4438

I'll throw it up on Phabricator tomorrow, let me know if there are any general comments towards the approach or nitpicks on the patch itself.

cc @davidbolvansky since you seem active in the Sema space (and you commented on the original patch).

nathanchance added a commit to ClangBuiltLinux/llvm-project that referenced this issue Mar 6, 2020
GCC does not warn on casts from pointers to enumerators, while clang
currently does: https://godbolt.org/z/3DFDVG

This causes a bunch of extra warnings in the Linux kernel, where
certain structs contain a void pointer to avoid using a gigantic
union for all of the various types of driver data, such as
versions.

Add a diagnostic that allows certain projects like the kernel to
disable the warning just for enums, which allowst those projects to
keep full compatibility with GCC but keeps the intention of treating
casts to integers and enumerators the same by default so that other
projects have the opportunity to catch issues not noticed before (or
follow suite and disable the warning).

Link: ClangBuiltLinux/linux#887
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
@nathanchance

This comment has been minimized.

Copy link
Member Author

@nathanchance nathanchance commented Mar 6, 2020

LLVM patch submitted: https://reviews.llvm.org/D75758

Tested with the following diff for the kernel: https://gist.github.com/767cccf4d093c1342e1994083518815e

@m-gupta

This comment has been minimized.

Copy link

@m-gupta m-gupta commented Mar 6, 2020

Thanks, I was planning to work on it as first thing this morning but @nathanchance beat me to it :).

Congrats on your first major LLVM contribution!

nathanchance added a commit to ClangBuiltLinux/llvm-project that referenced this issue Mar 7, 2020
GCC does not warn on casts from pointers to enumerators, while clang
currently does: https://godbolt.org/z/3DFDVG

This causes a bunch of extra warnings in the Linux kernel, where
certain structs contain a void pointer to avoid using a gigantic
union for all of the various types of driver data, such as
versions.

Add a diagnostic that allows certain projects like the kernel to
disable the warning just for enums, which allows those projects to
keep full compatibility with GCC but keeps the intention of treating
casts to integers and enumerators the same by default so that other
projects have the opportunity to catch issues not noticed before (or
follow suite and disable the warning).

Link: ClangBuiltLinux/linux#887
MaskRay added a commit to llvm/llvm-project that referenced this issue Mar 8, 2020
GCC does not warn on casts from pointers to enumerators, while clang
currently does: https://godbolt.org/z/3DFDVG

This causes a bunch of extra warnings in the Linux kernel, where
certain structs contain a void pointer to avoid using a gigantic
union for all of the various types of driver data, such as
versions.

Add a diagnostic that allows certain projects like the kernel to
disable the warning just for enums, which allows those projects to
keep full compatibility with GCC but keeps the intention of treating
casts to integers and enumerators the same by default so that other
projects have the opportunity to catch issues not noticed before (or
follow suite and disable the warning).

Link: ClangBuiltLinux/linux#887

Reviewed By: rjmccall

Differential Revision: https://reviews.llvm.org/D75758
@nathanchance

This comment has been minimized.

Copy link
Member Author

@nathanchance nathanchance commented Mar 8, 2020

@m-gupta

This comment has been minimized.

Copy link

@m-gupta m-gupta commented Mar 14, 2020

@nathanchance Do you know if the patch has been committed to stable branches?

@nathanchance

This comment has been minimized.

Copy link
Member Author

@nathanchance nathanchance commented Mar 14, 2020

@m-gupta Masahiro just picked up the patch today. Not sure if he plans to send a pull request for -rc6 but if not, certainly for -rc7/final; in other words, the patch should be to mainline within a week hopefully. Once it has made it to mainline, it should be shipped to stable within a couple of weeks (depending o

If that timeline doesn't work for CrOS, here is the backported version that I will send when I get the rejected email from Greg so there should be no conflicts when stable gets merged. It applies cleanly via git am to 4.4 through 4.19. The patch as I have sent it above should apply cleanly to 5.4 and newer.

@m-gupta

This comment has been minimized.

Copy link

@m-gupta m-gupta commented Mar 14, 2020

Thanks, I was just looking for a local patch to apply to our builds. Will replace by an official commit once available.

krasCGQ added a commit to krasCGQ/moesyndrome-kernel that referenced this issue Mar 15, 2020
Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang. It
will be visible under W=1 in case people want to go about fixing these
easily and enabling the warning treewide.

Cc: stable@vger.kernel.org
Link: ClangBuiltLinux/linux#887
Link: llvm/llvm-project@2a41b31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Albert I <kras@raphielgang.org>
SaintZ13 added a commit to SaintZ13/schwifty_kernel_op7pro that referenced this issue Mar 15, 2020
Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang.

Credit: @nathanchance
Link: ClangBuiltLinux/linux#887
Link: llvm/llvm-project@2a41b31
SaintZ13 added a commit to SaintZ13/schwifty_kernel_op7pro that referenced this issue Mar 15, 2020
Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang. It
will be visible under W=1 in case people want to go about fixing these
easily and enabling the warning treewide.

Cc: stable@vger.kernel.org
Link: ClangBuiltLinux/linux#887
Link: llvm/llvm-project@2a41b31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
ruscur pushed a commit to ruscur/linux that referenced this issue Mar 16, 2020
Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang. It
will be visible under W=1 in case people want to go about fixing these
easily and enabling the warning treewide.

Cc: stable@vger.kernel.org
Link: ClangBuiltLinux#887
Link: llvm/llvm-project@2a41b31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
@nathanchance

This comment has been minimized.

YumeMichi added a commit to YumeMichi/kernel_xiaomi_sdm845 that referenced this issue Mar 17, 2020
Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang.

Change-Id: Ib18b16da716a91edd008f5296cc85955bfb10d37
Cc: stable@vger.kernel.org
Link: ClangBuiltLinux/linux#887
Link: llvm/llvm-project@2a41b31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Danny Lin <danny@kdrag0n.dev>
nicholasbishop pushed a commit to neverware/kernel that referenced this issue Mar 18, 2020
Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang. It
will be visible under W=1 in case people want to go about fixing these
easily and enabling the warning treewide.

Cc: stable@vger.kernel.org
Link: ClangBuiltLinux/linux#887
Link: llvm/llvm-project@2a41b31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
(am from https://patchwork.kernel.org/patch/11432749/)

BUG=chromium:1058965
TEST=kernel compiles with ToT clang

Signed-off-by: Manoj Gupta <manojgupta@google.com>
Change-Id: Ia848739fb684fec08c6aac8c39d50ba7ef357cc2
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2103959
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
@nathanchance

This comment has been minimized.

Copy link
Member Author

@nathanchance nathanchance commented Mar 20, 2020

Merged into mainline: https://git.kernel.org/linus/82f2bc2fcc0160d6f82dd1ac64518ae0a4dd183f

This should be picked up automatically for stable but if Android/CrOS needs this sooner, here's an "official" backport for 4.19 and earlier: https://gist.github.com/366fe819bf1314eccf3e66d690e40575

$ curl -LSs https://gist.githubusercontent.com/nathanchance/366fe819bf1314eccf3e66d690e40575/raw/c0093b60e2871416eb48fe7de3fb343fee5105b4/gistfile1.txt | git am
@nathanchance nathanchance self-assigned this Mar 20, 2020
hnaz added a commit to hnaz/linux-mm that referenced this issue Mar 21, 2020
GIT c63c50fc2ec9afc4de21ef9ead2eac64b178cce1

commit 1d0c32ec3b860a32df593a22bad0d1dbc5546a59
Author: Greg Kurz <groug@kaod.org>
Date:   Wed Mar 18 18:43:30 2020 +0100

    KVM: PPC: Fix kernel crash with PR KVM
    
    With PR KVM, shutting down a VM causes the host kernel to crash:
    
    [  314.219284] BUG: Unable to handle kernel data access on read at 0xc00800000176c638
    [  314.219299] Faulting instruction address: 0xc008000000d4ddb0
    cpu 0x0: Vector: 300 (Data Access) at [c00000036da077a0]
        pc: c008000000d4ddb0: kvmppc_mmu_pte_flush_all+0x68/0xd0 [kvm_pr]
        lr: c008000000d4dd94: kvmppc_mmu_pte_flush_all+0x4c/0xd0 [kvm_pr]
        sp: c00000036da07a30
       msr: 900000010280b033
       dar: c00800000176c638
     dsisr: 40000000
      current = 0xc00000036d4c0000
      paca    = 0xc000000001a00000   irqmask: 0x03   irq_happened: 0x01
        pid   = 1992, comm = qemu-system-ppc
    Linux version 5.6.0-master-gku+ (greg@palmb) (gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)) #17 SMP Wed Mar 18 13:49:29 CET 2020
    enter ? for help
    [c00000036da07ab0] c008000000d4fbe0 kvmppc_mmu_destroy_pr+0x28/0x60 [kvm_pr]
    [c00000036da07ae0] c0080000009eab8c kvmppc_mmu_destroy+0x34/0x50 [kvm]
    [c00000036da07b00] c0080000009e50c0 kvm_arch_vcpu_destroy+0x108/0x140 [kvm]
    [c00000036da07b30] c0080000009d1b50 kvm_vcpu_destroy+0x28/0x80 [kvm]
    [c00000036da07b60] c0080000009e4434 kvm_arch_destroy_vm+0xbc/0x190 [kvm]
    [c00000036da07ba0] c0080000009d9c2c kvm_put_kvm+0x1d4/0x3f0 [kvm]
    [c00000036da07c00] c0080000009da760 kvm_vm_release+0x38/0x60 [kvm]
    [c00000036da07c30] c000000000420be0 __fput+0xe0/0x310
    [c00000036da07c90] c0000000001747a0 task_work_run+0x150/0x1c0
    [c00000036da07cf0] c00000000014896c do_exit+0x44c/0xd00
    [c00000036da07dc0] c0000000001492f4 do_group_exit+0x64/0xd0
    [c00000036da07e00] c000000000149384 sys_exit_group+0x24/0x30
    [c00000036da07e20] c00000000000b9d0 system_call+0x5c/0x68
    
    This is caused by a use-after-free in kvmppc_mmu_pte_flush_all()
    which dereferences vcpu->arch.book3s which was previously freed by
    kvmppc_core_vcpu_free_pr(). This happens because kvmppc_mmu_destroy()
    is called after kvmppc_core_vcpu_free() since commit ff030fdf5573
    ("KVM: PPC: Move kvm_vcpu_init() invocation to common code").
    
    The kvmppc_mmu_destroy() helper calls one of the following depending
    on the KVM backend:
    
    - kvmppc_mmu_destroy_hv() which does nothing (Book3s HV)
    
    - kvmppc_mmu_destroy_pr() which undoes the effects of
      kvmppc_mmu_init() (Book3s PR 32-bit)
    
    - kvmppc_mmu_destroy_pr() which undoes the effects of
      kvmppc_mmu_init() (Book3s PR 64-bit)
    
    - kvmppc_mmu_destroy_e500() which does nothing (BookE e500/e500mc)
    
    It turns out that this is only relevant to PR KVM actually. And both
    32 and 64 backends need vcpu->arch.book3s to be valid when calling
    kvmppc_mmu_destroy_pr(). So instead of calling kvmppc_mmu_destroy()
    from kvm_arch_vcpu_destroy(), call kvmppc_mmu_destroy_pr() at the
    beginning of kvmppc_core_vcpu_free_pr(). This is consistent with
    kvmppc_mmu_init() being the last call in kvmppc_core_vcpu_create_pr().
    
    For the same reason, if kvmppc_core_vcpu_create_pr() returns an
    error then this means that kvmppc_mmu_init() was either not called
    or failed, in which case kvmppc_mmu_destroy() should not be called.
    Drop the line in the error path of kvm_arch_vcpu_create().
    
    Fixes: ff030fdf5573 ("KVM: PPC: Move kvm_vcpu_init() invocation to common code")
    Signed-off-by: Greg Kurz <groug@kaod.org>
    Reviewed-by: Sean Christopherson <sean.j.christopherson@intel.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/158455341029.178873.15248663726399374882.stgit@bahia.lan

commit eb916a5a93a64c182b0a8f43886aa6bb4c3e52b0
Author: Mario Kleiner <mario.kleiner.de@gmail.com>
Date:   Mon Mar 2 07:17:32 2020 +0100

    drm/amd/display: Fix pageflip event race condition for DCN.
    
    Commit '16f17eda8bad ("drm/amd/display: Send vblank and user
    events at vsartup for DCN")' introduces a new way of pageflip
    completion handling for DCN, and some trouble.
    
    The current implementation introduces a race condition, which
    can cause pageflip completion events to be sent out one vblank
    too early, thereby confusing userspace and causing flicker:
    
    prepare_flip_isr():
    
    1. Pageflip programming takes the ddev->event_lock.
    2. Sets acrtc->pflip_status == AMDGPU_FLIP_SUBMITTED
    3. Releases ddev->event_lock.
    
    --> Deadline for surface address regs double-buffering passes on
        target pipe.
    
    4. dc_commit_updates_for_stream() MMIO programs the new pageflip
       into hw, but too late for current vblank.
    
    => pflip_status == AMDGPU_FLIP_SUBMITTED, but flip won't complete
       in current vblank due to missing the double-buffering deadline
       by a tiny bit.
    
    5. VSTARTUP trigger point in vblank is reached, VSTARTUP irq fires,
       dm_dcn_crtc_high_irq() gets called.
    
    6. Detects pflip_status == AMDGPU_FLIP_SUBMITTED and assumes the
       pageflip has been completed/will complete in this vblank and
       sends out pageflip completion event to userspace and resets
       pflip_status = AMDGPU_FLIP_NONE.
    
    => Flip completion event sent out one vblank too early.
    
    This behaviour has been observed during my testing with measurement
    hardware a couple of time.
    
    The commit message says that the extra flip event code was added to
    dm_dcn_crtc_high_irq() to prevent missing to send out pageflip events
    in case the pflip irq doesn't fire, because the "DCH HUBP" component
    is clock gated and doesn't fire pflip irqs in that state. Also that
    this clock gating may happen if no planes are active. This suggests
    that the problem addressed by that commit can't happen if planes
    are active.
    
    The proposed solution is therefore to only execute the extra pflip
    completion code iff the count of active planes is zero and otherwise
    leave pflip completion handling to the pflip irq handler, for a
    more race-free experience.
    
    Note that i don't know if this fixes the problem the original commit
    tried to address, as i don't know what the test scenario was. It
    does fix the observed too early pageflip events though and points
    out the problem introduced.
    
    Fixes: 16f17eda8bad ("drm/amd/display: Send vblank and user events at vsartup for DCN")
    Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
    Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

commit 3568b88944fef28db3ee989b957da49ffc627ede
Author: Vincenzo Frascino <vincenzo.frascino@arm.com>
Date:   Thu Mar 19 14:11:38 2020 +0000

    arm64: compat: Fix syscall number of compat_clock_getres
    
    The syscall number of compat_clock_getres was erroneously set to 247
    (__NR_io_cancel!) instead of 264. This causes the vDSO fallback of
    clock_getres() to land on the wrong syscall for compat tasks.
    
    Fix the numbering.
    
    Cc: <stable@vger.kernel.org>
    Fixes: 53c489e1dfeb6 ("arm64: compat: Add missing syscall numbers")
    Acked-by: Catalin Marinas <catalin.marinas@arm.com>
    Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
    Signed-off-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
    Signed-off-by: Will Deacon <will@kernel.org>

commit 5d892919fdd0cefd361697472d4e1b174a594991
Author: Corentin Labbe <clabbe@baylibre.com>
Date:   Wed Mar 18 15:26:49 2020 +0000

    rtc: max8907: add missing select REGMAP_IRQ
    
    I have hit the following build error:
    
      armv7a-hardfloat-linux-gnueabi-ld: drivers/rtc/rtc-max8907.o: in function `max8907_rtc_probe':
      rtc-max8907.c:(.text+0x400): undefined reference to `regmap_irq_get_virq'
    
    max8907 should select REGMAP_IRQ
    
    Fixes: 94c01ab6d7544 ("rtc: add MAX8907 RTC driver")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 7883a14339299773b2ce08dcfd97c63c199a9289
Author: Mikhail Petrov <Mikhail.Petrov@mir.dev>
Date:   Wed Mar 11 23:37:09 2020 +0300

    scripts/kallsyms: fix wrong kallsyms_relative_base
    
    There is the code in the read_symbol function in 'scripts/kallsyms.c':
    
            if (is_ignored_symbol(name, type))
                    return NULL;
    
            /* Ignore most absolute/undefined (?) symbols. */
            if (strcmp(name, "_text") == 0)
                    _text = addr;
    
    But the is_ignored_symbol function returns true for name="_text" and
    type='A'. So the next condition is not executed and the _text variable
    is always zero.
    
    It makes the wrong kallsyms_relative_base symbol as a result of the code
    (CONFIG_KALLSYMS_BASE_RELATIVE is defined):
    
            if (base_relative) {
                    output_label("kallsyms_relative_base");
                    output_address(relative_base);
                    printf("\n");
            }
    
    Because the output_address function uses the _text variable.
    
    So the kallsyms_lookup function and all related functions in the kernel
    do not work properly. For example, the stack trace in oops:
    
     Call Trace:
     [aa095e58] [809feab8] kobj_ns_ops_tbl+0x7ff09ac8/0x7ff1c1c4 (unreliable)
     [aa095e98] [80002b64] kobj_ns_ops_tbl+0x7f50db74/0x80000010
     [aa095ef8] [809c3d24] kobj_ns_ops_tbl+0x7feced34/0x7ff1c1c4
     [aa095f28] [80002ed0] kobj_ns_ops_tbl+0x7f50dee0/0x80000010
     [aa095f38] [8000f238] kobj_ns_ops_tbl+0x7f51a248/0x80000010
    
    The right stack trace:
    
     Call Trace:
     [aa095e58] [809feab8] module_vdu_video_init+0x2fc/0x3bc (unreliable)
     [aa095e98] [80002b64] do_one_initcall+0x40/0x1f0
     [aa095ef8] [809c3d24] kernel_init_freeable+0x164/0x1d8
     [aa095f28] [80002ed0] kernel_init+0x14/0x124
     [aa095f38] [8000f238] ret_from_kernel_thread+0x14/0x1c
    
    [masahiroy@kernel.org:
    
    This issue happens on binutils <= 2.22
    The following commit fixed it:
    https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d2667025dd30611514810c28bee9709e4623012a
    
    The symbol type of _text is 'T' on binutils >= 2.23
    The minimal supported binutils version for the kernel build is 2.21
    ]
    
    Signed-off-by: Mikhail Petrov <Mikhail.Petrov@mir.dev>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

commit c83557859eaa1286330a4d3d2e1ea0c0988c4604
Author: Will Deacon <will@kernel.org>
Date:   Wed Mar 18 20:38:29 2020 +0000

    arm64: kpti: Fix "kpti=off" when KASLR is enabled
    
    Enabling KASLR forces the use of non-global page-table entries for kernel
    mappings, as this is a decision that we have to make very early on before
    mapping the kernel proper. When used in conjunction with the "kpti=off"
    command-line option, it is possible to use non-global kernel mappings but
    with the kpti trampoline disabled.
    
    Since commit 09e3c22a86f6 ("arm64: Use a variable to store non-global
    mappings decision"), arm64_kernel_unmapped_at_el0() reflects only the use of
    non-global mappings and does not take into account whether the kpti
    trampoline is enabled. This breaks context switching of the TPIDRRO_EL0
    register for 64-bit tasks, where the clearing of the register is deferred to
    the ret-to-user code, but it also breaks the ARM SPE PMU driver which
    helpfully recommends passing "kpti=off" on the command line!
    
    Report whether or not KPTI is actually enabled in
    arm64_kernel_unmapped_at_el0() and check the 'arm64_use_ng_mappings' global
    variable directly when determining the protection flags for kernel mappings.
    
    Cc: Mark Brown <broonie@kernel.org>
    Reported-by: Hongbo Yao <yaohongbo@huawei.com>
    Tested-by: Hongbo Yao <yaohongbo@huawei.com>
    Fixes: 09e3c22a86f6 ("arm64: Use a variable to store non-global mappings decision")
    Signed-off-by: Will Deacon <will@kernel.org>

commit a3c33e7a4a116f8715c0ef0e668e6aeff009c762
Author: James Zhu <James.Zhu@amd.com>
Date:   Wed Mar 18 17:12:12 2020 -0400

    drm/amdgpu: fix typo for vcn2.5/jpeg2.5 idle check
    
    fix typo for vcn2.5/jpeg2.5 idle check
    
    Signed-off-by: James Zhu <James.Zhu@amd.com>
    Reviewed-by: Leo Liu <leo.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

commit b5689d22aa6d815f29d34f8cbd708f9d34eed70a
Author: James Zhu <James.Zhu@amd.com>
Date:   Wed Mar 18 17:10:56 2020 -0400

    drm/amdgpu: fix typo for vcn2/jpeg2 idle check
    
    fix typo for vcn2/jpeg2 idle check
    
    Signed-off-by: James Zhu <James.Zhu@amd.com>
    Reviewed-by: Leo Liu <leo.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

commit acfc62dc68770aa665cc606891f6df7d6d1e52c0
Author: James Zhu <James.Zhu@amd.com>
Date:   Wed Mar 18 17:09:05 2020 -0400

    drm/amdgpu: fix typo for vcn1 idle check
    
    fix typo for vcn1 idle check
    
    Signed-off-by: James Zhu <James.Zhu@amd.com>
    Reviewed-by: Leo Liu <leo.liu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

commit dcf23ac3e846ca0cf626c155a0e3fcbbcf4fae8a
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Mar 18 07:52:21 2020 -0400

    locks: reinstate locks_delete_block optimization
    
    There is measurable performance impact in some synthetic tests due to
    commit 6d390e4b5d48 (locks: fix a potential use-after-free problem when
    wakeup a waiter). Fix the race condition instead by clearing the
    fl_blocker pointer after the wake_up, using explicit acquire/release
    semantics.
    
    This does mean that we can no longer use the clearing of fl_blocker as
    the wait condition, so switch the waiters over to checking whether the
    fl_blocked_member list_head is empty.
    
    Reviewed-by: yangerkun <yangerkun@huawei.com>
    Reviewed-by: NeilBrown <neilb@suse.de>
    Fixes: 6d390e4b5d48 (locks: fix a potential use-after-free problem when wakeup a waiter)
    Signed-off-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 4b8a5cfb5fd375cf4c7502a18f0096ed2881be27
Author: Xiao Yang <yangx.jy@cn.fujitsu.com>
Date:   Wed Mar 18 18:34:16 2020 +0800

    modpost: Get proper section index by get_secindex() instead of st_shndx
    
    (uint16_t) st_shndx is limited to 65535(i.e. SHN_XINDEX) so sym_get_data() gets
    wrong section index by st_shndx if requested symbol contains extended section
    index that is more than 65535.  In this case, we need to get proper section index
    by .symtab_shndx section.
    
    Module.symvers generated by building kernel with "-ffunction-sections -fdata-sections"
    shows the issue.
    
    Fixes: 56067812d5b0 ("kbuild: modversions: add infrastructure for emitting relative CRCs")
    Fixes: e84f9fbbece1 ("modpost: refactor namespace_from_kstrtabns() to not hard-code section name")
    Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

commit 5076190daded2197f62fe92cf69674488be44175
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Tue Mar 17 11:04:09 2020 -0700

    mm: slub: be more careful about the double cmpxchg of freelist
    
    This is just a cleanup addition to Jann's fix to properly update the
    transaction ID for the slub slowpath in commit fd4d9c7d0c71 ("mm: slub:
    add missing TID bump..").
    
    The transaction ID is what protects us against any concurrent accesses,
    but we should really also make sure to make the 'freelist' comparison
    itself always use the same freelist value that we then used as the new
    next free pointer.
    
    Jann points out that if we do all of this carefully, we could skip the
    transaction ID update for all the paths that only remove entries from
    the lists, and only update the TID when adding entries (to avoid the ABA
    issue with cmpxchg and list handling re-adding a previously seen value).
    
    But this patch just does the "make sure to cmpxchg the same value we
    used" rather than then try to be clever.
    
    Acked-by: Jann Horn <jannh@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit fd4d9c7d0c71866ec0c2825189ebd2ce35bd95b8
Author: Jann Horn <jannh@google.com>
Date:   Tue Mar 17 01:28:45 2020 +0100

    mm: slub: add missing TID bump in kmem_cache_alloc_bulk()
    
    When kmem_cache_alloc_bulk() attempts to allocate N objects from a percpu
    freelist of length M, and N > M > 0, it will first remove the M elements
    from the percpu freelist, then call ___slab_alloc() to allocate the next
    element and repopulate the percpu freelist. ___slab_alloc() can re-enable
    IRQs via allocate_slab(), so the TID must be bumped before ___slab_alloc()
    to properly commit the freelist head change.
    
    Fix it by unconditionally bumping c->tid when entering the slowpath.
    
    Cc: stable@vger.kernel.org
    Fixes: ebe909e0fdb3 ("slub: improve bulk alloc strategy")
    Signed-off-by: Jann Horn <jannh@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit b216a8e7908cd750550c0480cf7d2b3a37f06954
Author: Qiujun Huang <hqjagain@gmail.com>
Date:   Wed Mar 18 15:53:50 2020 +0800

    drm/lease: fix WARNING in idr_destroy
    
    drm_lease_create takes ownership of leases. And leases will be released
    by drm_master_put.
    
    drm_master_put
        ->drm_master_destroy
                ->idr_destroy
    
    So we needn't call idr_destroy again.
    
    Reported-and-tested-by: syzbot+05835159fe322770fe3d@syzkaller.appspotmail.com
    Signed-off-by: Qiujun Huang <hqjagain@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/1584518030-4173-1-git-send-email-hqjagain@gmail.com

commit 6e622cd8bd888c7fa3ee2b7dfb3514ab53b21570
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Feb 24 10:20:44 2020 -0800

    tty: fix compat TIOCGSERIAL checking wrong function ptr
    
    Commit 77654350306a ("take compat TIOC[SG]SERIAL treatment into
    tty_compat_ioctl()") changed the compat version of TIOCGSERIAL to start
    checking for the presence of the ->set_serial function pointer rather
    than ->get_serial.  This appears to be a copy-and-paste error, since
    ->get_serial is the function pointer that is called as well as the
    pointer that is checked by the non-compat version of TIOCGSERIAL.
    
    Fix this by checking the correct function pointer.
    
    Fixes: 77654350306a ("take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl()")
    Cc: <stable@vger.kernel.org> # v4.20+
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Acked-by: Jiri Slaby <jslaby@suse.cz>
    Link: https://lore.kernel.org/r/20200224182044.234553-3-ebiggers@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17329563a97df3ba474eca5037c1336e46e14ff8
Author: Eric Biggers <ebiggers@google.com>
Date:   Mon Feb 24 10:20:43 2020 -0800

    tty: fix compat TIOCGSERIAL leaking uninitialized memory
    
    Commit 77654350306a ("take compat TIOC[SG]SERIAL treatment into
    tty_compat_ioctl()") changed the compat version of TIOCGSERIAL to start
    copying a whole 'serial_struct32' to userspace rather than individual
    fields, but failed to initialize all padding and fields -- namely the
    hole after the 'iomem_reg_shift' field, and the 'reserved' field.
    
    Fix this by initializing the struct to zero.
    
    [v2: use sizeof, and convert the adjacent line for consistency.]
    
    Reported-by: syzbot+8da9175e28eadcb203ce@syzkaller.appspotmail.com
    Fixes: 77654350306a ("take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl()")
    Cc: <stable@vger.kernel.org> # v4.20+
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Acked-by: Jiri Slaby <jslaby@suse.cz>
    Link: https://lore.kernel.org/r/20200224182044.234553-2-ebiggers@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ed069827ca70af057caf21c395f76c2c0b82d429
Author: Eric Biggers <ebiggers@google.com>
Date:   Sun Feb 23 23:33:59 2020 -0800

    tty: drop outdated comments about release_tty() locking
    
    The current version of the TTY code unlocks the tty_struct(s) before
    release_tty() rather than after.  Moreover, tty_unlock_pair() no longer
    exists.  Thus, remove the outdated comments regarding tty_unlock_pair().
    
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Link: https://lore.kernel.org/r/20200224073359.292795-1-ebiggers@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4686392c32361c97e8434adf9cc77ad7991bfa81
Author: Ricky Wu <ricky_wu@realtek.com>
Date:   Mon Mar 16 10:52:32 2020 +0800

    mmc: rtsx_pci: Fix support for speed-modes that relies on tuning
    
    The TX/RX register should not be treated the same way to allow for better
    support of tuning. Fix this by using a default initial value for TX.
    
    Signed-off-by: Ricky Wu <ricky_wu@realtek.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20200316025232.1167-1-ricky_wu@realtek.com
    [Ulf: Updated changelog]
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit add492d2e9446a77ede9bb43699ec85ca8fc1aba
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Tue Mar 17 08:22:15 2020 +0200

    intel_th: pci: Add Elkhart Lake CPU support
    
    This adds support for the Trace Hub in Elkhart Lake CPU.
    
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20200317062215.15598-7-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ce666be89a8a09c5924ff08fc32e119f974bdab6
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Tue Mar 17 08:22:14 2020 +0200

    intel_th: Fix user-visible error codes
    
    There are a few places in the driver that end up returning ENOTSUPP to
    the user, replace those with EINVAL.
    
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Fixes: ba82664c134ef ("intel_th: Add Memory Storage Unit driver")
    Cc: stable@vger.kernel.org # v4.4+
    Link: https://lore.kernel.org/r/20200317062215.15598-6-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 885f123554bbdc1807ca25a374be6e9b3bddf4de
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Tue Mar 17 08:22:13 2020 +0200

    intel_th: msu: Fix the unexpected state warning
    
    The unexpected state warning should only warn on illegal state
    transitions. Fix that.
    
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Fixes: 615c164da0eb4 ("intel_th: msu: Introduce buffer interface")
    Cc: stable@vger.kernel.org # v5.4+
    Link: https://lore.kernel.org/r/20200317062215.15598-5-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 283f87c0d5d32b4a5c22636adc559bca82196ed3
Author: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date:   Tue Mar 17 08:22:11 2020 +0200

    stm class: sys-t: Fix the use of time_after()
    
    The operands of time_after() are in a wrong order in both instances in
    the sys-t driver. Fix that.
    
    Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
    Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Fixes: 39f10239df75 ("stm class: p_sys-t: Add support for CLOCKSYNC packets")
    Fixes: d69d5e83110f ("stm class: Add MIPI SyS-T protocol support")
    Cc: stable@vger.kernel.org # v4.20+
    Link: https://lore.kernel.org/r/20200317062215.15598-3-alexander.shishkin@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f50b7dacccbab2b9e3ef18f52a6dcc18ed2050b9
Author: Cristian Marussi <cristian.marussi@arm.com>
Date:   Wed Mar 11 17:12:45 2020 +0000

    arm64: smp: fix crash_smp_send_stop() behaviour
    
    On a system configured to trigger a crash_kexec() reboot, when only one CPU
    is online and another CPU panics while starting-up, crash_smp_send_stop()
    will fail to send any STOP message to the other already online core,
    resulting in fail to freeze and registers not properly saved.
    
    Moreover even if the proper messages are sent (case CPUs > 2)
    it will similarly fail to account for the booting CPU when executing
    the final stop wait-loop, so potentially resulting in some CPU not
    been waited for shutdown before rebooting.
    
    A tangible effect of this behaviour can be observed when, after a panic
    with kexec enabled and loaded, on the following reboot triggered by kexec,
    the cpu that could not be successfully stopped fails to come back online:
    
    [  362.291022] ------------[ cut here ]------------
    [  362.291525] kernel BUG at arch/arm64/kernel/cpufeature.c:886!
    [  362.292023] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
    [  362.292400] Modules linked in:
    [  362.292970] CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Not tainted 5.6.0-rc4-00003-gc780b890948a #105
    [  362.293136] Hardware name: Foundation-v8A (DT)
    [  362.293382] pstate: 200001c5 (nzCv dAIF -PAN -UAO)
    [  362.294063] pc : has_cpuid_feature+0xf0/0x348
    [  362.294177] lr : verify_local_elf_hwcaps+0x84/0xe8
    [  362.294280] sp : ffff800011b1bf60
    [  362.294362] x29: ffff800011b1bf60 x28: 0000000000000000
    [  362.294534] x27: 0000000000000000 x26: 0000000000000000
    [  362.294631] x25: 0000000000000000 x24: ffff80001189a25c
    [  362.294718] x23: 0000000000000000 x22: 0000000000000000
    [  362.294803] x21: ffff8000114aa018 x20: ffff800011156a00
    [  362.294897] x19: ffff800010c944a0 x18: 0000000000000004
    [  362.294987] x17: 0000000000000000 x16: 0000000000000000
    [  362.295073] x15: 00004e53b831ae3c x14: 00004e53b831ae3c
    [  362.295165] x13: 0000000000000384 x12: 0000000000000000
    [  362.295251] x11: 0000000000000000 x10: 00400032b5503510
    [  362.295334] x9 : 0000000000000000 x8 : ffff800010c7e204
    [  362.295426] x7 : 00000000410fd0f0 x6 : 0000000000000001
    [  362.295508] x5 : 00000000410fd0f0 x4 : 0000000000000000
    [  362.295592] x3 : 0000000000000000 x2 : ffff8000100939d8
    [  362.295683] x1 : 0000000000180420 x0 : 0000000000180480
    [  362.296011] Call trace:
    [  362.296257]  has_cpuid_feature+0xf0/0x348
    [  362.296350]  verify_local_elf_hwcaps+0x84/0xe8
    [  362.296424]  check_local_cpu_capabilities+0x44/0x128
    [  362.296497]  secondary_start_kernel+0xf4/0x188
    [  362.296998] Code: 52805001 72a00301 6b01001f 54000ec0 (d4210000)
    [  362.298652] SMP: stopping secondary CPUs
    [  362.300615] Starting crashdump kernel...
    [  362.301168] Bye!
    [    0.000000] Booting Linux on physical CPU 0x0000000003 [0x410fd0f0]
    [    0.000000] Linux version 5.6.0-rc4-00003-gc780b890948a (crimar01@e120937-lin) (gcc version 8.3.0 (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36))) #105 SMP PREEMPT Fri Mar 6 17:00:42 GMT 2020
    [    0.000000] Machine model: Foundation-v8A
    [    0.000000] earlycon: pl11 at MMIO 0x000000001c090000 (options '')
    [    0.000000] printk: bootconsole [pl11] enabled
    .....
    [    0.138024] rcu: Hierarchical SRCU implementation.
    [    0.153472] its@2f020000: unable to locate ITS domain
    [    0.154078] its@2f020000: Unable to locate ITS domain
    [    0.157541] EFI services will not be available.
    [    0.175395] smp: Bringing up secondary CPUs ...
    [    0.209182] psci: failed to boot CPU1 (-22)
    [    0.209377] CPU1: failed to boot: -22
    [    0.274598] Detected PIPT I-cache on CPU2
    [    0.278707] GICv3: CPU2: found redistributor 1 region 0:0x000000002f120000
    [    0.285212] CPU2: Booted secondary processor 0x0000000001 [0x410fd0f0]
    [    0.369053] Detected PIPT I-cache on CPU3
    [    0.372947] GICv3: CPU3: found redistributor 2 region 0:0x000000002f140000
    [    0.378664] CPU3: Booted secondary processor 0x0000000002 [0x410fd0f0]
    [    0.401707] smp: Brought up 1 node, 3 CPUs
    [    0.404057] SMP: Total of 3 processors activated.
    
    Make crash_smp_send_stop() account also for the online status of the
    calling CPU while evaluating how many CPUs are effectively online: this way
    the right number of STOPs is sent and all other stopped-cores's registers
    are properly saved.
    
    Fixes: 78fd584cdec05 ("arm64: kdump: implement machine_crash_shutdown()")
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
    Signed-off-by: Will Deacon <will@kernel.org>

commit d0bab0c39e32d39a8c5cddca72e5b4a3059fe050
Author: Cristian Marussi <cristian.marussi@arm.com>
Date:   Wed Mar 11 17:12:44 2020 +0000

    arm64: smp: fix smp_send_stop() behaviour
    
    On a system with only one CPU online, when another one CPU panics while
    starting-up, smp_send_stop() will fail to send any STOP message to the
    other already online core, resulting in a system still responsive and
    alive at the end of the panic procedure.
    
    [  186.700083] CPU3: shutdown
    [  187.075462] CPU2: shutdown
    [  187.162869] CPU1: shutdown
    [  188.689998] ------------[ cut here ]------------
    [  188.691645] kernel BUG at arch/arm64/kernel/cpufeature.c:886!
    [  188.692079] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
    [  188.692444] Modules linked in:
    [  188.693031] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.6.0-rc4-00001-g338d25c35a98 #104
    [  188.693175] Hardware name: Foundation-v8A (DT)
    [  188.693492] pstate: 200001c5 (nzCv dAIF -PAN -UAO)
    [  188.694183] pc : has_cpuid_feature+0xf0/0x348
    [  188.694311] lr : verify_local_elf_hwcaps+0x84/0xe8
    [  188.694410] sp : ffff800011b1bf60
    [  188.694536] x29: ffff800011b1bf60 x28: 0000000000000000
    [  188.694707] x27: 0000000000000000 x26: 0000000000000000
    [  188.694801] x25: 0000000000000000 x24: ffff80001189a25c
    [  188.694905] x23: 0000000000000000 x22: 0000000000000000
    [  188.694996] x21: ffff8000114aa018 x20: ffff800011156a38
    [  188.695089] x19: ffff800010c944a0 x18: 0000000000000004
    [  188.695187] x17: 0000000000000000 x16: 0000000000000000
    [  188.695280] x15: 0000249dbde5431e x14: 0262cbe497efa1fa
    [  188.695371] x13: 0000000000000002 x12: 0000000000002592
    [  188.695472] x11: 0000000000000080 x10: 00400032b5503510
    [  188.695572] x9 : 0000000000000000 x8 : ffff800010c80204
    [  188.695659] x7 : 00000000410fd0f0 x6 : 0000000000000001
    [  188.695750] x5 : 00000000410fd0f0 x4 : 0000000000000000
    [  188.695836] x3 : 0000000000000000 x2 : ffff8000100939d8
    [  188.695919] x1 : 0000000000180420 x0 : 0000000000180480
    [  188.696253] Call trace:
    [  188.696410]  has_cpuid_feature+0xf0/0x348
    [  188.696504]  verify_local_elf_hwcaps+0x84/0xe8
    [  188.696591]  check_local_cpu_capabilities+0x44/0x128
    [  188.696666]  secondary_start_kernel+0xf4/0x188
    [  188.697150] Code: 52805001 72a00301 6b01001f 54000ec0 (d4210000)
    [  188.698639] ---[ end trace 3f12ca47652f7b72 ]---
    [  188.699160] Kernel panic - not syncing: Attempted to kill the idle task!
    [  188.699546] Kernel Offset: disabled
    [  188.699828] CPU features: 0x00004,20c02008
    [  188.700012] Memory Limit: none
    [  188.700538] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
    
    [root@arch ~]# echo Helo
    Helo
    [root@arch ~]# cat /proc/cpuinfo | grep proce
    processor       : 0
    
    Make smp_send_stop() account also for the online status of the calling CPU
    while evaluating how many CPUs are effectively online: this way, the right
    number of STOPs is sent, so enforcing a proper freeze of the system at the
    end of panic even under the above conditions.
    
    Fixes: 08e875c16a16c ("arm64: SMP support")
    Reported-by: Dave Martin <Dave.Martin@arm.com>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
    Signed-off-by: Will Deacon <will@kernel.org>

commit b401f8c4f492cbf74f3f59c9141e5be3071071bb
Author: Anthony Mallet <anthony.mallet@laas.fr>
Date:   Thu Mar 12 14:31:01 2020 +0100

    USB: cdc-acm: fix rounding error in TIOCSSERIAL
    
    By default, tty_port_init() initializes those parameters to a multiple
    of HZ. For instance in line 69 of tty_port.c:
       port->close_delay = (50 * HZ) / 100;
    https://github.com/torvalds/linux/blob/master/drivers/tty/tty_port.c#L69
    
    With e.g. CONFIG_HZ = 250 (as this is the case for Ubuntu 18.04
    linux-image-4.15.0-37-generic), the default setting for close_delay is
    thus 125.
    
    When ioctl(fd, TIOCGSERIAL, &s) is executed, the setting returned in
    user space is '12' (125/10). When ioctl(fd, TIOCSSERIAL, &s) is then
    executed with the same setting '12', the value is interpreted as '120'
    which is different from the current setting and a EPERM error may be
    raised by set_serial_info() if !CAP_SYS_ADMIN.
    https://github.com/torvalds/linux/blob/master/drivers/usb/class/cdc-acm.c#L919
    
    Fixes: ba2d8ce9db0a6 ("cdc-acm: implement TIOCSSERIAL to avoid blocking close(2)")
    Signed-off-by: Anthony Mallet <anthony.mallet@laas.fr>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200312133101.7096-2-anthony.mallet@laas.fr
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 633e2b2ded739a34bd0fb1d8b5b871f7e489ea29
Author: Anthony Mallet <anthony.mallet@laas.fr>
Date:   Thu Mar 12 14:31:00 2020 +0100

    USB: cdc-acm: fix close_delay and closing_wait units in TIOCSSERIAL
    
    close_delay and closing_wait are specified in hundredth of a second but stored
    internally in jiffies. Use the jiffies_to_msecs() and msecs_to_jiffies()
    functions to convert from each other.
    
    Signed-off-by: Anthony Mallet <anthony.mallet@laas.fr>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200312133101.7096-1-anthony.mallet@laas.fr
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75d7676ead19b1fbb5e0ee934c9ccddcb666b68c
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Fri Mar 13 13:07:08 2020 +0100

    usb: quirks: add NO_LPM quirk for RTL8153 based ethernet adapters
    
    We have been receiving bug reports that ethernet connections over
    RTL8153 based ethernet adapters stops working after a while with
    errors like these showing up in dmesg when the ethernet stops working:
    
    [12696.189484] r8152 6-1:1.0 enp10s0u1: Tx timeout
    [12702.333456] r8152 6-1:1.0 enp10s0u1: Tx timeout
    [12707.965422] r8152 6-1:1.0 enp10s0u1: Tx timeout
    
    This has been reported on Dell WD15 docks, Belkin USB-C Express Dock 3.1
    docks and with generic USB to ethernet dongles using the RTL8153
    chipsets. Some users have tried adding usbcore.quirks=0bda:8153:k to
    the kernel commandline and all users who have tried this report that
    this fixes this.
    
    Also note that we already have an existing NO_LPM quirk for the RTL8153
    used in the Microsoft Surface Dock (where it uses a different usb-id).
    
    This commit adds a NO_LPM quirk for the generic Realtek RTL8153
    0bda:8153 usb-id, fixing the Tx timeout errors on these devices.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198931
    Cc: stable@vger.kernel.org
    Cc: russianneuromancer@ya.ru
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://lore.kernel.org/r/20200313120708.100339-1-hdegoede@redhat.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7368760d1bcdabf515c41a502568b489de3da683
Author: Peter Chen <peter.chen@nxp.com>
Date:   Mon Mar 16 11:10:34 2020 +0800

    usb: chipidea: udc: fix sleeping function called from invalid context
    
    The code calls pm_runtime_get_sync with irq disabled, it causes below
    warning:
    
    BUG: sleeping function called from invalid context at
    wer/runtime.c:1075
    in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid:
    er/u8:1
    CPU: 1 PID: 37 Comm: kworker/u8:1 Not tainted
    20200304-00181-gbebfd2a5be98 #1588
    Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
    Workqueue: ci_otg ci_otg_work
    [<c010e8bd>] (unwind_backtrace) from [<c010a315>]
    1/0x14)
    [<c010a315>] (show_stack) from [<c0987d29>]
    5/0x94)
    [<c0987d29>] (dump_stack) from [<c013e77f>]
    +0xeb/0x118)
    [<c013e77f>] (___might_sleep) from [<c052fa1d>]
    esume+0x75/0x78)
    [<c052fa1d>] (__pm_runtime_resume) from [<c0627a33>]
    0x23/0x74)
    [<c0627a33>] (ci_udc_pullup) from [<c062fb93>]
    nect+0x2b/0xcc)
    [<c062fb93>] (usb_gadget_connect) from [<c062769d>]
    _connect+0x59/0x104)
    [<c062769d>] (ci_hdrc_gadget_connect) from [<c062778b>]
    ssion+0x43/0x48)
    [<c062778b>] (ci_udc_vbus_session) from [<c062f997>]
    s_connect+0x17/0x9c)
    [<c062f997>] (usb_gadget_vbus_connect) from [<c062634d>]
    bd/0x128)
    [<c062634d>] (ci_otg_work) from [<c0134719>]
    rk+0x149/0x404)
    [<c0134719>] (process_one_work) from [<c0134acb>]
    0xf7/0x3bc)
    [<c0134acb>] (worker_thread) from [<c0139433>]
    x118)
    [<c0139433>] (kthread) from [<c01010bd>]
    (ret_from_fork+0x11/0x34)
    
    Tested-by: Dmitry Osipenko <digetx@gmail.com>
    Cc: <stable@vger.kernel.org> #v5.5
    Fixes: 72dc8df7920f ("usb: chipidea: udc: protect usb interrupt enable")
    Reported-by: Dmitry Osipenko <digetx@gmail.com>
    Signed-off-by: Peter Chen <peter.chen@nxp.com>
    Link: https://lore.kernel.org/r/20200316031034.17847-2-peter.chen@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 979a2665eb6c603ddce0ab374041ab101827b2e7
Author: Murphy Zhou <jencce.kernel@gmail.com>
Date:   Sat Mar 14 11:38:31 2020 +0800

    CIFS: fiemap: do not return EINVAL if get nothing
    
    If we call fiemap on a truncated file with none blocks allocated,
    it makes sense we get nothing from this call. No output means
    no blocks have been counted, but the call succeeded. It's a valid
    response.
    
    Simple example reproducer:
    xfs_io -f 'truncate 2M' -c 'fiemap -v' /cifssch/testfile
    xfs_io: ioctl(FS_IOC_FIEMAP) ["/cifssch/testfile"]: Invalid argument
    
    Signed-off-by: Murphy Zhou <jencce.kernel@gmail.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
    CC: Stable <stable@vger.kernel.org>

commit 1be1fa42ebb73ad8fd67d2c846931361b4e3dd0a
Author: Shyam Prasad N <nspmangalore@gmail.com>
Date:   Mon Mar 9 01:35:09 2020 -0700

    CIFS: Increment num_remote_opens stats counter even in case of smb2_query_dir_first
    
    The num_remote_opens counter keeps track of the number of open files which must be
    maintained by the server at any point. This is a per-tree-connect counter, and the value
    of this counter gets displayed in the /proc/fs/cifs/Stats output as a following...
    
    Open files: 0 total (local), 1 open on server
                                 ^^^^^^^^^^^^^^^^
    As a thumb-rule, we want to increment this counter for each open/create that we
    successfully execute on the server. Similarly, we should decrement the counter when
    we successfully execute a close.
    
    In this case, an increment was being missed in case of smb2_query_dir_first,
    in case of successful open. As a result, we would underflow the counter and we
    could even see the counter go to negative after sufficient smb2_query_dir_first calls.
    
    I tested the stats counter for a bunch of filesystem operations with the fix.
    And it looks like the counter looks correct to me.
    
    I also check if we missed the increments and decrements elsewhere. It does not
    seem so. Few other cases where an open is done and we don't increment the counter are
    the compound calls where the corresponding close is also sent in the request.
    
    Signed-off-by: Shyam Prasad N <nspmangalore@gmail.com>
    CC: Stable <stable@vger.kernel.org>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Reviewed-by: Aurelien Aptel <aaptel@suse.com>
    Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>

commit 39946886fc865a4c26f1b3ea0805936db2d8986d
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Fri Feb 28 12:22:59 2020 +0300

    cifs: potential unintitliazed error code in cifs_getattr()
    
    Smatch complains that "rc" could be uninitialized.
    
        fs/cifs/inode.c:2206 cifs_getattr() error: uninitialized symbol 'rc'.
    
    Changing it to "return 0;" improves readability as well.
    
    Fixes: cc1baf98c8f6 ("cifs: do not ignore the SYNC flags in getattr")
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Steve French <stfrench@microsoft.com>
    Acked-by: Ronnie Sahlberg <lsahlber@redhat.com>

commit a124458a127ccd7629e20cd7bae3e1f758ed32aa
Author: Jian-Hong Pan <jian-hong@endlessm.com>
Date:   Tue Mar 17 16:28:09 2020 +0800

    ALSA: hda/realtek - Enable the headset of Acer N50-600 with ALC662
    
    A headset on the desktop like Acer N50-600 does not work, until quirk
    ALC662_FIXUP_ACER_NITRO_HEADSET_MODE is applied.
    
    Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200317082806.73194-3-jian-hong@endlessm.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit d858c706bdca97698752bd26b60c21ec07ef04f2
Author: Jian-Hong Pan <jian-hong@endlessm.com>
Date:   Tue Mar 17 16:28:07 2020 +0800

    ALSA: hda/realtek - Enable headset mic of Acer X2660G with ALC662
    
    The Acer desktop X2660G with ALC662 can't detect the headset microphone
    until ALC662_FIXUP_ACER_X2660G_HEADSET_MODE quirk applied.
    
    Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200317082806.73194-2-jian-hong@endlessm.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit bb5786b9286c253557a0115bc8d21879e61b7b94
Author: Michael Straube <straube.linux@gmail.com>
Date:   Thu Mar 12 10:36:52 2020 +0100

    staging: rtl8188eu: Add device id for MERCUSYS MW150US v2
    
    This device was added to the stand-alone driver on github.
    Add it to the staging driver as well.
    
    Link: https://github.com/lwfinger/rtl8188eu/commit/2141f244c3e7
    Signed-off-by: Michael Straube <straube.linux@gmail.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200312093652.13918-1-straube.linux@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae62cf5eb2792d9a818c2d93728ed92119357017
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Mar 12 12:01:51 2020 +0100

    staging: greybus: loopback_test: fix potential path truncations
    
    Newer GCC warns about possible truncations of two generated path names as
    we're concatenating the configurable sysfs and debugfs path prefixes
    with a filename and placing the results in buffers of the same size as
    the maximum length of the prefixes.
    
            snprintf(d->name, MAX_STR_LEN, "gb_loopback%u", dev_id);
    
            snprintf(d->sysfs_entry, MAX_SYSFS_PATH, "%s%s/",
                     t->sysfs_prefix, d->name);
    
            snprintf(d->debugfs_entry, MAX_SYSFS_PATH, "%sraw_latency_%s",
                     t->debugfs_prefix, d->name);
    
    Fix this by separating the maximum path length from the maximum prefix
    length and reducing the latter enough to fit the generated strings.
    
    Note that we also need to reduce the device-name buffer size as GCC
    isn't smart enough to figure out that we ever only used MAX_STR_LEN
    bytes of it.
    
    Fixes: 6b0658f68786 ("greybus: tools: Add tools directory to greybus repo and add loopback")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20200312110151.22028-4-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f16023834863932f95dfad13fac3fc47f77d2f29
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Mar 12 12:01:50 2020 +0100

    staging: greybus: loopback_test: fix potential path truncation
    
    Newer GCC warns about a possible truncation of a generated sysfs path
    name as we're concatenating a directory path with a file name and
    placing the result in a buffer that is half the size of the maximum
    length of the directory path (which is user controlled).
    
    loopback_test.c: In function 'open_poll_files':
    loopback_test.c:651:31: warning: '%s' directive output may be truncated writing up to 511 bytes into a region of size 255 [-Wformat-truncation=]
      651 |   snprintf(buf, sizeof(buf), "%s%s", dev->sysfs_entry, "iteration_count");
          |                               ^~
    loopback_test.c:651:3: note: 'snprintf' output between 16 and 527 bytes into a destination of size 255
      651 |   snprintf(buf, sizeof(buf), "%s%s", dev->sysfs_entry, "iteration_count");
          |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Fix this by making sure the buffer is large enough the concatenated
    strings.
    
    Fixes: 6b0658f68786 ("greybus: tools: Add tools directory to greybus repo and add loopback")
    Fixes: 9250c0ee2626 ("greybus: Loopback_test: use poll instead of inotify")
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20200312110151.22028-3-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8f3675be4bda33adbdc1dd2ab3b6c76a7599a79e
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Mar 12 12:01:49 2020 +0100

    staging: greybus: loopback_test: fix poll-mask build breakage
    
    A scripted conversion from userland POLL* to kernel EPOLL* constants
    mistakingly replaced the poll flags in the loopback_test tool, which
    therefore no longer builds.
    
    Fixes: a9a08845e9ac ("vfs: do bulk POLL* -> EPOLL* replacement")
    Cc: stable <stable@vger.kernel.org>     # 4.16
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20200312110151.22028-2-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 53dd0a7cd65edc83b0c243d1c08377c8b876b2ee
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date:   Sun Mar 15 17:44:25 2020 +0100

    mmc: sdhci-of-at91: fix cd-gpios for SAMA5D2
    
    SAMA5D2x doesn't drive CMD line if GPIO is used as CD line (at least
    SAMA5D27 doesn't). Fix this by forcing card-detect in the module
    if module-controlled CD is not used.
    
    Fixed commit addresses the problem only for non-removable cards. This
    amends it to also cover gpio-cd case.
    
    Cc: stable@vger.kernel.org
    Fixes: 7a1e3f143176 ("mmc: sdhci-of-at91: force card detect value for non removable devices")
    Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Link: https://lore.kernel.org/r/8d10950d9940468577daef4772b82a071b204716.1584290561.git.mirq-linux@rere.qmqm.pl
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

commit 18b587b45c13bb6a07ed0edac15f06892593d07a
Author: Masahiro Yamada <yamada.masahiro@socionext.com>
Date:   Thu Mar 12 19:42:57 2020 +0900

    mmc: sdhci-cadence: set SDHCI_QUIRK2_PRESET_VALUE_BROKEN for UniPhier
    
    The SDHCI_PRESET_FOR_* registers are not set for the UniPhier platform
    integration. (They are all read as zeros).
    
    Set the SDHCI_QUIRK2_PRESET_VALUE_BROKEN quirk flag. Otherwise, the
    High Speed DDR mode on the eMMC controller (MMC_TIMING_MMC_DDR52)
    would not work.
    
    I split the platform data to give no impact to other platforms,
    although the UniPhier platform is currently only the upstream user
    of this IP.
    
    The SDHCI_QUIRK2_PRESET_VALUE_BROKEN flag is set if the compatible
    string matches to "socionext,uniphier-sd4hc".
    
    Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20200312104257.21017-1-yamada.masahiro@socionext.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

commit 3397b251ea02003f47f0b1667f3fe30bb4f9ce90
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Mar 16 19:47:53 2020 +0100

    mmc: sdhci-acpi: Disable write protect detection on Acer Aspire Switch 10 (SW5-012)
    
    On the Acer Aspire Switch 10 (SW5-012) microSD slot always reports the card
    being write-protected even though microSD cards do not have a write-protect
    switch at all.
    
    Add a new DMI_QUIRK_SD_NO_WRITE_PROTECT quirk which when set sets
    the MMC_CAP2_NO_WRITE_PROTECT flag on the controller for the external SD
    slot; and add a DMI quirk table entry which selects this quirk for the
    Acer SW5-012.
    
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20200316184753.393458-2-hdegoede@redhat.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

commit 84d49b3d08a1d33690cc159036f381c31c27c17b
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Mon Mar 16 19:47:52 2020 +0100

    mmc: sdhci-acpi: Switch signal voltage back to 3.3V on suspend on external microSD on Lenovo Miix 320
    
    Based on a sample of 7 DSDTs from Cherry Trail devices using an AXP288
    PMIC depending on the design one of 2 possible LDOs on the PMIC is used
    for the MMC signalling voltage, either DLDO3 or GPIO1LDO (GPIO1 pin in
    low noise LDO mode).
    
    The Lenovo Miix 320-10ICR uses GPIO1LDO in the SHC1 ACPI device's DSM
    methods to set 3.3 or 1.8 signalling voltage and this appears to work
    as advertised, so presumably the device is actually using GPIO1LDO for
    the external microSD signalling voltage.
    
    But this device has a bug in the _PS0 method of the SHC1 ACPI device,
    the DSM remembers the last set signalling voltage and the _PS0 restores
    this after a (runtime) suspend-resume cycle, but it "restores" the voltage
    on DLDO3 instead of setting it on GPIO1LDO as the DSM method does. DLDO3
    is used for the LCD and setting it to 1.8V causes the LCD to go black.
    
    This commit works around this issue by calling the Intel DSM to reset the
    signal voltage to 3.3V after the host has been runtime suspended.
    This will make the _PS0 method reprogram the DLDO3 voltage to 3.3V, which
    leaves it at its original setting fixing the LCD going black.
    
    This commit adds and uses a DMI quirk mechanism to only trigger this
    workaround on the Lenovo Miix 320 while leaving the behavior of the
    driver unchanged on other devices.
    
    BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=111294
    BugLink: https://gitlab.freedesktop.org/drm/intel/issues/355
    Reported-by: russianneuromancer <russianneuromancer@ya.ru>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20200316184753.393458-1-hdegoede@redhat.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

commit 785d74ec3bbf26ac7f6e92e6e96a259aec0f107a
Author: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Date:   Mon Mar 16 14:25:19 2020 +0300

    initramfs: restore default compression behavior
    
    Even though INITRAMFS_SOURCE kconfig option isn't set in most of
    defconfigs it is used (set) extensively by various build systems.
    Commit f26661e12765 ("initramfs: make initramfs compression choice
    non-optional") has changed default compression mode. Previously we
    compress initramfs using available compression algorithm. Now
    we don't use any compression at all by default.
    It significantly increases the image size in case of build system
    chooses embedded initramfs. Initially I faced with this issue while
    using buildroot.
    
    As of today it's not possible to set preferred compression mode
    in target defconfig as this option depends on INITRAMFS_SOURCE
    being set. Modification of all build systems either doesn't look
    like good option.
    
    Let's instead rewrite initramfs compression mode choices list
    the way that "INITRAMFS_COMPRESSION_NONE" will be the last option
    in the list. In that case it will be chosen only if all other
    options (which implements any compression) are not available.
    
    Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

commit 5190044c2965514a973184ca68ef5fad57a24670
Author: Jessica Yu <jeyu@kernel.org>
Date:   Wed Mar 11 18:01:20 2020 +0100

    modpost: move the namespace field in Module.symvers last
    
    In order to preserve backwards compatability with kmod tools, we have to
    move the namespace field in Module.symvers last, as the depmod -e -E
    option looks at the first three fields in Module.symvers to check symbol
    versions (and it's expected they stay in the original order of crc,
    symbol, module).
    
    In addition, update an ancient comment above read_dump() in modpost that
    suggested that the export type field in Module.symvers was optional. I
    suspect that there were historical reasons behind that comment that are
    no longer accurate. We have been unconditionally printing the export
    type since 2.6.18 (commit bd5cbcedf44), which is over a decade ago now.
    
    Fix up read_dump() to treat each field as non-optional. I suspect the
    original read_dump() code treated the export field as optional in order
    to support pre <= 2.6.18 Module.symvers (which did not have the export
    type field). Note that although symbol namespaces are optional, the
    field will not be omitted from Module.symvers if a symbol does not have
    a namespace. In this case, the field will simply be empty and the next
    delimiter or end of line will follow.
    
    Cc: stable@vger.kernel.org
    Fixes: cb9b55d21fe0 ("modpost: add support for symbol namespaces")
    Tested-by: Matthias Maennich <maennich@google.com>
    Reviewed-by: Matthias Maennich <maennich@google.com>
    Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
    Signed-off-by: Jessica Yu <jeyu@kernel.org>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

commit 819d578d51d0ce73f06e35d69395ef55cd683a74
Author: Tony Fischetti <tony.fischetti@gmail.com>
Date:   Thu Mar 12 12:16:06 2020 -0400

    HID: add ALWAYS_POLL quirk to lenovo pixart mouse
    
    A lenovo pixart mouse (17ef:608d) is afflicted common the the malfunction
    where it disconnects and reconnects every minute--each time incrementing
    the device number. This patch adds the device id of the device and
    specifies that it needs the HID_QUIRK_ALWAYS_POLL quirk in order to
    work properly.
    
    Signed-off-by: Tony Fischetti <tony.fischetti@gmail.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit 58322a1590fc189a8e1e349d309637d4a4942840
Author: Chen-Tsung Hsieh <chentsung@chromium.org>
Date:   Mon Mar 16 15:24:19 2020 +0800

    HID: google: add moonball USB id
    
    Add 1 additional hammer-like device.
    
    Signed-off-by: Chen-Tsung Hsieh <chentsung@chromium.org>
    Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>

commit fe8b7085cac3b0db03cdbb26d9309bc27325df0a
Author: Matt Roper <matthew.d.roper@intel.com>
Date:   Wed Mar 11 09:22:55 2020 -0700

    drm/i915: Handle all MCR ranges
    
    The bspec documents multiple MCR ranges; make sure they're all captured
    by the driver.
    
    Bspec: 13991, 52079
    Fixes: 592a7c5e082e ("drm/i915: Extend non readable mcr range")
    Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
    Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200311162300.1838847-2-matthew.d.roper@intel.com
    Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
    (cherry picked from commit 415d1269975d3fc21c13a6ae8de7b5fe0e6febb1)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>

commit c09f6b4d0883dfb859c1ddcfb04c3260ef310ce0
Author: Caz Yokoyama <caz.yokoyama@intel.com>
Date:   Wed Mar 4 14:13:59 2020 -0800

    Revert "drm/i915/tgl: Add extra hdc flush workaround"
    
    This reverts commit 36a6b5d964d995b536b1925ec42052ee40ba92c4.
    
    The commit takes care Wa_1604544889 which was fixed on a0 stepping based on
    a0 replan. So no SW workaround is required on any stepping now.
    
    Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
    Signed-off-by: Caz Yokoyama <caz.yokoyama@intel.com>
    Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
    Fixes: 36a6b5d964d9 ("drm/i915/tgl: Add extra hdc flush workaround")
    Link: https://patchwork.freedesktop.org/patch/msgid/1c751032ce79c80c5485cae315f1a9904ce07cac.1583359940.git.caz.yokoyama@intel.com
    (cherry picked from commit 175c4d9b3b9a60b4ea0b8cd034011808c6a03b05)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>

commit 9777d8b2d2a148bc5d46694ec4f2559282fec8cf
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Mar 11 09:26:23 2020 +0000

    drm/i915/execlists: Track active elements during dequeue
    
    Record the initial active element we use when building the next ELSP
    submission, so that we can compare against it latter to see if there's
    no change.
    
    Fixes: 44d0a9c05bc0 ("drm/i915/execlists: Skip redundant resubmission")
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200311092624.10012-2-chris@chris-wilson.co.uk
    (cherry picked from commit 60ef5b7ac6a131f09d287a5f156c878c2c926a30)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>

commit 6c3171ef76a0bad892050f6959a7eac02fb16df7
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Mar 16 10:05:06 2020 +0100

    ALSA: seq: oss: Fix running status after receiving sysex
    
    This is a similar bug like the previous case for virmidi: the invalid
    running status is kept after receiving a sysex message.
    
    Again the fix is to clear the running status after handling the sysex.
    
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/3b4a4e0f232b7afbaf0a843f63d0e538e3029bfd.camel@domdv.de
    Link: https://lore.kernel.org/r/20200316090506.23966-3-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit 4384f167ce5fa7241b61bb0984d651bc528ddebe
Author: Takashi Iwai <tiwai@suse.de>
Date:   Mon Mar 16 10:05:05 2020 +0100

    ALSA: seq: virmidi: Fix running status after receiving sysex
    
    The virmidi driver handles sysex event exceptionally in a short-cut
    snd_seq_dump_var_event() call, but this missed the reset of the
    running status.  As a result, it may lead to an incomplete command
    right after the sysex when an event with the same running status was
    queued.
    
    Fix it by clearing the running status properly via alling
    snd_midi_event_reset_decode() for that code path.
    
    Reported-by: Andreas Steinmetz <ast@domdv.de>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/3b4a4e0f232b7afbaf0a843f63d0e538e3029bfd.camel@domdv.de
    Link: https://lore.kernel.org/r/20200316090506.23966-2-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

commit 82f2bc2fcc0160d6f82dd1ac64518ae0a4dd183f
Author: Nathan Chancellor <natechancellor@gmail.com>
Date:   Wed Mar 11 12:41:21 2020 -0700

    kbuild: Disable -Wpointer-to-enum-cast
    
    Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
    casting to enums. The kernel does this in certain places, such as device
    tree matches to set the version of the device being used, which allows
    the kernel to avoid using a gigantic union.
    
    https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
    https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
    https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264
    
    To avoid a ton of false positive warnings, disable this particular part
    of the warning, which has been split off into a separate diagnostic so
    that the entire warning does not need to be turned off for clang. It
    will be visible under W=1 in case people want to go about fixing these
    easily and enabling the warning treewide.
    
    Cc: stable@vger.kernel.org
    Link: https://github.com/ClangBuiltLinux/linux/issues/887
    Link: https://github.com/llvm/llvm-project/commit/2a41b31fcdfcb67ab7038fc2ffb606fd50b83a84
    Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

commit 8c34cd1a7f089dc03933289c5d4a4d1489549828
Author: Gerd Hoffmann <kraxel@redhat.com>
Date:   Fri Mar 13 09:41:52 2020 +0100

    drm/bochs: downgrade pci_request_region failure from error to warning
    
    Shutdown of firmware framebuffer has a bunch of problems.  Because
    of this the framebuffer region might still be reserved even after
    drm_fb_helper_remove_conflicting_pci_framebuffers() returned.
    
    Don't consider pci_request_region() failure for the framebuffer
    region as fatal error to workaround this issue.
    
    Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
    Acked-by: Sam Ravnborg <sam@ravnborg.org>
    Link: http://patchwork.freedesktop.org/patch/msgid/20200313084152.2734-1-kraxel@redhat.com

commit dec9de2ada523b344eb2428abfedf9d6cd0a0029
Author: Mario Kleiner <mario.kleiner.de@gmail.com>
Date:   Fri Feb 28 22:36:07 2020 +0100

    drm/amd/display: Add link_rate quirk for Apple 15" MBP 2017
    
    This fixes a problem found on the MacBookPro 2017 Retina panel:
    
    The panel reports 10 bpc color depth in its EDID, and the
    firmware chooses link settings at boot which support enough
    bandwidth for 10 bpc (324000 kbit/sec aka LINK_RATE_RBR2
    aka 0xc), but the DP_MAX_LINK_RATE dpcd register only reports
    2.7 Gbps (multiplier value 0xa) as possible, in direct
    contradiction of what the firmware successfully set up.
    
    This restricts the panel to 8 bpc, not providing the full
    color depth of the panel on Linux <= 5.5. Additionally, commit
    '4a8ca46bae8a ("drm/amd/display: Default max bpc to 16 for eDP")'
    introduced into Linux 5.6-rc1 will unclamp panel depth to
    its full 10 bpc, thereby requiring a eDP bandwidth for all
    modes that exceeds the bandwidth available and causes all modes
    to fail validation -> No modes for the laptop panel -> failure
    to set any mode -> Panel goes dark.
    
    This patch adds a quirk specific to the MBP 2017 15" Retina
    panel to override reported max link rate to the correct maximum
    of 0xc = LINK_RATE_RBR2 to fix the darkness and reduced display
    precision.
    
    Please apply for Linux 5.6+ to avoid regressing Apple MBP panel
    support.
    
    Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

commit 063e768ebd27d3ec0d6908b7f8ea9b0a732b9949
Author: Evan Quan <evan.quan@amd.com>
Date:   Wed Mar 11 14:15:27 2020 +0800

    drm/amdgpu: add fbdev suspend/resume on gpu reset
    
    This can fix the baco reset failure seen on Navi10.
    And this should be a low risk fix as the same sequence
    is already used for system suspend/resume.
    
    Signed-off-by: Evan Quan <evan.quan@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

commit 5bbc6604a62814511c32f2e39bc9ffb2c1b92cbe
Author: Tom St Denis <tom.stdenis@amd.com>
Date:   Tue Mar 10 08:40:41 2020 -0400

    drm/amd/amdgpu: Fix GPR read from debugfs (v2)
    
    The offset into the array was specified in bytes but should
    be in terms of 32-bit words.  Also prevent large reads that
    would also cause a buffer overread.
    
    v2:  Read from correct offset from internal storage buffer.
    
    Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
    Acked-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org

commit b55dbe596942e15b3d18d36a41af4fde022c9d48…
RealAkito added a commit to HarukaNetwork/haruka-workstation-kernel that referenced this issue Mar 22, 2020
Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang. It
will be visible under W=1 in case people want to go about fixing these
easily and enabling the warning treewide.

Cc: stable@vger.kernel.org
Link: ClangBuiltLinux/linux#887
Link: llvm/llvm-project@2a41b31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Albert I <kras@raphielgang.org>
Signed-off-by: Akito Mizukito <akito@evolution-x.org>
RealAkito added a commit to HarukaNetwork/haruka-workstation-kernel that referenced this issue Mar 23, 2020
Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang. It
will be visible under W=1 in case people want to go about fixing these
easily and enabling the warning treewide.

Cc: stable@vger.kernel.org
Link: ClangBuiltLinux/linux#887
Link: llvm/llvm-project@2a41b31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Albert I <kras@raphielgang.org>
Signed-off-by: Akito Mizukito <akito@evolution-x.org>
RealAkito added a commit to HarukaNetwork/haruka-workstation-kernel that referenced this issue Mar 23, 2020
Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang. It
will be visible under W=1 in case people want to go about fixing these
easily and enabling the warning treewide.

Cc: stable@vger.kernel.org
Link: ClangBuiltLinux/linux#887
Link: llvm/llvm-project@2a41b31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Albert I <kras@raphielgang.org>
Signed-off-by: Akito Mizukito <akito@evolution-x.org>
Boos4721 pushed a commit to Boos4721/op6_kernel that referenced this issue Mar 24, 2020
commit 82f2bc2fcc0160d6f82dd1ac64518ae0a4dd183f upstream.

Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang. It
will be visible under W=1 in case people want to go about fixing these
easily and enabling the warning treewide.

Cc: stable@vger.kernel.org
Link: ClangBuiltLinux/linux#887
Link: llvm/llvm-project@2a41b31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Boos4721 pushed a commit to Boos4721/op5_kernel that referenced this issue Mar 24, 2020
commit 82f2bc2fcc0160d6f82dd1ac64518ae0a4dd183f upstream.

Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang. It
will be visible under W=1 in case people want to go about fixing these
easily and enabling the warning treewide.

Cc: stable@vger.kernel.org
Link: ClangBuiltLinux/linux#887
Link: llvm/llvm-project@2a41b31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mrchapp pushed a commit to mrchapp/linux that referenced this issue Mar 24, 2020
commit 82f2bc2 upstream.

Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang. It
will be visible under W=1 in case people want to go about fixing these
easily and enabling the warning treewide.

Cc: stable@vger.kernel.org
Link: ClangBuiltLinux#887
Link: llvm/llvm-project@2a41b31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mrchapp pushed a commit to mrchapp/linux that referenced this issue Mar 24, 2020
commit 82f2bc2 upstream.

Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang. It
will be visible under W=1 in case people want to go about fixing these
easily and enabling the warning treewide.

Cc: stable@vger.kernel.org
Link: ClangBuiltLinux#887
Link: llvm/llvm-project@2a41b31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
UtsavBalar1231 added a commit to UtsavBalar1231/kernel_xiaomi_raphael that referenced this issue Mar 24, 2020
Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang.

Cc: stable@vger.kernel.org
Link: ClangBuiltLinux/linux#887
Link: llvm/llvm-project@2a41b31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Danny Lin <danny@kdrag0n.dev>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
UtsavBalar1231 added a commit to UtsavBalar1231/kernel_xiaomi_raphael that referenced this issue Mar 24, 2020
Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang.

Cc: stable@vger.kernel.org
Link: ClangBuiltLinux/linux#887
Link: llvm/llvm-project@2a41b31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Danny Lin <danny@kdrag0n.dev>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
woodsts pushed a commit to woodsts/linux-stable that referenced this issue Mar 25, 2020
commit 82f2bc2 upstream.

Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang. It
will be visible under W=1 in case people want to go about fixing these
easily and enabling the warning treewide.

Cc: stable@vger.kernel.org
Link: ClangBuiltLinux/linux#887
Link: llvm/llvm-project@2a41b31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
woodsts pushed a commit to woodsts/linux-stable that referenced this issue Mar 25, 2020
commit 82f2bc2 upstream.

Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang. It
will be visible under W=1 in case people want to go about fixing these
easily and enabling the warning treewide.

Cc: stable@vger.kernel.org
Link: ClangBuiltLinux/linux#887
Link: llvm/llvm-project@2a41b31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
woodsts pushed a commit to woodsts/linux-stable that referenced this issue Mar 25, 2020
commit 82f2bc2 upstream.

Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang. It
will be visible under W=1 in case people want to go about fixing these
easily and enabling the warning treewide.

Cc: stable@vger.kernel.org
Link: ClangBuiltLinux/linux#887
Link: llvm/llvm-project@2a41b31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mrchapp pushed a commit to mrchapp/linux that referenced this issue Mar 25, 2020
commit 82f2bc2 upstream.

Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang. It
will be visible under W=1 in case people want to go about fixing these
easily and enabling the warning treewide.

Cc: stable@vger.kernel.org
Link: ClangBuiltLinux#887
Link: llvm/llvm-project@2a41b31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mrchapp pushed a commit to mrchapp/linux that referenced this issue Mar 25, 2020
commit 82f2bc2 upstream.

Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang. It
will be visible under W=1 in case people want to go about fixing these
easily and enabling the warning treewide.

Cc: stable@vger.kernel.org
Link: ClangBuiltLinux#887
Link: llvm/llvm-project@2a41b31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mrchapp pushed a commit to mrchapp/linux that referenced this issue Mar 25, 2020
commit 82f2bc2 upstream.

Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang. It
will be visible under W=1 in case people want to go about fixing these
easily and enabling the warning treewide.

Cc: stable@vger.kernel.org
Link: ClangBuiltLinux#887
Link: llvm/llvm-project@2a41b31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mrchapp pushed a commit to mrchapp/linux that referenced this issue Mar 25, 2020
commit 82f2bc2 upstream.

Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang. It
will be visible under W=1 in case people want to go about fixing these
easily and enabling the warning treewide.

Cc: stable@vger.kernel.org
Link: ClangBuiltLinux#887
Link: llvm/llvm-project@2a41b31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
poad42 pushed a commit to op5-q/kernel_oneplus_msm8998 that referenced this issue Mar 26, 2020
commit 82f2bc2fcc0160d6f82dd1ac64518ae0a4dd183f upstream.

Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang. It
will be visible under W=1 in case people want to go about fixing these
easily and enabling the warning treewide.

Cc: stable@vger.kernel.org
Link: ClangBuiltLinux/linux#887
Link: llvm/llvm-project@2a41b31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mishamyrt added a commit to mishamyrt/davinci-pancake-kernel that referenced this issue Mar 27, 2020
Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang.

Cc: stable@vger.kernel.org
Link: ClangBuiltLinux/linux#887
Link: llvm/llvm-project@2a41b31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
MrArtemSid added a commit to MrArtemSid/android_kernel_xiaomi_santoni that referenced this issue Mar 28, 2020
commit 82f2bc2fcc0160d6f82dd1ac64518ae0a4dd183f upstream.

Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when
casting to enums. The kernel does this in certain places, such as device
tree matches to set the version of the device being used, which allows
the kernel to avoid using a gigantic union.

https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428
https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402
https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264

To avoid a ton of false positive warnings, disable this particular part
of the warning, which has been split off into a separate diagnostic so
that the entire warning does not need to be turned off for clang. It
will be visible under W=1 in case people want to go about fixing these
easily and enabling the warning treewide.

Cc: stable@vger.kernel.org
Link: ClangBuiltLinux/linux#887
Link: llvm/llvm-project@2a41b31
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.