From: Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>
To: Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>
Cc: linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH 3/4] usb: Bind devices to ACPI devices when possible
Date: Mon, 12 Mar 2012 20:56:16 +0000 [thread overview]
Message-ID: <20120312205616.GB22929@srcf.ucam.org> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1203121631230.1216-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
On Mon, Mar 12, 2012 at 04:38:57PM -0400, Alan Stern wrote:
> On Mon, 12 Mar 2012, Matthew Garrett wrote:
>
> > Built-in USB devices will typically have a representation in the system
> > ACPI tables. Add support for binding the two together so the USB code can
> > make use of the associated methods.
>
> > +static int usb_acpi_find_device(struct device *dev, acpi_handle *handle)
> > +{
> > + struct usb_device *udev = to_usb_device(dev);
> > + struct device *parent = dev->parent;
> > + acpi_handle *parent_handle = DEVICE_ACPI_HANDLE(parent);
> > +
> > + if (!parent_handle)
> > + return -ENODEV;
> > +
> > + *handle = acpi_get_child(parent_handle, udev->portnum);
> > +
> > + if (!*handle)
> > + return -ENODEV;
> > +
> > + return 0;
> > +}
> > +
> > +static struct acpi_bus_type usb_acpi_bus = {
> > + .bus = &usb_bus_type,
> > + .find_bridge = NULL,
> > + .find_device = usb_acpi_find_device,
> > +};
>
> I don't understand exactly how this is supposed to work. Does this
> mean that the ACPI core will call usb_acpi_find_device() for every ACPI
> device whose underlying real device is registered on the usb_bus_type?
> If so, when does this call take place?
Kind of? platform_notify gets called whenever a device is registered,
and on ACPi systems that'll be acpi_platform_notify. It'll take the
registered device and, if there are glue functions for that bus type,
pass it to the callback functions. The idea is that we have two
disparate device trees, the Linux one and the ACPI one. This just gives
us an opportunity to glue some of the devices together.
> Or does it work some other way?
>
> Bear in mind that USB devices aren't the only things registered with
> usb_bus_type. We also register device structures representing USB
> interfaces and endpoints. Hence the to_usb_device() call above might
> not always do what you want.
Ugh. Is there any clean way to distinguish from the device structure? If
not, the easiest would seem to be to just add another bus type
structure, even if the members are identical.
--
Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-03-12 20:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-12 23:58 [PATCH 1/4] ACPI: Fix up _PLD methods Matthew Garrett
2012-03-12 20:17 ` Greg KH
2012-03-12 20:27 ` Matthew Garrett
2012-03-12 23:58 ` [PATCH 2/4] ACPI: Add _PLD support Matthew Garrett
2012-03-12 23:58 ` [PATCH 3/4] usb: Bind devices to ACPI devices when possible Matthew Garrett
2012-03-12 20:38 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.1203121631230.1216-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2012-03-12 20:56 ` Matthew Garrett [this message]
2012-03-12 21:03 ` Alan Stern
[not found] ` <Pine.LNX.4.44L0.1203121702000.1216-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
2012-03-12 21:12 ` Matthew Garrett
2012-03-12 23:58 ` [PATCH 4/4] usb: Set device removable state based on ACPI USB data Matthew Garrett
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=20120312205616.GB22929@srcf.ucam.org \
--to=mjg59-1xo5oi07kqx4cg9nei1l7q@public.gmane.org \
--cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
--cc=lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox