Linux GPIO subsystem development
 help / color / mirror / Atom feed
From: Conor Dooley <conor@kernel.org>
To: Yangyu Chen <cyy@cyyself.name>
Cc: linux-riscv@lists.infradead.org,
	Damien Le Moal <dlemoal@kernel.org>,
	Dan Carpenter <dan.carpenter@linaro.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>, Guo Ren <guoren@kernel.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	linux-gpio@vger.kernel.org, linux-clk@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 0/5] riscv: Kconfig.socs: Deprecate SOC_CANAAN and use SOC_CANAAN_K210 for K210
Date: Thu, 28 Mar 2024 17:29:47 +0000	[thread overview]
Message-ID: <20240328-daytime-hankie-41a57ad9fbce@spud> (raw)
In-Reply-To: <tencent_2E60E33C1F88A090B6B3A332AE528C6B8806@qq.com>

[-- Attachment #1: Type: text/plain, Size: 4028 bytes --]

Yangyu,

And Linus/Stephen/Philipp I guess!

On Fri, Mar 29, 2024 at 01:03:22AM +0800, Yangyu Chen wrote:
> Since SOC_FOO should be deprecated from patch [1], and cleanup for other
> SoCs is already in the mailing list [2,3,4], so we deprecate the use of
> SOC_CANAAN and use ARCH_CANAAN for SoCs vendored by Canaan instead from now
> on.
> 
> However, the K210 SoC is so special for NoMMU and built for loader.bin, if
> we share the ARCH_CANAAN symbol directly for K210 and other new SoCs which
> has MMU and no need for loader, it will confuse some users who may try to
> boot MMU Kernel on K210, but it will fail. Thus, this patch set renamed the
> original use of SOC_CANAAN to SOC_CANAAN_K210 for K210 SoC, as Damien
> suggested from the list [5]. Then, it made some adaptations for soc, clk,
> pinctrl, and reset drivers.
> 
> Note: This patch set is used to prepare for Canaan K230 Support, which is
> on the mailing list [6]. The next revision for the K230 support patch will
> be based on this patch set.

Please, if you don't completely understand what I tell you to do, ask me
to clarify. Asking for more information on what to do is not a problem,
it saves effort for everyone if you ask rather than submit another
version. This patchset has the same sort of problem as was pointed
out on the v5 and v6 of the k230 support.
All patches in this series must go through the same tree, if they don't
then the relevant drivers will not compile in the subsystem trees. As
the new symbol will not be defined there. This is why I said that you
should solicit acks from the subsystem maintainers to take this all via
the soc tree - but you do have to explicitly ask for them! I suggested
doing it under the --- line in each patch, as often maintainers ignore
the parts of a series that do not involve them (I know I do this with
dt-bindings *all* the time).

The only way this works without taking everything via one tree is if we
introduce ARCH_CANAAN for 6.10-rc1, switch every driver subsystem over in
6.11-rc1 and then delete the Kconfig symbol after 6.11-rc1. Although I
also waited with my SOC_FOO symbol removals because I wanted the
ARCH_FOO symbols to propagate into .configs, I followed the process
above so that things could be taken into subsystem trees without
preventing building the drivers.

I'm perfectly happy to take the whole series via the soc tree, but I need
acks on the clk, pinctrl and reset patches before I can do that.

Thanks,
Conor.

> [1] https://lore.kernel.org/linux-riscv/20221121221414.109965-1-conor@kernel.org/
> [2] https://lore.kernel.org/linux-riscv/20240305-praying-clad-c4fbcaa7ed0a@spud/
> [3] https://lore.kernel.org/linux-riscv/20240305-fled-undrilled-41dc0c46bb29@spud/
> [4] https://lore.kernel.org/linux-riscv/20240305-stress-earflap-d7ddb8655a4d@spud/
> [5] https://lore.kernel.org/linux-riscv/2b0511af-1b5b-4c90-a673-c9113bb58142@kernel.org/
> [6] https://lore.kernel.org/linux-riscv/tencent_F76EB8D731C521C18D5D7C4F8229DAA58E08@qq.com/
> 
> Yangyu Chen (5):
>   riscv: Kconfig.socs: Split ARCH_CANAAN and SOC_CANAAN_K210
>   soc: canaan: Deprecate SOC_CANAAN and use SOC_CANAAN_K210 for K210
>   clk: k210: Deprecate SOC_CANAAN and use SOC_CANAAN_K210
>   pinctrl: k210: Deprecate SOC_CANAAN and use SOC_CANAAN_K210
>   reset: k210: Deprecate SOC_CANAAN and use SOC_CANAAN_K210
> 
>  arch/riscv/Kconfig.socs                        | 10 ++++++++--
>  arch/riscv/Makefile                            |  2 +-
>  arch/riscv/configs/nommu_k210_defconfig        |  3 ++-
>  arch/riscv/configs/nommu_k210_sdcard_defconfig |  3 ++-
>  drivers/clk/Kconfig                            |  4 ++--
>  drivers/pinctrl/Kconfig                        |  4 ++--
>  drivers/reset/Kconfig                          |  4 ++--
>  drivers/soc/Makefile                           |  2 +-
>  drivers/soc/canaan/Kconfig                     |  4 ++--
>  9 files changed, 22 insertions(+), 14 deletions(-)
> 
> -- 
> 2.43.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  parent reply	other threads:[~2024-03-28 17:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-28 17:03 [PATCH v1 0/5] riscv: Kconfig.socs: Deprecate SOC_CANAAN and use SOC_CANAAN_K210 for K210 Yangyu Chen
2024-03-28 17:06 ` [PATCH v1 1/5] riscv: Kconfig.socs: Split ARCH_CANAAN and SOC_CANAAN_K210 Yangyu Chen
2024-03-28 17:06 ` [PATCH v1 2/5] soc: canaan: Deprecate SOC_CANAAN and use SOC_CANAAN_K210 for K210 Yangyu Chen
2024-03-30  2:04   ` Guo Ren
2024-03-28 17:06 ` [PATCH v1 3/5] clk: k210: Deprecate SOC_CANAAN and use SOC_CANAAN_K210 Yangyu Chen
2024-03-28 21:11   ` Stephen Boyd
2024-03-28 17:06 ` [PATCH v1 4/5] pinctrl: " Yangyu Chen
2024-03-28 17:06 ` [PATCH v1 5/5] reset: " Yangyu Chen
2024-04-02  9:18   ` Philipp Zabel
2024-03-28 17:29 ` Conor Dooley [this message]
2024-03-28 17:31   ` [PATCH v1 0/5] riscv: Kconfig.socs: Deprecate SOC_CANAAN and use SOC_CANAAN_K210 for K210 Conor Dooley
2024-04-05 15:47 ` Conor Dooley

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20240328-daytime-hankie-41a57ad9fbce@spud \
    --to=conor@kernel.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=cyy@cyyself.name \
    --cc=dan.carpenter@linaro.org \
    --cc=dlemoal@kernel.org \
    --cc=guoren@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mturquette@baylibre.com \
    --cc=p.zabel@pengutronix.de \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=sboyd@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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