linux-kernel - [RFC PATCH 0/2] serial: kgdboc: convert to the faux device interface

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250506125133.108786-1-nicolescu.roxana@protonmail.com>
Date: Tue, 06 May 2025 12:51:36 +0000
From: Roxana Nicolescu <nicolescu.roxana@...tonmail.com>
To: gregkh@...uxfoundation.org, rafael@...nel.org, dakr@...nel.org, jason.wessel@...driver.com, danielt@...nel.org, dianders@...omium.org, jirislaby@...nel.org
Cc: kgdb-bugreport@...ts.sourceforge.net, linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org, skhan@...uxfoundation.org, linux-kernel-mentees@...ts.linux.dev
Subject: [RFC PATCH 0/2] serial: kgdboc: convert to the faux device interface

The kgdboc uses a "fake" platform device to handle tty drivers showing
up late. In case the tty device is not detected during probe, it will
return EPROBE_DEFER which means the probe will be called later when the
tty device might be there. Before this, the kgdboc driver
would be initialized early in the process (useful for early boot
debugging) but then the tty device wouldn't be there, and retry wouldn't be
done later. For a better explanation, see commit
'68e55f61c138: ("kgdboc: Use a platform device to handle tty drivers
showing up late")'.

This replaces the platform_device usage with faux_device which was
introduced recently for scenarios like this, where there is not real
platform device needed. Moreover, it makes the code cleaner than before.

To acomodate this, I had to change the faux_device implementation. When
the device is created, if probe failed and the driver did not bind to the
device, it will be destroyed, therefore probe won't be retried later in
case of EPROBE_DEFER. Now, the faux device is destroyed only if probe
failed with something other than -EPROBE_DEFER.

I am kindly asking for your advice here, because I am not sure this is
100% the intended usage of faux_device. In the kgdboc driver, the
platform device is for sure fake, but if we're gonna use it for deferred
probe, isn't it defeating the purpose of a faux device not being
attached to real hardware? I also checked the previous discussions when
the faux device was introduced and some people even argue than having
probe and remove functions is also a bit contradictory.
Let me know what you think.

Roxana Nicolescu (2):
  driver core: faux: create the device if probe() is deferred too
  serial: kgdboc: convert to use faux_device

 drivers/base/faux.c         | 10 +++++---
 drivers/tty/serial/kgdboc.c | 50 +++++++++++--------------------------
 2 files changed, 21 insertions(+), 39 deletions(-)

-- 
2.34.1