linux-kernel - Re: [PATCH v2 5/5] iio: afe: iio-rescale: Re-use generic struct s32

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: <c3fac656-5c9b-4b39-f5e9-e3637f4d5746@axentia.se>
Date:   Thu, 27 Jan 2022 13:11:14 +0100
From:   Peter Rosin <peda@...ntia.se>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Liam Beguin <liambeguin@...il.com>,
        Jonathan Cameron <jic23@...nel.org>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        Andreas Kemnade <andreas@...nade.info>,
        linux-arm-msm@...r.kernel.org, linux-iio@...r.kernel.org,
        linux-kernel@...r.kernel.org, Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Lars-Peter Clausen <lars@...afoo.de>
Subject: Re: [PATCH v2 5/5] iio: afe: iio-rescale: Re-use generic struct
 s32_fract

On 2022-01-26 13:04, Andy Shevchenko wrote:
> On Wed, Jan 26, 2022 at 11:26:50AM +0100, Peter Rosin wrote:
>> It's easy to both remove and to add back "the bigger object". I just
>> don't see the point of the churn. Technically you can probably rearrange
>> stuff in probe and remove the 2nd argument to ->props() altogether and
>> chase pointers from the dev object instead. I don't see the point of
>> that either. It doesn't really make things simpler, it doesn't really
>> make things easier to read. To me, it's just pointless churn.
> 
> Since you still haven't got a point the conclusions are wrong.
> The point is (I dunno how more clear to make it) is to have proper
> layering from the (current) design perspective.
> 
> If we go to the road full of "if it will come XYZ then this sucks".
> The future is uncertain and neither of us may prove the current
> change good or bad in terms of the future (unknown and uncertain)
> changes.
> 
> Preventing this patch to land is to tell "Oh, my design is bad,
> but I will keep it, because in the future everything may change".
> So, why don't you make this future to be now?
> 
>>> TL;DR: It makes possible not to mix bananas with wooden boxes.
>>
>> Which is all good until you need to ship an apple in the box with the
>> bananas. (e.g. if you for some reason need the bananas to get ripe real
>> quick, apples produce ethylene)
> 
> Really. arguments about the future changes are weak. If you have
> patches in mind, send them, We will see in practice what you meant.

I can do one better - here are links to patches from 7-8 months ago.

https://lore.kernel.org/lkml/20210530005917.20953-1-liambeguin@gmail.com/
https://lore.kernel.org/lkml/20210530005917.20953-6-liambeguin@gmail.com/

Or, if you prefer, the latest revisions.

https://lore.kernel.org/lkml/20220108205319.2046348-9-liambeguin@gmail.com/
https://lore.kernel.org/lkml/20220108205319.2046348-14-liambeguin@gmail.com/

You have made review comments on that series.

My previous arguments were based on gut feel, and I'm sorry for not
thinking of the offset in the referred series before.

Cheers,
Peter