netdev - 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] [day] [month] [year] [list]

Message-ID: <CAHp75VcXtwe3zutnZUDNXBPe1qgwP+GbBF9KSFHOPioEvSk3Pw@mail.gmail.com>
Date: Fri, 7 Mar 2025 20:06:30 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Choong Yong Liang <yong.liang.choong@...ux.intel.com>
Cc: david.e.box@...ux.intel.com, 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 Fri, Mar 7, 2025 at 7:28 AM Choong Yong Liang
<yong.liang.choong@...ux.intel.com> wrote:
> 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.

> >> 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.
> >>
> >> 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
> >
> >> 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.

> The current ACPI dependency for the config DWMAC_INTEL is necessary,

I can argue on this. The driver worked without problems on the cases I
explained, so the dependency introduced very recently and only for a
subset of the cases. What you probably wanted to say is that "the
dependency is needed to avoid compilation errors in CONFIG_ACPI=n
cases since the used API doesn't (yet) provide the necessary stubs".
With that being assumed I agree.

> 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.

Yes, please do it as the ACPI dependency brings a few hundreds of
kilobytes into the kernel with a lot of possible unneeded stuff.

-- 
With Best Regards,
Andy Shevchenko