linux-kernel - Re: [PATCH v3 3/3] irqchip: Add Qualcomm MPM controller 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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 07 Dec 2021 10:16:32 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Shawn Guo <shawn.guo@...aro.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Maulik Shah <quic_mkshah@...cinc.com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Loic Poulain <loic.poulain@...aro.org>,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/3] irqchip: Add Qualcomm MPM controller driver

On Tue, 07 Dec 2021 09:48:36 +0000,
Shawn Guo <shawn.guo@...aro.org> wrote:
> 
> On Mon, Dec 06, 2021 at 01:48:12PM +0000, Marc Zyngier wrote:
> > > > > +static int qcom_mpm_enter_sleep(struct qcom_mpm_priv *priv)
> > > > > +{
> > > > > +	int i, ret;
> > > > > +
> > > > > +	for (i = 0; i < priv->reg_stride; i++)
> > > > > +		qcom_mpm_write(priv, MPM_REG_STATUS, i, 0);
> > > > > +
> > > > > +	/* Notify RPM to write vMPM into HW */
> > > > 
> > > > What do you mean by 'into HW'? We just did that, right? or are these
> > > > registers just fake and most of the stuff is in the RPM?
> > > 
> > > I have a note about this in commit log.
> > > 
> > > - All the register settings are done by APSS on an internal memory
> > >   region called vMPM, and RPM will flush them into hardware after it
> > >   receives a mailbox/IPC notification from APSS.
> > > 
> > > So yes, these registers are fake/virtual in memory, and RPM will
> > > actually flush the values into the MPM hardware block.
> > 
> > Then why are you using MMIO accessors all over the place if this is
> > just RAM? Who *owns* this memory? Is it normal DRAM? Or some flops
> > exposed by a device? Why isn't the state simply communicated over the
> > mailbox instead?
> 
> It's a piece of internal memory (SRAM) which can be access by AP and
> RPM.  The communication mechanism is defined by SoC/RPM design, and we
> can do nothing but following the procedure.

Then the procedure needs to be documented:

- Who owns the memory at any given time?

- What are the events that trigger a change of ownership?

- What are the messages exchanged between these entities?

- What is the synchronisation mechanism between the various processing
  entities (MPM. RPM, APSS...)?

- Is the per-interrupt tracking a HW requirement or a SW
  implementation choice? Could this instead be a one-shot operation
  iterating over the whole state?

All this needs to be explained so that it is maintainable, because I'm
getting tired of drivers that mimic the QC downstream code without
justification nor documentation to support the implementation.

	M.

-- 
Without deviation from the norm, progress is not possible.