X86 platform drivers
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Luke Jones <luke@ljones.dev>
Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	platform-driver-x86@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	acpi4asus-user@lists.sourceforge.net, hdegoede@redhat.com,
	corentin.chary@gmail.com, markgross@kernel.org,
	jdelvare@suse.com
Subject: Re: [PATCH v2 1/1] platform/x86: asus-wmi: add support for ASUS screenpad
Date: Fri, 5 May 2023 21:43:44 -0700	[thread overview]
Message-ID: <17fb02ff-e2d8-9c0b-3de6-670c82fee997@roeck-us.net> (raw)
In-Reply-To: <M8X7UR.MPEZYPQ0PU4F1@ljones.dev>

On 5/5/23 20:48, Luke Jones wrote:
> 
> 
> On Fri, May 5 2023 at 18:30:36 -0700, Guenter Roeck <linux@roeck-us.net> wrote:
>> On 5/5/23 16:43, Luke Jones wrote:
>>>
>>>
>>> On Fri, May 5 2023 at 16:08:16 +0300, Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote:
>>>> On Fri, 5 May 2023, Luke D. Jones wrote:
>>>>
>>>>>  Add support for the WMI methods used to turn off and adjust the
>>>>>  brightness of the secondary "screenpad" device found on some high-end
>>>>>  ASUS laptops like the GX650P series and others.
>>>>>
>>>>>  These methods are utilised in a new backlight device named:
>>>>>  - asus_screenpad
>>>>>
>>>>>  Signed-off-by: Luke D. Jones <luke@ljones.dev>
>>>>>  ---
>>>>>   .../ABI/testing/sysfs-platform-asus-wmi       |   2 +-
>>>>>   drivers/platform/x86/asus-wmi.c               | 132 ++++++++++++++++++
>>>>>   drivers/platform/x86/asus-wmi.h               |   1 +
>>>>>   include/linux/platform_data/x86/asus-wmi.h    |   4 +
>>>>>   4 files changed, 138 insertions(+), 1 deletion(-)
>>>>>
>>>>>  diff --git a/Documentation/ABI/testing/sysfs-platform-asus-wmi b/Documentation/ABI/testing/sysfs-platform-asus-wmi
>>>>>  index a77a004a1baa..df9817c6233a 100644
>>>>>  --- a/Documentation/ABI/testing/sysfs-platform-asus-wmi
>>>>>  +++ b/Documentation/ABI/testing/sysfs-platform-asus-wmi
>>>>>  @@ -97,4 +97,4 @@ Contact:    "Luke Jones" <luke@ljones.dev>
>>>>>   Description:
>>>>>           Enable an LCD response-time boost to reduce or remove ghosting:
>>>>>               * 0 - Disable,
>>>>>  -            * 1 - Enable
>>>>>  +            * 1 - Enable
>>>>>  \ No newline at end of file
>>>>
>>>> Spurious change?
>>>
>>> Indeed it is. Not sure how that occurred.
>>>
>>>>
>>>>>  diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
>>>>>  index 1038dfdcdd32..0528eef02ef7 100644
>>>>>  --- a/drivers/platform/x86/asus-wmi.c
>>>>>  +++ b/drivers/platform/x86/asus-wmi.c
>>>>>  @@ -200,6 +200,7 @@ struct asus_wmi {
>>>>>
>>>>>       struct input_dev *inputdev;
>>>>>       struct backlight_device *backlight_device;
>>>>>  +    struct backlight_device *screenpad_backlight_device;
>>>>>       struct platform_device *platform_device;
>>>>>
>>>>>       struct led_classdev wlan_led;
>>>>>  @@ -3208,6 +3209,129 @@ static int is_display_toggle(int code)
>>>>>       return 0;
>>>>>   }
>>>>>
>>>>>  +/* Screenpad backlight */
>>>>>  +
>>>>>  +static int read_screenpad_backlight_power(struct asus_wmi *asus)
>>>>>  +{
>>>>>  +    int ret = asus_wmi_get_devstate_simple(asus, ASUS_WMI_DEVID_SCREENPAD_POWER);
>>>>
>>>> Please move this to own line because now you have the extra newline
>>>> in between the call and error handling.
>>>
>>> I don't understand what you mean sorry. Remove the new line or:
>>> int ret;
>>> ret = asus_wmi_get_devstate_simple(asus, ASUS_WMI_DEVID_SCREENPAD_POWER);
>>>
>>>>
>>>>>  +
>>>>>  +    if (ret < 0)
>>>>>  +        return ret;
>>>>>  +    /* 1 == powered */
>>>>>  +    return ret ? FB_BLANK_UNBLANK : FB_BLANK_POWERDOWN;
>>>>>  +}
>>>>>  +
>>>>>  +static int read_screenpad_brightness(struct backlight_device *bd)
>>>>>  +{
>>>>>  +    struct asus_wmi *asus = bl_get_data(bd);
>>>>>  +    u32 retval;
>>>>>  +    int err;
>>>>>  +
>>>>>  +    err = read_screenpad_backlight_power(asus);
>>>>>  +    if (err < 0)
>>>>>  +        return err;
>>>>>  +    /* The device brightness can only be read if powered, so return stored */
>>>>>  +    if (err == FB_BLANK_POWERDOWN)
>>>>>  +        return asus->driver->screenpad_brightness;
>>>>>  +
>>>>>  +    err = asus_wmi_get_devstate(asus, ASUS_WMI_DEVID_SCREENPAD_LIGHT, &retval);
>>>>>  +    if (err < 0)
>>>>>  +        return err;
>>>>>  +
>>>>>  +    return retval & ASUS_WMI_DSTS_BRIGHTNESS_MASK;
>>>>>  +}
>>>>>  +
>>>>>  +static int update_screenpad_bl_status(struct backlight_device *bd)
>>>>>  +{
>>>>>  +    struct asus_wmi *asus = bl_get_data(bd);
>>>>>  +    int power, err = 0;
>>>>>  +    u32 ctrl_param;
>>>>>  +
>>>>>  +    power = read_screenpad_backlight_power(asus);
>>>>>  +    if (power == -ENODEV)
>>>>>  +        return err;
>>>>
>>>> Just return 0. Or is there perhaps something wrong/missing here?
>>>
>>> I thought the correct thing was to return any possible error state (here, anything less than 0 would be an error, right?)
>>>
>>
>> Well, yes, but you are not returning an error. You are returning 'err'
>> which is 0 at this point. So, at the very least, this code is (very)
>> misleading since it suggests that it would return some error
>> (as saved in the 'err' variable) when it doesn't.
>>
>> Guenter
>>
> 
> Oh! Right I see it now, I'm sorry, I just kept skipping over it somehow.
> 
> So I should change to:
>      power = read_screenpad_backlight_power(asus);
>      if (power < 0)
>          return power;
> 
> Is that acceptable?
> 

That depends on what the code is supposed to do. Right now it is
"If read_screenpad_backlight_power() returns -ENODEV, stop and return
no error (let the rest of the code continue). If it returns another error,
return it".
Changing the code as suggested above changes the semantics to
"If read_screenpad_backlight_power() returns an error, always return it".

Looking at the patch, I don't have a definite answer.
asus_screenpad_init() happily registers the backlight if
read_screenpad_backlight_power() returns -ENODEV. One could argue that
the other functions should thus handle that situation gracefully as well,
but read_screenpad_brightness() does return -ENODEV in that situation.
I think you should decide how you want to handle that case and handle
it consistently across all functions.

Either case, there is another problem in asus_screenpad_init():
If read_screenpad_brightness() fails, the function returns an error,
but does not unregister the backlight device.

Guenter


  reply	other threads:[~2023-05-06  4:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-05  4:30 [PATCH v2 0/1] platform/x86: asus-wmi: add support for ASUS screenpad Luke D. Jones
2023-05-05  4:30 ` [PATCH v2 1/1] " Luke D. Jones
2023-05-05 13:08   ` Ilpo Järvinen
2023-05-05 23:43     ` Luke Jones
2023-05-06  1:30       ` Guenter Roeck
2023-05-06  3:48         ` Luke Jones
2023-05-06  4:43           ` Guenter Roeck [this message]
2023-05-06  8:09             ` Luke Jones
2023-05-06 13:24               ` Guenter Roeck
2023-05-08  8:21       ` Ilpo Järvinen
2023-05-06 11:52 ` [PATCH v2 0/1] " Hans de Goede
2023-05-15 12:39   ` Hans de Goede
2023-05-15 22:34     ` Luke Jones
2023-05-25 11:09       ` Hans de Goede
2023-06-04  4:52         ` Luke Jones
2023-06-06  8:58           ` Hans de Goede
2023-06-06 22:45             ` Luke Jones
2023-06-13 10:27               ` 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=17fb02ff-e2d8-9c0b-3de6-670c82fee997@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=acpi4asus-user@lists.sourceforge.net \
    --cc=corentin.chary@gmail.com \
    --cc=hdegoede@redhat.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=jdelvare@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luke@ljones.dev \
    --cc=markgross@kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    /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