| Message ID | 20210101125629.20974-1-jiaxun.yang@flygoat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | IdeaPad platform profile support | expand |
Hi, On 1/1/21 1:56 PM, Jiaxun Yang wrote: > Tested on Lenovo Yoga-14SARE Chinese Edition. > > Jiaxun Yang (2): > ACPI: platform-profile: Introduce data parameter to handler > platform/x86: ideapad-laptop: DYTC Platform profile support > > drivers/acpi/platform_profile.c | 4 +- > drivers/platform/x86/Kconfig | 1 + > drivers/platform/x86/ideapad-laptop.c | 281 ++++++++++++++++++++++++++ > include/linux/platform_profile.h | 5 +- > 4 files changed, 287 insertions(+), 4 deletions(-) Thank you for your series, unfortunately the "ACPI: platform-profile: Introduce data parameter to handler" patch causes a conflict with the pending: "[PATCH v8 3/3] platform/x86: thinkpad_acpi: Add platform profile support" patch. But I do agree that adding that data parameter makes sense, so it might be best to merge: "ACPI: platform-profile: Introduce data parameter to handler" First and then rebase the thinkpad_acpi patch on top. Rafael, do you think you could add: "ACPI: platform-profile: Introduce data parameter to handler" To the 2 ACPI: platform-profile patches which you already have pending for 5.11-rc# ? Regards, Hans
On Mon, Jan 4, 2021 at 3:36 PM Hans de Goede <hdegoede@redhat.com> wrote: > > Hi, > > On 1/1/21 1:56 PM, Jiaxun Yang wrote: > > Tested on Lenovo Yoga-14SARE Chinese Edition. > > > > Jiaxun Yang (2): > > ACPI: platform-profile: Introduce data parameter to handler > > platform/x86: ideapad-laptop: DYTC Platform profile support > > > > drivers/acpi/platform_profile.c | 4 +- > > drivers/platform/x86/Kconfig | 1 + > > drivers/platform/x86/ideapad-laptop.c | 281 ++++++++++++++++++++++++++ > > include/linux/platform_profile.h | 5 +- > > 4 files changed, 287 insertions(+), 4 deletions(-) > > > Thank you for your series, unfortunately the > "ACPI: platform-profile: Introduce data parameter to handler" > patch causes a conflict with the pending: > "[PATCH v8 3/3] platform/x86: thinkpad_acpi: Add platform profile support" > patch. > > But I do agree that adding that data parameter makes sense, so > it might be best to merge: > > "ACPI: platform-profile: Introduce data parameter to handler" > > First and then rebase the thinkpad_acpi patch on top. > > Rafael, do you think you could add: > > "ACPI: platform-profile: Introduce data parameter to handler" > > To the 2 ACPI: platform-profile patches which you already have pending for 5.11-rc# ? I'm not sure why that patch is needed at all, because whoever registers a platform profile handler needs to have access to the original handler object anyway. Also, on a somewhat related note, I'm afraid that it may not be a good idea to push this series for 5.11-rc in the face of recent objections against new material going in after the merge window. Cheers!
Hi, On 1/4/21 9:33 PM, Rafael J. Wysocki wrote: > On Mon, Jan 4, 2021 at 3:36 PM Hans de Goede <hdegoede@redhat.com> wrote: >> >> Hi, >> >> On 1/1/21 1:56 PM, Jiaxun Yang wrote: >>> Tested on Lenovo Yoga-14SARE Chinese Edition. >>> >>> Jiaxun Yang (2): >>> ACPI: platform-profile: Introduce data parameter to handler >>> platform/x86: ideapad-laptop: DYTC Platform profile support >>> >>> drivers/acpi/platform_profile.c | 4 +- >>> drivers/platform/x86/Kconfig | 1 + >>> drivers/platform/x86/ideapad-laptop.c | 281 ++++++++++++++++++++++++++ >>> include/linux/platform_profile.h | 5 +- >>> 4 files changed, 287 insertions(+), 4 deletions(-) >> >> >> Thank you for your series, unfortunately the >> "ACPI: platform-profile: Introduce data parameter to handler" >> patch causes a conflict with the pending: >> "[PATCH v8 3/3] platform/x86: thinkpad_acpi: Add platform profile support" >> patch. >> >> But I do agree that adding that data parameter makes sense, so >> it might be best to merge: >> >> "ACPI: platform-profile: Introduce data parameter to handler" >> >> First and then rebase the thinkpad_acpi patch on top. >> >> Rafael, do you think you could add: >> >> "ACPI: platform-profile: Introduce data parameter to handler" >> >> To the 2 ACPI: platform-profile patches which you already have pending for 5.11-rc# ? > > I'm not sure why that patch is needed at all, because whoever > registers a platform profile handler needs to have access to the > original handler object anyway. True, I was actually thinking that instead of the data argument, we might pass a pointer to the original handler object like this: @@ -64,7 +64,7 @@ static ssize_t platform_profile_show(struct device *dev, return -ENODEV; } - err = cur_profile->profile_get(&profile); + err = cur_profile->profile_get(cur_profile, &profile); mutex_unlock(&profile_lock); if (err) return err; And then the driver which has registered the cur_profile, can get to its own data by using container of on the cur_profile pointer. With the code currently in your bleeding-edge branch, there is no way for any driver-code to get to its own (possibly/likely dynamically allocated) driver-data struct. E.g. a typical driver using only dynamic data tied to device_get_drvdata, might have this: struct driver_data { ... struct platform_profile_handler profile_handler; ... }; int probe(...) { struct driver_data *my_data; my_data = devm_kzalloc(dev, sizeof(*my_data), GFP_KERNEL); ... ret = platform_profile_register(&my_data->profile_handler); ... } And with the change which I suggest above would then be able to get the struct driver_data *my_data back from the profile_get callback by using container_of on the struct platform_profile_handler *profile_handler argument added to the profile_get callback. I know that the platform_profile stuff is intended to only have a single provider, so this could use global variables, but some drivers which may be a provider use 0 global variables (other then module_params) atm and it would be a lot cleaner from the pov of the design of these drivers to be able to do something like the pseudo code above. Which is why I added my Reviewed-by to patch 1/2 of the series from this thread. Patch 1/2 does use a slightly different approach then I suggest above, thinking more about this it would be cleaner IMHO to just pass the cur_profile pointer to the callbacks as the pseudo-code patch which I wrote above does. Drivers which use globals can then just ignore the extra argument (and keep the platform_profile_handler struct const) where as drivers which use dynamic allocation can embed the struct in their driver's data-struct. > Also, on a somewhat related note, I'm afraid that it may not be a good > idea to push this series for 5.11-rc in the face of recent objections > against new material going in after the merge window. That is fine with me, since this did not make rc1 (nor rc2) I'm not entirely comfortable with sending out a late pull-req for the pdx86 side of this either, so lets postpone this to 5.12 (sorry Mark). Rafael, once we have the discussion with the passing a pointer back to the drivers data thing resolved (and a patch merged for that if we go that route) can you provide me with an immutable branch to merge into pdx86/for-next so that I can then merge the pdx86 bits on top ? Note this does not need to be done right now around say rc4 would be fine, so that we have some time for the patches currently in bleeding-edge to settle a bit. Regards, Hans
On 04/01/2021 15:58, Hans de Goede wrote: > Hi, > > On 1/4/21 9:33 PM, Rafael J. Wysocki wrote: >> On Mon, Jan 4, 2021 at 3:36 PM Hans de Goede <hdegoede@redhat.com> >> wrote: >>> >>> Hi, >>> >>> On 1/1/21 1:56 PM, Jiaxun Yang wrote: >>>> Tested on Lenovo Yoga-14SARE Chinese Edition. >>>> <snip> > >> Also, on a somewhat related note, I'm afraid that it may not be a >> good idea to push this series for 5.11-rc in the face of recent >> objections against new material going in after the merge window. > > That is fine with me, since this did not make rc1 (nor rc2) I'm not > entirely comfortable with sending out a late pull-req for the pdx86 > side of this either, so lets postpone this to 5.12 (sorry Mark). It is what it is. > > Rafael, once we have the discussion with the passing a pointer back > to the drivers data thing resolved (and a patch merged for that if we > go that route) can you provide me with an immutable branch to merge > into pdx86/for-next so that I can then merge the pdx86 bits on top ? > > Note this does not need to be done right now around say rc4 would be > fine, so that we have some time for the patches currently in > bleeding-edge to settle a bit. > Just for my understanding of what happens next....please correct me if I have anything wrong: - platform_profile gets pulled from ACPI for 5.11 - platform_profile gets updated to add this data/pointer implementation and goes into 5.12. Jiaxun, let me know if you're happy with following up on that based on Hans suggestions, If you are pushed for time let me know and I'll happily help out/implement/test as required. I sadly don't have any ideapads but very happy to support your efforts any way I can. - Can we get the x86 portion done at the same time or does that end up going to 5.13? I had been looking at the ideapad_laptop.c patch and have some concerns there as Jiaxun's patch is essentially a duplicate of what I implemented in thinkpad_acpi.c which doesn't seem to be ideal (especially as there is a V6 version of DYTC coming out this year). I haven't had time to look at code to consider better alternatives though... Mark
在 2021/1/5 上午5:58, Mark Pearson 写道: > On 04/01/2021 15:58, Hans de Goede wrote: >> Hi, >> >> On 1/4/21 9:33 PM, Rafael J. Wysocki wrote: >>> On Mon, Jan 4, 2021 at 3:36 PM Hans de Goede <hdegoede@redhat.com> >>> wrote: >>>> Hi, >>>> >>>> On 1/1/21 1:56 PM, Jiaxun Yang wrote: >>>>> Tested on Lenovo Yoga-14SARE Chinese Edition. >>>>> [...] > Just for my understanding of what happens next....please correct me if I > have anything wrong: > > - platform_profile gets pulled from ACPI for 5.11 > > - platform_profile gets updated to add this data/pointer implementation > and goes into 5.12. Hi all, Another approach could be just let all the patch go through pdx86 tree and with pointer part acked by Rafael as it's unlikely to have merge conflicts. > Jiaxun, let me know if you're happy with following > up on that based on Hans suggestions, If you are pushed for time let me > know and I'll happily help out/implement/test as required. I sadly don't > have any ideapads but very happy to support your efforts any way I can. I'm happy with Hans suggestion, will send v2 for it later. I've been ask Lenovo engineers about DYTC and other ideapad ACPI stuff on Lenovo China forum[1], but moderator here told me Lenovo won't invest any Linux effort on their consumer product line :-( Is it possible to publish a DYTC specification or documents to help us further understand these mechanisms? I'm tired of reading disassembly AML and code to figure out these internals. > > - Can we get the x86 portion done at the same time or does that end up > going to 5.13? I had been looking at the ideapad_laptop.c patch and have > some concerns there as Jiaxun's patch is essentially a duplicate of what > I implemented in thinkpad_acpi.c which doesn't seem to be ideal > (especially as there is a V6 version of DYTC coming out this year). I > haven't had time to look at code to consider better alternatives though... It may be worthy to share these code but I'm comfort to have this duplication as I'm unsure about the future of DYTC. Will DYTC for thinkpads always coherent with DYTC for ideapads? Thanks. [1]: https://club.lenovo.com.cn/thread-5980431-1-1.html - Jiaxun > > Mark
Hi, On 1/4/21 10:58 PM, Mark Pearson wrote: > On 04/01/2021 15:58, Hans de Goede wrote: >> Hi, >> >> On 1/4/21 9:33 PM, Rafael J. Wysocki wrote: >>> On Mon, Jan 4, 2021 at 3:36 PM Hans de Goede <hdegoede@redhat.com> >>> wrote: >>>> >>>> Hi, >>>> >>>> On 1/1/21 1:56 PM, Jiaxun Yang wrote: >>>>> Tested on Lenovo Yoga-14SARE Chinese Edition. >>>>> > <snip> >> >>> Also, on a somewhat related note, I'm afraid that it may not be a >>> good idea to push this series for 5.11-rc in the face of recent >>> objections against new material going in after the merge window. >> >> That is fine with me, since this did not make rc1 (nor rc2) I'm not >> entirely comfortable with sending out a late pull-req for the pdx86 >> side of this either, so lets postpone this to 5.12 (sorry Mark). > It is what it is. > >> >> Rafael, once we have the discussion with the passing a pointer back >> to the drivers data thing resolved (and a patch merged for that if we >> go that route) can you provide me with an immutable branch to merge >> into pdx86/for-next so that I can then merge the pdx86 bits on top ? >> >> Note this does not need to be done right now around say rc4 would be >> fine, so that we have some time for the patches currently in >> bleeding-edge to settle a bit. >> > Just for my understanding of what happens next....please correct me if I > have anything wrong: > > - platform_profile gets pulled from ACPI for 5.11 > > - platform_profile gets updated to add this data/pointer implementation > and goes into 5.12. Jiaxun, let me know if you're happy with following > up on that based on Hans suggestions, If you are pushed for time let me > know and I'll happily help out/implement/test as required. I sadly don't > have any ideapads but very happy to support your efforts any way I can. > > - Can we get the x86 portion done at the same time or does that end up > going to 5.13? No, the plan is to get it all in 5.12. This is why I asked Rafael for an immutable branch with the ACPI bits, then I can merge that branch into pdx86/for-next and then apply the thinkpad and ideapad patches on top, all for 5.12 . Regards, Hans
Hi Jiaxun, On 05/01/2021 01:24, Jiaxun Yang wrote: > 在 2021/1/5 上午5:58, Mark Pearson 写道: >> On 04/01/2021 15:58, Hans de Goede wrote: >>> Hi, >>> >>> On 1/4/21 9:33 PM, Rafael J. Wysocki wrote: >>>> On Mon, Jan 4, 2021 at 3:36 PM Hans de Goede <hdegoede@redhat.com> >>>> wrote: >>>>> Hi, >>>>> >>>>> On 1/1/21 1:56 PM, Jiaxun Yang wrote: >>>>>> Tested on Lenovo Yoga-14SARE Chinese Edition. >>>>>> > [...] >> Just for my understanding of what happens next....please correct me if I >> have anything wrong: >> >> - platform_profile gets pulled from ACPI for 5.11 >> >> - platform_profile gets updated to add this data/pointer implementation >> and goes into 5.12. > Hi all, > > Another approach could be just let all the patch go through pdx86 tree > and with > pointer part acked by Rafael as it's unlikely to have merge conflicts. > >> Jiaxun, let me know if you're happy with following >> up on that based on Hans suggestions, If you are pushed for time let me >> know and I'll happily help out/implement/test as required. I sadly don't >> have any ideapads but very happy to support your efforts any way I can. > > > I'm happy with Hans suggestion, will send v2 for it later. > > I've been ask Lenovo engineers about DYTC and other ideapad ACPI > stuff on Lenovo China forum[1], but moderator here told me Lenovo won't > invest any Linux effort on their consumer product line :-( > > Is it possible to publish a DYTC specification or documents to help us > further > understand these mechanisms? > > I'm tired of reading disassembly AML and code to figure out these > internals. > I hear you :) Afraid I'm not allowed to publish the full DYTC spec - but I make public the bits that I can. I don't have many hooks into the ideapad team as it's not in the Linux plan - so I can't answer your questions with confidence. I am going to ask the firmware team if they can confirm if ideapad is using the same spec - it would make sense if they are. Feel free to bug me off mailing list and I'll happily help out with any debugging issues. I'm also not allowed to confirm or deny future plans but my personal hope is that the Linux project in Lenovo grows. Fingers crossed for the future. >> >> - Can we get the x86 portion done at the same time or does that end up >> going to 5.13? I had been looking at the ideapad_laptop.c patch and have >> some concerns there as Jiaxun's patch is essentially a duplicate of what >> I implemented in thinkpad_acpi.c which doesn't seem to be ideal >> (especially as there is a V6 version of DYTC coming out this year). I >> haven't had time to look at code to consider better alternatives >> though... > > It may be worthy to share these code but I'm comfort to have this > duplication as I'm > unsure about the future of DYTC. Will DYTC for thinkpads always coherent > with DYTC > for ideapads? I'll see if I can find out. > > Thanks. > > [1]: https://club.lenovo.com.cn/thread-5980431-1-1.html > > - Jiaxun > >> >> Mark >
On Mon, Jan 4, 2021 at 9:58 PM Hans de Goede <hdegoede@redhat.com> wrote: > > Hi, > > On 1/4/21 9:33 PM, Rafael J. Wysocki wrote: > > On Mon, Jan 4, 2021 at 3:36 PM Hans de Goede <hdegoede@redhat.com> wrote: > >> > >> Hi, > >> > >> On 1/1/21 1:56 PM, Jiaxun Yang wrote: > >>> Tested on Lenovo Yoga-14SARE Chinese Edition. > >>> > >>> Jiaxun Yang (2): > >>> ACPI: platform-profile: Introduce data parameter to handler > >>> platform/x86: ideapad-laptop: DYTC Platform profile support > >>> > >>> drivers/acpi/platform_profile.c | 4 +- > >>> drivers/platform/x86/Kconfig | 1 + > >>> drivers/platform/x86/ideapad-laptop.c | 281 ++++++++++++++++++++++++++ > >>> include/linux/platform_profile.h | 5 +- > >>> 4 files changed, 287 insertions(+), 4 deletions(-) > >> > >> > >> Thank you for your series, unfortunately the > >> "ACPI: platform-profile: Introduce data parameter to handler" > >> patch causes a conflict with the pending: > >> "[PATCH v8 3/3] platform/x86: thinkpad_acpi: Add platform profile support" > >> patch. > >> > >> But I do agree that adding that data parameter makes sense, so > >> it might be best to merge: > >> > >> "ACPI: platform-profile: Introduce data parameter to handler" > >> > >> First and then rebase the thinkpad_acpi patch on top. > >> > >> Rafael, do you think you could add: > >> > >> "ACPI: platform-profile: Introduce data parameter to handler" > >> > >> To the 2 ACPI: platform-profile patches which you already have pending for 5.11-rc# ? > > > > I'm not sure why that patch is needed at all, because whoever > > registers a platform profile handler needs to have access to the > > original handler object anyway. > > True, I was actually thinking that instead of the data argument, we might > pass a pointer to the original handler object like this: > > @@ -64,7 +64,7 @@ static ssize_t platform_profile_show(struct device *dev, > return -ENODEV; > } > > - err = cur_profile->profile_get(&profile); > + err = cur_profile->profile_get(cur_profile, &profile); > mutex_unlock(&profile_lock); > if (err) > return err; I would prefer this approach. > > And then the driver which has registered the cur_profile, can get to > its own data by using container of on the cur_profile pointer. > > With the code currently in your bleeding-edge branch, there is no way > for any driver-code to get to its own (possibly/likely dynamically > allocated) driver-data struct. > > E.g. a typical driver using only dynamic data tied to device_get_drvdata, > might have this: > > struct driver_data { > ... > struct platform_profile_handler profile_handler; > ... > }; > > int probe(...) { > struct driver_data *my_data; > > my_data = devm_kzalloc(dev, sizeof(*my_data), GFP_KERNEL); > > ... > > ret = platform_profile_register(&my_data->profile_handler); > ... > } > > And with the change which I suggest above would then be able to > get the struct driver_data *my_data back from the profile_get callback by > using container_of on the struct platform_profile_handler *profile_handler > argument added to the profile_get callback. OK, fair enough. > I know that the platform_profile stuff is intended to only have a > single provider, so this could use global variables, but some > drivers which may be a provider use 0 global variables (other then > module_params) atm and it would be a lot cleaner from the pov > of the design of these drivers to be able to do something like the > pseudo code above. Which is why I added my Reviewed-by to patch 1/2 > of the series from this thread. > > Patch 1/2 does use a slightly different approach then I suggest above, > thinking more about this it would be cleaner IMHO to just pass the > cur_profile pointer to the callbacks as the pseudo-code patch which I > wrote above does. Drivers which use globals can then just ignore > the extra argument (and keep the platform_profile_handler struct const) > where as drivers which use dynamic allocation can embed the struct in > their driver's data-struct. Agreed. > > Also, on a somewhat related note, I'm afraid that it may not be a good > > idea to push this series for 5.11-rc in the face of recent objections > > against new material going in after the merge window. > > That is fine with me, since this did not make rc1 (nor rc2) I'm not entirely > comfortable with sending out a late pull-req for the pdx86 side of this > either, so lets postpone this to 5.12 (sorry Mark). > > Rafael, once we have the discussion with the passing a pointer back to > the drivers data thing resolved (and a patch merged for that if we go > that route) can you provide me with an immutable branch to merge into > pdx86/for-next so that I can then merge the pdx86 bits on top ? Sure, no problem. > Note this does not need to be done right now around say rc4 would be fine, > so that we have some time for the patches currently in bleeding-edge to > settle a bit. OK Cheers!
Hi, On 1/5/21 6:18 PM, Rafael J. Wysocki wrote: > On Mon, Jan 4, 2021 at 9:58 PM Hans de Goede <hdegoede@redhat.com> wrote: <snip> >> Patch 1/2 does use a slightly different approach then I suggest above, >> thinking more about this it would be cleaner IMHO to just pass the >> cur_profile pointer to the callbacks as the pseudo-code patch which I >> wrote above does. Drivers which use globals can then just ignore >> the extra argument (and keep the platform_profile_handler struct const) >> where as drivers which use dynamic allocation can embed the struct in >> their driver's data-struct. > > Agreed. Note that Jiaxun has provided a v2 of this patch-set with patch 1/2 implementing the new approach. Can you merge merge that patch please and then once you're happy that this has seen enough exposure in -next, provide me with an immutable branch with the 3 platform-profile patches in it ? Regards, Hans
On Wed, Jan 6, 2021 at 10:17 AM Hans de Goede <hdegoede@redhat.com> wrote: > > Hi, > > On 1/5/21 6:18 PM, Rafael J. Wysocki wrote: > > On Mon, Jan 4, 2021 at 9:58 PM Hans de Goede <hdegoede@redhat.com> wrote: > > <snip> > > >> Patch 1/2 does use a slightly different approach then I suggest above, > >> thinking more about this it would be cleaner IMHO to just pass the > >> cur_profile pointer to the callbacks as the pseudo-code patch which I > >> wrote above does. Drivers which use globals can then just ignore > >> the extra argument (and keep the platform_profile_handler struct const) > >> where as drivers which use dynamic allocation can embed the struct in > >> their driver's data-struct. > > > > Agreed. > > Note that Jiaxun has provided a v2 of this patch-set with patch 1/2 implementing > the new approach. > > Can you merge merge that patch please and then once you're happy that this > has seen enough exposure in -next, provide me with an immutable branch with > the 3 platform-profile patches in it ? I will, thanks!