Custom Search
|
Date: December 31, 2006
From: Evgeni Golov <sargentd-V0Z8x+al8ubk1uMJSBkQmQ@xxxxxxxxxxxxxxxx>
References:
<20061231192158.GA19002@xxxxxxxxxxxxxxxxxxxxx> <20061231200745.GC19002@xxxxxxxxxxxxxxxxxxxxx> <en989k$hml$1@xxxxxxxxxxxxx> <20061231223406.GA30112@xxxxxxxxxxxxxxxxxxxxx>
On Sun, 31 Dec 2006 20:34:07 -0200 Henrique de Moraes Holschuh wrote: > > NACK for Z61m with latest BIOS. Fn+Home/End works, and tpb reports > > correctly. > > Just checking: You are at BIOS 7FET94WW (2.12), correct? It was > released 2006-12-18. Uh, 2.12 is out? Okay, I'm on 2.11, will try 2.12 tomorrow, when I'm back from the new-year-party here ;) So NACK for 2.11, not 2.12... Regards -- ^^^ | Evgeni -SargentD- Golov (sargentd-V0Z8x+al8ubk1uMJSBkQmQ@xxxxxxxxxxxxxxxx) d(O_o)b | PGP-Key-ID: 0xAC15B50C >-|-< | WWW: http://www.die-welt.net ICQ: 54116744 / \ | IRC: #sod @ irc.german-freakz.net ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Date: December 31, 2006
From: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@xxxxxxxxxxxxxxxx>
In-reply-to:
<en989k$hml$1@xxxxxxxxxxxxx>
References:
<20061231192158.GA19002@xxxxxxxxxxxxxxxxxxxxx> <20061231200745.GC19002@xxxxxxxxxxxxxxxxxxxxx> <en989k$hml$1@xxxxxxxxxxxxx>
On Sun, 31 Dec 2006, Evgeni Golov wrote: > On Sun, 31 Dec 2006 18:07:45 -0200 Henrique de Moraes Holschuh wrote: > > It is likely that the R60 and Z61 with 2.x BIOS might have the same > > issue, so if you have any of these machines with a 2.x BIOS, please > > reply telling us whether it shows the brightness issue or not. > > NACK for Z61m with latest BIOS. Fn+Home/End works, and tpb reports > correctly. Just checking: You are at BIOS 7FET94WW (2.12), correct? It was released 2006-12-18. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Date: December 31, 2006
From: Evgeni Golov <sargentd-V0Z8x+al8ubk1uMJSBkQmQ@xxxxxxxxxxxxxxxx>
References:
<20061231192158.GA19002@xxxxxxxxxxxxxxxxxxxxx> <20061231200745.GC19002@xxxxxxxxxxxxxxxxxxxxx>
On Sun, 31 Dec 2006 18:07:45 -0200 Henrique de Moraes Holschuh wrote: > It is likely that the R60 and Z61 with 2.x BIOS might have the same > issue, so if you have any of these machines with a 2.x BIOS, please > reply telling us whether it shows the brightness issue or not. NACK for Z61m with latest BIOS. Fn+Home/End works, and tpb reports correctly. regards Evgeni -- ^^^ | Evgeni -SargentD- Golov (sargentd-V0Z8x+al8ubk1uMJSBkQmQ@xxxxxxxxxxxxxxxx) d(O_o)b | PGP-Key-ID: 0xAC15B50C >-|-< | WWW: http://www.die-welt.net ICQ: 54116744 / \ | IRC: #sod @ irc.german-freakz.net ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Date: December 31, 2006
From: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@xxxxxxxxxxxxxxxx>
In-reply-to:
<20061231192158.GA19002-ZGHd14iZgfaRjzvQDGKj+xxZW9W5cXbT@xxxxxxxxxxxxxxxx>
References:
<20061231192158.GA19002@xxxxxxxxxxxxxxxxxxxxx>
On Sun, 31 Dec 2006, Henrique de Moraes Holschuh wrote: > Well, I have finally got down to try to track the bug with brightness in X60 > ThinkPads. I have just been told elsewhere in this thread by Chris Hanson that T60 with BIOS 2.x also have this bug, so I am also interested in T60 reports. It is likely that the R60 and Z61 with 2.x BIOS might have the same issue, so if you have any of these machines with a 2.x BIOS, please reply telling us whether it shows the brightness issue or not. Obviously, I am interested in answers to the X60 questions from onwers of *any* machine that has the problem, even if it is not a X60. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Date: December 31, 2006
From: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@xxxxxxxxxxxxxxxx>
In-reply-to:
<459811EE.5080803-EfZU8u+QLuPpgkiH4x7ZXw@xxxxxxxxxxxxxxxx>
References:
<20061231192158.GA19002@xxxxxxxxxxxxxxxxxxxxx> <459811EE.5080803@xxxxxxxxxxxxx>
On Sun, 31 Dec 2006, Chris Hanson wrote: > This is also a problem with the 2.x versions of the T60 BIOS, so that's > a larger pool of people who can help. I can provide help, and I'm > willing to write to Lenovo to complain. This probably means ALL 2.x BIOSes in *60 and *61 are an issue. This does not bode well. OTOH, some T60 owners *can* raise hell with Lenovo for breaking Linux support, which will help later on. > The 2.x versions also has the problem that causes the two processors to > be controlled together when doing frequency scaling; in the 1.x the > processors are handled independently. My limited research seems to > indicate that this is an ACPI problem. This is a separate issue, so let's start another thread to talk about it. And again, please remember you CAN report it as a bug to Lenovo. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Date: December 31, 2006
From: Chris Hanson <cph-EfZU8u+QLuPpgkiH4x7ZXw@xxxxxxxxxxxxxxxx>
In-reply-to:
<20061231192158.GA19002-ZGHd14iZgfaRjzvQDGKj+xxZW9W5cXbT@xxxxxxxxxxxxxxxx>
References:
<20061231192158.GA19002@xxxxxxxxxxxxxxxxxxxxx>
Henrique de Moraes Holschuh wrote: > Therefore, we are stuck with properly identifying the bug, and then flooding > Lenovo with complains from X60 owners still under warranty, requesting a > fix. I will add workarounds to ibm-acpi, if one is possible, but we don't > know much about that yet. > > Obviously, I will need help from X60 owners as I cannot reproduce the > problem without a X60. This is also a problem with the 2.x versions of the T60 BIOS, so that's a larger pool of people who can help. I can provide help, and I'm willing to write to Lenovo to complain. The 2.x versions also has the problem that causes the two processors to be controlled together when doing frequency scaling; in the 1.x the processors are handled independently. My limited research seems to indicate that this is an ACPI problem. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Date: December 31, 2006
From: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@xxxxxxxxxxxxxxxx>
Well, I have finally got down to try to track the bug with brightness in X60
ThinkPads.
And, well, whatever Lenovo did on the X60 that broke the brightness support,
it doesn't look like it was in the ACPI tables. That means BIOS and/or EC
firmware, which is not something I am going to attempt to fix, unless
someone gives me a X60 as a gift ;-)
Therefore, we are stuck with properly identifying the bug, and then flooding
Lenovo with complains from X60 owners still under warranty, requesting a
fix. I will add workarounds to ibm-acpi, if one is possible, but we don't
know much about that yet.
Obviously, I will need help from X60 owners as I cannot reproduce the
problem without a X60.
Problem description, as I understood it:
1. Fn+Home/fn+End *do* work, but tpb, KDE and other similar
"ThinkPad CMOS snooping" things don't report Fn+Home (brightness up)
anymore.
2. Lenovo changed the mappings and Fn+Home generates a hotkey event
that is the same as the fn+F7 one (switch monitor output), which
would explain all sort of weird behaviour if fn+F7 ain't safe in
your particular configuration.
So, let's start with a few question for X60 owners with BIOS 2.x:
First, did I understood the problem correctly? Do you have any extra
information on the issue?
Remember that if fn+Home is indeed causing fn+F7 events, something in your
system may well react to fn+F7 (and thus, also to fn+Home now), and, e.g.,
hang X *hard* trying to switch from the internal display to the external
output. So have a look on the ThinkWiki pages about video output switching
before you report back any sort of weird behaviour that could be explained
by *that*.
Second, please set the ibm-acpi hotkey mask to 0xffff, and tell me what
events fn+Home, fn+End and fn+F7 are generating (probably it is safer to do
this from the console).
Third, please tell me if "echo 4 > /proc/acpi/ibm/cmos" (brightness up) and
"echo 5 > /proc/acpi/ibm/cmos" (brightness down) works.
Fourth, if you disable the bit for fn+F7 in the hotkey mask, what happens to
fn+F7 and fn+Home ? and if you enable it, what happens to fn+F7 an fn+Home?
(again, be careful if this would cause video output port switching, try it
from the console).
I am directing replies to this thread to the ibm-acpi-devel mailinglist.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Date: December 31, 2006
From: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@xxxxxxxxxxxxxxxx>
In-reply-to:
<E1GtH0P-0007WV-Q5-mUMCHd/4doTcSu1xaG3OGkB+6BGkLq7r@xxxxxxxxxxxxxxxx>
References:
<E1GtH0P-0007WV-Q5@xxxxxxxxxxxxxxxxxxx>
Whoopie from ThinkWiki just sent me an email, calling my attention to the fact that the patch you submitted is in fact different from the one I merged... something I should have triple-verified. It appears the t60p has the bay in a different ACPI node than some other *60 ThinkPads. Either that, or the node moves depending on ICHR mode set in the BIOS. So I apologise for the screw up, and: Acked-by: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@xxxxxxxxxxxxxxxx> I am merging your patch into the ibm-acpi tree and will ask Len to push it to Linus. Now, please excuse me while I go look for a new brown-paperbag hat... On Sun, 10 Dec 2006, Theodore Ts'o wrote: > Add Ultrabay Support for the T60p Thinkpad > > The following patch adds support for obtaining the status and ejecting > Ultrabay devices for the T60p Thinkpad; my guess is that it probably > works on T60 Thinkpads and probably more recent Lenovo latops as well. > > With the 2.03 BIOS I have been able to eject a SATA drive in an Ultrabay > carrier by using the command: > > "echo 1 > /sys/class/scsi_device/1:0:0:0/device/delete" > > and upon re-inserting the it back into the device and issuing the > command: > > "echo 0 0 0 > /sys/class/scsi_host/host1/scan" > > have the device appear again. (With the 1.02 BIOS the device does not > function when re-inserted, even after a warm boot; a cold reboot is > required to store the Ultrabay device's functionality.) > > More complicated Ultrabay eject and insert scripts can be found on the > ThinkWiki, although it's important to comment out the "hdparm -Y" as it > apparently doesn't work or do anything, and causes the eject process to > hang for about a minute. > > Signed-off-by: "Theodore Ts'o" <tytso-3s7WtUTddSA@xxxxxxxxxxxxxxxx> > > Index: 2.6.19/drivers/acpi/ibm_acpi.c > =================================================================== > --- 2.6.19.orig/drivers/acpi/ibm_acpi.c 2006-12-09 18:35:09.000000000 > -0500 > +++ 2.6.19/drivers/acpi/ibm_acpi.c 2006-12-09 18:35:42.000000000 -0500 > @@ -169,6 +169,7 @@ > #endif > IBM_HANDLE(bay, root, "\\_SB.PCI.IDE.SECN.MAST", /* 570 */ > "\\_SB.PCI0.IDE0.IDES.IDSM", /* 600e/x, 770e, 770x */ > + "\\_SB.PCI0.IDE0.PRIM.MSTR", /* T60p */ > "\\_SB.PCI0.IDE0.SCND.MSTR", /* all others */ > ); /* A21e, R30, R31 */ > -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Date: December 30, 2006
From: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@xxxxxxxxxxxxxxxx>
Well, I am taking my sweet time to release a tarball, so now that ibm-acpi is in 2.6.20-rc2, here are the patches. Enjoy! -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
ibm-acpi-2.6.18.patch
Description: Text Data
ibm-acpi-2.6.19.patch
Description: Text Data
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Date: December 30, 2006
From: Henrique de Moraes Holschuh <hmh@xxxxxxxxxx>
In-reply-to:
<20061230192649.13533.53575.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<20061230192618.13533.29790.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20061230192649.13533.53575.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
On Sat, 30 Dec 2006, Henrique de Moraes Holschuh wrote: > Support for ACPI_BAY has not been merged in mainline yet. Usage of > "depends on FOO=n" fails if FOO is undefined, thus ibm-acpi support > for bay was being made non-available in a kernel that has no other > sort of bay support. > > Fix it to use "depends on ! FOO" instead, that does the right thing > when FOO is undefined. Fix ACPI_IBM_DOCK accordingly as well while > at it, and also improve the help text. Either this patch, or a different fix (see below), should to be sent to Linus. Otherwise, it causes a regression (lack of removable bay support in ibm-acpi). Unfortunately, I didn't notice the problem before because I had ACPI_BAY applied to my 2.6.18 and 2.6.19 test trees. The patch uses "depends on ! FOO", which means the legacy support in ibm-acpi can be selected if ACPI_DOCK or ACPI_BAY is set to "m" (module). Loading ACPI_DOCK or ACPI_BAY module along with ibm-acpi and ACPI_IBM_DOCK or ACPI_IBM_BAY could cause weird behaviour (untested) on some systems. There are alternate ways to fix this. The easiest would be to revert commit 2df910b4c3edcce9a0c12394db6f5f4a6e69c712 from Linus' tree, and I'd submit it again when ACPI_BAY is ready to be sent to mainline. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
Date: December 30, 2006
From: Henrique de Moraes Holschuh <hmh@xxxxxxxxxx>
In-reply-to:
<20061230192618.13533.29790.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<20061230192618.13533.29790.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
From: Henrique de Moraes Holschuh <hmh@xxxxxxxxxx>
Support for ACPI_BAY has not been merged in mainline yet. Usage of
"depends on FOO=n" fails if FOO is undefined, thus ibm-acpi support
for bay was being made non-available in a kernel that has no other
sort of bay support.
Fix it to use "depends on ! FOO" instead, that does the right thing
when FOO is undefined. Fix ACPI_IBM_DOCK accordingly as well while
at it, and also improve the help text.
Signed-off-by: Henrique de Moraes Holschuh <hmh@xxxxxxxxxx>
---
drivers/acpi/Kconfig | 17 ++++++++++-------
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index aa884d8..95de81f 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -213,26 +213,29 @@ config ACPI_IBM
config ACPI_IBM_DOCK
bool "Legacy Docking Station Support"
depends on ACPI_IBM
- depends on ACPI_DOCK=n
- default n
+ depends on ! ACPI_DOCK
+ default y
---help---
Allows the ibm_acpi driver to handle docking station events.
This support is obsoleted by CONFIG_HOTPLUG_PCI_ACPI. It will
allow locking and removing the laptop from the docking station,
but will not properly connect PCI devices.
- If you are not sure, say N here.
+ If you are not sure, select ACPI_DOCK instead.
config ACPI_IBM_BAY
bool "Legacy Removable Bay Support"
depends on ACPI_IBM
- depends on ACPI_BAY=n
- default n
+ depends on ! ACPI_BAY
+ default y
---help---
Allows the ibm_acpi driver to handle removable bays.
- This support is obsoleted by CONFIG_ACPI_BAY.
+ This support is obsoleted by CONFIG_ACPI_BAY. It will allow
+ enabling and disabling devices in the removable bays, but it
+ will not properly add or remove the devices from the kernel,
+ which must be done manually by userspace scripts.
- If you are not sure, say N here.
+ If you are not sure, select ACPI_BAY instead if it is available.
config ACPI_TOSHIBA
tristate "Toshiba Laptop Extras"
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Date: December 20, 2006
From: Len Brown <lenb@xxxxxxxxxx>
In-reply-to:
<20061218175332.8826.95334.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<20061218175207.8826.25057.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20061218175332.8826.95334.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Applied. thanks, -Len On Monday 18 December 2006 12:53, Henrique de Moraes Holschuh wrote: > From: Alexey Starikovskiy <alexey_y_starikovskiy@xxxxxxxxxxxxxxx> > > Allow clean removal by setting notify_installed in the right place. > > Alexey Starikovskiy <alexey.y.starikovskiy@xxxxxxxxx> > Signed-off-by: Henrique de Moraes Holschuh <hmh@xxxxxxxxxx> > Signed-off-by: Len Brown <len.brown@xxxxxxxxx> > --- > > drivers/acpi/ibm_acpi.c | 3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c > index 003a987..719a320 100644 > --- a/drivers/acpi/ibm_acpi.c > +++ b/drivers/acpi/ibm_acpi.c > @@ -1805,7 +1805,7 @@ static int __init setup_notify(struct ibm_struct *ibm) > ibm->name, status); > return -ENODEV; > } > - > + ibm->notify_installed = 1; > return 0; > } > > @@ -1882,7 +1882,6 @@ static int __init ibm_init(struct ibm_struct *ibm) > ret = setup_notify(ibm); > if (ret < 0) > return ret; > - ibm->notify_installed = 1; > } > > return 0; > > > -- > "One disk to rule them all, One disk to find them. One disk to bring > them all and in the darkness grind them. In the Land of Redmond > where the shadows lie." -- The Silicon Valley Tarot > Henrique Holschuh > - > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
Date: December 19, 2006
From: John Fettig <jfettig-e94Sedi4moU@xxxxxxxxxxxxxxxx>
In-reply-to:
<20061217215628.GB4815-ZGHd14iZgfaRjzvQDGKj+xxZW9W5cXbT@xxxxxxxxxxxxxxxx>
References:
<1166205192.29625.6.camel@xxxxxxxxxxxxxxxxxxxxx> <20061217215628.GB4815@xxxxxxxxxxxxxxxxxxxxx>
On Sun, 2006-12-17 at 19:56 -0200, Henrique de Moraes Holschuh wrote: > Regression caused by a new BIOS from Lenovo, and I have not had the time to > look into it yet. Ok, I will anxiously await your appraisal. Thanks, John ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Date: December 18, 2006
From: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@xxxxxxxxxxxxxxxx>
In-reply-to:
<20061218175207.8826.25057.stgit-H32KNTuDSMjdPi8JTuvWk31TOOPCyuNQ5NbjCUgZEJk@xxxxxxxxxxxxxxxx>
References:
<20061218175207.8826.25057.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
From: Alexey Starikovskiy
<alexey_y_starikovskiy-VuQAYsv1563Yd54FQh9/CA@xxxxxxxxxxxxxxxx>
Allow clean removal by setting notify_installed in the right place.
Alexey Starikovskiy
<alexey.y.starikovskiy-ral2JQCrhuEAvxtiuMwx3w@xxxxxxxxxxxxxxxx>
Signed-off-by: Henrique de Moraes Holschuh
<hmh-N3TV7GIv+o9fyO9Q7EP/yw@xxxxxxxxxxxxxxxx>
Signed-off-by: Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@xxxxxxxxxxxxxxxx>
---
drivers/acpi/ibm_acpi.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c
index 003a987..719a320 100644
--- a/drivers/acpi/ibm_acpi.c
+++ b/drivers/acpi/ibm_acpi.c
@@ -1805,7 +1805,7 @@ static int __init setup_notify(struct ibm_struct *ibm)
ibm->name, status);
return -ENODEV;
}
-
+ ibm->notify_installed = 1;
return 0;
}
@@ -1882,7 +1882,6 @@ static int __init ibm_init(struct ibm_struct *ibm)
ret = setup_notify(ibm);
if (ret < 0)
return ret;
- ibm->notify_installed = 1;
}
return 0;
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Date: December 18, 2006
From: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@xxxxxxxxxxxxxxxx>
Please pull from the ibm-acpi-devel git tree at:
git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
branch for-upstream/acpi-test, to receve this patch series.
This series contains just one patch that was dropped from acpi-test
for some unknown reason. It is the same patch I submitted for 2.6.20
and 2.6.19 in a separate message.
ACPI: ibm_acpi: allow clean removal
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Date: December 18, 2006
From: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@xxxxxxxxxxxxxxxx>
In-reply-to:
<20061218174503.8531.86189.stgit-H32KNTuDSMjdPi8JTuvWk31TOOPCyuNQ5NbjCUgZEJk@xxxxxxxxxxxxxxxx>
References:
<20061218174503.8531.86189.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
From: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@xxxxxxxxxxxxxxxx>
This patch adds support for the ultrabay on the T60, X60 and other new
ThinkPads that have a SATA ultrabay.
I intend to keep bay and dock support in ibm-acpi working and updated until
it finally gets deprecated and removed in favour of the generic dock and
bay support. But we aren't there yet.
Signed-off-by: Henrique de Moraes Holschuh
<hmh-N3TV7GIv+o9fyO9Q7EP/yw@xxxxxxxxxxxxxxxx>
---
drivers/acpi/ibm_acpi.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c
index 003a987..4a9f3bf 100644
--- a/drivers/acpi/ibm_acpi.c
+++ b/drivers/acpi/ibm_acpi.c
@@ -169,6 +169,7 @@ IBM_HANDLE(dock, root, "\\_SB.GDCK", /* X30, X31,
X40 */
#endif
IBM_HANDLE(bay, root, "\\_SB.PCI.IDE.SECN.MAST", /* 570 */
"\\_SB.PCI0.IDE0.IDES.IDSM", /* 600e/x, 770e, 770x */
+ "\\_SB.PCI0.SATA.SCND.MSTR", /* T60, X60, Z60 */
"\\_SB.PCI0.IDE0.SCND.MSTR", /* all others */
); /* A21e, R30, R31 */
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Date: December 18, 2006
From: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@xxxxxxxxxxxxxxxx>
In-reply-to:
<20061218174503.8531.86189.stgit-H32KNTuDSMjdPi8JTuvWk31TOOPCyuNQ5NbjCUgZEJk@xxxxxxxxxxxxxxxx>
References:
<20061218174503.8531.86189.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
From: Alexey Starikovskiy
<alexey_y_starikovskiy-VuQAYsv1563Yd54FQh9/CA@xxxxxxxxxxxxxxxx>
Allow clean removal by setting notify_installed in the right place.
Alexey Starikovskiy
<alexey.y.starikovskiy-ral2JQCrhuEAvxtiuMwx3w@xxxxxxxxxxxxxxxx>
Signed-off-by: Henrique de Moraes Holschuh
<hmh-N3TV7GIv+o9fyO9Q7EP/yw@xxxxxxxxxxxxxxxx>
Signed-off-by: Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@xxxxxxxxxxxxxxxx>
---
drivers/acpi/ibm_acpi.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c
index 4a9f3bf..025a9f9 100644
--- a/drivers/acpi/ibm_acpi.c
+++ b/drivers/acpi/ibm_acpi.c
@@ -1806,7 +1806,7 @@ static int __init setup_notify(struct ibm_struct *ibm)
ibm->name, status);
return -ENODEV;
}
-
+ ibm->notify_installed = 1;
return 0;
}
@@ -1883,7 +1883,6 @@ static int __init ibm_init(struct ibm_struct *ibm)
ret = setup_notify(ibm);
if (ret < 0)
return ret;
- ibm->notify_installed = 1;
}
return 0;
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Date: December 18, 2006
From: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@xxxxxxxxxxxxxxxx>
Please pull from the ibm-acpi-devel git tree at:
git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
branch for-upstream/acpi-release, to receve this patch series.
The following series contains two patches that should be merged for 2.6.20,
and also 2.6.19.y (thus stable@korg is also cc'ed).
ACPI: ibm_acpi: allow clean removal
Without this patch, rmmod'ing ibm-acpi is a Bad Idea. This patch
was already in acpi-test, and was dropped for some unknown reason.
I will re-submit it for acpi-test as well.
ACPI: ibm-acpi: add support for the ultrabay on the T60,X60
Tested patch that adds support for the T60, X60 and other ThinkPads
with a SATA Advanced Ultrabay.
This patch is already in the acpi-test tree.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Date: December 17, 2006
From: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@xxxxxxxxxxxxxxxx>
In-reply-to:
<1166205192.29625.6.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@xxxxxxxxxxxxxxxx>
References:
<1166205192.29625.6.camel@xxxxxxxxxxxxxxxxxxxxx>
On Fri, 15 Dec 2006, John Fettig wrote: > It seems something is wrong with the way ibm_acpi is interpreting the Fn > +Home combo which is supposed to be "brightness up" on this laptop. > When I press it while Xorg is running, it crashes (or at the very least, > blanks). When I press it while in a VT, it works fine. If I stop acpi > and then press it, it still works fine. I'm not sure exactly where the > bug is, and I suspect there are multiple across different packages. I > created a bug report at > > https://bugs.freedesktop.org/show_bug.cgi?id=9355 > > Any help? Regression caused by a new BIOS from Lenovo, and I have not had the time to look into it yet. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Date: December 16, 2006
From: Len Brown <lenb@xxxxxxxxxx>
In-reply-to:
<20061125204155.6604.35338.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<20061125204155.6604.35338.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
applied, with this update to play with Linux-2.6.20-rc1
thanks,
-Len
commit 25c68a33b7b74b37793b1250007e5e21d621a7fc
Author: Len Brown <len.brown@xxxxxxxxx>
Date: Fri Dec 8 04:43:41 2006 -0500
ACPI: ibm_acpi: respond to workqueue update
Signed-off-by: Len Brown <len.brown@xxxxxxxxx>
diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c
index 92e7b6e..ab18007 100644
--- a/drivers/acpi/ibm_acpi.c
+++ b/drivers/acpi/ibm_acpi.c
@@ -1825,9 +1825,9 @@ static enum fan_control_commands fan_control_commands;
static int fan_control_status_known;
static u8 fan_control_initial_status;
-static void fan_watchdog_fire(void *ignored);
+static void fan_watchdog_fire(struct work_struct *ignored);
static int fan_watchdog_maxinterval;
-static DECLARE_WORK(fan_watchdog_task, fan_watchdog_fire, NULL);
+static DECLARE_DELAYED_WORK(fan_watchdog_task, fan_watchdog_fire);
static int fan_init(void)
{
@@ -2284,7 +2284,7 @@ static int fan_write(char *buf)
return rc;
}
-static void fan_watchdog_fire(void *ignored)
+static void fan_watchdog_fire(struct work_struct *ignored)
{
printk(IBM_NOTICE "fan watchdog: enabling fan\n");
if (fan_set_enable()) {
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Date: December 15, 2006
From: John Fettig <jfettig-e94Sedi4moU@xxxxxxxxxxxxxxxx>
Hello, It seems something is wrong with the way ibm_acpi is interpreting the Fn +Home combo which is supposed to be "brightness up" on this laptop. When I press it while Xorg is running, it crashes (or at the very least, blanks). When I press it while in a VT, it works fine. If I stop acpi and then press it, it still works fine. I'm not sure exactly where the bug is, and I suspect there are multiple across different packages. I created a bug report at https://bugs.freedesktop.org/show_bug.cgi?id=9355 Any help? John ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Date: December 10, 2006
From: Theodore Tso <tytso-3s7WtUTddSA@xxxxxxxxxxxxxxxx>
In-reply-to:
<20061210124945.GA23625-ZGHd14iZgfaRjzvQDGKj+xxZW9W5cXbT@xxxxxxxxxxxxxxxx>
References:
<E1GtH0P-0007WV-Q5@xxxxxxxxxxxxxxxxxxx> <20061210124945.GA23625@xxxxxxxxxxxxxxxxxxxxx>
On Sun, Dec 10, 2006 at 10:49:46AM -0200, Henrique de Moraes Holschuh wrote:
>
> Thanks, an equivalent patch is alredy merged in acpi-test, and waiting a
> push to linus.
>
> BTW: this is an ACK if you want to merge this patch ahead of the stuff in
> acpi-test.
Great, I don't think I saw any mention of T60 support on the
linux-thinkpad mailing list, so I didn't realize this work had already
been done. Would have saved me all of 15 minutes or so. :-)
When is acpi-test scehduled to be merged? If it's going to be pushed
soon into mainline, then I don't want to make any extra work for
folks. If it's going to be a while, the patch is pretty simple and
low-risk, so hopefully it can get merged quickly.
> > have the device appear again. (With the 1.02 BIOS the device does not
> > function when re-inserted, even after a warm boot; a cold reboot is
> > required to store the Ultrabay device's functionality.)
>
> Nice to know that, thanks.
I wasn't quite exact in describing the problem originally, so for the
record, if you are using a 1.02/1.04 BIOS, if all you do is
disassociate the device using:
"echo 1 > /sys/class/scsi_device/1:0:0:0/device/delete"
it's fine. But if you apply this patch and then actually shut the bay using:
"echo eject > /proc/acpi/ibm/bay"
Then when you re-insert the disk, it will appear to be probed, but any
attempt to read or write from the disk will return an error, and doing
a shutdown and trying to boot off of the device will also result in an
error. Only a power-cycle will restore the Ultrabay to usability.
When I upgraded to the 2.03 BIOS, it worked just fine, so I assume
this was a BIOS and/or DSDT bug fix.
> Take a look on the experimental ACPI bay and dock support in acpi-test, it
> is even better than ibm-acpi's builtin support... and in fact, deprecates
> it.
Great, I'll have to look at it. In the meantime, here's an updated
patch which only changes the documentation and comments. I'll leave
it to Andrew/Linus to decide whether they want to merge this patch or
acpi-test.
- Ted
Add Ultrabay Support for the T60p Thinkpad
The following patch adds support for obtaining the status and ejecting
Ultrabay devices for the T60p Thinkpad; my guess is that it probably
works on T60 Thinkpads and probably more recent Lenovo latops as well.
With the 2.03 BIOS I have been able to eject a SATA drive in an Ultrabay
carrier by using the commands:
"echo 1 > /sys/class/scsi_device/1:0:0:0/device/delete"
"echo eject > /proc/acpi/ibm/bay"
and upon re-inserting the it back into the device and issuing the
command:
"echo 0 0 0 > /sys/class/scsi_host/host1/scan"
have the device appear again. (With the 1.02 BIOS the device does not
function when re-inserted, even after a warm boot; a cold reboot is
required to store the Ultrabay device's functionality.)
More complicated Ultrabay eject and insert scripts can be found on the
ThinkWiki, although it's important to comment out the "hdparm -Y" as it
apparently doesn't work or do anything, and causes the eject process to
hang for about a minute.
Signed-off-by: "Theodore Ts'o" <tytso-3s7WtUTddSA@xxxxxxxxxxxxxxxx>
Index: 2.6.19/drivers/acpi/ibm_acpi.c
===================================================================
--- 2.6.19.orig/drivers/acpi/ibm_acpi.c 2006-12-09 18:35:09.000000000 -0500
+++ 2.6.19/drivers/acpi/ibm_acpi.c 2006-12-09 18:35:42.000000000 -0500
@@ -169,6 +169,7 @@
#endif
IBM_HANDLE(bay, root, "\\_SB.PCI.IDE.SECN.MAST", /* 570 */
"\\_SB.PCI0.IDE0.IDES.IDSM", /* 600e/x, 770e, 770x */
+ "\\_SB.PCI0.IDE0.PRIM.MSTR", /* {T,Z}]6{0,1}[p] */
"\\_SB.PCI0.IDE0.SCND.MSTR", /* all others */
); /* A21e, R30, R31 */
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Date: December 10, 2006
From: Henrique de Moraes Holschuh <hmh-N3TV7GIv+o9fyO9Q7EP/yw@xxxxxxxxxxxxxxxx>
In-reply-to:
<E1GtH0P-0007WV-Q5-mUMCHd/4doTcSu1xaG3OGkB+6BGkLq7r@xxxxxxxxxxxxxxxx>
References:
<E1GtH0P-0007WV-Q5@xxxxxxxxxxxxxxxxxxx>
On Sun, 10 Dec 2006, Theodore Ts'o wrote: > Add Ultrabay Support for the T60p Thinkpad Thanks, an equivalent patch is alredy merged in acpi-test, and waiting a push to linus. BTW: this is an ACK if you want to merge this patch ahead of the stuff in acpi-test. > Ultrabay devices for the T60p Thinkpad; my guess is that it probably > works on T60 Thinkpads and probably more recent Lenovo latops as well. It works on all *60 and *61 new ThinkPads, yes. > have the device appear again. (With the 1.02 BIOS the device does not > function when re-inserted, even after a warm boot; a cold reboot is > required to store the Ultrabay device's functionality.) Nice to know that, thanks. Take a look on the experimental ACPI bay and dock support in acpi-test, it is even better than ibm-acpi's builtin support... and in fact, deprecates it. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Date: December 10, 2006
From: "Theodore Ts'o" <tytso@xxxxxxx>
Add Ultrabay Support for the T60p Thinkpad
The following patch adds support for obtaining the status and ejecting
Ultrabay devices for the T60p Thinkpad; my guess is that it probably
works on T60 Thinkpads and probably more recent Lenovo latops as well.
With the 2.03 BIOS I have been able to eject a SATA drive in an Ultrabay
carrier by using the command:
"echo 1 > /sys/class/scsi_device/1:0:0:0/device/delete"
and upon re-inserting the it back into the device and issuing the
command:
"echo 0 0 0 > /sys/class/scsi_host/host1/scan"
have the device appear again. (With the 1.02 BIOS the device does not
function when re-inserted, even after a warm boot; a cold reboot is
required to store the Ultrabay device's functionality.)
More complicated Ultrabay eject and insert scripts can be found on the
ThinkWiki, although it's important to comment out the "hdparm -Y" as it
apparently doesn't work or do anything, and causes the eject process to
hang for about a minute.
Signed-off-by: "Theodore Ts'o" <tytso@xxxxxxx>
Index: 2.6.19/drivers/acpi/ibm_acpi.c
===================================================================
--- 2.6.19.orig/drivers/acpi/ibm_acpi.c 2006-12-09 18:35:09.000000000 -0500
+++ 2.6.19/drivers/acpi/ibm_acpi.c 2006-12-09 18:35:42.000000000 -0500
@@ -169,6 +169,7 @@
#endif
IBM_HANDLE(bay, root, "\\_SB.PCI.IDE.SECN.MAST", /* 570 */
"\\_SB.PCI0.IDE0.IDES.IDSM", /* 600e/x, 770e, 770x */
+ "\\_SB.PCI0.IDE0.PRIM.MSTR", /* T60p */
"\\_SB.PCI0.IDE0.SCND.MSTR", /* all others */
); /* A21e, R30, R31 */
Date: December 07, 2006
From: Henrique de Moraes Holschuh <hmh@xxxxxxxxxx>
In-reply-to:
<200612070123.25992.len.brown@xxxxxxxxx>
References:
<20061125204155.6604.35338.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <200612070123.25992.len.brown@xxxxxxxxx>
On Thu, 07 Dec 2006, Len Brown wrote: > Henrique, > FYI, A pull of this branch will take everything included underneath it. > In this case, it will take all the contents of acpi-test that this branch is > built upon. > > That is fine for testing, but it isn't a path to upstream b/c > not everything in acpi-test is going to get sent up to Linus at the same time > as ibm-acpi. I was operating under the false idea that the flow should be ibm-acpi-devel -> acpi-test -> linus. > For this batch, I'll just re-parent the series, or re-commit the e-mail > patches. Thanks. > But in the future, if you base your patches directly against some snapshot of > Linus' tree > and don't include anything else besides your changes, then I can pull it > directly. > Of course you can do both by checking your changes in on a branch off of > Linus' > baseline and then merging onto your mirror of acpi-test. In that event I'd > pull from your branch based on Linus' mirror. Will do. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
Date: December 07, 2006
From: Len Brown <len.brown@xxxxxxxxx>
In-reply-to:
<20061125204155.6604.35338.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<20061125204155.6604.35338.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
On Saturday 25 November 2006 15:41, Henrique de Moraes Holschuh wrote: > git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git > for-upstream/acpi-test Henrique, FYI, A pull of this branch will take everything included underneath it. In this case, it will take all the contents of acpi-test that this branch is built upon. That is fine for testing, but it isn't a path to upstream b/c not everything in acpi-test is going to get sent up to Linus at the same time as ibm-acpi. For this batch, I'll just re-parent the series, or re-commit the e-mail patches. But in the future, if you base your patches directly against some snapshot of Linus' tree and don't include anything else besides your changes, then I can pull it directly. Of course you can do both by checking your changes in on a branch off of Linus' baseline and then merging onto your mirror of acpi-test. In that event I'd pull from your branch based on Linus' mirror. thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html