linux-kernel - Re: [PATCH 0/9] Serial slave device bus

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 10 Jan 2017 13:40:21 +0100
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Marcel Holtmann <marcel@...tmann.org>,
        Rob Herring <robh@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        Sebastian Reichel <sre@...nel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Peter Hurley <peter@...leysoftware.com>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        Loic Poulain <loic.poulain@...el.com>,
        Pavel Machek <pavel@....cz>, NeilBrown <neil@...wn.name>,
        Linus Walleij <linus.walleij@...aro.org>,
        "open list:BLUETOOTH DRIVERS" <linux-bluetooth@...r.kernel.org>,
        linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/9] Serial slave device bus

Hi Andy,

> Am 10.01.2017 um 13:20 schrieb Andy Shevchenko <andriy.shevchenko@...ux.intel.com>:
> 
> 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