Please pull ACPI updates

Please pull ACPI updates

[Andi Kleen]

Linus,

Please pull from

  git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-acpi-merge-2.6 release-2.6.27

to get the initial ACPI updates for 2.6.27. We got a few more changes
dependent on yet unpulled trees and some other candidate patches,
but that's the bulk for the changes intended for 2.6.27. Most of that
has been collected by Len Brown before he went on sabbatical. I was
relatively conservative with additional changes so far.

-Andi

Aaron Durbin (1):
      Add the ability to reset the machine using the RESET_REG in ACPI's FADT table.

Adrian Bunk (1):
      eeepc-laptop: static

Alan Cox (1):
      snapshot: Push BKL down into ioctl handlers

Alok N Kataria (1):
      ACPI: fix checkpatch.pl complaints in scan.c

Bjorn Helgaas (29):
      PNP: add detail to debug resource dump
      PNP: remove pnp_resource.index
      PNP: add pnp_resource_type() internal interface
      PNP: add pnp_resource_type_name() helper function
      PNP: make pnp_{port,mem,etc}_start(), et al work for invalid resources
      PNP: replace pnp_resource_table with dynamically allocated resources
      PNPACPI: keep disabled resources when parsing current config
      PNP: remove ratelimit on add resource failures
      PNP: dont sort by type in /sys/.../resources
      PNP: add pnp_possible_config() -- can a device could be configured this way?
      PNP: whitespace/coding style fixes
      PNP: define PNP-specific IORESOURCE_IO_* flags alongside IRQ, DMA, MEM
      PNP: make resource option structures private to PNP subsystem
      PNP: introduce pnp_irq_mask_t typedef
      PNP: increase I/O port & memory option address sizes
      PNP: improve resource assignment debug
      PNP: in debug resource dump, make empty list obvious
      PNP: make resource assignment functions return 0 (success) or -EBUSY (failure)
      PNP: remove redundant pnp_can_configure() check
      PNP: centralize resource option allocations
      PNPACPI: ignore _PRS interrupt numbers larger than PNP_IRQ_NR
      PNP: rename pnp_register_*_resource() local variables
      PNP: support optional IRQ resources
      PNP: remove extra 0x100 bit from option priority
      ISAPNP: handle independent options following dependent ones
      PNP: convert resource options to single linked list
      PNP: avoid legacy IDE IRQs
      PNPACPI: add support for HP vendor-specific CCSR descriptors
      ACPI: use dev_printk when possible

Bob Moore (17):
      Make GPE disable more robust
      ACPICA: Add argument count checking to control method invocation via acpi_evaluate_object
      ACPICA: Fix for hang on GPE method invocation
      ACPICA: Fix possible negative array index in acpi_ut_validate_exception
      ACPICA: Eliminate acpi_native_uint type v2
      ACPICA: Removed unused include files from source files
      ACPICA: Several lint changes, no functional changes
      ACPICA: Add const qualifier for appropriate string constants
      ACPICA: Update version to 20080514
      ACPICA: Workaround for reversed _PRT entries from BIOS
      ACPICA: Update DMAR and SRAT table definitions
      ACPICA: Update disassembler for DMAR table changes
      ACPICA: Fix for invalid large array index on 64-bit systems
      ACPICA: Cleanup debug operand dump mechanism
      ACPICA: Cleanup of _PRT parsing code
      ACPICA: Fix mutex debug code for wrong loop termination value
      ACPICA: Update version to 20080609

Carlos Corbacho (7):
      acer-wmi: Remove LED colour comment from documentation
      acer-wmi: Blacklist backlight on Acer Aspire 1520 & 1360 series
      acer-wmi: Respect framebuffer blanking in backlight
      acer-wmi: Add EC quirk for Fujitsu Siemens Amilo Li 1718
      acer-wmi: Disable device autodetection on Fujitsu Siemens Amilo Li2732
      acer-wmi: Add debugfs file for device detection
      acer-wmi: Remove version number

Cezary Jackiewicz (2):
      misc,acpi,backlight: compal Laptop Extras
      compal-laptop: remove unnecessary lcd_level attribute

David Brownell (1):
      ACPI PM: acpi_pm_device_sleep_state() cleanup

Jan Beulich (2):
      ACPICA: Update tracking macros to reduce code/data size
      Fix FADT parsing

Johannes Berg (1):
      APM emulation: Notify about all suspend events, not just APM invoked ones (v2)

Jonathan Woithe (1):
      Fujitsu-laptop update

Julia Jomantaite (1):
      ACPI: video: fix brightness allocation

Len Brown (3):
      dock: bay: Don't call acpi_walk_namespace() when ACPI is disabled.
      ACPI: Zhang Rui maintains ACPI THERMAL and FAN
      ACPI: Andi Kleen maintains the ACPI sub-system

Mike Travis (1):
      ACPI: change processors from array to per_cpu variable

Rafael J. Wysocki (4):
      PCI ACPI: Drop the second argument of platform_pci_choose_state
      ACPI PM: Remove obsolete Toshiba workaround
      Freezer: Introduce PF_FREEZER_NOSIG
      snapshot: Use pm_mutex for mutual exclusion

Randy Dunlap (2):
      acpi: fix printk format warning
      fujitsu-laptop: depends on INPUT

Vegard Nossum (2):
      ACPICA: fix mutex names in debug code.
      ACPI: don't walk tables if ACPI was disabled

Yi Yang (2):
      ACPI: fix acpi fan state set error
      ACPI: fix processor throttling set error

Zhang Rui (4):
      fix a deadlock issue when poking "eject" file
      force offline the processor during hot-removal
      create sysfs link from acpi device to sysdev for cpu
      ACPI: Enhance /sys/firmware/interrupts to allow enable/disable/clear from user-space

