linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Rosin <peda@axentia.se>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Liam Beguin <liambeguin@gmail.com>,
	Jonathan Cameron <jic23@kernel.org>,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Andreas Kemnade <andreas@kemnade.info>,
	linux-arm-msm@vger.kernel.org, linux-iio@vger.kernel.org,
	linux-kernel@vger.kernel.org, Andy Gross <agross@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Lars-Peter Clausen <lars@metafoo.de>
Subject: Re: [PATCH v2 5/5] iio: afe: iio-rescale: Re-use generic struct s32_fract
Date: Thu, 27 Jan 2022 13:11:14 +0100	[thread overview]
Message-ID: <c3fac656-5c9b-4b39-f5e9-e3637f4d5746@axentia.se> (raw)
In-Reply-To: <7bae39d5-7a38-ebdd-074a-6c140dc3a519@axentia.se>

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

  reply	other threads:[~2022-01-27 12:11 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-10 19:31 [PATCH v2 1/5] math.h: Introduce data types for fractional numbers Andy Shevchenko
2022-01-10 19:31 ` [PATCH v2 2/5] iio: adc: rn5t618: Re-use generic struct u16_fract Andy Shevchenko
2022-01-10 19:31 ` [PATCH v2 3/5] iio: adc: twl4030-madc: Re-use generic struct s16_fract Andy Shevchenko
2022-01-10 19:31 ` [PATCH v2 4/5] iio: adc: qcom-vadc-common: Re-use generic struct u32_fract Andy Shevchenko
2022-01-10 19:31 ` [PATCH v2 5/5] iio: afe: iio-rescale: Re-use generic struct s32_fract Andy Shevchenko
2022-01-15 18:52   ` Jonathan Cameron
2022-01-24 15:18     ` Andy Shevchenko
2022-01-24 15:19       ` Andy Shevchenko
2022-01-24 21:28       ` Liam Beguin
2022-01-25 13:17         ` Andy Shevchenko
2022-01-25 14:54           ` Peter Rosin
2022-01-25 18:17             ` Andy Shevchenko
2022-01-26 10:26               ` Peter Rosin
2022-01-26 12:04                 ` Andy Shevchenko
2022-01-26 12:35                   ` Peter Rosin
2022-01-26 13:01                     ` Andy Shevchenko
2022-01-27 11:03                       ` Peter Rosin
2022-01-27 12:11                         ` Peter Rosin [this message]
2022-01-27 15:09                           ` Andy Shevchenko
2022-01-27 15:08                         ` Andy Shevchenko
2022-01-26 15:54                   ` Liam Beguin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c3fac656-5c9b-4b39-f5e9-e3637f4d5746@axentia.se \
    --to=peda@axentia.se \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=agross@kernel.org \
    --cc=andreas@kemnade.info \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=jic23@kernel.org \
    --cc=lars@metafoo.de \
    --cc=liambeguin@gmail.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).