linux-kernel - RE: [PATCH V2] firmware: arm_scmi: Make scmi core independent of transport type

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] [day] [month] [year] [list]

Date:   Fri, 17 Jan 2020 02:26:43 +0000
From:   Peng Fan <peng.fan@....com>
To:     Sudeep Holla <sudeep.holla@....com>
CC:     Viresh Kumar <viresh.kumar@...aro.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "jassisinghbrar@...il.com" <jassisinghbrar@...il.com>,
        "cristian.marussi@....com" <cristian.marussi@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH V2] firmware: arm_scmi: Make scmi core independent of
 transport type

> Subject: Re: [PATCH V2] firmware: arm_scmi: Make scmi core independent of
> transport type
> 
> On Wed, Jan 15, 2020 at 08:53:51AM +0000, Peng Fan wrote:
> >
> > > Subject: [PATCH V2] firmware: arm_scmi: Make scmi core independent
> > > of transport type
> > >
> > > The SCMI specification is fairly independent of the transport
> > > protocol, which can be a simple mailbox (already implemented) or
> anything else.
> > > The current Linux implementation however is very much dependent of
> > > the mailbox transport layer.
> > >
> > > This patch makes the SCMI core code (driver.c) independent of the
> > > mailbox transport layer and moves all mailbox related code to a new
> > > file: mailbox.c.
> > >
> > > We can now implement more transport protocols to transport SCMI
> > > messages, some of the transport protocols getting discussed
> > > currently are SMC/HVC, SPCI (built on top of SMC/HVC), OPTEE based
> > > mailbox (similar to SPCI), and vitio based transport as alternative to
> mailbox.
> > >
> > > The transport protocols just need to provide struct scmi_desc, which
> > > also implements the struct scmi_transport_ops.
> >
> > I need put shmem for each protocol, is this expected?
> 
> No, it's optional. If some/all protocols need dedicated channel for whatever
> reasons(like DVFS/Perf for polling based transfers), they can specify.
> Absence of dedicated channel infers all protocols share the channel(s).
> 
> > Sudeep,
> > I am able to use smc to directly transport data, with adding a new
> > file, just named smc.c including a scmi_smc_desc,
> 
> Good.
> 
> > But I not find a good way to pass smc id to smc transport file.
> >
> 
> IMO, we have to deal this in transport specific init. I am thinking of
> chan_setup in context of this patch. Does that make sense ?

Yes, will you implement that?

> 
> [...]
> 
> > +
> > +    scmi_clk: protocol@14 {
> > +            reg = <0x14>;
> > +            shmem = <&cpu_scp_lpri>;
> > +            #clock-cells = <1>;
> > +            clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>,
> <&clk_ext2>,
> > +                     <&clk_ext3>, <&clk_ext4>;
> > +            clock-names = "osc_32k", "osc_24m", "clk_ext1",
> "clk_ext2",
> > +                          "clk_ext3", "clk_ext4";
> 
> This caught my attention, why do we need these clocks phandle list and clock
> names above ? Ideally just need scmi_clk phandle and the index to refer and
> names need to be provided by the firmware.

No need, I forgot the remove them.

Thanks
Peng.

> 
> --
> Regards,
> Sudeep