Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Al Boldi]

Linus Torvalds wrote:
> On Wed, 25 Jul 2007, Len Brown wrote:
> > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
> > release
> >
> > Fixes regressions -- a build failure, an oops, some dmesg spam.
> > Also fixes some D-state issues and adds ACPI module auto-loading.
> > Yes, I'd hoped to get the last two in before rc1.
> > I'm hopeful that a couple-days into rc2 is sufficiently early for them.
>
> I hate pulling this, but I did. However, what I hate even more after
> having done so is that ACPI now seems to select CPU hotplug. Why?
>
> That is just *broken*. Sure, if you select STR or hibernation, we need CPU
> hotplug,

You are kidding, right?  CPU hotplug is broken big time; it kills a machine 
like virus-scanner.  I always turn it of as a rule.  And now you want 
STR/STD to be dependent on it?  Even on UP?  Why?


Thanks!

--
Al

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Len Brown]

On Wednesday 25 July 2007 16:40, Al Boldi wrote:
> Linus Torvalds wrote:
> > On Wed, 25 Jul 2007, Len Brown wrote:
> > > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
> > > release
> > >
> > > Fixes regressions -- a build failure, an oops, some dmesg spam.
> > > Also fixes some D-state issues and adds ACPI module auto-loading.
> > > Yes, I'd hoped to get the last two in before rc1.
> > > I'm hopeful that a couple-days into rc2 is sufficiently early for them.
> >
> > I hate pulling this, but I did. However, what I hate even more after
> > having done so is that ACPI now seems to select CPU hotplug. Why?
> >
> > That is just *broken*. Sure, if you select STR or hibernation, we need CPU
> > hotplug,
> 
> You are kidding, right?  CPU hotplug is broken big time; it kills a machine 
> like virus-scanner.  I always turn it of as a rule.  And now you want 
> STR/STD to be dependent on it?  Even on UP?  Why?

CPU_HOTPLUG is needed to take the non-boot processors off-line before the suspend,
and to bring them on-line upon the resume.  If you have specific problems
with bringing logical processors offline and online, then please speak up
because many are depending on this functionality working.

SMP system sleep support has always depended on CPU_HOTPLUG, per above.

No, uniprocessor system sleep does not depend on CPU_HOTPLUG.

-Len

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[david]

On Thu, 26 Jul 2007, Len Brown wrote:

> On Wednesday 25 July 2007 16:40, Al Boldi wrote:
>> Linus Torvalds wrote:
>>> On Wed, 25 Jul 2007, Len Brown wrote:
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
>>>> release
>>>>
>>>> Fixes regressions -- a build failure, an oops, some dmesg spam.
>>>> Also fixes some D-state issues and adds ACPI module auto-loading.
>>>> Yes, I'd hoped to get the last two in before rc1.
>>>> I'm hopeful that a couple-days into rc2 is sufficiently early for them.
>>>
>>> I hate pulling this, but I did. However, what I hate even more after
>>> having done so is that ACPI now seems to select CPU hotplug. Why?
>>>
>>> That is just *broken*. Sure, if you select STR or hibernation, we need CPU
>>> hotplug,
>>
>> You are kidding, right?  CPU hotplug is broken big time; it kills a machine
>> like virus-scanner.  I always turn it of as a rule.  And now you want
>> STR/STD to be dependent on it?  Even on UP?  Why?
>
> CPU_HOTPLUG is needed to take the non-boot processors off-line before the suspend,
> and to bring them on-line upon the resume.  If you have specific problems
> with bringing logical processors offline and online, then please speak up
> because many are depending on this functionality working.

nobody is arguing that CPU_HOTPLUG should not be a requirement for 
suspend, what we are questioning is why simply enabling ACPI should 
require CPU_HOTPLUG.

not everyone who configures ACPI wants to use suspend (of any flavor)

David Lang

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Al Boldi]

david@lang.hm wrote:
> On Thu, 26 Jul 2007, Len Brown wrote:
> > On Wednesday 25 July 2007 16:40, Al Boldi wrote:
> >> Linus Torvalds wrote:
> >>> On Wed, 25 Jul 2007, Len Brown wrote:
> >>>> git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
> >>>> release
> >>>>
> >>>> Fixes regressions -- a build failure, an oops, some dmesg spam.
> >>>> Also fixes some D-state issues and adds ACPI module auto-loading.
> >>>> Yes, I'd hoped to get the last two in before rc1.
> >>>> I'm hopeful that a couple-days into rc2 is sufficiently early for
> >>>> them.
> >>>
> >>> I hate pulling this, but I did. However, what I hate even more after
> >>> having done so is that ACPI now seems to select CPU hotplug. Why?
> >>>
> >>> That is just *broken*. Sure, if you select STR or hibernation, we need
> >>> CPU hotplug,
> >>
> >> You are kidding, right?  CPU hotplug is broken big time; it kills a
> >> machine like virus-scanner.  I always turn it of as a rule.  And now
> >> you want STR/STD to be dependent on it?  Even on UP?  Why?
> >
> > CPU_HOTPLUG is needed to take the non-boot processors off-line before
> > the suspend, and to bring them on-line upon the resume.  If you have
> > specific problems with bringing logical processors offline and online,
> > then please speak up because many are depending on this functionality
> > working.
>
> nobody is arguing that CPU_HOTPLUG should not be a requirement for
> suspend, what we are questioning is why simply enabling ACPI should
> require CPU_HOTPLUG.
>
> not everyone who configures ACPI wants to use suspend (of any flavor)

Actually, I would go one step further and just rip out hotplug from the 
kernel proper, and let userland handle it.  Really, just like devfs, hotplug 
has no place in the kernel.


Thanks!

--
Al

[GIT PATCH] ACPI patches for 2.6.23-rc1

[Len Brown]

Hi Linus,

please pull from: 

git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release

Fixes regressions -- a build failure, an oops, some dmesg spam.
Also fixes some D-state issues and adds ACPI module auto-loading.
Yes, I'd hoped to get the last two in before rc1.
I'm hopeful that a couple-days into rc2 is sufficiently early for them.

This will update the files shown below.

thanks!

-Len

