Hi Andy, > Am 10.01.2017 um 13:20 schrieb Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>: > > On Tue, 2017-01-10 at 13:10 +0100, H. Nikolaus Schaller wrote: > >>> 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. >> >> The device I want to upstream the driver speaks NMEA but should be >> powered down unless accessed... > > By the way, have you seen the series [1] I'm working on towards bringing > runtime PM for all (current) serial drivers? > > [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 -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
