All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
To: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Valdis.Kletnieks@vt.edu, Lin Ming <ming.m.lin@intel.com>,
	Hugh Dickins <hugh.dickins@tiscali.co.uk>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"lenb@kernel.org" <lenb@kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: [patch 9/9] acpi: fix NULL bug for HID/UID string
Date: Sat, 15 Aug 2009 16:14:22 +0200	[thread overview]
Message-ID: <200908151614.22326.bzolnier@gmail.com> (raw)
In-Reply-To: <200908141410.53840.bjorn.helgaas@hp.com>

On Friday 14 August 2009 22:10:53 Bjorn Helgaas wrote:
> On Friday 14 August 2009 01:53:40 pm Valdis.Kletnieks@vt.edu wrote:
> > On Fri, 14 Aug 2009 10:44:50 MDT, Bjorn Helgaas said:
> > 
> > > I don't quite understand how this oops happens, though.  It seems that
> > > we crashed in this path:
> > > 
> > >   acpi_device_probe
> > >     acpi_bus_driver_init
> > >       driver->ops.add  (calls acpi_video_bus_add)
> > >     acpi_device_install_notify_handler
> > >       hid = acpi_device_hid(device)
> > >       strcmp(hid, ACPI_BUTTON_HID_POWERF))
> > >         *** OOPS, hid == NULL ***
> > > 
> > > But the acpi_video_bus driver claims devices using ACPI_VIDEO_HID
> > > ("LNXVIDEO"), and acpi_device_set_id() already does synthesize
> > > that HID, so acpi_device_hid() should have been valid.  So why
> > > did we oops?
> > 
> > When I tripped over it, acpi_device_set_id() *wasn't* synthesizing an HID,
> > it was explicitly setting a NULL pointer.
> 
> What I don't understand is why the acpi_video_bus driver could get
> bound to the device if the device didn't have a HID.

This was also puzzling me while I hit the original issue so I did some more
research at that time and it turned out that binding is not controlled by
HID but by ->ops.add method of ACPI driver.

In the case of ACPI video driver it goes like that (for 2.6.31-rc6):

acpi_device_probe()
  acpi_bus_driver_init()
    driver->ops.add() [ acpi_video_bus_add() ]
      acpi_video_bus_check()

and in acpi_video_bus_check() we have:

...
	/* Since there is no HID, CID and so on for VGA driver, we have
	 * to check well known required nodes.
	 */

	/* Does this device support video switching? */
	if (video->cap._DOS) {
		video->flags.multihead = 1;
		status = 0;
	}

	/* Does this device support retrieving a video ROM? */
	if (video->cap._ROM) {
		video->flags.rom = 1;
		status = 0;
	}

	/* Does this device support configuring which video device to POST? */
	if (video->cap._GPD && video->cap._SPD && video->cap._VPO) {
		video->flags.post = 1;
		status = 0;
	}

	return status;
...

IOW HID is not required at all for ACPI device drivers at the moment which
becomes a problem after "ACPICA: Major update for acpi_get_object_info
external interface" commit since acpi_device_hid() will no longer return
a pointer to an empty static buffer but a NULL instead..

I think that ideally we should always have a valid HID for ACPI devices
(synthesized in case of ACPI video and similar devices) in the long-term
but could we get Hugh's patch applied for now, please?

While your patch also looks valid and most likely fixes ACPI video oops
Hugh's patch is still needed for fully fixing the problem at the moment
(i.e. ACPI button driver seems to need it).

This problem has been in ACPI tree (and thus in -next) for way too long
already (three weeks with the known fix) and the current situation is not
moving things forward (we have just people rediscovering the issue the
hard way)..

Thanks,
Bart

  reply	other threads:[~2009-08-15 14:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-06 22:57 [patch 9/9] acpi: fix NULL bug for HID/UID string akpm
2009-08-06 23:18 ` Hugh Dickins
2009-08-13 15:55   ` Bjorn Helgaas
2009-08-13 16:46     ` Hugh Dickins
2009-08-14  1:28       ` Lin Ming
2009-08-14 16:44         ` Bjorn Helgaas
2009-08-14 18:18           ` Hugh Dickins
2009-08-14 20:08             ` Bjorn Helgaas
2009-08-14 20:36               ` Hugh Dickins
2009-08-14 19:53           ` Valdis.Kletnieks
2009-08-14 20:10             ` Bjorn Helgaas
2009-08-15 14:14               ` Bartlomiej Zolnierkiewicz [this message]
2009-08-17 17:44                 ` Bjorn Helgaas
2009-09-01  1:41   ` Len Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200908151614.22326.bzolnier@gmail.com \
    --to=bzolnier@gmail.com \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=akpm@linux-foundation.org \
    --cc=bjorn.helgaas@hp.com \
    --cc=hugh.dickins@tiscali.co.uk \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=ming.m.lin@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.