linux-kernel - Re: [PATCH 1/6] wifi: ath10k: sdio: simplify module initialization

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 03 Apr 2024 17:25:36 +0300
From: Kalle Valo <kvalo@...nel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc: Jeff Johnson <quic_jjohnson@...cinc.com>,  Jeff Johnson
 <jjohnson@...nel.org>,  Brian Norris <briannorris@...omium.org>,  Ajay
 Singh <ajay.kathat@...rochip.com>,  Claudiu Beznea
 <claudiu.beznea@...on.dev>,  linux-wireless@...r.kernel.org,
  ath10k@...ts.infradead.org,  linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/6] wifi: ath10k: sdio: simplify module initialization

Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org> writes:

> On 03/04/2024 15:50, Kalle Valo wrote:
>
>> Jeff Johnson <quic_jjohnson@...cinc.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@...aro.org>
>>>
>>> Acked-by: Jeff Johnson <quic_jjohnson@...cinc.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@...nel.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

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches