archive mirror
 help / color / mirror / Atom feed
From: AngeloGioacchino Del Regno <>
To: Bo-Chen Chen <>,,,,
Subject: Re: [PATCH v3] reset: mediatek: Move mediatek system clock reset to reset folder
Date: Thu, 29 Sep 2022 14:50:38 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Il 29/09/22 14:10, Bo-Chen Chen ha scritto:
> To manager mediatek system clock reset easier, we move the driver to
> drivers/reset.
> The modifications in this series:
> - Move clk/mediatek/reset.c to reset/reset-mediatek-sysclk.c
> - Move reset data which are scattered around the mediatek drivers to
>    reset-mediatek-sysclk.c
> - For mtk clk drivers which support device, we can ues
>    mtk_reset_controller_register() to register reset controller using
>    auxiliary bus.
> - For mtk clk drivers which do not support device (only support
>    device_node), we use mtk_reset_{init/remove}_with_node to register
>    reset controller.
> Signed-off-by: Bo-Chen Chen <>

I've just analyzed this idea a bit more, and there's the outcome.

This driver would be fine, if some MediaTek SoCs weren't shipped with
a bootloader that supports only very small kernels... because then, if
the reset controller is not available at boot time, it's unlikely that
you can probe the eMMC or the uSD, so it won't be possible to actually
compile this driver as a module and load it afterwards.

Please don't misunderstand me: I like the idea of having the MediaTek
SoC sysclk reset controller as a ... reset controller driver but, to
make that work, one fundamental issue must be solved...

If the kernel is configured for, let's say, MT2701 and MT2712, we're
always building in reset controller support for MT7622, 7629, 8135, 8173,
8183, 8186, 8192, 8195 - and this list will grow with MT8188, and others.

Obviously, it's useless to have support for, say, MT7622, if the MT7622
system clock controllers aren't built-in, nor modules.

So, to make this idea to work, we have to find a way to:
1. Build in support only for the required SoC(s)
2. Put the reset index mapping arrays in SoC-specific files, or this
    single file driver will see an exponential growth.

Wrapping it up - as the driver is right now - we're losing flexibility:
we need to maintain the current flexibility while keeping the improvements
that are made with this proposal.



> ---
> Changes for v3:
> 1. Add reset bit of PCIE and USB for MT8195.
> 2. Rebased oo linux-next-0928.
> Version for this series:
> v2 :
> v1 :
> RFC:

linux-arm-kernel mailing list

  reply	other threads:[~2022-09-29 12:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-29 12:10 [PATCH v3] reset: mediatek: Move mediatek system clock reset to reset folder Bo-Chen Chen
2022-09-29 12:50 ` AngeloGioacchino Del Regno [this message]
2022-09-30 18:59   ` Stephen Boyd
2022-10-03 11:28     ` AngeloGioacchino Del Regno

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).