linux-kernel - Re: [PATCH 5/5] tty: serial: Add 8250-core based omap driver

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]

Message-ID: <20140717081232.GH18374@atomide.com>
Date:	Thu, 17 Jul 2014 01:12:32 -0700
From:	Tony Lindgren <tony@...mide.com>
To:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Felipe Balbi <balbi@...com>, linux-kernel@...r.kernel.org,
	linux-serial@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH 5/5] tty: serial: Add 8250-core based omap driver

* Sebastian Andrzej Siewior <bigeasy@...utronix.de> [140717 00:44]:
> * Tony Lindgren | 2014-07-17 00:09:00 [-0700]:
> 
> >Seems to boot a bit further now with output from serial console
> >initially, then I'm getting the following error again that's probably
> >related to clocks not enabled when the registers are accessed:
> 
> It is (mostly) the same thing as before. We have additionally 
> omap_8250_startup() in the backtrace but it is the same thing.
> So you  say I miss a clock? Looking through serial8250_do_startup() I see:
> - pm_runtime_get_sync(port->dev); which should get the clocks up
> - serial8250_clear_fifos() which does a write at address + 8. Seems to 
>   work. 
> - serial_port_in(port, UART_LSR); does a read at address + 0x14, seems 
>   to work.
> - serial_port_in(port, UART_RX); does a read at address + 0. This is 
>   probably the bad one.

Hmm it could be that it works for a while because the clocks are on
from the bootloader and pm_runtime calls won't do anything. This
could happen if the interconnect data based on the ti,hwmods entry
is not getting matched to the new driver. This gets initialized when
the device entry gets created in omap_device_build_from_dt().

Or maybe something now affects the clock aliases? It seems that we
are still missing the clocks entries in the .dtsi files, see the
mappings with $ git grep uart drivers/clk/ti/
 
> Now comparing with omap-serial I noticed that I do a 32bit access
> instead a 16bit.
> Could you please try the following hack:

No change with that :) 
 
Regards,

Tony
--
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/