From: Tony Lindgren <tony@atomide.com>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Jiri Slaby" <jirislaby@kernel.org>,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
"Andy Shevchenko" <andriy.shevchenko@intel.com>,
"Dhruva Gole" <d-gole@ti.com>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"John Ogness" <john.ogness@linutronix.de>,
"Johan Hovold" <johan@kernel.org>,
"Sebastian Andrzej Siewior" <bigeasy@linutronix.de>,
"Vignesh Raghavendra" <vigneshr@ti.com>,
linux-omap@vger.kernel.org, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] serial: core: Fix probing serial_base_bus devices
Date: Thu, 1 Jun 2023 18:46:12 +0300 [thread overview]
Message-ID: <20230601154612.GE14287@atomide.com> (raw)
In-Reply-To: <d7c857b8-4aa1-cd5d-4c45-392f7ed6857b@samsung.com>
* Marek Szyprowski <m.szyprowski@samsung.com> [230601 15:09]:
> On 01.06.2023 16:21, Greg Kroah-Hartman wrote:
> > On Thu, Jun 01, 2023 at 05:14:44PM +0300, Tony Lindgren wrote:
> >> If a physical serial port device driver uses arch_initcall() we fail to
> >> probe the serial_base_bus devices and the serial port tx fails. This is
> >> because as serial_base_bus uses module_initcall().
> >>
> >> Let's fix the issue by changing serial_base_bus to use arch_initcall().
> > This will only work if the linking order is such that this will always
> > come before the drivers. Is that the case here?
>
> Yes, serial_base_bus is linked as a second object, just after the
> serial_core. Device drivers come later.
If we don't want to rely on the Makefile order here, we could do something
like the patch below.
Regards,
Tony
8< ---------------------
diff --git a/drivers/tty/serial/serial_base_bus.c b/drivers/tty/serial/serial_base_bus.c
--- a/drivers/tty/serial/serial_base_bus.c
+++ b/drivers/tty/serial/serial_base_bus.c
@@ -11,12 +11,18 @@
#include <linux/container_of.h>
#include <linux/device.h>
#include <linux/module.h>
+#include <linux/mutex.h>
#include <linux/serial_core.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
#include "serial_base.h"
+static bool serial_base_initialized;
+static DEFINE_MUTEX(serial_base_lock);
+
+static int serial_base_init(void);
+
static int serial_base_match(struct device *dev, struct device_driver *drv)
{
int len = strlen(drv->name);
@@ -48,6 +54,12 @@ static int serial_base_device_init(struct uart_port *port,
void (*release)(struct device *dev),
int id)
{
+ /*
+ * Initialize bus if not yet initialized. Some drivers are using
+ * arch_initcall()
+ */
+ serial_base_init();
+
device_initialize(dev);
dev->type = type;
dev->parent = parent_dev;
@@ -163,6 +175,14 @@ static int serial_base_init(void)
{
int ret;
+ mutex_lock(&serial_base_lock);
+
+ /* Also called from serial_base_device_init() in some cases */
+ if (serial_base_initialized) {
+ ret = 0;
+ goto out_unlock;
+ }
+
ret = bus_register(&serial_base_bus_type);
if (ret)
return ret;
@@ -175,6 +195,10 @@ static int serial_base_init(void)
if (ret)
goto err_ctrl_exit;
+ serial_base_initialized = true;
+
+ mutex_unlock(&serial_base_lock);
+
return 0;
err_ctrl_exit:
@@ -183,15 +207,21 @@ static int serial_base_init(void)
err_bus_unregister:
bus_unregister(&serial_base_bus_type);
+out_unlock:
+ mutex_unlock(&serial_base_lock);
+
return ret;
}
module_init(serial_base_init);
static void serial_base_exit(void)
{
+ mutex_lock(&serial_base_lock);
serial_base_port_exit();
serial_base_ctrl_exit();
bus_unregister(&serial_base_bus_type);
+ serial_base_initialized = false;
+ mutex_unlock(&serial_base_lock);
}
module_exit(serial_base_exit);
--
2.40.1
prev parent reply other threads:[~2023-06-01 15:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-01 14:14 [PATCH] serial: core: Fix probing serial_base_bus devices Tony Lindgren
2023-06-01 14:21 ` Greg Kroah-Hartman
2023-06-01 15:07 ` Tony Lindgren
2023-06-01 15:45 ` Greg Kroah-Hartman
2023-06-01 15:09 ` Marek Szyprowski
2023-06-01 15:44 ` Greg Kroah-Hartman
2023-06-01 15:46 ` Tony Lindgren [this message]
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=20230601154612.GE14287@atomide.com \
--to=tony@atomide.com \
--cc=andriy.shevchenko@intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bigeasy@linutronix.de \
--cc=d-gole@ti.com \
--cc=gregkh@linuxfoundation.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jirislaby@kernel.org \
--cc=johan@kernel.org \
--cc=john.ogness@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=vigneshr@ti.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.