public inbox for linux-serial@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Gerhard Engleder <gerhard@engleder-embedded.com>
Cc: linux-serial@vger.kernel.org, gregkh@linuxfoundation.org,
	jirislaby@kernel.org, lukas@wunner.de,
	Gerhard Engleder <eg@keba.com>
Subject: Re: [PATCH v4 1/2] serial: Keep rs485 settings for devices without firmware node
Date: Wed, 26 Nov 2025 14:10:17 +0100	[thread overview]
Message-ID: <aSb8OTRLUsgcXUjO@black.igk.intel.com> (raw)
In-Reply-To: <20251023151229.11774-2-gerhard@engleder-embedded.com>

On Thu, Oct 23, 2025 at 05:12:28PM +0200, Gerhard Engleder wrote:
> 
> Commit fe7f0fa43cef ("serial: 8250: Support rs485 devicetree properties")
> retrieves rs485 properties for 8250 drivers. These properties are read
> from the firmware node of the device within uart_get_rs485_mode(). If the
> firmware node does not exist, then the rs485 flags are still reset. Thus,
> 8250 driver cannot set rs485 flags to enable a defined rs485 mode during
> driver loading. This is no problem so far, as no 8250 driver sets the
> rs485 flags.
> 
> The default rs485 mode can also be set by firmware nodes. But for some
> devices a firmware node does not exist. E.g., for a PCIe based serial
> interface on x86 no device tree is available and the ACPI information of
> the BIOS often cannot by modified.

While the code is okay per se, the above statement is not fully true.
We specifically have device properties and software nodes to provide
the missing bits.

> In this case it shall be possible,
> that a driver works out of the box by setting a reasonable default rs485
> mode.
> 
> If no firmware node exists, then it should be possible for the driver to
> set a reasonable default rs485 mode. Therefore, reset rs485 flags only
> if a firmware node exists.

-- 
With Best Regards,
Andy Shevchenko



  parent reply	other threads:[~2025-11-26 13:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-23 15:12 [PATCH v4 0/2] serial: add KEBA UART driver Gerhard Engleder
2025-10-23 15:12 ` [PATCH v4 1/2] serial: Keep rs485 settings for devices without firmware node Gerhard Engleder
2025-10-26  9:25   ` Lukas Wunner
2025-11-26 13:10   ` Andy Shevchenko [this message]
2025-11-26 20:42     ` Gerhard Engleder
2025-10-23 15:12 ` [PATCH v4 2/2] serial: 8250: add driver for KEBA UART Gerhard Engleder
2025-10-26  9:30   ` Lukas Wunner
2025-11-26 13:17   ` Andy Shevchenko
2025-11-26 21:06     ` Gerhard Engleder
2025-11-26 21:33       ` Andy Shevchenko
2025-11-27 19:40         ` Gerhard Engleder
2025-11-27 19:58           ` Andy Shevchenko
2025-11-26 15:46   ` Ilpo Järvinen
2025-11-26 21:30     ` Gerhard Engleder
2025-11-27  9:28       ` Ilpo Järvinen
2025-11-27 19:43         ` Gerhard Engleder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aSb8OTRLUsgcXUjO@black.igk.intel.com \
    --to=andriy.shevchenko@intel.com \
    --cc=eg@keba.com \
    --cc=gerhard@engleder-embedded.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=lukas@wunner.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox