From: Tony Lindgren <tony@atomide.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Jiri Slaby" <jirislaby@kernel.org>,
"Andy Shevchenko" <andriy.shevchenko@intel.com>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Johan Hovold" <johan@kernel.org>,
"Sebastian Andrzej Siewior" <bigeasy@linutronix.de>,
"Vignesh Raghavendra" <vigneshr@ti.com>,
linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-serial@vger.kernel.org
Subject: Re: [PATCH v5 1/1] serial: core: Start managing serial controllers to enable runtime PM
Date: Wed, 1 Feb 2023 08:38:42 +0200 [thread overview]
Message-ID: <Y9oI8m132aQOeSed@atomide.com> (raw)
In-Reply-To: <Y9jo9bTnmejWYoH2@kroah.com>
* Greg Kroah-Hartman <gregkh@linuxfoundation.org> [230131 10:10]:
> On Mon, Jan 16, 2023 at 09:59:58AM +0200, Tony Lindgren wrote:
> > We want to enable runtime PM for serial port device drivers in a generic
> > way. To do this, we want to have the serial core layer manage the
> > registered physical serial controller devices.
> >
> > To do this, let's set up a struct device for the serial core controller
> > as suggested by Greg and Jiri. The serial core controller devices are
> > children of the physical serial port device. The serial core controller
> > device is needed to support multiple different kind of ports connected
> > to single physical serial port device.
> >
> > Let's also set up a struct device for the serial core port. The serial
> > core port instances are children of the serial core controller device.
>
> Looking better, but why is this new device a platform device? That
> feels odd, you should never have a platform device hanging off of a
> non-platform device, right?
No special need for it to be a platform device. It just is easy to set
up, and for my test case the serial port physical device is also a
platform device.
What's your preference here?
> What does the sysfs tree look like now with this patch applied?
Below are two examples of what's in sysfs.
Regards,
Tony
8< -----------------
On arm64 with two physical 8250 devices I have:
# ls -l /sys/devices/platform/serial8250/
total 0
lrwxrwxrwx 1 root root 0 Jan 1 1970 driver -> ../../../bus/platform/drivers/serial8250
-rw-r--r-- 1 root root 4096 Jan 1 1970 driver_override
-r--r--r-- 1 root root 4096 Jan 1 1970 modalias
drwxr-xr-x 2 root root 0 Jan 1 1970 power
drwxr-xr-x 5 root root 0 Jan 1 1970 serial-ctrl.0.auto
lrwxrwxrwx 1 root root 0 Jan 1 1970 subsystem -> ../../../bus/platform
drwxr-xr-x 4 root root 0 Jan 1 1970 tty
-rw-r--r-- 1 root root 4096 Jan 1 1970 uevent
# ls -l /sys/devices/platform/serial8250/serial-ctrl*
total 0
lrwxrwxrwx 1 root root 0 Jan 1 1970 driver -> ../../../../bus/platform/drivers/serial-ctrl
-rw-r--r-- 1 root root 4096 Jan 1 1970 driver_override
-r--r--r-- 1 root root 4096 Jan 1 1970 modalias
drwxr-xr-x 2 root root 0 Jan 1 1970 power
drwxr-xr-x 3 root root 0 Jan 1 1970 serial-port.1.auto
drwxr-xr-x 3 root root 0 Jan 1 1970 serial-port.4.auto
lrwxrwxrwx 1 root root 0 Jan 1 1970 subsystem -> ../../../../bus/platform
-rw-r--r-- 1 root root 4096 Jan 1 1970 uevent
On x86_64 qemu with one port I have:
# ls -l /sys/devices/pnp0/00:04/
total 0
lrwxrwxrwx 1 root root 0 Feb 1 06:13 driver -> ../../../bus/pnp/drivers/serial
lrwxrwxrwx 1 root root 0 Feb 1 06:13 firmware_node -> ../../LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:01/PNP0501:00
-r--r--r-- 1 root root 4096 Feb 1 06:13 id
-r--r--r-- 1 root root 4096 Feb 1 06:13 options
-rw-r--r-- 1 root root 4096 Feb 1 06:13 resources
drwxr-xr-x 3 root root 0 Feb 1 06:12 serial-ctrl.0.auto
lrwxrwxrwx 1 root root 0 Feb 1 06:13 subsystem -> ../../../bus/pnp
drwxr-xr-x 3 root root 0 Feb 1 06:12 tty
-rw-r--r-- 1 root root 4096 Feb 1 06:12 uevent
# ls -l /sys/devices/pnp0/00:04/serial-ctrl.0.auto/
total 0
lrwxrwxrwx 1 root root 0 Feb 1 06:13 driver -> ../../../../bus/platform/drivers/serial-ctrl
-rw-r--r-- 1 root root 4096 Feb 1 06:13 driver_override
-r--r--r-- 1 root root 4096 Feb 1 06:13 modalias
drwxr-xr-x 2 root root 0 Feb 1 06:12 serial-port.1.auto
lrwxrwxrwx 1 root root 0 Feb 1 06:13 subsystem -> ../../../../bus/platform
-rw-r--r-- 1 root root 4096 Feb 1 06:12 uevent
next prev parent reply other threads:[~2023-02-01 6:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-16 7:59 [PATCH v5 1/1] serial: core: Start managing serial controllers to enable runtime PM Tony Lindgren
2023-01-31 10:09 ` Greg Kroah-Hartman
2023-02-01 6:38 ` Tony Lindgren [this message]
2023-04-20 11:34 ` Greg Kroah-Hartman
2023-03-02 16:06 ` Andy Shevchenko
2023-03-06 6:49 ` Tony Lindgren
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=Y9oI8m132aQOeSed@atomide.com \
--to=tony@atomide.com \
--cc=andriy.shevchenko@intel.com \
--cc=bigeasy@linutronix.de \
--cc=gregkh@linuxfoundation.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jirislaby@kernel.org \
--cc=johan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--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.