Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp2061024pxb; Mon, 11 Oct 2021 20:37:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJySULFAcSA0cXmGE9Q2GbNtBAyCmztHQQNZmvCakgVLRmIDFhU1GYcazPGdKmQwds+y8q/e X-Received: by 2002:a17:906:369a:: with SMTP id a26mr29408491ejc.539.1634009876076; Mon, 11 Oct 2021 20:37:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634009876; cv=none; d=google.com; s=arc-20160816; b=PpbeIgO8AAwDVm6COvuvftkpufcJaj9C90xUWBfa7TR/GZlsbPuuTvTGMZZI8tcWiS jwOXdDCWVE5+7MKV5il4vrF/YulkRF8fVz80nuG3/TNHl4ucxiH9RnQOzpZyNl/2qrLT tXDqUJGjo5ReVx0RQqbnkkobueygeL2P/P3qgW+6UzryrOAQ+zAvTM40j7NEDBK5YD6Y y9t71RQbKZXEuNcXURxgnpVlIUZq3M1FkttpIYylRcN3Zn75bLSX9/9YIdxkWmvGHOVe UM/aFSLXl4QuKazF4dEwE4JnACDGqirPSSRLSCa4j9O9QWlbJ9L5yGZIWeOBCzXcrXWq Qpgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=EmhQGrBHhBqco3/fKYTerqn3hrMIea7RZ3yw7yTntJk=; b=aRSQKlAJ9CKYKpXHk3D+YydEV7VWkSnWOD8uprX4rCwXeBtNnd3OrEnowniUkEFo92 zL2nZN2nr2mZjv3OvbioEl7Yh6e7gAKVlZ8SwYquXJKzPGS+qdoE/eDTWaFvpLzbWFtd EiADY/v5PN5btFXzZY4OH1nqe2nScxED52iDmRhUHuMcLTLVWc7I/9R/7BBTaROiZMTT a8MtqZT2UqK3L8s6ZZyDBGCp2O6lSD8cGz+2p1fPcb+q2lXmx5rwzC1gkt9OFURqeWOI 6Wtt+K8ih1fYvY4klgXWntiCvokM7/ejotbEq7numtYe0Z1DSz3sAYxka4JhMO7kJy5I m7VA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=FC1XDkTl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v8si14910900ejy.617.2021.10.11.20.37.25; Mon, 11 Oct 2021 20:37:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=FC1XDkTl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232063AbhJLDhK (ORCPT + 99 others); Mon, 11 Oct 2021 23:37:10 -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-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