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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CY1PR0301MB0748E49FD0D2232858A3774F87710@CY1PR0301MB0748.namprd03.prod.outlook.com>
Date:	Thu, 27 Nov 2014 01:15:38 +0000
From:	Stuart Yoder <stuart.yoder@...escale.com>
To:	Alexander Graf <agraf@...e.de>,
	Jose Rivera <German.Rivera@...escale.com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"arnd@...db.de" <arnd@...db.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC:	Kim Phillips <Kim.Phillips@...escale.com>,
	Scott Wood <scottwood@...escale.com>,
	"bhamciu1@...escale.com" <bhamciu1@...escale.com>,
	"R89243@...escale.com" <R89243@...escale.com>,
	Geoff Thorpe <Geoff.Thorpe@...escale.com>,
	"bhupesh.sharma@...escale.com" <bhupesh.sharma@...escale.com>,
	"nir.erez@...escale.com" <nir.erez@...escale.com>,
	Richard Schmitt <richard.schmitt@...escale.com>
Subject: RE: [PATCH 1/3 v4] drivers/bus: Added Freescale Management Complex
 APIs

> >>> +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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/