From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Konstantin Aladyshev <aladyshev22@gmail.com>
Cc: linux-acpi@vger.kernel.org, linux-i2c@vger.kernel.org
Subject: Re: Assigning fixed numbers to i2c buses via ACPI code
Date: Wed, 12 Feb 2025 14:06:47 +0200 [thread overview]
Message-ID: <Z6yO1wJ12FuiEVdf@smile.fi.intel.com> (raw)
In-Reply-To: <CACSj6VWkDnQj2=tOPMsbTo0uerNSR6sGSMO9c1FxWbEfYFz7Lg@mail.gmail.com>
On Wed, Feb 12, 2025 at 03:06:37PM +0300, Konstantin Aladyshev wrote:
> I'm running OpenBmc project on the x86 host. One of the applications
> from the OpenBmc ecosystem tries to find IPMI FRU devices on all
> available I2C buses. For that it would perform some transactions for
> every possible I2C device on every I2C bus to understand if it is an
> EEPROM or not.
> If the user doesn't want to scan some buses it can provide
> blocklist.json with addresses of the buses which shouldn't be scanned
> for FRU. But this blocklist operates with absolute addresses, which is
> why I want to be sure that my I2C buses would have fixed numbers on
> all systems.
The problem is how that blacklist is being organized. Nobody has to rely on
the bus numbers that are assigned during runtime by Linux kernel.
> Also it can be the case when the user wants to make sure that buses
> behind different I2C muxes are numbered in a particular way.
Why?
> Shortly speaking, existing OpenBmc software relies on this alias
> functionality in a couple of different scenarios.
Bad design. Even in OF world aliases are admitted to be a hack rather than
a solution.
> There are many examples of its usage in the BMC DTS code for different
> machines. Therefore I wonder if it is possible to do the same with x86 via
> ACPI tables to support existing OpenBmc applications.
I believe this is not an ACPI issue, this is issue of how that blacklist and
other things were designed and implemented. The correct way is to analyse sysfs
based on the registered host controllers, if one wants a platform-specific black
list, it should contain the HW addresses (bus, address, etc.) to identify
the controller and never the number that is assigned by the OS.
This is the very similar trap people got with eth0, eth1, ... in the past.
> On Wed, Feb 12, 2025 at 2:08 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Wed, Feb 12, 2025 at 11:18:44AM +0300, Konstantin Aladyshev wrote:
> > > Hello!
> > >
> > > Is it possible to assign fixed numbers to i2c buses via ACPI code?
> > >
> > > In DTS code it is done via aliases
> > > (https://docs.kernel.org/i2c/i2c-sysfs.html#caveat).
> > >
> > > For example:
> > > ```
> > > aliases {
> > > i2c20 = &imux20;
> > > }
> > >
> > > &i2c1 {
> > > status = "okay";
> > >
> > > i2c-mux@77 {
> > > ...
> > > imux20: i2c@0 {
> > > ...
> > > }
> > > ...
> > > }
> > > }
> > > ```
> > >
> > > Is it possible to do something like that in ACPI code?
> >
> > Why? What the problem do you actually have?
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2025-02-12 12:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-12 8:18 Assigning fixed numbers to i2c buses via ACPI code Konstantin Aladyshev
2025-02-12 11:08 ` Andy Shevchenko
2025-02-12 12:06 ` Konstantin Aladyshev
2025-02-12 12:06 ` Andy Shevchenko [this message]
2025-02-12 12:37 ` Konstantin Aladyshev
2025-02-12 13:31 ` Andy Shevchenko
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z6yO1wJ12FuiEVdf@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=aladyshev22@gmail.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox