On Wed, 2018-05-23 at 10:58 -0700, Tony Lindgren wrote:

* Andy Shevchenko [off-list ref] [180522 21:42]:

quoted

On Thu, May 17, 2018 at 10:30 PM, Tony Lindgren [off-list ref]
wrote:

quoted

So how about add some "noidle" kernel command line parameter for
console
that calls
pm_runtime_forbid() and then you have the UART permanently
on.

IIUC _forbid() can be overwritten via sysfs.
And I would prefer to do other way around, something like
console.idle
and put default for OMAP to yes and no for everything else.

OK yeah console.idle sounds good to me. We should default to a
safe option.

I'll see what we can do here.

quoted

quoted

Hmm I guess you could make also serial8250_rpm_get() do nothing
based on that.

Have you seen entire series which I keep here:
https://bitbucket.org/andy-shev/linux/branch/topic/uart/rpm?
Among other things it gets rid of those specific callbacks entirely.

Well I was not Cc:ed on it, I browsed it in some archive and it
seemed unsafe to me. But if you figured out a way to do it
conditionally
based on console.idle
 without causing regressions.

I restored that branch with some updated patches. It's far from done and
doesn't have any new stuff (yet) regrading to this discussion.

quoted

quoted

I do agree the serial runtime PM has an issue if it depends on
pm_runtime_irq_safe() being set.

It's more than an issue. The  so called "support" of RPM for UART is
_based on the hack_.
I would love to NAK that in the first place if I would have known of
it in time.

Hmm well it seems that you too have been patching the 8250_rpm
functions for years and then now what after multiple years you
hit this issue? :)

Nope, I hit it as soon as I tried.

I can't find easily the discussion (hmm... yes, I was so pissed off that
time, I put a bit of harsh in that) I had with Sebastian few years back,
but at least I reported about an issue.

quoted

quoted

quoted

So, I can, of course just remove callbacks from the console
->write().
Though it will prevent to use kernel console anyway.

Please et's not start breaking things, we already see a constant
flow of regressions on weekly basis.

Now we are stick with a hack and the case based on that is against
fixing things.
This is how it looks from my side.

Sorry yeah I agree there are issues, but let's fix it properly

Agree.

 with
no regressions.

...though I think a word "regression" is inappropriate here. Regression
is what the support did in the first place. Pity I didn't know about it
at that time.

-- 
Andy Shevchenko [off-list ref]
Intel Finland Oy