Zhao Yakui (4):
      ACPI: Disable the C2C3_FFH access mode HW has no MWAIT support
      ACPI: Create "idle=halt" bootparam
      ACPI : Create "idle=nomwait" bootparam
      ACPI: Disable MWAIT via DMI on broken Compal board

 Documentation/ABI/testing/sysfs-firmware-acpi |  127 +++--
 Documentation/kernel-parameters.txt           |    5 +-
 Documentation/laptops/acer-wmi.txt            |    2 -
 MAINTAINERS                                   |   25 +-
 arch/ia64/kernel/process.c                    |    4 +
 arch/x86/kernel/acpi/processor.c              |    6 +
 arch/x86/kernel/process.c                     |   28 +-
 arch/x86/mm/srat_32.c                         |    3 +-
 drivers/acpi/Makefile                         |    2 +-
 drivers/acpi/bay.c                            |    3 +
 drivers/acpi/bus.c                            |    2 +-
 drivers/acpi/dispatcher/dsinit.c              |    2 +-
 drivers/acpi/dispatcher/dsmethod.c            |    1 -
 drivers/acpi/dispatcher/dsopcode.c            |   22 +-
 drivers/acpi/dispatcher/dswexec.c             |    8 -
 drivers/acpi/dispatcher/dswstate.c            |   20 +-
 drivers/acpi/dock.c                           |    3 +
 drivers/acpi/events/evevent.c                 |    6 +-
 drivers/acpi/events/evgpe.c                   |   36 +-
 drivers/acpi/events/evgpeblk.c                |   18 +-
 drivers/acpi/events/evmisc.c                  |    4 +-
 drivers/acpi/events/evregion.c                |    5 +-
 drivers/acpi/events/evrgnini.c                |    2 +-
 drivers/acpi/events/evxfevnt.c                |   18 +-
 drivers/acpi/executer/exconfig.c              |   17 +-
 drivers/acpi/executer/exconvrt.c              |   12 +-
 drivers/acpi/executer/excreate.c              |    2 -
 drivers/acpi/executer/exdump.c                |   67 +--
 drivers/acpi/executer/exfldio.c               |    9 +-
 drivers/acpi/executer/exmisc.c                |    8 +-
 drivers/acpi/executer/exprep.c                |    8 +-
 drivers/acpi/executer/exregion.c              |    2 +-
 drivers/acpi/executer/exresop.c               |    4 +
 drivers/acpi/executer/exstore.c               |    6 -
 drivers/acpi/fan.c                            |    8 +-
 drivers/acpi/glue.c                           |    3 +
 drivers/acpi/hardware/hwgpe.c                 |   52 ++-
 drivers/acpi/namespace/nsdump.c               |    6 +-
 drivers/acpi/namespace/nseval.c               |   35 +
 drivers/acpi/namespace/nsinit.c               |    1 -
 drivers/acpi/namespace/nsload.c               |    3 +-
 drivers/acpi/namespace/nsparse.c              |   15 +-
 drivers/acpi/namespace/nsutils.c              |   50 +-
 drivers/acpi/namespace/nsxfeval.c             |    3 +-
 drivers/acpi/numa.c                           |    4 +-
 drivers/acpi/parser/psargs.c                  |    4 +-
 drivers/acpi/parser/psxface.c                 |    4 +-
 drivers/acpi/pci_irq.c                        |   38 +-
 drivers/acpi/processor_core.c                 |   75 ++-
 drivers/acpi/processor_idle.c                 |   34 +-
 drivers/acpi/processor_perflib.c              |   18 +-
 drivers/acpi/processor_throttling.c           |   38 +-
 drivers/acpi/reboot.c                         |   50 ++
 drivers/acpi/resources/rscalc.c               |    4 +-
 drivers/acpi/resources/rscreate.c             |   41 +-
 drivers/acpi/resources/rsmisc.c               |    2 +-
 drivers/acpi/resources/rsutils.c              |   13 +-
 drivers/acpi/scan.c                           |   62 ++-
 drivers/acpi/sleep/main.c                     |   39 +-
 drivers/acpi/system.c                         |  169 +++++-
 drivers/acpi/tables/tbfadt.c                  |   23 +-
 drivers/acpi/tables/tbfind.c                  |    5 +-
 drivers/acpi/tables/tbinstal.c                |   30 +-
 drivers/acpi/tables/tbutils.c                 |   15 +-
 drivers/acpi/tables/tbxface.c                 |   28 +-
 drivers/acpi/tables/tbxfroot.c                |    4 +-
 drivers/acpi/utilities/utalloc.c              |    5 +-
 drivers/acpi/utilities/utcopy.c               |    4 +-
 drivers/acpi/utilities/utdebug.c              |   54 +-
 drivers/acpi/utilities/utdelete.c             |    2 +-
 drivers/acpi/utilities/uteval.c               |    5 +-
 drivers/acpi/utilities/utmisc.c               |   39 +-
 drivers/acpi/utilities/utmutex.c              |    4 +-
 drivers/acpi/utilities/utobject.c             |    9 +-
 drivers/acpi/video.c                          |  123 +++--
 drivers/char/apm-emulation.c                  |  346 +++++++-----
 drivers/misc/Kconfig                          |   31 +-
 drivers/misc/Makefile                         |    5 +-
 drivers/misc/acer-wmi.c                       |  145 ++++-
 drivers/misc/compal-laptop.c                  |  404 ++++++++++++
 drivers/misc/eeepc-laptop.c                   |    4 +-
 drivers/misc/fujitsu-laptop.c                 |  825 +++++++++++++++++++++++--
 drivers/pci/pci-acpi.c                        |    6 +-
 drivers/pci/pci.c                             |    4 +-
 drivers/pci/pci.h                             |    3 +-
 drivers/pnp/base.h                            |  148 ++++-
 drivers/pnp/core.c                            |   29 +-
 drivers/pnp/interface.c                       |  207 +++----
 drivers/pnp/isapnp/core.c                     |  253 +++-----
 drivers/pnp/manager.c                         |  414 ++++---------
 drivers/pnp/pnpacpi/core.c                    |    4 +-
 drivers/pnp/pnpacpi/rsparser.c                |  492 +++++++++------
 drivers/pnp/pnpbios/rsparser.c                |  274 +++++----
 drivers/pnp/quirks.c                          |  307 +++++-----
 drivers/pnp/resource.c                        |  454 ++++++--------
 drivers/pnp/support.c                         |  171 +++++-
 drivers/pnp/system.c                          |    4 +-
 drivers/serial/8250_pnp.c                     |   24 +-
 include/acpi/acconfig.h                       |    2 +-
 include/acpi/acdisasm.h                       |    1 +
 include/acpi/acdispat.h                       |    2 +-
 include/acpi/acexcep.h                        |   10 +-
 include/acpi/acglobal.h                       |    2 +-
 include/acpi/achware.h                        |    4 +-
 include/acpi/acinterp.h                       |    5 +-
 include/acpi/aclocal.h                        |    6 +-
 include/acpi/acmacros.h                       |   38 +-
 include/acpi/acnamesp.h                       |   30 +-
 include/acpi/acpi_bus.h                       |    4 +-
 include/acpi/acpiosxf.h                       |    2 +-
 include/acpi/acpixf.h                         |   12 +-
 include/acpi/acstruct.h                       |   10 +-
 include/acpi/actables.h                       |   27 +-
 include/acpi/actbl1.h                         |   23 +-
 include/acpi/actypes.h                        |   16 +-
 include/acpi/acutils.h                        |   70 ++-
 include/acpi/processor.h                      |    2 +-
 include/acpi/reboot.h                         |   14 +-
 include/asm-ia64/processor.h                  |    2 +
 include/asm-x86/processor.h                   |    2 +
 include/linux/freezer.h                       |   10 +
 include/linux/ioport.h                        |    5 +
 include/linux/pnp.h                           |  146 +++--
 include/linux/sched.h                         |    1 +
 kernel/cpu.c                                  |    1 +
 kernel/kthread.c                              |    2 +-
 kernel/power/process.c                        |   97 ++--
 kernel/power/user.c                           |   71 ++-
 128 files changed, 4330 insertions(+), 2449 deletions(-)
 create mode 100644 drivers/acpi/reboot.c
 create mode 100644 drivers/misc/compal-laptop.c

Re: Please pull ACPI updates

[Rafael J. Wysocki]

On Wednesday, 16 of July 2008, Andi Kleen wrote:
> 
> Linus,
> 
> Please pull from
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-acpi-merge-2.6 release-2.6.27
> 
> to get the initial ACPI updates for 2.6.27. We got a few more changes
> dependent on yet unpulled trees and some other candidate patches,
> but that's the bulk for the changes intended for 2.6.27. Most of that
> has been collected by Len Brown before he went on sabbatical. I was
> relatively conservative with additional changes so far.

Well, IMO it would be better to merge PCI first.

Thanks,
Rafael

Re: Please pull ACPI updates

[Jesse Barnes]

On Wednesday, July 16, 2008 3:11 pm Rafael J. Wysocki wrote:
> On Wednesday, 16 of July 2008, Andi Kleen wrote:
> > Linus,
> >
> > Please pull from
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-acpi-merge-2.6
> > release-2.6.27
> >
> > to get the initial ACPI updates for 2.6.27. We got a few more changes
> > dependent on yet unpulled trees and some other candidate patches,
> > but that's the bulk for the changes intended for 2.6.27. Most of that
> > has been collected by Len Brown before he went on sabbatical. I was
> > relatively conservative with additional changes so far.
>
> Well, IMO it would be better to merge PCI first.

Yeah, they're interdependent (I pulled from Len's tree, hopefully Andi 
preserved the changesets).  I had wanted to do a little more testing of what 
I've got, but I haven't heard any huge complaints so far so maybe things are 
ok.  I'll generate a pull request now.

Jesse

Re: Please pull ACPI updates

[Linus Torvalds]

On Wed, 16 Jul 2008, Jesse Barnes wrote:
> 
> Yeah, they're interdependent (I pulled from Len's tree, hopefully Andi 
> preserved the changesets).

Andi did not. The whole series I pulled was rebased today at 2PM.

I was going to complain about it, because Len's trees were always a 
pleasure to pull with clearly delineated topic branches etc, and pulling 
from Andi was such a let-down in comparison.

But I decided to let it slide, because quite frankly, Len had done better 
than the average bear, and I didn't realize that the commits Andi had 
rebased had actually been in Len's tree in the _good_ format.

It seems I was wrong - I should _not_ have let it slide, and it appears 
that Andi had actually destroyed Len's pretty tree.

Andi. This can _not_ continue. You need to learn how to use topic 
branches, and how to not screw up other peoples trees. Otherwise I'll just 
have to stop pulling from you. AGAIN.

			Linus

Re: Please pull ACPI updates

[Jesse Barnes]

On Wednesday, July 16, 2008 4:45 pm Linus Torvalds wrote:
> On Wed, 16 Jul 2008, Jesse Barnes wrote:
> > Yeah, they're interdependent (I pulled from Len's tree, hopefully Andi
> > preserved the changesets).
>
> Andi did not. The whole series I pulled was rebased today at 2PM.

Ugg, when Andi took over we talked about it; I thought we had agreed that he 
would stick with Len's tree.  I guess I was wrong.

> I was going to complain about it, because Len's trees were always a
> pleasure to pull with clearly delineated topic branches etc, and pulling
> from Andi was such a let-down in comparison.

Is a topic branch flow like what Len uses documented somewhere that you know 
of?  I know my process could use some improvement; I'd rather not have to 
wait for Len to come back to ask him. :)

Thanks,
Jesse

Re: Please pull ACPI updates

[Linus Torvalds]

On Wed, 16 Jul 2008, Jesse Barnes wrote:
> >
> > Andi did not. The whole series I pulled was rebased today at 2PM.
> 
> Ugg, when Andi took over we talked about it; I thought we had agreed that he 
> would stick with Len's tree.  I guess I was wrong.

Well, I haven't actually seen Len's original tree, so maybe the stuff Andi 
pushed was just the stuff he had queued up independently. I guess I 
shouldn't judge before I'm sure.

> Is a topic branch flow like what Len uses documented somewhere that you know 
> of?  I know my process could use some improvement; I'd rather not have to 
> wait for Len to come back to ask him. :)

Len wrote it up at one point, but I can't for the life of me remember 
where. 

He's not the onyl one to ask, though - Ingo and Thomas seem to have picked 
up topic branches pretty well (I had some issues with a couple of the 
topics, but they weren't fundamental and the major one was probably 
because Ingo tried a bit too hard to make sure that I never saw any 
conflicts at all).

Other topic branch users include Jeff Garzik and rmk. There's definitely 
people around who should be able to talk about what they are doing.

		Linus

Re: Please pull ACPI updates

[Linus Torvalds]

On Wed, 16 Jul 2008, Linus Torvalds wrote:
>
> Well, I haven't actually seen Len's original tree, so maybe the stuff Andi 
> pushed was just the stuff he had queued up independently. I guess I 
> shouldn't judge before I'm sure.

