linux-kernel - Re: [PATCH 2/2] [media] exynos-gsc: Fix imprecise external abort due disabled power domain

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:   Fri, 20 Jan 2017 07:01:46 -0300
From:   Javier Martinez Canillas <javier@....samsung.com>
To:     Marek Szyprowski <m.szyprowski@...sung.com>,
        linux-kernel@...r.kernel.org
Cc:     Inki Dae <inki.dae@...sung.com>,
        Andi Shyti <andi.shyti@...sung.com>,
        Shuah Khan <shuahkh@....samsung.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Kukjin Kim <kgene@...nel.org>,
        linux-samsung-soc@...r.kernel.org,
        Sylwester Nawrocki <s.nawrocki@...sung.com>,
        linux-media@...r.kernel.org, Krzysztof Kozlowski <krzk@...nel.org>,
        linux-arm-kernel@...ts.infradead.org,
        Ulf Hansson <ulf.hansson@...aro.org>
Subject: Re: [PATCH 2/2] [media] exynos-gsc: Fix imprecise external abort due
 disabled power domain

Hello Marek,

On 01/20/2017 05:08 AM, Marek Szyprowski wrote:
> Hi Javier,
> 

[snip]

>> Ok, I misunderstood the relationship between runtime PM and the power domains
>> then. I thought the power domains were only powered on when the runtime PM
>> framework resumed an associated device (i.e: pm_runtime_get_sync() is called).
> 
> Power domains are implemented transparently for the drivers. Even when driver
> doesn't support runtime pm, but its device is in the power domain, the core will
> ensure that the domain will be turned on all the time the driver is bound to the
> device.
>

I got it now, thank a lot for your explanation.
 
>> But even if this isn't the case, shouldn't the reset in probe only be needed
>> if CONFIG_PM isn't enabled? (IOW, $SUBJECT but with another commit message).
> 
> This looks like an over-engineering. I don't like polluting driver code with
> conditional statements like IS_ENABLED(CONFIG_*). It should not hurt to reset
> the device in driver probe, especially just in case the device was left in
> some partially configured/working state by bootloader or previous kernel run
> (if started from kexec). Adding this conditional code to avoid some issues
> with power domain or clocks configuration also suggests that one should
> instead solve the problem elsewhere. Driver should be able to access device
> registers in its probe() in any case without the additional hacks.
>

Fair enough, I already posted the patch but I'll ask it to be dropped.

[snip]

>>
>> This seems to be caused by some needed clocks to access the power domains
>> to be gated, since I don't get these erros when passing clk_ignore_unused
>> as parameter in the kernel command line.
> 
> I think that those issues were fixes by the following patch:
> https://patchwork.kernel.org/patch/9484607/
> It still didn't reach mainline, but I hope it will go as a fix to v4.10.
>

That won't be enough since the CLK_ACLK432_SCALER needs to be ungated for
Exynos5422/5800 as mentioned on another mail in this thread.

> Please test if this solves your issue. Please not that adding more clocks
> to the power domain drivers will solve only the problem with turning domain
> on/off, but the are more cases where those clocks should be turned on (like
> IOMMU integration), so marking them as critical solves that problem too.
>

Ok, I understand your point.
 
> Best regards

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America