On Tue, 2023-09-12 at 10:45 -0700, srinivas pandruvada wrote: > On Tue, 2023-09-12 at 15:52 +0300, Ilpo Järvinen wrote: > > On Mon, 11 Sep 2023, srinivas pandruvada wrote: > > > On Mon, 2023-09-11 at 18:47 +0300, Ilpo Järvinen wrote: > > > > > > > > [...] > > > > But I don't suggest using such method. This causes confusion and > > > difficult to change. For example if we increase range of P-state > > > control, then there is no way to know what is the start point of > > > T- > > > states. > > > > Yes. I understand it would be confusing. > > > > > It is best to create to separate cooling devices for BW and link > > > width. > > > > Okay. If that's the case, then I see no reason to add the Link > > Width > > cooling device now as it could do nothing besides reporting the > > current > > link width. > > > > The only question that then remains is how to take this into > > account > > in > > the naming of the cooling devices, currently PCIe_Port_<pci_name()> > > is > > used but perhaps it would be better to change that to > > PCIe_Port_Link_Speed_... to allow PCI_Port_Link_Width_... to be > > added > > later beside it? > It is better in that way to add BW sorry, link width controller > controller later. > > Also adding separate cooling device will let thermal configuration, > choose different method at different thermal thresholds or all > together. > > Thanks, > Srinivas > > > > > > Also there is a requirement that anything you add to thermal > > > sysfs, > > > it > > > should have some purpose for thermal control. I hope Link width > > > control > > > is targeted to similar use case BW control. > > > > Ability to control Link Width seems to be part of PCIe 6.0 L0p. > > AFAICT, > > the reasons are to lower/control power consumption so it seems to > > be > > within scope. > > > > >
