LKML Archive on
help / color / mirror / Atom feed
From: Arnd Bergmann <>
To: "Paweł Anikiel" <>
Cc: Alexandre Belloni <>,
	Arnd Bergmann <>,,
	Andy Shevchenko <>,
	Mika Westerberg <>,
	Rob Herring <>,
	Philipp Zabel <>,
	Olof Johansson <>, SoC Team <>,
	Dinh Nguyen <>,
	Pratyush Yadav <>,
	Tudor Ambarus <>,
	Linux I2C <>,
	Linux Kernel Mailing List <>,
	Sebastian Reichel <>,
	"Leizhen (ThunderTown)" <>,
	Jonathan Cameron <>,
	DTML <>,
	Linux ARM <>,
	Konrad Adamczyk <>,
	Tomasz Nowicki <>,
	Jacek Majkowski <>,
	Alexandru Stan <>
Subject: Re: [PATCH v2 2/4] dt-bindings: add bus number property
Date: Wed, 6 Oct 2021 11:41:17 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Oct 6, 2021 at 11:21 AM Paweł Anikiel <> wrote:
> On Tue, Oct 5, 2021 at 6:28 PM Alexandre Belloni <> 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.


  parent reply	other threads:[~2021-10-06  9:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-05 14:37 [PATCH v2 0/4] Add support for the Mercury+ AA1 module Paweł Anikiel
2021-10-05 14:37 ` [PATCH v2 1/4] i2c: check bus number property in DesignWare I2C Controller Paweł Anikiel
2021-10-05 16:19   ` Andy Shevchenko
2021-10-05 14:37 ` [PATCH v2 2/4] dt-bindings: add bus number property Paweł Anikiel
2021-10-05 16:22   ` Arnd Bergmann
2021-10-05 16:28     ` Alexandre Belloni
2021-10-06  9:29       ` Paweł Anikiel
     [not found]       ` <>
2021-10-06  9:41         ` Arnd Bergmann [this message]
2021-10-05 14:37 ` [PATCH v2 3/4] reset: socfpga: add empty driver allowing consumers to probe Paweł Anikiel
2021-10-05 14:37 ` [PATCH v2 4/4] dts: socfpga: Add Mercury+ AA1 devicetree Paweł Anikiel
     [not found] ` <20211005143746.xE5rCkt-P_XlNkn9bJ8ZqYPY4nQQ7doqzSd4FrAlICY@z>
2021-10-14 16:46   ` [PATCH v2 2/4] dt-bindings: add bus number property Rob Herring

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v2 2/4] dt-bindings: add bus number property' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).