Frederic Barrat <fbar...@linux.vnet.ibm.com> writes: > Le 11/02/2018 à 18:10, Vaibhav Jain a écrit : >> Thanks for reviewing the patch Christophe, >> >> christophe lombard <clomb...@linux.vnet.ibm.com> writes: >>>> +bool cxl_enable_psltrace = true; >>>> +module_param_named(enable_psltrace, cxl_enable_psltrace, bool, 0600); >>>> +MODULE_PARM_DESC(enable_psltrace, "Set PSL traces on probe. default: on"); >>>> + >>> I am not too agree to add a new parameter. This can cause doubts. >>> PSL team has confirmed that enabling traces has no impact. >>> Do you see any reason to disable the traces ? >> >> Traces on PSL follow a 'set and fetch' model. So once the trace buffer for >> a specific array is full it will stop and switch to 'FIN' state and at >> that point we need to fetch the trace-data and reinit the array to >> re-arm it. > > If the PSL trace arrays don't wrap, is there anything to gain by > enabling tracing by default instead of letting the developer handle it > through sysfs? I was under the (now wrong) impression that the PSL would > wrap. Enabling the traces quickly enough should let AFU developers debug init issues. Specifically AFU's that rely on cxl kernel-apis.
> I'm not a big fan of the module parameter. It seems we're giving a > second way of activating traces on top of sysfs, more cumbersome and > limited. Yes, this indeed is providing a second way of activating traces on top of sysfs. The way I see this that there are two ways PSL traces are managed: 1. Let userspace handle state machine of the traces entirely via sysfs. 2. PSL trace machine is handled via cxl. It starts it when a card is probed and stops it when the card is reset. -- Vaibhav Jain <vaib...@linux.vnet.ibm.com> Linux Technology Center, IBM India Pvt. Ltd.
