Re: [PATCH v4 4/5] platform/x86/amd: pmc: use FCH_PM_BASE definition

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 16, 2025 at 09:58:20AM +0200, Ingo Molnar wrote:
> 
> * Yazen Ghannam <yazen.ghannam@xxxxxxx> wrote:
> 
> > On Mon, Apr 14, 2025 at 07:26:57PM -0500, Mario Limonciello wrote:
> > > From: Mario Limonciello <mario.limonciello@xxxxxxx>
> > > 
> > > The s2idle mmio quirk uses a scratch register in the FCH.
> > > Adjust the code to clarify that.
> > > 
> > > Signed-off-by: Mario Limonciello <mario.limonciello@xxxxxxx>
> > > ---
> > > v4:
> > >  * Use fch.h instead
> > > ---
> > >  arch/x86/include/asm/amd/fch.h            | 1 +
> > >  drivers/platform/x86/amd/pmc/pmc-quirks.c | 3 ++-
> > >  2 files changed, 3 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/x86/include/asm/amd/fch.h b/arch/x86/include/asm/amd/fch.h
> > > index a5fd91ff92df3..9b32e8a03193e 100644
> > > --- a/arch/x86/include/asm/amd/fch.h
> > > +++ b/arch/x86/include/asm/amd/fch.h
> > > @@ -8,5 +8,6 @@
> > >  /* register offsets from PM base */
> > >  #define FCH_PM_DECODEEN			0x00
> > >  #define FCH_PM_DECODEEN_SMBUS0SEL	GENMASK(20, 19)
> > > +#define FCH_PM_SCRATCH			0x80
> > >  
> > >  #endif
> > > diff --git a/drivers/platform/x86/amd/pmc/pmc-quirks.c b/drivers/platform/x86/amd/pmc/pmc-quirks.c
> > > index b4f49720c87f6..3c680d2029f62 100644
> > > --- a/drivers/platform/x86/amd/pmc/pmc-quirks.c
> > > +++ b/drivers/platform/x86/amd/pmc/pmc-quirks.c
> > > @@ -8,6 +8,7 @@
> > >   * Author: Mario Limonciello <mario.limonciello@xxxxxxx>
> > >   */
> > >  
> > > +#include <asm/amd/fch.h>
> > 
> > Arch headers should go after linux headers, I think.
> 
> That's true, but it's a mostly stylistic requirement these days.
> 
> > So that arch stuff can override generic stuff.
> 
> Arch headers that override generic stuff are very much supposed to be 
> able to build stand-alone and in pretty much any order with other 
> headers, with very few exceptions. Ordering dependencies are very much 
> frowned upon, because if they don't trigger build failures they can 
> result in subtle breakages.
> 

Ah okay, thanks for clarifying!

-Yazen




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux