Frederic Barrat <> writes:

> Le 11/02/2018 à 18:10, Vaibhav Jain a écrit :
>> Thanks for reviewing the patch Christophe,
>> christophe lombard <> 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

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 <>
Linux Technology Center, IBM India Pvt. Ltd.

Reply via email to