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 PHC | |
Open Source and information security mailing list archives
| ||
|
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
Powered by blists - more mailing lists