Hi Rafael,
Thanks for reviewing! My comments are in-line.
On Sat, 2012-11-24 at 23:01 +0100, Rafael J. Wysocki wrote:
> On Thursday, November 08, 2012 01:23:44 PM Toshi Kani wrote:
> > Added a new .sys_notify interface, which allows ACPI drivers to
> > register their system-lev
On Sat, 2012-11-24 at 23:37 +0100, Rafael J. Wysocki wrote:
> On Saturday, November 24, 2012 11:01:56 PM Rafael J. Wysocki wrote:
> > On Thursday, November 08, 2012 01:23:44 PM Toshi Kani wrote:
> > > Added a new .sys_notify interface, which allows ACPI drivers to
> > >
> > > {
> > > - struct acpi_device *device = NULL;
> > > - struct acpi_driver *driver;
> > > -
> > > ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Notification %#02x to handle %p\n",
> > > type, handle));
> > >
> > > - blocking_notifier_call_chain(&acpi_bus_notify_list,
> > > -
On Mon, 2012-11-26 at 21:44 +0100, Rafael J. Wysocki wrote:
> On Monday, November 26, 2012 12:06:39 PM Toshi Kani wrote:
> > On Sat, 2012-11-24 at 23:37 +0100, Rafael J. Wysocki wrote:
> > > On Saturday, November 24, 2012 11:01:56 PM Rafael J. Wysocki wrote:
> > > >
On Mon, 2012-11-26 at 14:09 -0700, Toshi Kani wrote:
> On Mon, 2012-11-26 at 21:44 +0100, Rafael J. Wysocki wrote:
> > On Monday, November 26, 2012 12:06:39 PM Toshi Kani wrote:
> > > On Sat, 2012-11-24 at 23:37 +0100, Rafael J. Wysocki wrote:
> > > > On Saturday,
On Fri, 2012-11-23 at 18:50 +0100, Vasilis Liaskovitis wrote:
> This function should be registered for devices that need to execute some
> non-acpi related action in order to be safely removed. If this function
> returns zero, the acpi core can continue with removing the device.
>
> Make acpi_bus_
> >> Consider the following sequence of operations for a hotplugged memory
> >> device:
> >>
> >> 1. echo "PNP0C80:XX" > /sys/bus/acpi/drivers/acpi_memhotplug/unbind
> >> 2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
> >>
> >> If we don't offline/remove the memory, we have no chance to do it in
On Tue, 2012-11-27 at 19:32 +0100, Vasilis Liaskovitis wrote:
> On Mon, Nov 26, 2012 at 05:19:01PM -0700, Toshi Kani wrote:
> > > >> Consider the following sequence of operations for a hotplugged memory
> > > >> device:
> > > >>
> > > >&g
On Wed, 2012-11-28 at 00:41 +0100, Rafael J. Wysocki wrote:
> On Tuesday, November 27, 2012 03:03:47 PM Toshi Kani wrote:
> > On Tue, 2012-11-27 at 19:32 +0100, Vasilis Liaskovitis wrote:
> > > On Mon, Nov 26, 2012 at 05:19:01PM -0700, Toshi Kani wrote:
> > > > > &
On Wed, 2012-11-28 at 01:29 +0100, Rafael J. Wysocki wrote:
> On Monday, November 26, 2012 10:44:08 AM Toshi Kani wrote:
> > Hi Rafael,
> >
> > Thanks for reviewing! My comments are in-line.
> >
> > On Sat, 2012-11-24 at 23:01 +0100, Rafael J. Wysocki wrote:
>
> > > > > By using acpi_install_notify_handler(), each driver needs to walk
> > > > > through the entire ACPI namespace to find its associated ACPI devices
> > > > > and call it to register one by one. I think this is more work for
> > > > > non-ACPI drivers than defining acpi_driver.
> > > >
> >
On Wed, 2012-11-28 at 19:05 +0800, Hanjun Guo wrote:
> On 2012/11/24 1:50, Vasilis Liaskovitis wrote:
> > As discussed in https://patchwork.kernel.org/patch/1581581/
> > the driver core remove function needs to always succeed. This means we need
> > to know that the device can be successfully remov
On Wed, 2012-11-28 at 19:28 +0100, Rafael J. Wysocki wrote:
> On Wednesday, November 28, 2012 09:54:43 AM Toshi Kani wrote:
> > > > > > > By using acpi_install_notify_handler(), each driver needs to walk
> > > > > > > through the enti
> > > > > > > Consider the following case:
> > > > > > >
> > > > > > > We hotremove the memory device by SCI and unbind it from the
> > > > > > > driver at the same time:
> > > > > > >
> > > > > > > CPUa CPUb
> > > > > > > acpi_memory_device_notif
On Wed, 2012-11-28 at 22:09 +0100, Rafael J. Wysocki wrote:
> On Wednesday, November 28, 2012 01:31:39 PM Toshi Kani wrote:
> > On Wed, 2012-11-28 at 19:28 +0100, Rafael J. Wysocki wrote:
> > > On Wednesday, November 28, 2012 09:54:43 AM Toshi Kani wrote:
> >
On Wed, 2012-11-28 at 22:40 +0100, Rafael J. Wysocki wrote:
> On Wednesday, November 28, 2012 02:02:48 PM Toshi Kani wrote:
> > > > > > > > > Consider the following case:
> > > > > > > > >
> > > > > > > > > We ho
On Wed, 2012-11-28 at 23:01 +0100, Rafael J. Wysocki wrote:
> On Wednesday, November 28, 2012 02:40:09 PM Toshi Kani wrote:
> > On Wed, 2012-11-28 at 22:40 +0100, Rafael J. Wysocki wrote:
> > > On Wednesday, November 28, 2012 02:02:48 PM Toshi Kani wrote:
> > > &
> > > > > > I see. I do not think whether or not the device is removed on eject
> > > > > > makes any difference here. The issue is that after driver_unbind()
> > > > > > is
> > > > > > done, acpi_bus_hot_remove_device() no longer calls the ACPI memory
> > > > > > driver (hence, it cannot fail i
> > > > > > I think it has some challenge as well. We bind an ACPI driver with
> > > > > > device_register(), which calls device_add()-> kobject_add(). So,
> > > > > > all
> > > > > > non-present ACPI device objects will show up in sysfs, unless we can
> > > > > > change the core. This will cha
On Wed, 2012-11-28 at 23:49 +0100, Rafael J. Wysocki wrote:
> On Wednesday, November 28, 2012 03:33:27 PM Toshi Kani wrote:
> > > > > > > > I think it has some challenge as well. We bind an ACPI driver
> > > > > > > > with
> > > > &g
On Thu, 2012-11-29 at 00:49 +0100, Rafael J. Wysocki wrote:
> On Wednesday, November 28, 2012 02:02:48 PM Toshi Kani wrote:
> > > > > > > > > Consider the following case:
> > > > > > > > >
> > > > > > > > > We ho
On Wed, 2012-11-28 at 18:02 -0700, Toshi Kani wrote:
> On Thu, 2012-11-29 at 00:49 +0100, Rafael J. Wysocki wrote:
> > On Wednesday, November 28, 2012 02:02:48 PM Toshi Kani wrote:
> > > > > > > > > > Consider the following case:
> > > > >
On Thu, 2012-11-29 at 11:03 +0100, Rafael J. Wysocki wrote:
> On Wednesday, November 28, 2012 06:15:42 PM Toshi Kani wrote:
> > On Wed, 2012-11-28 at 18:02 -0700, Toshi Kani wrote:
> > > On Thu, 2012-11-29 at 00:49 +0100, Rafael J. Wysocki wrote:
> > > > On Wednesday,
On Thu, 2012-11-29 at 11:15 +0100, Rafael J. Wysocki wrote:
> On Wednesday, November 28, 2012 11:41:36 AM Toshi Kani wrote:
> > On Wed, 2012-11-28 at 19:05 +0800, Hanjun Guo wrote:
> > > On 2012/11/24 1:50, Vasilis Liaskovitis wrote:
> > > > As discussed in http
On Thu, 2012-11-29 at 12:04 +0100, Vasilis Liaskovitis wrote:
> Hi,
>
> On Wed, Nov 28, 2012 at 06:15:42PM -0700, Toshi Kani wrote:
> > On Wed, 2012-11-28 at 18:02 -0700, Toshi Kani wrote:
> > > On Thu, 2012-11-29 at 00:49 +0100, Rafael J. Wysocki wrote:
> > > >
On Thu, 2012-11-29 at 12:30 +0100, Vasilis Liaskovitis wrote:
> On Thu, Nov 29, 2012 at 11:03:05AM +0100, Rafael J. Wysocki wrote:
> > On Wednesday, November 28, 2012 06:15:42 PM Toshi Kani wrote:
> > > On Wed, 2012-11-28 at 18:02 -0700, Toshi Kani wrote:
> > > > On
On Thu, 2012-11-29 at 11:53 +, Colin King wrote:
> From: Colin Ian King
>
> ACPI_EXCEPTION() already appends a newline, so there is no
> need for the failed _DCK messaged to include one too.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/acpi/dock.c | 2 +-
> 1 file changed, 1 insertion
On Thu, 2012-11-29 at 21:25 +0100, Rafael J. Wysocki wrote:
> On Thursday, November 29, 2012 10:56:30 AM Toshi Kani wrote:
> > On Thu, 2012-11-29 at 12:30 +0100, Vasilis Liaskovitis wrote:
> > > On Thu, Nov 29, 2012 at 11:03:05AM +0100, Rafael J. Wysocki wrote:
> > >
On Thu, 2012-11-29 at 21:30 +0100, Rafael J. Wysocki wrote:
> On Thursday, November 29, 2012 10:03:12 AM Toshi Kani wrote:
> > On Thu, 2012-11-29 at 11:15 +0100, Rafael J. Wysocki wrote:
> > > On Wednesday, November 28, 2012 11:41:36 AM Toshi Kani wrote:
> > > > On
On Thu, 2012-11-29 at 13:39 -0700, Toshi Kani wrote:
> On Thu, 2012-11-29 at 21:30 +0100, Rafael J. Wysocki wrote:
> > On Thursday, November 29, 2012 10:03:12 AM Toshi Kani wrote:
> > > On Thu, 2012-11-29 at 11:15 +0100, Rafael J. Wysocki wrote:
> > > > On Wednesday,
On Thu, 2012-11-29 at 22:23 +0100, Rafael J. Wysocki wrote:
> On Thursday, November 29, 2012 01:38:39 PM Toshi Kani wrote:
> > On Thu, 2012-11-29 at 21:25 +0100, Rafael J. Wysocki wrote:
> > > On Thursday, November 29, 2012 10:56:30 AM Toshi Kani wrote:
> > > > On
On Thu, 2012-11-29 at 12:48 +0800, Hanjun Guo wrote:
> On 2012/11/29 2:41, Toshi Kani wrote:
> > On Wed, 2012-11-28 at 19:05 +0800, Hanjun Guo wrote:
> >> On 2012/11/24 1:50, Vasilis Liaskovitis wrote:
> >>> As discussed in https://patchwork.kernel.org/patch/1581581
On Thu, 2012-11-29 at 23:11 +0100, Rafael J. Wysocki wrote:
> On Thursday, November 29, 2012 02:46:44 PM Toshi Kani wrote:
> > On Thu, 2012-11-29 at 22:23 +0100, Rafael J. Wysocki wrote:
> > > On Thursday, November 29, 2012 01:38:39 PM Toshi Kani wrote:
> > >
> >
On Fri, 2012-11-30 at 01:13 +0100, Rafael J. Wysocki wrote:
> On Thursday, November 29, 2012 04:17:19 PM Toshi Kani wrote:
> > On Thu, 2012-11-29 at 23:11 +0100, Rafael J. Wysocki wrote:
> > > On Thursday, November 29, 2012 02:46:44 PM Toshi Kani wrote:
> > > > On
On Mon, 2013-03-18 at 11:19 +0900, Yasuaki Ishimatsu wrote:
> Hi Toshi,
>
> Sorry for the late reply
>
> 2013/03/13 23:50, Toshi Kani wrote:
> > On Wed, 2013-03-13 at 15:54 +0900, Yasuaki Ishimatsu wrote:
> >> At http://marc.info/?l=linux-acpi&m=135769405
On Sat, 2013-02-02 at 16:01 +0100, Greg KH wrote:
> On Fri, Feb 01, 2013 at 01:40:10PM -0700, Toshi Kani wrote:
> > On Fri, 2013-02-01 at 07:30 +, Greg KH wrote:
> > > On Thu, Jan 31, 2013 at 06:32:18PM -0700, Toshi Kani wrote:
> > > > This is already done for
On Mon, 2013-02-04 at 14:41 +0100, Rafael J. Wysocki wrote:
> On Sunday, February 03, 2013 07:23:49 PM Greg KH wrote:
> > On Sat, Feb 02, 2013 at 09:15:37PM +0100, Rafael J. Wysocki wrote:
> > > On Saturday, February 02, 2013 03:58:01 PM Greg KH wrote:
:
> > > Yes, but those are just remove event
On Mon, 2013-02-04 at 15:21 +0100, Rafael J. Wysocki wrote:
> On Monday, February 04, 2013 04:48:10 AM Greg KH wrote:
> > On Sun, Feb 03, 2013 at 09:44:39PM +0100, Rafael J. Wysocki wrote:
> > > > Yes, but those are just remove events and we can only see how
> > > > destructive they
> > > > were a
On Mon, 2013-02-04 at 04:46 -0800, Greg KH wrote:
> On Sun, Feb 03, 2013 at 05:28:09PM -0700, Toshi Kani wrote:
> > On Sat, 2013-02-02 at 16:01 +0100, Greg KH wrote:
> > > On Fri, Feb 01, 2013 at 01:40:10PM -0700, Toshi Kani wrote:
> > > > On Fri, 2013-02-01
On Mon, 2013-02-04 at 20:48 +0100, Rafael J. Wysocki wrote:
> On Monday, February 04, 2013 09:02:46 AM Toshi Kani wrote:
> > On Mon, 2013-02-04 at 14:41 +0100, Rafael J. Wysocki wrote:
> > > On Sunday, February 03, 2013 07:23:49 PM Greg KH wrote:
> > > > On Sat, Fe
On Mon, 2013-02-04 at 21:12 +0100, Rafael J. Wysocki wrote:
> On Monday, February 04, 2013 12:46:24 PM Toshi Kani wrote:
> > On Mon, 2013-02-04 at 20:48 +0100, Rafael J. Wysocki wrote:
> > > On Monday, February 04, 2013 09:02:46 AM Toshi Kani wrote:
> > > > On
On Mon, 2013-02-04 at 20:45 +0100, Rafael J. Wysocki wrote:
> On Monday, February 04, 2013 09:46:18 AM Toshi Kani wrote:
> > On Mon, 2013-02-04 at 04:46 -0800, Greg KH wrote:
> > > On Sun, Feb 03, 2013 at 05:28:09PM -0700, Toshi Kani wrote:
> > > > On Sat, 2013-02-02
On Mon, 2013-02-04 at 21:07 +0100, Rafael J. Wysocki wrote:
> On Monday, February 04, 2013 06:33:52 AM Greg KH wrote:
> > On Mon, Feb 04, 2013 at 03:21:22PM +0100, Rafael J. Wysocki wrote:
> > > On Monday, February 04, 2013 04:48:10 AM Greg KH wrote:
> > > > On Sun, Feb 03, 2013 at 09:44:39PM +0100
On Tue, 2013-02-05 at 00:23 +0100, Rafael J. Wysocki wrote:
> On Monday, February 04, 2013 01:59:27 PM Toshi Kani wrote:
> > On Mon, 2013-02-04 at 20:45 +0100, Rafael J. Wysocki wrote:
> > > On Monday, February 04, 2013 09:46:18 AM Toshi Kani wrote:
> > > > On Mon, 2
On Tue, 2013-02-05 at 00:52 +0100, Rafael J. Wysocki wrote:
> On Monday, February 04, 2013 03:13:29 PM Toshi Kani wrote:
> > On Mon, 2013-02-04 at 21:07 +0100, Rafael J. Wysocki wrote:
> > > On Monday, February 04, 2013 06:33:52 AM Greg KH wrote:
> > > > On Mon, Fe
; there may be another handler matching an ID of a higher priority
> which should be preferred). Make the code follow this observation.
>
> This change has been suggested and justified by Toshi Kani.
>
> Signed-off-by: Rafael J. Wysocki
Looks good! Thanks for making th
ch.
With the update in my patchset:
Reviewed-by: Toshi Kani
Thanks,
-Toshi
>
> Signed-off-by: Rafael J. Wysocki
> ---
> drivers/acpi/Kconfig |2
> drivers/acpi/container.c | 158
> ++-
> drivers/acpi/internal.h |
This patchset enables sysfs eject for ACPI scan drivers and
registers the ACPI container driver as an ACPI scan driver.
This patchset is the one I mentioned in my following reply.
Toshi
Re: [PATCH 2/2] ACPI / scan: Simplify container driver
On Mon, 2013-02-04 at 00:47 +0100, Rafael J. Wysocki w
Changed sysfs eject, acpi_eject_store(), to support ACPI scan handlers.
Signed-off-by: Toshi Kani
---
drivers/acpi/scan.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index cfd7a69..3ff632e 100644
--- a/drivers/acpi/scan.c
Changed to register the ACPI container driver as an ACPI scan driver
so that sysfs eject of container devices works.
Fixed a typo in the acpi_container_init() prototype definition.
Removed struct acpi_container, which is no longer used.
Signed-off-by: Toshi Kani
---
This patch applies on top
On Thu, 2013-02-07 at 01:55 +0100, Rafael J. Wysocki wrote:
> On Wednesday, February 06, 2013 03:32:18 PM Toshi Kani wrote:
> > On Mon, 2013-02-04 at 00:47 +0100, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki
> > >
> > > The only useful thing that
On Thu, 2013-02-07 at 02:32 +0100, Rafael J. Wysocki wrote:
> On Wednesday, February 06, 2013 05:51:42 PM Toshi Kani wrote:
> > On Thu, 2013-02-07 at 01:55 +0100, Rafael J. Wysocki wrote:
> > > On Wednesday, February 06, 2013 03:32:18 PM Toshi Kani wrote:
> > > > On
CPI_CONTAINER
> >
> > It should be CONFIG_ACPI_CONTAINER.
>
> Totally correct.
Just FYI, this change is included in my patch 2/2 as well.
https://patchwork.kernel.org/patch/2108881/
Thanks,
-Toshi
> > By this, acpi_container_init() do nothing. When I fix it and test the p
When acpi_device_install_notify_handler() failed in acpi_device_probe(),
it calls acpi_drv->ops.remove() and fails the probe. However, the ACPI
driver is left bound to the acpi_device. Fix it by clearing the driver
and driver_data fields.
Signed-off-by: Toshi Kani
---
This patch is based
On Thu, 2013-02-07 at 23:18 +0100, Rafael J. Wysocki wrote:
> On Thursday, February 07, 2013 02:19:13 PM Toshi Kani wrote:
> > When acpi_device_install_notify_handler() failed in acpi_device_probe(),
> > it calls acpi_drv->ops.remove() and fails the probe. However, the ACPI
On Thu, 2013-02-07 at 23:42 +0100, Rafael J. Wysocki wrote:
> On Thursday, February 07, 2013 07:32:07 AM Toshi Kani wrote:
> > On Thu, 2013-02-07 at 02:32 +0100, Rafael J. Wysocki wrote:
> > > On Wednesday, February 06, 2013 05:51:42 PM Toshi Kani wrote:
> > > > On
On Fri, 2013-02-08 at 09:50 +0900, Yasuaki Ishimatsu wrote:
> Hi Toshi,
>
> 2013/02/07 7:50, Toshi Kani wrote:
> > Changed sysfs eject, acpi_eject_store(), to support ACPI scan handlers.
> >
> > Signed-off-by: Toshi Kani
> > ---
> > drivers/acpi/s
On Fri, 2013-02-08 at 10:33 +0900, Yasuaki Ishimatsu wrote:
> 2013/02/08 10:10, Toshi Kani wrote:
> > On Fri, 2013-02-08 at 09:50 +0900, Yasuaki Ishimatsu wrote:
> >> Hi Toshi,
> >>
> >> 2013/02/07 7:50, Toshi Kani wrote:
> >>> Changed sysfs eject, a
On Fri, 2013-02-08 at 13:52 +0100, Rafael J. Wysocki wrote:
> On Thursday, February 07, 2013 06:05:19 PM Toshi Kani wrote:
> > On Thu, 2013-02-07 at 23:42 +0100, Rafael J. Wysocki wrote:
> > > On Thursday, February 07, 2013 07:32:07 AM Toshi Kani wrote:
> > > > On
es a little sense to build that driver as a module,
> > so make it non-modular and add its initialization to the
> > namespace scanning code.
> >
> > In addition to that, make the namespace walk callback used for
> > installing the notify handlers more straightforward.
On Sat, 2013-02-09 at 00:18 +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The include/acpi/container.h only contains a definition of a
> structure that is not used any more, so drop it entirely.
>
> Similar change was proposed earlier by Toshi Kani.
>
>
config ACPI_CONTAINER has been changed to bool (y/n), and its
module option is no longer valid. So, remove the use of
CONFIG_ACPI_CONTAINER_MODULE.
Signed-off-by: Toshi Kani
---
include/linux/acpi.h |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/acpi.h b
On Tue, 2013-02-12 at 00:22 +0100, Rafael J. Wysocki wrote:
> On Monday, February 11, 2013 03:33:20 PM Toshi Kani wrote:
> > config ACPI_CONTAINER has been changed to bool (y/n), and its
> > module option is no longer valid. So, remove the use of
> > CONFIG_ACPI_CONTAINER_MO
ly companion "physical" device objects).
> Therefore acpi_bus_hot_remove_device() has to acquire the scan
> lock before carrying out the bus trimming and hold it through
> the evaluation of _EJ0, so make that happen.
>
> Signed-off-by: Rafael J. Wysocki
Looks good.
Acked-
memory
hot-delete operations, which allows releasing a partial memory range
and adjusts remaining resource accordingly. This patchset makes no
changes to the existing interfaces since their restriction is still
valid for I/O resources.
---
Toshi Kani (3):
resource: Add __adjust_resource() for in
Added __adjust_resource(), which is called by adjust_resource()
internally after the resource_lock is held. There is no interface
change to adjust_resource(). This change allows other functions
to call __adjust_resource() internally while the resource_lock is
held.
Signed-off-by: Toshi Kani
__release_region(), logs an error message and returns no error
since a void function.
Signed-off-by: Toshi Kani
---
mm/memory_hotplug.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 57decb2..c916582 100644
--- a/mm
their restriction
is valid for I/O resources.
Signed-off-by: Toshi Kani
---
include/linux/ioport.h |2 +
kernel/resource.c | 87
2 files changed, 89 insertions(+)
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 85ac9b9b
On Wed, 2013-04-03 at 10:26 +0900, Yasuaki Ishimatsu wrote:
> 2013/04/03 1:17, Toshi Kani wrote:
> > Added release_mem_region_adjustable(), which releases a requested
> > region from a currently busy memory resource. This interface
> > adjusts the matched memory resour
On Wed, 2013-04-03 at 13:37 +0800, Ram Pai wrote:
> On Tue, Apr 02, 2013 at 10:17:29AM -0600, Toshi Kani wrote:
> > Added release_mem_region_adjustable(), which releases a requested
> > region from a currently busy memory resource. This interface
> > adjusts the ma
On Wed, 2013-04-03 at 15:37 +0800, Gu Zheng wrote:
> On 04/03/2013 12:17 AM, Toshi Kani wrote:
>
> > Added release_mem_region_adjustable(), which releases a requested
> > region from a currently busy memory resource. This interface
> > adjusts the matched memory res
their restriction
is valid for I/O resources.
Signed-off-by: Toshi Kani
---
Updated per code reviews from Yasuaki Ishimatsu, Ram Pai and
Gu Zheng.
---
include/linux/ioport.h |2 +
kernel/resource.c | 93
2 files changed, 95 insertions
On Thu, 2013-04-04 at 14:48 +0800, Ram Pai wrote:
> On Wed, Apr 03, 2013 at 01:55:05PM -0600, Toshi Kani wrote:
> > On Wed, 2013-04-03 at 13:37 +0800, Ram Pai wrote:
> > > On Tue, Apr 02, 2013 at 10:17:29AM -0600, Toshi Kani wrote:
> > > > + whi
On Mon, 2013-01-28 at 13:58 +0100, Rafael J. Wysocki wrote:
> On Thursday, January 24, 2013 01:26:56 AM Rafael J. Wysocki wrote:
> > Hi All,
> >
> > There is a considerable amount of confusion in the ACPI subsystem about what
> > ACPI drivers are used for. Namely, some of them are used as "normal
On Mon, 2013-01-28 at 13:59 +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Introduce struct acpi_scan_handler for representing objects that
> will do configuration tasks depending on ACPI device nodes'
> hardware IDs (HIDs).
>
> Currently, those tasks are done either directly by t
On Tue, 2013-01-29 at 12:28 +0100, Rafael J. Wysocki wrote:
> On Monday, January 28, 2013 07:35:39 PM Toshi Kani wrote:
> > On Mon, 2013-01-28 at 13:59 +0100, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki
> > >
> > > Introduce struct acpi_scan_h
On Tue, 2013-01-29 at 22:32 +0100, Rafael J. Wysocki wrote:
> On Tuesday, January 29, 2013 07:50:43 AM Toshi Kani wrote:
> > On Tue, 2013-01-29 at 12:28 +0100, Rafael J. Wysocki wrote:
> > > On Monday, January 28, 2013 07:35:39 PM Toshi Kani wrote:
> > > > On Mon, 201
On Wed, 2013-01-30 at 00:19 +0100, Rafael J. Wysocki wrote:
> On Tuesday, January 29, 2013 03:57:10 PM Toshi Kani wrote:
> > On Tue, 2013-01-29 at 22:32 +0100, Rafael J. Wysocki wrote:
> > > On Tuesday, January 29, 2013 07:50:43 AM Toshi Kani wrote:
> > > > On
#x27;t
> see reason to wait with that change.
>
> The following patches introduce ACPI scan handlers and make some use of them.
>
> [1/4] Introduce struct acpi_scan_handler for configuration tasks depending on
> device IDs.
>
> [2/4] Make ACPI PCI root driver use struct
On Tue, 2013-01-29 at 23:48 -0500, Greg KH wrote:
> On Mon, Jan 14, 2013 at 12:02:04PM -0700, Toshi Kani wrote:
> > On Mon, 2013-01-14 at 19:48 +0100, Rafael J. Wysocki wrote:
> > > On Monday, January 14, 2013 08:33:48 AM Toshi Kani wrote:
> > > > On Fri, 2013-
On Tue, 2013-01-29 at 23:51 -0500, Greg KH wrote:
> On Mon, Jan 14, 2013 at 12:21:30PM -0700, Toshi Kani wrote:
> > On Mon, 2013-01-14 at 20:07 +0100, Rafael J. Wysocki wrote:
> > > On Monday, January 14, 2013 11:42:09 AM Toshi Kani wrote:
> > > > On Mon, 2013-
On Tue, 2013-01-29 at 23:53 -0500, Greg KH wrote:
> On Thu, Jan 10, 2013 at 04:40:19PM -0700, Toshi Kani wrote:
> > Added include/linux/sys_hotplug.h, which defines the system device
> > hotplug framework interfaces used by the framework itself and
> > handlers.
> >
On Tue, 2013-01-29 at 23:54 -0500, Greg KH wrote:
> On Thu, Jan 10, 2013 at 04:40:21PM -0700, Toshi Kani wrote:
> > Added sys_hotplug.c, which is the system device hotplug framework code.
> >
> > shp_register_handler() allows modules to register their hotplug handlers
On Tue, 2013-01-29 at 23:58 -0500, Greg KH wrote:
> On Thu, Jan 10, 2013 at 04:40:19PM -0700, Toshi Kani wrote:
> > +/*
> > + * Hot-plug device information
> > + */
>
> Again, stop it with the "generic" hotplug term here, and everywhere
> else. You are
On Thu, 2013-01-31 at 05:24 +, Greg KH wrote:
> On Wed, Jan 30, 2013 at 06:15:12PM -0700, Toshi Kani wrote:
> > > Please make it a "real" pointer, and not a void *, those shouldn't be
> > > used at all if possible.
> >
> > How about ch
On Thu, 2013-01-31 at 21:54 +0100, Rafael J. Wysocki wrote:
> On Wednesday, January 30, 2013 07:57:45 PM Toshi Kani wrote:
> > On Tue, 2013-01-29 at 23:58 -0500, Greg KH wrote:
> > > On Thu, Jan 10, 2013 at 04:40:19PM -0700, Toshi Kani wrote:
:
> > > > +};
> &
On Fri, 2013-02-01 at 07:30 +, Greg KH wrote:
> On Thu, Jan 31, 2013 at 06:32:18PM -0700, Toshi Kani wrote:
> > This is already done for PCI host bridges and platform devices and I don't
> > > see why we can't do that for the other types of devices too.
> >
On Fri, 2013-02-01 at 23:21 +0100, Rafael J. Wysocki wrote:
> On Friday, February 01, 2013 01:40:10 PM Toshi Kani wrote:
> > On Fri, 2013-02-01 at 07:30 +, Greg KH wrote:
> > > On Thu, Jan 31, 2013 at 06:32:18PM -0700, Toshi Kani wrote:
> > > > This is already
-off-by: Rafael J. Wysocki
Acked-by: Toshi Kani
Thanks,
-Toshi
> ---
>
> On top of current linux-pm.git/linux-next.
>
> Thanks,
> Rafael
>
> ---
> drivers/acpi/dock.c|8 ++--
> drivers/acpi/scan.c| 12 +++-
> driv
On Thu, 2013-01-24 at 01:26 +0100, Rafael J. Wysocki wrote:
> Hi All,
>
> There is a considerable amount of confusion in the ACPI subsystem about what
> ACPI drivers are used for. Namely, some of them are used as "normal" device
> drivers that bind to devices and handle them using ACPI control me
|2 +-
> 4 files changed, 77 insertions(+), 125 deletions(-)
This patchset fixed a blocker panic I was hitting in my memory hot-plug
testing. Memory hotplug works fine with this patchset (for testing my
hotplug framework patchset :). For the series:
Tested-by: Toshi Kani
Than
On Fri, 2013-01-25 at 23:11 +0100, Rafael J. Wysocki wrote:
> On Friday, January 25, 2013 09:52:21 AM Toshi Kani wrote:
> > On Thu, 2013-01-24 at 01:26 +0100, Rafael J. Wysocki wrote:
:
> > >
> > > I wonder if anyone is seeing any major problems with this at the high
On Sat, 2013-02-23 at 22:38 +, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> 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
On Sun, 2013-02-17 at 16:24 +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Introduce user space interface for manipulating hotplug profiles
> associated with ACPI scan handlers.
>
> The interface consists of sysfs directories under
> /sys/firmware/acpi/hotplug/, one for each hotpl
On Mon, 2013-02-25 at 13:51 +0900, Yasuaki Ishimatsu wrote:
> Hi Toshi,
>
> 2013/02/23 4:42, Toshi Kani wrote:
> > In order to eject a memory device object represented as "PNP0C80:%d"
> > in sysfs, its associated memblocks (system/memory/memory%d) need to
> >
PNP0C80:05.
# ll /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C80:05
lrwxrwxrwx. memory8 -> ../../../system/memory/memory8
lrwxrwxrwx. memory9 -> ../../../system/memory/memory9
Signed-off-by: Toshi Kani
---
This patch applies on top of the Rafael's patch below.
https://patchwork.ker
On Tue, 2013-02-26 at 00:39 +0100, Rafael J. Wysocki wrote:
> On Monday, February 25, 2013 11:07:52 AM Toshi Kani wrote:
> > On Sat, 2013-02-23 at 22:38 +, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki
> > >
> > > Multiple drivers handling hotpl
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 +, Rafael J. Wysocki wrote:
> >>> From: Rafael J. Wysocki
On Tue, 2013-02-26 at 05:37 +, Yasuaki Ishimatsu wrote:
> 2013/02/26 6:02, Toshi Kani wrote:
> > In order to eject a memory device object represented as "PNP0C80:%d"
> > in sysfs, its associated memblocks (system/memory/memory%d) need to
> > be off-lined. How
On Tue, 2013-02-26 at 23:46 +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Switch the ACPI container driver to using common device hotplug code
> introduced previously. This reduces the driver down to a trivial
> definition and registration of a struct acpi_scan_handler object.
>
1 - 100 of 1776 matches
Mail list logo