ps. individual patches are available on linux-acpi@vger.kernel.org
and a consolidated plain patch is available here:
ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.23/acpi-release-20070126-2.6.23-rc1.diff.gz

 arch/i386/kernel/acpi/Makefile      |    2 
 arch/i386/kernel/setup.c            |    2 
 arch/i386/mm/init.c                 |    2 
 arch/ia64/kernel/acpi.c             |   19 ++
 arch/x86_64/kernel/acpi/Makefile    |    2 
 arch/x86_64/kernel/acpi/sleep.c     |    4 
 arch/x86_64/kernel/head.S           |    2 
 arch/x86_64/kernel/setup.c          |    2 
 drivers/acpi/Kconfig                |   64 +++------
 drivers/acpi/ac.c                   |    9 +
 drivers/acpi/acpi_memhotplug.c      |    8 +
 drivers/acpi/asus_acpi.c            |   11 +
 drivers/acpi/battery.c              |    9 +
 drivers/acpi/button.c               |   12 +
 drivers/acpi/container.c            |   10 +
 drivers/acpi/ec.c                   |    8 -
 drivers/acpi/events/evrgnini.c      |    2 
 drivers/acpi/fan.c                  |    8 +
 drivers/acpi/namespace/nsxfeval.c   |    2 
 drivers/acpi/pci_link.c             |    9 +
 drivers/acpi/pci_root.c             |    9 +
 drivers/acpi/power.c                |    8 +
 drivers/acpi/processor_core.c       |    8 +
 drivers/acpi/processor_throttling.c |   59 ++++++--
 drivers/acpi/sbs.c                  |   10 +
 drivers/acpi/scan.c                 |  156 ++++++++++++++++-------
 drivers/acpi/sleep/Makefile         |    4 
 drivers/acpi/sleep/main.c           |  162 +++++++++++++++++++-----
 drivers/acpi/sleep/poweroff.c       |    2 
 drivers/acpi/sleep/proc.c           |   20 ++
 drivers/acpi/sleep/wakeup.c         |    2 
 drivers/acpi/thermal.c              |    8 +
 drivers/acpi/utilities/uteval.c     |    4 
 drivers/acpi/video.c                |    8 +
 drivers/char/hpet.c                 |    8 +
 drivers/input/misc/atlas_btns.c     |    9 +
 drivers/misc/asus-laptop.c          |   41 ++++--
 drivers/misc/sony-laptop.c          |   21 ++-
 drivers/misc/thinkpad_acpi.c        |   20 ++
 drivers/misc/thinkpad_acpi.h        |    2 
 drivers/pci/pci-acpi.c              |   28 +++-
 drivers/pci/pci.c                   |    8 -
 drivers/pci/pci.h                   |    2 
 drivers/pnp/driver.c                |    5 
 drivers/pnp/pnpacpi/core.c          |   33 +++-
 include/acpi/acpi_bus.h             |    7 -
 include/acpi/acpi_drivers.h         |   25 +--
 include/acpi/actypes.h              |    6 
 include/acpi/acutils.h              |    4 
 include/asm-i386/acpi.h             |   23 +--
 include/asm-i386/suspend.h          |    2 
 include/asm-ia64/acpi.h             |    5 
 include/asm-x86_64/acpi.h           |   22 +--
 include/asm-x86_64/suspend.h        |    2 
 include/linux/acpi.h                |    1 
 include/linux/mod_devicetable.h     |    6 
 include/linux/pnp.h                 |    4 
 kernel/sysctl.c                     |    2 
 scripts/mod/file2alias.c            |   12 +
 59 files changed, 668 insertions(+), 277 deletions(-)

through these commits:

Al Viro (1):
      ACPI: asus-laptop: Fix failure exits

Len Brown (5):
      ACPI: Kconfig: CONFIG_ACPI_PROCFS now defaults to N
      ACPI: Kconfig: fold /proc/acpi/sleep under CONFIG_ACPI_PROCFS
      ACPI: Kconfig: always enable CONFIG_ACPI_SLEEP on X86
      ACPI: quiet ACPI Exceptions due to no _PTC or _TSS
      ACPI: Kconfig: remove CONFIG_ACPI_SLEEP from source

Luming Yu (1):
      ACPI: fix oops due to typo in new throttling code

Rafael J. Wysocki (2):
      ACPI: Implement the set_target() callback from pm_ops
      ACPI: Remove references to ACPI_STATE_S2 from acpi_pm_enter

Shaohua Li (4):
      ACPI: Add acpi_pm_device_sleep_state helper routine
      ACPI, PNP: hook ACPI D-state to PNP suspend/resume
      ACPI: Use ACPI methods to select PCI device suspend state
      ACPI: ignore _PSx method for hotplugable PCI devices

Thomas Renninger (3):
      ACPI: autoload modules - ACPICA modifications
      ACPI: autoload modules - Create ACPI alias interface
      ACPI: autoload modules - Create __mod_acpi_device_table symbol for all ACPI drivers

with this log:

commit 323ef30af3a0da47cc761b04b262d98d0fe79126
Merge: cb3e0c1... 1ba90e3...
Author: Len Brown <len.brown@intel.com>
Date:   Wed Jul 25 01:36:53 2007 -0400

    Pull auto-load-modules into release branch

commit cb3e0c107bebc6cf3e7158f7aa54c32017c7d4c4
Merge: 1e1f3f2... 50ad147...
Author: Len Brown <len.brown@intel.com>
Date:   Wed Jul 25 01:36:31 2007 -0400

    Pull d-states into release branch
    
    Conflicts:
    
    	drivers/acpi/sleep/main.c
    
    Signed-off-by: Len Brown <len.brown@intel.com>

commit 1e1f3f24cdbc53e67acd7b2e37e6cf0cb11bd13c
Merge: c30c620... e8b2fd0...
Author: Len Brown <len.brown@intel.com>
Date:   Wed Jul 25 01:35:25 2007 -0400

    Pull kconfig into release branch

commit e8b2fd01228f690c3e0cb3f14facfa8d93d4adae
Author: Len Brown <len.brown@intel.com>
Date:   Tue Jul 24 22:26:33 2007 -0400

    ACPI: Kconfig: remove CONFIG_ACPI_SLEEP from source
    
    As it was a synonym for (CONFIG_ACPI && CONFIG_X86),
    the ifdefs for it were more clutter than they were worth.
    
    For ia64, just add a few stubs in anticipation of future
    S3 or S4 support.
    
    Signed-off-by: Len Brown <len.brown@intel.com>

commit c30c620ee1cc351bcc149c4280e1166998df0064
Author: Len Brown <len.brown@intel.com>
Date:   Wed Jul 25 00:57:46 2007 -0400

    ACPI: quiet ACPI Exceptions due to no _PTC or _TSS
    
    ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating _PTC [20070126]
    ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126]
    
    These methods are optional, so Linux should not
    alarm users when they are not found.
    
    http://bugzilla.kernel.org/show_bug.cgi?id=8802
    
    Signed-off-by: Len Brown <len.brown@intel.com>
    Acked-by: Luming Yu <luming.yu@intel.com>

commit 50ad147aa09c829cd452fae6ca99396c0b5b0695
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Tue Jul 24 11:58:39 2007 +0200

    ACPI: Remove references to ACPI_STATE_S2 from acpi_pm_enter
    
    Remove references to ACPI_STATE_S2, introduced by
    acpi-implement-the-set_target-callback-from-pm_ops.patch, from acpi_pm_enter().
    
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit 7c5aa6642fa26641ebf286966a165aec71c91991
Author: Len Brown <len.brown@intel.com>
Date:   Tue Jul 24 02:25:03 2007 -0400

    ACPI: Kconfig: always enable CONFIG_ACPI_SLEEP on X86
    
    The SMP dependency on HOTPLUG_CPU and SUSPEND_SMP
    caused more harm than good -- making ACPI sleep
    support vanish for configs missing those options.
    So simply select them on the (ACPI && SMP && X86) systems
    that need them.
    
    Also, remove the prompt for ACPI_SLEEP,
    virtually nobody (intentionally) enables ACPI without it.
    
    Signed-off-by: Len Brown <len.brown@intel.com>

commit 43532c8a46ae313c2da3baa7598a1de4d403ba83
Author: Len Brown <len.brown@intel.com>
Date:   Tue Jul 24 02:16:50 2007 -0400

    ACPI: Kconfig: fold /proc/acpi/sleep under CONFIG_ACPI_PROCFS
    
    /proc/acpi/sleep has had its own "default n" option,
    ACPI_SLEEP_PROC_SLEEP, for many months.
    Time to delete ACPI_SLEEP_PROC_SLEEP.
    
    Users that still need /proc/acpi/sleep can still get it
    along with the other deprecated /proc/acpi files
    by enabling CONFIG_ACPI_PROCFS.
    
    Also delete ACPI_SLEEP_PROC_FS, which was an umbrella
    for /proc/acpi/sleep, wakeup, alarm, because it was
    effectively just a synonym for ACPI_SLEEP.
    
    Signed-off-by: Len Brown <len.brown@intel.com>

commit fb804714560463534ebcb538a3b0a3c687a830ec
Author: Len Brown <len.brown@intel.com>
Date:   Tue Jul 24 01:50:46 2007 -0400

    ACPI: Kconfig: CONFIG_ACPI_PROCFS now defaults to N
    
    delete "default y" from CONFIG_ACPI_PROCFS
    (effectively making the default 'N')
    
    List exactly what /proc files this option controls,
    and clarify that it doesn't change non-deprecated files.
    
    Signed-off-by: Len Brown <len.brown@intel.com>

