RE: [PATCH 1/3 v4] drivers/bus: Added Freescale Management Complex APIs

[Stuart Yoder]

> >>> +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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/