linux-kernel - Re: [RFC 06/13] soc: mediatek: apu: Add apu core 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]

Message-ID: <88a4e8f1-6ab7-cb2d-c88b-758b92b1811e@collabora.com>
Date:   Tue, 26 Oct 2021 17:17:40 +0200
From:   AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>
To:     Flora Fu <flora.fu@...iatek.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Sumit Semwal <sumit.semwal@...aro.org>
Cc:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, linux-media@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org,
        Yong Wu <yong.wu@...iatek.com>,
        Pi-Cheng Chen <pi-cheng.chen@...iatek.com>
Subject: Re: [RFC 06/13] soc: mediatek: apu: Add apu core driver

Il 23/10/21 13:14, Flora Fu ha scritto:
> Add apu core driver.
> The core driver will init the reset part of apu functions.
> 
> Signed-off-by: Flora Fu <flora.fu@...iatek.com>
> ---
>   drivers/soc/mediatek/Kconfig           | 18 +++++
>   drivers/soc/mediatek/apusys/Makefile   |  3 +
>   drivers/soc/mediatek/apusys/apu-core.c | 91 ++++++++++++++++++++++++++
>   drivers/soc/mediatek/apusys/apu-core.h | 11 ++++
>   4 files changed, 123 insertions(+)
>   create mode 100644 drivers/soc/mediatek/apusys/apu-core.c
>   create mode 100644 drivers/soc/mediatek/apusys/apu-core.h
> 

Hello Flora,

I don't think that this custom probe/init mechanism through apu-core.c
can ever be a thing: you should simply register a number of platform
drivers (likely modules) and let the kernel decide what to probe
first, what to probe last, as it's done for every kernel driver.

I understand that this may reduce probe deferrals, as it's a controlled
probe sequence, made specifically for apusys, but it's anyway something
that won't give you big gains (and if it was, then you should still let
the kernel decide and eventually optimize that mechanism somehow).

I want to note that, since this series is rather huge, I will probably
do more than one incremental review of it... and for how things look,
this will most probably be split to more than one series, to allow getting
reviews from specific subsystem maintainers, leading to better code quality
and robustness in the end.

Some more details are coming in reply of other patches in this series.

Thanks,
- Angelo