linux-kernel - Re: [PATCH v4 2/7] nvmem: qcom-spmi-sdam: Migrate to devm_spmi_subdevice_alloc_and

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]

Message-ID: <a10685e2-e4af-4097-b432-778e83e0b3bf@collabora.com>
Date: Wed, 17 Sep 2025 11:15:37 +0200
From: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
To: Andy Shevchenko <andy.shevchenko@...il.com>,
 Uwe Kleine-König <u.kleine-koenig@...libre.com>
Cc: Andy Shevchenko <andriy.shevchenko@...el.com>, sboyd@...nel.org,
 jic23@...nel.org, dlechner@...libre.com, nuno.sa@...log.com,
 andy@...nel.org, arnd@...db.de, gregkh@...uxfoundation.org,
 srini@...nel.org, vkoul@...nel.org, kishon@...nel.org, sre@...nel.org,
 krzysztof.kozlowski@...aro.org, linux-arm-msm@...r.kernel.org,
 linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-phy@...ts.infradead.org, linux-pm@...r.kernel.org,
 kernel@...labora.com, wenst@...omium.org, casey.connolly@...aro.org,
 Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
 Neil Armstrong <neil.armstrong@...aro.org>
Subject: Re: [PATCH v4 2/7] nvmem: qcom-spmi-sdam: Migrate to
 devm_spmi_subdevice_alloc_and_add()

Il 16/09/25 18:20, Andy Shevchenko ha scritto:
> On Tue, Sep 16, 2025 at 6:11 PM Uwe Kleine-König
> <u.kleine-koenig@...libre.com> wrote:
>> On Tue, Sep 16, 2025 at 04:35:35PM +0300, Andy Shevchenko wrote:
>>> On Tue, Sep 16, 2025 at 03:24:56PM +0200, Uwe Kleine-König wrote:
>>>> On Tue, Sep 16, 2025 at 10:44:40AM +0200, AngeloGioacchino Del Regno wrote:
> 
> ...
> 
>>>>> +MODULE_IMPORT_NS("SPMI");
>>>>
>>>> If it's exactly the files that #include <linux/spmi.h> should have that
>>>> namespace import, you can put the MODULE_IMPORT_NS into that header.
>>>
>>> Which makes anyone to import namespace even if they just want to use some types
>>> out of the header.
>>
>> Notice that I carefully formulated my suggestion to cope for this case.
> 
> And I carefully answered. Your proposal won't prevent _other_ files to
> use the same header in the future without needing a namespace to be
> imported.
> 
>>> This is not good solution generally speaking. Also this will
>>> diminish one of the purposes of _NS variants of MODULE*/EXPORT*, i.e. make it
>>> invisible that some of the code may become an abuser of the API just by someone
>>> include the header (for a reason or by a mistake).
>>
>> Yeah, opinions differ. In my eyes it's quite elegant.
> 
> It's not a pure opinion, it has a technical background that I
> explained. The explicit usage of MODULE_IMPORT_NS() is better than
> some header somewhere that might even be included by another and be
> proxied to the code that doesn't need / want to have this namespace to
> be present. Puting MODULE_IMPORT_NS() into a _header_ is a minefield
> for the future.
> 

Uwe, thanks for your review - much appreciated.

Even though I get your point... Sorry, but here I do agree with Andy, and I think
he explained some of the reasons pretty well.

Cheers,
Angelo