All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nilawar, Badal" <badal.nilawar@intel.com>
To: Andi Shyti <andi.shyti@linux.intel.com>
Cc: linux-hwmon@vger.kernel.org, linux@roeck-us.net,
	intel-xe@lists.freedesktop.org
Subject: Re: [Intel-xe] [PATCH v3 1/6] drm/xe/hwmon: Add HWMON infrastructure
Date: Fri, 4 Aug 2023 18:55:42 +0530	[thread overview]
Message-ID: <3e294a80-3fde-13bb-4cd0-e5d19fca65b4@intel.com> (raw)
In-Reply-To: <ZMrbZXOVsyT133D8@ashyti-mobl2.lan>



On 03-08-2023 04:10, Andi Shyti wrote:
> Hi Badal,
> 
> [...]
> 
>> +struct xe_hwmon_data {
>> +	struct device *hwmon_dev;
>> +	struct xe_gt *gt;
>> +	char name[12];
>> +};
>> +
>> +struct xe_hwmon {
>> +	struct xe_hwmon_data ddat;
>> +	struct mutex hwmon_lock;
>> +};
> 
> why do we need two structures here? Can we merge them?
In my previous series I mentioned its require to hold multiple hwmon 
devices.
> 
>> +static const struct hwmon_channel_info *hwmon_info[] = {
>> +	NULL
>> +};
> 
> just:
> 
>    static const struct hwmon_channel_info *hwmon_info[] = { };
> 
> would do.
sure
> 
>> +static umode_t
>> +hwmon_is_visible(const void *drvdata, enum hwmon_sensor_types type,
>> +		 u32 attr, int channel)
>> +{
>> +	struct xe_hwmon_data *ddat = (struct xe_hwmon_data *)drvdata;
>> +	int ret;
>> +
>> +	xe_device_mem_access_get(gt_to_xe(ddat->gt));
>> +
>> +	switch (type) {
>> +	default:
>> +		ret = 0;
>> +		break;
>> +	}
>> +
>> +	xe_device_mem_access_put(gt_to_xe(ddat->gt));
>> +
>> +	return ret;
> 
> OK... we are forced to go through the switch and initialize ret.
> Would be nicer to initialize ret to '0'... but it's not
> important, feel free to ignore this comment if the compiler
> doesn't complain.
> 
>> +}
> 
> [...]
> 
>> +	/*  hwmon_dev points to device hwmon<i> */
>> +	hwmon_dev = devm_hwmon_device_register_with_info(dev, ddat->name,
>> +							 ddat,
>> +							 &hwmon_chip_info,
>> +							 NULL);
>> +	if (IS_ERR(hwmon_dev)) {
>> +		drm_warn(&xe->drm, "Fail to register xe hwmon, Err:%ld\n", PTR_ERR(hwmon_dev));
> 
> I think this is better:
> 
>     drm_warn(&xe->drm, "Fail to register xe hwmon (%pe)\n", hwmon_dev);
Sure
> 
>> +		xe->hwmon = NULL;
>> +		return;
>> +	}
>> +
>> +	ddat->hwmon_dev = hwmon_dev;
>> +}
>> +
>> +void xe_hwmon_unregister(struct xe_device *xe)
>> +{
>> +	xe->hwmon = NULL;
> 
> I think this is not necessary. Will xe check for hwmon at some
> point?
Yes this not needed as we are using devm_hwmon* function to register 
hwmon but in i915 patches this was suggested for sanity. I will remove 
this function.

Regards,
Badal
> 
> Andi
> 
>> +}

WARNING: multiple messages have this Message-ID (diff)
From: "Nilawar, Badal" <badal.nilawar@intel.com>
To: Andi Shyti <andi.shyti@linux.intel.com>
Cc: <intel-xe@lists.freedesktop.org>, <linux-hwmon@vger.kernel.org>,
	<anshuman.gupta@intel.com>, <ashutosh.dixit@intel.com>,
	<linux@roeck-us.net>, <riana.tauro@intel.com>,
	<matthew.brost@intel.com>
Subject: Re: [PATCH v3 1/6] drm/xe/hwmon: Add HWMON infrastructure
Date: Fri, 4 Aug 2023 18:55:42 +0530	[thread overview]
Message-ID: <3e294a80-3fde-13bb-4cd0-e5d19fca65b4@intel.com> (raw)
In-Reply-To: <ZMrbZXOVsyT133D8@ashyti-mobl2.lan>



