On 22/06/2017 at 10:22, Uwe Kleine-K?nig wrote:

Hello Sascha,

On Thu, Jun 22, 2017 at 08:31:57AM +0200, Sascha Hauer wrote:

quoted

On Wed, Jun 21, 2017 at 12:21:22PM +0200, Uwe Kleine-K?nig wrote:

quoted

+/**
+ * of_get_rs485_mode() - Implement parsing rs485 properties
+ * @np: uart node
+ * @rs485conf: output parameter
+ *
+ * This function implements the device tree binding described in
+ * Documentation/devicetree/bindings/serial/rs485.txt.
+ *
+ * Return: 0 on success, 1 if the node doesn't contain rs485 stuff, or a
+ * negative error code.
+ */
+int of_get_rs485_mode(struct device_node *np, struct serial_rs485 *rs485conf)
+{
+	u32 rs485_delay[2];
+	int ret;
+
+	ret = of_property_read_u32_array(np, "rs485-rts-delay" rs485_delay, 2);
+	if (ret == -EINVAL) /* property does not exist */
+		return 1;

As the de-facto standard for the drivers implementing the rs485 bindings
is to make the properties optional, despite the documentation. Wouldn't

I must admit that I failed to mention in the commit log that being
strict here was added by me even though I'm not the author.

quoted

it be better to make this property optional in the binding instead? This
wouldn't unnecessarily break old device trees and 0/0 seems a sane
default we can use when the property doesn't exist.

Would be fine for me, too. It was Nicolas Ferre who specified this as
being required in 0331bbf3c6fd9. Added people who discussed the patch
back then (but without questioning rs485-rts-delay being mandatory).

Uwe,

This would be find with me too.
Indeed, the conversion to an optional option won't break the atmel driver.

Thanks for your work on this topic.

Best regards,
-- 
Nicolas Ferre