From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Angelo Dureghello <adureghello@baylibre.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
Lars-Peter Clausen <lars@metafoo.de>,
Michael Hennerich <Michael.Hennerich@analog.com>,
"Nuno Sa" <nuno.sa@analog.com>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Olivier Moysan <olivier.moysan@foss.st.com>,
<linux-iio@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<devicetree@vger.kernel.org>, <dlechner@baylibre.com>
Subject: Re: [PATCH v3 08/10] iio: dac: ad3552r: extract common code (no changes in behavior intended)
Date: Fri, 4 Oct 2024 15:21:47 +0100 [thread overview]
Message-ID: <20241004152147.00003a2a@Huawei.com> (raw)
In-Reply-To: <zlfrwjnr6spzzmy75qifbdn3tuhsjsr3emxxrzoahejxf3ehem@ajymvtzgfuno>
> > > +int ad3552r_get_custom_gain(struct device *dev, struct fwnode_handle *child,
> > > + u8 *gs_p, u8 *gs_n, u16 *rfb, s16 *goffs)
> > > +{
> > > + int err;
> > > + u32 val;
> > > + struct fwnode_handle *gain_child __free(fwnode_handle) =
> > > + fwnode_get_named_child_node(child,
> > One tab more than the line above is fine for cases like this and makes for
> > more readable code.
> >
> Aligning with c then line comes to long.
> I can offer, as in other drivers:
>
> int ad3552r_get_custom_gain(struct device *dev, struct fwnode_handle *child,
> u8 *gs_p, u8 *gs_n, u16 *rfb, s16 *goffs)
> {
> int err;
> u32 val;
> struct fwnode_handle *gain_child __free(fwnode_handle) =
> fwnode_get_named_child_node(child,
> "custom-output-range-config");
That looks good to me
>
> Also, do you prefer 80 or 100 as eol limit ?
Prefer 80, but not at the cost of readability
>
>
> > > + "custom-output-range-config");
> >
> > Align this final parameter with c of child.
> >
>
> > > +static int ad3552r_find_range(u16 id, s32 *vals)
> > > +{
> > > + int i, len;
> > > + const s32 (*ranges)[2];
> > > +
> > > + if (id == AD3542R_ID) {
> >
> > This is already in your model_data. Use that not another lookup via
> > an ID enum. The ID enum approach doesn't scale as we add more parts
> > as it scatters device specific code through the driver.
> >
>
> This function is only used internally to this common part.
>
> >
> > > + len = ARRAY_SIZE(ad3542r_ch_ranges);
> > > + ranges = ad3542r_ch_ranges;
> > > + } else {
> > > + len = ARRAY_SIZE(ad3552r_ch_ranges);
> > > + ranges = ad3552r_ch_ranges;
> > > + }
> > > +
> > > + for (i = 0; i < len; i++)
> > > + if (vals[0] == ranges[i][0] * 1000 &&
> > > + vals[1] == ranges[i][1] * 1000)
> > > + return i;
> > > +
> > > + return -EINVAL;
> > > +}
> > > +
> > > +int ad3552r_get_output_range(struct device *dev, enum ad3552r_id chip_id,
> > > + struct fwnode_handle *child, u32 *val)
> > As above, don't pass the enum. Either pass the model_data or pass the
> > actual stuff you need which is the ranges array and size of that array.
> >
>
> Cannot pass model data, structures of the 2 drviers are different.
> If i pass arrays, the logic of deciding what array (checking the id)
> must be done in the drivers, but in this way, there will be less
> common code.
I'd prefer that to having an ID register look up in here.
Roughly speaking looking up by ID is almost always the wrong
way to go for long term scalability of a driver as more parts
are added.
Jonathan
next prev parent reply other threads:[~2024-10-04 14:21 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-19 9:19 [PATCH v3 00/10] iio: add support for the ad3552r AXI DAC IP Angelo Dureghello
2024-09-19 9:19 ` [PATCH v3 01/10] iio: backend: adi-axi-dac: fix wrong register bitfield Angelo Dureghello
2024-09-20 12:45 ` Nuno Sá
2024-09-29 10:38 ` Jonathan Cameron
2024-09-19 9:19 ` [PATCH v3 02/10] dt-bindings: iio: dac: axi-dac: add ad3552r axi variant Angelo Dureghello
2024-09-20 12:47 ` Nuno Sá
2024-09-22 20:59 ` Krzysztof Kozlowski
2024-09-29 10:46 ` Jonathan Cameron
2024-09-30 12:52 ` Angelo Dureghello
2024-09-30 13:15 ` Nuno Sá
2024-09-30 14:52 ` Jonathan Cameron
2024-09-19 9:19 ` [PATCH v3 03/10] dt-bindings: iio: dac: ad3552r: fix maximum spi speed Angelo Dureghello
2024-09-22 20:59 ` Krzysztof Kozlowski
2024-09-19 9:20 ` [PATCH v3 04/10] dt-bindings: iio: dac: ad3552r: add io-backend support Angelo Dureghello
2024-09-22 21:02 ` Krzysztof Kozlowski
2024-09-23 15:50 ` Angelo Dureghello
2024-09-24 8:02 ` Krzysztof Kozlowski
2024-09-24 12:27 ` Nuno Sá
2024-09-25 7:22 ` Krzysztof Kozlowski
2024-09-25 11:55 ` Nuno Sá
2024-09-28 12:20 ` Krzysztof Kozlowski
2024-09-29 10:59 ` Jonathan Cameron
2024-09-30 7:20 ` Nuno Sá
2024-09-30 7:31 ` Krzysztof Kozlowski
2024-09-30 8:24 ` Nuno Sá
2024-09-30 13:22 ` Angelo Dureghello
2024-09-30 15:09 ` Jonathan Cameron
2024-10-01 8:23 ` Nuno Sá
2024-10-01 18:29 ` Jonathan Cameron
2024-10-02 5:54 ` Krzysztof Kozlowski
2024-10-02 9:00 ` Nuno Sá
2024-09-29 10:51 ` Jonathan Cameron
2024-09-30 14:15 ` Angelo Dureghello
2024-09-30 14:49 ` Jonathan Cameron
2024-09-30 15:08 ` Angelo Dureghello
2024-09-30 19:20 ` David Lechner
2024-10-01 8:09 ` Angelo Dureghello
2024-09-19 9:20 ` [PATCH v3 05/10] iio: backend: extend features Angelo Dureghello
2024-09-20 12:50 ` Nuno Sá
2024-09-24 14:11 ` Angelo Dureghello
2024-09-25 11:59 ` Nuno Sá
2024-10-02 9:14 ` Angelo Dureghello
2024-09-29 11:05 ` Jonathan Cameron
2024-09-30 19:25 ` David Lechner
2024-10-01 8:14 ` Nuno Sá
2024-10-01 8:35 ` Angelo Dureghello
2024-10-01 18:32 ` Jonathan Cameron
2024-09-19 9:20 ` [PATCH v3 06/10] iio: backend: adi-axi-dac: " Angelo Dureghello
2024-09-20 13:10 ` Nuno Sá
2024-09-29 11:28 ` Jonathan Cameron
2024-09-19 9:20 ` [PATCH v3 07/10] iio: dac: ad3552r: changes to use FIELD_PREP Angelo Dureghello
2024-09-19 9:20 ` [PATCH v3 08/10] iio: dac: ad3552r: extract common code (no changes in behavior intended) Angelo Dureghello
2024-09-29 11:57 ` Jonathan Cameron
2024-10-02 15:50 ` Angelo Dureghello
2024-10-04 14:21 ` Jonathan Cameron [this message]
2024-09-19 9:20 ` [PATCH v3 09/10] iio: dac: ad3552r: add axi platform driver Angelo Dureghello
2024-09-29 12:17 ` Jonathan Cameron
2024-09-19 9:20 ` [PATCH v3 10/10] iio: backend: adi-axi-dac: add registering of child fdt node Angelo Dureghello
2024-09-29 12:21 ` Jonathan Cameron
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=20241004152147.00003a2a@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=Michael.Hennerich@analog.com \
--cc=adureghello@baylibre.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=olivier.moysan@foss.st.com \
--cc=robh@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).