commit 1ba90e3a87c46500623afdc3898573e4a5ebb21b
Author: Thomas Renninger <trenn@suse.de>
Date:   Mon Jul 23 14:44:41 2007 +0200

    ACPI: autoload modules - Create __mod_acpi_device_table symbol for all ACPI drivers
    
    modpost is going to use these to create e.g. acpi:ACPI0001
    in modules.alias.
    
    Signed-off-by: Thomas Renninger <trenn@suse.de>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit 29b71a1ca74491fab9fed09e9d835d840d042690
Author: Thomas Renninger <trenn@suse.de>
Date:   Mon Jul 23 14:43:51 2007 +0200

    ACPI: autoload modules - Create ACPI alias interface
    
    Modify modpost (file2alias.c) to add acpi*:XYZ0001: alias in modules.alias
    like:
    grep acpi /lib/modules/2.6.22-rc4-default/modules.alias
    alias acpi*:SNY5001:* sony_laptop
    alias acpi*:SNY6001:* sony_laptop
    for e.g. the sony_laptop module.
    This module matches against all ACPI devices with a HID or CID of SNY5001
    or SNY6001
    
    Export an uevent and modalias sysfs file containing the string:
    [MODALIAS=]acpi:PNP0C0C:
    additional CIDs are concatenated at the end.
    
    Signed-off-by: Thomas Renninger <trenn@suse.de>
    Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit 8c8eb78f673c07b60f31751e1e47ac367c60c6b7
Author: Thomas Renninger <trenn@suse.de>
Date:   Mon Jul 23 14:43:32 2007 +0200

    ACPI: autoload modules - ACPICA modifications
    
    Define standardized HIDs - Rename current acpi_device_id to acpica_device_id
    
    Signed-off-by: Thomas Renninger <trenn@suse.de>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit 3b0d71170d37878bbb1203ebc3f92e36d6151a80
Author: Al Viro <viro@ftp.linux.org.uk>
Date:   Mon Jul 23 11:21:34 2007 +0100

    ACPI: asus-laptop: Fix failure exits
    
    > Subject         : drivers/misc/asus-laptop.c:*: error: 'struct led_classdev' has no member named 'class_dev'
    > References      : http://lkml.org/lkml/2007/7/22/299
    > Submitter       : Gabriel C <nix.or.die@googlemail.com>
    
    Fallout from f8a7c6fe14f556ca8eeddce258cb21392d0c3a2f.  However, looking
    at it shows that checks done in ASUS_LED_UNREGISTER() can't trigger
    at all (we never get to asus_led_exit() if registration fails) and
    if that registration fails, we actually leak stuff.  IOW, it's worse
    than just replacing class_dev with dev in there - the tests themselves
    had been papering over the lousy cleanup logics.
    
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit 3cc2649b879f0e83fd51b14c82bad5f8f208591e
Author: Luming Yu <luming.yu@gmail.com>
Date:   Mon Jul 23 12:39:28 2007 -0400

    ACPI: fix oops due to typo in new throttling code
    
    Signed-off-by: Luming Yu <luming.yu@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit 10b3dcae0f275e2546e55303d64ddbb58cec7599
Author: Shaohua Li <shaohua.li@intel.com>
Date:   Fri Jul 20 10:03:25 2007 +0800

    ACPI: ignore _PSx method for hotplugable PCI devices
    
    If the ACPI device has _EJ0, ignore the device.
    _PSx will set power for the slot,
    and the hotplug driver will take care of _PSx.
    
    Signed-off-by: Shaohua Li <shaohua.li@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit ab826ca4cf2fe8ebcfd21189ca8bfeb47ca88359
Author: Shaohua Li <shaohua.li@intel.com>
Date:   Fri Jul 20 10:03:22 2007 +0800

    ACPI: Use ACPI methods to select PCI device suspend state
    
    applied after Rafel's 'PM: Update global suspend and hibernation
    operations framework' patch set
    
    Signed-off-by: Shaohua Li<shaohua.li@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit fc30e68e88baf463683bde43347756889ba2ffae
Author: Shaohua Li <shaohua.li@intel.com>
Date:   Fri Jul 20 10:03:20 2007 +0800

    ACPI, PNP: hook ACPI D-state to PNP suspend/resume
    
    applied after Rafel's 'PM: Update global suspend and hibernation operations framework' patch set
    
    Signed-off-by: Shaohua Li <shaohua.li@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit fd4aff1a28eecbd729b409bf7d3eff5948f20414
Author: Shaohua Li <shaohua.li@intel.com>
Date:   Tue Jul 17 22:40:25 2007 +0200

    ACPI: Add acpi_pm_device_sleep_state helper routine
    
    Based on the David Brownell's patch at
    http://marc.info/?l=linux-acpi&m=117873972806360&w=2
    updated by: Rafael J. Wysocki <rjw@sisk.pl>
    
    Add a helper routine returning the lowest power (highest number) ACPI device
    power state that given device can be in while the system is in the sleep state
    indicated by acpi_target_sleep_state .
    
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Acked-by: Pavel Machek <pavel@ucw.cz>
    Signed-off-by: Len Brown <len.brown@intel.com>

commit e9b3aba887f47f9cd64de20fec9c333a932b70dc
Author: Rafael J. Wysocki <rjw@sisk.pl>
Date:   Tue Jul 17 22:40:06 2007 +0200

    ACPI: Implement the set_target() callback from pm_ops
    
    In the future some drivers may need to use ACPI to determine the low power
    states in which to place their devices, but to provide the drivers with this
    information the ACPI core needs to know what sleep state the system is going to
    enter.  Namely, the device's state should not be too high power for given system
    sleep state and, if the device is supposed to be able to wake up the system, its
    state should not be too low power for the wake up to be possible).  For this
    purpose, the ACPI core needs to implement the set_target() method in 'struct
    pm_ops' and store the target system sleep state passed by the PM core in a
    variable.
    
    Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    Acked-by: Pavel Machek <pavel@ucw.cz>
    Acked-by: David Brownell <david-b@pacbell.net>
    Signed-off-by: Len Brown <len.brown@intel.com>

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Tino Keitel]

On Wed, Jul 25, 2007 at 12:38:50 -0400, Len Brown wrote:
> Len Brown (5):
>       ACPI: Kconfig: CONFIG_ACPI_PROCFS now defaults to N

Hi,

where can I find the information in /proc/acpi/battery and
/proc/acpi/processor without procfs?

Regards,
Tino

Please CC: me in replies.

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Len Brown]

On Wednesday 25 July 2007 12:49, Tino Keitel wrote:
> On Wed, Jul 25, 2007 at 12:38:50 -0400, Len Brown wrote:
> > Len Brown (5):
> >       ACPI: Kconfig: CONFIG_ACPI_PROCFS now defaults to N
> 
> Hi,
> 
> where can I find the information in /proc/acpi/battery and
> /proc/acpi/processor without procfs?

CONFIG_ACPI_PROCFS applies only to the deprecated /proc files
listed in the Kconfig help -- it doesn't apply (yet)
to /proc/acpi/battery and /proc/acpi/processor

see the patch here:

http://marc.info/?l=linux-acpi&m=118534272010912&w=2

cheers,
-Len

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Linus Torvalds]

On Wed, 25 Jul 2007, Len Brown wrote:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release
> 
> Fixes regressions -- a build failure, an oops, some dmesg spam.
> Also fixes some D-state issues and adds ACPI module auto-loading.
> Yes, I'd hoped to get the last two in before rc1.
> I'm hopeful that a couple-days into rc2 is sufficiently early for them.

I hate pulling this, but I did. However, what I hate even more after 
having done so is that ACPI now seems to select CPU hotplug. Why?

