Messages in this thread | | | Date | Thu, 21 May 2020 09:05:54 +0100 | From | Sudeep Holla <> | Subject | Re: [PATCH v4 0/7] firmware: smccc: Add basic SMCCC v1.2 + ARCH_SOC_ID support |
| |
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: > > > > > > > > On Mon, 18 May 2020 10:12:15 +0100, Sudeep Holla wrote: > > > > > This patch series adds support for SMCCCv1.2 ARCH_SOC_ID. > > > > > This doesn't add other changes added in SMCCC v1.2 yet. They will > > > > > follow these soon along with its first user SPCI/PSA-FF. > > > > > > > > > > This is tested using upstream TF-A + the patch[3] fixing the original > > > > > implementation there. > > > > > > > > > > [...] > > > > > > > > Applied to arm64 (for-next/smccc), thanks! > > > > > > > > [1/7] firmware: smccc: Add HAVE_ARM_SMCCC_DISCOVERY to identify SMCCC v1.1 and above > > > > https://git.kernel.org/arm64/c/e5bfb21d98b6 > > > > [2/7] firmware: smccc: Update link to latest SMCCC specification > > > > https://git.kernel.org/arm64/c/15c704ab6244 > > > > [3/7] firmware: smccc: Add the definition for SMCCCv1.2 version/error codes > > > > https://git.kernel.org/arm64/c/0441bfe7f00a > > > > [4/7] firmware: smccc: Drop smccc_version enum and use ARM_SMCCC_VERSION_1_x instead > > > > https://git.kernel.org/arm64/c/ad5a57dfe434 > > > > [5/7] firmware: smccc: Refactor SMCCC specific bits into separate file > > > > https://git.kernel.org/arm64/c/f2ae97062a48 > > > > [6/7] firmware: smccc: Add function to fetch SMCCC version > > > > https://git.kernel.org/arm64/c/a4fb17465182 > > > > [7/7] firmware: smccc: Add ARCH_SOC_ID support > > > > https://git.kernel.org/arm64/c/ce6488f0ce09 > > > > > > > > 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. > > > > > > I'm not entirely convinced, but don't revert it for now because of that, > > > I assume we can find a solution. > > > > > > > I liked your idea of making this generic and hardcode values if required > > for other drivers. I will take a look at that/ > > > > > However, please have a look at the build failure report for patch 5 > > > and fix it if you can see what went wrong. > > > > > > > Any pointers for that failure ? I seem to have missed them. I pushed > > branch couple of times to my tree but got build success both times. > > Any specific config or compilers ? > > See below for the reply from the 0day build bot to your email. It seems it > was not sent to the mailing list, but you were on Cc. Looking at it now, > the fix should be trivial. >
Ah, clang it is. I must start building with clang regularly. Thanks for pointing it out. Somehow few of these kbuild-bot emails has been marked junk last few days. Sorry for the noise.
-- Regards, Sudeep
| |