On 3/16/23 13:08, "Guenter Roeck" <groeck7@xxxxxxxxx <mailto:groeck7@xxxxxxxxx> wrote: >Wrong conclusion. You have (or should have) devicetree node(s) such as >sata: sata@80000 { >compatible = "marvell,orion-sata"; >reg = <0x80000 0x5000>; >interrupts = <21>; >clocks = <&gate_clk 14>, <&gate_clk 15>; >clock-names = "0", "1"; >phys = <&sata_phy0>, <&sata_phy1>; >phy-names = "port0", "port1"; >status = "disabled"; >}; I did see this, but just though that is a compatible match to marvell's sata driver. Nothing to do with your drivetemp. >Those nodes should have devices associated with them (in this case instantiated >by drivers/ata/sata_mv.c). At the same time, the drivetemp driver callback >(drivetemp_add) gets called with a device pointer as parameter. The question >is how to get from the device pointer passed to drivetemp_add() to the device >created by the sata_mv driver. Is it dev ? or dev->parent ? Or dev->parent->parent ? >The devicetree node associated with that device is the one which should be used >to set the hwmon device devicetree node. Essentially you'll have to find out where >in the device list to find the of_node pointing to the above sata node. Then we >can discuss how to make that node available to the thermal subsystem. Thanks for the hint. By checking marvell's SATA driver, it uses "ata_host_activate" to register a platform SATA driver. In our SATA driver, we rely on "ahci_platform_init_host" to register a platform SATA driver. Not sure whether this is the difference, but use the following patch can solve this issue. @@ -540,9 +531,9 @@ static int drivetemp_add(struct device *dev, struct class_interface *intf) goto abort; } - st->hwdev = hwmon_device_register_with_info(dev->parent, "drivetemp", - st, &drivetemp_chip_info, - NULL); + st->hwdev = hwmon_device_register_with_info( + dev->parent->parent->parent->parent->parent, "drivetemp", st, + &drivetemp_chip_info, NULL); The problem is that in our case, dev is a scsi_device, dev->parent is a sd device, dev->parent->parent is a scsi target, dev->parent->parent->parent is a scsi host dev->parent->parent->parent->parent is an ATA device, while its parent is our platform device (ahci). Besides, a change in dts is required to move #thermal-sensor-cells = <0> from a SATA port to an ahci host. @@ -94,16 +94,15 @@ realtek,satawrap = <&sata_phy>; #address-cells = <1>; #size-cells = <0>; + #thermal-sensor-cells = <0>; status = "okay"; sata_port0: sata-port@0 { reg = <0>; phys = <&sata_phy 0>; resets = <&clkc RTD1295_RSTN_SATA_0>, <&clkc RTD1295_RSTN_SATA_PHY_0>; sata-gpios = <&misc_gpio 16 GPIO_ACTIVE_HIGH>; - #thermal-sensor-cells = <0>; status = "okay"; }; }; Without this change, sensor registration would still fail due to mismatch of the np node in thermal_zone_of_sensor_register function. if (sensor_specs.np == sensor_np && id == sensor_id) { tzd = thermal_zone_of_add_sensor(child, sensor_np, data, ops); if (!IS_ERR(tzd)) tzd->ops->set_mode(tzd, THERMAL_DEVICE_ENABLED); of_node_put(sensor_specs.np); of_node_put(child); goto exit; } This might be a good solution for my initial problem, and it works perfectly for a single drive case. Thank you again for the advice. For a system with more than 1 drive, there is still a mapping between multiple hwmon devices and a thermal zone. Since I move the #thermal-sensor-cells = <0> from SATA port to a AHCI host, thermal zone is associated with the host, not each SATA port. Take the below case for example, it sounds that the thermal zone is associated with hwmon2 only. root@OpenWRT-Kylin:/sys/class/thermal# cat thermal_zone1/temp 48000 root@OpenWRT-Kylin:/sys/class/thermal# cat ../hwmon/hwmon1/temp1_input 50000 root@OpenWRT-Kylin:/sys/class/thermal# cat ../hwmon/hwmon2/temp1_input 48000 Thanks Regards, Phinex
