| Message ID | 20240329171019.63836-1-krzysztof.kozlowski@linaro.org (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Kalle Valo |
| Headers | show |
| Series | [1/6] wifi: ath10k: sdio: simplify module initialization | expand |
On 3/29/2024 10:10 AM, Krzysztof Kozlowski wrote: > This driver's initialization functions do not perform any custom code, > except printing messages. Printing messages on modules > loading/unloading is discouraged because it pollutes the dmesg > regardless whether user actually has this device. Core kernel code > already gives tools to investigate whether module was loaded or not. > > Drop the printing messages which allows to replace open-coded > module_sdio_driver(). > > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> > > --- > > FYI: > I have ongoing patchset touching few lines above this patch chunk > (sdio_driver) which might go via different tree. If that patchset is > applied via different tree, it might result in a trivial conflict, but > there is no dependency. They can go via separate trees (except that > trivial conflict). I'll let Kalle respond if he'll take this through the ath tree vs letting you take it through your tree
Jeff Johnson <quic_jjohnson@quicinc.com> writes: > On 3/29/2024 10:10 AM, Krzysztof Kozlowski wrote: >> This driver's initialization functions do not perform any custom code, >> except printing messages. Printing messages on modules >> loading/unloading is discouraged because it pollutes the dmesg >> regardless whether user actually has this device. Core kernel code >> already gives tools to investigate whether module was loaded or not. >> >> Drop the printing messages which allows to replace open-coded >> module_sdio_driver(). >> >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> > >> >> --- >> >> FYI: >> I have ongoing patchset touching few lines above this patch chunk >> (sdio_driver) which might go via different tree. If that patchset is >> applied via different tree, it might result in a trivial conflict, but >> there is no dependency. They can go via separate trees (except that >> trivial conflict). > > I'll let Kalle respond if he'll take this through the ath tree vs letting you > take it through your tree I prefer to avoid conflicts as much as possible. In this patchset I'm not anticipating any conflicts with wireless trees, so if we can avoid any conflicts, please take this patchset via the other tree: Acked-by: Kalle Valo <kvalo@kernel.org> I'll drop this patchset from my queue. But if I should take these to wireless trees instead just let me know.
On 03/04/2024 15:50, Kalle Valo wrote: > Jeff Johnson <quic_jjohnson@quicinc.com> writes: > >> On 3/29/2024 10:10 AM, Krzysztof Kozlowski wrote: >>> This driver's initialization functions do not perform any custom code, >>> except printing messages. Printing messages on modules >>> loading/unloading is discouraged because it pollutes the dmesg >>> regardless whether user actually has this device. Core kernel code >>> already gives tools to investigate whether module was loaded or not. >>> >>> Drop the printing messages which allows to replace open-coded >>> module_sdio_driver(). >>> >>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >> >> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> >> >>> >>> --- >>> >>> FYI: >>> I have ongoing patchset touching few lines above this patch chunk >>> (sdio_driver) which might go via different tree. If that patchset is >>> applied via different tree, it might result in a trivial conflict, but >>> there is no dependency. They can go via separate trees (except that >>> trivial conflict). >> >> I'll let Kalle respond if he'll take this through the ath tree vs letting you >> take it through your tree > > I prefer to avoid conflicts as much as possible. In this patchset I'm > not anticipating any conflicts with wireless trees, so if we can avoid > any conflicts, please take this patchset via the other tree: > > Acked-by: Kalle Valo <kvalo@kernel.org> > > I'll drop this patchset from my queue. But if I should take these to > wireless trees instead just let me know. OK, let me squeeze both through sdio, with corrected subjects. Best regards, Krzysztof
On 03/04/2024 15:50, Kalle Valo wrote: > Jeff Johnson <quic_jjohnson@quicinc.com> writes: > >> On 3/29/2024 10:10 AM, Krzysztof Kozlowski wrote: >>> This driver's initialization functions do not perform any custom code, >>> except printing messages. Printing messages on modules >>> loading/unloading is discouraged because it pollutes the dmesg >>> regardless whether user actually has this device. Core kernel code >>> already gives tools to investigate whether module was loaded or not. >>> >>> Drop the printing messages which allows to replace open-coded >>> module_sdio_driver(). >>> >>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >> >> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> >> >>> >>> --- >>> >>> FYI: >>> I have ongoing patchset touching few lines above this patch chunk >>> (sdio_driver) which might go via different tree. If that patchset is >>> applied via different tree, it might result in a trivial conflict, but >>> there is no dependency. They can go via separate trees (except that >>> trivial conflict). >> >> I'll let Kalle respond if he'll take this through the ath tree vs letting you >> take it through your tree > > I prefer to avoid conflicts as much as possible. In this patchset I'm > not anticipating any conflicts with wireless trees, so if we can avoid > any conflicts, please take this patchset via the other tree: > > Acked-by: Kalle Valo <kvalo@kernel.org> > > I'll drop this patchset from my queue. But if I should take these to > wireless trees instead just let me know. Just to clarify - only the first patch has possible conflict. The rest should be fine. Can you pick up 2-6 patches from this set? Best regards, Krzysztof
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> writes: > On 03/04/2024 15:50, Kalle Valo wrote: > >> Jeff Johnson <quic_jjohnson@quicinc.com> writes: >> >>> On 3/29/2024 10:10 AM, Krzysztof Kozlowski wrote: >>>> This driver's initialization functions do not perform any custom code, >>>> except printing messages. Printing messages on modules >>>> loading/unloading is discouraged because it pollutes the dmesg >>>> regardless whether user actually has this device. Core kernel code >>>> already gives tools to investigate whether module was loaded or not. >>>> >>>> Drop the printing messages which allows to replace open-coded >>>> module_sdio_driver(). >>>> >>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >>> >>> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com> >>> >>>> >>>> --- >>>> >>>> FYI: >>>> I have ongoing patchset touching few lines above this patch chunk >>>> (sdio_driver) which might go via different tree. If that patchset is >>>> applied via different tree, it might result in a trivial conflict, but >>>> there is no dependency. They can go via separate trees (except that >>>> trivial conflict). >>> >>> I'll let Kalle respond if he'll take this through the ath tree vs letting you >>> take it through your tree >> >> I prefer to avoid conflicts as much as possible. In this patchset I'm >> not anticipating any conflicts with wireless trees, so if we can avoid >> any conflicts, please take this patchset via the other tree: >> >> Acked-by: Kalle Valo <kvalo@kernel.org> >> >> I'll drop this patchset from my queue. But if I should take these to >> wireless trees instead just let me know. > > Just to clarify - only the first patch has possible conflict. The rest > should be fine. Ah, I was not quite sure what patches had the conflict. > Can you pick up 2-6 patches from this set? Yeah, that sounds the best. So patches 2-6 are back in my queue: https://patchwork.kernel.org/project/linux-wireless/list/?series=839844&state=*&order=date
diff --git a/drivers/net/wireless/ath/ath10k/sdio.c b/drivers/net/wireless/ath/ath10k/sdio.c index 0ab5433f6cf6..1acb9fba9a8e 100644 --- a/drivers/net/wireless/ath/ath10k/sdio.c +++ b/drivers/net/wireless/ath/ath10k/sdio.c @@ -2671,25 +2671,7 @@ static struct sdio_driver ath10k_sdio_driver = { .pm = ATH10K_SDIO_PM_OPS, }, }; - -static int __init ath10k_sdio_init(void) -{ - int ret; - - ret = sdio_register_driver(&ath10k_sdio_driver); - if (ret) - pr_err("sdio driver registration failed: %d\n", ret); - - return ret; -} - -static void __exit ath10k_sdio_exit(void) -{ - sdio_unregister_driver(&ath10k_sdio_driver); -} - -module_init(ath10k_sdio_init); -module_exit(ath10k_sdio_exit); +module_sdio_driver(ath10k_sdio_driver); MODULE_AUTHOR("Qualcomm Atheros"); MODULE_DESCRIPTION("Driver support for Qualcomm Atheros 802.11ac WLAN SDIO devices");
This driver's initialization functions do not perform any custom code, except printing messages. Printing messages on modules loading/unloading is discouraged because it pollutes the dmesg regardless whether user actually has this device. Core kernel code already gives tools to investigate whether module was loaded or not. Drop the printing messages which allows to replace open-coded module_sdio_driver(). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> --- FYI: I have ongoing patchset touching few lines above this patch chunk (sdio_driver) which might go via different tree. If that patchset is applied via different tree, it might result in a trivial conflict, but there is no dependency. They can go via separate trees (except that trivial conflict). --- drivers/net/wireless/ath/ath10k/sdio.c | 20 +------------------- 1 file changed, 1 insertion(+), 19 deletions(-)