No, he rebased it - the three commits you shared are now separate ones. 

Most of the conflicts seem to have been due tot he x86 tree changes 
though. But it seems I didn't mess up too much: at least the result booted 
for me without complaints. So I pushed out my resolution.

Jesse, can you please double-check it?

			Linus

Re: Please pull ACPI updates

[Jesse Barnes]

On Wednesday, July 16, 2008 5:53:55 pm Linus Torvalds wrote:
> On Wed, 16 Jul 2008, Linus Torvalds wrote:
> > Well, I haven't actually seen Len's original tree, so maybe the stuff
> > Andi pushed was just the stuff he had queued up independently. I guess I
> > shouldn't judge before I'm sure.
>
> No, he rebased it - the three commits you shared are now separate ones.

Well, I could have misunderstood what we talked about; I guess I just assumed 
Andi & I would chat before sending out our pull requests.  I'll be sure to 
coordinate better next time.

> Most of the conflicts seem to have been due tot he x86 tree changes
> though. But it seems I didn't mess up too much: at least the result booted
> for me without complaints. So I pushed out my resolution.
>
> Jesse, can you please double-check it?

Just looked, seems fine.  I'd pat you on the head to reassure you about it, 
but my arms aren't quite long enough...

I'll dig around some more for git best practices too.  Based on what I've seen 
of the x86 tree I don't have nearly enough branches (though on the plus side, 
I almost never rebase since I don't want to hose any downstream users, and I 
don't merge from your tree until after you've pulled to avoid cluttering up 
the log).

Thanks,
Jesse

Re: Please pull ACPI updates

[Linus Torvalds]

On Wed, 16 Jul 2008, Jesse Barnes wrote:
> 
> I'll dig around some more for git best practices too.  Based on what I've seen 
> of the x86 tree I don't have nearly enough branches

Don't worry about it. Start small. I think the x86 tree took up some 
pretty extreme limits, as can be seen by their 29-way merge or whatever it 
was. They also obviously have a lot more stuff going on than the PCI tree 
would be expected to have.

For most people, I'd expect that a small handful of branches is good. It 
might be just one, but it might be a couple of independent issues.

The point where a topic branch is _really_ useful is when you ask yourself 
whether that particular change is something that you (or somebody else!) 
might want to delay or test separately from some other change - that's 
when "oh, let's just use a separate branch for it" is really appropriate.

Len, for example, often did topic branches for individual bugzilla 
entries, and obviously for big conceptually separate things like ACPICA, 
which really _is_ a totally disjoint development track.

Other people, like rmk, use topic branches for particular hardware 
platforms.

On the other hand, if it's a trivial and obvious thing, there's no point 
in putting it into a separate branch. A number people who keep topic 
branches for all their major development then end up having a "misc" 
branch for just random things.

And remember: in git, topic branches are temporary things. You can rename 
them, you can delete them, you can ignore them. And before you've pushed 
things out, you can even decide to create a topic branch of a set of 
commits _after_ the fact. So you can commit _first_, and then decide that 
that commit was probably best to keep separate, so you create a topic 
branch with that commit on it, an go back to the pre-commit state on your 
regular branch.

BUT!

 - Not everybody _has_ to use topic branches. If you are maintaining 
   something that is very specific to begin with, _all_ your maintenance 
   is basically one topic to start with, so you'd never have separate 
   topic branches.

   The filesystem people, for example, do not tend to use topic branches 
   for this reason. They do their filesystem. They seldom have issues that 
   crop up on just certain platforms etc.

 - And more importantly - play around with it. Get used to it first. Look 
   at what other people do. Start small, with perhaps just one special 
   topic branch to test the waters with.

So don't worry _too_ much.

			Linus

Re: Please pull ACPI updates

[Andi Kleen]

Linus Torvalds wrote:
> 
> On Wed, 16 Jul 2008, Jesse Barnes wrote:
>>> Andi did not. The whole series I pulled was rebased today at 2PM.
>> Ugg, when Andi took over we talked about it; I thought we had agreed that he 
>> would stick with Len's tree.  I guess I was wrong.
> 
> Well, I haven't actually seen Len's original tree, so maybe the stuff Andi 
> pushed was just the stuff he had queued up independently. I guess I 
> shouldn't judge before I'm sure.

I originally started with topic branches and imported a few patches
this way, but then eventually realized they don't really match my
working style. In particular I tend to edit and sometimes
delete old patches and that seems to be quite painful with
the topic branch setup (or perhaps I just haven't figured out
how to do it nicely). Also tried it with guilt, but that
also ran into some issues (in particular after merges one
cannot manage the patches as a guilt stack anymore)

What I did then was to export Len's tree to quilt, do all the touchups
etc, merged some more patches and then regenerated a quilt tree for
the merge request. That is how the old x86-64 tree used to work.

-Andi

Re: Please pull ACPI updates

[Linus Torvalds]

On Thu, 17 Jul 2008, Andi Kleen wrote:
> 
> I originally started with topic branches and imported a few patches
> this way, but then eventually realized they don't really match my
> working style.

That still doesn't excuse then breaking _other_ peoples work.

> What I did then was to export Len's tree to quilt, do all the touchups
> etc, merged some more patches and then regenerated a quilt tree for
> the merge request. That is how the old x86-64 tree used to work.

Right. 

And Andi, remember the problems with that one? Remember how I ended up 
refusing to 'git pull' from you? (Also look at how it failed to work well 
for Ingo and Thomas as well, and how people complained about that? It's 
not just you.)

In other words, "That is how the old x86-64 tree used to NOT work".

			Linus

Re: Please pull ACPI updates

[Andi Kleen]

Linus Torvalds wrote:
> 
> On Wed, 16 Jul 2008, Jesse Barnes wrote:
>> Yeah, they're interdependent (I pulled from Len's tree, hopefully Andi 
>> preserved the changesets).
> 
> Andi did not. The whole series I pulled was rebased today at 2PM.
> 
> I was going to complain about it, because Len's trees were always a 
> pleasure to pull with clearly delineated topic branches etc, and pulling 
> from Andi was such a let-down in comparison.

I went back to quilt because the topic branches didn't really
work out for me.

> But I decided to let it slide, because quite frankly, Len had done better 
> than the average bear, and I didn't realize that the commits Andi had 
> rebased had actually been in Len's tree in the _good_ format.
> 
> It seems I was wrong - I should _not_ have let it slide, and it appears 
> that Andi had actually destroyed Len's pretty tree.

My plan was to keep everything in quilt and just regenerate for the pull.
Please let me know if it's now not allowed anymore to use quilt.

-Andi

Re: Please pull ACPI updates

[Linus Torvalds]

On Thu, 17 Jul 2008, Andi Kleen wrote:
> 
> My plan was to keep everything in quilt and just regenerate for the pull.
> Please let me know if it's now not allowed anymore to use quilt.

End-point developers can use quilt all thei like.

But people cannot and *MUST NOT* destroy other peoples work with quilt, 
nor make it harder for people to share commits.

Len had apparently left a nice topic tree for you. You took that work, and 
then destroyed it. And yes, it is noticeable: Jesse had shared some of the 
work from Len by pulling one of the branches (the 'suspend' branch), and 
then you literally re-wrote _public_ history, so now tohose patches are 
duplicated.

Now, duplicate patches happen, and that's not a huge technical issue (most 
of the time it all merges cleanly, and it was just three patches this 
time), but if you're going to rebase stuff, you're basically making it 
impossible for people to share work with you. They can never rely on your 
git trees, because your git threes are all throw-away.

Btw, being throw-away also means that they get essentially no testing. 
They get rewritten each time, so even if you expose them to something like 
linux-next and they get testing there, when you rebase them, the end 
result is something *different*, and a lot of the test coverage goes away.

See the discussion from May about the x86 tree. I don't have it online in 
my archives any more, but google finds

	http://kerneltrap.org/Linux/Git_Management

which has at least a big part of the discussion in one readable page.

So no, there's nothing wrong with a quilt interface. But there _is_ 
something wrong with a maintainer that makes it harder for other people 
(in this case Jesse) to work with him, because he destroys history.

		Linus

Re: Please pull ACPI updates

[Len Brown]

Andi, Jesse, Linus,

Thanks for working through this while I'm away.

Patches with cross-tree dependencies happen,
and they continue to be a challenge to our process.
We don't really have an organized way to handle them.
It seems that every time they are a communication challenge
and I'm sorry I wasn't there to hold up my
end of the communication on this merge.

Jesse,

I use Tony Luck's topic-branch scheme, now part of the git manual:

http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#maintaining-topic-branches

Re: updating history in git
yes, this is an sort of an oxymoron, but it is necessary
for a "middle-man" maintainer.
On one hand, we need to test exactly what is checked in,
and on the other hand, not every test passes...
So we need to revise what we checked in before it goes upstream
and becomes permanent history.

The alternative would be to check in a lot of reverts
and incremental patches that make the final history
sent to linus really confusing.

I find that the topic branches help a lot with this.
My "test" branch is the merge of a bunch of topic branches.
If a topic branch turns out to be bad, I can re-merge my test
branch from those topics, excluding the bad one.
(or including a revised replacement).

All the branches besides the revised one maintain
their place in history.  So if they used to work,
they shoulds still work.  Of course the merge itself
can go bad...  But my topic branches are as independent
as possible, so this is rare.

