Re: [PATCH 2/3] cxl: Introduce module parameter 'enable_psltrace'

Frederic Barrat [off-list ref] writes:

Le 11/02/2018 =C3=A0 18:10, Vaibhav Jain a =C3=A9crit=C2=A0:

quoted

Thanks for reviewing the patch Christophe,
=20
christophe lombard [off-list ref] writes:

quoted

quoted

+bool cxl_enable_psltrace =3D true;
+module_param_named(enable_psltrace, cxl_enable_psltrace, bool, 0600);
+MODULE_PARM_DESC(enable_psltrace, "Set PSL traces on probe. default: =

on");

quoted

quoted

quoted

+

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 ?

=20
Traces on PSL follow a 'set and fetch' model. So once the trace buffer f=

or

quoted

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=20
enabling tracing by default instead of letting the developer handle it=20
through sysfs? I was under the (now wrong) impression that the PSL would=

=20

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=20
second way of activating traces on top of sysfs, more cumbersome and=20
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.

--=20
Vaibhav Jain [off-list ref]
Linux Technology Center, IBM India Pvt. Ltd.