On 17.07.2018 15:21, Tom Rini wrote:
On Tue, Jul 17, 2018 at 12:45:51PM +0000, Alexey Brodkin wrote:
Hi Felix,
-----Original Message----- From: Felix Brack [mailto:fb@ltec.ch] Sent: Tuesday, July 17, 2018 3:13 PM To: Alexander Graf agraf@suse.de; Lokesh Vutla lokeshvutla@ti.com; u-boot@lists.denx.de Cc: Wolfgang Denk wd@denx.de; Tom Rini trini@konsulko.com; Marek Vasut marek.vasut@gmail.com; Patrice Chotard patrice.chotard@st.com; Michal Simek michal.simek@xilinx.com; Simon Glass sjg@chromium.org; Alexey Brodkin Alexey.Brodkin@synopsys.com; Bin Meng bmeng.cn@gmail.com; Ley Foon Tan ley.foon.tan@intel.com; Patrick Delaunay patrick.delaunay@st.com; Mario Six mario.six@gdsys.cc; Stefan Roese sr@denx.de; Bernhard Messerklinger bernhard.messerklinger@br-automation.com Subject: Re: [PATCH v2] serial: ns16550: Add register shift variable
[snip]
Adding a separate PORT in ns16550_serial_ids for a particular architecture, platform or SoC would be an option. However the patch I posted is much more generic as it offers to set the reg-shift property for no matter what architecture, platform or SoC. It can also easily be extended by adding more conditional defaults to the Kconfig file.
I'd say we're dealing with just one corner-case here. If I understand a concept of Device Tree it is supposed to describe your hardware. Thus if reg shift exists in your HW it should be explicitly mentioned in your .dts. If for some [historical] reason you have to deal with "incorrect" .dts then I'd prefer to have mentioned quirk with a separate PORT in ns16550_serial_ids instead of adding yet another Kconfig option.
So, this is part of the problem I suppose. I don't know _why_ we can't just add the correct and valid reg-shift property to the dtsi file in Linux and be done with it. Then the U-Boot driver would work because we parse that property.
The only reason I can see why the <reg-shift> property "can't be added" to the Linux .dtsi file is that there is nothing broken in Linux. Hence we would actually ask Linux to add a property required by U-Boot.
This is exactly the reason for my RFC suggesting other solutions as the U-Boot build system is able to use a SoC and even a board specific .dtsi file.
regards Felix