linux-kernel - Re: [PATCH v2 2/4] dt-bindings: add bus number property

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a0f=fahxax1jOz32uLzitV_PRPoHAfrQLx_qccmh_gcXg@mail.gmail.com>
Date:   Wed, 6 Oct 2021 11:41:17 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Paweł Anikiel <pan@...ihalf.com>
Cc:     Alexandre Belloni <alexandre.belloni@...tlin.com>,
        Arnd Bergmann <arnd@...db.de>, jarkko.nikula@...ux.intel.com,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Rob Herring <robh+dt@...nel.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Olof Johansson <olof@...om.net>, SoC Team <soc@...nel.org>,
        Dinh Nguyen <dinguyen@...nel.org>,
        Pratyush Yadav <p.yadav@...com>,
        Tudor Ambarus <Tudor.Ambarus@...rochip.com>,
        Linux I2C <linux-i2c@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Sebastian Reichel <sre@...nel.org>,
        "Leizhen (ThunderTown)" <thunder.leizhen@...wei.com>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        DTML <devicetree@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Konrad Adamczyk <ka@...ihalf.com>,
        Tomasz Nowicki <tn@...ihalf.com>,
        Jacek Majkowski <jam@...ihalf.com>,
        Alexandru Stan <amstan@...gle.com>
Subject: Re: [PATCH v2 2/4] dt-bindings: add bus number property

On Wed, Oct 6, 2021 at 11:21 AM Paweł Anikiel <pan@...ihalf.com> wrote:
> On Tue, Oct 5, 2021 at 6:28 PM Alexandre Belloni <alexandre.belloni@...tlin.com> wrote:
>>
>> What happens when two nodes have the same busno property because e.g.
>> one is in a dtsi and the other one is in a dts?
>
>
> If busno is set, the alias is ignored (the code that checks aliases
> is never reached). If two nodes have the same busno property, we get
> a WARN in drivers/i2c/i2c-core-base.c:1637, and only on of them
> gets attached.
>
> What is a better way of doing this then? Is adding aliases to the
> devicetree like this okay?
>
> aliases {
> ...
> i2c0 = &i2c0;
> i2c1 = &i2c1;
> };

Yes, this is the normal way to do it.

The way I tend to think of it is that the soc.dtsi file contains a description
of hardware that exists inside of the chip and is as much as possible
detached from how an OS uses it or what is connected to it on the
outside. You then have the board.dts file that contains everything specific
to the board.

The /chosen and /aliases nodes in turn are specific to the individual
machine, based on local configuration, installed OS and boot loader,
and how the devices on the board are used.

We tend to have the /aliases node populated with a sensible configuration
of how we expect them to be used for a given board. So if your machine
connects two of the internal i2c buses on the SoC, it makes sense to assign
them the aliases i2c0 and i2c1. On the other hand, if one of them is
not connected anywhere, you may skip that, or if there is an additional
i2c controller in programmable logic or behind some gpio lines, you can
make that your i2c0 alias.

      Arnd