Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp3955971ybl; Tue, 21 Jan 2020 10:05:50 -0800 (PST) X-Google-Smtp-Source: APXvYqxw3R2N9FD88/ySkZaK1L778ox6HCy7+gCmckvxYTj5pqcp+pPclX3R0hbw/92ABN9wiarh X-Received: by 2002:a9d:7590:: with SMTP id s16mr4177002otk.89.1579629950079; Tue, 21 Jan 2020 10:05:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579629950; cv=none; d=google.com; s=arc-20160816; b=Dgx7k8YOuuy9hqMKH96qr3w7+zltFvQ3UyUILvomJPRTXTzRG2cOjwHH302D0WEc2c 5G3qh/sPGWSdHO1b+B9wkY5EwW8eD2+PX4ICfhMQ4YcDSscqGVo1elNTDsF0Y3M8ukCi 7vsh25V+diO3wnoC8Bi95OkzgC9CnRThlhRRxf5DbQ/BPpPqE17QZxeGGqqCJH4XnZKR VJ2VHmTv2uR6aaVWnL8nRZWjTfIc1bU28fwSWbfv4bZIfF7yPDLILEvUiQINl6m4Rizv B7tCPSiFPIdJrUEjc9wcUAcTyCGhitRqzu5pqLCoYUzwXAT4Ezo1WFb/5o7UGt5nX5/s J5yg== 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 :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=cg+YPsDfM1ob0yxor4xchJQEa3EuKlEGGFToU2O3ihE=; b=JTmsDjojnLGaCvlCzV6Bf5rs9tA/EijDSULCb1b5Ib9D2fK7F2JvHN+6kJD3ttYvQ2 /kFoOdsMUBspFc+tePzPVk78ryzu7j5IkWU7vBy44kIscD8NoinoDmkPab3HpPrc5EDQ nWN9gnk+7lC2HBLPwScCDK+SHCsur3EIPQeUpSazJ2qCua87e8mV/cKIzXKoTO6RgFHV YBAYDePD/ICfNFzkTTrBCHTGcCwEQpYf9hKOHEVIur+Y366b6SIYMgyHTxjWfJmTOyuM 2yGmW7niuFMmSWuCpNtuwTPDcPHgQqHqevPSUKdkCCZTRzbH9HW70GPy/Wj0uif8nU3t wrNA== 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 m4si22991070otn.281.2020.01.21.10.05.34; Tue, 21 Jan 2020 10:05:50 -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 S1729413AbgAUSCh (ORCPT + 99 others); Tue, 21 Jan 2020 13:02:37 -0500 Received: from mx2.suse.de ([195.135.220.15]:38472 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729273AbgAUSCh (ORCPT ); Tue, 21 Jan 2020 13:02:37 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 184BAAEC1; Tue, 21 Jan 2020 18:02:34 +0000 (UTC) Date: Tue, 21 Jan 2020 19:02:31 +0100 From: Jean Delvare To: Luca Ceresoli Cc: linux-doc@vger.kernel.org, linux-i2c@vger.kernel.org, Wolfram Sang , Peter Rosin , linux-kernel@vger.kernel.org Subject: Re: [PATCH 21/26] docs: i2c: instantiating-devices: rearrange static instatiation Message-ID: <20200121190231.6e88bbdc@endymion> In-Reply-To: <20200105225012.11701-21-luca@lucaceresoli.net> References: <20200105224006.10321-1-luca@lucaceresoli.net> <20200105225012.11701-1-luca@lucaceresoli.net> <20200105225012.11701-21-luca@lucaceresoli.net> Organization: SUSE Linux X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 5 Jan 2020 23:50:07 +0100, Luca Ceresoli wrote: > Among the "static" instantiation methods the "board file" method is > described first. Move it as last, since it is being replaced by the other > methods. > > Also fix subsubsection heading syntax and remove the "Method 1[abc]" > prefix as the subsubsection structure clarifies the logical hierarchy. > > Signed-off-by: Luca Ceresoli > --- > Documentation/i2c/instantiating-devices.rst | 98 ++++++++++++--------- > 1 file changed, 54 insertions(+), 44 deletions(-) > > diff --git a/Documentation/i2c/instantiating-devices.rst b/Documentation/i2c/instantiating-devices.rst > index 5debaafef64d..cbcafb36b417 100644 > --- a/Documentation/i2c/instantiating-devices.rst > +++ b/Documentation/i2c/instantiating-devices.rst > @@ -9,54 +9,27 @@ reason, the kernel code must instantiate I2C devices explicitly. There are > several ways to achieve this, depending on the context and requirements. > > > -Method 1a: Declare the I2C devices by bus number > ------------------------------------------------- > +Method 1: Declare the I2C devices statically > +-------------------------------------------- > > This method is appropriate when the I2C bus is a system bus as is the case > -for many embedded systems. On such systems, each I2C bus has a number > -which is known in advance. It is thus possible to pre-declare the I2C > -devices which live on this bus. This is done with an array of struct > -i2c_board_info which is registered by calling i2c_register_board_info(). > +for many embedded systems. On such systems, each I2C bus has a number which > +is known in advance. It is thus possible to pre-declare the I2C devices > +which live on this bus. > > -Example (from omap2 h4):: > +This information is provided to the kernel in a different way on different > +architectures: device tree, ACPI or board files. > > - static struct i2c_board_info h4_i2c_board_info[] __initdata = { > - { > - I2C_BOARD_INFO("isp1301_omap", 0x2d), > - .irq = OMAP_GPIO_IRQ(125), > - }, > - { /* EEPROM on mainboard */ > - I2C_BOARD_INFO("24c01", 0x52), > - .platform_data = &m24c01, > - }, > - { /* EEPROM on cpu card */ > - I2C_BOARD_INFO("24c01", 0x57), > - .platform_data = &m24c01, > - }, > - }; > - > - static void __init omap_h4_init(void) > - { > - (...) > - i2c_register_board_info(1, h4_i2c_board_info, > - ARRAY_SIZE(h4_i2c_board_info)); > - (...) > - } > - > -The above code declares 3 devices on I2C bus 1, including their respective > -addresses and custom data needed by their drivers. When the I2C bus in > -question is registered, the I2C devices will be instantiated automatically > -by i2c-core. > +When the I2C bus in question is registered, the I2C devices will be > +instantiated automatically by i2c-core. The devices will be automatically > +unbound and destroyed when the I2C bus they sit on goes away (if ever). > > -The devices will be automatically unbound and destroyed when the I2C bus > -they sit on goes away (if ever.) > > +Declare the I2C devices via devicetree > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > -Method 1b: Declare the I2C devices via devicetree > -------------------------------------------------- > - > -This method has the same implications as method 1a. The declaration of I2C > -devices is here done via devicetree as subnodes of the master controller. > +On platforms using devicetree the declaration of I2C devices is done in I suggest adding a comma between "devicetree" and "the" to make the sentence easier to read. > +subnodes of the master controller. > > Example:: > > @@ -81,14 +54,51 @@ Here, two devices are attached to the bus using a speed of 100kHz. For > additional properties which might be needed to set up the device, please refer > to its devicetree documentation in Documentation/devicetree/bindings/. > > - > -Method 1c: Declare the I2C devices via ACPI > -------------------------------------------- > +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` . > > > +Declare the I2C devices in board files > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > + > +In many embedded architectures devicetree has replaced the old hardware Same here between "architectures" and "devicetree". > +description based on board files, but the latter are still used in old > +code. Instantiating I2C devices via board files is done with an array of > +struct i2c_board_info which is registered by calling > +i2c_register_board_info(). > + > +Example (from omap2 h4):: > + > + static struct i2c_board_info h4_i2c_board_info[] __initdata = { > + { > + I2C_BOARD_INFO("isp1301_omap", 0x2d), > + .irq = OMAP_GPIO_IRQ(125), > + }, > + { /* EEPROM on mainboard */ > + I2C_BOARD_INFO("24c01", 0x52), > + .platform_data = &m24c01, > + }, > + { /* EEPROM on cpu card */ > + I2C_BOARD_INFO("24c01", 0x57), > + .platform_data = &m24c01, > + }, > + }; > + > + static void __init omap_h4_init(void) > + { > + (...) > + i2c_register_board_info(1, h4_i2c_board_info, > + ARRAY_SIZE(h4_i2c_board_info)); > + (...) > + } > + > +The above code declares 3 devices on I2C bus 1, including their respective > +addresses and custom data needed by their drivers. > + > + > Method 2: Instantiate the devices explicitly > -------------------------------------------- > You have some inconsistency in your spacing between subsections, some have 1 blank line before while some have 2. I think 1 is enough. At any rate it should be consistent. Reviewed-by: Jean Delvare -- Jean Delvare SUSE L3 Support