spi: docs: adjust summary to CONFIG_SYSFS_DEPRECATED removal
Commit Message
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@gmail.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(-)
Comments
On Tue, Mar 14, 2023 at 9:03 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Tue, Mar 14, 2023 at 08:56:09AM +0100, Lukas Bulwahn wrote:
> > 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@gmail.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.
>
> They have been symlinks for years, the only subsystem that the
> CONFIG_SYSFS_DEPRECATED logic still modified was for the block
> subsystem. So your change looks good to me, thanks for doing this:
>
Thanks for confirming, Greg. That was my wild guess and it was just a
quick update while passing through that one section of that whole
document.
Lukas
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
On Tue, 14 Mar 2023 08:56:09 +0100, Lukas Bulwahn wrote:
> 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.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi: docs: adjust summary to CONFIG_SYSFS_DEPRECATED removal
commit: 93d205457dcda137e73dbfdcaa6a3c4c3b6d505f
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
@@ -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?