Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <a88a130f-dc5d-e3d0-b707-dea4df14a48a@gmail.com>
Date:   Fri, 29 Jul 2022 11:38:42 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.11.0
Subject: Re: [PATCH 7/7] brcmfmac: introduce BRCMFMAC exported symbols
 namespace
Content-Language: en-US
To:     Kalle Valo <kvalo@kernel.org>
Cc:     arend.vanspriel@broadcom.com, linux-wireless@vger.kernel.org
References: <20220613091915.18884-1-arend.vanspriel@broadcom.com>
 <CAJ65rDwMzF8hhuykrikSdsPMgy4GhLkTUfqTfn-cbHwCL5OE2Q@mail.gmail.com>
 <87fsilo9so.fsf@kernel.org>
From:   Arend Van Spriel <aspriel@gmail.com>
In-Reply-To: <87fsilo9so.fsf@kernel.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 7/28/2022 11:39 AM, Kalle Valo wrote:
> aspriel@gmail.com writes:
> 
>> Instead of using EXPORT_SYMBOL() use namespace variant and only if
>> build vendor-specific code as separate module.
> 
> The commit log should always answer to the question "why?".

Let me try:

Exported symbols are usable from any kernel module. Using the namespace 
variant requires the caller to explicitly import the symbols. This makes 
it more clear that these are only intended to be used by brcmfmac 
driver. When vendor-support is built-in there is no reason to export the
symbols at all.

If the above is acceptable I will use that when resending the patch series.

Regards,
Arend