Hi, On Thu, Sep 06, 2012 at 03:44:13PM -0700, Kevin Hilman wrote: > Felipe Balbi <ba...@ti.com> 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
signature.asc
Description: Digital signature
