On Sun, Jul 02, 2017 at 03:52:39AM +0200, Andreas F?rber wrote:

Am 30.06.2017 um 16:27 schrieb Rob Herring:

quoted

On Fri, Jun 30, 2017 at 6:12 AM, Andreas F?rber [off-list ref] wrote:

quoted

Am 29.06.2017 um 22:10 schrieb Rob Herring:

quoted

On Tue, Jun 27, 2017 at 02:55:18AM +0200, Andreas F?rber wrote:

quoted

Add an initial binding for the RDA8810PL UART.

Signed-off-by: Andreas F?rber <afaerber@suse.de>
---
 Documentation/devicetree/bindings/serial/rda-uart.txt | 13 +++++++++++++
 1 file changed, 13 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/serial/rda-uart.txt

diff --git a/Documentation/devicetree/bindings/serial/rda-uart.txt b/Documentation/devicetree/bindings/serial/rda-uart.txt
new file mode 100644
index 000000000000..6840a8aee035
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/rda-uart.txt

@@ -0,0 +1,13 @@
+RDA Micro UART
+
+Required properties:
+- compatible :  "rda,8810pl-uart" for RDA8810PL
+- reg        :  Offset and length of the register set for the device.

No clocks or interrupts?

Not yet. I've only pieced together an earlycon driver so far, no full
serial driver. The .dtsi doesn't even have an interrupt-controller node
yet - wasn't clear to me whether this SoC even has a GIC and, if so,
where, from the downstream pre-DT code.

How far can you boot with no interrupts?

That was described in the cover letter, as usual.

quoted

DT bindings shouldn't unnecessarily evolve. Really, anything added
should be optional to maintain compatibility. Sometimes that's
unavoidable, but this isn't one of those cases.

Makes sense. Maybe this series should've been marked RFC. It's too late
for 4.13 anyway, so there's lots of time left to extend the bindings.

BTW I saw that Kevin was adding a disclaimer to the Amlogic bindings
that they are not stable. Is that required here, too?

I'm not really a fan of that. I've yet to see anyone remove an unstable 
tag. I'd rather see it for specific bindings, rather than platforms as a 
whole. It shouldn't be that hard to get most bindings complete enough 
and to a point that can be extended in a compatible way. In the end, 
decisions about breaking compatibility are up to the platform maintainer 
regardless of any text in some document.

quoted

So submit this when
you have something more complete.

Negative. I worked weeks and months towards perfect STM32 drivers, and
despite showing it to ST and at a LinuxCon Japan, someone else sent less
sophisticated patches (e.g., fixed-clocks) and took all the credit. Same
with Turris Omnia. Therefore I am now submitting my new patches early,
not just when everything is complete.

Fair enough. I should have said, we'll apply/ack when more complete. 
Submit it as often as you want.

Rob