From: Conor Dooley <conor.dooley@microchip.com>
To: Pierre Gondois <pierre.gondois@arm.com>
Cc: <linux-kernel@vger.kernel.org>, Dan Carpenter <error27@gmail.com>,
kernel test robot <lkp@intel.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Sudeep Holla <sudeep.holla@arm.com>,
Palmer Dabbelt <palmer@rivosinc.com>,
Gavin Shan <gshan@redhat.com>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH -next] cacheinfo: Correctly handle new acpi_get_cache_info() prototype
Date: Tue, 24 Jan 2023 13:31:06 +0000 [thread overview]
Message-ID: <Y8/dmlR7p5rIbRLF@wendy> (raw)
In-Reply-To: <20230124123450.321852-1-pierre.gondois@arm.com>
[-- Attachment #1.1: Type: text/plain, Size: 1704 bytes --]
Hey!
On Tue, Jan 24, 2023 at 01:34:46PM +0100, Pierre Gondois wrote:
> commit bd500361a937 ("ACPI: PPTT: Update acpi_find_last_cache_level()
> to acpi_get_cache_info()")
> updates the function acpi_get_cache_info().
>
> If CONFIG_ACPI_PPTT is not defined, acpi_get_cache_info() doesn't
> update its *levels and *split_levels parameters and returns 0.
> This can lead to a faulty behaviour.
>
> Make acpi_get_cache_info() return an error code if CONFIG_ACPI_PPTT
> is not defined. Initialize levels and split_levels before passing
> their address to acpi_get_cache_info().
>
> Also, in init_cache_level():
Hmm...
> - commit e75d18cecbb3 ("arm64: cacheinfo: Fix incorrect
> assignment of signed error value to unsigned fw_level")
> checks the fw_level value in init_cache_level() in case
> the value is negative. Remove this check as the error code
> is not returned through fw_level anymore.
> - if no PPTT is present or CONFIG_ACPI_PPTT is not defined,
> it is still possible to use the cache information from clidr_el1.
> Instead of aborting if acpi_get_cache_info() returns an error
> code, just continue.
To be honest, these feel like entirely separate things that should be
in different patches. You've got:
- Dan's smatch fixes
- a redundant check being removed
- a behaviour change for if acpi_get_cache_info() returns an error
> Reported-by: Dan Carpenter <error27@gmail.com>
> Reported-by: kernel test robot <lkp@intel.com>
How about Link: to the LKP/Dan's report?
Link: https://lore.kernel.org/all/Y86iruJPuwNN7rZw@kili/
I did a quick check but didn't don't see the LKP report...
Also a Fixes: tag too, no?
Thanks,
Conor.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor.dooley@microchip.com>
To: Pierre Gondois <pierre.gondois@arm.com>
Cc: <linux-kernel@vger.kernel.org>, Dan Carpenter <error27@gmail.com>,
kernel test robot <lkp@intel.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Sudeep Holla <sudeep.holla@arm.com>,
Palmer Dabbelt <palmer@rivosinc.com>,
Gavin Shan <gshan@redhat.com>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH -next] cacheinfo: Correctly handle new acpi_get_cache_info() prototype
Date: Tue, 24 Jan 2023 13:31:06 +0000 [thread overview]
Message-ID: <Y8/dmlR7p5rIbRLF@wendy> (raw)
In-Reply-To: <20230124123450.321852-1-pierre.gondois@arm.com>
[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]
Hey!
On Tue, Jan 24, 2023 at 01:34:46PM +0100, Pierre Gondois wrote:
> commit bd500361a937 ("ACPI: PPTT: Update acpi_find_last_cache_level()
> to acpi_get_cache_info()")
> updates the function acpi_get_cache_info().
>
> If CONFIG_ACPI_PPTT is not defined, acpi_get_cache_info() doesn't
> update its *levels and *split_levels parameters and returns 0.
> This can lead to a faulty behaviour.
>
> Make acpi_get_cache_info() return an error code if CONFIG_ACPI_PPTT
> is not defined. Initialize levels and split_levels before passing
> their address to acpi_get_cache_info().
>
> Also, in init_cache_level():
Hmm...
> - commit e75d18cecbb3 ("arm64: cacheinfo: Fix incorrect
> assignment of signed error value to unsigned fw_level")
> checks the fw_level value in init_cache_level() in case
> the value is negative. Remove this check as the error code
> is not returned through fw_level anymore.
> - if no PPTT is present or CONFIG_ACPI_PPTT is not defined,
> it is still possible to use the cache information from clidr_el1.
> Instead of aborting if acpi_get_cache_info() returns an error
> code, just continue.
To be honest, these feel like entirely separate things that should be
in different patches. You've got:
- Dan's smatch fixes
- a redundant check being removed
- a behaviour change for if acpi_get_cache_info() returns an error
> Reported-by: Dan Carpenter <error27@gmail.com>
> Reported-by: kernel test robot <lkp@intel.com>
How about Link: to the LKP/Dan's report?
Link: https://lore.kernel.org/all/Y86iruJPuwNN7rZw@kili/
I did a quick check but didn't don't see the LKP report...
Also a Fixes: tag too, no?
Thanks,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2023-01-24 13:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-24 12:34 [PATCH -next] cacheinfo: Correctly handle new acpi_get_cache_info() prototype Pierre Gondois
2023-01-24 12:34 ` Pierre Gondois
2023-01-24 13:31 ` Conor Dooley [this message]
2023-01-24 13:31 ` Conor Dooley
2023-01-24 13:50 ` Sudeep Holla
2023-01-24 13:50 ` Sudeep Holla
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=Y8/dmlR7p5rIbRLF@wendy \
--to=conor.dooley@microchip.com \
--cc=catalin.marinas@arm.com \
--cc=error27@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=gshan@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=palmer@rivosinc.com \
--cc=pierre.gondois@arm.com \
--cc=rafael@kernel.org \
--cc=sudeep.holla@arm.com \
--cc=will@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.