On Wed, 05 Jul 2006, Brown, Len wrote:
We asked Linus to change the name in the Makefile during this period,
but he declined. I'm open to suggestions.
A simple README.txt in the release/ directory which explains this would be
enough, I suppose. Renaming these patches to -2.6.17-git would also
to the old ACPI TMP0-7 mode if anything is amiss.
Userspace ABI is not changed for 8 sensors, but /proc/acpi/ibm/thermal is
extended for 16 sensors if the firmware supports 16 sensors.
A documentation update is also provided.
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Cc: [EMAIL
This teaches dmi_decode() how to decode and save OEM Strings (type 11) DMI
information, which is currently discarded silently. Existing code using
DMI is not affected. Follows the System Management BIOS (SMBIOS)
Specification (http://www.dmtf.org/standards/smbios), and also the
userspace
of the drivers?
Please comment.
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Cc: Borislav Deianov [EMAIL PROTECTED]
Cc: Holger Macht [EMAIL PROTECTED]
Cc: Andy Whitcroft [EMAIL PROTECTED]
Index: 2.6.18/drivers/acpi/ibm_acpi.c
On Mon, 06 Nov 2006, Richard Purdie wrote:
that other devices would have a similar set of constraints (all the
existing users at the time did). On such hardware, deinitialising
anything you initialised is the norm and makes sense but the PC/ACPI
world is different.
Yes, and we don't *init*
There is a bug here in that acpiphp shouldn't even be used on the X60 -
it has no hotpluggable slots.
What about the internal mini PCI express slots (where the Intel 3945ABG
device and EVDO wwwan cards are plugged)?
Also, ThinkWiki lists this machine as one that has a CardBus slot. A
On Mon, 06 Nov 2006, Stefan Seyfried wrote:
On Mon, Nov 06, 2006 at 11:29:03AM -0200, Henrique de Moraes Holschuh wrote:
There is a bug here in that acpiphp shouldn't even be used on the X60
-
it has no hotpluggable slots.
What about the internal mini PCI express slots (where
Hello ibm-acpi users and linux-acpi developers,
In order not to generate too much extra noise in the linux-thinkpad
mailinglist, and to keep driver-specific traffic outside of linux-acpi, I
have created an ibm-acpi-devel mailing list on sourceforge.net.
The URI for the mailman list information
On Mon, 06 Nov 2006, Richard Purdie wrote:
Those commits were designed to standardise several behaviours amongst
several drivers and this specific case was added to the core rather than
coding it in each of several drivers. We therefore really need to update
those other drivers too (locomo at
enough that, apart from typos,
there is little chance of getting them wrong.
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Cc: Richard Purdie [EMAIL PROTECTED]
Cc: Andriy Skulysh [EMAIL PROTECTED]
Cc: Antonino Daplas [EMAIL PROTECTED]
--
diff --git a/drivers/video/backlight/backlight.c
On Sat, 25 Nov 2006, Adrian Bunk wrote:
It also removes a static function of the same name in
drivers/acpi/ibm_acpi.c to ibm_acpi_driver_init() to fix the namespace
collision.
I might as well fix the entire ibm-acpi driver so that it doesn't have any
more issues like this in the future.
I
On Fri, 01 Dec 2006, Pavel Machek wrote:
Looks okay to me. We really want unified interface for backlight.
Then I request some help to get
http://article.gmane.org/gmane.linux.acpi.devel/19792
merged.
Without it, the backlight interface becomes annoying on laptops. Your
screen will be powered
enough that, apart from typos,
there is little chance of getting them wrong.
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Acked-by: Richard Purdie [EMAIL PROTECTED]
Acked-by: Pavel Machek [EMAIL PROTECTED]
---
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight
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
From: Alexey Starikovskiy [EMAIL PROTECTED]
Allow clean removal by setting notify_installed in the right place.
Alexey Starikovskiy [EMAIL PROTECTED]
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Signed-off-by: Len Brown [EMAIL PROTECTED]
---
drivers/acpi/ibm_acpi.c |3
From: Henrique de Moraes Holschuh [EMAIL PROTECTED]
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
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 [EMAIL PROTECTED] is also
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
From: Alexey Starikovskiy [EMAIL PROTECTED]
Allow clean removal by setting notify_installed in the right place.
Alexey Starikovskiy [EMAIL PROTECTED]
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Signed-off-by: Len Brown [EMAIL PROTECTED]
---
drivers/acpi/ibm_acpi.c |3
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
A new one for you, it exists since 2.6.20-rc2.
Subject : ThinkPad removable bay support disabled unconditionally
References : http://marc.theaimsgroup.com/?l=linux-acpim=116750681901208w=2
Caused-By: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Handled-By : Henrique de Moraes
ibm-acpi bay support. This is a serious regression for ThinkPad users.
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
---
drivers/acpi/Kconfig| 11 ---
drivers/acpi/ibm_acpi.c | 13 +
2 files changed, 1 insertions(+), 23 deletions(-)
diff --git a/drivers
On Tue, 16 Jan 2007, Len Brown wrote:
nobody else with a T60 noticed this since November?
It might be a good idea to Cc [EMAIL PROTECTED] when asking
such questions, as it will reach a lot of thinkpad power users that run
Linux. I know a number of people subscribe to both linux-acpi and
On Tue, 23 Jan 2007, Mike Perry wrote:
Is there currently any way to disable busmastering or C3 transitions
(without recompilation)? Or better: is it possible to make the system
less eager to transition into C3 or otherwise reduce the frequency of
these transitions? If I could just get the
On Tue, 23 Jan 2007, Len Brown wrote:
BTW. what model Thinkpad do you have?
I own a ThinkPad T43 with ATI graphics (I wish I had bought one with Intel
graphics, but they only had the crap screens on those), but I don't know if
Mike Perry has a ThinkPad at all. It's just that whatever his laptop
On Tue, 06 Feb 2007, Starikovskiy, Alexey Y wrote:
T43 2668-NG2 BIOS 1.23 EC 1.03
We use the same BIOS (TP-1Y), but you are using a very old version. A lot
might have changed since then, including AHCI support going away. I don't
think I ever run a 1.23 bios on my machine...
And I know for a
or do anything, and causes the eject process to
hang for about a minute.
Signed-off-by: Theodore Ts'o [EMAIL PROTECTED]
Cc: Whoopie [EMAIL PROTECTED]
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
---
drivers/acpi/ibm_acpi.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions
This patch fixes a small memory leak on module removal, and does other
assorted minor cleanups on the module init codepath.
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
---
drivers/acpi/ibm_acpi.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git
On Tue, 06 Feb 2007, Henrique de Moraes Holschuh wrote:
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.SATA.SCND.MSTR, /* T60, X60, Z60, SATA
On Thu, 08 Feb 2007, Alexey Starikovskiy wrote:
first thing to check is timing of acpi_hw_disable_all_gpes() at
drivers/acpi/events/evgpe.c:647,
printk() around it should be good.
Done, and the thing is looping like heck, and wasting time:
Feb 9 00:23:44 thorin kernel: Stopping tasks ...
On Thu, 08 Feb 2007, Starikovskiy, Alexey Y wrote:
Please also try to set acpi_gbl_system_awake_and_running to true in the
same place, if you find that disable_all_gpes() is called not once...
Here's what happens if I acpi_gbl_system_awake_and_running = true; right
after the call to
On Fri, 09 Feb 2007, Len Brown wrote:
resuming our previous discussion on this topic...
I'd rather see nmi watchdog disabled by default.
But if that battle isn't going to be concluded in my natural
life-time, then I'm okay with a workaround for that bug
in the interest of functioning
On Fri, 09 Feb 2007, Len Brown wrote:
Try disconnecting usb devices until lsusb shows nothing.
On some ThinkPads, this means removing uhci_hcd and ehci_hcd, because they
have internal USB devices (bluetooth, fingerprint reader, etc).
--
One disk to rule them all, One disk to find them. One
On Fri, 09 Feb 2007, Matthew Garrett wrote:
On Fri, Feb 09, 2007 at 12:26:22PM -0200, Henrique de Moraes Holschuh wrote:
According to a patch sent to LKML a while ago that blacklisted all ThinkPads
from nmi_watchdog, the ThinkPad SMBIOS does INT 0x10 or something else that
will cause double
On Fri, 09 Feb 2007, Sascha Heid wrote:
Am Freitag, den 09.02.2007, 12:29 -0200 schrieb Henrique de Moraes
Holschuh:
On Fri, 09 Feb 2007, Len Brown wrote:
Try disconnecting usb devices until lsusb shows nothing.
On some ThinkPads, this means removing uhci_hcd and ehci_hcd, because
On Fri, 09 Feb 2007, Pavel Machek wrote:
Not including another /proc/acpi/ibm -like nightmare, is it?
Don't worry, I am already on my way to kill /proc/acpi/ibm... :-)
--
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
On Sat, 10 Feb 2007, Ismail Dönmez wrote:
Hmmf looks like a userspace bug, but it certainly did work before ACPI update.
Well, I don't know if this is the case here, but after reading the userland
code that people use on most applets to read /proc/acpi/ibm, I was upset and
disgusted for days.
On Tue, 13 Feb 2007, Mattia Dongili wrote:
well this is actually hardware driven, the brightness_default in
sony-laptop only exposes a DSDT method to set this value.
So it's actually one more feature, not a software trick :)
I admit the attribute could be better named 'poweron_brightness'.
On Tue, 13 Feb 2007, Mattia Dongili wrote:
On Tue, Feb 13, 2007 at 10:16:59AM -0200, Henrique de Moraes Holschuh wrote:
On Tue, 13 Feb 2007, Mattia Dongili wrote:
well this is actually hardware driven, the brightness_default in
sony-laptop only exposes a DSDT method to set this value
Make ibm-acpi bay support optional at kernel compile time.
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
---
This is very useful for people trying out the new ACPI generic bay driver.
It does NOT conflict with ACPI_BAY on purpose. That is for later, when we
are sure ACPI_BAY
On Wed, 21 Feb 2007, Alexey Starikovskiy wrote:
Pavel Machek wrote:
2) Fix is very disconnected from the problem. Deinitialize mouse so
that fans work after reboot. WTF?
ACPI spec implies that EC controller and PS/2 mouse/keyboards controller
are one entity. So if mouse screws up its
The brightness class core does not update the initial status of
the device's brightness at register time. Do it by ourselves
before we register the class device.
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Cc: Richard Purdie [EMAIL PROTECTED]
---
NOTE: This patch needs an ACK
The brightness class core does not update the initial status of the
device's brightness at register time. Do it by ourselves.
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Cc: Richard Purdie [EMAIL PROTECTED]
---
Waiting ACK from Richard Purdie, applies on top of 2.6.21-rc1
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
From: Henrique de Moraes Holschuh [EMAIL PROTECTED]
ACPI: ibm-acpi: fix initial status of backlight device
The brightness class core does not update the initial status of the
device's brightness at register time. Do
Len,
Please pull from git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
branch for-upstream/acpi-test
to receive the following patches:
ACPI: ibm-acpi: make ibm-acpi bay support optional
ACPI: ibm-acpi: fix initial status of backlight device
The branch is based on 2.6.21-rc1.
--
The brightness class core does not update the initial status of the
device's brightness at register time. Do it by ourselves.
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Acked-by: Richard Purdie [EMAIL PROTECTED]
---
drivers/acpi/ibm_acpi.c | 10 +-
1 files changed, 9
Make ibm-acpi bay support optional at kernel compile time.
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
---
drivers/acpi/Kconfig| 11 +++
drivers/acpi/ibm_acpi.c | 12
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/drivers/acpi
On Fri, 23 Feb 2007, Len Brown wrote:
+config ACPI_IBM_BAY
+ bool Legacy Removable Bay Support
+ depends on ACPI_IBM
+ default y
+ ---help---
+ Allows the ibm_acpi driver to handle removable bays. It will allow
+ disabling the device in the bay, and also
Shuffle code around to better organize the driver code inside the
ibm-acpi.c file.
This patch adds no functional changes. It is pure fluff that will make me
a bit more productive.
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
---
drivers/acpi/ibm_acpi.c | 1382
Add a (private) header file for ibm-acpi, and move type definitions and
ThinkPad driver constants to the new header file.
This patch has no functional changes.
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
---
drivers/acpi/ibm_acpi.c | 136 +---
drivers/acpi
Len,
Please pull from:
git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
branch for-upstream/acpi-test
to receive the following patches:
Henrique de Moraes Holschuh (5):
ACPI: ibm-acpi: rename some identifiers
ACPI: ibm-acpi: add header file
ACPI: ibm-acpi: organize
Update documentation header, and relocate a hunk of text that was missplaced.
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
---
Documentation/ibm-acpi.txt | 85 +---
1 files changed, 25 insertions(+), 60 deletions(-)
diff --git
Rename some identifiers so that they are more in tune with the rest of the
driver code, or less generic.
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
---
drivers/acpi/ibm_acpi.c | 43 ---
1 files changed, 24 insertions(+), 19 deletions
I am working on a conversion of ibm-acpi to sysfs, and in the process I am
trying to do away with every non-generic interface I can. At least two
ibm-acpi interfaces map directly to hwmon/lm-sensors style: fan and thermal.
I'd like to expose them as hwmon attributes, using the hwmon generic
On Mon, 26 Feb 2007, Jean Delvare wrote:
However, some thinkpad thermal sensors are hotswappable (they're inside
battery packs, for example). What is the recommended way to deal with that?
I was planning to return -ENXIO for sensors thare are currently unavailable,
and I could also try
Improve the backlight code to emulate as much as possible the power
management events, as we are unable to really power on or power off the
backlight.
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Acked-by: Richard Purdie [EMAIL PROTECTED]
---
Len, I have added
On Tue, 27 Feb 2007, Jean Delvare wrote:
I don't really have time for such long reads, sorry. If there's
anything in particular you think I should know, just tell me.
Just that the stale value is indeed useful on one particular case.
pwm#_enable = 0 means fan# at full speed, _not_ fan#
(ibm-acpi-devel removed from cc, subject changed)
On Wed, 28 Feb 2007, Zhang Rui wrote:
I'm converting these two modules to sysfs. I think thermal has too
much ACPI specific information and is not that easy to have a generic
interface.
It is not easy. In fact, it could be quite complicated.
On Mon, 26 Feb 2007, Jean Delvare wrote:
I was going to place all fan attributes in a sysfs group (subdirectory)
named fan, and all thermal attributes in a sysfs group named thermal. Is
that acceptable?
No, it's not, as it wouldn't be compatible with what all the other
drivers do and
On Fri, 02 Mar 2007, Jean Delvare wrote:
(And as a side note, this is really the board's owner SMBus controller.
The hardware doesn't belong to the BIOS author.)
Especially when they won't do their job right, and won't fix it later
either...
--
One disk to rule them all, One disk to find
On Fri, 02 Mar 2007, Jean Delvare wrote:
I like the idea, it should work as long as we are guaranteed that all
the hwmon device accesses happen in the AML code? I'm not familiar with
ACPI, so you tell me.
Some fubar machines do it in SMM mode, and the AML code just reads memory
regions that
On Tue, 06 Mar 2007, Kristen Carlson Accardi wrote:
Eliminate bay events on resume if nothing has changed.
Are these *really* useless? What if the *contents* of the bay changed?
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them.
On Wed, 07 Mar 2007, Len Brown wrote:
Anybody got any candidates for a series of transactions that would
benefit from this mode? If yes, is it possible to detect an efficiency
benefit from enabling burst mode for that series?
ibm-acpi would like a lot to have burst-mode for EC dumps (read of
]
commit 994efacdf9a087b52f71e620b58dfa526b0cf928
Handled-By : Jiri Kosina [EMAIL PROTECTED]
Richard Purdie [EMAIL PROTECTED]
Henrique de Moraes Holschuh [EMAIL PROTECTED]
Status : patches are being discussed
The confirmed fix is in the ACPI test branch
On Thu, 08 Mar 2007, Zhang Rui wrote:
First, ACPI thermal zone can be used to set different cooling policies,
i.e. passive cooling mode and active cooling mode.
In passive mode, just as Matthew Garrett described, ACPI thermal may
throttle the CPU if the passive trip point is triggered, i.e.
On Thu, 08 Mar 2007, Len Brown wrote:
Henrique,
If you could refresh this on to of the latest acpi-test,
that would be great. (ibm-acpi changes in acpi-test are
headed for 2.6.21).
These are not 2.6.21 material, I don't want Linus goint postal on either of
us :-)
Please tell me when you
I shall protect the ibm-acpi city against the invasion of the barbarian
blanks! To the unforgiving jaws of sed s/[[:blank:]]\+$// they go!
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
---
Documentation/ibm-acpi.txt |6 +++---
drivers/acpi/ibm_acpi.c|6 +++---
2 files
Len,
Please pull from:
git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
branch for-upstream/acpi-test
to receive the following patches:
ACPI: ibm-acpi: kill trailing whitespace
ACPI: ibm-acpi: rename some identifiers
ACPI: ibm-acpi: add header file
ACPI:
Add a (private) header file for ibm-acpi, and move type definitions and
ThinkPad driver constants to the new header file.
This patch has no functional changes.
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
---
drivers/acpi/ibm_acpi.c | 137 +---
drivers/acpi
On Sun, 11 Mar 2007, Len Brown wrote:
heh, the service window is always open at this restaurant:-)
Nice :-)
seriously, as I use topic branches, I'm happy to accept patches
for future releases sooner than later and they will not get
in the way of the current release.
Ok. I will make sure to
Len,
Please pull from:
git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
branch for-upstream/acpi-test
to receive the following patch, targetted at 2.6.22:
ACPI: ibm-acpi: move driver to drivers/misc hierarchy
Note: the branch I am asking you to pull from is the same branch I
ibm-acpi is not an ACPICA driver, so move it to drivers/misc as per Len
Brown's request.
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
---
drivers/acpi/Kconfig | 37 -
drivers/acpi/Makefile |1 -
drivers/misc
On Thu, 15 Mar 2007, Len Brown wrote:
+config ACPI_IBM_BAY
Should this depend on ACPI_BAY=n?
It should allow both as modules, so that the user can choose which one to
run.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In
On Thu, 15 Mar 2007, Chris Wedgwood wrote:
ACPI_IBM_BAY cannot coexist with ACPI_BAY --- it causes the IBM ACPI
code to fail to initialize so all the IBM ACPI functionality is
missing. The simplest fix is to just make sure the Kconfig magic
disallows ACPI_IBM_BAY when ACPI_BAY is enabled.
On Thu, 15 Mar 2007, Chris Wedgwood wrote:
ACPI_IBM_BAY cannot coexist with ACPI_BAY --- it causes the IBM ACPI
code to fail to initialize so all the IBM ACPI functionality is
missing. The simplest fix is to just make sure the Kconfig magic
disallows ACPI_IBM_BAY when ACPI_BAY is enabled.
On Thu, 15 Mar 2007, Kristen Carlson Accardi wrote:
Doesn't this option enable support for controlling the bay device via
ibm_acpi?
Yes, but the problem is that ACPI_BAY is not nearly good enough in
ThinkPads... yet.
If so - if you compile this one, then the user who chooses to use bay.ko
On Thu, 15 Mar 2007, Kristen Carlson Accardi wrote:
On Thu, 15 Mar 2007 14:55:06 -0300
Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
Please look at the patch I just sent. It allows ibm-acpi to load if
ACPI_BAY is loaded. It will, of course, cause ACPI_BAY to refuse to load
On Thu, 15 Mar 2007, Shem Multinymous wrote:
I'm not sure which stage of the unplug you're referring to, but after
a lever released event on ThinkPads there must remain a way for
userspace code to run before the kernel does anything irreversible to
I mean when one echo 1 eject, so it won't
Kristen,
I just compared ibm-acpi bay stuff with what is in the generic driver.
Here's a initial take of stuff to do:
1. The generic driver only handles hotplug bays (_EJ0). I'd like to also
handle warm/coldplug bays (_EJ3).
Warm/coldplug bays are available on ThinkPads model 600e/x, A2Xm/p,
This patch allows for ibm-acpi to coexist (with diminished functionality) with
other drivers like ACPI_BAY. ibm-acpi will simply disable the functions it is
not able to register ACPI notifiers for.
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Cc: Chris Wedgwood [EMAIL PROTECTED
This patch allows for ibm-acpi to coexist (with diminished functionality) with
other drivers like ACPI_BAY. ibm-acpi will simply disable the functions it is
not able to register ACPI notifiers for.
Signed-off-by: Henrique de Moraes Holschuh [EMAIL PROTECTED]
Cc: Chris Wedgwood [EMAIL PROTECTED
On Thu, 15 Mar 2007, Chris Wedgwood wrote:
On Thu, Mar 15, 2007 at 02:51:14PM -0300, Henrique de Moraes Holschuh wrote:
This patch allows for ibm-acpi to coexist (with diminished
functionality) with other drivers like ACPI_BAY.
Given the ACP_IBM_BAY implementation is more complete
On Thu, 15 Mar 2007, Kristen Carlson Accardi wrote:
this patch gives me the following compile error:
drivers/acpi/ibm_acpi.c: In function ???ibm_init???:
drivers/acpi/ibm_acpi.c:2605: warning: implicit declaration of function
???ibm_exit???
drivers/acpi/ibm_acpi.c: At top level:
On Thu, 15 Mar 2007, Kristen Carlson Accardi wrote:
I haven't followed the ibm_acpi development lately, but when I first
wrote the bay driver, it had a couple features that ibm_acpi didn't have,
and then of course, is missing some it does have. What used to be the
case is that if bay was
On Thu, 15 Mar 2007, Henrique de Moraes Holschuh wrote:
3. is_ejectable_bay is too simple-minded. It could work for batteries, if it
didn't try so hard to detect only sata/ata devices as bays. Maybe it can be
changed to try to detect anything that can be ejected and which is not a
dock
On Sun, 18 Mar 2007, Tejun Heo wrote:
Kristen Carlson Accardi wrote:
1. It will handle all device types (ATAPI, PATA, SATA, batteries);
2. It will do the right thing on plug and unplug. This means telling the
rest of the kernel to disable the device in the bay, for example. Right
now
On Sun, 18 Mar 2007, Holger Macht wrote:
those ThinkPads where it is needed. Afterwards it does the corresponding
dock/undock request on ibm_acpi. And this works reliably good what I can
see from the feedback I already got. But for this to work, userspace would
It should work with the generic
On Sun, 18 Mar 2007, Holger Macht wrote:
It doesn't work, I've already tried. The bay driver only emits an event if
you really try to remove the bay, but not on docking/undocking.
Ah, now I understand what you mean.
Looks like we really need the dock driver to sort of like act as a bus.
--
On Mon, 19 Mar 2007, Kristen Carlson Accardi wrote:
On Mon, 19 Mar 2007 15:37:46 +0100
Holger Macht [EMAIL PROTECTED] wrote:
Sure. What actually bothers me is that in its current state, the dock
station driver signals 'green' on the dock station as soon as the user
presses the hardware
On Mon, 19 Mar 2007, Theodore Tso wrote:
One more thing I would add from a power management perspective. It
should be able to powerdown the bay cleanly on suspend-to-ram, without
necessarily disconnecting libata or unmounting the filesystem.
The disconnect-or-not needs to be
On Mon, 19 Mar 2007, Kristen Carlson Accardi wrote:
It should work with the generic bay device too, but I have no ideas about
dock. But you'll need to deal with udev with the new bay device, something
I am not too happy about. These things are ACPI events, they should remain
so unless
On Mon, 19 Mar 2007, Kristen Carlson Accardi wrote:
Is this what you had in mind? (Warning - I didn't test this).
Allow the driver to be loaded with an option that will allow userspace to
control whether the laptop is ejected immediately when the user presses the
button, or only when the
On Mon, 19 Mar 2007, Kristen Carlson Accardi wrote:
Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
So the first step is to improve is_ejectable_bay. What reason did you have
to limit it only to devices where is_ata returns true? Is there a reason
why anything that is not a dock
On Mon, 19 Mar 2007, Shem Multinymous wrote:
Userspace wants to (non-force-)-unmount by itself after (1), so it can
stop the eject process if the filesystems cannot be cleanly
unmounted. So the force-unmount at (3) ends up being a redundant
safety measure at best.
More like it is a make sure
On Tue, 20 Mar 2007, Alexey Starikovskiy wrote:
So either make it just a printk (KERN_INFO) at init time or drop it
completely.
A printk might be useful for debugging...
--
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
On Tue, 20 Mar 2007, Zhang Rui wrote:
Add sysfs interface for ACPI devices.
While doing the ibm-acpi sysfs work (not submitted yet), I have found I need
something like this to properly parse simple ulongs from sysfs:
static int parse_strtoul(const char *buf,
unsigned long max,
On Tue, 20 Mar 2007, Theodore Tso wrote:
The disconnect-or-not needs to be user-configurable, as the user may well
swap devices in the bay while the system is sleeping, AND this is supposed
to be a valid thing to do from a usercase PoV (earlier ThinkPad laptops only
had warm-swap bays, for
On Tue, 20 Mar 2007, Theodore Tso wrote:
On Tue, Mar 20, 2007 at 12:14:43PM -0300, Henrique de Moraes Holschuh wrote:
Maybe, but then the suspend mail have to fail if there are processes
that are keeping the filesystem from being unmounted. Or the
Yes. But this is standard
On Wed, 21 Mar 2007, Zhang Rui wrote:
On Tue, 2007-03-20 at 12:31 -0300, Henrique de Moraes Holschuh wrote:
On Tue, 20 Mar 2007, Zhang Rui wrote:
Add sysfs interface for ACPI devices.
While doing the ibm-acpi sysfs work (not submitted yet), I have found I need
something like
On Thu, 22 Mar 2007, Len Brown wrote:
On Tuesday 20 March 2007 05:21, Zhang Rui wrote:
From: Zhang Rui [EMAIL PROTECTED]
Add ACPI Fan device sysfs interface.
Attribute ModeDescription
state RW Fan state.
0: Fan is in D0 state(on).
1 - 100 of 514 matches
Mail list logo
