* [PATCH] ACPI:add _STA evaluating at do_acpi_find_child() @ 2013-05-21 11:19 jeff.wu 2013-05-21 4:13 ` Jeff Wu 2013-05-21 13:34 ` Lan Tianyu 0 siblings, 2 replies; 13+ messages in thread From: jeff.wu @ 2013-05-21 11:19 UTC (permalink / raw) To: lenb, rjw, linux-acpi Cc: zlinuxkernel, lekensteyn, dagobertstaler, shang.huang, aaron.lwe From: Jeff Wu <zlinuxkernel@gmail.com> Once do_acpi_find_child() found the first matching handle, it makes the acpi_get_child() loop stop and return the matching handle. But, at some of the platforms, a "_ADR" is with the multiple devices, and if one is enabled, the others will be disabled. Just like a case: Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV0 Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV1 Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV2 If DEV0 and DEV1 are disabled and DEV2 is enabled, the target is to get DEV2 handle, but actually it always return the first disabled device DEV0 handle. So add a _STA evaluating at do_acpi_find_child() to check the device status. If the object exists, but it is disabled, acpi_get_child() will continue looping to get the correct handle that the object exists and is enabled. Signed-off-by: Jeff Wu <zlinuxkernel@gmail.com> --- drivers/acpi/glue.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c index 40a84cc..ace6c2e 100644 --- a/drivers/acpi/glue.c +++ b/drivers/acpi/glue.c @@ -81,11 +81,14 @@ static struct acpi_bus_type *acpi_get_bus_type(struct device *dev) static acpi_status do_acpi_find_child(acpi_handle handle, u32 lvl_not_used, void *addr_p, void **ret_p) { - unsigned long long addr; acpi_status status; + unsigned long long addr = 0, sta = 0; status = acpi_evaluate_integer(handle, METHOD_NAME__ADR, NULL, &addr); if (ACPI_SUCCESS(status) && addr == *((u64 *)addr_p)) { + status = acpi_bus_get_status_handle(handle, &sta); + if (ACPI_SUCCESS(status) && !(sta & ACPI_STA_DEVICE_ENABLED)) + return AE_CTRL_DEPTH; *ret_p = handle; return AE_CTRL_TERMINATE; } -- 1.8.1.2 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH] ACPI:add _STA evaluating at do_acpi_find_child() 2013-05-21 11:19 [PATCH] ACPI:add _STA evaluating at do_acpi_find_child() jeff.wu @ 2013-05-21 4:13 ` Jeff Wu 2013-05-21 13:34 ` Lan Tianyu 1 sibling, 0 replies; 13+ messages in thread From: Jeff Wu @ 2013-05-21 4:13 UTC (permalink / raw) To: jeff.wu Cc: lenb, rjw, linux-acpi, lekensteyn, dagobertstaler, shane.huang, aaron.lwe I also found the similar topic at mail list : 1. [PATCH] ACPI: return first _ADR match for acpi_get_child http://www.spinics.net/lists/linux-acpi/msg39739.html 2.ACPI: Rework acpi_get_child() to be more efficient" has been added to the 3.8-stable tree http://www.spinics.net/lists/stable/msg03621.html 2013/5/21 <jeff.wu@amd.com>: > From: Jeff Wu <zlinuxkernel@gmail.com> > > Once do_acpi_find_child() found the first matching handle, it makes the acpi_get_child() > loop stop and return the matching handle. But, at some of the platforms, a "_ADR" is > with the multiple devices, and if one is enabled, the others will be disabled. > Just like a case: > Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV0 > Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV1 > Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV2 > > If DEV0 and DEV1 are disabled and DEV2 is enabled, the target is to get DEV2 handle, but > actually it always return the first disabled device DEV0 handle. So add a _STA evaluating > at do_acpi_find_child() to check the device status. If the object exists, but it is disabled, > acpi_get_child() will continue looping to get the correct handle that the object exists and > is enabled. > > > Signed-off-by: Jeff Wu <zlinuxkernel@gmail.com> > --- > drivers/acpi/glue.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c > index 40a84cc..ace6c2e 100644 > --- a/drivers/acpi/glue.c > +++ b/drivers/acpi/glue.c > @@ -81,11 +81,14 @@ static struct acpi_bus_type *acpi_get_bus_type(struct device *dev) > static acpi_status do_acpi_find_child(acpi_handle handle, u32 lvl_not_used, > void *addr_p, void **ret_p) > { > - unsigned long long addr; > acpi_status status; > + unsigned long long addr = 0, sta = 0; > > status = acpi_evaluate_integer(handle, METHOD_NAME__ADR, NULL, &addr); > if (ACPI_SUCCESS(status) && addr == *((u64 *)addr_p)) { > + status = acpi_bus_get_status_handle(handle, &sta); > + if (ACPI_SUCCESS(status) && !(sta & ACPI_STA_DEVICE_ENABLED)) > + return AE_CTRL_DEPTH; > *ret_p = handle; > return AE_CTRL_TERMINATE; > } > -- > 1.8.1.2 > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ACPI:add _STA evaluating at do_acpi_find_child() 2013-05-21 11:19 [PATCH] ACPI:add _STA evaluating at do_acpi_find_child() jeff.wu 2013-05-21 4:13 ` Jeff Wu @ 2013-05-21 13:34 ` Lan Tianyu 2013-05-21 14:21 ` Lan Tianyu 2013-05-22 3:27 ` Jeff Wu 1 sibling, 2 replies; 13+ messages in thread From: Lan Tianyu @ 2013-05-21 13:34 UTC (permalink / raw) To: jeff.wu Cc: Len Brown, Rafael J. Wysocki, linux-acpi, zlinuxkernel, lekensteyn, dagobertstaler, shang.huang, aaron.lwe 2013/5/21 <jeff.wu@amd.com>: > From: Jeff Wu <zlinuxkernel@gmail.com> > > Once do_acpi_find_child() found the first matching handle, it makes the acpi_get_child() > loop stop and return the matching handle. But, at some of the platforms, a "_ADR" is > with the multiple devices, and if one is enabled, the others will be disabled. > Just like a case: > Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV0 > Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV1 > Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV2 > > If DEV0 and DEV1 are disabled and DEV2 is enabled, the target is to get DEV2 handle, but > actually it always return the first disabled device DEV0 handle. So add a _STA evaluating > at do_acpi_find_child() to check the device status. If the object exists, but it is disabled, > acpi_get_child() will continue looping to get the correct handle that the object exists and > is enabled. > > > Signed-off-by: Jeff Wu <zlinuxkernel@gmail.com> > --- > drivers/acpi/glue.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c > index 40a84cc..ace6c2e 100644 > --- a/drivers/acpi/glue.c > +++ b/drivers/acpi/glue.c > @@ -81,11 +81,14 @@ static struct acpi_bus_type *acpi_get_bus_type(struct device *dev) > static acpi_status do_acpi_find_child(acpi_handle handle, u32 lvl_not_used, > void *addr_p, void **ret_p) > { > - unsigned long long addr; > acpi_status status; > + unsigned long long addr = 0, sta = 0; > > status = acpi_evaluate_integer(handle, METHOD_NAME__ADR, NULL, &addr); > if (ACPI_SUCCESS(status) && addr == *((u64 *)addr_p)) { > + status = acpi_bus_get_status_handle(handle, &sta); > + if (ACPI_SUCCESS(status) && !(sta & ACPI_STA_DEVICE_ENABLED)) > + return AE_CTRL_DEPTH; Will this affect other devices? Since the device maybe disabled during do binding with ACPI. After some operations, the device would be enabled. Hi Rafael: How about add a new function "acpi_get_children_with_same_addr" to return a list which contains all these child devices with same _ADR.And then do some special check in the specific bus glue callback. Since these cases are no common. > *ret_p = handle; > return AE_CTRL_TERMINATE; > } > -- > 1.8.1.2 > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best regards Tianyu Lan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ACPI:add _STA evaluating at do_acpi_find_child() 2013-05-21 13:34 ` Lan Tianyu @ 2013-05-21 14:21 ` Lan Tianyu 2013-05-22 3:27 ` Jeff Wu 1 sibling, 0 replies; 13+ messages in thread From: Lan Tianyu @ 2013-05-21 14:21 UTC (permalink / raw) To: jeff.wu Cc: Len Brown, Rafael J. Wysocki, linux-acpi, zlinuxkernel, lekensteyn, dagobertstaler, shang.huang, aaron.lwe 2013/5/21 Lan Tianyu <lantianyu1986@gmail.com>: > 2013/5/21 <jeff.wu@amd.com>: >> From: Jeff Wu <zlinuxkernel@gmail.com> >> >> Once do_acpi_find_child() found the first matching handle, it makes the acpi_get_child() >> loop stop and return the matching handle. But, at some of the platforms, a "_ADR" is >> with the multiple devices, and if one is enabled, the others will be disabled. >> Just like a case: >> Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV0 >> Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV1 >> Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV2 >> >> If DEV0 and DEV1 are disabled and DEV2 is enabled, the target is to get DEV2 handle, but >> actually it always return the first disabled device DEV0 handle. So add a _STA evaluating >> at do_acpi_find_child() to check the device status. If the object exists, but it is disabled, >> acpi_get_child() will continue looping to get the correct handle that the object exists and >> is enabled. >> >> >> Signed-off-by: Jeff Wu <zlinuxkernel@gmail.com> >> --- >> drivers/acpi/glue.c | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c >> index 40a84cc..ace6c2e 100644 >> --- a/drivers/acpi/glue.c >> +++ b/drivers/acpi/glue.c >> @@ -81,11 +81,14 @@ static struct acpi_bus_type *acpi_get_bus_type(struct device *dev) >> static acpi_status do_acpi_find_child(acpi_handle handle, u32 lvl_not_used, >> void *addr_p, void **ret_p) >> { >> - unsigned long long addr; >> acpi_status status; >> + unsigned long long addr = 0, sta = 0; >> >> status = acpi_evaluate_integer(handle, METHOD_NAME__ADR, NULL, &addr); >> if (ACPI_SUCCESS(status) && addr == *((u64 *)addr_p)) { >> + status = acpi_bus_get_status_handle(handle, &sta); >> + if (ACPI_SUCCESS(status) && !(sta & ACPI_STA_DEVICE_ENABLED)) >> + return AE_CTRL_DEPTH; > Will this affect other devices? Since the device maybe disabled during > do binding with ACPI. > After some operations, the device would be enabled. > > Hi Rafael: > How about add a new function > "acpi_get_children_with_same_addr" to return a list > which contains all these child devices with same _ADR.And then do some > special check in the specific Sorry for broken line. Just update. Will this affect other devices? Since the device maybe disabled during do binding with ACPI. After some operations, the device would be enabled. Hi Rafael: How about add a new function "acpi_get_children_with_ same_addr" to return a list which contains all these child devices with same _ADR.And then do some special check in the specific bus glue callback. Since these cases are no common. > bus glue callback. Since these cases are no common. > >> *ret_p = handle; >> return AE_CTRL_TERMINATE; >> } >> -- >> 1.8.1.2 >> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > Best regards > Tianyu Lan -- Best regards Tianyu Lan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ACPI:add _STA evaluating at do_acpi_find_child() 2013-05-21 13:34 ` Lan Tianyu 2013-05-21 14:21 ` Lan Tianyu @ 2013-05-22 3:27 ` Jeff Wu 2013-05-22 6:41 ` Lan Tianyu 1 sibling, 1 reply; 13+ messages in thread From: Jeff Wu @ 2013-05-22 3:27 UTC (permalink / raw) To: Lan Tianyu, linux-acpi Cc: Len Brown, Rafael J. Wysocki, lekensteyn, Sergio Perez, shang.huang, Aaron Lu 2013/5/21 Lan Tianyu <lantianyu1986@gmail.com>: > 2013/5/21 <jeff.wu@amd.com>: >> From: Jeff Wu <zlinuxkernel@gmail.com> >> >> Once do_acpi_find_child() found the first matching handle, it makes the acpi_get_child() >> loop stop and return the matching handle. But, at some of the platforms, a "_ADR" is >> with the multiple devices, and if one is enabled, the others will be disabled. >> Just like a case: >> Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV0 >> Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV1 >> Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV2 >> >> If DEV0 and DEV1 are disabled and DEV2 is enabled, the target is to get DEV2 handle, but >> actually it always return the first disabled device DEV0 handle. So add a _STA evaluating >> at do_acpi_find_child() to check the device status. If the object exists, but it is disabled, >> acpi_get_child() will continue looping to get the correct handle that the object exists and >> is enabled. >> >> >> Signed-off-by: Jeff Wu <zlinuxkernel@gmail.com> >> --- >> drivers/acpi/glue.c | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c >> index 40a84cc..ace6c2e 100644 >> --- a/drivers/acpi/glue.c >> +++ b/drivers/acpi/glue.c >> @@ -81,11 +81,14 @@ static struct acpi_bus_type *acpi_get_bus_type(struct device *dev) >> static acpi_status do_acpi_find_child(acpi_handle handle, u32 lvl_not_used, >> void *addr_p, void **ret_p) >> { >> - unsigned long long addr; >> acpi_status status; >> + unsigned long long addr = 0, sta = 0; >> >> status = acpi_evaluate_integer(handle, METHOD_NAME__ADR, NULL, &addr); >> if (ACPI_SUCCESS(status) && addr == *((u64 *)addr_p)) { >> + status = acpi_bus_get_status_handle(handle, &sta); >> + if (ACPI_SUCCESS(status) && !(sta & ACPI_STA_DEVICE_ENABLED)) >> + return AE_CTRL_DEPTH; > Will this affect other devices? Since the device maybe disabled during > do binding with ACPI. > After some operations, the device would be enabled. At our platforms, DEV1 use for win8,DEV2 use for win7,DEV1 use for Linux. If these devices are disabled when do init, they will always be disabled ,so, work fine. At some of the platforms, the devices may be disabled during do the first binding ,if their status are changed,do they not do re-binding ? > > Hi Rafael: > How about add a new function > "acpi_get_children_with_same_addr" to return a list > which contains all these child devices with same _ADR.And then do some > special check in the specific > bus glue callback. Since these cases are no common. > >> *ret_p = handle; >> return AE_CTRL_TERMINATE; >> } >> -- >> 1.8.1.2 >> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > Best regards > Tianyu Lan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ACPI:add _STA evaluating at do_acpi_find_child() 2013-05-22 3:27 ` Jeff Wu @ 2013-05-22 6:41 ` Lan Tianyu 2013-05-22 7:42 ` Jeff Wu 0 siblings, 1 reply; 13+ messages in thread From: Lan Tianyu @ 2013-05-22 6:41 UTC (permalink / raw) To: Jeff Wu Cc: linux-acpi, Len Brown, Rafael J. Wysocki, lekensteyn, Sergio Perez, shang.huang, Aaron Lu 2013/5/22 Jeff Wu <zlinuxkernel@gmail.com>: > 2013/5/21 Lan Tianyu <lantianyu1986@gmail.com>: >> 2013/5/21 <jeff.wu@amd.com>: >>> From: Jeff Wu <zlinuxkernel@gmail.com> >>> >>> Once do_acpi_find_child() found the first matching handle, it makes the acpi_get_child() >>> loop stop and return the matching handle. But, at some of the platforms, a "_ADR" is >>> with the multiple devices, and if one is enabled, the others will be disabled. >>> Just like a case: >>> Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV0 >>> Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV1 >>> Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV2 >>> >>> If DEV0 and DEV1 are disabled and DEV2 is enabled, the target is to get DEV2 handle, but >>> actually it always return the first disabled device DEV0 handle. So add a _STA evaluating >>> at do_acpi_find_child() to check the device status. If the object exists, but it is disabled, >>> acpi_get_child() will continue looping to get the correct handle that the object exists and >>> is enabled. >>> >>> >>> Signed-off-by: Jeff Wu <zlinuxkernel@gmail.com> >>> --- >>> drivers/acpi/glue.c | 5 ++++- >>> 1 file changed, 4 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c >>> index 40a84cc..ace6c2e 100644 >>> --- a/drivers/acpi/glue.c >>> +++ b/drivers/acpi/glue.c >>> @@ -81,11 +81,14 @@ static struct acpi_bus_type *acpi_get_bus_type(struct device *dev) >>> static acpi_status do_acpi_find_child(acpi_handle handle, u32 lvl_not_used, >>> void *addr_p, void **ret_p) >>> { >>> - unsigned long long addr; >>> acpi_status status; >>> + unsigned long long addr = 0, sta = 0; >>> >>> status = acpi_evaluate_integer(handle, METHOD_NAME__ADR, NULL, &addr); >>> if (ACPI_SUCCESS(status) && addr == *((u64 *)addr_p)) { >>> + status = acpi_bus_get_status_handle(handle, &sta); >>> + if (ACPI_SUCCESS(status) && !(sta & ACPI_STA_DEVICE_ENABLED)) >>> + return AE_CTRL_DEPTH; >> Will this affect other devices? Since the device maybe disabled during >> do binding with ACPI. >> After some operations, the device would be enabled. > At our platforms, DEV1 use for win8,DEV2 use for win7,DEV1 use for Linux. > If these devices are disabled when do init, they will always be > disabled ,so, work fine. > > At some of the platforms, the devices may be disabled during do the > first binding ,if their status are changed,do they not do re-binding ? Currently, the glue binding operation takes place when the device is created. In my mind, there is no re-binding operation after the device being created, Unless the device being removed and created again. > >> >> Hi Rafael: >> How about add a new function >> "acpi_get_children_with_same_addr" to return a list >> which contains all these child devices with same _ADR.And then do some >> special check in the specific >> bus glue callback. Since these cases are no common. >> >>> *ret_p = handle; >>> return AE_CTRL_TERMINATE; >>> } >>> -- >>> 1.8.1.2 >>> >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> >> >> -- >> Best regards >> Tianyu Lan -- Best regards Tianyu Lan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ACPI:add _STA evaluating at do_acpi_find_child() 2013-05-22 6:41 ` Lan Tianyu @ 2013-05-22 7:42 ` Jeff Wu 2013-05-23 0:06 ` Rafael J. Wysocki 0 siblings, 1 reply; 13+ messages in thread From: Jeff Wu @ 2013-05-22 7:42 UTC (permalink / raw) To: Lan Tianyu, Rafael J. Wysocki, linux-acpi Cc: Len Brown, lekensteyn, Sergio Perez, shane.huang, Aaron Lu 2013/5/22 Lan Tianyu <lantianyu1986@gmail.com>: > 2013/5/22 Jeff Wu <zlinuxkernel@gmail.com>: >> 2013/5/21 Lan Tianyu <lantianyu1986@gmail.com>: >>>> From: Jeff Wu <zlinuxkernel@gmail.com> >>>> >>>> Once do_acpi_find_child() found the first matching handle, it makes the acpi_get_child() >>>> loop stop and return the matching handle. But, at some of the platforms, a "_ADR" is >>>> with the multiple devices, and if one is enabled, the others will be disabled. >>>> Just like a case: >>>> Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV0 >>>> Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV1 >>>> Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV2 >>>> >>>> If DEV0 and DEV1 are disabled and DEV2 is enabled, the target is to get DEV2 handle, but >>>> actually it always return the first disabled device DEV0 handle. So add a _STA evaluating >>>> at do_acpi_find_child() to check the device status. If the object exists, but it is disabled, >>>> acpi_get_child() will continue looping to get the correct handle that the object exists and >>>> is enabled. >>>> >>>> >>>> Signed-off-by: Jeff Wu <zlinuxkernel@gmail.com> >>>> --- >>>> drivers/acpi/glue.c | 5 ++++- >>>> 1 file changed, 4 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c >>>> index 40a84cc..ace6c2e 100644 >>>> --- a/drivers/acpi/glue.c >>>> +++ b/drivers/acpi/glue.c >>>> @@ -81,11 +81,14 @@ static struct acpi_bus_type *acpi_get_bus_type(struct device *dev) >>>> static acpi_status do_acpi_find_child(acpi_handle handle, u32 lvl_not_used, >>>> void *addr_p, void **ret_p) >>>> { >>>> - unsigned long long addr; >>>> acpi_status status; >>>> + unsigned long long addr = 0, sta = 0; >>>> >>>> status = acpi_evaluate_integer(handle, METHOD_NAME__ADR, NULL, &addr); >>>> if (ACPI_SUCCESS(status) && addr == *((u64 *)addr_p)) { >>>> + status = acpi_bus_get_status_handle(handle, &sta); >>>> + if (ACPI_SUCCESS(status) && !(sta & ACPI_STA_DEVICE_ENABLED)) >>>> + return AE_CTRL_DEPTH; >>> Will this affect other devices? Since the device maybe disabled during >>> do binding with ACPI. >>> After some operations, the device would be enabled. >> At our platforms, DEV1 use for win8,DEV2 use for win7,DEV1 use for Linux. >> If these devices are disabled when do init, they will always be >> disabled ,so, work fine. >> >> At some of the platforms, the devices may be disabled during do the >> first binding ,if their status are changed,do they not do re-binding ? > Currently, the glue binding operation takes place when the device is > created. In my mind, there is no re-binding operation after the device being > created, Unless the device being removed and created again. Thank you very much. So, as your suggestion, it is a better solution to add a new function for the same _ADR devices, waiting for Rafael's suggestion. >> >>> >>> Hi Rafael: >>> How about add a new function >>> "acpi_get_children_with_same_addr" to return a list >>> which contains all these child devices with same _ADR.And then do some >>> special check in the specific >>> bus glue callback. Since these cases are no common. >>> >>>> *ret_p = handle; >>>> return AE_CTRL_TERMINATE; >>>> } >>>> -- >>>> 1.8.1.2 >>>> >>>> >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in >>>> the body of a message to majordomo@vger.kernel.org >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >>> >>> >>> -- >>> Best regards >>> Tianyu Lan > > > > -- > Best regards > Tianyu Lan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ACPI:add _STA evaluating at do_acpi_find_child() 2013-05-22 7:42 ` Jeff Wu @ 2013-05-23 0:06 ` Rafael J. Wysocki 2013-05-23 12:56 ` Lan Tianyu 2013-05-24 8:21 ` Jeff Wu 0 siblings, 2 replies; 13+ messages in thread From: Rafael J. Wysocki @ 2013-05-23 0:06 UTC (permalink / raw) To: Jeff Wu Cc: Lan Tianyu, linux-acpi, Len Brown, lekensteyn, Sergio Perez, shane.huang, Aaron Lu On Wednesday, May 22, 2013 03:42:04 PM Jeff Wu wrote: > 2013/5/22 Lan Tianyu <lantianyu1986@gmail.com>: > > 2013/5/22 Jeff Wu <zlinuxkernel@gmail.com>: > >> 2013/5/21 Lan Tianyu <lantianyu1986@gmail.com>: > >>>> From: Jeff Wu <zlinuxkernel@gmail.com> > >>>> > >>>> Once do_acpi_find_child() found the first matching handle, it makes the acpi_get_child() > >>>> loop stop and return the matching handle. But, at some of the platforms, a "_ADR" is > >>>> with the multiple devices, and if one is enabled, the others will be disabled. > >>>> Just like a case: > >>>> Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV0 > >>>> Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV1 > >>>> Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV2 > >>>> > >>>> If DEV0 and DEV1 are disabled and DEV2 is enabled, the target is to get DEV2 handle, but > >>>> actually it always return the first disabled device DEV0 handle. So add a _STA evaluating > >>>> at do_acpi_find_child() to check the device status. If the object exists, but it is disabled, > >>>> acpi_get_child() will continue looping to get the correct handle that the object exists and > >>>> is enabled. > >>>> > >>>> > >>>> Signed-off-by: Jeff Wu <zlinuxkernel@gmail.com> > >>>> --- > >>>> drivers/acpi/glue.c | 5 ++++- > >>>> 1 file changed, 4 insertions(+), 1 deletion(-) > >>>> > >>>> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c > >>>> index 40a84cc..ace6c2e 100644 > >>>> --- a/drivers/acpi/glue.c > >>>> +++ b/drivers/acpi/glue.c > >>>> @@ -81,11 +81,14 @@ static struct acpi_bus_type *acpi_get_bus_type(struct device *dev) > >>>> static acpi_status do_acpi_find_child(acpi_handle handle, u32 lvl_not_used, > >>>> void *addr_p, void **ret_p) > >>>> { > >>>> - unsigned long long addr; > >>>> acpi_status status; > >>>> + unsigned long long addr = 0, sta = 0; > >>>> > >>>> status = acpi_evaluate_integer(handle, METHOD_NAME__ADR, NULL, &addr); > >>>> if (ACPI_SUCCESS(status) && addr == *((u64 *)addr_p)) { > >>>> + status = acpi_bus_get_status_handle(handle, &sta); > >>>> + if (ACPI_SUCCESS(status) && !(sta & ACPI_STA_DEVICE_ENABLED)) > >>>> + return AE_CTRL_DEPTH; > >>> Will this affect other devices? Since the device maybe disabled during > >>> do binding with ACPI. > >>> After some operations, the device would be enabled. > >> At our platforms, DEV1 use for win8,DEV2 use for win7,DEV1 use for Linux. > >> If these devices are disabled when do init, they will always be > >> disabled ,so, work fine. > >> > >> At some of the platforms, the devices may be disabled during do the > >> first binding ,if their status are changed,do they not do re-binding ? > > Currently, the glue binding operation takes place when the device is > > created. In my mind, there is no re-binding operation after the device being > > created, Unless the device being removed and created again. > Thank you very much. > So, as your suggestion, it is a better solution to add a new function > for the same _ADR devices, I don't really think this is a good idea, because then it won't be clear when to use which version. Your patch kind of makes sense (although we don't need to initialize both local variables to 0), but the Tianyu's concern is valid in principle either. Perhaps it would be better to make do_acpi_find_child() return the disabled device if its the only one matching or the first enabled matching device otherwise? Rafael > >>> Hi Rafael: > >>> How about add a new function > >>> "acpi_get_children_with_same_addr" to return a list > >>> which contains all these child devices with same _ADR.And then do some > >>> special check in the specific > >>> bus glue callback. Since these cases are no common. > >>> > >>>> *ret_p = handle; > >>>> return AE_CTRL_TERMINATE; > >>>> } > >>>> -- > >>>> 1.8.1.2 > >>>> > >>>> > >>>> -- > >>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > >>>> the body of a message to majordomo@vger.kernel.org > >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html > >>> > >>> > >>> > >>> -- > >>> Best regards > >>> Tianyu Lan > > > > > > > > -- > > Best regards > > Tianyu Lan > -- > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ACPI:add _STA evaluating at do_acpi_find_child() 2013-05-23 0:06 ` Rafael J. Wysocki @ 2013-05-23 12:56 ` Lan Tianyu 2013-05-23 22:00 ` Rafael J. Wysocki 2013-05-24 8:21 ` Jeff Wu 1 sibling, 1 reply; 13+ messages in thread From: Lan Tianyu @ 2013-05-23 12:56 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Jeff Wu, linux-acpi, Len Brown, lekensteyn, Sergio Perez, shane.huang, Aaron Lu 2013/5/23 Rafael J. Wysocki <rjw@sisk.pl>: > On Wednesday, May 22, 2013 03:42:04 PM Jeff Wu wrote: >> 2013/5/22 Lan Tianyu <lantianyu1986@gmail.com>: >> > 2013/5/22 Jeff Wu <zlinuxkernel@gmail.com>: >> >> 2013/5/21 Lan Tianyu <lantianyu1986@gmail.com>: >> >>>> From: Jeff Wu <zlinuxkernel@gmail.com> >> >>> Will this affect other devices? Since the device maybe disabled during >> >>> do binding with ACPI. >> >>> After some operations, the device would be enabled. >> >> At our platforms, DEV1 use for win8,DEV2 use for win7,DEV1 use for Linux. >> >> If these devices are disabled when do init, they will always be >> >> disabled ,so, work fine. >> >> >> >> At some of the platforms, the devices may be disabled during do the >> >> first binding ,if their status are changed,do they not do re-binding ? >> > Currently, the glue binding operation takes place when the device is >> > created. In my mind, there is no re-binding operation after the device being >> > created, Unless the device being removed and created again. >> Thank you very much. >> So, as your suggestion, it is a better solution to add a new function >> for the same _ADR devices, > > I don't really think this is a good idea, because then it won't be clear when > to use which version. Ok. How about make them as one function?. New function will return all the children's handle with same _ADR and the number of children. The caller should check the number. If the number is 1 and then do eveything that now have done. If the number is larger than 1. It should select one according their strategy. There is another such issue. In this case, the first child should be selected. http://www.spinics.net/lists/linux-acpi/msg39739.html > > Your patch kind of makes sense (although we don't need to initialize both > local variables to 0), but the Tianyu's concern is valid in principle either. > > Perhaps it would be better to make do_acpi_find_child() return the disabled > device if its the only one matching or the first enabled matching device > otherwise? > > Rafael > > -- Best regards Tianyu Lan ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ACPI:add _STA evaluating at do_acpi_find_child() 2013-05-23 12:56 ` Lan Tianyu @ 2013-05-23 22:00 ` Rafael J. Wysocki 2013-05-24 8:22 ` Jeff Wu 0 siblings, 1 reply; 13+ messages in thread From: Rafael J. Wysocki @ 2013-05-23 22:00 UTC (permalink / raw) To: Lan Tianyu Cc: Jeff Wu, linux-acpi, Len Brown, lekensteyn, Sergio Perez, shane.huang, Aaron Lu On Thursday, May 23, 2013 08:56:32 PM Lan Tianyu wrote: > 2013/5/23 Rafael J. Wysocki <rjw@sisk.pl>: > > On Wednesday, May 22, 2013 03:42:04 PM Jeff Wu wrote: > >> 2013/5/22 Lan Tianyu <lantianyu1986@gmail.com>: > >> > 2013/5/22 Jeff Wu <zlinuxkernel@gmail.com>: > >> >> 2013/5/21 Lan Tianyu <lantianyu1986@gmail.com>: > >> >>>> From: Jeff Wu <zlinuxkernel@gmail.com> > >> >>> Will this affect other devices? Since the device maybe disabled during > >> >>> do binding with ACPI. > >> >>> After some operations, the device would be enabled. > >> >> At our platforms, DEV1 use for win8,DEV2 use for win7,DEV1 use for Linux. > >> >> If these devices are disabled when do init, they will always be > >> >> disabled ,so, work fine. > >> >> > >> >> At some of the platforms, the devices may be disabled during do the > >> >> first binding ,if their status are changed,do they not do re-binding ? > >> > Currently, the glue binding operation takes place when the device is > >> > created. In my mind, there is no re-binding operation after the device being > >> > created, Unless the device being removed and created again. > >> Thank you very much. > >> So, as your suggestion, it is a better solution to add a new function > >> for the same _ADR devices, > > > > I don't really think this is a good idea, because then it won't be clear when > > to use which version. > Ok. How about make them as one function?. > New function will return all the children's handle with same _ADR and the number > of children. The caller should check the number. If the number is 1 and then > do eveything that now have done. If the number is larger than 1. It should > select one according their strategy. Why do you think that the callers may have different strategies? They are subsystems, not drivers. > There is another such issue. In this case, the first child should be selected. > http://www.spinics.net/lists/linux-acpi/msg39739.html No, that's about something different. Thanks, Rafael > > Your patch kind of makes sense (although we don't need to initialize both > > local variables to 0), but the Tianyu's concern is valid in principle either. > > > > Perhaps it would be better to make do_acpi_find_child() return the disabled > > device if its the only one matching or the first enabled matching device > > otherwise? > > > > Rafael > > > > > > -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ACPI:add _STA evaluating at do_acpi_find_child() 2013-05-23 22:00 ` Rafael J. Wysocki @ 2013-05-24 8:22 ` Jeff Wu 0 siblings, 0 replies; 13+ messages in thread From: Jeff Wu @ 2013-05-24 8:22 UTC (permalink / raw) To: Rafael J. Wysocki, Lan Tianyu Cc: linux-acpi, Len Brown, lekensteyn, Sergio Perez, shane.huang, Aaron Lu 2013/5/24 Rafael J. Wysocki <rjw@sisk.pl>: > On Thursday, May 23, 2013 08:56:32 PM Lan Tianyu wrote: >> 2013/5/23 Rafael J. Wysocki <rjw@sisk.pl>: >> > On Wednesday, May 22, 2013 03:42:04 PM Jeff Wu wrote: >> >> 2013/5/22 Lan Tianyu <lantianyu1986@gmail.com>: >> >> > 2013/5/22 Jeff Wu <zlinuxkernel@gmail.com>: >> >> >> 2013/5/21 Lan Tianyu <lantianyu1986@gmail.com>: >> >> >>>> From: Jeff Wu <zlinuxkernel@gmail.com> >> >> >>> Will this affect other devices? Since the device maybe disabled during >> >> >>> do binding with ACPI. >> >> >>> After some operations, the device would be enabled. >> >> >> At our platforms, DEV1 use for win8,DEV2 use for win7,DEV1 use for Linux. >> >> >> If these devices are disabled when do init, they will always be >> >> >> disabled ,so, work fine. >> >> >> >> >> >> At some of the platforms, the devices may be disabled during do the >> >> >> first binding ,if their status are changed,do they not do re-binding ? >> >> > Currently, the glue binding operation takes place when the device is >> >> > created. In my mind, there is no re-binding operation after the device being >> >> > created, Unless the device being removed and created again. >> >> Thank you very much. >> >> So, as your suggestion, it is a better solution to add a new function >> >> for the same _ADR devices, >> > >> > I don't really think this is a good idea, because then it won't be clear when >> > to use which version. >> Ok. How about make them as one function?. >> New function will return all the children's handle with same _ADR and the number >> of children. The caller should check the number. If the number is 1 and then >> do eveything that now have done. If the number is larger than 1. It should >> select one according their strategy. > > Why do you think that the callers may have different strategies? They are > subsystems, not drivers. > >> There is another such issue. In this case, the first child should be selected. >> http://www.spinics.net/lists/linux-acpi/msg39739.html > > No, that's about something different. Thanks, Rafel and Lan,TianYu > > Thanks, > Rafael > > >> > Your patch kind of makes sense (although we don't need to initialize both >> > local variables to 0), but the Tianyu's concern is valid in principle either. >> > >> > Perhaps it would be better to make do_acpi_find_child() return the disabled >> > device if its the only one matching or the first enabled matching device >> > otherwise? >> > >> > Rafael >> > >> > >> >> > -- > I speak only for myself. > Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ACPI:add _STA evaluating at do_acpi_find_child() 2013-05-23 0:06 ` Rafael J. Wysocki 2013-05-23 12:56 ` Lan Tianyu @ 2013-05-24 8:21 ` Jeff Wu 2013-05-24 21:46 ` Rafael J. Wysocki 1 sibling, 1 reply; 13+ messages in thread From: Jeff Wu @ 2013-05-24 8:21 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Lan Tianyu, linux-acpi, Len Brown, lekensteyn, Sergio Perez, shane.huang, Aaron Lu 2013/5/23 Rafael J. Wysocki <rjw@sisk.pl>: > On Wednesday, May 22, 2013 03:42:04 PM Jeff Wu wrote: >> 2013/5/22 Lan Tianyu <lantianyu1986@gmail.com>: >> > 2013/5/22 Jeff Wu <zlinuxkernel@gmail.com>: >> >> 2013/5/21 Lan Tianyu <lantianyu1986@gmail.com>: >> >>>> From: Jeff Wu <zlinuxkernel@gmail.com> >> >>>> >> >>>> Once do_acpi_find_child() found the first matching handle, it makes the acpi_get_child() >> >>>> loop stop and return the matching handle. But, at some of the platforms, a "_ADR" is >> >>>> with the multiple devices, and if one is enabled, the others will be disabled. >> >>>> Just like a case: >> >>>> Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV0 >> >>>> Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV1 >> >>>> Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV2 >> >>>> >> >>>> If DEV0 and DEV1 are disabled and DEV2 is enabled, the target is to get DEV2 handle, but >> >>>> actually it always return the first disabled device DEV0 handle. So add a _STA evaluating >> >>>> at do_acpi_find_child() to check the device status. If the object exists, but it is disabled, >> >>>> acpi_get_child() will continue looping to get the correct handle that the object exists and >> >>>> is enabled. >> >>>> >> >>>> >> >>>> Signed-off-by: Jeff Wu <zlinuxkernel@gmail.com> >> >>>> --- >> >>>> drivers/acpi/glue.c | 5 ++++- >> >>>> 1 file changed, 4 insertions(+), 1 deletion(-) >> >>>> >> >>>> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c >> >>>> index 40a84cc..ace6c2e 100644 >> >>>> --- a/drivers/acpi/glue.c >> >>>> +++ b/drivers/acpi/glue.c >> >>>> @@ -81,11 +81,14 @@ static struct acpi_bus_type *acpi_get_bus_type(struct device *dev) >> >>>> static acpi_status do_acpi_find_child(acpi_handle handle, u32 lvl_not_used, >> >>>> void *addr_p, void **ret_p) >> >>>> { >> >>>> - unsigned long long addr; >> >>>> acpi_status status; >> >>>> + unsigned long long addr = 0, sta = 0; >> >>>> >> >>>> status = acpi_evaluate_integer(handle, METHOD_NAME__ADR, NULL, &addr); >> >>>> if (ACPI_SUCCESS(status) && addr == *((u64 *)addr_p)) { >> >>>> + status = acpi_bus_get_status_handle(handle, &sta); >> >>>> + if (ACPI_SUCCESS(status) && !(sta & ACPI_STA_DEVICE_ENABLED)) >> >>>> + return AE_CTRL_DEPTH; >> >>> Will this affect other devices? Since the device maybe disabled during >> >>> do binding with ACPI. >> >>> After some operations, the device would be enabled. >> >> At our platforms, DEV1 use for win8,DEV2 use for win7,DEV1 use for Linux. >> >> If these devices are disabled when do init, they will always be >> >> disabled ,so, work fine. >> >> >> >> At some of the platforms, the devices may be disabled during do the >> >> first binding ,if their status are changed,do they not do re-binding ? >> > Currently, the glue binding operation takes place when the device is >> > created. In my mind, there is no re-binding operation after the device being >> > created, Unless the device being removed and created again. >> Thank you very much. >> So, as your suggestion, it is a better solution to add a new function >> for the same _ADR devices, > > I don't really think this is a good idea, because then it won't be clear when > to use which version. > > Your patch kind of makes sense (although we don't need to initialize both > local variables to 0), but the Tianyu's concern is valid in principle either. > > Perhaps it would be better to make do_acpi_find_child() return the disabled > device if its the only one matching or the first enabled matching device > otherwise? Hi Rafael, Thanks, i will try it , if it is ok, i will send out the patch. > > Rafael > > >> >>> Hi Rafael: >> >>> How about add a new function >> >>> "acpi_get_children_with_same_addr" to return a list >> >>> which contains all these child devices with same _ADR.And then do some >> >>> special check in the specific >> >>> bus glue callback. Since these cases are no common. >> >>> >> >>>> *ret_p = handle; >> >>>> return AE_CTRL_TERMINATE; >> >>>> } >> >>>> -- >> >>>> 1.8.1.2 >> >>>> >> >>>> >> >>>> -- >> >>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in >> >>>> the body of a message to majordomo@vger.kernel.org >> >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >>> >> >>> >> >>> >> >>> -- >> >>> Best regards >> >>> Tianyu Lan >> > >> > >> > >> > -- >> > Best regards >> > Tianyu Lan >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > I speak only for myself. > Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] ACPI:add _STA evaluating at do_acpi_find_child() 2013-05-24 8:21 ` Jeff Wu @ 2013-05-24 21:46 ` Rafael J. Wysocki 0 siblings, 0 replies; 13+ messages in thread From: Rafael J. Wysocki @ 2013-05-24 21:46 UTC (permalink / raw) To: Jeff Wu Cc: Lan Tianyu, linux-acpi, Len Brown, lekensteyn, Sergio Perez, shane.huang, Aaron Lu On Friday, May 24, 2013 04:21:03 PM Jeff Wu wrote: > 2013/5/23 Rafael J. Wysocki <rjw@sisk.pl>: > > On Wednesday, May 22, 2013 03:42:04 PM Jeff Wu wrote: > >> 2013/5/22 Lan Tianyu <lantianyu1986@gmail.com>: > >> > 2013/5/22 Jeff Wu <zlinuxkernel@gmail.com>: > >> >> 2013/5/21 Lan Tianyu <lantianyu1986@gmail.com>: > >> >>>> From: Jeff Wu <zlinuxkernel@gmail.com> > >> >>>> > >> >>>> Once do_acpi_find_child() found the first matching handle, it makes the acpi_get_child() > >> >>>> loop stop and return the matching handle. But, at some of the platforms, a "_ADR" is > >> >>>> with the multiple devices, and if one is enabled, the others will be disabled. > >> >>>> Just like a case: > >> >>>> Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV0 > >> >>>> Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV1 > >> >>>> Address : 0x1FFFF ; handle : SB_PCI0.SATA.DEV2 > >> >>>> > >> >>>> If DEV0 and DEV1 are disabled and DEV2 is enabled, the target is to get DEV2 handle, but > >> >>>> actually it always return the first disabled device DEV0 handle. So add a _STA evaluating > >> >>>> at do_acpi_find_child() to check the device status. If the object exists, but it is disabled, > >> >>>> acpi_get_child() will continue looping to get the correct handle that the object exists and > >> >>>> is enabled. > >> >>>> > >> >>>> > >> >>>> Signed-off-by: Jeff Wu <zlinuxkernel@gmail.com> > >> >>>> --- > >> >>>> drivers/acpi/glue.c | 5 ++++- > >> >>>> 1 file changed, 4 insertions(+), 1 deletion(-) > >> >>>> > >> >>>> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c > >> >>>> index 40a84cc..ace6c2e 100644 > >> >>>> --- a/drivers/acpi/glue.c > >> >>>> +++ b/drivers/acpi/glue.c > >> >>>> @@ -81,11 +81,14 @@ static struct acpi_bus_type *acpi_get_bus_type(struct device *dev) > >> >>>> static acpi_status do_acpi_find_child(acpi_handle handle, u32 lvl_not_used, > >> >>>> void *addr_p, void **ret_p) > >> >>>> { > >> >>>> - unsigned long long addr; > >> >>>> acpi_status status; > >> >>>> + unsigned long long addr = 0, sta = 0; > >> >>>> > >> >>>> status = acpi_evaluate_integer(handle, METHOD_NAME__ADR, NULL, &addr); > >> >>>> if (ACPI_SUCCESS(status) && addr == *((u64 *)addr_p)) { > >> >>>> + status = acpi_bus_get_status_handle(handle, &sta); > >> >>>> + if (ACPI_SUCCESS(status) && !(sta & ACPI_STA_DEVICE_ENABLED)) > >> >>>> + return AE_CTRL_DEPTH; > >> >>> Will this affect other devices? Since the device maybe disabled during > >> >>> do binding with ACPI. > >> >>> After some operations, the device would be enabled. > >> >> At our platforms, DEV1 use for win8,DEV2 use for win7,DEV1 use for Linux. > >> >> If these devices are disabled when do init, they will always be > >> >> disabled ,so, work fine. > >> >> > >> >> At some of the platforms, the devices may be disabled during do the > >> >> first binding ,if their status are changed,do they not do re-binding ? > >> > Currently, the glue binding operation takes place when the device is > >> > created. In my mind, there is no re-binding operation after the device being > >> > created, Unless the device being removed and created again. > >> Thank you very much. > >> So, as your suggestion, it is a better solution to add a new function > >> for the same _ADR devices, > > > > I don't really think this is a good idea, because then it won't be clear when > > to use which version. > > > > Your patch kind of makes sense (although we don't need to initialize both > > local variables to 0), but the Tianyu's concern is valid in principle either. > > > > Perhaps it would be better to make do_acpi_find_child() return the disabled > > device if its the only one matching or the first enabled matching device > > otherwise? > > Hi Rafael, > Thanks, i will try it , if it is ok, i will send out the patch. Yes, please. Thanks, Rafael > >> >>> Hi Rafael: > >> >>> How about add a new function > >> >>> "acpi_get_children_with_same_addr" to return a list > >> >>> which contains all these child devices with same _ADR.And then do some > >> >>> special check in the specific > >> >>> bus glue callback. Since these cases are no common. > >> >>> > >> >>>> *ret_p = handle; > >> >>>> return AE_CTRL_TERMINATE; > >> >>>> } > >> >>>> -- > >> >>>> 1.8.1.2 > >> >>>> > >> >>>> > >> >>>> -- > >> >>>> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > >> >>>> the body of a message to majordomo@vger.kernel.org > >> >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html > >> >>> > >> >>> > >> >>> > >> >>> -- > >> >>> Best regards > >> >>> Tianyu Lan > >> > > >> > > >> > > >> > -- > >> > Best regards > >> > Tianyu Lan > >> -- > >> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > >> the body of a message to majordomo@vger.kernel.org > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > > I speak only for myself. > > Rafael J. Wysocki, Intel Open Source Technology Center. -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2013-05-24 21:37 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-05-21 11:19 [PATCH] ACPI:add _STA evaluating at do_acpi_find_child() jeff.wu 2013-05-21 4:13 ` Jeff Wu 2013-05-21 13:34 ` Lan Tianyu 2013-05-21 14:21 ` Lan Tianyu 2013-05-22 3:27 ` Jeff Wu 2013-05-22 6:41 ` Lan Tianyu 2013-05-22 7:42 ` Jeff Wu 2013-05-23 0:06 ` Rafael J. Wysocki 2013-05-23 12:56 ` Lan Tianyu 2013-05-23 22:00 ` Rafael J. Wysocki 2013-05-24 8:22 ` Jeff Wu 2013-05-24 8:21 ` Jeff Wu 2013-05-24 21:46 ` Rafael J. Wysocki
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.