Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp20913345ybl; Sun, 5 Jan 2020 14:52:08 -0800 (PST) X-Google-Smtp-Source: APXvYqygEQV020HfJUvPdh+KTMOfOC0q5nCbziKLyt7ufqCfE0D4cSYCFlf2unMdkXEakAffv/O7 X-Received: by 2002:a9d:c02:: with SMTP id 2mr114995183otr.183.1578264728070; Sun, 05 Jan 2020 14:52:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578264728; cv=none; d=google.com; s=arc-20160816; b=jXGmZ22JYN/dxAiWNaFqCSVodt7TmVEwY8+AcCWOTffkS2fwEdzD9Rtk/wxmMv4c9J jMc6kX+MT94kss+QTHcU6giTRNRgqrVMSmMU3bvOU04nEqX0CPGxELKFJDM5wk/Gjlfc u47rdcPFo2nAF9F6AhrjBEqFbjNssayvQs2pFQIrB2v3yZpd89zoaSKADyU0BROLN5I5 CMoUdhmaWvwbIVQs6kzBaoykh8IzFI5sw0+R4N9Y1sLNUb8tTR4xyVyxONiHxHLa7M2G tqXo4JnYhJzR8bIjlyu2P3AHGJXtWbzaRRxgph9fIsCUWKQYyrPFBOly6Osbt7Kg84Sp 3/3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=LZVrOTrcRK6H+NwWyR4PgD/6Xzn6incYDL3tmG1odCM=; b=QLr+R0FFk/04nRXQDaHYNQUAf1jHab5m41ooo3wk0FTTcTuB8XOEu49CiyoNzevni5 u7xOsEt9TThktgxMGoeG/zVNauJrve8xMKZPIIYypoM6Qs79PgqMFCRKgO1PirLgBKOG cZq4RtlpI01WAhQoUmuSv6F4whqURcGfFQJYBzP7O4lORA4M1YAdNeQ4hPZwDd/+/lvt 0Sq39JJb8UnCmiA6ULqWazD5mkGV1O6e9j8hSfQnzKHeEotEQJua+xd2QDsQIqEppwGW R/9PW5pU7YdE3hPbjlCgVsSddDTjQRBnAfbcBOMyInhlgK0LE2XasqaU8kgprJvMvpHw Ti4g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t20si34690730otr.64.2020.01.05.14.51.56; Sun, 05 Jan 2020 14:52:08 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727316AbgAEWvC (ORCPT + 99 others); Sun, 5 Jan 2020 17:51:02 -0500 Received: from hostingweb31-40.netsons.net ([89.40.174.40]:46795 "EHLO hostingweb31-40.netsons.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727201AbgAEWvC (ORCPT ); Sun, 5 Jan 2020 17:51:02 -0500 Received: from [37.160.42.38] (port=5507 helo=melee.fritz.box) by hostingweb31.netsons.net with esmtpa (Exim 4.92) (envelope-from ) id 1ioEjb-00GSqI-Hd; Sun, 05 Jan 2020 23:50:59 +0100 From: Luca Ceresoli To: linux-doc@vger.kernel.org, linux-i2c@vger.kernel.org Cc: Luca Ceresoli , Wolfram Sang , Peter Rosin , linux-kernel@vger.kernel.org Subject: [PATCH 06/26] docs: i2c: replace "I2C-transfer" -> "I2C transfer" consistently Date: Sun, 5 Jan 2020 23:49:52 +0100 Message-Id: <20200105225012.11701-6-luca@lucaceresoli.net> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20200105225012.11701-1-luca@lucaceresoli.net> References: <20200105224006.10321-1-luca@lucaceresoli.net> <20200105225012.11701-1-luca@lucaceresoli.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hostingweb31.netsons.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lucaceresoli.net X-Get-Message-Sender-Via: hostingweb31.netsons.net: authenticated_id: luca+lucaceresoli.net/only user confirmed/virtual account not confirmed X-Authenticated-Sender: hostingweb31.netsons.net: luca@lucaceresoli.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org "I2C transfer" is a legitimate english sentence, no need for a hyphen between the two words, as as such it is used in most of the documentation. Remove the hyphen in the few places where it is present. Signed-off-by: Luca Ceresoli --- Documentation/i2c/i2c-topology.rst | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/Documentation/i2c/i2c-topology.rst b/Documentation/i2c/i2c-topology.rst index b413ef6a6773..2a18b53e3508 100644 --- a/Documentation/i2c/i2c-topology.rst +++ b/Documentation/i2c/i2c-topology.rst @@ -137,14 +137,14 @@ Mux-locked Example When there is an access to D1, this happens: - 1. Someone issues an I2C-transfer to D1. + 1. Someone issues an I2C transfer to D1. 2. M1 locks muxes on its parent (the root adapter in this case). 3. M1 calls ->select to ready the mux. - 4. M1 (presumably) does some I2C-transfers as part of its select. - These transfers are normal I2C-transfers that locks the parent + 4. M1 (presumably) does some I2C transfers as part of its select. + These transfers are normal I2C transfers that locks the parent adapter. - 5. M1 feeds the I2C-transfer from step 1 to its parent adapter as a - normal I2C-transfer that locks the parent adapter. + 5. M1 feeds the I2C transfer from step 1 to its parent adapter as a + normal I2C transfer that locks the parent adapter. 6. M1 calls ->deselect, if it has one. 7. Same rules as in step 4, but for ->deselect. 8. M1 unlocks muxes on its parent. @@ -169,7 +169,7 @@ PL1. If you build a topology with a parent-locked mux being the child of another mux, this might break a possible assumption from the child mux that the root adapter is unused between its select op and the actual transfer (e.g. if the child mux is auto-closing - and the parent mux issues I2C-transfers as part of its select). + and the parent mux issues I2C transfers as part of its select). This is especially the case if the parent mux is mux-locked, but it may also happen if the parent mux is parent-locked. @@ -197,15 +197,15 @@ Parent-locked Example When there is an access to D1, this happens: - 1. Someone issues an I2C-transfer to D1. + 1. Someone issues an I2C transfer to D1. 2. M1 locks muxes on its parent (the root adapter in this case). 3. M1 locks its parent adapter. 4. M1 calls ->select to ready the mux. - 5. If M1 does any I2C-transfers (on this root adapter) as part of - its select, those transfers must be unlocked I2C-transfers so + 5. If M1 does any I2C transfers (on this root adapter) as part of + its select, those transfers must be unlocked I2C transfers so that they do not deadlock the root adapter. - 6. M1 feeds the I2C-transfer from step 1 to the root adapter as an - unlocked I2C-transfer, so that it does not deadlock the parent + 6. M1 feeds the I2C transfer from step 1 to the root adapter as an + unlocked I2C transfer, so that it does not deadlock the parent adapter. 7. M1 calls ->deselect, if it has one. 8. Same rules as in step 5, but for ->deselect. @@ -293,7 +293,7 @@ device lockups and/or other problems. The topology is especially troublesome if M2 is an auto-closing mux. In that case, any interleaved accesses to D4 might close M2 -prematurely, as might any I2C-transfers part of M1->select. +prematurely, as might any I2C transfers part of M1->select. But if M2 is not making the above stated assumption, and if M2 is not auto-closing, the topology is fine. -- 2.24.1