From: Sudeep Holla <sudeep.holla@arm.com> To: Arnd Bergmann <arnd@arndb.de> Cc: Will Deacon <will@kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Catalin Marinas <catalin.marinas@arm.com>, Mark Rutland <mark.rutland@arm.com>, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>, Steven Price <steven.price@arm.com>, harb@amperecomputing.com, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v4 0/7] firmware: smccc: Add basic SMCCC v1.2 + ARCH_SOC_ID support Date: Thu, 21 May 2020 10:15:15 +0100 [thread overview] Message-ID: <20200521091458.GA6425@bogus> (raw) In-Reply-To: <CAK8P3a3dV0B26XE3oFQGTFf8EWV0AHoLudNtpSSB_t+pCfkOkQ@mail.gmail.com> On Thu, May 21, 2020 at 11:06:23AM +0200, Arnd Bergmann wrote: > On Thu, May 21, 2020 at 10:11 AM Sudeep Holla <sudeep.holla@arm.com> wrote: > > On Thu, May 21, 2020 at 08:57:56AM +0100, Will Deacon wrote: > > > On Thu, May 21, 2020 at 09:34:10AM +0200, Arnd Bergmann wrote: > > > > On Thu, May 21, 2020 at 9:07 AM Sudeep Holla <sudeep.holla@arm.com> wrote: > > > > > On Wed, May 20, 2020 at 11:54:16PM +0200, Arnd Bergmann wrote: > > > > > > On Wed, May 20, 2020 at 11:29 PM Will Deacon <will@kernel.org> wrote: > > > > > > > Applied to arm64 (for-next/smccc), thanks! > > > > > > > > > > > > > > Arnd -- Sudeep's reply to you about the sysfs groups seemed reasonable to me, > > > > > > > but please shout if you'd rather I dropped this in order to pursue an > > > > > > > alternative approach. > > > > > > > > > > > > I missed the reply earlier, thanks for pointing me to it again. > > > > > > D'oh, I took your silence as "no objections". Oh well! > > > > > > > > > I'm not entirely convinced, but don't revert it for now because of that, > > > > > > I assume we can find a solution. > > > > > > Ok, cheers. It's on a separate branch so it's easy enough to drop if > > > necessary (i.e. no reverts needed). Sudeep -- please send any extra patches > > > on top of the branch. > > > > > > > Indeed, it is also last patch in the series. However if Arnd is happy > > with the sysfs names, we can move to generic code later without breaking > > anything. > > > > We need not revert or drop it now. I will leave that to you or Arnd to > > decide. Just that it may be too late to get acks for all the soc sysfs > > drivers in time for v5.8 > > > > I am fine if you want to drop the last patch. > > Ok, let's drop that patch then and make sure we do something that > everyone is happy with later on. I'm already in favor of adding > a more reliable soc_device instance based on this, but we need to > be sure we don't screw up the contents of the attributes when we > can't change them later. > Sure. Will, please drop the last patch in the series. I will rework moving the custom attributes to the core. > > > > >> drivers/firmware/smccc/smccc.c:14:13: warning: no previous prototype for function 'arm_smccc_version_init' [-Wmissing-prototypes] > > > > void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit) > > > > ^ > > > > drivers/firmware/smccc/smccc.c:14:1: note: declare 'static' if the > > > > function is not intended to be used outside of this translation unit > > > > void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit) > > > > > > I saw that when I applied the patches, but since the function is called from > > > another compilation unit (psci/psci.o), I just ignored it as we have loads > > > of these already and it only screams if you build with W=1. > > > > > > > /me confused. Do you need the fix for this warning or you are happy to ignore? > > I want a fix for that, as I hope we can eventually turn this warning on by > default and stop playing whack-a-mole when they come up. Most of these > warnings are harmless, but occasionally the prototypes don't match exactly > and cause real bugs depending on the configuration, and ensuring both > sides include a common header file is an easy way to make it work > more reliably. > Agreed. > Note that the warning should come up for either W=1 or C=1, and I also > think that new code should generally be written sparse-clean and have > no warnings with 'make C=1' as a rule. > Sure, I am facing issues with clang-8, it fails to build arm_smccc_1_1_invoke which I think Nick was mentioning in some other thread. I will try latest clang. -- Regards, Sudeep
WARNING: multiple messages have this Message-ID (diff)
From: Sudeep Holla <sudeep.holla@arm.com> To: Arnd Bergmann <arnd@arndb.de> Cc: Mark Rutland <mark.rutland@arm.com>, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>, Catalin Marinas <catalin.marinas@arm.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Steven Price <steven.price@arm.com>, harb@amperecomputing.com, Will Deacon <will@kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v4 0/7] firmware: smccc: Add basic SMCCC v1.2 + ARCH_SOC_ID support Date: Thu, 21 May 2020 10:15:15 +0100 [thread overview] Message-ID: <20200521091458.GA6425@bogus> (raw) In-Reply-To: <CAK8P3a3dV0B26XE3oFQGTFf8EWV0AHoLudNtpSSB_t+pCfkOkQ@mail.gmail.com> On Thu, May 21, 2020 at 11:06:23AM +0200, Arnd Bergmann wrote: > On Thu, May 21, 2020 at 10:11 AM Sudeep Holla <sudeep.holla@arm.com> wrote: > > On Thu, May 21, 2020 at 08:57:56AM +0100, Will Deacon wrote: > > > On Thu, May 21, 2020 at 09:34:10AM +0200, Arnd Bergmann wrote: > > > > On Thu, May 21, 2020 at 9:07 AM Sudeep Holla <sudeep.holla@arm.com> wrote: > > > > > On Wed, May 20, 2020 at 11:54:16PM +0200, Arnd Bergmann wrote: > > > > > > On Wed, May 20, 2020 at 11:29 PM Will Deacon <will@kernel.org> wrote: > > > > > > > Applied to arm64 (for-next/smccc), thanks! > > > > > > > > > > > > > > Arnd -- Sudeep's reply to you about the sysfs groups seemed reasonable to me, > > > > > > > but please shout if you'd rather I dropped this in order to pursue an > > > > > > > alternative approach. > > > > > > > > > > > > I missed the reply earlier, thanks for pointing me to it again. > > > > > > D'oh, I took your silence as "no objections". Oh well! > > > > > > > > > I'm not entirely convinced, but don't revert it for now because of that, > > > > > > I assume we can find a solution. > > > > > > Ok, cheers. It's on a separate branch so it's easy enough to drop if > > > necessary (i.e. no reverts needed). Sudeep -- please send any extra patches > > > on top of the branch. > > > > > > > Indeed, it is also last patch in the series. However if Arnd is happy > > with the sysfs names, we can move to generic code later without breaking > > anything. > > > > We need not revert or drop it now. I will leave that to you or Arnd to > > decide. Just that it may be too late to get acks for all the soc sysfs > > drivers in time for v5.8 > > > > I am fine if you want to drop the last patch. > > Ok, let's drop that patch then and make sure we do something that > everyone is happy with later on. I'm already in favor of adding > a more reliable soc_device instance based on this, but we need to > be sure we don't screw up the contents of the attributes when we > can't change them later. > Sure. Will, please drop the last patch in the series. I will rework moving the custom attributes to the core. > > > > >> drivers/firmware/smccc/smccc.c:14:13: warning: no previous prototype for function 'arm_smccc_version_init' [-Wmissing-prototypes] > > > > void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit) > > > > ^ > > > > drivers/firmware/smccc/smccc.c:14:1: note: declare 'static' if the > > > > function is not intended to be used outside of this translation unit > > > > void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit) > > > > > > I saw that when I applied the patches, but since the function is called from > > > another compilation unit (psci/psci.o), I just ignored it as we have loads > > > of these already and it only screams if you build with W=1. > > > > > > > /me confused. Do you need the fix for this warning or you are happy to ignore? > > I want a fix for that, as I hope we can eventually turn this warning on by > default and stop playing whack-a-mole when they come up. Most of these > warnings are harmless, but occasionally the prototypes don't match exactly > and cause real bugs depending on the configuration, and ensuring both > sides include a common header file is an easy way to make it work > more reliably. > Agreed. > Note that the warning should come up for either W=1 or C=1, and I also > think that new code should generally be written sparse-clean and have > no warnings with 'make C=1' as a rule. > Sure, I am facing issues with clang-8, it fails to build arm_smccc_1_1_invoke which I think Nick was mentioning in some other thread. I will try latest clang. -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-05-21 9:15 UTC|newest] Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-05-18 9:12 [PATCH v4 0/7] firmware: smccc: Add basic SMCCC v1.2 + ARCH_SOC_ID support Sudeep Holla 2020-05-18 9:12 ` Sudeep Holla 2020-05-18 9:12 ` [PATCH v4 1/7] firmware: smccc: Add HAVE_ARM_SMCCC_DISCOVERY to identify SMCCC v1.1 and above Sudeep Holla 2020-05-18 9:12 ` Sudeep Holla 2020-05-18 9:12 ` [PATCH v4 2/7] firmware: smccc: Update link to latest SMCCC specification Sudeep Holla 2020-05-18 9:12 ` Sudeep Holla 2020-05-18 9:12 ` [PATCH v4 3/7] firmware: smccc: Add the definition for SMCCCv1.2 version/error codes Sudeep Holla 2020-05-18 9:12 ` Sudeep Holla 2020-05-18 9:12 ` [PATCH v4 4/7] firmware: smccc: Drop smccc_version enum and use ARM_SMCCC_VERSION_1_x instead Sudeep Holla 2020-05-18 9:12 ` Sudeep Holla 2020-05-18 9:12 ` [PATCH v4 5/7] firmware: smccc: Refactor SMCCC specific bits into separate file Sudeep Holla 2020-05-18 9:12 ` Sudeep Holla 2020-05-19 12:00 ` kbuild test robot 2020-05-20 10:29 ` kbuild test robot 2020-05-18 9:12 ` [PATCH v4 6/7] firmware: smccc: Add function to fetch SMCCC version Sudeep Holla 2020-05-18 9:12 ` Sudeep Holla 2020-05-18 9:12 ` [PATCH v4 7/7] firmware: smccc: Add ARCH_SOC_ID support Sudeep Holla 2020-05-18 9:12 ` Sudeep Holla 2020-05-18 9:30 ` Arnd Bergmann 2020-05-18 9:30 ` Arnd Bergmann 2020-05-18 11:55 ` Sudeep Holla 2020-05-18 11:55 ` Sudeep Holla 2020-05-20 21:51 ` Arnd Bergmann 2020-05-20 21:51 ` Arnd Bergmann 2020-05-21 7:07 ` Sudeep Holla 2020-05-21 7:07 ` Sudeep Holla 2020-05-20 21:29 ` [PATCH v4 0/7] firmware: smccc: Add basic SMCCC v1.2 + " Will Deacon 2020-05-20 21:29 ` Will Deacon 2020-05-20 21:54 ` Arnd Bergmann 2020-05-20 21:54 ` Arnd Bergmann 2020-05-21 7:07 ` Sudeep Holla 2020-05-21 7:07 ` Sudeep Holla 2020-05-21 7:34 ` Arnd Bergmann 2020-05-21 7:34 ` Arnd Bergmann 2020-05-21 7:57 ` Will Deacon 2020-05-21 7:57 ` Will Deacon 2020-05-21 8:10 ` Sudeep Holla 2020-05-21 8:10 ` Sudeep Holla 2020-05-21 9:06 ` Arnd Bergmann 2020-05-21 9:06 ` Arnd Bergmann 2020-05-21 9:15 ` Sudeep Holla [this message] 2020-05-21 9:15 ` Sudeep Holla 2020-05-21 9:17 ` Will Deacon 2020-05-21 9:17 ` Will Deacon 2020-05-21 9:26 ` Sudeep Holla 2020-05-21 9:26 ` Sudeep Holla 2020-05-21 10:14 ` Will Deacon 2020-05-21 10:14 ` Will Deacon 2020-05-21 10:24 ` Sudeep Holla 2020-05-21 10:24 ` Sudeep Holla 2020-05-21 9:30 ` Arnd Bergmann 2020-05-21 9:30 ` Arnd Bergmann 2020-05-21 10:14 ` Russell King - ARM Linux admin 2020-05-21 10:14 ` Russell King - ARM Linux admin 2020-05-21 10:31 ` Arnd Bergmann 2020-05-21 10:31 ` Arnd Bergmann 2020-05-21 11:46 ` Russell King - ARM Linux admin 2020-05-21 11:46 ` Russell King - ARM Linux admin 2020-05-21 8:05 ` Sudeep Holla 2020-05-21 8:05 ` 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=20200521091458.GA6425@bogus \ --to=sudeep.holla@arm.com \ --cc=arnd@arndb.de \ --cc=catalin.marinas@arm.com \ --cc=harb@amperecomputing.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lorenzo.pieralisi@arm.com \ --cc=mark.rutland@arm.com \ --cc=steven.price@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: linkBe 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.