On 10/4/24 12:57 PM, Dan Williams wrote: > kernel test robot wrote: >> Hi David, >> >> kernel test robot noticed the following build warnings: >> >> [auto build test WARNING on 431c39f6d3edbab14f48dbf37a58ccdc0ac3be1e] >> >> url: https://github.com/intel-lab-lkp/linux/commits/David-Lechner/iio-core-make-iio_device_claim_direct_mode-__must_check/20241002-233644 >> base: 431c39f6d3edbab14f48dbf37a58ccdc0ac3be1e >> patch link: https://lore.kernel.org/r/20241002-iio-must-check-claim-direct-v1-1-ab94ce728731%40baylibre.com >> patch subject: [PATCH] iio: core: make iio_device_claim_direct_mode() __must_check > [..] >>>> include/linux/iio/iio.h:669:50: warning: ignoring return value of function declared with 'warn_unused_result' attribute [-Wunused-result] >> 669 | DEFINE_GUARD(iio_claim_direct, struct iio_dev *, iio_device_claim_direct_mode(_T), > > So I think this points to the fact that iio_device_claim_direct_mode() > should not be using DEFINE_GUARD() in the first instance. I think > iio_claim_direct() really wants to be using DEFINE_CLASS() directly. > Skip usage of DEFINE_GUARD() which I now see is unable to interoperate > with a __must_check locking function. > > Perhaps the new class can be something like: > > DEFINE_GUARD_EXCL_COND() > > ...which creates a guard that is exclusively conditional and has no > unconditional flavor. However, maybe that only lives in iio unless and > until another user arrives. Hmm... I see what you mean. All other conditional guards (e.g. mutex_trylock) have an unconditional counterpart (mutex_lock) that is used with DEFINE_GUARD.
