public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: linux-acpi@vger.kernel.org, driver-core@lists.linux.dev,
	linux-kernel@vger.kernel.org, Daniel Scally <djrscally@gmail.com>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Danilo Krummrich <dakr@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Guenter Roeck <linux@roeck-us.net>
Subject: Re: [PATCH v1 1/1] device property: Document how to check for the property presence
Date: Wed, 18 Mar 2026 10:03:27 +0200	[thread overview]
Message-ID: <abpcT5Yqfi5_SjKR@ashevche-desk.local> (raw)
In-Reply-To: <abnVTODs9fOqF9eV@kekkonen.localdomain>

On Wed, Mar 18, 2026 at 12:27:24AM +0200, Sakari Ailus wrote:
> On Tue, Mar 17, 2026 at 10:08:28PM +0100, Andy Shevchenko wrote:

...

> > + * In order to check for the property presence, use device_property_present().
> 
> Do you really think we should add this clause for each of these functions?

Yes, as Guenter pointed out that this has to be documented clearly.

> I don't think it belongs here.

And? What should we do then (taking into account my below comments)?

> The error code list doesn't document what is returned if a property doesn't
> exist (-EINVAL) and it'd be helpful to add this.

No, this change is exactly against this. Because using an error code that may
cover not only that case is at bare minimum fragile and layering violation.
APIs that require to know the implementation details are not good APIs.

> It would have been best to have a separate error code for this albeit
> changing this now might not be that troublesome either: very, very few
> callers depend on receiving such an error code but there are still many
> callers.

I'm against this because we have already a dedicated API to check for property
presence, why do we need to have another (confusing!) way of doing the same?

Having a dedicated code may help to debug, but shouldn't be used as a main
feature in my opinion.

-- 
With Best Regards,
Andy Shevchenko



  parent reply	other threads:[~2026-03-18  8:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-17 21:08 [PATCH v1 1/1] device property: Document how to check for the property presence Andy Shevchenko
2026-03-17 22:27 ` Sakari Ailus
2026-03-17 22:32   ` Guenter Roeck
2026-03-18  8:03   ` Andy Shevchenko [this message]
2026-03-18  9:10     ` Sakari Ailus
2026-03-18  9:41       ` Andy Shevchenko
2026-03-18 11:26         ` Sakari Ailus
2026-03-18 14:16           ` Andy Shevchenko
2026-03-18  8:04 ` Geert Uytterhoeven

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=abpcT5Yqfi5_SjKR@ashevche-desk.local \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=dakr@kernel.org \
    --cc=djrscally@gmail.com \
    --cc=driver-core@lists.linux.dev \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=rafael@kernel.org \
    --cc=sakari.ailus@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox