All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Mark Brown <broonie@kernel.org>,
	Geert Uytterhoeven <geert+renesas@glider.be>
Cc: linux-spi@vger.kernel.org, kernel@pengutronix.de
Subject: [PATCH 33/33] Documentation: spi: Update documentation for renaming "master" to "controller"
Date: Mon, 15 Jan 2024 21:13:19 +0100	[thread overview]
Message-ID: <be5c943816fc0e0ed466e3ede2f82b448cecc0c6.1705348270.git.u.kleine-koenig@pengutronix.de> (raw)
In-Reply-To: <cover.1705348269.git.u.kleine-koenig@pengutronix.de>

In commit 8caab75fd2c2 ("spi: Generalize SPI "master" to "controller"")
some functions and struct members were renamed. Adapt the documentation
accordingly.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
 Documentation/spi/spi-summary.rst | 74 +++++++++++++++----------------
 1 file changed, 37 insertions(+), 37 deletions(-)

diff --git a/Documentation/spi/spi-summary.rst b/Documentation/spi/spi-summary.rst
index 33f05901ccf3..e714472007f1 100644
--- a/Documentation/spi/spi-summary.rst
+++ b/Documentation/spi/spi-summary.rst
@@ -9,7 +9,7 @@ What is SPI?
 The "Serial Peripheral Interface" (SPI) is a synchronous four wire serial
 link used to connect microcontrollers to sensors, memory, and peripherals.
 It's a simple "de facto" standard, not complicated enough to acquire a
-standardization body.  SPI uses a master/slave configuration.
+standardization body.  SPI uses a host/target configuration.
 
 The three signal wires hold a clock (SCK, often on the order of 10 MHz),
 and parallel data lines with "Master Out, Slave In" (MOSI) or "Master In,
@@ -19,11 +19,11 @@ commonly used.  Each clock cycle shifts data out and data in; the clock
 doesn't cycle except when there is a data bit to shift.  Not all data bits
 are used though; not every protocol uses those full duplex capabilities.
 
-SPI masters use a fourth "chip select" line to activate a given SPI slave
+SPI hosts use a fourth "chip select" line to activate a given SPI slave
 device, so those three signal wires may be connected to several chips
 in parallel.  All SPI slaves support chipselects; they are usually active
 low signals, labeled nCSx for slave 'x' (e.g. nCS0).  Some devices have
-other signals, often including an interrupt to the master.
+other signals, often including an interrupt to the host.
 
 Unlike serial busses like USB or SMBus, even low level protocols for
 SPI slave functions are usually not interoperable between vendors
@@ -45,8 +45,8 @@ SPI slave functions are usually not interoperable between vendors
 
 In the same way, SPI slaves will only rarely support any kind of automatic
 discovery/enumeration protocol.  The tree of slave devices accessible from
-a given SPI master will normally be set up manually, with configuration
-tables.
+a given SPI host controller will normally be set up manually, with
+configuration tables.
 
 SPI is only one of the names used by such four-wire protocols, and
 most controllers have no problem handling "MicroWire" (think of it as
@@ -62,8 +62,8 @@ course they won't handle full duplex transfers.  You may find such
 chips described as using "three wire" signaling: SCK, data, nCSx.
 (That data line is sometimes called MOMI or SISO.)
 
-Microcontrollers often support both master and slave sides of the SPI
-protocol.  This document (and Linux) supports both the master and slave
+Microcontrollers often support both host and target sides of the SPI
+protocol.  This document (and Linux) supports both the host and target
 sides of SPI interactions.
 
 
@@ -118,7 +118,7 @@ starting low (CPOL=0) and data stabilized for sampling during the
 trailing clock edge (CPHA=1), that's SPI mode 1.
 
 Note that the clock mode is relevant as soon as the chipselect goes
-active.  So the master must set the clock to inactive before selecting
+active.  So the host must set the clock to inactive before selecting
 a slave, and the slave can tell the chosen polarity by sampling the
 clock level when its select line goes active.  That's why many devices
 support for example both modes 0 and 3:  they don't care about polarity,
@@ -179,7 +179,7 @@ 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 to a logical node which could hold
-	class related state for the SPI master controller managing bus "B".
+	class related state for the SPI host controller managing bus "B".
 	All spiB.* devices share one physical SPI bus segment, with SCLK,
 	MOSI, and MISO.
 
@@ -316,7 +316,7 @@ sharing a bus with a device that interprets chipselect "backwards" is
 not possible until the infrastructure knows how to deselect it.
 
 Then your board initialization code would register that table with the SPI
-infrastructure, so that it's available later when the SPI master controller
+infrastructure, so that it's available later when the SPI host controller
 driver is registered::
 
 	spi_register_board_info(spi_board_info, ARRAY_SIZE(spi_board_info));
@@ -474,34 +474,34 @@ How do I write an "SPI Master Controller Driver"?
 An SPI controller will probably be registered on the platform_bus; write
 a driver to bind to the device, whichever bus is involved.
 
-The main task of this type of driver is to provide an "spi_master".
-Use spi_alloc_master() to allocate the master, and spi_master_get_devdata()
-to get the driver-private data allocated for that device.
+The main task of this type of driver is to provide an "spi_controller".
+Use spi_alloc_host() to allocate the host controller, and
+spi_controller_get_devdata() to get the driver-private data allocated for that
+device.
 
 ::
 
-	struct spi_master	*master;
+	struct spi_controller	*ctlr;
 	struct CONTROLLER	*c;
 
-	master = spi_alloc_master(dev, sizeof *c);
-	if (!master)
+	ctlr = spi_alloc_host(dev, sizeof *c);
+	if (!ctlr)
 		return -ENODEV;
 
-	c = spi_master_get_devdata(master);
+	c = spi_controller_get_devdata(ctlr);
 
-The driver will initialize the fields of that spi_master, including the
-bus number (maybe the same as the platform device ID) and three methods
-used to interact with the SPI core and SPI protocol drivers.  It will
-also initialize its own internal state.  (See below about bus numbering
-and those methods.)
+The driver will initialize the fields of that spi_controller, including the bus
+number (maybe the same as the platform device ID) and three methods used to
+interact with the SPI core and SPI protocol drivers.  It will also initialize
+its own internal state.  (See below about bus numbering and those methods.)
 
-After you initialize the spi_master, then use spi_register_master() to
+After you initialize the spi_controller, then use spi_register_controller() to
 publish it to the rest of the system. At that time, device nodes for the
 controller and any predeclared spi devices will be made available, and
 the driver model core will take care of binding them to drivers.
 
-If you need to remove your SPI controller driver, spi_unregister_master()
-will reverse the effect of spi_register_master().
+If you need to remove your SPI controller driver, spi_unregister_controller()
+will reverse the effect of spi_register_controller().
 
 
 Bus Numbering
@@ -519,10 +519,10 @@ then be replaced by a dynamically assigned number. You'd then need to treat
 this as a non-static configuration (see above).
 
 
-SPI Master Methods
-^^^^^^^^^^^^^^^^^^
+SPI Host Controller Methods
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-``master->setup(struct spi_device *spi)``
+``ctlr->setup(struct spi_device *spi)``
 	This sets up the device clock rate, SPI mode, and word sizes.
 	Drivers may change the defaults provided by board_info, and then
 	call spi_setup(spi) to invoke this routine.  It may sleep.
@@ -534,34 +534,34 @@ SPI Master Methods
 	.. note::
 
 		BUG ALERT:  for some reason the first version of
-		many spi_master drivers seems to get this wrong.
+		many spi_controller drivers seems to get this wrong.
 		When you code setup(), ASSUME that the controller
 		is actively processing transfers for another device.
 
-``master->cleanup(struct spi_device *spi)``
+``ctlr->cleanup(struct spi_device *spi)``
 	Your controller driver may use spi_device.controller_state to hold
 	state it dynamically associates with that device.  If you do that,
 	be sure to provide the cleanup() method to free that state.
 
-``master->prepare_transfer_hardware(struct spi_master *master)``
+``ctlr->prepare_transfer_hardware(struct spi_controller *ctlr)``
 	This will be called by the queue mechanism to signal to the driver
 	that a message is coming in soon, so the subsystem requests the
 	driver to prepare the transfer hardware by issuing this call.
 	This may sleep.
 
-``master->unprepare_transfer_hardware(struct spi_master *master)``
+``ctlr->unprepare_transfer_hardware(struct spi_controller *ctlr)``
 	This will be called by the queue mechanism to signal to the driver
 	that there are no more messages pending in the queue and it may
 	relax the hardware (e.g. by power management calls). This may sleep.
 
-``master->transfer_one_message(struct spi_master *master, struct spi_message *mesg)``
+``ctlr->transfer_one_message(struct spi_controller *ctlr, struct spi_message *mesg)``
 	The subsystem calls the driver to transfer a single message while
 	queuing transfers that arrive in the meantime. When the driver is
 	finished with this message, it must call
 	spi_finalize_current_message() so the subsystem can issue the next
 	message. This may sleep.
 
-``master->transfer_one(struct spi_master *master, struct spi_device *spi, struct spi_transfer *transfer)``
+``ctrl->transfer_one(struct spi_controller *ctlr, struct spi_device *spi, struct spi_transfer *transfer)``
 	The subsystem calls the driver to transfer a single transfer while
 	queuing transfers that arrive in the meantime. When the driver is
 	finished with this transfer, it must call
@@ -576,15 +576,15 @@ SPI Master Methods
 	* 0: transfer is finished
 	* 1: transfer is still in progress
 
-``master->set_cs_timing(struct spi_device *spi, u8 setup_clk_cycles, u8 hold_clk_cycles, u8 inactive_clk_cycles)``
-	This method allows SPI client drivers to request SPI master controller
+``ctrl->set_cs_timing(struct spi_device *spi, u8 setup_clk_cycles, u8 hold_clk_cycles, u8 inactive_clk_cycles)``
+	This method allows SPI client drivers to request SPI host controller
 	for configuring device specific CS setup, hold and inactive timing
 	requirements.
 
 Deprecated Methods
 ^^^^^^^^^^^^^^^^^^
 
-``master->transfer(struct spi_device *spi, struct spi_message *message)``
+``ctrl->transfer(struct spi_device *spi, struct spi_message *message)``
 	This must not sleep. Its responsibility is to arrange that the
 	transfer happens and its complete() callback is issued. The two
 	will normally happen later, after other transfers complete, and
-- 
2.43.0


  parent reply	other threads:[~2024-01-15 20:21 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-15 20:12 [PATCH 00/33] spi: get rid of some legacy macros Uwe Kleine-König
2024-01-15 20:12 ` Uwe Kleine-König
2024-01-15 20:12 ` Uwe Kleine-König
2024-01-15 20:12 ` [PATCH 01/33] fpga: ice40-spi: Follow renaming of SPI "master" to "controller" Uwe Kleine-König
2024-01-20 15:29   ` Xu Yilun
2024-01-15 20:12 ` [PATCH 02/33] ieee802154: ca8210: " Uwe Kleine-König
2024-01-16 20:06   ` Simon Horman
2024-01-17 12:19   ` Stefan Schmidt
2024-01-15 20:12 ` [PATCH 03/33] iio: adc: ad_sigma_delta: " Uwe Kleine-König
2024-01-16  7:44   ` Nuno Sá
2024-01-21 16:27     ` Jonathan Cameron
2024-01-15 20:12 ` [PATCH 04/33] Input: pxspad - follow " Uwe Kleine-König
2024-01-16 19:14   ` Dmitry Torokhov
2024-01-15 20:12 ` [PATCH 05/33] Input: synaptics-rmi4 " Uwe Kleine-König
2024-01-16 19:14   ` Dmitry Torokhov
2024-01-15 20:12 ` [PATCH 06/33] media: mgb4: Follow " Uwe Kleine-König
2024-01-16 10:17   ` Martin Tůma
2024-01-15 20:12 ` [PATCH 07/33] media: netup_unidvb: " Uwe Kleine-König
2024-01-15 20:12 ` [PATCH 08/33] media: usb/msi2500: " Uwe Kleine-König
2024-01-15 20:12 ` [PATCH 09/33] media: v4l2-subdev: " Uwe Kleine-König
2024-01-15 20:12 ` [PATCH 10/33] misc: gehc-achc: " Uwe Kleine-König
2024-01-15 20:12 ` [PATCH 11/33] mmc: mmc_spi: " Uwe Kleine-König
2024-01-15 20:12 ` [PATCH 12/33] mtd: dataflash: " Uwe Kleine-König
2024-01-15 20:12   ` Uwe Kleine-König
2024-01-15 20:12 ` [PATCH 13/33] mtd: rawnand: fsl_elbc: Let .probe retry if local bus is missing Uwe Kleine-König
2024-01-15 20:12   ` Uwe Kleine-König
2024-01-15 20:13 ` [PATCH 14/33] net: ks8851: Follow renaming of SPI "master" to "controller" Uwe Kleine-König
2024-01-16 20:05   ` Simon Horman
2024-01-15 20:13 ` [PATCH 15/33] net: vertexcom: mse102x: " Uwe Kleine-König
2024-01-16 20:05   ` Simon Horman
2024-01-15 20:13 ` [PATCH 16/33] platform/chrome: cros_ec_spi: " Uwe Kleine-König
2024-01-18  3:49   ` Tzung-Bi Shih
2024-01-15 20:13 ` [PATCH 17/33] spi: bitbang: " Uwe Kleine-König
2024-01-15 20:13   ` Uwe Kleine-König
2024-01-16  8:33   ` Geert Uytterhoeven
2024-01-16  8:33     ` Geert Uytterhoeven
2024-01-16 12:47     ` Uwe Kleine-König
2024-01-16 12:47       ` Uwe Kleine-König
2024-01-19  7:11   ` kernel test robot
2024-01-19  7:11     ` kernel test robot
2024-01-15 20:13 ` [PATCH 18/33] spi: cadence-quadspi: Don't emit error message on allocation error Uwe Kleine-König
2024-01-15 20:13 ` [PATCH 19/33] spi: cadence-quadspi: Follow renaming of SPI "master" to "controller" Uwe Kleine-König
2024-01-15 20:13 ` [PATCH 20/33] spi: cavium: " Uwe Kleine-König
2024-01-15 20:13 ` [PATCH 21/33] spi: geni-qcom: " Uwe Kleine-König
2024-01-15 20:13 ` [PATCH 22/33] spi: loopback-test: " Uwe Kleine-König
2024-01-15 20:13 ` [PATCH 23/33] spi: slave-mt27xx: " Uwe Kleine-König
2024-01-15 20:13   ` Uwe Kleine-König
2024-01-16 15:41   ` Mark Brown
2024-01-16 15:41     ` Mark Brown
2024-01-15 20:13 ` [PATCH 24/33] spi: spidev: " Uwe Kleine-König
2024-01-15 20:13 ` [PATCH 25/33] staging: fbtft: " Uwe Kleine-König
2024-01-15 20:13   ` Uwe Kleine-König
2024-01-15 20:13 ` [PATCH 26/33] staging: greybus: spi: " Uwe Kleine-König
2024-01-16  5:38   ` Viresh Kumar
2024-01-15 20:13 ` [PATCH 27/33] tpm_tis_spi: " Uwe Kleine-König
2024-01-19 21:29   ` Jarkko Sakkinen
2024-01-15 20:13 ` [PATCH 28/33] usb: gadget: max3420_udc: " Uwe Kleine-König
2024-01-16  7:25   ` Herve Codina
2024-01-15 20:13 ` [PATCH 29/33] video: fbdev: mmp: " Uwe Kleine-König
2024-01-15 20:13   ` Uwe Kleine-König
2024-01-15 20:13 ` [PATCH 30/33] wifi: libertas: " Uwe Kleine-König
2024-01-18  9:26   ` Kalle Valo
2024-01-15 20:13 ` [PATCH 31/33] spi: fsl-lib: " Uwe Kleine-König
2024-01-15 20:13 ` [PATCH 32/33] spi: Drop compat layer from renaming " Uwe Kleine-König
2024-01-15 20:13 ` Uwe Kleine-König [this message]
2024-01-16 14:40 ` [PATCH 00/33] spi: get rid of some legacy macros Mark Brown
2024-01-16 14:40   ` Mark Brown
2024-01-16 14:40   ` Mark Brown
2024-01-16 15:18   ` Uwe Kleine-König
2024-01-16 15:18     ` Uwe Kleine-König
2024-01-16 15:18     ` Uwe Kleine-König

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=be5c943816fc0e0ed466e3ede2f82b448cecc0c6.1705348270.git.u.kleine-koenig@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --cc=broonie@kernel.org \
    --cc=geert+renesas@glider.be \
    --cc=kernel@pengutronix.de \
    --cc=linux-spi@vger.kernel.org \
    /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.