From: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
To: Michael Neuling <mikey@neuling.org>,
imunsie@au1.ibm.com, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH next] cxl: Allow PSL timebase to not sync
Date: Tue, 15 Mar 2016 19:36:26 +0100 [thread overview]
Message-ID: <56E8562A.6010502@linux.vnet.ibm.com> (raw)
In-Reply-To: <1458001649.12098.59.camel@neuling.org>
Hi Mikey,
Le 15/03/2016 01:27, Michael Neuling a écrit :
> I'm not happy with doing this unless we add something which advertises
> that it's synced or not to userspace.
>
> If we do that, I'm happy to just fail without the need of the parameter
> but advertise it to userspace.
OK, so I'm guessing that by advertising, you mean more than logging
something in dmesg, since that's already the case.
Are you suggesting to make the sync status available programmatically
(like through a status on /sys)? Seems like it would be pushing some
work on applications which want to use the psl timebase in the future,
just because there's currently a problem with some card models.
So I doubt I'm understanding you correctly here.
My vote was to keep it simple: it's all or nothing. If the driver claims
to support psl timebase sync, it should work on all the cards. This is
not the case today, so let's not make it a requirement until we are
confident it's working as expected. cxlflash is not using it, so there
should be no harm done. We'd keep the psl sync code in mostly to get
exposure on multiple setups.
> 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 really care about the module parameter. It was mostly a feeble
attempt to be developer-friendly and activate the feature easily on some
setup.
Fred
next prev parent reply other threads:[~2016-03-15 18:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-14 18:55 [PATCH] cxl: Allow PSL timebase to not sync Frederic Barrat
2016-03-14 19:29 ` [PATCH next] " Frederic Barrat
2016-03-15 0:27 ` Michael Neuling
2016-03-15 3:56 ` Michael Ellerman
2016-03-16 11:32 ` Frederic Barrat
2016-03-15 4:09 ` Vaibhav Jain
2016-03-15 18:36 ` Frederic Barrat [this message]
2016-03-17 1:41 ` Ian Munsie
2016-03-17 2:45 ` Michael Neuling
2016-03-17 20:49 ` Frederic Barrat
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56E8562A.6010502@linux.vnet.ibm.com \
--to=fbarrat@linux.vnet.ibm.com \
--cc=imunsie@au1.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mikey@neuling.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).