Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-531-gfdfa13a06d-fm-20230703.001-gfdfa13a0
Mime-Version: 1.0
Message-Id: <e06e8927-5c77-4df4-b595-dbcf647076ee@app.fastmail.com>
In-Reply-To: <3611feaa-9c89-b580-6266-c12cf048f56a@ti.com>
References: <20230515160234.289631-1-afd@ti.com>
 <20230515160234.289631-6-afd@ti.com> <ZGJeRiqylcysFPqu@shell.armlinux.org.uk>
 <3611feaa-9c89-b580-6266-c12cf048f56a@ti.com>
Date:   Fri, 14 Jul 2023 09:52:33 +0200
From:   "Arnd Bergmann" <arnd@arndb.de>
To:     "Andrew Davis" <afd@ti.com>, "Russell King" <linux@armlinux.org.uk>
Cc:     "Baruch Siach" <baruch@tkos.co.il>,
        "Vladimir Zapolskiy" <vz@mleia.com>,
        "Kunihiko Hayashi" <hayashi.kunihiko@socionext.com>,
        "Masami Hiramatsu" <mhiramat@kernel.org>,
        "Geert Uytterhoeven" <geert+renesas@glider.be>,
        "Linus Walleij" <linus.walleij@linaro.org>,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 06/10] ARM: mach-airoha: Rework support and directory structure
Content-Type: text/plain
Precedence: bulk

On Thu, Jul 13, 2023, at 20:44, Andrew Davis wrote:
> On 5/15/23 11:31 AM, Russell King (Oracle) wrote:
>> On Mon, May 15, 2023 at 11:02:30AM -0500, Andrew Davis wrote:
>>> Having a platform need a mach-* directory should be seen as a negative,
>>> it means the platform needs special non-standard handling. ARM64 support
>>> does not allow mach-* directories at all. While we may not get to that
>>> given all the non-standard architectures we support, we should still try
>>> to get as close as we can and reduce the number of mach directories.
>>>
>>> The mach-airoha/ directory, and files within, provide just one "feature":
>>> having the kernel print the machine name if the DTB does not also contain
>>> a "model" string (which they always do). To reduce the number of mach-*
>>> directories let's do without that feature and remove this directory.
>> 
>> I'm guessing this is copy-n-pasted description. However:
>>> -static const char * const airoha_board_dt_compat[] = {
>>> -	"airoha,en7523",
>>> -	NULL,
>>> -};
>>> -
>>> -DT_MACHINE_START(MEDIATEK_DT, "Airoha Cortex-A53 (Device Tree)")
>>> -	.dt_compat	= airoha_board_dt_compat,
>>> -MACHINE_END
>> 
>> If this is actually used, then it will have the effect of providing a
>> "machine" that has both l2c_aux_mask and l2c_aux_val as zero, whereas
>> the default one has l2c_aux_mask set to ~0.
>> 
>
> Given we set l2c_aux_mask to ~0 as a default for "Generic" DT system I
> had assumed this was safe, but no I cannot prove it for this board as
> I don't have one.
>
> I wonder if we should have some way to set this in DT, that would
> let us drop some more MACHINE defines that exist only to set
> the l2c_aux_val/mask..

Going from an empty machine description to the default one is
generally safe as long as there is no actual l2x0 cache controller
in the system that would incorrectly get enabled by this in case
it is intentionally left disabled. I'm not aware of any such case,
but it's possible.

For the Airoha chip, we know this is safe because ARMv8 and later
ARMv7 cores (A7, A15 and A17) never have this type of cache
controller.

So your patch is fine, just mention in the description that
the change in the cache controller handling is correct.

      Arnd