Re: [PATCH v2 5/5] iio: afe: iio-rescale: Re-use generic struct s32_fract

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx/
> https://lore.kernel.org/lkml/20210530005917.20953-6-liambeguin@xxxxxxxxx/
> 
> Or, if you prefer, the latest revisions.
> 
> https://lore.kernel.org/lkml/20220108205319.2046348-9-liambeguin@xxxxxxxxx/
> https://lore.kernel.org/lkml/20220108205319.2046348-14-liambeguin@xxxxxxxxx/
> 
> 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





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux