linux-kernel - Re: [PATCH v2 1/4] iopoll: Generalize read_poll_timeout() into poll_timeout

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <cd2c7eb2b6877704534620098374075416514ce0@intel.com>
Date: Tue, 26 Aug 2025 13:56:34 +0300
From: Jani Nikula <jani.nikula@...el.com>
To: Ville Syrjälä <ville.syrjala@...ux.intel.com>,
 linux-kernel@...r.kernel.org
Cc: Lucas De Marchi <lucas.demarchi@...el.com>, Dibin Moolakadan
 Subrahmanian <dibin.moolakadan.subrahmanian@...el.com>, Imre Deak
 <imre.deak@...el.com>, David Laight <david.laight.linux@...il.com>, Geert
 Uytterhoeven <geert+renesas@...der.be>, Matt Wagantall
 <mattw@...eaurora.org>, Dejin Zheng <zhengdejin5@...il.com>,
 intel-gfx@...ts.freedesktop.org, intel-xe@...ts.freedesktop.org, Andrew
 Morton <akpm@...ux-foundation.org>, Sima Vetter <sima@...ll.ch>, Dave
 Airlie <airlied@...hat.com>
Subject: Re: [PATCH v2 1/4] iopoll: Generalize read_poll_timeout() into
 poll_timeout_us()

On Thu, 31 Jul 2025, Jani Nikula <jani.nikula@...el.com> wrote:
> On Tue, 15 Jul 2025, Ville Syrjälä <ville.syrjala@...ux.intel.com> wrote:
>> On Tue, Jul 08, 2025 at 04:16:34PM +0300, Ville Syrjala wrote:
>>> From: Ville Syrjälä <ville.syrjala@...ux.intel.com>
>>> 
>>> While read_poll_timeout() & co. were originally introduced just
>>> for simple I/O usage scenarios they have since been generalized to
>>> be useful in more cases.
>>> 
>>> However the interface is very cumbersome to use in the general case.
>>> Attempt to make it more flexible by combining the 'op', 'var' and
>>> 'args' parameter into just a single 'op' that the caller can fully
>>> specify.
>>> 
>>> For example i915 has one case where one might currently
>>> have to write something like:
>>> 	ret = read_poll_timeout(drm_dp_dpcd_read_byte, err,
>>> 				err || (status & mask),
>>> 				0 * 1000, 200 * 1000, false,
>>> 				aux, DP_FEC_STATUS, &status);
>>> which is practically illegible, but with the adjusted macro
>>> we do:
>>> 	ret = poll_timeout_us(err = drm_dp_dpcd_read_byte(aux, DP_FEC_STATUS, &status),
>>> 			      err || (status & mask),
>>> 			      0 * 1000, 200 * 1000, false);
>>> which much easier to understand.
>>> 
>>> One could even combine the 'op' and 'cond'  parameters into
>>> one, but that might make the caller a bit too unwieldly with
>>> assignments and checks being done on the same statement.
>>> 
>>> This makes poll_timeout_us() closer to the i915 __wait_for()
>>> macro, with the main difference being that __wait_for() uses
>>> expenential backoff as opposed to the fixed polling interval
>>> used by poll_timeout_us(). Eventually we might be able to switch
>>> (at least most of) i915 to use poll_timeout_us().
>>> 
>>> v2: Fix typos (Jani)
>>>     Fix delay_us docs for poll_timeout_us_atomic() (Jani)
>>> 
>>> Cc: Lucas De Marchi <lucas.demarchi@...el.com>
>>> Cc: Dibin Moolakadan Subrahmanian <dibin.moolakadan.subrahmanian@...el.com>
>>> Cc: Imre Deak <imre.deak@...el.com>
>>> Cc: David Laight <david.laight.linux@...il.com>
>>> Cc: Geert Uytterhoeven <geert+renesas@...der.be>
>>> Cc: Matt Wagantall <mattw@...eaurora.org>
>>> Cc: Dejin Zheng <zhengdejin5@...il.com>
>>> Cc: intel-gfx@...ts.freedesktop.org
>>> Cc: intel-xe@...ts.freedesktop.org
>>> Cc: linux-kernel@...r.kernel.org
>>> Reviewed-by: Jani Nikula <jani.nikula@...el.com>
>>> Signed-off-by: Ville Syrjälä <ville.syrjala@...ux.intel.com>
>>> ---
>>>  include/linux/iopoll.h | 110 +++++++++++++++++++++++++++++------------
>>>  1 file changed, 78 insertions(+), 32 deletions(-)
>>
>> Any thoughs how we should get this stuff in? Jani will need it for
>> some i915 stuff once he returns from vacation, so I could just push
>> it into drm-intel-next...
>>
>> Are people OK with that, or is there a better tree that could pick 
>> this up?
>
> Cc: Andrew
>
> The iopoll.h file is not in MAINTAINERS, and previous changes to it
> appear to have gone through various trees. I'd like to base follow-up
> work in i915 on this, but who could ack merging the patches via
> drm-intel-next? Though doesn't look like anyone's acked the earlier
> changes either...

Ville, can you submit this again, please?

If we don't get any feedback from anyone, I'm just going to merge this
via drm-intel-next.

Cc: Dave, Sima.


BR,
Jani.


-- 
Jani Nikula, Intel