Re: [PATCH 1/8] serial: core: only get RS485 termination gpio if supported
From: Andy Shevchenko <hidden>
Date: 2022-06-23 16:32:47
Also in:
linux-devicetree, linux-serial, lkml
On Thu, Jun 23, 2022 at 06:08:56PM +0200, Lino Sanfilippo wrote:
On 23.06.22 at 11:45, Andy Shevchenko wrote:quoted
On Thu, Jun 23, 2022 at 4:00 AM Lino Sanfilippo [off-list ref] wrote:quoted
On 22.06.22 at 19:04, Andy Shevchenko wrote:quoted
On Wed, Jun 22, 2022 at 05:46:52PM +0200, Lino Sanfilippo wrote:quoted
From: Lino Sanfilippo <redacted> In uart_get_rs485_mode() only try to get a termination GPIO if RS485 bus termination is supported by the driver.I'm not sure I got the usefulness of this change. We request GPIO line as optional, so if one is defined it in the DT/ACPI, then they probably want to (opportunistically) have it> With your change it's possible to have a DTS where GPIO line defined in a broken way and user won't ever know about it, if they are using platforms without termination support.This behavior is not introduced with this patch, also in the current code the driver wont inform the user if it does not make use erroneous defined termination GPIO.It does. If a previously stale GPIO resource may have deferred a probe and hence one may debug why the driver is not working, after this change one may put a stale GPIO resource into DT/ACPI and have nothing in the result. Meaning the change relaxes validation which I consider is not good.Ok I see the point. So what about changing it to:
You mean adding below after the existing code in the module?
if (port->rs485_term_gpio &&
!(port->rs485_supported->flags & SER_RS485_TERMINATE_BUS)) {
dev_warn(port->dev,
"%s (%d): RS485 termination gpio not supported by driver\n",
port->name, port->line);
devm_gpiod_put(dev, port->rs485_term_gpio);
port->rs485_term_gpio = NULL;
}
This would also be consistent to the warnings we print in uart_sanitize_serial_rs485() for invalid
RS485 settings.Probably it's okay, but I dunno we have much on this to gain. Users may start complaining of this (harmless) warning. I leave it to others to comment. -- With Best Regards, Andy Shevchenko _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel