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 07:29:58 -0700
From:   Tony Lindgren <tony@...mide.com>
To:     Sebastian Reichel <sre@...nel.org>
Cc:     "H. Nikolaus Schaller" <hns@...delico.com>,
        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>
Subject: Re: [PATCH 4/7] dt-bindings: gnss: add u-blox binding

* Sebastian Reichel <sre@...nel.org> [180504 13:40]:
> Hi,
> 
> On Fri, May 04, 2018 at 02:04:15PM +0200, H. Nikolaus Schaller wrote:
> > > Am 04.05.2018 um 13:42 schrieb Sebastian Reichel <sre@...nel.org>:
> > >> 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.
> 
> That sounds like a good plan.

I don't know the details, but sounds like you should might be able to
just the timer that comes with pm_runtime_use_autosuspend() :)

Regards,

Tony