All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: "Ruhl, Michael J" <michael.j.ruhl@intel.com>
Cc: "platform-driver-x86@vger.kernel.org"
	<platform-driver-x86@vger.kernel.org>,
	 "intel-xe@lists.freedesktop.org"
	<intel-xe@lists.freedesktop.org>,
	 Hans de Goede <hdegoede@redhat.com>,
	 "De Marchi, Lucas" <lucas.demarchi@intel.com>,
	 "Vivi, Rodrigo" <rodrigo.vivi@intel.com>
Subject: RE: [PATCH 03/10] platform/x86/intel/pmt: use guard(mutex)
Date: Mon, 2 Jun 2025 18:37:33 +0300 (EEST)	[thread overview]
Message-ID: <267e6423-9a3d-1c84-4feb-72ffb22c72fb@linux.intel.com> (raw)
In-Reply-To: <IA1PR11MB64187A2A2AD7E977C579745CC162A@IA1PR11MB6418.namprd11.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 3593 bytes --]

On Mon, 2 Jun 2025, Ruhl, Michael J wrote:

> >-----Original Message-----
> >From: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> >Sent: Saturday, May 31, 2025 1:24 AM
> >To: Ruhl, Michael J <michael.j.ruhl@intel.com>
> >Cc: platform-driver-x86@vger.kernel.org; intel-xe@lists.freedesktop.org; Hans
> >de Goede <hdegoede@redhat.com>; De Marchi, Lucas
> ><lucas.demarchi@intel.com>; Vivi, Rodrigo <rodrigo.vivi@intel.com>
> >Subject: Re: [PATCH 03/10] platform/x86/intel/pmt: use guard(mutex)
> >
> >On Fri, 30 May 2025, Michael J. Ruhl wrote:
> >
> >> Update the mutex paths to use the new guard() mechanism.
> >>
> >> With the removal of goto, do some minor cleanup of the current
> >> logic path.
> >>
> >> Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
> >> ---
> >>  drivers/platform/x86/intel/pmt/crashlog.c | 32 +++++++++++------------
> >>  1 file changed, 15 insertions(+), 17 deletions(-)
> >>
> >> diff --git a/drivers/platform/x86/intel/pmt/crashlog.c
> >b/drivers/platform/x86/intel/pmt/crashlog.c
> >> index d40c8e212733..c6d8a7a61d39 100644
> >> --- a/drivers/platform/x86/intel/pmt/crashlog.c
> >> +++ b/drivers/platform/x86/intel/pmt/crashlog.c
> >> @@ -155,9 +155,9 @@ enable_store(struct device *dev, struct
> >device_attribute *attr,
> >>  	if (result)
> >>  		return result;
> >>
> >> -	mutex_lock(&entry->control_mutex);
> >> +	guard(mutex)(&entry->control_mutex);
> >> +
> >>  	pmt_crashlog_set_disable(&entry->entry, !enabled);
> >> -	mutex_unlock(&entry->control_mutex);
> >>
> >>  	return count;
> >>  }
> >> @@ -189,26 +189,24 @@ trigger_store(struct device *dev, struct
> >device_attribute *attr,
> >>  	if (result)
> >>  		return result;
> >>
> >> -	mutex_lock(&entry->control_mutex);
> >> +	guard(mutex)(&entry->control_mutex);
> >>
> >>  	if (!trigger) {
> >>  		pmt_crashlog_set_clear(&entry->entry);
> >> -	} else if (pmt_crashlog_complete(&entry->entry)) {
> >> -		/* we cannot trigger a new crash if one is still pending */
> >> -		result = -EEXIST;
> >> -		goto err;
> >> -	} else if (pmt_crashlog_disabled(&entry->entry)) {
> >> -		/* if device is currently disabled, return busy */
> >> -		result = -EBUSY;
> >> -		goto err;
> >> -	} else {
> >> -		pmt_crashlog_set_execute(&entry->entry);
> >> +		return count;
> >>  	}
> >>
> >> -	result = count;
> >> -err:
> >> -	mutex_unlock(&entry->control_mutex);
> >> -	return result;
> >> +	/* we cannot trigger a new crash if one is still pending */
> >> +	if (pmt_crashlog_complete(&entry->entry))
> >> +		return -EEXIST;
> >> +
> >> +	/* if device is currently disabled, return busy */
> >> +	if (pmt_crashlog_disabled(&entry->entry))
> >> +		return -EBUSY;
> >> +
> >> +	pmt_crashlog_set_execute(&entry->entry);
> >> +
> >> +	return count;
> >>  }
> >>  static DEVICE_ATTR_RW(trigger);
> >
> >Thanks, the control flow is very straightforward after this change.
> 
> Checking for the disable bit after checking for the complete doesn't really make sense to me, 
> but I was concerned with "changing" the user experience...
> 
> Is this something that can be "updated"? (i.e. swapping the complete and disabled checks),

