All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: Shanker Donthineni <sdonthineni@nvidia.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
	Mark Rutland <mark.rutland@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, Vikram Sethi <vsethi@nvidia.com>,
	Thierry Reding <treding@nvidia.com>
Subject: Re: [PATCH v2] irqchip/gicv3: Workaround for NVIDIA erratum T241-FABRIC-4
Date: Thu, 16 Mar 2023 16:00:04 +0000	[thread overview]
Message-ID: <bf9f8763f0116c3f05c008923edfbedb@kernel.org> (raw)
In-Reply-To: <20230316151014.zaoxo4wmg4mzyoiq@bogus>

On 2023-03-16 15:10, Sudeep Holla wrote:
> On Wed, Mar 15, 2023 at 07:27:14AM -0500, Shanker Donthineni wrote:
>> Hi Marc,
>> 
>> On 3/15/23 03:34, Marc Zyngier wrote:
>> > Please don't duplicate existing code. There is already the required
>> > infrastructure in drivers/firmware/smccc/soc_id.c. All you need to do
>> > is:
>> >
>> > - disassociate the SMCCC probing from the device registration
>> >
>> > - probe the SOC_ID early
>> >
>> > - add accessors for the relevant data
>> >
>> > - select ARM_SMCCC_SOD_ID/ARM_SMCCC_DISCOVERY from the GICv3 Kconfig
>> 
>> 
>> I have not modified soc_id.c as it expects to be loaded as a module 
>> with
>> the use of module_init() and module_exit() functions. The exported 
>> symbols
>> in soc_id driver cannot be accessed from the built-in code.
>> 
>> Agree, the SOD-ID discovery code was duplicated.
>> 
>> Please guide me if the below approach is okay?
>> 
>> 1) Probe the SOC-ID in arm_smccc_version_init() and export two 
>> functions
>> arm_smccc_get_soc_id_version() and arm_smccc_get_soc_id_revision().
>> 
>> --- a/drivers/firmware/smccc/smccc.c
>> +++ b/drivers/firmware/smccc/smccc.c
>> @@ -17,9 +17,13 @@ static enum arm_smccc_conduit smccc_conduit = 
>> SMCCC_CONDUIT_NONE;
>> 
>>  bool __ro_after_init smccc_trng_available = false;
>>  u64 __ro_after_init smccc_has_sve_hint = false;
>> +s32 __ro_after_init smccc_soc_id_version = SMCCC_RET_NOT_SUPPORTED;
>> +s32 __ro_after_init smccc_soc_id_revision = SMCCC_RET_NOT_SUPPORTED;
>> 
>>  void __init arm_smccc_version_init(u32 version, enum 
>> arm_smccc_conduit conduit)
>>  {
>> +       struct arm_smccc_res res;
>> +
>>         smccc_version = version;
>>         smccc_conduit = conduit;
>> 
>> @@ -27,6 +31,18 @@ void __init arm_smccc_version_init(u32 version, 
>> enum arm_smccc_conduit conduit)
>>         if (IS_ENABLED(CONFIG_ARM64_SVE) &&
>>             smccc_version >= ARM_SMCCC_VERSION_1_3)
>>                 smccc_has_sve_hint = true;
>> +
>> +       if ((smccc_version >= ARM_SMCCC_VERSION_1_2) &&
>> +           (smccc_conduit != SMCCC_CONDUIT_NONE)) {
>> +               arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
>> +                                    ARM_SMCCC_ARCH_SOC_ID, &res);
>> +               if ((s32)res.a0 >= 0) {
>> +                       arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_SOC_ID, 0, 
>> &res);
>> +                       smccc_soc_id_version = (s32)res.a0;
>> +                       arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_SOC_ID, 1, 
>> &res);
>> +                       smccc_soc_id_revision = (s32)res.a0;
>> +               }
>> +       }
>>  }
>> 
>> 
>> +s32 arm_smccc_get_soc_id_version(void)
>> +{
>> +       return smccc_soc_id_version;
>> +}
>> +EXPORT_SYMBOL_GPL(arm_smccc_get_soc_id_version);
>> +
>> +s32 arm_smccc_get_soc_id_revision(void)
>> +{
>> +       return smccc_soc_id_revision;
>> +}
>> +EXPORT_SYMBOL_GPL(arm_smccc_get_soc_id_revision);
>> 
>> 
> 
> Overall, it looks OK to me. However I see neither the gic nor the 
> soc_id
> can be build as module atm. So do we really need the export symbols if 
> no
> other modules are using it ?

It really shouldn't be exported. Having accessors should be enough.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: Shanker Donthineni <sdonthineni@nvidia.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
	Mark Rutland <mark.rutland@arm.com>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, Vikram Sethi <vsethi@nvidia.com>,
	Thierry Reding <treding@nvidia.com>
Subject: Re: [PATCH v2] irqchip/gicv3: Workaround for NVIDIA erratum T241-FABRIC-4
Date: Thu, 16 Mar 2023 16:00:04 +0000	[thread overview]
Message-ID: <bf9f8763f0116c3f05c008923edfbedb@kernel.org> (raw)
In-Reply-To: <20230316151014.zaoxo4wmg4mzyoiq@bogus>

