<div dir="ltr"><div>Hi Patrick,</div><div><br></div><div>Thanks for the response. Sure. I will open an issue in TOF for requesting a new repository.</div><div><br></div><div>Thanks,</div><div>Kumar.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 15, 2022 at 12:22 AM Patrick Williams <<a href="mailto:patrick@stwcx.xyz">patrick@stwcx.xyz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Jan 05, 2022 at 07:53:18PM +0530, Kumar Thangavel wrote:<br>
> On Wed, Jan 5, 2022 at 1:20 AM Ed Tanous <<a href="mailto:ed@tanous.net" target="_blank">ed@tanous.net</a>> wrote:<br>
> <br>
> > On Mon, Jan 3, 2022 at 11:55 PM Kumar Thangavel<br>
> > <<a href="mailto:kumarthangavel.hcl@gmail.com" target="_blank">kumarthangavel.hcl@gmail.com</a>> wrote:<br>
<<clipped>><br>
<br>
We are initially supporting the non-open BIC implementation that we had on<br>
Yosemite v1,2, and 3, but we have recently started a fully open source<br>
implementation of the BIC side of this:<br>
<br>
    <a href="https://github.com/facebook/OpenBIC" rel="noreferrer" target="_blank">https://github.com/facebook/OpenBIC</a><br>
<br>
We'd certainly be interested in collaborating if anyone else is interested in<br>
designing a system using a uC like this.  Basically the BIC acts as an IO<br>
expander for the BMC so that we can manage multiple hosts and/or accelerator<br>
cards.<br>
<br>
At a high-level this is similar to the PLDM subsystem.  We have some IPMB events<br>
that the BIC push to the BMC and we already have those handled in the IPMI<br>
handlers, but there are other parts of the design where the BMC initiates<br>
activity.<br>
<br>
We could certainly spread the implementation out into various repositories,<br>
like dbus-sensors and phosphor-bmc-code-mgmt, but I suspect there are going to<br>
be challenges in a bug-free implementation in that regard.  There are cases<br>
where asking the BIC to do one activity, such as update itself, takes offline<br>
some other pieces of functionality, like sensors, and so there does need to be<br>
some state-awareness.  It seems less error prone to put all the various DBus<br>
objects related to the BIC into one daemon/repository in the same manner as<br>
PLDM is doing.<br>
<br>
<br>
Kumar, in order to get closure on this, I think you should open an issue to<br>
technical-oversight-forum requesting a repository.  Repository oversight is<br>
one of the primary functions of the TOF.<br>
<br>
-- <br>
Patrick Williams<br>
</blockquote></div></div>