TBH, I wouldn't worry over changing the precedence of returned error 
codes so just go ahead with that change (but please make it in a 
separate patch so it would be easy to revert in the very unlikely case 
that somebody depends on the old behavior).

> >Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
> 
> Thanks!
> 
> M
> 
> >
> >
> >--
> > i.
> 

-- 
 i.

  reply	other threads:[~2025-06-02 15:37 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-30 20:33 [PATCH 01/10] drm/xe: Correct BMG VSEC header sizing Michael J. Ruhl
2025-05-30 20:33 ` [PATCH 02/10] platform/x86/intel/pmt: white space cleanup Michael J. Ruhl
2025-05-31  5:19   ` Ilpo Järvinen
2025-05-30 20:33 ` [PATCH 03/10] platform/x86/intel/pmt: use guard(mutex) Michael J. Ruhl
2025-05-31  5:23   ` Ilpo Järvinen
2025-06-02 14:59     ` Ruhl, Michael J
2025-06-02 15:37       ` Ilpo Järvinen [this message]
2025-05-30 20:33 ` [PATCH 04/10] platform/x86/intel: refactor endpoint usage Michael J. Ruhl
2025-05-31  5:29   ` Ilpo Järvinen
2025-06-02 15:01     ` Ruhl, Michael J
2025-05-30 20:33 ` [PATCH 05/10] platform/x86/intel/pmt: crashlog binary file endpoint Michael J. Ruhl
2025-05-31  5:36   ` Ilpo Järvinen
2025-06-02 15:02     ` Ruhl, Michael J
2025-05-30 20:33 ` [PATCH 06/10] platform/x86/intel/pmt: decouple sysfs and namespace Michael J. Ruhl
2025-05-30 20:33 ` [PATCH 07/10] platform/x86/intel/pmt: use a version struct Michael J. Ruhl
2025-05-31  5:46   ` Ilpo Järvinen
2025-06-02 17:57     ` Ruhl, Michael J
2025-06-03  7:06       ` Ilpo Järvinen
2025-05-30 20:33 ` [PATCH 08/10] platform/x86/intel/pmt: support BMG crashlog Michael J. Ruhl
2025-05-31  5:52   ` Ilpo Järvinen
2025-06-02 18:00     ` Ruhl, Michael J
2025-05-30 20:33 ` [PATCH 09/10] sysfs debug Michael J. Ruhl
2025-05-31  5:53   ` Ilpo Järvinen
2025-06-02 15:07     ` Ruhl, Michael J
2025-05-31  5:17 ` [PATCH 01/10] drm/xe: Correct BMG VSEC header sizing Ilpo Järvinen
2025-05-31  5:18   ` Ilpo Järvinen
2025-06-02 14:54   ` Ruhl, Michael J

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=267e6423-9a3d-1c84-4feb-72ffb22c72fb@linux.intel.com \
    --to=ilpo.jarvinen@linux.intel.com \
    --cc=hdegoede@redhat.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=michael.j.ruhl@intel.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rodrigo.vivi@intel.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 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.