From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Fri, 19 Jan 2018 15:22:24 -0500 Subject: [U-Boot] [U-Boot, 1/4] serial: ns16550: da8xx (freon/primus) is not omap-like In-Reply-To: References: <20180108125059.GA14025@squirrel.local> <20180119152650.GA23609@bill-the-cat> <20180119154115.GV4660@bill-the-cat> Message-ID: <20180119202224.GY4660@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, Jan 19, 2018 at 05:39:32PM +0100, Matthijs van Duin wrote: > On 19 January 2018 at 16:41, Tom Rini wrote: > > OK. For v2, if you can convert CONFIG_SYS_NS16550_MEM32 to Kconfig as > > well I'd appreciate it. > > I'm not hugely comfortable doing that, since that would affect even > more targets. To be honest, I don't understand why it even exists as a > separate var instead of just testing whether > CONFIG_SYS_NS16550_REG_SIZE is 4 or -4. Are there actually some crazy > targets that allocate 4 bytes per register yet fail if you use 32-bit > access? It's most likely a case that just wasn't cleaned up. If you want to correct things by dropping CONFIG_SYS_NS16550_MEM32 and checking CONFIG_SYS_NS16550_REG_SIZE instead, that's fine. > Would you object hugely to me just implicitly setting > CONFIG_SYS_NS16550_MEM32 in ns16550.h for the c6x uart variant? I > think it makes a lot of sense to do so, since in that case the driver > itself explicitly depends on being able to write a value that doesn't > fit in a byte. Well, it's just SOC_DA8XX that isn't doing it today, and we need to migrate that CONFIG symbol or do away with it. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: