Re: [PATCH next] cxl: Allow PSL timebase to not sync

[Ian Munsie <imunsie@au1.ibm.com>]

Excerpts from Michael Neuling's message of 2016-03-15 11:27:29 +1100:
> I'm not happy with doing this unless we add something which advertises
> that it's synced or not to userspace.

In my opinion this is probably unnecessary (but it's not a bad idea
either and I'm happy for that to be added). As far as I know, no one is
using timebase in an AFU today, or if they are it is on working cards
(if it wasn't someone would have complained by now).

This change is just to make it so that the affected cards will work at
all, since at the moment we treat the failure of this feature no one
uses as fatal.

If / when someone actually needs timebase, they will have to debug the
root cause of the problem anyway (if we haven't already), at which point
they will have a working card regardless of whether this patch is merged
or not.

If it turns out to be a software bug it is not unreasonable for them to
say that their afu is only supported by kernel or firmware "whatever
version we fix it in".

That said, a read-only attribute in sysfs to indicate whether the
timebase is synced or not would be fine and give them something they can
query if they care about it.

> The parameter is a bit of a PITA too, as it's a driver level config not
> card level.  You really want to turn it on/off based on the card, not
> the whole system.

I don't agree - userspace already needs to know what AFU they are
dealing with and therefore knows if the timebase is important or not. A
read-only attribute in sysfs would be enough to tell them this. We can
be fairly confident that there is no software that would need to be
changed to check this today since we had been failing the whole init so
it wouldn't have worked at all regardless.

We did have a software bug where the sync was sensitive to the kernel
config, but that has been fixed. If anyone was using timebase (and I
don't think anyone was) already and lucked out by testing on a kernel
config that was working this won't impact them either since those cards
will work either way now that issue has been fixed.

IMO, we should ditch the module parameter altogether and never treat
timebase sync failure as fatal, and leave that up to any applications
actually need it to check.

Cheers,
-Ian