Received-SPF: pass (google.com: domain of linux-kernel+bounces-129881-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
From: Kalle Valo <kvalo@kernel.org>
To: Jeff Johnson <quic_jjohnson@quicinc.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,  Jeff Johnson
 <jjohnson@kernel.org>,  Brian Norris <briannorris@chromium.org>,  Ajay
 Singh <ajay.kathat@microchip.com>,  Claudiu Beznea
 <claudiu.beznea@tuxon.dev>,  <linux-wireless@vger.kernel.org>,
  <ath10k@lists.infradead.org>,  <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/6] wifi: ath10k: sdio: simplify module initialization
References: <20240329171019.63836-1-krzysztof.kozlowski@linaro.org>
	<f78fa061-3b34-47d2-a40c-bbec744f0f97@quicinc.com>
Date: Wed, 03 Apr 2024 16:50:41 +0300
In-Reply-To: <f78fa061-3b34-47d2-a40c-bbec744f0f97@quicinc.com> (Jeff
	Johnson's message of "Fri, 29 Mar 2024 10:22:00 -0700")
Message-ID: <87jzle5zda.fsf@kernel.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

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.

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

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