From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 92CC9524A0; Mon, 18 Mar 2024 15:24:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710775461; cv=none; b=J1GqHXRML9F9kRFfuH5dgcWyQJpRAENP9z80p+M9/1QLCMO+hiEhPqjAT0lZlmCVeWJ7x7EzZY5yFidggRilSB+8dtfibOJ3HRIJDhTxpggBwWenjxBmA07lNXnMvBHrTcYqZ0jSl2qHpcujZJObOvKAWO0v0Q9emNgx+a0yhCg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1710775461; c=relaxed/simple; bh=H5Yl2+KH5clpDAidnyUJS6JZKwl1txrmCW3WlkQErtY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=nXSskP7x02RtEG6KJ3yAQMR6gmfN0RCpEFMZ0z+2B+7rub+DmdsPvcEWjrpPjYrwXPYj8C3B/8SBL+7i5ef9g9b3UNx2dOANCgb56USRtLoYk9rQIE+7FdOjk5ZQGmTp3Ap6gWV2TXmRZokRUDe76q0KEBXhgtLTcj7NV4nTA+o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=CUYs6qZd; arc=none smtp.client-ip=192.198.163.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="CUYs6qZd" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1710775460; x=1742311460; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=H5Yl2+KH5clpDAidnyUJS6JZKwl1txrmCW3WlkQErtY=; b=CUYs6qZdtfdoS5y8xzNSgNbD+RchsJQE1vINYs1OLw+kpJ1vtAZFF7MV GtZuKt3JSop+VcqZGLNxd+d95UGRMn0hAN3KrJ7Se005Eqquh0TwRoWPC QmvDJY/lbx9G4lxa3dd/PXdBpx3J8DC/WZEngtKu7Y5o+PyHZdwcyorDz JcPReHQsdS5sZm/jJ2aeujDzshLBjU0RBT1CUFo7Z/lzKsY6Pm2b7ce/K UVU2wUcyhJqQntF6FlT0TgIREB6PbxX4+J55f66lg2HRlE8v7G/8PzeDy HJqAAdATQLGGxP9+q0o8IwjDWpenWyGRsZKC1rCTQrcsOc/wxqFuECWxQ Q==; X-IronPort-AV: E=McAfee;i="6600,9927,11017"; a="5456392" X-IronPort-AV: E=Sophos;i="6.07,134,1708416000"; d="scan'208";a="5456392" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Mar 2024 08:24:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,134,1708416000"; d="scan'208";a="13398989" Received: from ahmedess-mobl.ger.corp.intel.com (HELO localhost) ([10.252.53.133]) by fmviesa010-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Mar 2024 08:24:13 -0700 From: Jani Nikula To: Luca Weiss , Neil Armstrong , Andrzej Hajda , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter Cc: ~postmarketos/upstreaming@lists.sr.ht, phone-devel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Masahiro Yamada Subject: Re: [PATCH] drm/bridge: Select DRM_KMS_HELPER for DRM_PANEL_BRIDGE In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20240111-drm-panel-bridge-fixup-v1-1-e06292f6f500@fairphone.com> <171075294759.1615603.8073986785380285265.b4-ty@linaro.org> <87wmpzq0bp.fsf@intel.com> <87ttl3pzzi.fsf@intel.com> Date: Mon, 18 Mar 2024 17:24:10 +0200 Message-ID: <8734snpnqd.fsf@intel.com> Precedence: bulk X-Mailing-List: phone-devel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Mon, 18 Mar 2024, "Luca Weiss" wrote: > Would you know the correct fix for this? I'm aware of the pattern > "select FOO || !FOO" but I guess it's also not applicable here? I don't think that pattern works for select, only for depends on. And I think the problem, again, is the abuse of select for symbols with dependencies. $ git grep "select DRM_KMS_HELPER" | wc -l 122 I'm guessing these only work because a) they are tristates, and b) they directly or indirectly already "depends on DRM", which satisfies DRM_KMS_HELPER's "depends on DRM". I think the correct fix for this, and a plethora of other kconfig problems, is adhering to the note in Documentation/kbuild/kconfig-language.rst: Note: select should be used with care. select will force a symbol to a value without visiting the dependencies. By abusing select you are able to select a symbol FOO even if FOO depends on BAR that is not set. In general use select only for non-visible symbols (no prompts anywhere) and for symbols with no dependencies. That will limit the usefulness but on the other hand avoid the illegal configurations all over. The downsides are that it's a lot of churn to fix them, they'll creep back in, and kconfig doesn't warn about these cases up front while it could, and menuconfig etc. aren't helpful in enabling dependencies for you recursively. So here we are, adding bandaid year after year. :( BR, Jani. -- Jani Nikula, Intel