linux-kernel - Re: [PATCH RESEND,v6 2/8] dt-bindings: mailbox: Add property for CMDQ secure driver

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]

Date: Tue, 28 May 2024 15:59:56 +0100
From: Conor Dooley <conor@...nel.org>
To: Jason-JH Lin (林睿祥) <Jason-JH.Lin@...iatek.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"robh+dt@...nel.org" <robh+dt@...nel.org>,
	Singo Chang (張興國) <Singo.Chang@...iatek.com>,
	"linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>,
	Jason-ch Chen (陳建豪) <Jason-ch.Chen@...iatek.com>,
	"chunkuang.hu@...nel.org" <chunkuang.hu@...nel.org>,
	Shawn Sung (宋孝謙) <Shawn.Sung@...iatek.com>,
	Nancy Lin (林欣螢) <Nancy.Lin@...iatek.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"conor+dt@...nel.org" <conor+dt@...nel.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Project_Global_Chrome_Upstream_Group <Project_Global_Chrome_Upstream_Group@...iatek.com>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"krzysztof.kozlowski+dt@...aro.org" <krzysztof.kozlowski+dt@...aro.org>,
	"matthias.bgg@...il.com" <matthias.bgg@...il.com>,
	"jassisinghbrar@...il.com" <jassisinghbrar@...il.com>,
	"angelogioacchino.delregno@...labora.com" <angelogioacchino.delregno@...labora.com>
Subject: Re: [PATCH RESEND,v6 2/8] dt-bindings: mailbox: Add property for
 CMDQ secure driver

On Tue, May 28, 2024 at 02:38:46PM +0000, Jason-JH Lin (林睿祥) wrote:
> Hi Conor,
> 
> On Mon, 2024-05-27 at 18:36 +0100, Conor Dooley wrote:
> > On Sun, May 26, 2024 at 10:44:37PM +0800, Jason-JH.Lin wrote:
> > > 1. Add mboxes property to define a GCE loopping thread as a secure
> > > IRQ
> > > handler.
> > > The CMDQ secure driver requests a mbox channel and sends a looping
> > > command to the GCE thread. The looping command will wait for a
> > > secure
> > > packet done event signal from secure world and then jump back to
> > > the
> > > first instuction. Each time it waits for an event, it notifies the
> > > CMDQ driver to perform the same action as the IRQ handler.
> > > 
> > > 2. Add gce-events property from gce-props.yaml to define a
> > > secure packet done signal in secure world.
> > > There are 1024 events IDs for GCE to use to execute instructions in
> > > the specific event happened. These events could be signaled by HW
> > > or SW
> > > and their value would be different in different SoC because of HW
> > > event
> > > IDs distribution range from 0 to 1023.
> > > If we set a static event ID: 855 for mt8188, it might be conflict
> > > the
> > > event ID original set in mt8195.
> > 
> > Two different SoCs, two different compatibles, no problem.
> > I'm almost certain you previously told me that the firmware changing
> > could result in a different event ID, but I see no mention of that
> > here.
> 
> Yes, it could be, but we don't use it that way.
> 
> > The commit messages makes it seem like this can be determined by the
> > compatible, so either give me a commit message that explains why the
> > compatible is not sufficient or drop the patch.
> > 
> 
> Yes, this can be determined by compatible in CMDQ mailbox driver,
> so I think it's possible to put this in the CMDQ mailbox driver data
> and configure by different SoC.
> 
> The problem is these events are defined in include/dt-
> bindings/mailbox/mediatek,mt8188-gce.h and include/dt-
> bindings/gce/mt8195-gce.h.
> I can only use them in their mt8188.dts or mt8195.dts.
> 
> If I want to use the same event define in 2 different headers in the
> same CMDQ mailbox driver, I think I just can parse their dts to get the
> corresponding one.
> Do you know how to generally deal with this problem?
> Or I can just use the number of event ID in driver data without the
> event define in dt-bindings header.

I don't think I really understand the problem. You get the
channelid/event data from the match data, right? Is the problem that
both files define the same "word" to mean different numbers? In that
case, just define the numbers locally in the driver, you don't need to
include a binding header when there's no data sharing between dts and
kernel.

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)