That is just *broken*. Sure, if you select STR or hibernation, we need CPU 
hotplug, but just for picking ACPI? Why?

		Linus

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Len Brown]

On Wednesday 25 July 2007 14:48, Linus Torvalds wrote:

> ... ACPI now seems to select CPU hotplug. Why? 

ACPI=y SMP=y systems require SUSPEND_SMP=y for system sleep support,
and that requires HOTPLUG_CPU=y.

Note that ACPI=y SMP=n systems do not need it,
and thus will not select HOTPLUG_CPU=y

> That is just *broken*. Sure, if you select STR or hibernation, we need CPU 
> hotplug, but just for picking ACPI? Why?

My assumption is that if somebody selects CONFIG_ACPI,
that 99% of the time, they intend that to include support for
the ACPI hooks for system sleep states.

Conversely, supporting the 1% of people who don't want it
isn't worth messing with the 99% who do, nor is
the burden of yet another config option to maintain and
#ifdefs in the code.

On UP, they'd get ACPI system sleep support 100% of the time
by default, but on SMP this option had become problematic.

We used to have this:

if ACPI
...
config ACPI_SLEEP
        bool "Sleep States"
        depends on X86 && (!SMP || SUSPEND_SMP)
        depends on PM
        default y

So the poster-child failure was i386/defconfig itself...
It couldn't support suspend to RAM because it didn't include
CONFIG_ACPI_SLEEP.  Not trivial for a user to select it
when it doesn't even appear on the menu.  It doesn't appear
because CONFIG_SUSPEND_SMP isn't enabled, but that doesn't
appear either -- because CONFIG_HOTPLUG_CPU isn't selected.

Most users don't want that.

So today we have this:

menuconfig ACPI
	...
        select HOTPLUG_CPU if X86 && SMP
        select SUSPEND_SMP if X86 && SMP

Which I think leads to fewer surprises, and less complicated code.
(even though using select itself is fraught with peril:-)

thanks,
-Len

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[david]

On Wed, 25 Jul 2007, Len Brown wrote:

> On Wednesday 25 July 2007 14:48, Linus Torvalds wrote:
>
>> ... ACPI now seems to select CPU hotplug. Why?
>
> ACPI=y SMP=y systems require SUSPEND_SMP=y for system sleep support,
> and that requires HOTPLUG_CPU=y.
>
> Note that ACPI=y SMP=n systems do not need it,
> and thus will not select HOTPLUG_CPU=y
>
>> That is just *broken*. Sure, if you select STR or hibernation, we need CPU
>> hotplug, but just for picking ACPI? Why?
>
> My assumption is that if somebody selects CONFIG_ACPI,
> that 99% of the time, they intend that to include support for
> the ACPI hooks for system sleep states.
>
> Conversely, supporting the 1% of people who don't want it
> isn't worth messing with the 99% who do, nor is
> the burden of yet another config option to maintain and
> #ifdefs in the code.

so you are saying that you know better then we do what we need?

some people configure ACPI only becouse their system won't work properly 
without it. they have no intention of ever doing a STR or hibernate.

David Lang

> On UP, they'd get ACPI system sleep support 100% of the time
> by default, but on SMP this option had become problematic.
>
> We used to have this:
>
> if ACPI
> ...
> config ACPI_SLEEP
>        bool "Sleep States"
>        depends on X86 && (!SMP || SUSPEND_SMP)
>        depends on PM
>        default y
>
> So the poster-child failure was i386/defconfig itself...
> It couldn't support suspend to RAM because it didn't include
> CONFIG_ACPI_SLEEP.  Not trivial for a user to select it
> when it doesn't even appear on the menu.  It doesn't appear
> because CONFIG_SUSPEND_SMP isn't enabled, but that doesn't
> appear either -- because CONFIG_HOTPLUG_CPU isn't selected.

so have something like

config ACPI_SLEEP
         select HOTPLUG_CPU if X86 && SMP
         select SUSPEND_SMP if X86 && SMP

instead of makeing it dependant on ACPI.

David Lang

> Most users don't want that.
>
> So today we have this:
>
> menuconfig ACPI
> 	...
>        select HOTPLUG_CPU if X86 && SMP
>        select SUSPEND_SMP if X86 && SMP
>
> Which I think leads to fewer surprises, and less complicated code.
> (even though using select itself is fraught with peril:-)
>
> thanks,
> -Len
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Len Brown]

On Wednesday 25 July 2007 22:20, david@lang.hm wrote:
> On Wed, 25 Jul 2007, Len Brown wrote:
> 
> > On Wednesday 25 July 2007 14:48, Linus Torvalds wrote:
> >
> >> ... ACPI now seems to select CPU hotplug. Why?
> >
> > ACPI=y SMP=y systems require SUSPEND_SMP=y for system sleep support,
> > and that requires HOTPLUG_CPU=y.
> >
> > Note that ACPI=y SMP=n systems do not need it,
> > and thus will not select HOTPLUG_CPU=y
> >
> >> That is just *broken*. Sure, if you select STR or hibernation, we need CPU
> >> hotplug, but just for picking ACPI? Why?
> >
> > My assumption is that if somebody selects CONFIG_ACPI,
> > that 99% of the time, they intend that to include support for
> > the ACPI hooks for system sleep states.
> >
> > Conversely, supporting the 1% of people who don't want it
> > isn't worth messing with the 99% who do, nor is
> > the burden of yet another config option to maintain and
> > #ifdefs in the code.
> 
> so you are saying that you know better then we do what we need?

Feel free to share what you know about the benefits vs. the costs
of maintaining CONFIG_ACPI_SLEEP as a build option.

> some people configure ACPI only becouse their system won't work properly 
> without it. they have no intention of ever doing a STR or hibernate.

I agree.

Further, I expect that 100% - (some people %) = 99%

If you feel that your system has been degraded
because it now includes what used to be excluded under
CONFIG_ACPI_SLEEP=n, please let me know how.

> > On UP, they'd get ACPI system sleep support 100% of the time
> > by default, but on SMP this option had become problematic.
> >
> > We used to have this:
> >
> > if ACPI
> > ...
> > config ACPI_SLEEP
> >        bool "Sleep States"
> >        depends on X86 && (!SMP || SUSPEND_SMP)
> >        depends on PM
> >        default y
> >
> > So the poster-child failure was i386/defconfig itself...
> > It couldn't support suspend to RAM because it didn't include
> > CONFIG_ACPI_SLEEP.  Not trivial for a user to select it
> > when it doesn't even appear on the menu.  It doesn't appear
> > because CONFIG_SUSPEND_SMP isn't enabled, but that doesn't
> > appear either -- because CONFIG_HOTPLUG_CPU isn't selected.
> 
> so have something like
> 
> config ACPI_SLEEP
>          select HOTPLUG_CPU if X86 && SMP
>          select SUSPEND_SMP if X86 && SMP
> 
> instead of makeing it dependant on ACPI.

If more config options where better, then this
would indeed be an improvement over 2.6.22.
But more config options isn't better -- except for "some people":-)

thanks.
-Len

> > Most users don't want that.
> >
> > So today we have this:
> >
> > menuconfig ACPI
> > 	...
> >        select HOTPLUG_CPU if X86 && SMP
> >        select SUSPEND_SMP if X86 && SMP
> >
> > Which I think leads to fewer surprises, and less complicated code.
> > (even though using select itself is fraught with peril:-)
> >
> > thanks,
> > -Len
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[david]

On Thu, 26 Jul 2007, Len Brown wrote:

>>> CONFIG_ACPI_SLEEP.  Not trivial for a user to select it
>>> when it doesn't even appear on the menu.  It doesn't appear
>>> because CONFIG_SUSPEND_SMP isn't enabled, but that doesn't
>>> appear either -- because CONFIG_HOTPLUG_CPU isn't selected.
>>
>> so have something like
>>
>> config ACPI_SLEEP
>>          select HOTPLUG_CPU if X86 && SMP
>>          select SUSPEND_SMP if X86 && SMP
>>
>> instead of makeing it dependant on ACPI.
>
> If more config options where better, then this
> would indeed be an improvement over 2.6.22.
> But more config options isn't better -- except for "some people":-)