Customers of my test branch know that it can be re-based.
mm and linux-next are the main customers, and since
they re-merge from scratch each time, they're immune.
Individual developers simply deal with it as a diff,
say by using the plain-patch I export, or I do something special for them.

Sometimes I re-base topic branches to make
creating a diff of them versus a well known snapshot
(eg an -rc) easy.  This is particularly useful for
topic branches that take a long time to go upstream
b/c sometimes people want to test them, but only
against a recent baseline.

Branches pulled into "release" for linus are frozen,
or course, since Linus' tree is permanent history.
So any reverts/updates after that point have to
be real revert commits and incremental patches.

cheers,
-Len

ps.

One thing I wish I had in git is a way to make this sequence easier...

Say I have a big topic branch with 30 patches in it.
The 3rd patch turns out to have a bug in it, but the
rest of the series is okay.  Today I invoke gitk on
the branch and keep that open.
Then I create a new topic branch at the broken patch.

I always consult ~/src/git/Documentation/git-reset.txt
so I can remember the following sequence...

$ git reset --soft HEAD^
$ edit
$ git commit -a -c ORIG_HEAD

Now I've got the fixed 3rd patch checked in,
but 27 patches in the original branch are hanging
off the original broken 3rd patch.
So I git-cherry-pick 27 patches
I hope I get them in the right order and don't miss any...

It would be nice if we could somehow git rebase those
27 patches in a single command, but if we do,
that pulls with it the broken 3rd patch.

come to think of it, I can probably export 4..27 as
an mbox and then import it on top of the new 3,
maybe that is what others do.

Re: Please pull ACPI updates

[Harvey Harrison]

On Thu, 2008-07-17 at 14:49 -0400, Len Brown wrote:
> Andi, Jesse, Linus,
> 
> One thing I wish I had in git is a way to make this sequence easier...
> 
> Say I have a big topic branch with 30 patches in it.
> The 3rd patch turns out to have a bug in it, but the
> rest of the series is okay.  Today I invoke gitk on
> the branch and keep that open.
> Then I create a new topic branch at the broken patch.
> 
> I always consult ~/src/git/Documentation/git-reset.txt
> so I can remember the following sequence...
> 
> $ git reset --soft HEAD^
> $ edit
> $ git commit -a -c ORIG_HEAD
> 
> Now I've got the fixed 3rd patch checked in,
> but 27 patches in the original branch are hanging
> off the original broken 3rd patch.
> So I git-cherry-pick 27 patches
> I hope I get them in the right order and don't miss any...
> 
> It would be nice if we could somehow git rebase those
> 27 patches in a single command, but if we do,
> that pulls with it the broken 3rd patch.

git rebase --interactive

sounds like exactly what you are asking for.

Harvey

Re: Please pull ACPI updates

[Andi Kleen]

Harvey Harrison wrote:

> git rebase --interactive
> 
> sounds like exactly what you are asking for.

Sounds like a nice feature. Thanks for the pointer.

-Andi

Re: Please pull ACPI updates

[Linus Torvalds]

On Thu, 17 Jul 2008, Len Brown wrote:
> 
> ps.
> 
> One thing I wish I had in git is a way to make this sequence easier...

Actually, it _is_ easier, although apparently the thing that made it 
easier isn't necessarily widely known or documented.

I'm going to quote your whole sequence, because it's not a really odd 
thing do want to do, and quoting how you do it now also makes the "proper 
git way" actually much more understandable:

> Say I have a big topic branch with 30 patches in it.
> The 3rd patch turns out to have a bug in it, but the
> rest of the series is okay.  Today I invoke gitk on
> the branch and keep that open.
>
> Then I create a new topic branch at the broken patch.
> 
> I always consult ~/src/git/Documentation/git-reset.txt
> so I can remember the following sequence...
> 
> $ git reset --soft HEAD^
> $ edit
> $ git commit -a -c ORIG_HEAD
> 
> Now I've got the fixed 3rd patch checked in,
> but 27 patches in the original branch are hanging
> off the original broken 3rd patch.
> So I git-cherry-pick 27 patches
> I hope I get them in the right order and don't miss any...
> 
> It would be nice if we could somehow git rebase those
> 27 patches in a single command, but if we do,
> that pulls with it the broken 3rd patch.
> 
> come to think of it, I can probably export 4..27 as
> an mbox and then import it on top of the new 3,
> maybe that is what others do.

No, what others do (if they know the tricks) is to say something like:

	git rebase -i <starting-point>

("-i" is short for "--interactive") where the starting point is just where 
you want to start your work. It might be "origin", or it might be 
"HEAD~30" to say "30 commits ago" or whatever. Anyway, it's basically the 
stable point before the place you want to fix up.

That thing will literally show you the list of commits in an editor, and 
then you can re-order them or mark them for special actions.

The normal action is to "pick" the commit (ie you just cherry-pick it). 
But rather than just picking a commit (remember - you can change the order 
by just editing the list), you can also do

 - "edit": this just basically pauses the rebase after committing the 
    cherry-pick, so that you can then edit things and fix them with "git 
    commit --amend", and when you're happy, you do "git rebase --continue"
    to continue your series.

 - "squash": this squashes the commit in togethr with the previous one, 
   and is very useful together with moving commits around. IOW, maybe you 
   committed a fix to a previous commit, and want to integrate the fix 
   into the original commit - in that case you'd move the commit in the 
   list up to just after the commit you want to fix, and change the "pick" 
   into a "squash"

so it actually makes doing what you do above by hand much easier.

[ Honesty in advertising: I actually don't use this at all. I've tested 
  it, and I think it's very useful, but I have so far mostly ended up 
  doing this by hand in the very few cases I do it at all. Part of the 
  reason is that "git rebase -i" is fairly recent, so it's not part of my 
  normal tool set.

  But the bigger reason is that obviously all the commits I tend to do are 
  just merges, and I don't maintain "patch series" in my trees except 
  sometimes for git itself ]

Git rebase can also try to rebase merges (the "-p" flag - short form of 
"--preserve-merges"), so this _does_ work with a non-linear history too to 
some degree, but quite frankly, I would seriously suggest people try to 
avoid getting quite that funky with it. It's useful for emergencies, but 
you'd better know what you are doing, and you should look at the 
before-and-after state very carefully.

			Linus

Re: Please pull ACPI updates

[Linus Torvalds]

On Thu, 17 Jul 2008, Linus Torvalds wrote:
> 
> No, what others do (if they know the tricks) is to say something like:
> 
> 	git rebase -i <starting-point>

Oh, and before anybody goes any further with this: it's a very convenient 
feature, but it _is_ still technically nothing but a very nice interface 
to cherry-picking and rebasing history. 

So all the caveats about _not_ doing this with public history that others 
have already seen and possibly merged are still in place. That part 
doesn't change at all.

So it's great to do with private changes to clean them up before 
publicizing them, or possibly with branches that you have explicitly told 
people are _not_ stable, but it is still very much about creating a 
totally new history.

			Linus

Re: Please pull ACPI updates

[J. Bruce Fields]

On Thu, Jul 17, 2008 at 02:49:04PM -0400, Len Brown wrote:
> One thing I wish I had in git is a way to make this sequence easier...

Linus's answer (with rebase -i) is probably better, but my habit is to
do what you describe, with some minor shortcuts:

> Say I have a big topic branch with 30 patches in it.
> The 3rd patch turns out to have a bug in it, but the
> rest of the series is okay.  Today I invoke gitk on
> the branch and keep that open.
> Then I create a new topic branch at the broken patch.
> 
> I always consult ~/src/git/Documentation/git-reset.txt
> so I can remember the following sequence...
> 
> $ git reset --soft HEAD^
> $ edit
> $ git commit -a -c ORIG_HEAD

Instead of the above three steps, you can do just:

  $ edit
  $ git commit -a --amend

> Now I've got the fixed 3rd patch checked in,
> but 27 patches in the original branch are hanging
> off the original broken 3rd patch.
> So I git-cherry-pick 27 patches
> I hope I get them in the right order and don't miss any...
> 
> It would be nice if we could somehow git rebase those
> 27 patches in a single command, but if we do,
> that pulls with it the broken 3rd patch.

At this point I do

	git rebase --onto HEAD old-sha1 name-of-branch-to-rebase

(where old-sha1 is the name of the commit we just replaced, which I
usually cut-n-paste out of gitk).  That rebases the commits in the range
old-sha1...name-of-branch-to-rebase onto the new HEAD commit that you
just created, and replaces the named branch with the result.

> come to think of it, I can probably export 4..27 as
> an mbox and then import it on top of the new 3,
> maybe that is what others do.

That works too.

--b.

[PATCH] Revert duplicate "dock: bay: Don't call acpi_walk_namespace() when ACPI is disabled" commit (was: Please pull ACPI updates)

[Thomas Gleixner]

On Thu, 17 Jul 2008, Linus Torvalds wrote:
> On Thu, 17 Jul 2008, Andi Kleen wrote:
> > 
> > My plan was to keep everything in quilt and just regenerate for the pull.
> > Please let me know if it's now not allowed anymore to use quilt.
> 
> End-point developers can use quilt all thei like.
> 
> But people cannot and *MUST NOT* destroy other peoples work with quilt, 
> nor make it harder for people to share commits.
> 
> Len had apparently left a nice topic tree for you. You took that work, and 
> then destroyed it. And yes, it is noticeable: Jesse had shared some of the 
> work from Len by pulling one of the branches (the 'suspend' branch), and 
> then you literally re-wrote _public_ history, so now tohose patches are 
> duplicated.

