aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2024-06-11drm/panel: sharp-lq101r1sx01: Stop tracking prepared/enabledDouglas Anderson1-39/+0
As talked about in commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. Cc: Thierry Reding <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.17.Ifd6b12b8a4bca7d492e892ea7455e83f5c0ab5a8@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.17.Ifd6b12b8a4bca7d492e892ea7455e83f5c0ab5a8@changeid
2024-06-11drm/panel: seiko-43wvf1g: Don't call disable at shutdown/removeDouglas Anderson1-9/+0
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. A grep through mainline for compatible strings used by this driver indicates that it is used by IMX boards. As far as I can tell, all IMX boards are now correctly calling drm_atomic_helper_shutdown() so we can remove the calls. [1] https://lore.kernel.org/r/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Marco Franchi <[email protected]> Cc: Fabio Estevam <[email protected]> Cc: Laurentiu Palcu <[email protected]> Cc: Pengutronix Kernel Team <[email protected]> Cc: [email protected] Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.16.Ief712fb6720cb98bdf9ec8644362d028b6554f9b@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.16.Ief712fb6720cb98bdf9ec8644362d028b6554f9b@changeid
2024-06-11drm/panel: seiko-43wvf1g: Stop tracking prepared/enabledDouglas Anderson1-40/+0
As talked about in commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. Cc: Marco Franchi <[email protected]> Cc: Fabio Estevam <[email protected]> Cc: Laurentiu Palcu <[email protected]> Cc: Pengutronix Kernel Team <[email protected]> Cc: [email protected] Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.15.Idda91d310ca2e4f5a4ab4ca6eaf1afdaf14eeb51@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.15.Idda91d310ca2e4f5a4ab4ca6eaf1afdaf14eeb51@changeid
2024-06-11drm/panel: panasonic-vvx10f034n00: Don't call disable at shutdown/removeDouglas Anderson1-12/+0
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. Unfortunately, grepping mainline for this panel's compatible string shows no hits, so we can't be 100% sure if the DRM modeset driver used with this panel has been fixed. If it is found that the DRM modeset driver hasn't been fixed then this patch could be temporarily reverted until it is. [1] https://lore.kernel.org/r/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Werner Johansson <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.14.I1562c864ee35a9c166765488c95104b7e4e562da@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.14.I1562c864ee35a9c166765488c95104b7e4e562da@changeid
2024-06-11drm/panel: panasonic-vvx10f034n00: Stop tracking prepared/enabledDouglas Anderson1-34/+1
As talked about in commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. Cc: Werner Johansson <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.13.I7278e956ffd1cf686e737834578d4bb3ea527c7f@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.13.I7278e956ffd1cf686e737834578d4bb3ea527c7f@changeid
2024-06-11drm/panel: jdi-lt070me05000: Don't call disable at shutdown/removeDouglas Anderson1-12/+0
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. A grep through mainline for compatible strings used by this driver indicates that it is used by Qualcomm boards. The Qualcomm driver appears to be correctly calling drm_atomic_helper_shutdown() so we can remove the calls. [1] https://lore.kernel.org/r/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Vinay Simha BN <[email protected]> Cc: Sumit Semwal <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.12.I5f3426e511e77b93c247e0aac114bd12b2b2a933@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.12.I5f3426e511e77b93c247e0aac114bd12b2b2a933@changeid
2024-06-11drm/panel: jdi-lt070me05000: Stop tracking prepared/enabledDouglas Anderson1-25/+2
As talked about in commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. NOTE: as part of this, transition the panel's direct calls to its disable function in shutdown/remove to call through DRM panel. Cc: Vinay Simha BN <[email protected]> Cc: Sumit Semwal <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.11.I2e991044def6644c18ad8d7d686f4f3006f278de@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.11.I2e991044def6644c18ad8d7d686f4f3006f278de@changeid
2024-06-11drm/panel: tdo-tl070wsh30: Don't call unprepare+disable at shutdown/removeDouglas Anderson1-11/+0
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. Unfortunately, grepping mainline for this panel's compatible string shows no hits, so we can't be 100% sure if the DRM modeset driver used with this panel has been fixed. If it is found that the DRM modeset driver hasn't been fixed then this patch could be temporarily reverted until it is. [1] https://lore.kernel.org/r/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Neil Armstrong <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.10.I46ff4e28c260bcd8e81205debd0994e76fd8aeac@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.10.I46ff4e28c260bcd8e81205debd0994e76fd8aeac@changeid
2024-06-11drm/panel: tdo-tl070wsh30: Stop tracking preparedDouglas Anderson1-12/+0
As talked about in commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. Cc: Neil Armstrong <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.9.I5025ab14adc2efeef1be1843648547fb725106be@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.9.I5025ab14adc2efeef1be1843648547fb725106be@changeid
2024-06-11drm/panel: osd-osd101t2587-53ts: Don't call unprepare+disable at shutdown/removeDouglas Anderson1-14/+0
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. A grep through mainline for compatible strings used by this driver indicates that it is used by TI OMAP boards. The OMAP driver appears to be correctly calling drm_atomic_helper_shutdown() so we can remove the calls. [1] https://lore.kernel.org/r/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Peter Ujfalusi <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.8.Ic533ce1323b94230d4155f9364c2b7c1bc47e798@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.8.Ic533ce1323b94230d4155f9364c2b7c1bc47e798@changeid
2024-06-11drm/panel: osd-osd101t2587-53ts: Stop tracking prepared/enabledDouglas Anderson1-26/+1
As talked about in commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. Cc: Peter Ujfalusi <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.7.Ic7f6b4ae48027668940a756090cfc454645d3da4@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.7.Ic7f6b4ae48027668940a756090cfc454645d3da4@changeid
2024-06-11drm/panel: olimex-lcd-olinuxino: Don't call unprepare+disable at removeDouglas Anderson1-3/+0
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. Unfortunately, grepping mainline for this panel's compatible string shows no hits, so we can't be 100% sure if the DRM modeset driver used with this panel has been fixed. If it is found that the DRM modeset driver hasn't been fixed then this patch could be temporarily reverted until it is. [1] https://lore.kernel.org/r/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.6.I4c79deffb7551ecfb0378302f8dee1275fd1c060@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.6.I4c79deffb7551ecfb0378302f8dee1275fd1c060@changeid
2024-06-11drm/panel: olimex-lcd-olinuxino: Stop tracking prepared/enabledDouglas Anderson1-41/+0
As talked about in commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.5.I6a96d762be98321e02f56b5864359258d65d9da8@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.5.I6a96d762be98321e02f56b5864359258d65d9da8@changeid
2024-06-11drm/panel: khadas-ts050: Don't call unprepare+disable at shutdown/removeDouglas Anderson1-11/+0
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. Unfortunately, grepping mainline for this panel's compatible string shows no hits, so we can't be 100% sure if the DRM modeset driver used with this panel has been fixed. If it is found that the DRM modeset driver hasn't been fixed then this patch could be temporarily reverted until it is. [1] https://lore.kernel.org/r/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Jacobe Zang <[email protected]> Cc: Nicolas Belin <[email protected]> Cc: Neil Armstrong <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.4.I1ee65e7905bf5bf46a0e6c5126ac3c7aa25cb80b@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.4.I1ee65e7905bf5bf46a0e6c5126ac3c7aa25cb80b@changeid
2024-06-11drm/panel: khadas-ts050: Stop tracking prepared/enabledDouglas Anderson1-28/+0
As talked about in commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. Cc: Jacobe Zang <[email protected]> Cc: Nicolas Belin <[email protected]> Cc: Neil Armstrong <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.3.Ibed1026f20cab08c90fa376e68c2f23a343e826b@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.3.Ibed1026f20cab08c90fa376e68c2f23a343e826b@changeid
2024-06-11drm/panel: boe-himax8279d: Don't call unprepare+disable at shutdown/removeDouglas Anderson1-17/+0
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. Unfortunately, grepping mainline for this panel's compatible string shows no hits, so we can't be 100% sure if the DRM modeset driver used with this panel has been fixed. If it is found that the DRM modeset driver hasn't been fixed then this patch could be temporarily reverted until it is. [1] https://lore.kernel.org/r/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Jerry Han <[email protected]> Cc: Jitao Shi <[email protected]> Cc: Rock Wang <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.2.I19086c524d38f28f746befe85cb39ffda9d2f666@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.2.I19086c524d38f28f746befe85cb39ffda9d2f666@changeid
2024-06-11drm/panel: boe-himax8279d: Stop tracking prepared/enabledDouglas Anderson1-27/+4
As talked about in commit d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. NOTE: as part of this, transition the panel's direct calls to its disable/unprepare functions in shutdown/remove to call through DRM panel. Cc: Jerry Han <[email protected]> Cc: Jitao Shi <[email protected]> Cc: Rock Wang <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/20240604172305.v3.1.Ia3f254ab6e04e4f7afba6c066454498c8fb01324@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240604172305.v3.1.Ia3f254ab6e04e4f7afba6c066454498c8fb01324@changeid
2024-06-11pinctrl: renesas: rzg2l: Add support for RZ/V2H SoCLad Prabhakar1-3/+371
Add pinctrl driver support for RZ/V2H(P) SoC. Signed-off-by: Lad Prabhakar <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2024-06-11pinctrl: renesas: rzg2l: Acquire lock in rzg2l_pinctrl_pm_setup_pfc()Lad Prabhakar1-0/+3
To keep consistency with rzg2l_pinctrl_set_pfc_mode(), acquire the lock in rzg2l_pinctrl_pm_setup_pfc() during PFC setup. Signed-off-by: Lad Prabhakar <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Tested-by: Claudiu Beznea <[email protected]> # on RZ/G3S Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2024-06-11pinctrl: renesas: rzg2l: Add support for custom parametersLad Prabhakar1-0/+12
In preparation for passing custom params for RZ/V2H(P) SoC assign the custom params that are being passed via struct rzg2l_pinctrl_data. Signed-off-by: Lad Prabhakar <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2024-06-11pinctrl: renesas: rzg2l: Pass pincontrol device to ↵Lad Prabhakar1-1/+1
pinconf_generic_parse_dt_config() Pass the pincontrol device pointer to pinconf_generic_parse_dt_config() in preparation for passing custom params. Signed-off-by: Lad Prabhakar <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Tested-by: Claudiu Beznea <[email protected]> # on RZ/G3S Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2024-06-11pinctrl: renesas: rzg2l: Add support for pull-up/downLad Prabhakar1-0/+72
Add support to configure bias-disable, bias-pull-up, and bias-pull-down properties of the pin. Two new function pointers, hw_to_bias_param() and bias_param_to_hw(), are introduced in the struct rzg2l_pinctrl_data to configure bias settings, as the values in the PUPD register differ when compared to the RZ/G2L family and the RZ/V2H(P) SoC. Value | RZ/G2L | RZ/V2H --------------------------------- 00b: | Bias Disabled | Pull up/down disabled 01b: | Pull-up | Pull up/down disabled 10b: | Pull-down | Pull-down 11b: | Prohibited | Pull-up Signed-off-by: Lad Prabhakar <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2024-06-11pinctrl: renesas: rzg2l: Add support to configure slew-rateLad Prabhakar1-0/+18
Add support to configure slew-rate property of the pin. Signed-off-by: Lad Prabhakar <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2024-06-11pinctrl: renesas: rzg2l: Add function pointers for OEN register accessLad Prabhakar1-2/+10
Introduce function pointers oen_read() and oen_write(), in the struct rzg2l_pinctrl_data to facilitate reading and writing to the PFC_OEN register. On the RZ/V2H(P) SoC, unlocking the PWPR.REGWE_B bit before writing to the PFC_OEN register is necessary, and the PFC_OEN register has more bits compared to the RZ/G2L family. To handle these differences between RZ/G2L and RZ/V2H(P) and to reuse the existing code for RZ/V2H(P), these function pointers are introduced. Additionally, populate these function pointers with appropriate data for existing SoCs. Signed-off-by: Lad Prabhakar <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Tested-by: Claudiu Beznea <[email protected]> # on RZ/G3S Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2024-06-11pinctrl: renesas: rzg2l: Add function pointer for PMC register writeLad Prabhakar1-1/+10
Introduces pmc_writeb() function pointer, in the struct rzg2l_pinctrl_data to facilitate writing to the PMC register. On the RZ/V2H(P) SoC, unlocking the PWPR.REGWE_A bit before writing to PMC registers is required, whereas this is not the case for the existing RZ/G2L family. This addition enables the reuse of existing code for RZ/V2H(P). Additionally, populate this function pointer with appropriate data for existing SoCs. Note that this functionality is only handled in rzg2l_gpio_request(), as PMC unlock/lock during PFC setup will be taken care of in the pwpr_pfc_lock_unlock() function pointer. Signed-off-by: Lad Prabhakar <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Tested-by: Claudiu Beznea <[email protected]> # on RZ/G3S Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2024-06-11pinctrl: renesas: rzg2l: Add function pointer for PFC register lockingLad Prabhakar1-17/+27
On the RZ/G2L SoC, the PFCWE bit controls writing to PFC registers. However, on the RZ/V2H(P) SoC, the PFCWE (REGWE_A on RZ/V2H) bit controls writing to both PFC and PMC registers. Additionally, BIT(7) B0WI is undocumented for the PWPR register on RZ/V2H(P) SoC. To accommodate these differences across SoC variants, introduce the pwpr_pfc_lock_unlock() function pointer. Note, in rzg2l_pinctrl_set_pfc_mode() the pwpr_pfc_lock_unlock(.., false) is now called before PMC read/write and pwpr_pfc_lock_unlock(.., true) is now called after PMC read/write this is to keep changes minimal for RZ/V2H(P) SoC. Signed-off-by: Lad Prabhakar <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Tested-by: Claudiu Beznea <[email protected]> # on RZ/G3S Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2024-06-11pinctrl: renesas: rzg2l: Validate power registers for SD and ETHLad Prabhakar1-4/+8
On RZ/V2H(P) SoC, the power registers for SD and ETH do not exist, resulting in invalid register offsets. Ensure that the register offsets are valid before any read/write operations are performed. If the power registers are not available, both SD and ETH will be set to '0'. Signed-off-by: Lad Prabhakar <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Tested-by: Claudiu Beznea <[email protected]> # on RZ/G3S Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2024-06-11pinctrl: renesas: rzg2l: Enable variable configuration for allLad Prabhakar1-3/+1
Enable parsing of variable configuration for all architectures. This prepares for adding support for the RZ/V2H SoC, which utilizes the ARM64 architecture and features port pins with variable configuration. Signed-off-by: Lad Prabhakar <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Tested-by: Claudiu Beznea <[email protected]> # on RZ/G3S Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2024-06-11pinctrl: renesas: rzg2l: Drop struct rzg2l_variable_pin_cfgLad Prabhakar1-133/+54
Drop the rzg2l_variable_pin_cfg struct and instead use the RZG2L_VARIABLE_PIN_CFG_PACK() macro for the variable pin configuration. Signed-off-by: Lad Prabhakar <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Tested-by: Claudiu Beznea <[email protected]> # on RZ/G3S Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2024-06-11pinctrl: renesas: rzg2l: Allow more bits for pin configurationLad Prabhakar1-13/+17
The pin configuration bits have been growing for every new SoCs being added for the pinctrl-rzg2l driver which would mean updating the macros every time for each new configuration. To avoid this allocate additional bits for pin configuration by relocating the known fixed bits to the very end of the configuration. Also update the size of 'cfg' to 'u64' to allow more configuration bits in the 'struct rzg2l_variable_pin_cfg'. Signed-off-by: Lad Prabhakar <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Tested-by: Claudiu Beznea <[email protected]> # on RZ/G3S Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2024-06-11clk: renesas: r8a779h0: Add VIN clocksNiklas Söderlund1-0/+16
Add the VIN module clocks, which are used by the VIN modules on the Renesas R-Car V4M (R8A779H0) SoC. Signed-off-by: Niklas Söderlund <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]>
2024-06-11drivers: arch_topology: use __free attribute instead of of_node_put()Vincenzo Mezzela1-30/+26
Introduce the __free attribute for scope-based resource management. Resources allocated with __free are automatically released at the end of the scope. This enhancement aims to mitigate memory management issues associated with forgetting to release resources by utilizing __free instead of of_node_put(). The declaration of the device_node used within the do-while loops is moved directly within the loop so that the resource is automatically freed at the end of each iteration. Acked-by: Sudeep Holla <[email protected]> Suggested-by: Julia Lawall <[email protected]> Signed-off-by: Vincenzo Mezzela <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-11drivers: arch_topology: Refactor do-while loopsVincenzo Mezzela1-52/+55
Refactor do-while loops to move break condition within the loop's scope. This modification is in preparation to move the declaration of the device_node directly within the loop and take advantage of the automatic cleanup feature provided by the __free(device_node) attribute. Acked-by: Sudeep Holla <[email protected]> Signed-off-by: Vincenzo Mezzela <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2024-06-11OPP: ti: Fix ti_opp_supply_probe wrong return valuesPrimoz Fiser1-2/+4
Function ti_opp_supply_probe() since commit 6baee034cb55 ("OPP: ti: Migrate to dev_pm_opp_set_config_regulators()") returns wrong values when all goes well and hence driver probing eventually fails. Fixes: 6baee034cb55 ("OPP: ti: Migrate to dev_pm_opp_set_config_regulators()") Signed-off-by: Primoz Fiser <[email protected]> Signed-off-by: Viresh Kumar <[email protected]>
2024-06-11drm/i915: Compute CMRR and calculate vtotalMitul Golani3-11/+83
Compute Fixed Average Vtotal/CMRR with resepect to userspace VRR enablement. Also calculate required parameters in case of CMRR is enabled. During intel_vrr_compute_config, CMRR is getting enabled based on userspace has enabled Variable refresh mode with VRR timing generator or not. Make CMRR as small subset of FAVT mode, when Panel is running on Fixed refresh rate and on VRR framework then only enable CMRR to match with actual refresh rate. --v2: - Update is_cmrr_frac_required function return as bool, not int. [Jani] - Use signed int math instead of unsigned in cmrr_get_vtotal2. [Jani] - Fix typo and usage of camel case in cmrr_get_vtotal. [Jani] - Use do_div in cmrr_get_vtotalwhile calculating cmrr_m. [ Jani] - Simplify cmrr and vrr compute config in intel_vrr_compute_config. [Jani] - Correct valiable name usage in is_cmrr_frac_required. [Ville] --v3: - Removing RFC tag. --v4: - Added edp check to address edp usecase for now. (ville) - Updated is_cmrr_fraction_required to more simplified calculation. - on longterm goal to be worked upon uapi as suggestion from ville. --v5: - Correct vtotal paramas accuracy and add 2 digit precision. - Avoid using DIV_ROUND_UP and improve scanline precision. --v6: - Make CMRR a small subset of FAVT mode. --v7: - Update commit message to avoid confusion with Legacy VRR (Ankit). - Add cmrr.enable in last, so remove from this patch. --v8: - Set cmrr.enable in current patch instead of separate patch (Ankit). - Since vrr.enable and cmrr.enable are not mutually exclusive, handle accordingly (Ankit). - is_edp is not required inside is_cmrr_frac_required function (Ankit). - Add video_mode_required flag for future enhancement. - Correct cmrr_m/cmrr_n calculation. --v9: - Move patch to last and set other bits before computing cmrr.enable.(Ankit) - Add TODO: for to address target refresh rate precision as future enhancement. Signed-off-by: Mitul Golani <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Suraj Kandpal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915/display: Compute vrr vsync paramsMitul Golani1-8/+9
Compute vrr vsync params in case of FAVT as well instead of only to AVT mode of operation. --v2: - Remove redundant computation for vrr_vsync_start and vrr_vsync_end(Ankit). --v3: - vrr.enable and cmrr.enable check together is not required as both will be true at the same point in time. (Ankit) - Replace vrr.enable flag to cmrr.enable, mistakenly added. (Ankit) Signed-off-by: Mitul Golani <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Suraj Kandpal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915/display: Compute Adaptive sync SDP paramsMitul Golani1-3/+11
Compute params for Adaptive Sync SDP when Fixed Average Vtotal mode is enabled. --v2: Since vrr.enable is set in case of cmrr also, handle accordingly(Ankit). --v3: - Since vrr.enable is set in case of cmrr also, handle accordingly(Ankit). - check cmrr.enable when CMRR flags are set during intel_dp_compute_as_sdp. --v4: - Use drm_mode_vrefresh instead of manual calculation (Ankit). Signed-off-by: Mitul Golani <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Suraj Kandpal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915/display: Add support for pack and unpackMitul Golani1-0/+4
Add support of pack and unpack for target_rr_divider. --v2: - Set Target Refresh Rate Divider bit when related AS SDP bit is set (Ankit). --v3: - target_rr_divider is bools so set accordingly (Ankit). Signed-off-by: Mitul Golani <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Suraj Kandpal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915: Update trans_vrr_ctl flag when cmrr is computedMitul Golani2-2/+10
Add/update trans_vrr_ctl flag when crtc_state->cmrr.enable is set, With this commit setting the stage for subsequent CMRR enablement. --v2: - Check pipe active state in cmrr enabling. [Jani] - Remove usage of bitwise OR on booleans. [Jani] - Revert unrelated changes. [Jani] - Update intel_vrr_enable, vrr and cmrr enable conditions. [Jani] - Simplify whole if-ladder in intel_vrr_enable. [Jani] - Revert patch restructuring mistakes in intel_vrr_get_config. [Jani] --v3: - Check pipe active state in cmrr disabling.[Jani] - Correct messed up condition in intel_vrr_enable. [Jani] --v4: - Removing RFC tag. --v5: - CMRR handling in co-existatnce of LRR and DRRS. --v7: - Rebase on top of AS SDP merge. --v8: - Remove cmrr_enabling/disabling and update commit message. (Ankit) --v9: - Revert removed line(Ankit). Signed-off-by: Mitul Golani <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Suraj Kandpal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915: Define and compute Transcoder CMRR registersMitul Golani4-1/+62
Add register definitions for Transcoder Fixed Average Vtotal mode/CMRR function, with the necessary bitfields. Compute these registers when CMRR is enabled, extending Adaptive refresh rate capabilities. --v2: - Use intel_de_read64_2x32 in intel_vrr_get_config. [Jani] - Fix indent and order based on register offset. [Jani] --v3: - Removing RFC tag. --v4: - Update place holder for CMRR register definition. (Jani) --v5: - Add CMRR register definitions to a separate file intel_vrr_reg.h. --v6: - Fixed indentation. (Jani) - Add dependency header intel_display_reg_defs.h. (Jani) - Rename file name to intel_vrr_regs.h instead of reg.h (Jani) --v7: - Remove adding CMRR flag to vrr_ctl register during set_transcoder_timing, as it is already being done during intel_vrr_enable. (Ankit) Signed-off-by: Mitul Golani <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Suraj Kandpal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915: Separate VRR related register definitionsMitul Golani3-100/+112
Move VRR related register definitions to a separate file called intel_vrr_regs.h. Signed-off-by: Mitul Golani <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Suraj Kandpal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915: Update indentation for VRR registers and bitsMitul Golani1-87/+87
Update the indentation for the VRR register definition and its bits, and fix checkpatch issues to ensure smooth movement of registers and bits. --v2: - Keep XELPD_VRR_CTL_VRR_GUARDBAND(x) to avoid readability (Ankit). - Fix all indentation related VRR registers and bits instead of checkpatch one. Signed-off-by: Mitul Golani <[email protected]> Reviewed-by: Ankit Nautiyal <[email protected]> Signed-off-by: Suraj Kandpal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11Merge tag 'amd-drm-next-6.11-2024-06-07' of ↵Dave Airlie607-4639/+334377
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.11-2024-06-07: amdgpu: - DCN 4.0.x support - DCN 3.5 updates - GC 12.0 support - DP MST fixes - Cursor fixes - MES11 updates - MMHUB 4.1 support - DML2 Updates - DCN 3.1.5 fixes - IPS fixes - Various code cleanups - GMC 12.0 support - SDMA 7.0 support - SMU 13 updates - SR-IOV fixes - VCN 5.x fixes - MES12 support - SMU 14.x updates - Devcoredump improvements - Fixes for HDP flush on platforms with >4k pages - GC 9.4.3 fixes - RAS ACA updates - Silence UBSAN flex array warnings - MMHUB 3.3 updates amdkfd: - Contiguous VRAM allocations - GC 12.0 support - SDMA 7.0 support - SR-IOV fixes radeon: - Backlight workaround for iMac - Silence UBSAN flex array warnings UAPI: - GFX12 modifier and DCC support Proposed Mesa changes: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29510 - KFD GFX ALU exceptions Proposed ROCdebugger changes: https://github.com/ROCm/ROCdbgapi/commit/08c760622b6601abf906f75abbc5e21d9fd425df https://github.com/ROCm/ROCgdb/commit/944fe1c1414a68700414e86e32273b6bfa62ba6f - KFD Contiguous VRAM allocation flag Proposed ROCr/HIP changes: https://github.com/ROCm/ROCT-Thunk-Interface/commit/f7b4a269914a3ab4f1e2453c2879adb97b5cc9e5 https://github.com/ROCm/ROCR-Runtime/pull/214/commits/26e8530d05a775872cb06dde6693db72be0c454a https://github.com/ROCm/clr/commit/1d48f2a1ab38b632919c4b7274899b3faf4279ff Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11firmware: google: add missing MODULE_DESCRIPTION() macrosJeff Johnson8-0/+8
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/google/gsmi.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/google/coreboot_table.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/google/framebuffer-coreboot.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/google/memconsole.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/google/memconsole-coreboot.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/google/memconsole-x86-legacy.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/google/cbmem.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/firmware/google/vpd-sysfs.o Add the missing invocations of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <[email protected]> Link: https://lore.kernel.org/r/20240605-md-drivers-firmware-google-v1-1-18878de97fa5@quicinc.com Signed-off-by: Tzung-Bi Shih <[email protected]>
2024-06-10ice: use irq_update_affinity_hint()Michal Schmidt2-4/+4
irq_set_affinity_hint() is deprecated. Use irq_update_affinity_hint() instead. This removes the side-effect of actually applying the affinity. The driver does not really need to worry about spreading its IRQs across CPUs. The core code already takes care of that. On the contrary, when the driver applies affinities by itself, it breaks the users' expectations: 1. The user configures irqbalance with IRQBALANCE_BANNED_CPULIST in order to prevent IRQs from being moved to certain CPUs that run a real-time workload. 2. ice reconfigures VSIs at runtime due to a MIB change (ice_dcb_process_lldp_set_mib_change). Reopening a VSI resets the affinity in ice_vsi_req_irq_msix(). 3. ice has no idea about irqbalance's config, so it may move an IRQ to a banned CPU. The real-time workload suffers unacceptable latency. I am not sure if updating the affinity hints is at all useful, because irqbalance ignores them since 2016 ([1]), but at least it's harmless. This ice change is similar to i40e commit d34c54d1739c ("i40e: Use irq_update_affinity_hint()"). [1] https://github.com/Irqbalance/irqbalance/commit/dcc411e7bfdd Signed-off-by: Michal Schmidt <[email protected]> Reviewed-by: Sunil Goutham <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Tested-by: Pucha Himasekhar Reddy <[email protected]> Signed-off-by: Jacob Keller <[email protected]> Link: https://lore.kernel.org/r/20240607-next-2024-06-03-intel-next-batch-v3-3-d1470cee3347@intel.com Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-10ice: add and use roundup_u64 instead of open coding equivalentJacob Keller1-2/+1
In ice_ptp_cfg_clkout(), the ice driver needs to calculate the nearest next second of a current time value specified in nanoseconds. It implements this using div64_u64, because the time value is a u64. It could use div_u64 since NSEC_PER_SEC is smaller than 32-bits. Ideally this would be implemented directly with roundup(), but that can't work on all platforms due to a division which requires using the specific macros and functions due to platform restrictions, and to ensure that the most appropriate and fast instructions are used. The kernel doesn't currently provide any 64-bit equivalents for doing roundup. Attempting to use roundup() on a 32-bit platform will result in a link failure due to not having a direct 64-bit division. The closest equivalent for this is DIV64_U64_ROUND_UP, which does a division always rounding up. However, this only computes the division, and forces use of the div64_u64 in cases where the divisor is a 32bit value and could make use of div_u64. Introduce DIV_U64_ROUND_UP based on div_u64, and then use it to implement roundup_u64 which takes a u64 input value and a u32 rounding value. The name roundup_u64 matches the naming scheme of div_u64, and future patches could implement roundup64_u64 if they need to round by a multiple that is greater than 32-bits. Replace the logic in ice_ptp.c which does this equivalent with the newly added roundup_u64. Tested-by: Pucha Himasekhar Reddy <[email protected]> Signed-off-by: Jacob Keller <[email protected]> Link: https://lore.kernel.org/r/20240607-next-2024-06-03-intel-next-batch-v3-2-d1470cee3347@intel.com Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-10net: intel: Use *-y instead of *-objs in MakefileAndy Shevchenko11-31/+21
*-objs suffix is reserved rather for (user-space) host programs while usually *-y suffix is used for kernel drivers (although *-objs works for that purpose for now). Let's correct the old usages of *-objs in Makefiles. Reviewed-by: Aleksandr Loktionov <[email protected]> Reviewed-by: Alexander Lobakin <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Jacob Keller <[email protected]> Tested-by: Pucha Himasekhar Reddy <[email protected]> Signed-off-by: Jacob Keller <[email protected]> Link: https://lore.kernel.org/r/20240607-next-2024-06-03-intel-next-batch-v3-1-d1470cee3347@intel.com Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-11platform/chrome: cros_ec_proto: add missing MODULE_DESCRIPTION() macroJeff Johnson1-0/+1
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/platform/chrome/cros_kunit_proto_test.o Add the missing invocation of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <[email protected]> Link: https://lore.kernel.org/r/20240610-md-drivers-platform-chrome-v1-1-f9c75adcc1ca@quicinc.com Signed-off-by: Tzung-Bi Shih <[email protected]>
2024-06-10isdn: add missing MODULE_DESCRIPTION() macrosJeff Johnson13-0/+13
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/hardware/mISDN/hfcpci.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/hardware/mISDN/hfcmulti.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/hardware/mISDN/hfcsusb.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/hardware/mISDN/avmfritz.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/hardware/mISDN/speedfax.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/hardware/mISDN/mISDNinfineon.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/hardware/mISDN/w6692.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/hardware/mISDN/netjet.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/hardware/mISDN/mISDNipac.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/hardware/mISDN/mISDNisar.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/mISDN/mISDN_core.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/mISDN/mISDN_dsp.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/isdn/mISDN/l1oip.o Add the missing invocations of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2024-06-10Merge tag 'wireless-next-2024-06-07' of ↵Jakub Kicinski193-2184/+11081
git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.11 The first "new features" pull request for v6.11 with changes both in stack and in drivers. Nothing out of ordinary, except that we have two conflicts this time: net/mac80211/cfg.c https://lore.kernel.org/all/[email protected] drivers/net/wireless/microchip/wilc1000/netdev.c https://lore.kernel.org/all/[email protected] Major changes: cfg80211/mac80211 * parse Transmit Power Envelope (TPE) data in mac80211 instead of in drivers wilc1000 * read MAC address during probe to make it visible to user space iwlwifi * bump FW API to 91 for BZ/SC devices * report 64-bit radiotap timestamp * enable P2P low latency by default * handle Transmit Power Envelope (TPE) advertised by AP * start using guard() rtlwifi * RTL8192DU support ath12k * remove unsupported tx monitor handling * channel 2 in 6 GHz band support * Spatial Multiplexing Power Save (SMPS) in 6 GHz band support * multiple BSSID (MBSSID) and Enhanced Multi-BSSID Advertisements (EMA) support * dynamic VLAN support * add panic handler for resetting the firmware state ath10k * add qcom,no-msa-ready-indicator Device Tree property * LED support for various chipsets * tag 'wireless-next-2024-06-07' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (194 commits) wifi: ath12k: add hw_link_id in ath12k_pdev wifi: ath12k: add panic handler wifi: rtw89: chan: Use swap() in rtw89_swap_sub_entity() wifi: brcm80211: remove unused structs wifi: brcm80211: use sizeof(*pointer) instead of sizeof(type) wifi: ath12k: do not process consecutive RDDM event dt-bindings: net: wireless: ath11k: Drop "qcom,ipq8074-wcss-pil" from example wifi: ath12k: fix memory leak in ath12k_dp_rx_peer_frag_setup() wifi: rtlwifi: handle return value of usb init TX/RX wifi: rtlwifi: Enable the new rtl8192du driver wifi: rtlwifi: Add rtl8192du/sw.c wifi: rtlwifi: Constify rtl_hal_cfg.{ops,usb_interface_cfg} and rtl_priv.cfg wifi: rtlwifi: Add rtl8192du/dm.{c,h} wifi: rtlwifi: Add rtl8192du/fw.{c,h} and rtl8192du/led.{c,h} wifi: rtlwifi: Add rtl8192du/rf.{c,h} wifi: rtlwifi: Add rtl8192du/trx.{c,h} wifi: rtlwifi: Add rtl8192du/phy.{c,h} wifi: rtlwifi: Add rtl8192du/hw.{c,h} wifi: rtlwifi: Add new members to struct rtl_priv for RTL8192DU wifi: rtlwifi: Add rtl8192du/table.{c,h} ... Signed-off-by: Jakub Kicinski <[email protected]> ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.