Molly Shaffer | 1 Oct 07:42 2009
Picon

As long as it stays unsaid

Rely on this to make your intimate life happier! http://mrityp.noznicichef.com/

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Ingo Molnar | 1 Oct 11:57 2009
Picon
Picon

Re: [origin tree build failure] [PATCH] thinkpad-acpi: Fix build on !CONFIG_THINKPAD_ACPI_HOTKEY_POLL


* Henrique de Moraes Holschuh <hmh <at> hmh.eng.br> wrote:

> On Mon, 28 Sep 2009, Ingo Molnar wrote:
> > * Len Brown <lenb <at> kernel.org> wrote:
> > > > > >  drivers/platform/x86/thinkpad_acpi.c    |  632 +++++++++++++++++++---------
> > > > > 
> > > > > -tip testing found that these changes caused a build failure 
> > > > > in drivers/platform/x86/thinkpad_acpi.c when 
> > > > > !CONFIG_THINKPAD_ACPI_HOTKEY_POLL - the fix is attached  below.
> > > > 
> > > > Fixed by a different patch, which will hit mainline soon....
> > > 
> > > Ingo,
> > > 2.6.32-rc1 should build fine* -- let me know if it doesn't.
> > > 
> > > thanks,
> > > Len Brown, Intel Open Source Technology Center
> > > 
> > > * module this message, which Henruque assures me will go away soon
> > > drivers/platform/x86/thinkpad_acpi.c:2225: warning: 
> > > ???tpacpi_hotkey_driver_mask_set??? defined but not used
> > 
> > well, the warning is fixed properly in my patch, as pointed out in the 
> > changelog. Have you read that?
> 
> Your patch will break the driver when the functionality that uses 
> tpacpi_hotkey_driver_mask_set() lands in mainline.  That functionality 
> is already in a subsystem tree waiting a push to Linus.
> 
(Continue reading)

Dmitry Torokhov | 1 Oct 18:38 2009
Picon

Re: [PATCH] cmpc_acpi: Added support for Classmate PC ACPI devices.