It's not only about destroying work and history, it can be worse than that.

For example look at commits:

816c2eda3ce8fa7eb62f22e01e2ec7a3f7d677c0 (merged between 2.6.26-rc8 and -rc9)
and
cc7e51666d82aedfd6b9a033ca1a10d71c21f1ca (merged now)

The export to quilt and the lazy default fuzz setting of quilt added
aside of Andi's Signed-off-by the following gem:

commit cc7e51666d82aedfd6b9a033ca1a10d71c21f1ca
Author: Len Brown <len.brown@intel.com>
Date:   Tue Jun 24 22:57:12 2008 -0400

    dock: bay: Don't call acpi_walk_namespace() when ACPI is disabled.
    
    Signed-off-by: Len Brown <len.brown@intel.com>
    Signed-off-by: Andi Kleen <ak@linux.intel.com>

diff --git a/drivers/acpi/bay.c b/drivers/acpi/bay.c
index 61b6c5b..e6caf5d 100644
--- a/drivers/acpi/bay.c
+++ b/drivers/acpi/bay.c
@@ -380,6 +380,9 @@ static int __init bay_init(void)
 	if (acpi_disabled)
 		return -ENODEV;
 
+	if (acpi_disabled)
+		return -ENODEV;
+
 	/* look for dockable drive bays */
 	acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
 		ACPI_UINT32_MAX, find_bay, &bays, NULL);
diff --git a/drivers/acpi/dock.c b/drivers/acpi/dock.c
index bb7c51f..1e872e7 100644
--- a/drivers/acpi/dock.c
+++ b/drivers/acpi/dock.c
@@ -920,6 +920,9 @@ static int __init dock_init(void)
 	if (acpi_disabled)
 		return 0;
 
+	if (acpi_disabled)
+		return 0;
+
 	/* look for a dock station */
 	acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
 			    ACPI_UINT32_MAX, find_dock, &num, NULL);

[ Note the code duplication in both files ]

I stumbled accross this incidentally while looking at the recent merge
commits.

While this one looks odd but harmless, probably a full audit of all
the affected commits should be done.

Please revert the one I happened to notice. Patch below.

Thanks,

	tglx

----------->
Subject: APCI: revert duplicated patch
From: Thomas Gleixner <tglx@linutronix.de>

commit 816c2eda3ce8fa7eb62f22e01e2ec7a3f7d677c0
    dock: bay: Don't call acpi_walk_namespace() when ACPI is disabled.  

was merged between 2.6.26-rc8 and -rc9)

Due to rebasing the ACPI tree via quilt the same patch got applied
again via 

commit cc7e51666d82aedfd6b9a033ca1a10d71c21f1ca
    dock: bay: Don't call acpi_walk_namespace() when ACPI is disabled.  

Revert it, as it is obviously bogus.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

---
diff --git a/drivers/acpi/bay.c b/drivers/acpi/bay.c
index e6caf5d..61b6c5b 100644
--- a/drivers/acpi/bay.c
+++ b/drivers/acpi/bay.c
@@ -380,9 +380,6 @@ static int __init bay_init(void)
 	if (acpi_disabled)
 		return -ENODEV;
 
-	if (acpi_disabled)
-		return -ENODEV;
-
 	/* look for dockable drive bays */
 	acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
 		ACPI_UINT32_MAX, find_bay, &bays, NULL);
diff --git a/drivers/acpi/dock.c b/drivers/acpi/dock.c
index 1e872e7..bb7c51f 100644
--- a/drivers/acpi/dock.c
+++ b/drivers/acpi/dock.c
@@ -920,9 +920,6 @@ static int __init dock_init(void)
 	if (acpi_disabled)
 		return 0;
 
-	if (acpi_disabled)
-		return 0;
-
 	/* look for a dock station */
 	acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
 			    ACPI_UINT32_MAX, find_dock, &num, NULL);

Re: [PATCH] Revert duplicate "dock: bay: Don't call acpi_walk_namespace() when ACPI is disabled" commit

[Andi Kleen]

> Please revert the one I happened to notice. Patch below.

Good catch. Thanks. I'll queue a revert.

-Andi

Re: [PATCH] Revert duplicate "ACPI: don't walk tables if ACPI was disabled" commit (was: Please pull ACPI updates)

[Thomas Gleixner]

On Fri, 18 Jul 2008, Thomas Gleixner wrote:
> 
> Please revert the one I happened to notice. Patch below.

Another one.

Thanks,
 
 	tglx
 
----------->
Subject: APCI: revert another duplicated patch
From: Thomas Gleixner <tglx@linutronix.de>

commit d1857056904d5f313f11184fcfa624652ff9620a

is another superfluous duplicate commit caused by
git -> quilt -> git conversion.

Revert it.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de> 

---
diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index 6d18ca3..9b227d4 100644
--- a/drivers/acpi/glue.c
+++ b/drivers/acpi/glue.c
@@ -336,9 +336,6 @@ static int __init acpi_rtc_init(void)
 	if (acpi_disabled)
 		return 0;
 
-	if (acpi_disabled)
-		return 0;
-
 	if (dev) {
 		rtc_wake_setup();
 		rtc_info.wake_on = rtc_wake_on;

Re: Please pull ACPI updates

[Andi Kleen]

Jesse Barnes wrote:
> On Wednesday, July 16, 2008 3:11 pm Rafael J. Wysocki wrote:
>> On Wednesday, 16 of July 2008, Andi Kleen wrote:
>>> Linus,
>>>
>>> Please pull from
>>>
>>>   git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-acpi-merge-2.6
>>> release-2.6.27
>>>
>>> to get the initial ACPI updates for 2.6.27. We got a few more changes
>>> dependent on yet unpulled trees and some other candidate patches,
>>> but that's the bulk for the changes intended for 2.6.27. Most of that
>>> has been collected by Len Brown before he went on sabbatical. I was
>>> relatively conservative with additional changes so far.
>> Well, IMO it would be better to merge PCI first.
> 
> Yeah, they're interdependent (I pulled from Len's tree, hopefully Andi 
> preserved the changesets).  I had wanted to do a little more testing of what 
> I've got, but I haven't heard any huge complaints so far so maybe things are 
> ok.  I'll generate a pull request now.

Hmm, but if you're dependent ACPI needs to go in first anyways, doesn't it?

I don't think the ACPI tree is dependent on PCI at least. Or at least I didn't
notice any problems in this area.

-Andi

Re: Please pull ACPI updates

[Linus Torvalds]

On Thu, 17 Jul 2008, Andi Kleen wrote:
> 
> Hmm, but if you're dependent ACPI needs to go in first anyways, doesn't it?

Umm. The particular PART of ACPI you depend on needs to go in first, yes.

That's the whole point of topic branches. They allow you to separate out 
work to different areas, so that people who are interested in (say) the 
PCI-impacting ones can merge with one part, without having to wait for the 
other parts to stabilize.

> I don't think the ACPI tree is dependent on PCI at least. Or at least I didn't
> notice any problems in this area.

The PCI tree merged the suspend branch from the ACPI tree. You can see it 
by lookin gat the PCI merge in gitk:

	gitk dc7c65db^..dc7c65db

and roughly in the middle there you'll find Jesse's commit 53eb2fbe, in 
which he merges branch 'suspend' from Len's ACPI tree. 

So Jesse got these three commits:

	0e6859d... ACPI PM: Remove obsolete Toshiba workaround
	8d2bdf4... PCI ACPI: Drop the second argument of platform_pci_choose_state
	0616678... ACPI PM: acpi_pm_device_sleep_state() cleanup

from Len's tree. Then look at these three commits that I got when I 
actually merged from you:

	741438b... ACPI PM: Remove obsolete Toshiba workaround
	a80a6da... PCI ACPI: Drop the second argument of platform_pci_choose_state
	2fe2de5... ACPI PM: acpi_pm_device_sleep_state() cleanup

Look familiar? It's the same patches - just different commit ID's. You 
rebased and moved them around, so they're not really the "same" at all, 
and they don't show the shared history any more, and the fact that they 
were pulled earlier into the PCI tree (and then into mine).

This is what rebasing causes.

			Linus

Re: Please pull ACPI updates

[Linus Torvalds]

On Thu, 17 Jul 2008, Linus Torvalds wrote:
> 
> That's the whole point of topic branches. They allow you to separate out 
> work to different areas, so that people who are interested in (say) the 
> PCI-impacting ones can merge with one part, without having to wait for the 
> other parts to stabilize.

Btw, you don't really have to have a lot of them.

When it comes to ACPI in particular, I would really prefer to see at least 
the ACPICA stuff in a separate topic branch. It comes in from a different 
source, it's maintained separately, and when it causes problems(*) it ends 
up usually being handled differently too.

Len additionally split things like bugzilla entries up into individual 
topics, and that was really nice to see when merging, but I have to say 
that it was also "above and beyond" what I've ever expected of any 
maintainer. That said, I think ACPI has been rather bugzilla-driven (many 
other areas are feature-driven), and I do think it makes tons of sense to 
put fixes in different branches, and then you can merge them when you 
actualyl close the bug when the fix has been verified.

So one reason I reacted strongly to the ACPI change was definitely just 
that ACPI used to be one of the really nicely done subsystems (not just 
from a git standpoint, but the whole git flow was part of it). There were 
some issues very early on in git usage, but I gave a shout-out to Len at 
the last kernel summit for a reason.

