On Tuesday, February 26, 2013 11:02:56 AM Yasuaki Ishimatsu wrote:
> 2013/02/26 10:09, Toshi Kani wrote:
> > On Tue, 2013-02-26 at 09:40 +0900, Yasuaki Ishimatsu wrote:
> >> 2013/02/26 8:39, Rafael J. Wysocki wrote:
> >>> On Monday, February 25, 2013 11:07:52 AM Toshi Kani wrote:
> >>>> On Sat, 2013-02-23 at 22:38 +0000, Rafael J. Wysocki wrote:
> >>>>> From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> >>>>>
> >>>>> Multiple drivers handling hotplug-capable ACPI device nodes install
> >>>>> notify handlers covering the same types of events in a very similar
> >>>>> way. Moreover, those handlers are installed in separate namespace
> >>>>> walks, although that really should be done during namespace scans
> >>>>> carried out by acpi_bus_scan(). This leads to substantial code
> >>>>> duplication, unnecessary overhead and behavior that is hard to
> >>>>> follow.
> >>>>>
> >>>>> For this reason, introduce common code in drivers/acpi/scan.c for
> >>>>> handling hotplug-related notification and carrying out device
> >>>>> insertion and eject operations in a generic fashion, such that it
> >>>>> may be used by all of the relevant drivers in the future. To cover
> >>>>> the existing differences between those drivers introduce struct
> >>>>> acpi_hotplug_profile for representing collections of hotplug
> >>>>> settings associated with different ACPI scan handlers that can be
> >>>>> used by the drivers to make the common code reflect their current
> >>>>> behavior.
> >>>>>
> >>>>> Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> >>>>> ---
> >>>>>
> >>>>> This update causes acpi_bus_device_eject() to only emit KOBJ_OFFLINE
> >>>>> uevent if
> >>>>> autoexec is unset for the given scan handler.
> >>>>>
> >>>>> This will require the doc in patch [5/7] to be updated which I'm going
> >>>>> to do if
> >>>>> everyone is OK with the $subject patch.
> >>>>>
> >>>>> Thanks,
> >>>>> Rafael
> >>>> :
> >>>>> +
> >>>>> +static void acpi_scan_bus_device_check(acpi_handle handle, u32
> >>>>> ost_source)
> >>>>> +{
> >>>>> + struct acpi_device *device = NULL;
> >>>>> + u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE;
> >>>>> + int error;
> >>>>> +
> >>>>> + mutex_lock(&acpi_scan_lock);
> >>>>> +
> >>>>> + acpi_bus_get_device(handle, &device);
> >>>>> + if (device) {
> >>>>> + dev_warn(&device->dev, "Attempt to re-insert\n");
> >>>>> + goto out;
> >>>>> + }
> >>>>> + acpi_evaluate_hotplug_ost(handle, ost_source,
> >>>>> + ACPI_OST_SC_INSERT_IN_PROGRESS, NULL);
> >>>>> + error = acpi_bus_scan(handle);
> >>>>> + if (error) {
> >>>>> + acpi_handle_warn(handle, "Namespace scan failure\n");
> >>>>> + goto out;
> >>>>> + }
> >>>>> + error = acpi_bus_get_device(handle, &device);
> >>>>> + if (error) {
> >>>>> + acpi_handle_warn(handle, "Missing device node
> >>>>> object\n");
> >>>>> + goto out;
> >>>>> + }
> >>>>> + ost_code = ACPI_OST_SC_SUCCESS;
> >>>>> + if (device->handler && device->handler->hotplug.uevents)
> >>>>> + kobject_uevent(&device->dev.kobj, KOBJ_ONLINE);
> >>>>
> >>
> >>>> I confirmed that the uevent crash issue was solved. Thinking further, I
> >>>> wonder if we need to emit KOBJ_ONLINE here. This behavior is asymmetric
> >>>> since we do not emit KOBJ_OFFLINE when autoeject is set.
> >>>
> >>> Well, I put that in there only to be able to make the container driver
> >>> behave
> >>> in a backwards compatible way (which is to emit KOBJ_ONLINE at this
> >>> point).
> >>>
> >>> If the container driver doesn't need to emit KOBJ_ONLINE at all, I agree
> >>> with
> >>> your suggestion.
> >>>
> >>>> The definition of ONLINE/OFFLINE event to an ACPI device object seems
> >>>> also
> >>>> bogus since there is no online/offline operation to the ACPI device
> >>>> object
> >>>> itself.
> >>>> Online/offline operation is only possible to actual device, such as
> >>>> system/cpu/cpu% and system/memory/memory%.
> >>>
> >>> That's correct, but I don't know what the user space expectations are
> >>> currently.
> >>
> >> My system expects this event to be notified when hot adding container
> >> device.
> >> My container device has cpu and memory. As Toshi said, these devices are
> >> offline when hot adding container device. So in my system, when notifying
> >> container device's KOBJ_ONLINE event, my application runs for onlining
> >> these
> >> devices. If this event is not notified to user land, we cannot online these
> >> devices automatically.
> >
>
> > Thanks for the info. Can your application listen KOBJ_ADD to a
> > container device, instead of KOBJ_ONLINE? IOW, does it distinguish
> > between ADD and ONLINE events to a container device?
>
> My application does not distinguish between ADD and ONLINE events
> currently. But if the event is changed from ONLINE to ADD, I will
> change my application.
KOBJ_ADD is emitted for every struct acpi_device being registered, including
container devices, by acpi_device_add_finalize(). Can your application listen
to those events?
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
