On Thu, 17 Oct 2024, Rafael J. Wysocki wrote: > On Thu, Oct 17, 2024 at 2:16 PM Ilpo Järvinen > <ilpo.jarvinen@xxxxxxxxxxxxxxx> wrote: > > > > On Thu, 17 Oct 2024, Jonathan Cameron wrote: > > > > > On Wed, 9 Oct 2024 12:52:22 +0300 > > > Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx> wrote: > > > > > > > Add a thermal cooling driver to provide path to access PCIe bandwidth > > > > controller using the usual thermal interfaces. > > > > > > > > A cooling device is instantiated for controllable PCIe Ports from the > > > > bwctrl service driver. > > > > > > > > If registering the cooling device fails, allow bwctrl's probe to > > > > succeed regardless. As cdev in that case contains IS_ERR() pseudo > > > > "pointer", clean that up inside the probe function so the remove side > > > > doesn't need to suddenly make an odd looking IS_ERR() check. > > > > > > > > The thermal side state 0 means no throttling, i.e., maximum supported > > > > PCIe Link Speed. > > > > > > > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx> > > > > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> > > > > Acked-by: Rafael J. Wysocki <rafael@xxxxxxxxxx> # From the cooling device interface perspective > > > > > > Trivial thing noticed on a reread. > > > > > > > > > > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig > > > > index 61e7ae524b1f..d3f9686e26e7 100644 > > > > --- a/drivers/thermal/Kconfig > > > > +++ b/drivers/thermal/Kconfig > > > > @@ -220,6 +220,15 @@ config DEVFREQ_THERMAL > > > > > > > > If you want this support, you should say Y here. > > > > > > > > +config PCIE_THERMAL > > > > + bool "PCIe cooling support" > > > > + depends on PCIEPORTBUS > > > > + help > > > > + This implements PCIe cooling mechanism through bandwidth reduction > > > > + for PCIe devices. > > > > > > Technically links not devices, but don't think that matters much > > > > That distinction would be splitting hairs beyond what seems useful from > > ordinary user's point of view. If there's no device attached, BW > > controller cannot do anything since the link is not going to train. > > The link speed reduction is going to impact the speed the device > > can communicate with even if it technically occurs on the link. > > From the Kconfig description perspective I think it's better to say > "devices" even though technically it is about links, because device > performance is what users will measure and notice any changes of. Yes, that's what I tried to explain above. I intend to keep it as "devices" for this very reason. -- i.
