From: Grant Peltier <grantpeltier93@gmail.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: robh@kernel.org, geert+renesas@glider.be, magnus.damm@gmail.com,
grant.peltier.jg@renesas.com, brandon.howell.jg@renesas.com,
linux-hwmon@vger.kernel.org, devicetree@vger.kernel.org,
linux-doc@vger.kernel.org
Subject: Re: [PATCH v2 1/2] hwmon: (pmbus/isl68137) add support for voltage divider on Vout
Date: Thu, 24 Oct 2024 14:43:31 -0500 [thread overview]
Message-ID: <ZxqjY-5MvsZfzf3U@raspberrypi> (raw)
In-Reply-To: <7d705ac9-a109-4b49-9ac6-78bd2e9ca091@roeck-us.net>
Hi Guenter,
Thank you for the review!
On Thu, Oct 24, 2024 at 10:48:16AM -0700, Guenter Roeck wrote:
> On 10/22/24 18:58, Grant Peltier wrote:
> > + [...]
> > + switch (reg) {
> > + case PMBUS_VOUT_MAX:
> > + /*
> > + * In cases where a voltage divider is attached to the target
> > + * rail between Vout and the Vsense pin, Vout related PMBus
> > + * commands should be scaled based on the expected voltage
> > + * at the Vsense pin.
> > + * I.e. Vsense = Vout * R2 / (R1 + R2)
> > + */
> > + fallthrough;
> > + case PMBUS_VOUT_MARGIN_HIGH:
> > + fallthrough;
> > + case PMBUS_VOUT_MARGIN_LOW:
> > + fallthrough;
> > + case PMBUS_VOUT_OV_FAULT_LIMIT:
> > + fallthrough;
> > + case PMBUS_VOUT_UV_FAULT_LIMIT:
> > + fallthrough;
>
> Just add the comment after the last case and drop all the fallthrough;
> Same above.
>
Will fix in v4
> > + case PMBUS_VOUT_COMMAND:
> > + if (data->channel[page].vout_voltage_divider[0]
> > + && data->channel[page].vout_voltage_divider[1]) {
>
> It would be better to set defaults instead of having to check this
> for every executed command (for example by setting R1:=0 and R2:=1).
>
Sounds reasonable. I will adjust the channel initialization process to
set defaults instead and will remove the checks in v4.
> > [...]
> > +static int isl68137_probe_child_from_dt(struct device *dev,
> > + struct device_node *child,
> > + struct isl68137_data *data)
> > +{
> > + u32 channel;
> > + int err;
> > +
> > + err = of_property_read_u32(child, "reg", &channel);
> > + if (err) {
> > + dev_err(dev, "missing reg property of %pOFn\n", child);
> > + return err;
> > + }
> > + if (channel >= MAX_CHANNELS) {
>
> The actual number of channels (pages) supported by the chip is known here
> and should be checked, either by passing the number of channels or a pointer
> to the entire info structure to this function.
>
Will fix in v4.
> > + dev_err(dev, "invalid reg %d of %pOFn\n", channel, child);
> > + return -EINVAL;
> > + }
> > +
> > + of_property_read_u32_array(child, "renesas,vout-voltage-divider",
>
> Ultimately this potentially applies to _all_ hardware monitoring chips,
> so I would very much prefer a generic voltage divider property definition.
>
There is a parallel conversation on PATCH v3 2/2 about this. Would you
prefer that I match the implementation for maxim20730?
> > + data->channel[channel].vout_voltage_divider,
> > + ARRAY_SIZE(data->channel[channel].vout_voltage_divider));
>
> The returned data should be be validated here.
>
Fixed in v3.
> > +
> > + return 0;
> > +}
> > +
> > +static int isl68137_probe_from_dt(struct device *dev,
> > + struct isl68137_data *data)
> > +{
> > + const struct device_node *np = dev->of_node;
> > + struct device_node *child;
> > + int err;
> > +
> > + for_each_child_of_node(np, child) {
> > + if (strcmp(child->name, "channel"))
> > + continue;
> > +
> > + err = isl68137_probe_child_from_dt(dev, child, data);
> > + if (err)
> > + return err;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > static int isl68137_probe(struct i2c_client *client)
> > {
> > + struct device *dev = &client->dev;
> > struct pmbus_driver_info *info;
> > + struct isl68137_data *data;
> > + int i, err;
> > - info = devm_kzalloc(&client->dev, sizeof(*info), GFP_KERNEL);
> > - if (!info)
> > + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> > + if (!data)
> > return -ENOMEM;
> > - memcpy(info, &raa_dmpvr_info, sizeof(*info));
> > +
> > + for (i = 0; i < MAX_CHANNELS; i++)
> > + memset(data->channel[i].vout_voltage_divider,
> > + 0,
> > + sizeof(data->channel[i].vout_voltage_divider));
>
> Under what circumstance would this not already be 0 after devm_kzalloc() ?
>
Mental lapse on my end. Will change to set harmless defaults discussed
above.
> > + [...]
> > + if (dev->of_node) {
> This conditional should not be necessary because for_each_child_of_node()
> ultimately calls __of_get_next_child() which checks if the node pointer
> is NULL.
>
Will remove in v4.
> > + err = isl68137_probe_from_dt(dev, data);
> > + if (err)
> > + return err;
> > + [...]
Thanks again,
Grant
next prev parent reply other threads:[~2024-10-24 19:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-23 1:56 [PATCH v2 0/2] dt-bindings: hwmon: pmbus: add bindings for isl68137 Grant Peltier
2024-10-23 1:58 ` [PATCH v2 1/2] hwmon: (pmbus/isl68137) add support for voltage divider on Vout Grant Peltier
2024-10-23 7:34 ` Geert Uytterhoeven
2024-10-23 16:40 ` Grant Peltier
2024-10-24 17:48 ` Guenter Roeck
2024-10-24 19:43 ` Grant Peltier [this message]
2024-10-24 20:03 ` Guenter Roeck
2024-10-23 1:58 ` [PATCH v2 2/2] dt-bindings: hwmon: isl68137: add bindings to support voltage dividers Grant Peltier
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=ZxqjY-5MvsZfzf3U@raspberrypi \
--to=grantpeltier93@gmail.com \
--cc=brandon.howell.jg@renesas.com \
--cc=devicetree@vger.kernel.org \
--cc=geert+renesas@glider.be \
--cc=grant.peltier.jg@renesas.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=magnus.damm@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.