linux-kernel - Re: [PATCH v2 11/29] iommu/mediatek: Always pm_runtime

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:   Wed, 1 Sep 2021 12:10:39 +0000
From:   Yong Wu (吴勇) <Yong.Wu@...iatek.com>
To:     "hsinyi@...omium.org" <hsinyi@...omium.org>
CC:     "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "tfiga@...omium.org" <tfiga@...omium.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Youlin Pei (裴友林) 
        <youlin.pei@...iatek.com>,
        "drinkcat@...omium.org" <drinkcat@...omium.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "evgreen@...omium.org" <evgreen@...omium.org>,
        Anan Sun (孙安安) <Anan.Sun@...iatek.com>,
        "robin.murphy@....com" <robin.murphy@....com>,
        "joro@...tes.org" <joro@...tes.org>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        srv_heupstream <srv_heupstream@...iatek.com>,
        "tfiga@...gle.com" <tfiga@...gle.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        Chao Hao (郝超) <Chao.Hao@...iatek.com>,
        "krzysztof.kozlowski@...onical.com" 
        <krzysztof.kozlowski@...onical.com>,
        "will@...nel.org" <will@...nel.org>
Subject: Re: [PATCH v2 11/29] iommu/mediatek: Always pm_runtime_get while tlb
 flush

On Tue, 2021-08-24 at 15:10 +0800, Hsin-Yi Wang wrote:
> On Fri, Aug 13, 2021 at 2:57 PM Yong Wu <yong.wu@...iatek.com> wrote:
> > 
> > Prepare for 2 HWs that sharing pgtable in different power-domains.
> > 
> > The previous SoC don't have PM. Only mt8192 has power-domain,
> > and it is display's power-domain which nearly always is enabled.
> > 
> > When there are 2 M4U HWs, it may has problem.
> > In this function, we get the pm_status via the m4u dev, but it
> > don't
> > reflect the real power-domain status of the HW since there may be
> > other
> > HW also use that power-domain.
> > 
> > Currently we could not get the real power-domain status, thus
> > always
> > pm_runtime_get here.
> > 
> > Prepare for mt8195, thus, no need fix tags here.
> > 
> > This patch may drop the performance, we expect the user could
> > pm_runtime_get_sync before dma_alloc_attrs which need tlb ops.
> 
> Can you check if there are existing users that need to add this
> change?

The issue may exist in our most users. Our users mainly are in v4l2.
normally their flow like this:
a) VIDIOC_REQBUFS: call dma_alloc_attrs or dma_buf_map_attachment.
b) VIDIOC_STREAMON. 
c) VIDIOC_QBUF: device_run: pm_runtime_get_sync.

Requesting they call pm_runtime_get before dma_alloc_attrs looks not
reasonable. It seems that they should not care about this.

This patch mainly make sure the flow is right. Locally I have a TODO to
try get the real power-domain status here, the sample code like below:

static struct notifier_block mtk_penpd_notifier;

/* Register the genpd notifier. */
mtk_penpd_notifier.notifier_call = mtk_iommu_pd_callback;
ret = dev_pm_genpd_add_notifier(dev, &mtk_penpd_notifier);

/* Then get the real power domain status in the notifier */
 static int mtk_iommu_pd_callback(struct notifier_block *nb,
                        unsigned long flags, void *data) 
 {
       if (flags == GENPD_NOTIFY_ON)
           /* the real power domain is power on */
       else if (flags == GENPD_NOTIFY_PRE_OFF)
           /* the real power domain are going to power off. Take it as
power off.
            * Skip the tlb ops after receivice this flag.
            */
 }
 
 How about this? or any other suggestion to get the real power-domain
rather than the iommu device's power domain status.
 Thanks.

> 
> 
> > 
> > Signed-off-by: Yong Wu <yong.wu@...iatek.com>
> > ---
> 
> <snip>