coupling unrelated fetures togeather isn't better either.

David Lang

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Linus Torvalds]

On Thu, 26 Jul 2007, Len Brown wrote:
> 
> Feel free to share what you know about the benefits vs. the costs
> of maintaining CONFIG_ACPI_SLEEP as a build option.

Why don't you just make CONFIG_ACPI_SLEEP dependent on SOFTWARE_SUSPEND 
and STR?

> If you feel that your system has been degraded
> because it now includes what used to be excluded under
> CONFIG_ACPI_SLEEP=n, please let me know how.

I feel that I get asked to include a feature that 
 (a) I have no interest in on that machine
 (b) I didn't need to include before.

What was the advantage? And what was it that caused something like this to 
be a post-rc1 thing. That makes me really unhappy. This is a *regression*.

		Linus

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Len Brown]

On Thursday 26 July 2007 02:55, Linus Torvalds wrote:
> 
> On Thu, 26 Jul 2007, Len Brown wrote:
> > 
> > Feel free to share what you know about the benefits vs. the costs
> > of maintaining CONFIG_ACPI_SLEEP as a build option.
> 
> Why don't you just make CONFIG_ACPI_SLEEP dependent on SOFTWARE_SUSPEND 
> and STR?

CONFIG_STR doesn't exist.

I agree it is an attractive notion to have a high level feature presented
to the user, and that the tools should select what is needed to satisfy the
user's request.  Unfortunately Kconfig is exceptionally bad at supporting
this model.  "depend" frustrates users by making config options vanish
without explanation, and "select" is fundamentally broken
because it doesn't enforce dependencies.

> > If you feel that your system has been degraded
> > because it now includes what used to be excluded under
> > CONFIG_ACPI_SLEEP=n, please let me know how.
> 
> I feel that I get asked to include a feature that
>  (a) I have no interest in on that machine
>  (b) I didn't need to include before.
> 
> What was the advantage? And what was it that caused something like this to 
> be a post-rc1 thing. That makes me really unhappy. This is a *regression*.

I'm sorry that one fewer config options has offended your feeling of freedom,
honestly, I am.

I was actually asking how somebody's _system_ has been degraded
by this change -- but I haven't got an objective answer to that one yet.

As I said in my pull request, I agree that the D-state fixes ideally
should have merged a week earlier -- before the rc1 cutoff.
Indeed, we had a hack that could have gone up much earlier.
However, we waited for Rafael's more general list-blessed solution --
and it turned out that solution tripped over CONFIG_ACPI_SLEEP=n.

The reason is because there is a dependency between D-states and S-states.
In particular, devices which are enabled to be system wakeup devices
can be limited in what D-states they can enter (else they may
no longer be able to wake up the system when it is suspended)

I figured that rather than adding more ifdefs to solve that problem,
it was simpler to remove ifdefs.  I was also shocked to find i386 defconfig
with CONFIG_ACPI_SLEEP=n.  Maybe others are not shocked by this
and there is a reason that defconfig on x86_64 supports sleep
and i386 does not.  I assumed it was a bug, maybe I was wrong.

The context for this is the EPA ENERGY STAR specification for Computers,
which went into effect this month.  This spec says that systems which
can not automatically go into suspend within 15 minutes of idle
can _not_ earn a sticker.  No sticker, no client computer sales to governments.
If Linux can't get STR working, broadly deployed, and enabled by default,
then our plans for world domination are going to take a significant hit.

yes, I understand that there are SMP systems that want ACPI and don't
need sleep or CONFIG_HOGPLUG_CPU.  However, I don't see major distros
shipping kernels to their server customers that way, so I didn't think
it would offend a significant part of the community's sense of freedom
if this config option were removed.  Maybe I was wrong.

Obviously, your vote counts more than the sum total of a lot of the community,
so if you want me to put a config option in to allow ACPI w/o ACPI_SLEEP,
I'll simply do it for you.  However, I could do a better job of it
if I had a clear understanding of what the technical benefit of
that option is supposed to be, and how it will make Linux better.

-Len

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Linus Torvalds]

On Thu, 26 Jul 2007, Len Brown wrote:
> 
> I was actually asking how somebody's _system_ has been degraded
> by this change -- but I haven't got an objective answer to that one yet.

According to that logic, we should always compile *everything* in.

Do you see the problem?

And can you realize that this should not have happened after -rc1?

So send me the patch to undo this breakage, and stop making excuses.

		Linus

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[david]

On Thu, 26 Jul 2007, Len Brown wrote:

> 
> On Thursday 26 July 2007 02:55, Linus Torvalds wrote:
>>
>> On Thu, 26 Jul 2007, Len Brown wrote:
>
>>> If you feel that your system has been degraded
>>> because it now includes what used to be excluded under
>>> CONFIG_ACPI_SLEEP=n, please let me know how.
>>
>> I feel that I get asked to include a feature that
>>  (a) I have no interest in on that machine
>>  (b) I didn't need to include before.
>>
>> What was the advantage? And what was it that caused something like this to
>> be a post-rc1 thing. That makes me really unhappy. This is a *regression*.
>
> I'm sorry that one fewer config options has offended your feeling of freedom,
> honestly, I am.
>
> I was actually asking how somebody's _system_ has been degraded
> by this change -- but I haven't got an objective answer to that one yet.

how about the fact that Linus found the problem becouse his system didn't 
work right?

> As I said in my pull request, I agree that the D-state fixes ideally
> should have merged a week earlier -- before the rc1 cutoff.
> Indeed, we had a hack that could have gone up much earlier.
> However, we waited for Rafael's more general list-blessed solution --
> and it turned out that solution tripped over CONFIG_ACPI_SLEEP=n.
>
> The reason is because there is a dependency between D-states and S-states.
> In particular, devices which are enabled to be system wakeup devices
> can be limited in what D-states they can enter (else they may
> no longer be able to wake up the system when it is suspended)

you are assuming that people want to suspend

> I figured that rather than adding more ifdefs to solve that problem,
> it was simpler to remove ifdefs.  I was also shocked to find i386 defconfig
> with CONFIG_ACPI_SLEEP=n.  Maybe others are not shocked by this
> and there is a reason that defconfig on x86_64 supports sleep
> and i386 does not.  I assumed it was a bug, maybe I was wrong.
>
> The context for this is the EPA ENERGY STAR specification for Computers,
> which went into effect this month.  This spec says that systems which
> can not automatically go into suspend within 15 minutes of idle
> can _not_ earn a sticker.  No sticker, no client computer sales to governments.
> If Linux can't get STR working, broadly deployed, and enabled by default,
> then our plans for world domination are going to take a significant hit.

isn't the sticker and specification for hardware? but in any case not all 
hardware needs to get that sticker.

> yes, I understand that there are SMP systems that want ACPI and don't
> need sleep or CONFIG_HOGPLUG_CPU.  However, I don't see major distros
> shipping kernels to their server customers that way, so I didn't think
> it would offend a significant part of the community's sense of freedom
> if this config option were removed.  Maybe I was wrong.

distros aren't everything

> Obviously, your vote counts more than the sum total of a lot of the community,
> so if you want me to put a config option in to allow ACPI w/o ACPI_SLEEP,
> I'll simply do it for you.  However, I could do a better job of it
> if I had a clear understanding of what the technical benefit of
> that option is supposed to be, and how it will make Linux better.

the idea is that code that doesn't get compiled into the kernel can't 
cause the system to misbehave.

David Lang

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Linus Torvalds]

On Thu, 26 Jul 2007, david@lang.hm wrote:
> 
> how about the fact that Linus found the problem becouse his system didn't work
> right?

