On Thu, 9 Jul 2020 15:20:11 -0300 Jason Gunthorpe wrote: > > 2) having the driver set RO on the transactions it initiates, which > > are honored iff the PCI bit is set. > > > > It seems that in addition to the PCI core changes, there still is a need > > for driver controls? Unless the driver always enables RO if it's capable? > > I think the PCI spec imagined that when the config space RO bit was > enabled the PCI device would just start using RO packets, in an > appropriate and device specific way. > > So the fine grained control in #2 is something done extra by some > devices. > > IMHO if the driver knows it is functionally correct with RO then it > should enable it fully on the device when the config space bit is set. > > I'm not sure there is a reason to allow users to finely tune RO, at > least I haven't heard of cases where RO is a degredation depending on > workload. > > If some platform doesn't work when RO is turned on then it should be > globally black listed like is already done in some cases. > > If the devices has bugs and uses RO wrong, or the driver has bugs and > is only stable with !RO and Intel, then the driver shouldn't turn it > on at all. > > In all of these cases it is not a user tunable. > > Development and testing reasons, like 'is my crash from a RO bug?' to > tune should be met by the device global setpci, I think. +1
