linux-kernel - Re: [PATCH net-next v9 5/6] net: stmmac: configure SerDes according to the interface mode

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: <19b78790-d4d3-45db-9b1f-fbe40f8ed795@linux.intel.com>
Date: Fri, 7 Mar 2025 13:28:46 +0800
From: Choong Yong Liang <yong.liang.choong@...ux.intel.com>
To: david.e.box@...ux.intel.com, Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Simon Horman <horms@...nel.org>, Jose Abreu <joabreu@...opsys.com>,
 Jose Abreu <Jose.Abreu@...opsys.com>, Thomas Gleixner <tglx@...utronix.de>,
 Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
 Dave Hansen <dave.hansen@...ux.intel.com>, "H . Peter Anvin"
 <hpa@...or.com>, Rajneesh Bhardwaj <irenic.rajneesh@...il.com>,
 David E Box <david.e.box@...el.com>, Andrew Lunn <andrew+netdev@...n.ch>,
 "David S . Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>, Maxime Coquelin
 <mcoquelin.stm32@...il.com>, Alexandre Torgue
 <alexandre.torgue@...s.st.com>, Jiawen Wu <jiawenwu@...stnetic.com>,
 Mengyuan Lou <mengyuanlou@...-swift.com>,
 Heiner Kallweit <hkallweit1@...il.com>, Russell King
 <linux@...linux.org.uk>, Hans de Goede <hdegoede@...hat.com>,
 Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
 Richard Cochran <richardcochran@...il.com>,
 Serge Semin <fancer.lancer@...il.com>, x86@...nel.org,
 linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
 platform-driver-x86@...r.kernel.org,
 linux-stm32@...md-mailman.stormreply.com,
 linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH net-next v9 5/6] net: stmmac: configure SerDes according
 to the interface mode

On 7/3/2025 4:52 am, David E. Box wrote:
> On Thu, 2025-03-06 at 20:56 +0800, Choong Yong Liang wrote:
>>
>>
>> On 6/3/2025 5:05 pm, Andy Shevchenko wrote:
>>> On Thu, Mar 6, 2025 at 10:39 AM Choong Yong Liang
>>> <yong.liang.choong@...ux.intel.com> wrote:
>>>> On 6/3/2025 3:15 pm, Andy Shevchenko wrote:
>>>>> Thu, Feb 27, 2025 at 08:15:21PM +0800, Choong Yong Liang kirjoitti:
>>> ...
>>>
>>>>>> config DWMAC_INTEL
>>>>>>        default X86
>>>>>>        depends on X86 && STMMAC_ETH && PCI
>>>>>>        depends on COMMON_CLK
>>>>>> +    depends on ACPI
>>>>> Stray and unexplained change. Please, fix it. We don't need the
>>>>> dependencies
>>>>> which are not realised in the compile time.
>>>> The dependency on ACPI is necessary because the intel_pmc_ipc.h header
>>>> relies on ACPI functionality to interact with the Intel PMC.
>>> So, that header has to be fixed as ACPI here is really unneeded
>>> dependency for the cases when somebody (for whatever reasons) want to
>>> build a kernel without ACPI support but with the driver enabled for
>>> let's say PCI device.
>>>
>>>
>>> -- With Best Regards, Andy Shevchenko
>>
>> Hi Andy,
>>
>> Thank you for your feedback, Andy.
>> I appreciate your insights regarding the ACPI dependency.
>> The intel_pmc_ipc.h header is under the ownership of David E Box, who
>> focuses on the platform code, while my focus is on the netdev.
>>
>> Hi David,
>>
>> if you could kindly look into making the ACPI dependency optional in the
>> intel_pmc_ipc.h header, it would be greatly appreciated.
>> I am more than willing to provide any support necessary to ensure a smooth
>> resolution.
> 
> Choong you only need put the function under a #if CONFIG_ACPI block and provide
> an alternative that returns an error when the code is not build. Like this,
> 
> #if CONFIG_ACPI
> static inline int intel_pmc_ipc(struct pmc_ipc_cmd *ipc_cmd, struct pmc_ipc_rbuf
> *rbuf)
> {
>     ...
> }
> #else
> static inline int intel_pmc_ipc(struct pmc_ipc_cmd *ipc_cmd, struct pmc_ipc_rbuf
> *rbuf) { return -ENODEV; }
> #endif
> 
> David
> 
>>
>> This patch series has already been accepted, but we recognize the
>> importance of addressing this issue in the next patch series for upstream.
>> Our goal is to ensure that the driver can be compiled and function
>> correctly in both ACPI and non-ACPI environments.
>>
>> Thank you both for your understanding and collaboration.
> 
> 
Hi Andy and David,

Thank you for the feedback.

The current ACPI dependency for the config DWMAC_INTEL is necessary, but I 
agree on making it optional.

Implementing the suggestion from David using the "#if CONFIG_ACPI" approach 
would address your concern about users who need to build a kernel without 
ACPI support.

If you are okay with this approach, then I will submit the solution for 
upstream.