No, it works, it just forces me to use a configuration that I'm not 
personally interested in on that particular machine.

I tend to like using minimal kernels. I don't use modules on most of my 
machines, and I actually look over my config. Maybe I'm odd. But I think 
it's a good thing to let people decide what they want (and what they do 
_not_ want) in their kernels.

I think forcing people to use CPU_HOTPLUG is a mistake. There's a reason 
that existed as a config option. The ACPI changes basically mean that the 
whole CPU_HOTPLUG config option is totally pointless, because everybody is 
forced to have it.

		Linus

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Jeff Garzik]

Linus Torvalds wrote:
> 
> On Thu, 26 Jul 2007, david@lang.hm wrote:
>> how about the fact that Linus found the problem becouse his system didn't work
>> right?
> 
> No, it works, it just forces me to use a configuration that I'm not 
> personally interested in on that particular machine.
> 
> I tend to like using minimal kernels. I don't use modules on most of my 
> machines, and I actually look over my config. Maybe I'm odd. But I think 
> it's a good thing to let people decide what they want (and what they do 
> _not_ want) in their kernels.
> 
> I think forcing people to use CPU_HOTPLUG is a mistake. There's a reason 
> that existed as a config option. The ACPI changes basically mean that the 
> whole CPU_HOTPLUG config option is totally pointless, because everybody is 
> forced to have it.

Indeed -- forced to have a feature that is applicable in reality to 
0.00000001% of the user population, I'd wager :)

I read and hone my .config to utter minimalist perfection too :)  So 
count my vote here too, for -not- wanting CPU_HOTPLUG dead code in my 
kernel.

	Jeff

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Len Brown]

> > I was actually asking how somebody's _system_ has been degraded
> > by this change -- but I haven't got an objective answer to that one yet.
> 
> how about the fact that Linus found the problem becouse his system didn't 
> work right?

I guess I missed that message.  What system didn't work right,
and how did it fail?


> > The context for this is the EPA ENERGY STAR specification for Computers,
> > which went into effect this month.  This spec says that systems which
> > can not automatically go into suspend within 15 minutes of idle
> > can _not_ earn a sticker.  No sticker, no client computer sales to governments.
> > If Linux can't get STR working, broadly deployed, and enabled by default,
> > then our plans for world domination are going to take a significant hit.
> 
> isn't the sticker and specification for hardware? but in any case not all 
> hardware needs to get that sticker.

No, the sticker is for the entire system (HW+SW) as shipped to the customer.
ie. It is possible for the same hardware solution running Windows
to earn a sticker and land a sale, while Linux fails to earn a sticker
and loses the contract.

You're right, not all systems need to earn the sticker.
Indeed, ENERGY STAR is supposed to be a "premium" brand.
However, several governments disqualify bids for large
contracts if they do not meet ENERGY STAR.

> > yes, I understand that there are SMP systems that want ACPI and don't
> > need sleep or CONFIG_HOGPLUG_CPU.  However, I don't see major distros
> > shipping kernels to their server customers that way, so I didn't think
> > it would offend a significant part of the community's sense of freedom
> > if this config option were removed.  Maybe I was wrong.
> 
> distros aren't everything

Apparently a market for more config options of is alive and well.
Thank you for helping make the future of Linux more clear to me.

-Len

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Gabriel C]

Len Brown wrote:
> On Wednesday 25 July 2007 22:20, david@lang.hm wrote:
>> On Wed, 25 Jul 2007, Len Brown wrote:
>>
>>> On Wednesday 25 July 2007 14:48, Linus Torvalds wrote:
>>>
>>>> ... ACPI now seems to select CPU hotplug. Why?
>>> ACPI=y SMP=y systems require SUSPEND_SMP=y for system sleep support,
>>> and that requires HOTPLUG_CPU=y.
>>>

Well *require* if I want SUSPEND*.

>>> Note that ACPI=y SMP=n systems do not need it,
>>> and thus will not select HOTPLUG_CPU=y
>>>
>>>> That is just *broken*. Sure, if you select STR or hibernation, we need CPU
>>>> hotplug, but just for picking ACPI? Why?
>>> My assumption is that if somebody selects CONFIG_ACPI,
>>> that 99% of the time, they intend that to include support for
>>> the ACPI hooks for system sleep states.
>>>
>>> Conversely, supporting the 1% of people who don't want it
>>> isn't worth messing with the 99% who do, nor is
>>> the burden of yet another config option to maintain and
>>> #ifdefs in the code.
>> so you are saying that you know better then we do what we need?
> 
> Feel free to share what you know about the benefits vs. the costs
> of maintaining CONFIG_ACPI_SLEEP as a build option.
> 
>> some people configure ACPI only becouse their system won't work properly 
>> without it. they have no intention of ever doing a STR or hibernate.
> 
> I agree.
> 
> Further, I expect that 100% - (some people %) = 99%
> 
> If you feel that your system has been degraded
> because it now includes what used to be excluded under
> CONFIG_ACPI_SLEEP=n, please let me know how.

Even if I want to SUSPEND* to <something> I can't on my Dell Precision 530 boxes , 
SCSI is broken with suspend therefore all these boxes have the whole SUSPEND* off, 
all I need is ACPI.

So why you think I want to have this all enabled by default now ? 
Just to bloat the kernel with something doesn't even work for me ?

And I don't get from where you have the '99%' thing ?

 > 
>>> On UP, they'd get ACPI system sleep support 100% of the time
>>> by default, but on SMP this option had become problematic.
>>>
>>> We used to have this:
>>>
>>> if ACPI
>>> ...
>>> config ACPI_SLEEP
>>>        bool "Sleep States"
>>>        depends on X86 && (!SMP || SUSPEND_SMP)
>>>        depends on PM
>>>        default y
>>>
>>> So the poster-child failure was i386/defconfig itself...
>>> It couldn't support suspend to RAM because it didn't include
>>> CONFIG_ACPI_SLEEP.  Not trivial for a user to select it
>>> when it doesn't even appear on the menu.  It doesn't appear
>>> because CONFIG_SUSPEND_SMP isn't enabled, but that doesn't
>>> appear either -- because CONFIG_HOTPLUG_CPU isn't selected.
>> so have something like
>>
>> config ACPI_SLEEP
>>          select HOTPLUG_CPU if X86 && SMP
>>          select SUSPEND_SMP if X86 && SMP
>>
>> instead of makeing it dependant on ACPI.
> 
> If more config options where better, then this
> would indeed be an improvement over 2.6.22.
> But more config options isn't better -- except for "some people":-)

But in this case some config / new config is better.

I do not need ACPI to SUSPEND but to make the box work properly.

Ohh and isn't better to make 'ACPI_PROCESSOR  select SUSPEND_SMP and HOTPLUG_CPU if X86 && SMP' ?

...

config ACPI_PROCESSOR
        tristate "Processor"
        default y
        help
          This driver installs ACPI as the idle handler for Linux, and uses
          ACPI C2 and C3 processor states to save power, on systems that
          support it.  It is required by several flavors of cpufreq
          Performance-state drivers.

...

Is more logical for me to do it here but I may be wrong.

> 
> thanks.
> -Len
> 


Gabriel

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Len Brown]

On Thursday 26 July 2007 06:07, Gabriel C wrote:

> > If you feel that your system has been degraded
> > because it now includes what used to be excluded under
> > CONFIG_ACPI_SLEEP=n, please let me know how.
> 
> Even if I want to SUSPEND* to <something> I can't on my Dell Precision 530 boxes , 
> SCSI is broken with suspend therefore all these boxes have the whole SUSPEND* off, 
> all I need is ACPI.

Linux is already way behind the competition on both STR and STD.
Disabling it because it doesn't work will makes this situation
worse, not better.

