linux-kernel - Re: [PATCH 12/13] ARM: dts: omap3-gta04: uart4 is not connected, so mark it "disabled"

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:	Sat, 24 Jan 2015 09:28:42 +1100
From:	NeilBrown <neilb@...e.de>
To:	Tony Lindgren <tony@...mide.com>
Cc:	Marek Belisko <marek@...delico.com>, bcousson@...libre.com,
	robh+dt@...nel.org, pawel.moll@....com, mark.rutland@....com,
	ijc+devicetree@...lion.org.uk, galak@...eaurora.org,
	linux-omap@...r.kernel.org, devicetree@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	hns@...delico.com, NeilBrown <neil@...wn.name>
Subject: Re: [PATCH 12/13] ARM: dts: omap3-gta04: uart4 is not connected, so
 mark it "disabled"

On Thu, 22 Jan 2015 13:40:53 -0800 Tony Lindgren <tony@...mide.com> wrote:

> * Marek Belisko <marek@...delico.com> [150122 12:42]:
> > From: NeilBrown <neil@...wn.name>
> > 
> > Signed-off-by: NeilBrown <neil@...wn.name>
> > ---
> >  arch/arm/boot/dts/omap3-gta04.dtsi | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
> > index 228e79b..8d2b0a1 100644
> > --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> > +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> > @@ -357,6 +357,10 @@
> >  	pinctrl-0 = <&uart3_pins>;
> >  };
> >  
> > +&uart4 {
> > +	status = "disabled";
> > +};
> > +
> 
> This you probably want to avoid from PM point of view. Depending on
> bootloader state of uart4, Linux may or may not be able to hit any
> deeper power states.
> 
> Marking something with status = "disabled" in dts causes the device
> entry not even to be created. That means hwmod won't be able to reset
> and idle this device during boot.
> 
> The uart4 device is there for sure even if not muxed and in incomplete
> state. You may want to also check other places where you're using
> status = "disabled" for the same reasons.

That's ... unfortunate.  Would that apply to the MCBSPs too?  They are
disabled by default so you would need to explicitly enable them all for
sensible behaviour....

Hopefully there is some way to mark as device as "this is not used, make sure
it is turned off and stays off" ???

Thanks for the heads-up.  I'll have a look and see exactly what is happening.

BTW, on the topic of OMAP UARTs and power saving...
 I note that there are now two drivers for the OMAP3 UART - omap-serial and
 8250_omap.
 I also note that your commit:

commit a2fc36613ac1af2e92cbed7af80bc72d8114dd50
    ARM: OMAP3: Use manual idle for UARTs because of DMA errata

 is incompatible with omap-serial.  In particular, if I enable runtime
 suspend of the serial port by setting the autosuspend_timeout, then incoming
 characters will no longer wake the port (if I revert your patch incoming
 chars do wake the port).
 This could (I think) be fixed by enabling the RX/CTS interrupt.  However if
 omap-serial is being deprecated, then there probably isn't any point.

 So: what is the longer term expectation for these drivers?  Should we be
 switching over to 8250?

Thanks,
NeilBrown

Content of type "application/pgp-signature" skipped