linux-kernel - Re: [PATCH 4/7] dt-bindings: gnss: add u-blox binding

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:   Fri, 4 May 2018 14:04:15 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     Sebastian Reichel <sre@...nel.org>
Cc:     Andreas Kemnade <andreas@...nade.info>,
        Johan Hovold <johan@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Arnd Bergmann <arnd@...db.de>, Pavel Machek <pavel@....cz>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rob Herring <robh+dt@...nel.org>,
        Tony Lindgren <tony@...mide.com>
Subject: Re: [PATCH 4/7] dt-bindings: gnss: add u-blox binding

Hi Sebastian,

> Am 04.05.2018 um 13:42 schrieb Sebastian Reichel <sre@...nel.org>:
> 
> [+cc Tony]
> 
> Hi,
> 
>> I think it does not need much more (if at all) than a gpio controller on
>> the OMAP3 chip (I think the clocks are active anyways for use by the other
>> UARTs).
>> 
>> We had proposed years ago to reprogram the UART RX pin by pinmux-states
>> into an interrupt gpio but that was rejected because it was not general
>> enough and ugly in the device tree (an rx-gpios record where the rx-line
>> is already connected to the UART-rx).
>> 
>> Then we did experiment with tapping the UART driver and finally the
>> serdev API was developed to solve this problem. Hence we use it now this
>> way.
> 
> Having any UART active on OMAP results in the SoC not entering
> idle/off wasting energy. For normal (i.e. not connected to a peripheral)
> TTYs you can enable runtime autosuspend and configure the RX pin as
> wakeup interrupt. This will wakeup the TTY on incoming traffic, but you
> will lose the first few characters (since the serial device needs some
> time to wakeup). This is for example supported by the N900 uart3
> (debug uart):
> 
> $ grep -A4 "&uart3 {" arch/arm/boot/dts/omap3-n900.dts 
> &uart3 {
> 	interrupts-extended = <&intc 74 &omap3_pmx_core OMAP3_UART3_RX>;
> 	pinctrl-names = "default";
> 	pinctrl-0 = <&uart3_pins>;
> };
> 
> To get it working, you also need to enable autosuspend for the tty
> in userspace (echo 3000 /sys/class/tty/ttyS2/device/power/autosuspend_delay_ms).
> This is not enabled by default due to the character loss characteristic
> during wakeup.
> 
> Having said all of this, serdev does not yet support runtime PM (at
> all). Tony is currently looking into it. Fortunately serdev allows
> us to enable runtime PM by default (once implemented), since we know
> the remote side and can (hopefully) avoid losing characters (i.e.
> with sideband wakeup gpios).

thanks for explaining this! We originally had similar thoughts when
proposing a w2sg0004 driver for the first time (years ago), but we can
not accept loosing characters...

Now, I could imagine a potential solution. The key situation why we keep
the serdev open and listening is if the driver did try to turn the module
off, but in fact did turn it on (because it was not in sync).

It should be possible to cover this by a timer that is started
in this case. If there is serdev data received after assuming the module
is turned off, the driver has detected the wrong case - and can safely
close the serdev until we want to have it powered on again.

If there is no response after turing off, the module power state is already
in sync and we can close the serdev as well - after the timeout (let's say
30 seconds). Then, the serdev UART can idle. We should open the serdev
and start this timer also in the probe function to catch an initially wrong
state.

But I think we should focus on the basics of this driver first. Then it can
be optimized later on.

BR and thanks,
Nikolaus