From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Michal Simek <michal.simek@amd.com>
Cc: linux-kernel@vger.kernel.org, monstr@monstr.eu,
michal.simek@xilinx.com, git@xilinx.com,
"Salih Erim" <salih.erim@amd.com>,
"Anand Ashok Dumbre" <anand.ashok.dumbre@xilinx.com>,
"Andy Shevchenko" <andy@kernel.org>,
"David Lechner" <dlechner@baylibre.com>,
"Jonathan Cameron" <jic23@kernel.org>,
"Nuno Sá" <nuno.sa@analog.com>,
"open list:IIO SUBSYSTEM AND DRIVERS" <linux-iio@vger.kernel.org>
Subject: Re: [PATCH 2/6] iio: versal-sysmon: add driver for Versal Sysmon
Date: Tue, 9 Sep 2025 13:33:47 +0300 [thread overview]
Message-ID: <CAHp75Vc1hkf8jgP76+oHgKU_hFn2STPbgO550ZP2Z39KaCFb7A@mail.gmail.com> (raw)
In-Reply-To: <2780986977702f126416ec442c5336bd541f475b.1757061697.git.michal.simek@amd.com>
On Fri, Sep 5, 2025 at 11:42 AM Michal Simek <michal.simek@amd.com> wrote:
>
> Sysmon Driver uses Linux IIO framework, which was used to abstract the
> supply voltages and temperatures across the chip as Voltage and Temperature
> Channels in the framework. Since there are only 160 supply voltage
> registers and 184 measurement points, there is no constant mapping of
> supply voltage registers and the measurement points. User has to select
> the voltages to monitor in design tool. Depending on the selection, a
in the design
> voltage supply gets mapped to one of the supply registers. So, this mapping
> information is provided to the driver via a device tree. Depending on the
> number of supplies enabled in the design, the device tree will contain the
> information of name of the supply enabled and the supply register it maps
> to.
...
> +config VERSAL_SYSMON
> + tristate "Xilinx Sysmon driver for Versal"
> + depends on HAS_IOMEM
> + select VERSAL_SYSMON_CORE
> + help
> + Say yes here to have support for the Xilinx Sysmon.
> + The driver will enable users to monitor temperature and voltage on the
> + Xilinx Versal platform.
> +
> + The driver can also be build as a module. If so, the module will be called
built
> + versal-sysmon.
...
> +#include <linux/bits.h>
Quite a few headers are absent...
+ export.h
+ types.h
> +#include "versal-sysmon.h"
...
> +static u32 sysmon_temp_offset(int address)
> +{
> + switch (address) {
> + case TEMP_MAX:
> + return SYSMON_TEMP_MAX;
> + case TEMP_MIN:
> + return SYSMON_TEMP_MIN;
> + case TEMP_MAX_MAX:
> + return SYSMON_TEMP_MAX_MAX;
> + case TEMP_MIN_MIN:
> + return SYSMON_TEMP_MIN_MIN;
> + case TEMP_HBM:
> + return SYSMON_TEMP_HBM;
> + default:
> + return -EINVAL;
> + }
> + return -EINVAL;
Here and in many more, eliminate dead code.
> +}
...
> +static u32 sysmon_supply_thresh_offset(int address,
> + enum iio_event_direction dir)
> +{
> + if (dir == IIO_EV_DIR_RISING)
> + return (address * 4) + SYSMON_SUPPLY_TH_UP;
> + else if (dir == IIO_EV_DIR_FALLING)
> + return (address * 4) + SYSMON_SUPPLY_TH_LOW;
Redundant 'else'.
> + return -EINVAL;
> +}
...
> +static void sysmon_hbm_to_millicelsius(int raw_data, int *val, int *val2)
> +{
> + *val = ((raw_data >> SYSMON_HBM_TEMP_SHIFT) & SYSMON_HBM_TEMP_MASK) *
> + SYSMON_MILLI_SCALE;
Can the whole driver be switched to FIELD_PREP()/FIELD_GET()/FIELD_MODIFY()?
> + *val2 = 0;
> +}
...
> +static void sysmon_millicelsius_to_q8p7(u32 *raw_data, int val, int val2)
> +{
> + (void)val2;
Unneeded.
> + *raw_data = (val << SYSMON_FRACTIONAL_SHIFT) / SYSMON_MILLI_SCALE;
> +}
...
> +static void sysmon_supply_processedtoraw(int val, int val2, u32 reg_val,
> + u32 *raw_data)
> +{
> + int exponent = (reg_val & SYSMON_MODE_MASK) >> SYSMON_MODE_SHIFT;
> + int format = (reg_val & SYSMON_FMT_MASK) >> SYSMON_FMT_SHIFT;
> + int scale = 1 << (16 - exponent);
> + int tmp;
> +
> + tmp = (val * scale) / SYSMON_MILLI_SCALE;
> +
> + /* Set out of bound values to saturation levels */
> + if (format) {
> + if (tmp > SYSMON_UPPER_SATURATION_SIGNED)
> + tmp = 0x7fff;
> + else if (tmp < SYSMON_LOWER_SATURATION_SIGNED)
> + tmp = 0x8000;
This looks like s16 limits, can you use them?
> + } else {
> + if (tmp > SYSMON_UPPER_SATURATION)
> + tmp = 0xffff;
> + else if (tmp < SYSMON_LOWER_SATURATION)
> + tmp = 0x0000;
u16 respectively.
> + }
> +
> + *raw_data = tmp & 0xffff;
> +}
> + u32 ret = -EINVAL;
> + mutex_lock(&sysmon->mutex);
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + switch (chan->type) {
> + case IIO_TEMP:
> + offset = sysmon_temp_offset(chan->address);
> + *val = sysmon->temp_read(sysmon, offset);
> + *val2 = 0;
> + ret = IIO_VAL_INT;
> + break;
> +
> + case IIO_VOLTAGE:
> + offset = sysmon_supply_offset(chan->address);
> + sysmon_read_reg(sysmon, offset, ®val);
> + *val = (int)regval;
> + *val2 = 0;
> + ret = IIO_VAL_INT;
> + break;
> +
> + default:
> + break;
> + }> +
> + spin_unlock_irqrestore(&sysmon->lock, flags);
> + mutex_unlock(&sysmon->mutex);
> +
> + return 0;
> +}
...
> +#include <linux/bits.h>
+ io.h
> +#include <linux/moduleparam.h>
> +#include <linux/firmware/xlnx-zynqmp.h>
> +#include "versal-sysmon.h"
> +
> +static LIST_HEAD(sysmon_list_head);
list.h?
> +static struct iio_map sysmon_therm_static_maps[] = {
> + IIO_MAP("temp", "versal-thermal", "sysmon-temp-channel"),
Where are the IIO_MAP() and struct iio_map defined?
> + {}
> +};
> +
> +static inline int sysmon_direct_read_reg(struct sysmon *sysmon, u32 offset, u32 *data)
+ types.h for uXX.
> +{
> + *data = readl(sysmon->base + offset);
> +
> + return 0;
> +}
...
> + mutex_init(&sysmon->mutex);
devm?
...
> + indio_dev->dev.parent = &pdev->dev;
> + indio_dev->dev.of_node = pdev->dev.of_node;
Drop these, IIO core does the same and even better.
...
> + mutex_lock(&sysmon->mutex);
scoped_guard() from cleanup.h
> + if (list_empty(&sysmon_list_head)) {
> + sysmon->master_slr = true;
No need, just make a sane default and !exist will work in the other
branch the same way. I believe it's
bool exist = false;
> + } else {
> + list_for_each_entry(temp_sysmon, &sysmon_list_head, list) {
> + if (temp_sysmon->master_slr)
> + exist = true;
Why to continue?
> + }
> + sysmon->master_slr = !exist;
> + }
> +
> + mutex_unlock(&sysmon->mutex);
...
> +#include <linux/delay.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/iio/buffer.h>
> +#include <linux/iio/driver.h>
> +#include <linux/iio/events.h>
> +#include <linux/iio/machine.h>
> +#include <linux/iio/sysfs.h>
> +#include <linux/iio/adc/versal-sysmon-events.h>
> +#include <linux/iopoll.h>
> +#include <linux/kernel.h>
Mustn't be used in new drivers.
> +#include <linux/list.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/slab.h>
> +#include <linux/of_address.h>
Huh?! Please, make sure you are following IWYU principle, please
*drop* all of the headers that are *not* being used (by this header),
there are a LOT of them to be dropped.
...
> +/* Channel IDs for Temp Channels */
> +/* TEMP_MAX gives the current temperature for Production
> + * silicon.
> + * TEMP_MAX gives the current maximum temperature for ES1
> + * silicon.
> + */
> +#define TEMP_MAX 160
Here and everywhere else, bad namings.
...
This is an unfinished review due to the following reasons (from more
important to less):
- AMD is not the first day contributor, the code is awful, it missed a
lot of reviews and updates regarding the last several years of the
kernel development (IIO subsystem in particular). Please, avoid
letting reviewers do *your* job.
- The patches are too long to review, it would be nicer to make them
feature-by-feature, where each one is < 1000 LoCs.
- I started this a few days ago, but I'm busy at the moment, that's
another reason.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2025-09-09 10:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-05 8:41 [PATCH 0/6] xilinx: Add support for Xilinx Sysmon IP Michal Simek
2025-09-05 8:41 ` [PATCH 1/6] dt-bindings: iio: xilinx: Add Documentation for Sysmon Michal Simek
2025-09-05 11:30 ` Jonathan Cameron
2025-09-05 12:29 ` Michal Simek
2025-09-05 14:21 ` Erim, Salih
2025-09-05 20:44 ` David Lechner
2025-09-07 10:51 ` Jonathan Cameron
2025-09-08 11:13 ` Erim, Salih
2025-09-05 8:41 ` [PATCH 2/6] iio: versal-sysmon: add driver for Versal Sysmon Michal Simek
2025-09-05 12:23 ` Jonathan Cameron
2025-09-09 10:33 ` Andy Shevchenko [this message]
2025-09-10 8:26 ` Michal Simek
2025-09-05 8:41 ` [PATCH 3/6] iio: adc: versal-sysmon: Support AI Engine thermal monitoring Michal Simek
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=CAHp75Vc1hkf8jgP76+oHgKU_hFn2STPbgO550ZP2Z39KaCFb7A@mail.gmail.com \
--to=andy.shevchenko@gmail.com \
--cc=anand.ashok.dumbre@xilinx.com \
--cc=andy@kernel.org \
--cc=dlechner@baylibre.com \
--cc=git@xilinx.com \
--cc=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.simek@amd.com \
--cc=michal.simek@xilinx.com \
--cc=monstr@monstr.eu \
--cc=nuno.sa@analog.com \
--cc=salih.erim@amd.com \
/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).