> So why you think I want to have this all enabled by default now ? 
> Just to bloat the kernel with something doesn't even work for me ?

Can you be specific about how much additional "bloat" your system
must endure with CONFIG_ACPI_SLEEP=y

> >> config ACPI_SLEEP
> >>          select HOTPLUG_CPU if X86 && SMP
> >>          select SUSPEND_SMP if X86 && SMP
> >>
> >> instead of makeing it dependant on ACPI.
> > 
> > If more config options where better, then this
> > would indeed be an improvement over 2.6.22.
> > But more config options isn't better -- except for "some people":-)
> 
> But in this case some config / new config is better.
> 
> I do not need ACPI to SUSPEND but to make the box work properly.

You also don't need a lot of other code in your kernel.

At some point the complexity of supporting more configuration options
out-weights the benefits of having them.  I have a pretty good idea
of the cost of maintaining the code.  So my question to you is
is what, exactly, is the benefit of having 2.6.22 CONFIG_ACPI_SLEEP=y
that is now lost in 2.6.23-git?

> Ohh and isn't better to make 'ACPI_PROCESSOR  select SUSPEND_SMP and HOTPLUG_CPU if X86 && SMP' ?
>
> ...
> 
> config ACPI_PROCESSOR
>         tristate "Processor"
>         default y
>         help
>           This driver installs ACPI as the idle handler for Linux, and uses
>           ACPI C2 and C3 processor states to save power, on systems that
>           support it.  It is required by several flavors of cpufreq
>           Performance-state drivers.
> 
> ...
> 
> Is more logical for me to do it here but I may be wrong.

ACPI_PROCESSOR supports C-states and P-states and is not directly
related to support for system sleep states.  If your system is recent,
then it is likely that you want to enable this (and cpufreq) to save power --
even if you are not interested in system-wide sleep states.

-Len

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Linus Torvalds]

On Thu, 26 Jul 2007, Len Brown wrote:
> 
> Can you be specific about how much additional "bloat" your system
> must endure with CONFIG_ACPI_SLEEP=y

All of CONFIG_HOTPLUG_CPU. 

Len, this is not about ACPI code. This is about CONFIG_HOTPLUG_CPU. Which 
I don't want. And which you forced on me.

		Linus

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Gabriel C]

Len Brown wrote:
> On Thursday 26 July 2007 06:07, Gabriel C wrote:
> 
>>> If you feel that your system has been degraded
>>> because it now includes what used to be excluded under
>>> CONFIG_ACPI_SLEEP=n, please let me know how.
>> Even if I want to SUSPEND* to <something> I can't on my Dell Precision 530 boxes , 
>> SCSI is broken with suspend therefore all these boxes have the whole SUSPEND* off, 
>> all I need is ACPI.
> 
> Linux is already way behind the competition on both STR and STD.
> Disabling it because it doesn't work will makes this situation
> worse, not better.

Heh what else can I do ? The _bug_(s) are reporter for ages.

See this one as example ( this kills all my Dells ) and there are a lot more reported.

http://bugzilla.kernel.org/show_bug.cgi?id=3062

...

 Description From Nathan Bryant 2004-07-13 18:14

...

Notice '2004' and still no one really cares .. 
So all I can do for now is to disable it.

> 
>> So why you think I want to have this all enabled by default now ? 
>> Just to bloat the kernel with something doesn't even work for me ?
> 
> Can you be specific about how much additional "bloat" your system
> must endure with CONFIG_ACPI_SLEEP=y

At least I was not forced to use HOTPLUG_CPU .. 

Really I just enable what I need / works on my box(es).

> 
>>>> config ACPI_SLEEP
>>>>          select HOTPLUG_CPU if X86 && SMP
>>>>          select SUSPEND_SMP if X86 && SMP
>>>>
>>>> instead of makeing it dependant on ACPI.
>>> If more config options where better, then this
>>> would indeed be an improvement over 2.6.22.
>>> But more config options isn't better -- except for "some people":-)
>> But in this case some config / new config is better.
>>
>> I do not need ACPI to SUSPEND but to make the box work properly.
> 
> You also don't need a lot of other code in your kernel.
> 
> At some point the complexity of supporting more configuration options
> out-weights the benefits of having them.  I have a pretty good idea
> of the cost of maintaining the code.  So my question to you is
> is what, exactly, is the benefit of having 2.6.22 CONFIG_ACPI_SLEEP=y
> that is now lost in 2.6.23-git?
> 
>> Ohh and isn't better to make 'ACPI_PROCESSOR  select SUSPEND_SMP and HOTPLUG_CPU if X86 && SMP' ?
>>
>> ...
>>
>> config ACPI_PROCESSOR
>>         tristate "Processor"
>>         default y
>>         help
>>           This driver installs ACPI as the idle handler for Linux, and uses
>>           ACPI C2 and C3 processor states to save power, on systems that
>>           support it.  It is required by several flavors of cpufreq
>>           Performance-state drivers.
>>
>> ...
>>
>> Is more logical for me to do it here but I may be wrong.
> 
> ACPI_PROCESSOR supports C-states and P-states and is not directly
> related to support for system sleep states.  If your system is recent,
> then it is likely that you want to enable this (and cpufreq) to save power --
> even if you are not interested in system-wide sleep states.

Oh ok.

Well then add a dummy config onpion, ACPI_DESKTOP_SUSPEND or something , move the 2 selects to there ,
make it visible in the menu and make it even default y but that way one can disable it.

You have a config option more even you hate that =) but no #ifdef's in code.

> 
> -Len
> 


Gabriel

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Linus Torvalds]

On Wed, 25 Jul 2007, Len Brown wrote:
> On Wednesday 25 July 2007 14:48, Linus Torvalds wrote:
> 
> > ... ACPI now seems to select CPU hotplug. Why? 
> 
> ACPI=y SMP=y systems require SUSPEND_SMP=y for system sleep support,
> and that requires HOTPLUG_CPU=y.

.. and why do you think I want system sleep support? That's the bug.

> Note that ACPI=y SMP=n systems do not need it,
> and thus will not select HOTPLUG_CPU=y

I want SMP, dammit. This machine has multi-core. And I want ACPI. I just 
don't want the system sleep thing.

I didn't have it before, I don't need it, I don't want it.

> My assumption is that if somebody selects CONFIG_ACPI,
> that 99% of the time, they intend that to include support for
> the ACPI hooks for system sleep states.

That wasn't true before, and it makes no sense what-so-ever as an 
assumption.

The system sleep states are mostly usable on laptops. Not always even 
then. They are seldom used on desktops or servers, but both of those are 
often SMP machines, and certainly want ACPI.

So your "99%" makes no sense.

> So today we have this:
> 
> menuconfig ACPI
> 	...
>         select HOTPLUG_CPU if X86 && SMP
>         select SUSPEND_SMP if X86 && SMP

But why the *hell* is this dependent on ACPI?

Why not just do ACPI_SLEEP, and have *that* do "select 
HOTPLUG_CPU/SUSPEND_CPU".

> Which I think leads to fewer surprises, and less complicated code.

That makes no sense. You're tying together things that have *nothing* to 
do with each other.

As mentioned (and as is *obvious*), pretty much everybody who has a 
multi-core CPU on x86 wants ACPI and SMP. But the set of people who want 
to sw-suspend such a machine is *much* smaller. There is no 99%.

			Linus

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Jan Dittmer]

Len Brown wrote:
> Hi Linus,
> 
> please pull from: 
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release

This seems to break ia64 defconfig:

   Building modules, stage 2.
   MODPOST 157 modules
FATAL: drivers/acpi/button: sizeof(struct acpi_device_id)=20 is not a modulo of the size of section __mod_acpi_device_table=144.
Fix definition of struct acpi_device_id in mod_devicetable.h
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make: *** [_all] Error 2

gcc 3.3.6, binutils 2.15.94

