lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Fri, 15 Jan 2021 09:49:40 +0100
From:   Waldemar Rymarkiewicz <waldemar.rymarkiewicz@...il.com>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
        Zhang Rui <rui.zhang@...el.com>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Amit Kucheria <amitk@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>, linux-pm@...r.kernel.org
Subject: Re: Hook up a PCIe device into the thermal framework

Hi,

> > topology that DT modification will not work and still I have no device
> > node.
>
> I'm absolutely not a DT expert, but I assume that a thermal zone would
> be associated with some resource fixed by the platform, such as a fan,
> so I would think a thermal zone would have to be described in terms of
> the platform physical topology, not the PCI device type.

The thermal zone needs a temperature sensor device to read out
temperature and also some cooling devices which are mapped to specific
zone trips.
In a below scenario, when TZ hists the wifi_allert0 trip it will run
the fan but if the temp still rises it will try to dissipate the heat
by running some actions within wifi adapter eg. switch off some
antennas.

[...]
wifi_thermal: wifi-thermal {
    thermal-sensors = <&wifi_device>;
    trips {
        wifi_alert0: wifi-alert0 {
            temperature = <90000>;
            hysteresis = <5000>;
            type = "active";
        };

        wifi_alert1: wifi-alert1 {
            temperature = <110000>;
            hysteresis = <5000>;
            type = "passive";
        };

        cooling-maps {
            map0 {
                 trip = <&wifi_alert0>;
                 cooling-device = <&fan0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
            };
            map1 {
                 trip = <&wifi_alert1>;
                 cooling-device = <&wifi_device THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>;
            };
        };
};
[...]

My problem is not a cooling method but the binding of the PCI device
(it has a thermal sensor) with the thermal zone

    thermal-sensors = <&wifi_device>;     // wifi_devcie does not
exist until I will statically define it under PCI controller

The point here is that defining wifi_device under the controller I
need to reflect the PCI topology. Which is fair as DT should reflect
the HW connection. Even if I define a wifi_device anywhere in DT and
assuming the PCI core will search whole DT and not only subnodes of
the controller/bridge/switch here likely comes another problem. What
should be the key to search for the device node? PCI addresses devices
by bus:device: function and this is known after PCI scan.

To me seems that so far no one found a good way to handle thermal
within PCI devices, so some drivers statically create TZ and handle it
within the driver. This way, unfortunately, we lose the flexibility of
thermal control from a system-wide perspective. WiFi adapter is not
aware of the fan for example.

/Waldek

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