Re: [PATCH v4 00/21] OMAP UART Patches

[Felipe Balbi]

Hi,

On Thu, Sep 06, 2012 at 03:44:13PM -0700, Kevin Hilman wrote:
> Felipe Balbi <balbi@xxxxxx> writes:
> 
> > Hi guys,
> >
> > here's v4 of the omap uart patchset. No changes other than a rebase on top of
> > Greg's tty-next branch and Tony's Acked-by being added to a couple patches
> >
> > Note: I'm resending the series with Vikram's Software Flow Control fix anyway
> > as it can just be ignored if it's decided it needs to go into this merge
> > window.
> 
> Sorry to be late to the party... just getting back from some time off.
> 
> I'm assuming that this was not tested with PM, so decided I better do it

you assumed wrong. See the previous versions of the series and you'll
see I mention all the basic pm testing I did.

> myself seeing that Greg is has already merge it.  To test, I merged
> Greg's tty-next branch with v3.6-rc4 and did some PM testing.
> 
> The bad news is that it doesn't even compile (see reply to [PATCH v4
> 20/21]).  

yeah, that was an automerge issue when rebasing on greg's tty-next
branch, plus me assuming omap serial was already enabled on my .config
and not checking the compile output. Sent a patch now.

> Also, there is a big WARNING on boot[1], which seems to be triggered by
> a new check added for v3.6-rc3[2].  This appears to be introduced by
> $SUBJECT series, because I don't see it on vanilla v3.6-rc4.
> 
> The good news is that after hacking to fix up the compile problems,
> basic PM testing seems to be fine: idle to retention and off as well as
> suspend to retention and off work fine on 3430/n900, 3530/Overo,
> 3730/OveroSTORM, 3730/Beagle-xM.
> 
> Kevin
> 
> 
> [1]
> [    8.745666] WARNING: at /work/kernel/omap/pm/drivers/tty/tty_io.c:1420 tty_init_dev+0x14c/0x17c()
> [    8.755218] tty_init_dev: ttyO driver does not set tty->port. This will crash the kernel later. Fix the driver!
> [    8.765991] Modules linked in:
> [    8.769287] [<c0013d90>] (unwind_backtrace+0x0/0xf0) from [<c0036eec>] (warn_slowpath_common+0x4c/0x64)
> [    8.779327] [<c0036eec>] (warn_slowpath_common+0x4c/0x64) from [<c0036f98>] (warn_slowpath_fmt+0x30/0x40)
> [    8.789550] [<c0036f98>] (warn_slowpath_fmt+0x30/0x40) from [<c02c626c>] (tty_init_dev+0x14c/0x17c)
> [    8.799224] [<c02c626c>] (tty_init_dev+0x14c/0x17c) from [<c02c68a4>] (tty_open+0x11c/0x52c)
> [    8.808258] [<c02c68a4>] (tty_open+0x11c/0x52c) from [<c00f86ac>] (chrdev_open+0x90/0x15c)
> [    8.817108] [<c00f86ac>] (chrdev_open+0x90/0x15c) from [<c00f2b74>] (do_dentry_open+0x1e8/0x270)
> [    8.826507] [<c00f2b74>] (do_dentry_open+0x1e8/0x270) from [<c00f2c30>] (finish_open+0x34/0x4c)
> [    8.835784] [<c00f2c30>] (finish_open+0x34/0x4c) from [<c0102028>] (do_last.isra.21+0x5b0/0xbbc)
> [    8.845184] [<c0102028>] (do_last.isra.21+0x5b0/0xbbc) from [<c01026dc>] (path_openat+0xa8/0x44c)
> [    8.854675] [<c01026dc>] (path_openat+0xa8/0x44c) from [<c0102d34>] (do_filp_open+0x2c/0x80)
> [    8.863708] [<c0102d34>] (do_filp_open+0x2c/0x80) from [<c00f3b6c>] (do_sys_open+0xe8/0x184)
> [    8.872711] [<c00f3b6c>] (do_sys_open+0xe8/0x184) from [<c000db20>] (ret_fast_syscall+0x0/0x3c)
> [    8.882019] ---[ end trace e9bf408c37051346 ]---

This doesn't seem to be caused by $SUBJECT at all. See that we are
calling uart_add_one_port() which will call tty_port_register_device()
which, in turn, will call tty_port_link_device() and that will set
driver->ports[index] correctly.

Have you checked if this doesn't happen without my series before waving
your blame hammer ? FWIW, that part of the code wasn't change by
$SUBJECT at all.

-- 
balbi

Attachment: signature.asc
Description: Digital signature