linux-kernel - Re: [PATCH 1/5] drm: Add drm_fixed_16

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <YTBDbLzmf8aYInSM@pendragon.ideasonboard.com>
Date:   Thu, 2 Sep 2021 06:22:20 +0300
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Alyssa Rosenzweig <alyssa@...enzweig.io>
Cc:     dri-devel@...ts.freedesktop.org,
        Neil Armstrong <narmstrong@...libre.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Kevin Hilman <khilman@...libre.com>,
        Jerome Brunet <jbrunet@...libre.com>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        Rob Clark <robdclark@...il.com>, Sean Paul <sean@...rly.run>,
        Sandy Huang <hjc@...k-chips.com>,
        Heiko Stübner <heiko@...ech.de>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Abhinav Kumar <abhinavk@...eaurora.org>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Lee Jones <lee.jones@...aro.org>,
        Stephen Boyd <swboyd@...omium.org>,
        Kalyan Thota <kalyan_t@...eaurora.org>,
        Ville Syrjälä <ville.syrjala@...ux.intel.com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/5] drm: Add drm_fixed_16_16 helper

On Wed, Sep 01, 2021 at 09:35:40PM -0400, Alyssa Rosenzweig wrote:
> > Missing documentation :-)
> 
> Ack.
> 
> > > +static inline int drm_fixed_16_16(s32 mult, s32 div)
> > 
> > You should return a s32.
> 
> Ack.
> 
> > The function name isn't very explicit, and departs from the naming
> > scheme of other functions in the same file. As fixed-point numbers are
> > stored in a s64 for the drm_fixp_* helpers, we shouldn't rese the
> > drm_fixp_ prefix, maybe drm_fixp_s16_16_ would be a good prefix. The
> > function should probably be named drm_fixp_s16_16 from_fraction() then,
> > but then the same logic should possibly be replicated to ensure optimal
> > precision. I wonder if it wouldn't be best to simply use
> > drm_fixp_from_fraction() and shift the result right by 16 bits.
> 
> Sure, I'm not attached to the naming ... will wait to hear what colours
> everyone else wants the bikehed painted.
> 
> As for the implementation, I just went with what was used across
> multiple drivers already (no chance of regressions that way) but could
> reuse other helpers if it's better..? If the behaviour changes this goes
> from a trivial cleanup to a much more invasive changeset. I don't own
> half of the hardware here.

But except for msm which may need testing, all other drivers use the
existing FRAC_16_16() macro with constant arguments, so it shouldn't be
difficult to ensure that the new function gives the same results.

-- 
Regards,

Laurent Pinchart