Hi Andy,

Am 10.01.2017 um 13:20 schrieb Andy Shevchenko =

[off-list ref]:

=20
On Tue, 2017-01-10 at 13:10 +0100, H. Nikolaus Schaller wrote:
=20

quoted

quoted

So the question is really if a driver only needs to do power
management on open() and close() or if it also has to translate or
transform the packets. There are devices who speak NMEA and all is
good.

=20
The device I want to upstream the driver speaks NMEA but should be
powered down unless accessed...

=20
By the way, have you seen the series [1] I'm working on towards =

bringing

runtime PM for all (current) serial drivers?
=20
[1] https://www.spinics.net/lists/linux-serial/msg24025.html

sorry no.

Interesting: "The series has been tested on our hardware with serial =
console and RxD
used as GPIO to wake it."

We had implemented a driver ca. 5 years ago (Neil Brown did it) for our =
GPS chip by
doing exactly this (setting the RxD to GPIO and interrupt mode to know =
when it sends
data but the UART is off).

This would have been completely based on existing APIs (pinmux states, =
gpio)
and would not even have needed any general serial device bus driver API =
because
it did not tamper with the UART+tty layers but the RxD line.

So from a viewpoint of encapsulation it would have done what it should =
inside the
driver.

But there was no consensus to accept that to mainline.

What we need for this chip is quite special regarding PM. It is not =
about knowing
when to suspend/resume or power down/up the UART or host.

It is about that the chip might be in the wrong state, i.e. powered on =
when it
should be off and vice versa. This can only be detected by monitoring =
RxD
activity and taking action if it is in the unexpected state. And that =
must
be possible independently of some user space having /dev/ttyO1 opened.

BR,
Nikolaus