On 03-08-2023 04:10, Andi Shyti wrote:
> Hi Badal,
> 
> [...]
> 
>> +struct xe_hwmon_data {
>> +	struct device *hwmon_dev;
>> +	struct xe_gt *gt;
>> +	char name[12];
>> +};
>> +
>> +struct xe_hwmon {
>> +	struct xe_hwmon_data ddat;
>> +	struct mutex hwmon_lock;
>> +};
> 
> why do we need two structures here? Can we merge them?
In my previous series I mentioned its require to hold multiple hwmon 
devices.
> 
>> +static const struct hwmon_channel_info *hwmon_info[] = {
>> +	NULL
>> +};
> 
> just:
> 
>    static const struct hwmon_channel_info *hwmon_info[] = { };
> 
> would do.
sure
> 
>> +static umode_t
>> +hwmon_is_visible(const void *drvdata, enum hwmon_sensor_types type,
>> +		 u32 attr, int channel)
>> +{
>> +	struct xe_hwmon_data *ddat = (struct xe_hwmon_data *)drvdata;
>> +	int ret;
>> +
>> +	xe_device_mem_access_get(gt_to_xe(ddat->gt));
>> +
>> +	switch (type) {
>> +	default:
>> +		ret = 0;
>> +		break;
>> +	}
>> +
>> +	xe_device_mem_access_put(gt_to_xe(ddat->gt));
>> +
>> +	return ret;
> 
> OK... we are forced to go through the switch and initialize ret.
> Would be nicer to initialize ret to '0'... but it's not
> important, feel free to ignore this comment if the compiler
> doesn't complain.
> 
>> +}
> 
> [...]
> 
>> +	/*  hwmon_dev points to device hwmon<i> */
>> +	hwmon_dev = devm_hwmon_device_register_with_info(dev, ddat->name,
>> +							 ddat,
>> +							 &hwmon_chip_info,
>> +							 NULL);
>> +	if (IS_ERR(hwmon_dev)) {
>> +		drm_warn(&xe->drm, "Fail to register xe hwmon, Err:%ld\n", PTR_ERR(hwmon_dev));
> 
> I think this is better:
> 
>     drm_warn(&xe->drm, "Fail to register xe hwmon (%pe)\n", hwmon_dev);
Sure
> 
>> +		xe->hwmon = NULL;
>> +		return;
>> +	}
>> +
>> +	ddat->hwmon_dev = hwmon_dev;
>> +}
>> +
>> +void xe_hwmon_unregister(struct xe_device *xe)
>> +{
>> +	xe->hwmon = NULL;
> 
> I think this is not necessary. Will xe check for hwmon at some
> point?
Yes this not needed as we are using devm_hwmon* function to register 
hwmon but in i915 patches this was suggested for sanity. I will remove 
this function.

Regards,
Badal
> 
> Andi
> 
>> +}

  parent reply	other threads:[~2023-08-04 13:26 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-02 13:52 [Intel-xe] [PATCH v3 0/6] Add HWMON support for DGFX Badal Nilawar
2023-08-02 13:52 ` Badal Nilawar
2023-08-02 13:49 ` [Intel-xe] ✓ CI.Patch_applied: success for Add HWMON support for DGFX (rev3) Patchwork
2023-08-02 13:49 ` [Intel-xe] ✗ CI.checkpatch: warning " Patchwork
2023-08-02 13:50 ` [Intel-xe] ✓ CI.KUnit: success " Patchwork
2023-08-02 13:52 ` [Intel-xe] [PATCH v3 1/6] drm/xe/hwmon: Add HWMON infrastructure Badal Nilawar
2023-08-02 13:52   ` Badal Nilawar
2023-08-02 14:15   ` [Intel-xe] " Guenter Roeck
2023-08-02 14:15     ` Guenter Roeck
2023-08-02 22:40   ` [Intel-xe] " Andi Shyti
2023-08-02 22:40     ` Andi Shyti
2023-08-02 23:11     ` [Intel-xe] " Guenter Roeck
2023-08-02 23:11       ` Guenter Roeck
2023-08-02 23:34       ` [Intel-xe] " Andi Shyti
2023-08-02 23:34         ` Andi Shyti
2023-08-03  0:06         ` [Intel-xe] " Guenter Roeck
2023-08-03  0:06           ` Guenter Roeck
2023-08-02 23:12     ` [Intel-xe] " Guenter Roeck
2023-08-02 23:12       ` Guenter Roeck
2023-08-04 13:19       ` [Intel-xe] " Nilawar, Badal
2023-08-04 13:19         ` Nilawar, Badal
2023-08-04 14:26         ` [Intel-xe] " Guenter Roeck
2023-08-04 14:26           ` Guenter Roeck
2023-08-04 14:36           ` [Intel-xe] " Nilawar, Badal
2023-08-04 14:36             ` Nilawar, Badal
2023-08-08 21:31             ` [Intel-xe] " Rodrigo Vivi
2023-08-08 21:31               ` Rodrigo Vivi
2023-08-08 22:07               ` Guenter Roeck
2023-08-08 22:07                 ` Guenter Roeck
2023-08-11 16:01                 ` Rodrigo Vivi
2023-08-11 16:01                   ` Rodrigo Vivi
2023-08-11 17:39                   ` Guenter Roeck
2023-08-11 17:39                     ` Guenter Roeck
2023-08-11 18:48                     ` Rodrigo Vivi
2023-08-11 18:48                       ` Rodrigo Vivi
2023-08-04 14:43           ` Nilawar, Badal
2023-08-04 14:43             ` Nilawar, Badal
2023-08-04 13:25     ` Nilawar, Badal [this message]
2023-08-04 13:25       ` Nilawar, Badal
2023-08-02 13:52 ` [Intel-xe] [PATCH v3 2/6] drm/xe/hwmon: Expose power attributes Badal Nilawar
2023-08-02 13:52   ` Badal Nilawar
2023-08-02 23:23   ` [Intel-xe] " Andi Shyti
2023-08-02 23:23     ` Andi Shyti
2023-08-04 14:21     ` [Intel-xe] " Nilawar, Badal
2023-08-04 14:21       ` Nilawar, Badal
2023-08-02 13:52 ` [Intel-xe] [PATCH v3 3/6] drm/xe/hwmon: Expose card reactive critical power Badal Nilawar
2023-08-02 13:52   ` Badal Nilawar
2023-08-02 23:28   ` [Intel-xe] " Andi Shyti
2023-08-02 23:28     ` Andi Shyti
2023-08-04 13:31     ` [Intel-xe] " Nilawar, Badal
2023-08-04 13:31       ` Nilawar, Badal
2023-08-02 13:52 ` [Intel-xe] [PATCH v3 4/6] drm/xe/hwmon: Expose input voltage attribute Badal Nilawar
2023-08-02 13:52   ` Badal Nilawar
2023-08-02 23:32   ` [Intel-xe] " Andi Shyti
2023-08-02 23:32     ` Andi Shyti
2023-08-04 13:30     ` [Intel-xe] " Nilawar, Badal
2023-08-04 13:30       ` Nilawar, Badal
2023-08-02 13:52 ` [Intel-xe] [PATCH v3 5/6] drm/xe/hwmon: Expose hwmon energy attribute Badal Nilawar
2023-08-02 13:52   ` Badal Nilawar
2023-08-02 14:14   ` [Intel-xe] " Guenter Roeck
2023-08-02 14:14     ` Guenter Roeck
2023-08-03  6:34     ` [Intel-xe] " Nilawar, Badal
2023-08-03  6:34       ` Nilawar, Badal
2023-08-03 14:42       ` [Intel-xe] " Guenter Roeck
2023-08-03 14:42         ` Guenter Roeck
2023-08-02 13:52 ` [Intel-xe] [PATCH v3 6/6] drm/xe/hwmon: Expose power1_max_interval Badal Nilawar
2023-08-02 13:52   ` Badal Nilawar
2023-08-02 13:54 ` [Intel-xe] ✓ CI.Build: success for Add HWMON support for DGFX (rev3) Patchwork
2023-08-02 13:54 ` [Intel-xe] ✗ CI.Hooks: failure " Patchwork

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=3e294a80-3fde-13bb-4cd0-e5d19fca65b4@intel.com \
    --to=badal.nilawar@intel.com \
    --cc=andi.shyti@linux.intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux@roeck-us.net \
    /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.