Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1431571pxb; Mon, 11 Oct 2021 06:00:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxT1H1cKWFgyY3qqru2A6QOGNvUowXrkIv/pGp/C9wQAbmGHVXsF39bpXoutJMntINoercy X-Received: by 2002:aa7:c78f:: with SMTP id n15mr42196448eds.338.1633957234261; Mon, 11 Oct 2021 06:00:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633957234; cv=none; d=google.com; s=arc-20160816; b=KelN5fIUwTTZWgMt79wW56BTdxf1+BPDPBME4flElF6u+u5TI4gVbbwu1fEvRNrvRq fwgjsfpkmuqUo2lI8zlCK2ZM5OBE3z2PjFp8gydAbEEpyH9Iy7H5/fvrhXun76jKBqzm 2+QT79bj/lxarXVzA39cXluGhCOqdIaX16cmYwlkkhD0rABWTn2Rx8HWQcm6KPiDy30r 3SKInVDVipEc4D7fEt5QSwYOkFmVnPonMj6bNOd5usbibrMqHMwfu309xzKGiAoKvnJO 0WrvIwCY+B+KosqmKSVREgaHhGuqXvdiVjPOg7/RRbx/zHsp12lmLwVkGEKsKLzqEBw/ x48w== 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=mmIaLKrbsPcdQfNFBZqmZSPhrHWq8Kaob/N8FHo8Fls=; b=MNztSj9qkoarOufeeLoZJb9AwNik4n0jmJLH2QyN4EeNT6w7W+zFe0KakPKUs2WwMR 3jqIPuKoFaZON1OXCxUyIG8l7QXkX7kqzTU71WlkuUdDSZQ/9ouKrGoAEVEkXEQc5q4P fXkEVpzLUVez/t5YvGhk2hwlOqb79EAG48l342R+DXeJYxU6IaBYWTfVgiDDYOdpdzJR lAHYYxhh3NhcHfnHv6DNwX8AhVNjYLqSXk5aphRVyb/uotQA5UIRvioKhcx6/wicZg54 SzzzZrV89JRVGlOsYauFjgvAChOS5SFtxF+5rqiI5VvOeefSgZU1C30ImZgcevNebEEf Qo6A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=bngqbi74; 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 sb18si16865736ejc.767.2021.10.11.06.00.08; Mon, 11 Oct 2021 06:00:34 -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=bngqbi74; 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 S235377AbhJKJLf (ORCPT + 99 others); Mon, 11 Oct 2021 05:11:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235379AbhJKJLc (ORCPT ); Mon, 11 Oct 2021 05:11:32 -0400 Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0B3B0C061570 for ; Mon, 11 Oct 2021 02:09:33 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id bi9so1988574qkb.11 for ; Mon, 11 Oct 2021 02:09:33 -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=mmIaLKrbsPcdQfNFBZqmZSPhrHWq8Kaob/N8FHo8Fls=; b=bngqbi74I3OBcqTY+RIZ8kWeuOyHiNmThFK5GldqFngvi3XfTkB/kMa4N7aEWxGf4C kmh669p4sU54vplIHzevZ6ejfSTv8hQ21EVKnM3Jwjd1juoNN9ok18sOGEGqKGm5O9aH yhIP76S1l/RUi3QUGSxRbqeKPvS+o6qroqohq5p8ltaBoa+yfGFdtK5ZE3EMpU4WKzMe CJMphtVwLtgfuCENg9doUy6BDJckfpz3LduUs/nX7anoP4IElpegKccrPUZlfiuoxQCR waBzIhbVBdiKwgqZ5Bw+t2UKyjagxdCSTYIJcAMPGNUOLWOYTDu/jgsdMw45ow121n44 6s+g== 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=mmIaLKrbsPcdQfNFBZqmZSPhrHWq8Kaob/N8FHo8Fls=; b=AMTvAZcak95tmlLtVJQDIcYDQXbOHXzougVYXQSJLyI/NZ8gsOJT8dO4oLSB2jnDaF q0YZzx2gaAeNv3t7J31WSnGw51bnyLUUI5sDhmZHXHNHPxENsa2h9en37bYXd07jAK4V 4g9eg56QXDPXFyGnFXeDRp28/hOgacaazk7M6/u5qDTDWRF80THXlPpfaOakw3rcDSa2 ofyakkWwkh8jfS3AodGDvZ4+1i0OaBuK2w5UoR/gw11aAWnlH7TPDtDksyQ7odOZu1BD RmqW2cYnIOo6lFXF4uzK6jeY4qK6n1/2SggWGuC2zu8e0g1Szo6nTVi1zHWb4ChJpJae HFDA== X-Gm-Message-State: AOAM53153wS8U5LuNrYOojg1/8/WcELhGtJZ7WmpmzCuC9/PgdUljzBb 5maT3CSyFdlLa5Xz8lxZnyH9yLsjMTJuNex8vC/r0A== X-Received: by 2002:a37:bac6:: with SMTP id k189mr13621788qkf.186.1633943372114; Mon, 11 Oct 2021 02:09:32 -0700 (PDT) MIME-Version: 1.0 References: <20211010023350.978638-1-dmitry.baryshkov@linaro.org> In-Reply-To: From: Dmitry Baryshkov Date: Mon, 11 Oct 2021 12:09:21 +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 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. > > 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. -- With best wishes Dmitry