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: <20230314075609.5232-1-lukas.bulwahn@gmail.com>
Date:   Tue, 14 Mar 2023 08:56:09 +0100
From:   Lukas Bulwahn <lukas.bulwahn@...il.com>
To:     Mark Brown <broonie@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jens Axboe <axboe@...nel.dk>, linux-spi@...r.kernel.org,
        linux-kernel@...r.kernel.org
Cc:     kernel-janitors@...r.kernel.org,
        Lukas Bulwahn <lukas.bulwahn@...il.com>
Subject: [PATCH] spi: docs: adjust summary to CONFIG_SYSFS_DEPRECATED removal

With commit 721da5cee9d4 ("driver core: remove CONFIG_SYSFS_DEPRECATED and
CONFIG_SYSFS_DEPRECATED_V2"), ./scripts/checkkconfigsymbols.py indicated
an unresolved reference to the config SYSFS_DEPRECATED in the SPI summary
documentation.

Simply, delete the sentence referring to the removed config there. Also
update the documentation, as these sys/class entries should always be
symlinks, as the commit message of the commit above suggests.

Signed-off-by: Lukas Bulwahn <lukas.bulwahn@...il.com>
---
Mark, Greg, Jens, please confirm that these sys/class entries now always
are symlinks. That is simply my guess after reading a bit on sysfs_deprecated
also changed compared to the normal setup, but I am not the expert here.

 Documentation/spi/spi-summary.rst | 23 ++++++++++-------------
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/Documentation/spi/spi-summary.rst b/Documentation/spi/spi-summary.rst
index 3c95ae322fb1..33f05901ccf3 100644
--- a/Documentation/spi/spi-summary.rst
+++ b/Documentation/spi/spi-summary.rst
@@ -178,10 +178,10 @@ shows up in sysfs in several locations::
 
    /sys/bus/spi/drivers/D ... driver for one or more spi*.* devices
 
-   /sys/class/spi_master/spiB ... symlink (or actual device node) to
-	a logical node which could hold class related state for the SPI
-	master controller managing bus "B".  All spiB.* devices share one
-	physical SPI bus segment, with SCLK, MOSI, and MISO.
+   /sys/class/spi_master/spiB ... symlink to a logical node which could hold
+	class related state for the SPI master controller managing bus "B".
+	All spiB.* devices share one physical SPI bus segment, with SCLK,
+	MOSI, and MISO.
 
    /sys/devices/.../CTLR/slave ... virtual file for (un)registering the
 	slave device for an SPI slave controller.
@@ -191,16 +191,13 @@ shows up in sysfs in several locations::
 	Reading from this file shows the name of the slave device ("(null)"
 	if not registered).
 
-   /sys/class/spi_slave/spiB ... symlink (or actual device node) to
-	a logical node which could hold class related state for the SPI
-	slave controller on bus "B".  When registered, a single spiB.*
-	device is present here, possible sharing the physical SPI bus
-	segment with other SPI slave devices.
+   /sys/class/spi_slave/spiB ... symlink to a logical node which could hold
+	class related state for the SPI slave controller on bus "B".  When
+	registered, a single spiB.* device is present here, possible sharing
+	the physical SPI bus segment with other SPI slave devices.
 
-Note that the actual location of the controller's class state depends
-on whether you enabled CONFIG_SYSFS_DEPRECATED or not.  At this time,
-the only class-specific state is the bus number ("B" in "spiB"), so
-those /sys/class entries are only useful to quickly identify busses.
+At this time, the only class-specific state is the bus number ("B" in "spiB"),
+so those /sys/class entries are only useful to quickly identify busses.
 
 
 How does board-specific init code declare SPI devices?
-- 
2.17.1

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