And in that sense it's definitely unfair to require quite _that_ level of 
separation. I'm really not expecting it. 

But I *really* hate pulling from somebody, and seeing commit dates that 
are from five minutes ago, and based on something that I had just pushed 
out (which was essentially the case for this round of ACPI changes).

That literally shows that the code was hardly tested _at_all_ in that 
exact configuration. It may have gotten testing based on some earlier 
kernel version, but then it very clearly got rebased (or just quilt 
imported) on top of a totally new kernel base, and was not tested in that 
version very much if at all.

So even if you end up using quilt, I'd suggest you do so on a specific 
base, rather than on some random "kernel-of-the-moment-in-the-middle- 
of-the-merge-window". Because then at least I feel like the people 
involved have been doing their own development without having the rug 
pulled out from them all the time by using a different kernel as a base.

		Linus

(*) Which is happily fairly rare these days! I obviously detest the 
complexity that is ACPI, but even if I detest it, Intel should get cudos 
for getting it to work.

Re: Please pull ACPI updates

[Linus Torvalds]

On Thu, 17 Jul 2008, Linus Torvalds wrote:
> 
> But I *really* hate pulling from somebody, and seeing commit dates that 
> are from five minutes ago, and based on something that I had just pushed 
> out (which was essentially the case for this round of ACPI changes).

And Andi, before this goes any further, I'd like to say that (a) no, I 
don't hate you and (b) sorry in advance and in retrospect for my obviously 
abrasive personality and just being harsh.

In particular, this is something that I have gone through with a _lot_ of 
maintainers. So you don't need to feel bad about it. Ingo and Thomas 
obviously did the very same thing not that long ago.

And Davem had the same issue in the networking tree - most of the times 
when I pulled, I could tell that he had _just_ rebased the whole series, 
and I just knew that it had gotten effectively zero testing in that 
particular configuration.

For other trees it's still ongoing: you can generally trivially tell by 
looking at the merges and the dates of the commits relative to them and 
'base' they are done on top of. 

So you're definitely not alone. There are people who have done the same 
thing, and in many cases they did it for months. I'll happily try to help 
you with any git issues, and we can even change git itself to help with 
some things (historically we certainly have - I certainly hope that the 
need for it is going away, though). 

And I can also report that the people who then re-learnt their workflow 
and got used to maintaining several queues and not always working at the 
top of the tree and rebasing on top of whatever "random Linus kernel of 
the moment" (in order to actually work with and test what they eventually 
ask me to pull!) have so far been pretty enthusiastic about the workflow 
they learn once they pick it up.

And to give them credit for being smarter them me, others (like Jeff) 
started doing the whole "many different branches" thing long before I 
personally even realized how helpful it is.

And as mentioned, some still use the "queue on top of the most recent 
version" model, and when it's something fairly far away in the periphery 
and doesn't impact others, I don't really care. If it hadn't been for the 
PCI merge bringing up the issue, I'd have ignored the ACPI case too.

			Linus

Re: Please pull ACPI updates

[Andi Kleen]

Linus Torvalds wrote:
> 
> On Thu, 17 Jul 2008, Linus Torvalds wrote:
>> That's the whole point of topic branches. They allow you to separate out 
>> work to different areas, so that people who are interested in (say) the 
>> PCI-impacting ones can merge with one part, without having to wait for the 
>> other parts to stabilize.
> 
> Btw, you don't really have to have a lot of them.
> 
> When it comes to ACPI in particular, I would really prefer to see at least 
> the ACPICA stuff in a separate topic branch. It comes in from a different 
> source, it's maintained separately, and when it causes problems(*) it ends 
> up usually being handled differently too.

Ok I can do that one separately.

I think my main problem was that it seemed so painful to change old
commits and I ended up accumulating ugly reverts and incremental changes,
but perhaps I just need to do better frontend scripts to make
that easier.

> So one reason I reacted strongly to the ACPI change was definitely just 
> that ACPI used to be one of the really nicely done subsystems (not just 
> from a git standpoint, but the whole git flow was part of it). There were 
> some issues very early on in git usage, but I gave a shout-out to Len at 
> the last kernel summit for a reason.

Well, at least for this summer the ACPI tree will have some Andi flavor.

> And in that sense it's definitely unfair to require quite _that_ level of 
> separation. I'm really not expecting it. 
> 
> But I *really* hate pulling from somebody, and seeing commit dates that 
> are from five minutes ago, and based on something that I had just pushed 
> out (which was essentially the case for this round of ACPI changes).
> 
> That literally shows that the code was hardly tested _at_all_ in that 
> exact configuration. It may have gotten testing based on some earlier 
> kernel version, but then it very clearly got rebased (or just quilt 
> imported) on top of a totally new kernel base, and was not tested in that 
> version very much if at all.

Hmm, perhaps I'm thick, but for me the only difference seems to be
that the submitter does the merge that you would do (and safes
himself a yelling at if it doesn't build or crashes at boot or similar...).

In both  cases there's a "untested in that configuration" end configuration
in the end, but there's nothing much that can be done against it,
can't it?

> 
> So even if you end up using quilt, I'd suggest you do so on a specific 
> base, rather than on some random "kernel-of-the-moment-in-the-middle- 
> of-the-merge-window". 

That is what I usually do. I use the last -git* snapshot. I just updated
the git tree shortly before I generate the merge tree just to make
sure it still builds in your current tree.

Given it won't be tested much in that newer configuration then (I actually
test booted it on a few systems at least[1]), but that would be the same on your
side, wouldn't it?

-Andi

[1] which was quite painful this time because I ran into several problems
outside ACPI. e.g. DMAR oopsed and the x86 defconfigs were totally broken
and some other issues.

Re: Please pull ACPI updates

[Ray Lee]

On Thu, Jul 17, 2008 at 9:23 AM, Andi Kleen <andi@firstfloor.org> wrote:
> Linus Torvalds wrote:
>> But I *really* hate pulling from somebody, and seeing commit dates that
>> are from five minutes ago, and based on something that I had just pushed
>> out (which was essentially the case for this round of ACPI changes).
>>
>> That literally shows that the code was hardly tested _at_all_ in that
>> exact configuration. It may have gotten testing based on some earlier
>> kernel version, but then it very clearly got rebased (or just quilt
>> imported) on top of a totally new kernel base, and was not tested in that
>> version very much if at all.
>
> Hmm, perhaps I'm thick, but for me the only difference seems to be
> that the submitter does the merge that you would do (and safes
> himself a yelling at if it doesn't build or crashes at boot or similar...).
>
> In both  cases there's a "untested in that configuration" end configuration
> in the end, but there's nothing much that can be done against it,
> can't it?

It matters to us end-testers when we do a git bisect. If you leave the
history intact and let the merging happen at Linus' end (or, at least
at merge time), then there is a point in history of your tree that
someone (or git bisect) can check out and try, validating the patch,
and therefore fingering a failed merge.

It's the difference between having tested patches and an untested
merge, or untested new patches and an untested merge. Your point is
the end result is untested either way. The other way to look at it is
*how much* untested history ends up in the tree. In Linus' version,
just the point from the merge onward is untested. In your version,
everything is new.

Re: Please pull ACPI updates

[Andi Kleen]

> It matters to us end-testers when we do a git bisect. If you leave the
> history intact 

The whole point of the exercise of cleaning up/rewriting the history is to make
the tree as bisectable as possible.

Otherwise e.g. if I submitted patch + fixup + fixup + revert + fixup etc.
everyone doing a bisect would go crazy or rather hit many points
with various subtle breakages.

and let the merging happen at Linus' end (or, at least
> at merge time), then there is a point in history of your tree that
> someone (or git bisect) can check out and try, validating the patch,
> and therefore fingering a failed merge.

Why would you care about the merge and not about the individual patches?
Note that these quilt merges don't have conflicts.

> It's the difference between having tested patches and an untested
> merge, or untested new patches

The patches are as tested individually as they were before. I don't see
how you can call something that was in linux-next for some time and also
in my test tree "untested". The completely merged tree is not tested
well [1] in both cases (unless after some time of course) as far as I can see,
no difference.

[1] I do some basic testing as in building and test booting on a few
machines on each merge, so calling it completely untested is not
true.

> and an untested merge. 

So when I do a rebase versus Linus doing a merge (end result
the same code base) how is that more untested?

Your point is
> the end result is untested either way. The other way to look at it is
> *how much* untested history ends up in the tree. In Linus' version,
> just the point from the merge onward is untested. In your version,
> everything is new.

Sorry I still don't see the difference. AFAIK the only difference
is that I do the merge vs Linus doing it and that it looks slightly
different in the history, but apart from that (as in what
actually ends up in the source tree) it's all the same.

-Andi

Re: Please pull ACPI updates

[Linus Torvalds]

On Thu, 17 Jul 2008, Andi Kleen wrote:
> 
> The whole point of the exercise of cleaning up/rewriting the history is to make
> the tree as bisectable as possible.

No.

"git bisect" is perfetly able to handle merges. They are _fine_.

The problem with rebasing is that it *changes* something that was already 
tested (and possibly merged into somebody elses tree) into SOMETHING ELSE.

And that means that a large portion of the previous testing is basically 
thrown away.

In particular, if something worked for somebody before, it also removes 
the "known good state" from a bisection standpoint, so rebasing actually 
makes things _harder_ to bisect - because now you cannot sanely bisect 
between two versions of the tree (when you mark the old tree "good", it 
has no relevance to the new tree that had all the old history rewritten).