On Tue, Sep 29, 2009 at 05:41:42PM +0100, Alan Jenkins wrote:
> On 9/29/09, Thadeu Lima de Souza Cascardo <cascardo <at> holoscopio.com> wrote:
> 
> >> > +static void cmpc_tablet_idev_init(struct input_dev *inputdev)
> >> > +{
> >> > +	set_bit(EV_SW, inputdev->evbit);
> >> > +	set_bit(SW_TABLET_MODE, inputdev->swbit);
> >>
> >> Don't you need to initialize the switch value here?
> >>
> >
> > No, input_allocate_device does kzalloc. Otherwise, this would apply to
> > the other bitmaps as well.
> 
> The other bitmaps aren't for switches though.  Here's what prompted
> this comment - a snippet from the old (2.6.29) version of
> Documentation/rfkill.txt:
> 
> "2. Input device switches (sources of EV_SW events) DO store their current state
> (so you *must* initialize it by issuing a gratuitous input layer event on
> driver start-up and also when resuming from sleep), and that state CAN be
> queried from userspace through IOCTLs."
> 

There is a mixup betweeb capabilieies and state bitmasks. In init you
set up the capabilitis bits and you don't need to clear bitmaps. This is
true for everything - keys/buttons, switches, relatixe/absolute axis,
everything.

Now switches do naturally have a certain state. Unlke keys (which are
(Continue reading)

Alex Chiang | 1 Oct 19:59 2009
Picon

[PATCH, trivial] ACPI: dock: fix "sibiling" typo

Crossword clues as haikus:

	Snakes from the same brood
	fighting Jackson on a plane?
	sibilant siblings

I guess Will Shortz's job is still secure.

Signed-off-by: Alex Chiang <achiang <at> hp.com>
---
diff --git a/drivers/acpi/dock.c b/drivers/acpi/dock.c
index 3a2cfef..7338b6a 100644
--- a/drivers/acpi/dock.c
+++ b/drivers/acpi/dock.c
 <at>  <at>  -67,7 +67,7  <at>  <at>  struct dock_station {
 	struct list_head dependent_devices;
 	struct list_head hotplug_devices;

-	struct list_head sibiling;
+	struct list_head sibling;
 	struct platform_device *dock_device;
 };
 static LIST_HEAD(dock_stations);
 <at>  <at>  -275,7 +275,7  <at>  <at>  int is_dock_device(acpi_handle handle)

 	if (is_dock(handle))
 		return 1;
-	list_for_each_entry(dock_station, &dock_stations, sibiling) {
+	list_for_each_entry(dock_station, &dock_stations, sibling) {
 		if (find_dock_dependent_device(dock_station, handle))
(Continue reading)

Alex Chiang | 1 Oct 22:05 2009
Picon

Re: [PATCH] acpi: pci_root: fix NULL pointer deref after resume from suspend

Hi Danny,

* Danny Feng <dfeng <at> redhat.com>:
> Call Trace:
>  [<ffffffff81254193>] acpi_get_pci_dev+0x106/0x167
>  [<ffffffff8125545a>] acpi_pci_bind+0x1c/0x86
>  [<ffffffff8116230a>] ? sysfs_create_file+0x2a/0x2c
>  [<ffffffff8125141f>] acpi_add_single_object+0x964/0xa0c
>  [<ffffffff812515a7>] acpi_bus_check_add+0xe0/0x138
>  [<ffffffff81251667>] acpi_bus_scan+0x68/0xa0
>  [<ffffffff812516f4>] acpi_bus_add+0x2a/0x2e
>  [<ffffffff81252c59>] hotplug_dock_devices+0x114/0x13e
>  [<ffffffff8125301a>] acpi_dock_deferred_cb+0xbf/0x192
>  [<ffffffff8124d6ca>] acpi_os_execute_deferred+0x29/0x36
>  [<ffffffff8106a244>] worker_thread+0x251/0x347
>  [<ffffffff8106a1ef>] ? worker_thread+0x1fc/0x347
>  [<ffffffff8124d6a1>] ? acpi_os_execute_deferred+0x0/0x36
>  [<ffffffff8106e426>] ? autoremove_wake_function+0x0/0x39
>  [<ffffffff81069ff3>] ? worker_thread+0x0/0x347
>  [<ffffffff8106e0e0>] kthread+0x7f/0x87
>  [<ffffffff81012cea>] child_rip+0xa/0x20
>  [<ffffffff81012650>] ? restore_args+0x0/0x30
>  [<ffffffff8106e061>] ? kthread+0x0/0x87
>  [<ffffffff81012ce0>] ? child_rip+0x0/0x20
> Code: ff 49 89 fc 41 89 f5 a9 00 ff ff 07 74 11 be 87 00 00 00 48 c7 c7  
> 45 6d 5a 81 e8 f6 2b e3 ff 48 c7 c7 30 ab 68 81 e8 29 77 20 00 <49> 8b  
> 5c 24 28 49 83 c4 28 eb 09 44 39 6b 38 74 10 48 89 c3 48
> RIP  [<ffffffff812217e7>] pci_get_slot+0x4c/0x8c
>  RSP <ffff88022ee69aa0>
> CR2: 0000000000000028
(Continue reading)

Rafael J. Wysocki | 1 Oct 21:26 2009
Picon

2.6.32-rc1-git2: Reported regressions from 2.6.31

[Notes:

 * Here's the first summary report of known regressions from 2.6.31.  There's
   not too many of them at the moment, which is nice.

 * We're still getting quite a number of reports of regressions from 2.6.30 and
   it's been that way since 2.6.31 was released.  For details please see the
   summary report of regressions 2.6.30 -> 2.6.31 that will follow shortly.]

This message contains a list of some regressions from 2.6.31, for which there
are no fixes in the mainline I know of.  If any of them have been fixed already,
please let me know.

If you know of any other unresolved regressions from 2.6.31, please let me know
either and I'll add them to the list.  Also, please let me know if any of the
entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.

Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2009-10-02       22       15           9

Unresolved regressions
----------------------

(Continue reading)

James Bottomley | 2 Oct 00:48 2009
Picon

Re: 2.6.32-rc1-git2: Reported regressions from 2.6.31

On Thu, 2009-10-01 at 21:26 +0200, Rafael J. Wysocki wrote:
> Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=14214
> Subject         : BUG at drivers/scsi/scsi_lib.c:1108!
> Submitter       : Plamen Petrov <pvp-lsts@...>
> Date            : 2009-09-23 11:13 (9 days old)

This one is fixed (as confirmed by the bug report).

James

Arjan van de Ven | 2 Oct 00:51 2009

[PATCH] acpi: clean up video.c boundary checks and types

From 1e96af755961a028c888ba9e49c1d4c17c8a4442 Mon Sep 17 00:00:00 2001
From: Arjan van de Ven <arjan <at> linux.intel.com>
Date: Thu, 1 Oct 2009 15:48:40 -0700
Subject: [PATCH] acpi: clean up video.c boundary checks and types

proc.c and video.c are a bit sloppy around types and style,
confusing gcc for a new feature that'll be in 2.6.33 and will
cause a warning on the current code.

This patch changes

if  (foo + 1 > sizeof bar)

into

if (foo >= sizeof(bar))

which is more kernel-style.

it also changes a variable in proc.c to unsigned; it gets assigned
a value from an unsigned type, and is then only compared for > not
for negative, so using unsigned is just outright the right type

Signed-off-by: Arjan van de Ven <arjan <at> linux.intel.com>
---
 drivers/acpi/proc.c  |    2 +-
 drivers/acpi/video.c |    8 ++++----
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/proc.c b/drivers/acpi/proc.c
(Continue reading)

Alexey Starikovskiy | 2 Oct 00:53 2009
Picon

[PATCH] ACPI: EC: Restart command even if no interrupts from EC

EC may forget a command without sending any "reset" interrupt,
thus we need to lessen the requirement for transaction restart.

Reference: http://bugzilla.kernel.org/show_bug.cgi?id=14247
Signed-off-by: Alexey Starikovskiy <astarikovskiy <at> suse.de>
---

 drivers/acpi/ec.c |    4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index da7da37..9c34515 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
 <at>  <at>  -234,10 +234,8  <at>  <at>  static int ec_poll(struct acpi_ec *ec)
 			}
 			advance_transaction(ec, acpi_ec_read_status(ec));
 		} while (time_before(jiffies, delay));
-		if (!ec->curr->irq_count ||
-		    (acpi_ec_read_status(ec) & ACPI_EC_FLAG_IBF))
+		if (acpi_ec_read_status(ec) & ACPI_EC_FLAG_IBF)
 			break;
-		/* try restart command if we get any false interrupts */
 		pr_debug(PREFIX "controller reset, restart transaction\n");
 		spin_lock_irqsave(&ec->curr_lock, flags);
 		start_transaction(ec);

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Rafael J. Wysocki | 1 Oct 21:53 2009
Picon

2.6.32-rc1-git2: Reported regressions 2.6.30 -> 2.6.31

[Notes:

 * Quite a number of new regressions from 2.6.30 has been reported during
   the last three weeks.

 * The number of unresolved regressions 2.6.30 -> 2.6.31 is now the second
   highest ever.]

This message contains a list of some regressions introduced between 2.6.30 and
2.6.31, for which there are no fixes in the mainline I know of.  If any of them
have been fixed already, please let me know.

If you know of any other unresolved regressions introduced between 2.6.30
and 2.6.31, please let me know either and I'll add them to the list.
Also, please let me know if any of the entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.

Listed regressions statistics:

  Date          Total  Pending  Unresolved
  ----------------------------------------
  2009-10-02      151       49          42
  2009-09-06      123       34          27
  2009-08-26      108       33          26
  2009-08-20      102       32          29
  2009-08-10       89       27          24
  2009-08-02       76       36          28
(Continue reading)


Gmane