linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luke Jones <luke@ljones.dev>
To: "Barnabás Pőcze" <pobrn@protonmail.com>
Cc: hdegoede@redhat.com, corentin.chary@gmail.com,
	mgross@linux.intel.com, jdelvare@suse.com, linux@roeck-us.net,
	platform-driver-x86@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] asus-wmi: Add dgpu disable method
Date: Sat, 17 Jul 2021 11:09:19 +1200	[thread overview]
Message-ID: <JN1DWQ.EEHJJGGRQTP72@ljones.dev> (raw)
In-Reply-To: <knw744OJB1AYrrFpo77N1Eei0JZC3SjKzg6SMoMhOsEchAiE8-klOIPTyFCAUSiVeTopPNqgFSefQJ2av6Gs_cS4TuIRXVQcHUxvw8YvSl0=@protonmail.com>

Thank you for the insightful feedback.

On Mon, Jul 5 2021 at 00:47:31 +0000, Barnabás Pőcze 
<pobrn@protonmail.com> wrote:
> Hi
> 
> I have added a couple comments inline.
> 
> 
> 2021. július 5., hétfő 0:21 keltezéssel, Luke D. Jones írta:
> 
>>  In Windows the ASUS Armory Crate progrm can enable or disable the
>                                         ^
> "program"
> 
My "a" key is a little hard to press sometimes :(

> 
>>  dGPU via a WMI call. This functions much the same as various Linux
>>  methods in software where the dGPU is removed from the device tree.
>> 
>>  However the WMI call saves the state of dGPU enabled or not and this
> 
> I think "[...] the WMI call saves whether the dGPU is enabled or not, 
> and [...]"
> might be better.
> Or "[...] the WMI call saves the state of the dGPU (enabled or not) 
> and [...]".
> 
I've used the second option, thanks for pointing this out.

> 
>>  then changes the dGPU visibility in Linux with no way for Linux
>>  users to re-enable it. We expose the WMI method so users can see
>>  and change the dGPU ACPI state.
>> 
>>  Signed-off-by: Luke D. Jones <luke@ljones.dev>
>>  ---
>>   drivers/platform/x86/asus-wmi.c            | 98 
>> ++++++++++++++++++++++
>>   include/linux/platform_data/x86/asus-wmi.h |  3 +
>>   2 files changed, 101 insertions(+)
>> 
>>  diff --git a/drivers/platform/x86/asus-wmi.c 
>> b/drivers/platform/x86/asus-wmi.c
>>  index 2468076d6cd8..8dc3f7ed021f 100644
>>  --- a/drivers/platform/x86/asus-wmi.c
>>  +++ b/drivers/platform/x86/asus-wmi.c
>>  @@ -210,6 +210,9 @@ struct asus_wmi {
>>   	u8 fan_boost_mode_mask;
>>   	u8 fan_boost_mode;
>> 
>>  +	bool dgpu_disable_available;
>>  +	u8 dgpu_disable_mode;
>>  +
>>   	bool throttle_thermal_policy_available;
>>   	u8 throttle_thermal_policy_mode;
>> 
>>  @@ -427,6 +430,93 @@ static void 
>> lid_flip_tablet_mode_get_state(struct asus_wmi *asus)
>>   	}
>>   }
>> 
>>  +/* dGPU 
>> ********************************************************************/
>>  +static int dgpu_disable_check_present(struct asus_wmi *asus)
>>  +{
>>  +	u32 result;
>>  +	int err;
>>  +
>>  +	asus->dgpu_disable_available = false;
>>  +
>>  +	err = asus_wmi_get_devstate(asus, ASUS_WMI_DEVID_DGPU, &result);
>>  +	if (err) {
>>  +		if (err == -ENODEV)
>>  +			return 0;
>>  +		return err;
>>  +	}
>>  +
>>  +	if (result & ASUS_WMI_DSTS_PRESENCE_BIT)
>>  +		asus->dgpu_disable_available = true;
>>  +		asus->dgpu_disable_mode = result & ASUS_WMI_DSTS_STATUS_BIT;
>>  +
> 
> Aren't braces missing here?
> 
Yep. Fixed.

> 
>>  +	return 0;
>>  +}
>>  +
>>  +static int dgpu_disable_write(struct asus_wmi *asus)
>>  +{
>>  +	int err;
>>  +	u8 value;
>>  +	u32 retval;
>>  +
>>  +	value = asus->dgpu_disable_mode;
>>  +
>>  +	err = asus_wmi_set_devstate(ASUS_WMI_DEVID_DGPU, value, &retval);
>>  +
>>  +	sysfs_notify(&asus->platform_device->dev.kobj, NULL,
>>  +			"dgpu_disable");
> 
> A similar line with the exact same length in patch 3/3 is not broken 
> in two.
> And shouldn't the notification be sent if the operation succeeded?
> 
Fixed. I moved the sysfs_notify down below the error returns.
> 
>>  +
>>  +	if (err) {
>>  +		pr_warn("Failed to set dgpu disable: %d\n", err);
>>  +		return err;
>>  +	}
>>  +
>>  +	if (retval > 1 || retval < 0) {
>>  +		pr_warn("Failed to set dgpu disable (retval): 0x%x\n",
>>  +			retval);
>>  +		return -EIO;
>>  +	}
>>  +
>>  +	return 0;
>>  +}
>>  +
>>  +static ssize_t dgpu_disable_show(struct device *dev,
>>  +				   struct device_attribute *attr, char *buf)
>>  +{
>>  +	struct asus_wmi *asus = dev_get_drvdata(dev);
>>  +	u8 mode = asus->dgpu_disable_mode;
>>  +
>>  +	return scnprintf(buf, PAGE_SIZE, "%d\n", mode);
> 
> You could use `sysfs_emit()`.
> 
Thanks. Many things like this I'm actually unaware of. Most of these 
patches are done by reading existing code.

> 
>>  +}
>>  +
>>  +static ssize_t dgpu_disable_store(struct device *dev,
>>  +				    struct device_attribute *attr,
>>  +				    const char *buf, size_t count)
>>  +{
>>  +	int result;
>>  +	u8 disable;
>>  +	struct asus_wmi *asus = dev_get_drvdata(dev);
>>  +
>>  +	result = kstrtou8(buf, 10, &disable);
> 
> You could use `kstrtobool()`. I think that would be better since it 
> accepts
> 'y', 'n', etc. in addition to 0 and 1.
> 
Thanks! Wasn't aware of that. And since the setting for all 3 patches 
can only ever be 0/1 I've changed to use a bool instead of u8

> 
>>  +	if (result < 0)
>>  +		return result;
>>  +
>>  +	if (disable > 1 || disable < 0)
>>  +		return -EINVAL;
>>  +
>>  +	asus->dgpu_disable_mode = disable;
>>  +	/*
>>  +	 * The ACPI call used does not save the mode unless the call is 
>> run twice.
>>  +	 * Once to disable, then once to check status and save - this is 
>> two code
>>  +	 * paths in the method in the ACPI dumps.
>>  +	*/
>>  +	dgpu_disable_write(asus);
>>  +	dgpu_disable_write(asus);
> 
> Is there any reason the potential error codes are not returned?
> 
No I've fixed now. Guess I missed it.

> 
>>  +
>>  +	return count;
>>  +}
>>  +
>>  +static DEVICE_ATTR_RW(dgpu_disable);
>>  +
>>   /* Battery 
>> ********************************************************************/
>> 
>>   /* The battery maximum charging percentage */
>>  @@ -2412,6 +2502,7 @@ static struct attribute 
>> *platform_attributes[] = {
>>   	&dev_attr_camera.attr,
>>   	&dev_attr_cardr.attr,
>>   	&dev_attr_touchpad.attr,
>>  +	&dev_attr_dgpu_disable.attr,
>>   	&dev_attr_lid_resume.attr,
>>   	&dev_attr_als_enable.attr,
>>   	&dev_attr_fan_boost_mode.attr,
>>  @@ -2438,6 +2529,8 @@ static umode_t asus_sysfs_is_visible(struct 
>> kobject *kobj,
>>   		devid = ASUS_WMI_DEVID_LID_RESUME;
>>   	else if (attr == &dev_attr_als_enable.attr)
>>   		devid = ASUS_WMI_DEVID_ALS_ENABLE;
>>  +	else if (attr == &dev_attr_dgpu_disable.attr)
>>  +		ok = asus->dgpu_disable_available;
>>   	else if (attr == &dev_attr_fan_boost_mode.attr)
>>   		ok = asus->fan_boost_mode_available;
>>   	else if (attr == &dev_attr_throttle_thermal_policy.attr)
>>  @@ -2699,6 +2792,10 @@ static int asus_wmi_add(struct 
>> platform_device *pdev)
>>   	if (err)
>>   		goto fail_platform;
>> 
>>  +	err = dgpu_disable_check_present(asus);
>>  +	if (err)
>>  +		goto fail_dgpu_disable;
>>  +
> 
> Should this really be considered a "fatal" error?
> 
I was modelling this on fail_fan_boost_mode and 
fail_throttle_thermal_policy since a laptop can't have both of those 
which indicates that a failed one is fine, it seemed appropriate to 
follow the same behaviour here

> 
>>   	err = fan_boost_mode_check_present(asus);
>>   	if (err)
>>   		goto fail_fan_boost_mode;
>>  @@ -2799,6 +2896,7 @@ static int asus_wmi_add(struct 
>> platform_device *pdev)
>>   fail_sysfs:
>>   fail_throttle_thermal_policy:
>>   fail_fan_boost_mode:
>>  +fail_dgpu_disable:
>>   fail_platform:
>>   fail_panel_od:
>>   	kfree(asus);
>>  diff --git a/include/linux/platform_data/x86/asus-wmi.h 
>> b/include/linux/platform_data/x86/asus-wmi.h
>>  index 428aea701c7b..a528f9d0e4b7 100644
>>  --- a/include/linux/platform_data/x86/asus-wmi.h
>>  +++ b/include/linux/platform_data/x86/asus-wmi.h
>>  @@ -90,6 +90,9 @@
>>   /* Keyboard dock */
>>   #define ASUS_WMI_DEVID_KBD_DOCK		0x00120063
>> 
>>  +/* dgpu on/off */
>>  +#define ASUS_WMI_DEVID_DGPU		0x00090020
>>  +
>>   /* DSTS masks */
>>   #define ASUS_WMI_DSTS_STATUS_BIT	0x00000001
>>   #define ASUS_WMI_DSTS_UNKNOWN_BIT	0x00000002
>>  --
>>  2.31.1
> 
> 
> Regards,
> Barnabás Pőcze

Many thanks for your feedback again.
Luke.



  parent reply	other threads:[~2021-07-16 23:09 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-04 22:21 [PATCH 0/3] Support for ASUS egpu, dpgu disable, panel overdrive Luke D. Jones
2021-07-04 22:21 ` [PATCH 1/3] asus-wmi: Add panel overdrive functionality Luke D. Jones
2021-07-04 23:48   ` kernel test robot
2021-07-06 10:07   ` Hans de Goede
2021-07-06 10:08   ` Hans de Goede
2021-07-04 22:21 ` [PATCH 2/3] asus-wmi: Add dgpu disable method Luke D. Jones
2021-07-05  0:47   ` Barnabás Pőcze
2021-07-06 10:17     ` Hans de Goede
2021-07-08 17:09       ` Barnabás Pőcze
2021-07-16 23:09     ` Luke Jones [this message]
2021-07-06 10:10   ` Hans de Goede
2021-07-16 23:12     ` Luke Jones
2021-07-04 22:21 ` [PATCH 3/3] asus-wmi: Add egpu enable method Luke D. Jones
2021-07-06 10:19   ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=JN1DWQ.EEHJJGGRQTP72@ljones.dev \
    --to=luke@ljones.dev \
    --cc=corentin.chary@gmail.com \
    --cc=hdegoede@redhat.com \
    --cc=jdelvare@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=mgross@linux.intel.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=pobrn@protonmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).