Messages in this thread | | | From | Stuart Yoder <> | Subject | RE: [PATCH 1/3 v4] drivers/bus: Added Freescale Management Complex APIs | Date | Thu, 27 Nov 2014 01:15:38 +0000 |
| |
> >>> +int dprc_get_container_id(struct fsl_mc_io *mc_io, int *container_id) > >> > >> This one is definitely a misnomer. It's a command that operates on the > >> MC object, not a DPRC object. Also it doesn't fetch a random > >> "container_id", it fetches the root container id. > > > > It's not strictly the root container. It fetches the container/DPRC ID > > associated with the portal you are using. A virtual machine would use > > it to fetch it's container ID. > > So does every portal properly react to this call?
Yes, they should.
> Or do only container > portals react to it?
Every portal is associated with some contianer-- either built into the container/DPRC object, or in a container/DPRC.
> In fact, what does make the initial portal special?
Nothing...it has the same semantics as any other portal.
> Who reacts to > DPMNG_CMDID_foo calls? Every DPRC or only the initial root?
All portals. It just means 'what container am I in?'
> >> Please move it and its definition to the files that operate on the MC > >> management interface. > > > > Note, the binary interface opcode really is DPRC_CMDID_GET_CONT_ID. > > > > We can request that the binary interface naming be changed, but wouldn't > > it be better to keep the functions separated by opcode type-- having > > DPRC_CMDID* opcode-based commands be in one file and DPMNG_CMDID* commands > > in a separate file? > > It really depends on what the semantics are. If this is a call that's > only valid on the MC root, then it should belong there. If it's > available on every container portal, it should be part of dprc of course.
It is valid on any portal, including container portals. For that reason, I do think it may make sense for it to be a DPMNG* command. But, I would say leave the files implementing the opcode groupings alone until the MC architecture is changed.
Stuart
| |