All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Feist <james.feist@linux.intel.com>
To: Alex Qiu <xqiu@google.com>
Cc: Milton Miller II <miltonm@us.ibm.com>,
	Peter Lundgren <peterlundgren@google.com>,
	OpenBMC Maillist <openbmc@lists.ozlabs.org>,
	Kais Belgaied <belgaied@google.com>,
	Devjit Gopalpur <devjitg@google.com>
Subject: Re: Configuring device with I2C mux
Date: Wed, 8 Jan 2020 10:02:29 -0800	[thread overview]
Message-ID: <27eb67c0-c758-5b46-bb49-9eceec25bc4f@linux.intel.com> (raw)
In-Reply-To: <CAA_a9xKG_qk5sBUZY6T5xH+XG_HQwLXVf2Jy0GXX0Ob+6R1rig@mail.gmail.com>

On 1/8/20 9:54 AM, Alex Qiu wrote:
> Hi James,
> 
> Yes, we have multiple devices sitting behind the mux, and they're 
> onboard devices instead of standalone FRUs. The parent bus is described 
> as the FRU for each PCIe card.
> 
> After naming the mux channels, can these names be used somehow to config 
> I2C devices? For example, {"Bus": "$bus", "ChannelNames": 
> ["C0", "C1", "C2", "C3"]} for the mux, and {"Bus": "$bus.C1"} for 
> devices behind the mux on channel 1.

This syntax doesn't exist today.. On all our systems things behind the 
mux are again detectable, so we haven't hit this problem. Right now the 
template replacement is purely based on the found device on d-bus. So 
$bus is the bus property from the xyz.openbmc_project.FruDevice 
interface, there's no way to trace that to a mux channel, as it's just a 
d-bus property.

The code you're looking for is here: 
https://github.com/openbmc/entity-manager/blob/01542d2af1b1f45335cc8813fffcd3ed07f22989/src/Utils.cpp#L144 


Along with the channel identification logic here: 
https://github.com/openbmc/entity-manager/blob/01542d2af1b1f45335cc8813fffcd3ed07f22989/src/Overlay.cpp#L112

You could probably add some special syntax to make this work. Luckily 
this is the one part of entity-manager that is unit-tested, so that 
should help you 
https://github.com/openbmc/entity-manager/blob/master/test/test_entity-manager.cpp


-James

  reply	other threads:[~2020-01-08 18:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-08  1:13 Configuring device with I2C mux Alex Qiu
2020-01-08 14:43 ` Milton Miller II
2020-01-08 17:25   ` Alex Qiu
2020-01-08 17:46     ` James Feist
2020-01-08 17:54       ` Alex Qiu
2020-01-08 18:02         ` James Feist [this message]
2020-01-08 18:06           ` Alex Qiu
2020-01-10  1:46             ` Alex Qiu

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=27eb67c0-c758-5b46-bb49-9eceec25bc4f@linux.intel.com \
    --to=james.feist@linux.intel.com \
    --cc=belgaied@google.com \
    --cc=devjitg@google.com \
    --cc=miltonm@us.ibm.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=peterlundgren@google.com \
    --cc=xqiu@google.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.