From: Hans de Goede <hdegoede@redhat.com>
To: lindsey.stanpoor@gmail.com, intel-gfx@lists.freedesktop.org,
linux-usb@vger.kernel.org
Cc: heikki.krogerus@linux.intel.com, gregkh@linuxfoundation.org,
cnemo@tutanota.com
Subject: Re: [PATCH 1/1] usb: typec: altmodes/displayport: reorder dp_altmode_configured()
Date: Fri, 8 Oct 2021 10:52:32 +0200 [thread overview]
Message-ID: <da805c7c-e5fb-74fc-4122-88f920fae533@redhat.com> (raw)
In-Reply-To: <20211006043257.23242-1-lindsey.stanpoor@gmail.com>
Hi,
On 10/6/21 6:32 AM, lindsey.stanpoor@gmail.com wrote:
> From: Cameron Nemo <cnemo@tutanota.com>
>
> A recent commit [1] introduced an unintended behavioral change by
> reordering certain function calls. The sysfs_notify call for
> pin_assignment should only be invoked when the dp_altmode_notify call
> returns 0, and in the dp->data.conf == 0 case.
>
> [1] https://lore.kernel.org/r/20210817215201.795062-8-hdegoede@redhat.com
>
> Signed-off-by: Cameron Nemo <cnemo@tutanota.com>
You are right that my commit changed the behavior I should have added
something about that to the commit message, *but* I believe
that the new behavior is correct and should be kept.
Even if the dp_altmode_notify() fails, then reading from
the pin_assignment sysfs file will still show the new pin-assignment,
so the contents of the sysfs file has changed and thus the notify is
the correct thing to do independent of the dp_altmode_notify()
return value.
Likewise if we have selected a pin_assignment ourselves and the
user tries to change this by writing to the pin_assignment sysfs
file, then we may get an async (so not signalled as an error
on the sysfs write syscall) CMDT_RSP_NAK to the new pin_assignment
at which point we set dp->data.conf = 0; and then call
dp_altmode_configured() and in this case again the
sysfs file "contents" has changed so we should do a notify.
More-over doing a syfs-notify when nothing has changed is really
not the end of the world, it is not like we are going to do this
100s of times per second.
IOW I believe that the new behavior although different is
correct (and the new code is also a lot more straight forward).
So NACK from me for this change.
Question, does this patch fix an actual problem which you were
seeing, or did you just notice this while reviewing the change ?
Regards,
Hans
> ---
> drivers/usb/typec/altmodes/displayport.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/typec/altmodes/displayport.c b/drivers/usb/typec/altmodes/displayport.c
> index c1d8c23baa39..a15ae78066e3 100644
> --- a/drivers/usb/typec/altmodes/displayport.c
> +++ b/drivers/usb/typec/altmodes/displayport.c
> @@ -154,10 +154,17 @@ static int dp_altmode_status_update(struct dp_altmode *dp)
>
> static int dp_altmode_configured(struct dp_altmode *dp)
> {
> + int ret;
> +
> sysfs_notify(&dp->alt->dev.kobj, "displayport", "configuration");
> +
> + ret = dp_altmode_notify(dp);
> + if (ret || !dp->data.conf)
> + return ret;
> +
> sysfs_notify(&dp->alt->dev.kobj, "displayport", "pin_assignment");
>
> - return dp_altmode_notify(dp);
> + return 0;
> }
>
> static int dp_altmode_configure_vdm(struct dp_altmode *dp, u32 conf)
>
prev parent reply other threads:[~2021-10-08 8:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-06 4:32 [PATCH 1/1] usb: typec: altmodes/displayport: reorder dp_altmode_configured() lindsey.stanpoor
2021-10-08 8:09 ` Heikki Krogerus
2021-10-08 8:52 ` Hans de Goede [this message]
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=da805c7c-e5fb-74fc-4122-88f920fae533@redhat.com \
--to=hdegoede@redhat.com \
--cc=cnemo@tutanota.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=lindsey.stanpoor@gmail.com \
--cc=linux-usb@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