From: Phinex Hung <phinex@realtek.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: "jdelvare@suse.com" <jdelvare@suse.com>,
"linux-hwmon@vger.kernel.org" <linux-hwmon@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v1] hwmon: drivetemp: support to be a platform driver for thermal_of
Date: Fri, 17 Mar 2023 02:25:12 +0000 [thread overview]
Message-ID: <32659f71a1784b5484e63152eec29234@realtek.com> (raw)
In-Reply-To: <2b1e7e29-daa6-4f24-9fad-7ebe8b87a5fe@roeck-us.net>
On Friday, March 17 at 2023 2:18 AM , Guenter Roeck <groeck7@gmail.com> On Behalf Of Guenter Roeck wrote:
>Yes, except of course for the bugs (see below). That is much less than perfect, of course, since we'd really want the device node for the drive, not the controller, but it might be the best we can do.
See, thanks for the review, looks better and bug-less than my draft version.
Should I submit this patch again using the code snippet that we discussed? Or any suggestions ?
>> Or is it reasonable that we just match a specific compatible string and assign the device node to the original dev->parent used in drivetemp_add function ?
>>
>We can't add anything to the parent device node since we don't own it.
>Also, I don't know if devicetree maintainers would accept the concept of "virtual" device nodes (and I don't know how device nodes for drives would or should look like either).
What I am thinking about is "virtual" device nodes as well, such as..
@@ -99,6 +99,7 @@
status = "okay";
sata_port0: sata-port@0 {
+ compatible = "drivetemp,hdd-sensors";
reg = <0>;
phys = <&sata_phy 0>;
resets = <&clkc RTD1295_RSTN_SATA_0>,
@@ -110,6 +110,7 @@
};
sata_port1: sata-port@1 {
+ compatible = "drivetemp,hdd-sensors";
reg = <1>;
phys = <&sata_phy 1>;
resets = <&clkc (RTD1295_RSTN_SATA_1 | RTD1295_RSTN_REG_BANK_4)>,
And patches in the drivetemp.c itself..
--- a/drivers/hwmon/drivetemp.c
+++ b/drivers/hwmon/drivetemp.c
@@ -107,6 +107,7 @@
#include <scsi/scsi_device.h>
#include <scsi/scsi_driver.h>
#include <scsi/scsi_proto.h>
+#include <linux/of.h>
struct drivetemp_data {
struct list_head list; /* list of instantiated devices */
@@ -525,6 +526,7 @@ static int drivetemp_add(struct device *dev, struct class_interface *intf)
{
struct scsi_device *sdev = to_scsi_device(dev->parent);
struct drivetemp_data *st;
+ static struct device_node *node = NULL;
int err;
st = kzalloc(sizeof(*st), GFP_KERNEL);
@@ -540,6 +542,11 @@ static int drivetemp_add(struct device *dev, struct class_interface *intf)
goto abort;
}
+ node = of_find_compatible_node(node, NULL, "drivetemp,hdd-sensors");
+
+ if(node)
+ dev->parent->of_node = node;
+
st->hwdev = hwmon_device_register_with_info(dev->parent, "drivetemp",
st, &drivetemp_chip_info,
NULL);
Doing this can get my two HDD works for two thermal zones.
If "virtual" device node can be used, then we don't need to patch the hwmon.c core ?
>> - hdev->of_node = dev ? dev->of_node : NULL;
>> + while(!tdev->of_node)
> while (tdev && !tdev->of_node)
Thanks for this review, checking tdev can avoid endless loop. My fault for this.
> >- if (dev && dev->of_node && chip && chip->ops->read &&
> >+ if (tdev && tdev->of_node && chip && chip->ops->read &&
>This could probably be simplified to
> if (hdev->of_node && chip && ..
Looks better and simpiler.
Thanks
Regards,
Phinex
next prev parent reply other threads:[~2023-03-17 2:26 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-15 12:16 [PATCH v1] hwmon: drivetemp: support to be a platform driver for thermal_of phinex
2023-03-15 13:11 ` Krzysztof Kozlowski
2023-03-15 14:02 ` Phinex Hung
2023-03-15 14:06 ` Krzysztof Kozlowski
2023-03-15 14:16 ` Guenter Roeck
2023-03-15 15:06 ` kernel test robot
2023-03-15 15:36 ` Guenter Roeck
2023-03-16 2:21 ` Phinex Hung
2023-03-16 3:02 ` Guenter Roeck
2023-03-16 3:29 ` Phinex Hung
2023-03-16 5:07 ` Guenter Roeck
2023-03-16 7:35 ` Phinex Hung
2023-03-16 7:48 ` Phinex Hung
2023-03-16 13:22 ` Guenter Roeck
2023-03-16 14:17 ` Phinex Hung
2023-03-16 18:17 ` Guenter Roeck
2023-03-17 2:25 ` Phinex Hung [this message]
2023-03-15 21:15 ` kernel test robot
2023-03-15 22:28 ` kernel test robot
2023-03-21 6:02 ` [PATCH v2] hwmon: fix potential sensor registration fail if of_node is missing Phinex Hung
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=32659f71a1784b5484e63152eec29234@realtek.com \
--to=phinex@realtek.com \
--cc=jdelvare@suse.com \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox