The Atom PMC driver is always built-in, regardless of whether
the kernel being built is going to be run on an Atom (or even Intel) CPU.
Signed-off-by: Dave Jones <[email protected]>
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f2327e88e07c..04280177c1e2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2485,7 +2485,7 @@ config X86_DMA_REMAP
depends on STA2X11
config PMC_ATOM
- def_bool y
+ tristate "Intel Atom SOC power management controller driver"
depends on PCI
source "net/Kconfig"
Hi,
On Wed, Oct 15, 2014 at 10:46:03AM -0400, Dave Jones wrote:
> The Atom PMC driver is always built-in, regardless of whether
> the kernel being built is going to be run on an Atom (or even Intel) CPU.
>
> Signed-off-by: Dave Jones <[email protected]>
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index f2327e88e07c..04280177c1e2 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2485,7 +2485,7 @@ config X86_DMA_REMAP
> depends on STA2X11
>
> config PMC_ATOM
> - def_bool y
> + tristate "Intel Atom SOC power management controller driver"
looks like you should still have this as default y just to make sure you
a simple defconfig still enables this as it did before.
--
balbi
On Wed, Oct 15, 2014 at 09:52:45AM -0500, Felipe Balbi wrote:
> Hi,
>
> On Wed, Oct 15, 2014 at 10:46:03AM -0400, Dave Jones wrote:
> > The Atom PMC driver is always built-in, regardless of whether
> > the kernel being built is going to be run on an Atom (or even Intel) CPU.
> >
> > Signed-off-by: Dave Jones <[email protected]>
> >
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index f2327e88e07c..04280177c1e2 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -2485,7 +2485,7 @@ config X86_DMA_REMAP
> > depends on STA2X11
> >
> > config PMC_ATOM
> > - def_bool y
> > + tristate "Intel Atom SOC power management controller driver"
>
> looks like you should still have this as default y just to make sure you
> a simple defconfig still enables this as it did before.
I could, but why should this be default y ? There's no real
justification to inflict this on everyone, given atom is at best
a niche area of x86.
Dave
On Wed, Oct 15, 2014 at 10:59:24AM -0400, Dave Jones wrote:
> On Wed, Oct 15, 2014 at 09:52:45AM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Wed, Oct 15, 2014 at 10:46:03AM -0400, Dave Jones wrote:
> > > The Atom PMC driver is always built-in, regardless of whether
> > > the kernel being built is going to be run on an Atom (or even Intel) CPU.
> > >
> > > Signed-off-by: Dave Jones <[email protected]>
> > >
> > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > > index f2327e88e07c..04280177c1e2 100644
> > > --- a/arch/x86/Kconfig
> > > +++ b/arch/x86/Kconfig
> > > @@ -2485,7 +2485,7 @@ config X86_DMA_REMAP
> > > depends on STA2X11
> > >
> > > config PMC_ATOM
> > > - def_bool y
> > > + tristate "Intel Atom SOC power management controller driver"
> >
> > looks like you should still have this as default y just to make sure you
> > a simple defconfig still enables this as it did before.
>
> I could, but why should this be default y ? There's no real
> justification to inflict this on everyone, given atom is at best
> a niche area of x86.
well, because it already was a bool ? There might be distros out there
who would mysteriously loose PMC support after upgrade the kernel
without realizing that PMC_ATOM isn't a default y anymore.
Frankly though, no strong feelings. I won't be the one having to tell
users to change their .config ;-)
--
balbi
On Wed, 15 Oct 2014 10:59:24 -0400
Dave Jones <[email protected]> wrote:
> On Wed, Oct 15, 2014 at 09:52:45AM -0500, Felipe Balbi wrote:
> > Hi,
> >
> > On Wed, Oct 15, 2014 at 10:46:03AM -0400, Dave Jones wrote:
> > > The Atom PMC driver is always built-in, regardless of whether
> > > the kernel being built is going to be run on an Atom (or even Intel) CPU.
> > >
> > > Signed-off-by: Dave Jones <[email protected]>
> > >
> > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > > index f2327e88e07c..04280177c1e2 100644
> > > --- a/arch/x86/Kconfig
> > > +++ b/arch/x86/Kconfig
> > > @@ -2485,7 +2485,7 @@ config X86_DMA_REMAP
> > > depends on STA2X11
> > >
> > > config PMC_ATOM
> > > - def_bool y
> > > + tristate "Intel Atom SOC power management controller driver"
> >
> > looks like you should still have this as default y just to make sure you
> > a simple defconfig still enables this as it did before.
>
> I could, but why should this be default y ? There's no real
> justification to inflict this on everyone, given atom is at best
> a niche area of x86.
Possibly because you work for an enterprise vendor. Atom is not remotely
niche to everyone else.
This really does want to be a default Y for X86 at least, although I can
see that for the enterprise market you probably don't care quite so much
right now. Without that you are going to break a lot of users
configurations in a deeply surprising way.
Alan
The Atom PMC driver is always built-in, regardless of whether
the kernel being built is going to be run on an Atom (or even Intel) CPU.
Signed-off-by: Dave Jones <[email protected]>
Cc: One Thousand Gnomes <[email protected]>
Cc: [email protected]
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f2327e88e07c..b4dfd96aeea8 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2485,7 +2485,8 @@ config X86_DMA_REMAP
depends on STA2X11
config PMC_ATOM
- def_bool y
+ tristate "Intel Atom SOC power management controller driver"
+ default y
depends on PCI
source "net/Kconfig"
On 2014/10/16 10:18, Dave Jones wrote:
> The Atom PMC driver is always built-in, regardless of whether
> the kernel being built is going to be run on an Atom (or even Intel) CPU.
>
> Signed-off-by: Dave Jones <[email protected]>
> Cc: One Thousand Gnomes <[email protected]>
> Cc: [email protected]
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index f2327e88e07c..b4dfd96aeea8 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2485,7 +2485,8 @@ config X86_DMA_REMAP
> depends on STA2X11
>
> config PMC_ATOM
> - def_bool y
> + tristate "Intel Atom SOC power management controller driver"
PMC driver provides core function like reboot, better to change to
bool, or did you see a scenario it can be as a module?
Thanks,
-Aubrey
> + default y
> depends on PCI
>
> source "net/Kconfig"
>
>
On Thu, Oct 16, 2014 at 11:00:35AM +0800, Li, Aubrey wrote:
> On 2014/10/16 10:18, Dave Jones wrote:
> > The Atom PMC driver is always built-in, regardless of whether
> > the kernel being built is going to be run on an Atom (or even Intel) CPU.
> >
> > Signed-off-by: Dave Jones <[email protected]>
> > Cc: One Thousand Gnomes <[email protected]>
> > Cc: [email protected]
> >
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index f2327e88e07c..b4dfd96aeea8 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -2485,7 +2485,8 @@ config X86_DMA_REMAP
> > depends on STA2X11
> >
> > config PMC_ATOM
> > - def_bool y
> > + tristate "Intel Atom SOC power management controller driver"
>
> PMC driver provides core function like reboot, better to change to
> bool, or did you see a scenario it can be as a module?
All the MODULE_* stuff in arch/x86/kernel/pmc_atom.c threw me off.
It could also use a help text. I suspect you might be in a better
position than me to write one though.
Dave
* Dave Jones <[email protected]> wrote:
> The Atom PMC driver is always built-in, regardless of whether
> the kernel being built is going to be run on an Atom (or even Intel) CPU.
>
> Signed-off-by: Dave Jones <[email protected]>
> Cc: One Thousand Gnomes <[email protected]>
> Cc: [email protected]
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index f2327e88e07c..b4dfd96aeea8 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2485,7 +2485,8 @@ config X86_DMA_REMAP
> depends on STA2X11
>
> config PMC_ATOM
> - def_bool y
> + tristate "Intel Atom SOC power management controller driver"
> + default y
> depends on PCI
>
So what I think should happen is to decouple of the 'must work'
features from the optional debug features in this 'driver': the
Atom SoC power-off quirk should be made unconditional, as long as
the .config is Atom-supported (CPU_SUP_INTEL I guess).
All the other bits, such as the debugfs interface, should be in a
separately and appropriately named config option,
CONFIG_X86_INTEL_ATOM_PMC_DEBUG=y or so, with 'default n'.
The file should probably be split up, the quirk moved into one of
the generic quirk files, while pmc_atom.c should have the debugfs
interface.
That way we don't break anyone and remove the unnecessary code as
well. It's also a nice clean up.
Thanks,
Ingo
On 2014/10/16 13:24, Ingo Molnar wrote:
>
> * Dave Jones <[email protected]> wrote:
>
>> The Atom PMC driver is always built-in, regardless of whether
>> the kernel being built is going to be run on an Atom (or even Intel) CPU.
>>
>> Signed-off-by: Dave Jones <[email protected]>
>> Cc: One Thousand Gnomes <[email protected]>
>> Cc: [email protected]
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index f2327e88e07c..b4dfd96aeea8 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -2485,7 +2485,8 @@ config X86_DMA_REMAP
>> depends on STA2X11
>>
>> config PMC_ATOM
>> - def_bool y
>> + tristate "Intel Atom SOC power management controller driver"
>> + default y
>> depends on PCI
>>
>
> So what I think should happen is to decouple of the 'must work'
> features from the optional debug features in this 'driver': the
> Atom SoC power-off quirk should be made unconditional, as long as
> the .config is Atom-supported (CPU_SUP_INTEL I guess).
>
> All the other bits, such as the debugfs interface, should be in a
> separately and appropriately named config option,
> CONFIG_X86_INTEL_ATOM_PMC_DEBUG=y or so, with 'default n'.
>
> The file should probably be split up, the quirk moved into one of
> the generic quirk files, while pmc_atom.c should have the debugfs
> interface.
>
> That way we don't break anyone and remove the unnecessary code as
> well. It's also a nice clean up.
Thanks for the suggestion, I'll take a look if I can refine it after
I clean up my plate. Please expect a delay here.
-Aubrey
>
> Thanks,
>
> Ingo
>
>
On Thu, Oct 16, 2014 at 07:24:48AM +0200, Ingo Molnar wrote:
>
> * Dave Jones <[email protected]> wrote:
>
> > The Atom PMC driver is always built-in, regardless of whether
> > the kernel being built is going to be run on an Atom (or even Intel) CPU.
> >
> > Signed-off-by: Dave Jones <[email protected]>
> > Cc: One Thousand Gnomes <[email protected]>
> > Cc: [email protected]
> >
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index f2327e88e07c..b4dfd96aeea8 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -2485,7 +2485,8 @@ config X86_DMA_REMAP
> > depends on STA2X11
> >
> > config PMC_ATOM
> > - def_bool y
> > + tristate "Intel Atom SOC power management controller driver"
> > + default y
> > depends on PCI
> >
>
> So what I think should happen is to decouple of the 'must work'
> features from the optional debug features in this 'driver': the
> Atom SoC power-off quirk should be made unconditional, as long as
> the .config is Atom-supported (CPU_SUP_INTEL I guess).
>
> All the other bits, such as the debugfs interface, should be in a
> separately and appropriately named config option,
> CONFIG_X86_INTEL_ATOM_PMC_DEBUG=y or so, with 'default n'.
>
> The file should probably be split up, the quirk moved into one of
> the generic quirk files, while pmc_atom.c should have the debugfs
> interface.
>
The quirk isn't really a quirk, though. Maybe a separate poweroff driver
would make sense, similar to the other poweroff drivers in drivers/power/reset/.
It might also make sense to rework it as mfd client driver and tie it to
the lpc_ich driver, to be loaded when the lpc_ich driver is loaded.
I don't personally see a problem with making it tristate, as long as a remove
function is defined (which is not the case today). This way it would not have
to be loaded for non-Atom systems.
Guenter