So no, rebasing does _not_ make bisection easier. It makes it easier to 
understand, perhaps, but it actually makes many things much much harder, 
and removes all trace of any testing coverage that the old commit had.

			Linus

Re: Please pull ACPI updates

[Andi Kleen]

Linus Torvalds wrote:
> On Thu, 17 Jul 2008, Andi Kleen wrote:
>> The whole point of the exercise of cleaning up/rewriting the history is to make
>> the tree as bisectable as possible.
> 
> No.
> 
> "git bisect" is perfetly able to handle merges. They are _fine_.

The issue I worry about is it hitting between changes and their fixup.

e.g. for example if I find that specific change doesn't compile in some special
configuration then I amend it to fix that. Alternatively I could put in a fixup
commit  afterwards, but then if someone did bisect and the bisect hit inbetween
the change and the fixup they might end up with a tree that doesn't compile.

-Andi

Re: Please pull ACPI updates

[Linus Torvalds]

On Thu, 17 Jul 2008, Linus Torvalds wrote:
> 
> In particular, if something worked for somebody before, it also removes 
> the "known good state" from a bisection standpoint, so rebasing actually 
> makes things _harder_ to bisect - because now you cannot sanely bisect 
> between two versions of the tree (when you mark the old tree "good", it 
> has no relevance to the new tree that had all the old history rewritten).

Let me do a made-up example of this just to kind of illustrate the point.

Let's say that _I_ rebased history to always make it linear.

That would obviously make things much "easier" to bisect, since now it's 
just a linear list of commits, and bisection is just taking the midpoint 
of that list and trying it. Right? Also, I'd fix up the linear list so 
that any found bugs are squashed into th code that caused them, so all 
_known_ bugs are non-issues from the standpoint of bisection: because the 
code you are bisecting already has those removed entirely.

That's a clean nice linear history with no unnecessary breakages (no 
compile failures, no other unrelated and solved bugs) for bisection, so 
bisecting new bugs must be much simpler, right?

WRONG.

It means that a person who ran my tree as of yesterday, and had a working 
setup, but then updated to my tree as of today, and things break, can no 
longer bisect sanely AT ALL - because the state that he was at yesterday 
is basically completely *gone*, because it has been cleaned-up and 
sanitized, since I happened to rewrite history from a week ago due to 
finding a bug.

Also, related to the same thing, if that person had some patches of his 
own that he was working on on top of the state I had yesterday, since I 
rebased, it's now almost impossible for him to be able to judge what is 
really _new_ stuff, and what is just the old stuff he was working on, 
except it's been cleaned up and sanitized.

But at the same time, the new history is clearly _simpler_, isn't it? Yes, 
it is simpler, BUT ONLY IF YOU DON'T TAKE INTO ACCOUNT THAT SOMEBODY 
ALREADY SAW AND USED THE _OTHER_ HISTORY YESTERDAY!

I'm shouting, because this is really really important from a very 
fundamental standpoint. It's not just important from a git standpoint: 
this really is _not_ some odd git-specific implementation issue. No, it's 
much much more fundamental than git. It's a very basic fact that woudl be 
true with _any_ SCM.

So git just happens to encode that fundamental truth a bit more explicitly 
and make it very obvious. Git is very careful at _not_ losing that state 
as it existed somewhere yesterday.

So rebasing and cleanups may indeed result in a "simpler" history, but it 
only look that way if you then ignore all the _other_ "simpler" histories. 
So anybody who rebases basically creates not just one simple history, but 
a _many_ "simple" histories, and in doing so actually creates a 
potentially much bigger mess than he started out with!

As long as you never _ever_ expose your rewriting of history to anybody 
else, people won't notice or care, because you basically guarantee that 
nobody can ever see all those _other_ "simpler" histories, and they only 
see the one final result. That's why 'rebase' is useful for private 
histories.

But even then, any testing you did in your private tree is now suspect, 
because that testing was done with the old history that you threw away.  
So even if you delete all the old histories and never show them, they kind 
of do exist conceptually - they existed in the sense that you tested them, 
and you've just hidden the fact that what you release is different from 
what you tested.

		Linus

Re: Please pull ACPI updates

[Linus Torvalds]

On Thu, 17 Jul 2008, Linus Torvalds wrote:
> 
> But even then, any testing you did in your private tree is now suspect, 
> because that testing was done with the old history that you threw away.  
> So even if you delete all the old histories and never show them, they kind 
> of do exist conceptually - they existed in the sense that you tested them, 
> and you've just hidden the fact that what you release is different from 
> what you tested.

One final note on this: the above is obviously not a problem for simple 
code that only really does one thing, and in particular for code that you 
wrote yourself. Moving your own commits around to make them make more 
sense - or splitting them up etc - is often a _good_ thing, even if it 
obviously does change history.

So using rebase to clean up and simplify and/or fix up stupid ordering 
issues is good, and "git rebase -i" is actually really good for this 
thing.

No, the problems start happening when you do it on a larger scale, or (and 
this is very common in the kernel), your rebase _moves_ the commits over 
big distances because you update to the top of my development tree. In 
that case, while your patches themselves may not have changed, the base 
that you based them on may have changed really subtly - it still compiles, 
it still "works", but maybe it doesn't work as well as it used to. And 
that's why the old testing you did is basically almost worthless.

So rebasing can be good or bad. It's a matter of degree. Rebasing private 
and small things is generally good. Rebasing bigger things can cause 
problems. And the further away you rebase something, the more problems it 
will generally cause. 

		Linus

Re: Please pull ACPI updates

[Olivier Galibert]

On Thu, Jul 17, 2008 at 01:28:20PM -0700, Linus Torvalds wrote:
> One final note on this: the above is obviously not a problem for simple 
> code that only really does one thing, and in particular for code that you 
> wrote yourself. Moving your own commits around to make them make more 
> sense - or splitting them up etc - is often a _good_ thing, even if it 
> obviously does change history.

You seem to be talking of subtly different things Andi and you, and
since I'm quite interested in the answer I'll try to rephrase what I
understood.

You say "don't rebase on the most recent kernel version".  Andi seems
to accept that going forwards.  You say "use topic branches that are
based on whatever kernel version you had at the time, I'll do the
merge".  That's ok too.  His remaining question is "what do I do with
broken patches _in_the_topic_branch_?".  He wants to
amend/merge/split/reorder within the topic branch so that the branch
itself is bisectable.  So what should be done there?

  OG.

Re: Please pull ACPI updates

[Ray Lee]

On Fri, Jul 18, 2008 at 6:25 AM, Olivier Galibert <galibert@pobox.com> wrote:
> You say "don't rebase on the most recent kernel version".  Andi seems
> to accept that going forwards.  You say "use topic branches that are
> based on whatever kernel version you had at the time, I'll do the
> merge".  That's ok too.  His remaining question is "what do I do with
> broken patches _in_the_topic_branch_?".  He wants to
> amend/merge/split/reorder within the topic branch so that the branch
> itself is bisectable.  So what should be done there?

If the patches have problems, then make a new topic branch and redo
them there, or reorder, amend, squash, whatever inside the original
branch. The problem comes once you open that branch out for other
people to pull from, or if that branch had pulled patches from someone
else. At that point you're destroying the history that other people
are now already sharing, in a meta-data sense (changing the sha1), as
well as invalidating whatever test points that people may have had on
those commits.

In short, don't rewrite public history. If you want to share out your
works-in-progress, just let people know that those branches of yours
are volatile and not to be trusted. But you can't pull someone else's
public history, and then make it volatile; subtle trouble ensues.

Re: Please pull ACPI updates

[Andi Kleen]

> 
> It means that a person who ran my tree as of yesterday,

Ok I understand this applies to your tree because you have lots of direct users.
And also people tend to only submit patches to you which are relatively
well tested already and don't really do "raw development" in your tree.

But for people lower down the food chain that's not necessarily the
case. They usually only get some testing through -mm/linux-next
and perhaps occasionally for individual patches posted to verify
bugs. They tend to not have many people directly pulling their stuff
(and if it's someone it is some downstream developer who typically can deal
with an occasional rebase)

Anyways if you prefer I can send to you the raw development history
(with all reverts, fixups, non bisectable section etc.), but I suspect
you wouldn't really be very happy with that.

-Andi

Re: Please pull ACPI updates

[Ray Lee]

On Thu, Jul 17, 2008 at 12:49 PM, Andi Kleen <andi@firstfloor.org> wrote:
> Why would you care about the merge and not about the individual patches?
> Note that these quilt merges don't have conflicts.

Because sometimes merges are non-trivial. If you roll that merge
conflict resolution back into the original patch, then the patch is
now different. And in all these rebasings, who's to say there won't be
a typo that accidentally changes the original patch that has had more
testing? We'er all human, y'know?

>> It's the difference between having tested patches and an untested
>> merge, or untested new patches
>
> The patches are as tested individually as they were before. I don't see
> how you can call something that was in linux-next for some time and also
> in my test tree "untested".

Surely you agree that more testing is better? A rebased patch has had
less testing than the original patch, by definition.

> The completely merged tree is not tested
> well [1] in both cases (unless after some time of course) as far as I can see,
> no difference.
>
> [1] I do some basic testing as in building and test booting on a few
> machines on each merge, so calling it completely untested is not
> true.

