Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp184813pxj; Tue, 15 Jun 2021 23:29:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwDephAjZgyIQxelHqR1zygVGZfbWn6rrcA6PtNXeofvMQunuAV4Fsg6AuBZn9vAFOZCzgu X-Received: by 2002:a05:6e02:e85:: with SMTP id t5mr2368879ilj.65.1623824997693; Tue, 15 Jun 2021 23:29:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623824997; cv=none; d=google.com; s=arc-20160816; b=Tkhmc7PjhpkICFs14sX8HL4TF+dua7vRZZheQPRMv+bec0YMzSbamJ5UMttysI9ID4 kWmpuhY9Yu6bdk4iNGULZNrK9gL7X/f6Kf05viRjbgoP6dcn1aecUO1oWHH5A8TwexJC 10L0rjIZt9BhMQgBOWFa6adkrTbH6JrTBTlNYB553aGzUVAt49jMWH/AogP5MHBc/VSv +wcc+j5F4eV800voAgGlAbn21ecb/psa1vGZ9XiqFFkj0yBusFE1cWzlSTLBE9jCcSsA eB/rtefOPtr/bZ/gVdwF9A/fDCtC8b/WwRldwZBtTSgl6xOEpc6Wx64MHwTxmE/Ff8eH CBGA== 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 :dkim-signature; bh=U+i3r36XLMwn+ZXpIN5pTlwKWV/Ys1MzJcOFiBBTSyM=; b=q/lQVxQe+zE2SaGa6wvD3bCF4QLJQtYkcWVsFDQIz07mNqzbakdv6dh0i6xQWHOILS APQCTIVpX3x7imMTu6khKK3KbmguBrw+23Whs+Psn8laYXyZx3VGSnXe377I01s+kOEc kC+6e474RdNFzWteuW17Z81yWidU0QGyZo4bZuoKhieBq0omtYaXGrKTKtw5F+JzzWFC Ax+Bxc5jXBJN+IEcvaPzifIKv9dUyGvux8fCtR33l3JFYlg0Csy+pyD0kzHzJu1n8tZP xgSxGqZVOTQJS4FhTy83E0CD6qcoyHgWrXx9fdYl4+CCgCEkjD4iQP5YpESl5Zv1iBSd jAaA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="tRScV6M/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o192si1874662jao.55.2021.06.15.23.29.46; Tue, 15 Jun 2021 23:29:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="tRScV6M/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232116AbhFPGbK (ORCPT + 99 others); Wed, 16 Jun 2021 02:31:10 -0400 Received: from mail.kernel.org ([198.145.29.99]:60184 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231652AbhFPG3y (ORCPT ); Wed, 16 Jun 2021 02:29:54 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 8EF0661410; Wed, 16 Jun 2021 06:27:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1623824868; bh=s5phVl8oZV+l0jXJRR0YubysAsYGTgD50ZDKsIxUKuI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tRScV6M/50Olg4gS0FMkV/wbOSXS8Z7VqKNQ89m3V07EqUCwTm5LCQ/daKwmfktGQ m/Wh8w52HlfRnzmUJm7+P7ZaGtztc1ovhiZtKuQrB81wmEcwTF4pPzZdzHCQtc9/MU cLLR97HhdqfWLoWT+ZTWZzgkzMjoDH5+xWxG92jbMhtkJBjhi4NEECHupt/vuZqBNc YD0/Pxc8TDO7HBGn8wzu1++sfLoX6Qkb+8rLryLDCLtZYgvu64zaVLfvAIH65ybmkm j1vlRDb1oCRZAvve3v0LKbnK6HY0f1LrBdHPnOYhbhcQp9MfepGRpezcIcQ9schkhY sNQbjdXKO4KGA== Received: by mail.kernel.org with local (Exim 4.94.2) (envelope-from ) id 1ltP1e-004kJS-Q9; Wed, 16 Jun 2021 08:27:46 +0200 From: Mauro Carvalho Chehab To: Jonathan Corbet , Linux Doc Mailing List Cc: Mauro Carvalho Chehab , Wolfram Sang , linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v2 18/29] docs: i2c: avoid using ReST :doc:`foo` markup Date: Wed, 16 Jun 2021 08:27:33 +0200 Message-Id: <569722e3f7d73d746c145ea78d2b4fbe5defee90.1623824363.git.mchehab+huawei@kernel.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: Mauro Carvalho Chehab Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The :doc:`foo` tag is auto-generated via automarkup.py. So, use the filename at the sources, instead of :doc:`foo`. Acked-by: Wolfram Sang Signed-off-by: Mauro Carvalho Chehab --- Documentation/i2c/instantiating-devices.rst | 2 +- Documentation/i2c/old-module-parameters.rst | 3 ++- Documentation/i2c/smbus-protocol.rst | 4 ++-- 3 files changed, 5 insertions(+), 4 deletions(-) diff --git a/Documentation/i2c/instantiating-devices.rst b/Documentation/i2c/instantiating-devices.rst index e558e0a77e0c..890c9360ce19 100644 --- a/Documentation/i2c/instantiating-devices.rst +++ b/Documentation/i2c/instantiating-devices.rst @@ -59,7 +59,7 @@ Declare the I2C devices via ACPI ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ACPI can also describe I2C devices. There is special documentation for this -which is currently located at :doc:`../firmware-guide/acpi/enumeration`. +which is currently located at Documentation/firmware-guide/acpi/enumeration.rst. Declare the I2C devices in board files diff --git a/Documentation/i2c/old-module-parameters.rst b/Documentation/i2c/old-module-parameters.rst index 38e55829dee8..b08b6daabce9 100644 --- a/Documentation/i2c/old-module-parameters.rst +++ b/Documentation/i2c/old-module-parameters.rst @@ -17,7 +17,8 @@ address), ``force`` (to forcibly attach the driver to a given device) and With the conversion of the I2C subsystem to the standard device driver binding model, it became clear that these per-module parameters were no longer needed, and that a centralized implementation was possible. The new, -sysfs-based interface is described in :doc:`instantiating-devices`, section +sysfs-based interface is described in +Documentation/i2c/instantiating-devices.rst, section "Method 4: Instantiate from user-space". Below is a mapping from the old module parameters to the new interface. diff --git a/Documentation/i2c/smbus-protocol.rst b/Documentation/i2c/smbus-protocol.rst index 64689d19dd51..9e07e6bbe6a3 100644 --- a/Documentation/i2c/smbus-protocol.rst +++ b/Documentation/i2c/smbus-protocol.rst @@ -27,8 +27,8 @@ a different protocol operation entirely. Each transaction type corresponds to a functionality flag. Before calling a transaction function, a device driver should always check (just once) for the corresponding functionality flag to ensure that the underlying I2C -adapter supports the transaction in question. See :doc:`functionality` for -the details. +adapter supports the transaction in question. See +Documentation/i2c/functionality.rst for the details. Key to symbols -- 2.31.1