linux-kernel - Re: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

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] [day] [month] [year] [list]

Date:	Mon, 15 Oct 2012 15:37:17 -0700
From:	Kevin Hilman <khilman@...prootsystems.com>
To:	Tony Lindgren <tony@...mide.com>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Sourav <sourav.poddar@...com>, Paul Walmsley <paul@...an.com>,
	Felipe Balbi <balbi@...com>, gregkh@...uxfoundation.org,
	linux-kernel@...r.kernel.org, santosh.shilimkar@...com,
	linux-serial@...r.kernel.org, linux-omap@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, alan@...ux.intel.com
Subject: Re: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.

Tony Lindgren <tony@...mide.com> writes:

> * Kevin Hilman <khilman@...prootsystems.com> [121012 13:34]:
>>
>> I'm not conviced (yet) that a mismatch is the root cause.  Yes, that's
>> what the author of $SUBJECT patch assumed and stated, but I'm not
>> pursuaded.  
>> 
>> If it's an improperly configured mux issue, then the UART will break
>> whenever the device is actually omap_device_enable'd, whether in the
>> driver or in the bus layer.
>
> I tried booting n800 here with CONFIG_OMAP_MUX disabled, and no
> change. Serial console output stops right when the console initializes.

OK, since it's not mux, and since those who actually maintain this
driver don't seem to be taking care of this, I did some digging today.

Russell is right.  It's a mismatch between assumed runtime PM state
(disabled) and actual HW state.

During init, all omap_devices are idled by default, so that they are
correctly in the state that the runtime PM framework will later expect
them to be.  That is, all devices *except* the console UART.  For that
one, we use the special hwmod flag to not idle/reset the UART since that
will cause problems during earlyprintk usage, and the switch between
the earlyprintk console and the real console driver.

Since the console uart was left enabled during init, it needs to be
fully enabled and the runtime PM status set accordingly.

The patch below does this, and works fine on 2420/n810, as well as on
3530/Overo, 3730/OveroSTORM, 3730/Beagle-XM and 4430/PandaES.

Will send patch with a proper changelog shortly,

Kevin

diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0405c81..37b5dbe 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -327,6 +327,11 @@ void __init omap_serial_init_port(struct omap_board_data *bdata,
 	if ((console_uart_id == bdata->id) && no_console_suspend)
 		omap_device_disable_idle_on_suspend(pdev);

+	if (console_uart_id == bdata->id) {
+		omap_device_enable(pdev);
+		pm_runtime_set_active(&pdev->dev);
+	}
+
 	oh->mux = omap_hwmod_mux_init(bdata->pads, bdata->pads_cnt);

 	oh->dev_attr = uart;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/