On 2023-03-16 15:10, Sudeep Holla wrote:
> On Wed, Mar 15, 2023 at 07:27:14AM -0500, Shanker Donthineni wrote:
>> Hi Marc,
>> 
>> On 3/15/23 03:34, Marc Zyngier wrote:
>> > Please don't duplicate existing code. There is already the required
>> > infrastructure in drivers/firmware/smccc/soc_id.c. All you need to do
>> > is:
>> >
>> > - disassociate the SMCCC probing from the device registration
>> >
>> > - probe the SOC_ID early
>> >
>> > - add accessors for the relevant data
>> >
>> > - select ARM_SMCCC_SOD_ID/ARM_SMCCC_DISCOVERY from the GICv3 Kconfig
>> 
>> 
>> I have not modified soc_id.c as it expects to be loaded as a module 
>> with
>> the use of module_init() and module_exit() functions. The exported 
>> symbols
>> in soc_id driver cannot be accessed from the built-in code.
>> 
>> Agree, the SOD-ID discovery code was duplicated.
>> 
>> Please guide me if the below approach is okay?
>> 
>> 1) Probe the SOC-ID in arm_smccc_version_init() and export two 
>> functions
>> arm_smccc_get_soc_id_version() and arm_smccc_get_soc_id_revision().
>> 
>> --- a/drivers/firmware/smccc/smccc.c
>> +++ b/drivers/firmware/smccc/smccc.c
>> @@ -17,9 +17,13 @@ static enum arm_smccc_conduit smccc_conduit = 
>> SMCCC_CONDUIT_NONE;
>> 
>>  bool __ro_after_init smccc_trng_available = false;
>>  u64 __ro_after_init smccc_has_sve_hint = false;
>> +s32 __ro_after_init smccc_soc_id_version = SMCCC_RET_NOT_SUPPORTED;
>> +s32 __ro_after_init smccc_soc_id_revision = SMCCC_RET_NOT_SUPPORTED;
>> 
>>  void __init arm_smccc_version_init(u32 version, enum 
>> arm_smccc_conduit conduit)
>>  {
>> +       struct arm_smccc_res res;
>> +
>>         smccc_version = version;
>>         smccc_conduit = conduit;
>> 
>> @@ -27,6 +31,18 @@ void __init arm_smccc_version_init(u32 version, 
>> enum arm_smccc_conduit conduit)
>>         if (IS_ENABLED(CONFIG_ARM64_SVE) &&
>>             smccc_version >= ARM_SMCCC_VERSION_1_3)
>>                 smccc_has_sve_hint = true;
>> +
>> +       if ((smccc_version >= ARM_SMCCC_VERSION_1_2) &&
>> +           (smccc_conduit != SMCCC_CONDUIT_NONE)) {
>> +               arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
>> +                                    ARM_SMCCC_ARCH_SOC_ID, &res);
>> +               if ((s32)res.a0 >= 0) {
>> +                       arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_SOC_ID, 0, 
>> &res);
>> +                       smccc_soc_id_version = (s32)res.a0;
>> +                       arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_SOC_ID, 1, 
>> &res);
>> +                       smccc_soc_id_revision = (s32)res.a0;
>> +               }
>> +       }
>>  }
>> 
>> 
>> +s32 arm_smccc_get_soc_id_version(void)
>> +{
>> +       return smccc_soc_id_version;
>> +}
>> +EXPORT_SYMBOL_GPL(arm_smccc_get_soc_id_version);
>> +
>> +s32 arm_smccc_get_soc_id_revision(void)
>> +{
>> +       return smccc_soc_id_revision;
>> +}
>> +EXPORT_SYMBOL_GPL(arm_smccc_get_soc_id_revision);
>> 
>> 
> 
> Overall, it looks OK to me. However I see neither the gic nor the 
> soc_id
> can be build as module atm. So do we really need the export symbols if 
> no
> other modules are using it ?

It really shouldn't be exported. Having accessors should be enough.

Thanks,

         M.
-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-03-16 16:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-14 13:51 [PATCH v2] irqchip/gicv3: Workaround for NVIDIA erratum T241-FABRIC-4 Shanker Donthineni
2023-03-14 13:51 ` Shanker Donthineni
2023-03-15  8:34 ` Marc Zyngier
2023-03-15 12:27   ` Shanker Donthineni
2023-03-15 12:27     ` Shanker Donthineni
2023-03-16 15:10     ` Sudeep Holla
2023-03-16 15:10       ` Sudeep Holla
2023-03-16 16:00       ` Marc Zyngier [this message]
2023-03-16 16:00         ` Marc Zyngier
2023-03-16 22:41         ` Shanker Donthineni
2023-03-16 22:41           ` Shanker Donthineni
2023-03-15 22:07 ` kernel test robot
2023-03-15 22:07   ` kernel test robot
2023-03-15 22:48 ` kernel test robot
2023-03-15 22:48   ` kernel test robot

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=bf9f8763f0116c3f05c008923edfbedb@kernel.org \
    --to=maz@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=sdonthineni@nvidia.com \
    --cc=sudeep.holla@arm.com \
    --cc=tglx@linutronix.de \
    --cc=treding@nvidia.com \
    --cc=vsethi@nvidia.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.