http://l4x.org/k/?d=32569

Jan

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Thomas Renninger]

On Fri, 2007-07-27 at 08:26 +0200, Jan Dittmer wrote:
> Len Brown wrote:
> > Hi Linus,
> > 
> > please pull from: 
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release
> 
> This seems to break ia64 defconfig:
> 
>    Building modules, stage 2.
>    MODPOST 157 modules
> FATAL: drivers/acpi/button: sizeof(struct acpi_device_id)=20 is not a modulo of the size of section __mod_acpi_device_table=144.
> Fix definition of struct acpi_device_id in mod_devicetable.h
> make[2]: *** [__modpost] Error 1
> make[1]: *** [modules] Error 2
> make: *** [_all] Error 2
> 
> gcc 3.3.6, binutils 2.15.94
> 
> http://l4x.org/k/?d=32569

This is strange, I just compiled on a IA64 with button as module
(defconfig), but with gcc version 4.1.2, all is fine.
Anyone an idea how to run into that?

I won't be able to detailed debug this before Monday, but be sure I will
do so then.

Thanks,

    Thomas

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Adrian Bunk]

On Fri, Jul 27, 2007 at 06:25:12PM +0200, Thomas Renninger wrote:
> On Fri, 2007-07-27 at 08:26 +0200, Jan Dittmer wrote:
> > Len Brown wrote:
> > > Hi Linus,
> > > 
> > > please pull from: 
> > > 
> > > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release
> > 
> > This seems to break ia64 defconfig:
> > 
> >    Building modules, stage 2.
> >    MODPOST 157 modules
> > FATAL: drivers/acpi/button: sizeof(struct acpi_device_id)=20 is not a modulo of the size of section __mod_acpi_device_table=144.
> > Fix definition of struct acpi_device_id in mod_devicetable.h
> > make[2]: *** [__modpost] Error 1
> > make[1]: *** [modules] Error 2
> > make: *** [_all] Error 2
> > 
> > gcc 3.3.6, binutils 2.15.94
> > 
> > http://l4x.org/k/?d=32569
> 
> This is strange, I just compiled on a IA64 with button as module
> (defconfig), but with gcc version 4.1.2, all is fine.
> Anyone an idea how to run into that?

I don't have an idea how this happens, but it sounds like an alignment 
issue:

sizeof(struct acpi_device_id)=20
"struct acpi_device_id button_device_ids[]" contains 6 elements
144 = 6 * 24 = 6 * (3 * 8)

So it seems on ia64 with gcc 3.3.6 there's some 8 byte alignment of the 
array members?

Sam and the ia64 maintainers Cc'ed - they might know better what's going 
on here.

> I won't be able to detailed debug this before Monday, but be sure I will
> do so then.
> 
> Thanks,
> 
>     Thomas

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Adrian Bunk]

On Fri, Jul 27, 2007 at 06:25:12PM +0200, Thomas Renninger wrote:
> On Fri, 2007-07-27 at 08:26 +0200, Jan Dittmer wrote:
> > Len Brown wrote:
> > > Hi Linus,
> > > 
> > > please pull from: 
> > > 
> > > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release
> > 
> > This seems to break ia64 defconfig:
> > 
> >    Building modules, stage 2.
> >    MODPOST 157 modules
> > FATAL: drivers/acpi/button: sizeof(struct acpi_device_id)  is not a modulo of the size of section __mod_acpi_device_table\x144.
> > Fix definition of struct acpi_device_id in mod_devicetable.h
> > make[2]: *** [__modpost] Error 1
> > make[1]: *** [modules] Error 2
> > make: *** [_all] Error 2
> > 
> > gcc 3.3.6, binutils 2.15.94
> > 
> > http://l4x.org/k/?d2569
> 
> This is strange, I just compiled on a IA64 with button as module
> (defconfig), but with gcc version 4.1.2, all is fine.
> Anyone an idea how to run into that?

I don't have an idea how this happens, but it sounds like an alignment 
issue:

sizeof(struct acpi_device_id) 
"struct acpi_device_id button_device_ids[]" contains 6 elements
144 = 6 * 24 = 6 * (3 * 8)

So it seems on ia64 with gcc 3.3.6 there's some 8 byte alignment of the 
array members?

Sam and the ia64 maintainers Cc'ed - they might know better what's going 
on here.

> I won't be able to detailed debug this before Monday, but be sure I will
> do so then.
> 
> Thanks,
> 
>     Thomas

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Andreas Schwab]

Adrian Bunk <bunk@stusta.de> writes:

> I don't have an idea how this happens, but it sounds like an alignment 
> issue:
>
> sizeof(struct acpi_device_id)=20

This is wrong.  The structure has 24 bytes (including 7(!) bytes of
padding).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Andreas Schwab]

Adrian Bunk <bunk@stusta.de> writes:

> I don't have an idea how this happens, but it sounds like an alignment 
> issue:
>
> sizeof(struct acpi_device_id) 

This is wrong.  The structure has 24 bytes (including 7(!) bytes of
padding).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Andreas Schwab]

Jan Dittmer <jdi@l4x.org> writes:

> Len Brown wrote:
>> Hi Linus,
>>
>> please pull from: 
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release
>
> This seems to break ia64 defconfig:
>
>   Building modules, stage 2.
>   MODPOST 157 modules
> FATAL: drivers/acpi/button: sizeof(struct acpi_device_id)=20 is not a modulo of the size of section __mod_acpi_device_table=144.

Are you cross-compiling?  The definition of kernel_ulong_t won't work on
x86.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Andreas Schwab]

Jan Dittmer <jdi@l4x.org> writes:

> Len Brown wrote:
>> Hi Linus,
>>
>> please pull from: 
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release
>
> This seems to break ia64 defconfig:
>
>   Building modules, stage 2.
>   MODPOST 157 modules
> FATAL: drivers/acpi/button: sizeof(struct acpi_device_id)=20 is not a modulo of the size of section __mod_acpi_device_table=144.

Are you cross-compiling?  The definition of kernel_ulong_t won't work on
x86.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Jan Dittmer]

Andreas Schwab wrote:
> Jan Dittmer <jdi@l4x.org> writes:
> 
>> Len Brown wrote:
>>> Hi Linus,
>>>
>>> please pull from: 
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release
>> This seems to break ia64 defconfig:
>>
>>   Building modules, stage 2.
>>   MODPOST 157 modules
>> FATAL: drivers/acpi/button: sizeof(struct acpi_device_id)=20 is not a modulo of the size of section __mod_acpi_device_table=144.
> 
> Are you cross-compiling?  The definition of kernel_ulong_t won't work on
> x86.

Yes, sorry, should have mentioned that. Build system is x86. Still,
it didn't happen before the recent acpi merge.

Jan

Re: [GIT PATCH] ACPI patches for 2.6.23-rc1

[Yasha Okshtein]

On 7/28/07, Jan Dittmer <jdi@l4x.org> wrote:
> Andreas Schwab wrote:
> > Jan Dittmer <jdi@l4x.org> writes:
> >> Len Brown wrote:
> >> FATAL: drivers/acpi/button: sizeof(struct acpi_device_id)=20 is not a modulo of the size of section __mod_acpi_device_table=144.
> > Are you cross-compiling?  The definition of kernel_ulong_t won't work on
> > x86.
> Yes, sorry, should have mentioned that. Build system is x86. Still,
> it didn't happen before the recent acpi merge.

I also have the same error, which I didn't have in 2.6.22:

FATAL: drivers/acpi/ac: sizeof(struct acpi_device_id)=20 is not a
modulo of the size of section __mod_acpi_device_table=48.
Fix definition of struct acpi_device_id in mod_devicetable.h
make[1]: *** [__modpost] Error 1

Build system is x86_64. I'm not cross-compiling, as the target machine
(not the build machine) is also x86_64.

 - Yasha