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

Message-ID: <YfK1mZQ0BTyDgNUB@smile.fi.intel.com>
Date:   Thu, 27 Jan 2022 17:09:13 +0200
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Peter Rosin <peda@...ntia.se>
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 Thu, Jan 27, 2022 at 01:11:14PM +0100, Peter Rosin wrote:
> 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.

No problem and thanks for your comments!

-- 
With Best Regards,
Andy Shevchenko