From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E545DC433F5 for ; Tue, 12 Oct 2021 03:35:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CD18360F43 for ; Tue, 12 Oct 2021 03:35:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232135AbhJLDhM (ORCPT ); Mon, 11 Oct 2021 23:37:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52158 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231755AbhJLDhJ (ORCPT ); Mon, 11 Oct 2021 23:37:09 -0400 Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 39903C061570 for ; Mon, 11 Oct 2021 20:35:07 -0700 (PDT) Received: by mail-qv1-xf29.google.com with SMTP id z3so12157226qvl.9 for ; Mon, 11 Oct 2021 20:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EmhQGrBHhBqco3/fKYTerqn3hrMIea7RZ3yw7yTntJk=; b=FC1XDkTlI9I/tEz1ohiUY519cWZieN3uOODYV1C8Mv3OPjdtuFF+dqXcKq77X5dTbL FITyfzUfZejn0lwoVQeHM4AB2z4b5c5tInY0RTkagZbfu5nYFlWPBc5Zx/zpJMx3zM5T 4v/o6h1PcKie+43TKXDMoBuLDUJX7aItxVIUwGjHMLdz2mtn+hb6QeNbKqm4fEoCBz6p 8K8yqovQoXvFiY2FMTkwqAP8uFXwjIjE+AiWX1ww9oZJJ99LE+Hy8oYKAZ8Sy+kQYNFs MzLN+AGWmAWrziF0nCvPLEkzSA9KcMArO6SdzuV4FN6wl/LXMiF3A/sm2Jz+cRzHwFSu mokg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EmhQGrBHhBqco3/fKYTerqn3hrMIea7RZ3yw7yTntJk=; b=3X0P0FK6dv/tuygw0C/QjnWOUtYWOnoQdXZefe9XzrbVblmmIl99ZlLhgQBgcvesaS ovlCuGJrpUtj6nTTTosHo6fk23vIgQruHIsUbGwAyKxtAk8nXRhVFvtdUk3rylCAqh01 O1uS9FOwKMcpSaA1p3jJHLNRKLuVfUW7tsYBcO+6ohOvZumpo1Rn7fvW+rLsWWTIOvLx PfupHtWDhlQpNQxrpzrgGMnXER7CGx2LMuFaEldcP8FJi/gLUH7F/wV0VCs50ObTYg0p JkMj8n6t0LUNCXO9OBniolHlz/CU8zwu54ABTnt++p3G7f0tRkwfvNKkJn0sTS9cDAI6 +WwQ== X-Gm-Message-State: AOAM530P2tOkSMOoRsX0rVXvViiqXzgbMu8BfcZoYZziJPbhEQ+zpc6Q xQfjYIHY3XAd3Mp3MDPRVOGVxHyxADkx4hGMWsAItw== X-Google-Smtp-Source: ABdhPJwYk1vV8P7NVAAIhul2dADSwoQQewMWHAp5qbboSqFlQZFU1gNvtKnlICCH4yrsmE2uME429X0JuBEM+OhICKQ= X-Received: by 2002:a05:6214:70f:: with SMTP id b15mr27855384qvz.16.1634009706228; Mon, 11 Oct 2021 20:35:06 -0700 (PDT) MIME-Version: 1.0 References: <20211010023350.978638-1-dmitry.baryshkov@linaro.org> In-Reply-To: From: Dmitry Baryshkov Date: Tue, 12 Oct 2021 06:34:54 +0300 Message-ID: Subject: Re: [PATCH] iommu: fix ARM_SMMU vs QCOM_SCM compilation To: Arnd Bergmann Cc: Bjorn Andersson , Joerg Roedel , Will Deacon , Robin Murphy , Kalle Valo , Thierry Reding , Andy Gross , linux-arm-msm , "open list:IOMMU DRIVERS" , Linux Kernel Mailing List , Linux ARM , Daniel Lezcano Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 11 Oct 2021 at 12:57, Arnd Bergmann wrote: > > On Mon, Oct 11, 2021 at 11:10 AM Dmitry Baryshkov > wrote: > > > > On Mon, 11 Oct 2021 at 09:09, Arnd Bergmann wrote: > > > > > > On Mon, Oct 11, 2021 at 6:11 AM Dmitry Baryshkov > > > wrote: > > > > On Sun, 10 Oct 2021 at 20:42, Arnd Bergmann wrote: > > > > > > > > The patch seems correct, but it becomes overcomplicated. What about: > > > > - restoring QCOM_SCM stubs > > > > > > The stubs are what has led to the previous bugs in this area to often > > > go unnoticed for too long, as illustrated by your suggestion > > > > > > > - making ARM_SMMU select QCOM_SCM if ARM_SMMU_QCOM > > > > > > I assume you meant "select QCOM_SCM if ARCH_QCOM", > > > after we stop using ARM_SMMU_QCOM? > > > > > > > This would have almost the same result as with your patch, but without > > > > extra ARM_SMMU_QCOM Kconfig symbol. > > > > > > The "almost" is the problem: consider the case of > > > > > > CONFIG_ARM=y > > > CONFIG_COMPILE_TEST=y > > > CONFIG_ARCH_QCOM=n > > > CONFIG_ARM_SMMU=y > > > CONFIG_DRM_MSM=m > > > CONFIG_QCOM_SCM=m (selected by DRM_MSM) > > > > > > The stubs here lead to ARM_SMMU linking against the QCOM_SCM > > > driver from built-in code, which fails because QCOM_SCM itself > > > is a loadable module. > > > > I see. The idealist in me wishes to change my suggestion to > > 'select QCOM_SCM if ARCH_QCOM || COMPILE_TEST' > > but I have the subtle feeling that this also might fail somehow. > > I think that would actually work, but it has the nasty side-effect > that simply flipping 'CONFIG_COMPILE_TEST' changes what > the kernel does, rather than just hiding or unhiding additional > options. > > > > We can move the "select QCOM_SCM" in the ARM_SMMU_QCOM > > > symbol if we make that a tristate though, if you want to separate it > > > a little more. > > > > This would complicate things a bit, as we would no longer be able to > > use 'arm-smmu-$(CONFIG_ARM_SMMU_QCOM) +=' construct. > > I'm fairly sure we could still use that, Kbuild is smart enough > to include both 'file-m +=' and 'file-y += ' in 'file.ko', see > scripts/Makefile.lib: > > # If $(foo-objs), $(foo-y), $(foo-m), or $(foo-) exists, foo.o is a > composite object > multi-obj-y := $(call multi-search, $(obj-y), .o, -objs -y) > multi-obj-m := $(call multi-search, $(obj-m), .o, -objs -y -m) > multi-obj-ym := $(multi-obj-y) $(multi-obj-m) > > # Replace multi-part objects by their individual parts, > # including built-in.a from subdirectories > real-obj-y := $(call real-search, $(obj-y), .o, -objs -y) > real-obj-m := $(call real-search, $(obj-m), .o, -objs -y -m) Ah, I thought Kbuild would accept only foo-y, please excuse me. > > What doesn't work is having a built-in driver in a directory that is > guarded with a =m symbol, or including a =m object into a =y > module. > > Arnd -- With best wishes Dmitry