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.

Reply via email to