Andi, no offense was intended here. I'm just asking you to walk
through a thought experiment with me, okay?

>> and an untested merge.
>
> So when I do a rebase versus Linus doing a merge (end result
> the same code base) how is that more untested?

If you rebase, you're creating new patches that have less testing than
the originals. You're also tossing away a history of the changesets,
which means that any external testers can no longer point to a
historical potion of a tree and say "I tested that".

Maybe the merging is trivial in all the cases you've hit so far,
great. What happens when it isn't? That's the larger point here.

>> Your point is
>> the end result is untested either way. The other way to look at it is
>> *how much* untested history ends up in the tree. In Linus' version,
>> just the point from the merge onward is untested. In your version,
>> everything is new.
>
> Sorry I still don't see the difference. AFAIK the only difference
> is that I do the merge vs Linus doing it and that it looks slightly
> different in the history, but apart from that (as in what
> actually ends up in the source tree) it's all the same.

Uhm, the history is the whole point of using source control and git.
If all we cared about was the end result and not the history, there'd
be little point to using source management other than to help speed
merging.

Re: Please pull ACPI updates

[Andi Kleen]

Ray Lee wrote:
> On Thu, Jul 17, 2008 at 12:49 PM, Andi Kleen <andi@firstfloor.org> wrote:
>> Why would you care about the merge and not about the individual patches?
>> Note that these quilt merges don't have conflicts.
> 
> Because sometimes merges are non-trivial. If you roll that merge
> conflict resolution back into the original patch, then the patch is
> now different. And in all these rebasings, who's to say there won't be
> a typo that accidentally changes the original patch that has had more
> testing? We'er all human, y'know?

You only focus only on the merges, but I focus on all the other changes too.
The reason I maintain patches in quilt is that it's quite easy to
fix them up.

Besides as a subsystem maintainer the actual conflict points are
very rare because normally people don't change drivers/acpi without
going through me.

>>> It's the difference between having tested patches and an untested
>>> merge, or untested new patches
>> The patches are as tested individually as they were before. I don't see
>> how you can call something that was in linux-next for some time and also
>> in my test tree "untested".
> 
> Surely you agree that more testing is better? A rebased patch has had
> less testing than the original patch, by definition.

What I don't agree on is that a rebased patch had less testing than
a patch that got merged by someone else (in this case Linus) into
their tree when my tree wasn't at exactly the same point. In both
cases it's a merge and yes it is untested initially, but not less
so in both of the cases.


>>> and an untested merge.
>> So when I do a rebase versus Linus doing a merge (end result
>> the same code base) how is that more untested?
> 
> If you rebase, you're creating new patches that have less testing than
> the originals. You're also tossing away a history of the changesets,
> which means that any external testers can no longer point to a
> historical potion of a tree and say "I tested that".

They can't do that anyways because I maintain my patches in quilt.

So there's no canonical such tree. Besides I don't consider
it very likely that testers just test my tree (except me myself).

Normally testers either test individual patches (e.g. something that is posted
as a test patch in bugzilla) or completely merged trees like -mm
or linux-next. I am not aware of a significant test population
that just pulls ACPI trees only. It really wouldn't make much sense
either, testers should really test multiple subsystems in parallel,
otherwise testing wouldn't really scale.

> Uhm, the history is the whole point of using source control and git.
> If all we cared about was the end result and not the history, there'd
> be little point to using source management other than to help speed
> merging.

Sorry, but that's not really how it works.

Normally the rule is (and Linus used to encourage that)
is that when something hits his tree it shouldn't have the complete development
history.

Because normally for non trivial changes you would end up with sequences
like

initial change
fix some problems
fix more problems found during testing
make it compile in configuration foo
fix a typo ...
etc.

[just take a look at some of the version numbers in larger patch series.
Often they easily hit double digits. Or sometimes the fix-fix-fix-fix-foo
patches in -mm. Of course Andrew tends to clean that up before more]


Needless to say such a conglomeration is not bisectable. If your
bisect ends in the middle it might not compile or crash in trivial
ways etc.

Or as a maintainer submitter sends patch version A
Then someone finds a problem.
Review finds problems.
Submitter sends patch version A v2
repeat a few times

Or again if you asked to keep the whole history the final merge would have

merge A
revert A
merge Av2
revert Av2
merge Av3
revert Av3
...

Now in a ideal world the person doing the change would get everything
right the first time, but we're not living in a ideal world.

But when something goes into the Linus tree it just supposed to be a single
patch that does this change cleanly without all these additional development steps.

Anyways I'm dropping out of this discussion now because I think I made
all my points already multiples times.

-Andi

Re: Please pull ACPI updates

[david]

On Thu, 17 Jul 2008, Andi Kleen wrote:

> Ray Lee wrote:
>> On Thu, Jul 17, 2008 at 12:49 PM, Andi Kleen <andi@firstfloor.org> wrote:
>>> Why would you care about the merge and not about the individual patches?
>>> Note that these quilt merges don't have conflicts.
>>
>> Because sometimes merges are non-trivial. If you roll that merge
>> conflict resolution back into the original patch, then the patch is
>> now different. And in all these rebasings, who's to say there won't be
>> a typo that accidentally changes the original patch that has had more
>> testing? We'er all human, y'know?
>
> You only focus only on the merges, but I focus on all the other changes too.
> The reason I maintain patches in quilt is that it's quite easy to
> fix them up.
>
> Besides as a subsystem maintainer the actual conflict points are
> very rare because normally people don't change drivers/acpi without
> going through me.
>
>>>> It's the difference between having tested patches and an untested
>>>> merge, or untested new patches
>>> The patches are as tested individually as they were before. I don't see
>>> how you can call something that was in linux-next for some time and also
>>> in my test tree "untested".
>>
>> Surely you agree that more testing is better? A rebased patch has had
>> less testing than the original patch, by definition.
>
> What I don't agree on is that a rebased patch had less testing than
> a patch that got merged by someone else (in this case Linus) into
> their tree when my tree wasn't at exactly the same point. In both
> cases it's a merge and yes it is untested initially, but not less
> so in both of the cases.
>

Andi,

say you create patch P1 against tree version T1 creating tree T2

you then rebase patch P1 against tree version T5 creating tree T6

people tested tree T2, they didn't test tree T6. while the changes made by 
patch P1 are still the same, there may be other changes that interact with 
things (and not nessasarily by chnaging the same area of the code, they 
may change memory layouts, timing, etc)

when someone is trying to track things down they can no longer recreate 
the state of tree T2, you've wiped the record of that from history. all 
they can do is to test version T5 and T6.

the other approach is that you create patch P1 against tree version T1 
creating tree T2, this then gets merged with tree version T5 upstream 
creating tree T6.

now when someone goes to track down a problem they can see all four tree 
versions, T1, T2, T5, and T6. they can not only test that T5 works but T6 
doesn't, but they can test that T2 works as well. They then can immediatly 
start looking for other interactions that are the result of the merge (and 
what's different between T1 and T5) rather then focusing just on 'what did 
patch P1 change'


now, it's also not good to have large areas of non-bisectable trees and 
bugs with their fixes a lot later, but with distributed testing and 
development you will never completely eliminate this.

there are things that you can do to minimize that, and using some number 
of topic branches seems to be one of the big ones (and I'll point you at 
the other explinations from this thread that have focused on what those 
are)

David Lang

Please pull ACPI updates

[Andi Kleen]

Linus,

Please pull ACPI updates from 

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

which contains

Andi Kleen (5):
      Revert "Fix FADT parsing"
      Revert "dock: bay: Don't call acpi_walk_namespace() when ACPI is disabled."
      Merge branch 'merge' into release-2.6.27
      Revert "ACPI: don't walk tables if ACPI was disabled"
      Merge branch 'for-upstream/acpi-test' of git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6 into release-2.6.27

Bjorn Helgaas (1):
      ACPI: stop complaints about interrupt link End Tags and blank IRQ descriptors

Henrique de Moraes Holschuh (7):
      ACPI: thinkpad-acpi: minor refactor on radio switch init
      ACPI: thinkpad-acpi: consolidate wlsw notification function
      ACPI: thinkpad-acpi: prepare for bluetooth and wwan rfkill support
      ACPI: thinkpad-acpi: WLSW overrides other rfkill switches
      ACPI: thinkpad-acpi: add bluetooth and WWAN rfkill support
      ACPI: thinkpad-acpi: bump up version to 0.21
      ACPI: thinkpad-acpi: don't misdetect in get_thinkpad_model_data() on -ENOMEM

Ingo Molnar (1):
      acpi: fix crash in core ACPI code, triggered by CONFIG_ACPI_PCI_SLOT=y

Zhao Yakui (2):
      ACPI: Ignore _BQC object when registering backlight device
      ACPI : Set FAN device to correct state in boot phase

 Documentation/laptops/thinkpad-acpi.txt |   26 ++-
 drivers/acpi/namespace/nsnames.c        |    8 +
 drivers/acpi/pci_link.c                 |   31 ++-
 drivers/acpi/tables/tbfadt.c            |   17 +-
 drivers/acpi/thermal.c                  |   43 +++
 drivers/acpi/utilities/utalloc.c        |    4 +
 drivers/acpi/video.c                    |   14 +-
 drivers/misc/Kconfig                    |    2 +
 drivers/misc/thinkpad_acpi.c            |  475 ++++++++++++++++++++++---------
 9 files changed, 446 insertions(+), 174 deletions(-)