From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=192.198.163.13 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794592304; b=4uYWq/DhXe6bxwKYHi+jQ+aBntv7hPDeZVMZ6jxhrR3G46PuL+kwo49fAXm9sge/jzns +sjem4+HmnCUgqq1dUjJCa0bFnVNZ99IZx9WsQ9R6gcSnTmidGH9hLeQJ+nyZKZI5OHuV j5vw67CIWpWAJ2a9Lt7X1PaiCHDlbqz4vXNPHHwQdamFZELEQWIFLoDGXgCK+UrytNWke foEljRdPE8q0cqouJXIl8o4BDJIXNkKjcpe1InVuC5YpnPObx68r9bJosruz78rh+iKMO aj1PatdUuxNg01A14SaC9qW0hmULMIbBifHgBsKNGZxUvOO4PqJlY5jmiAZeCZ4JEYA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794592304; h=DMARC-Filter:DKIM-Signature:X-CSE-ConnectionGUID:X-CSE-MsgGUID: X-IronPort-AV:X-IronPort-AV:Received:X-CSE-ConnectionGUID: X-CSE-MsgGUID:X-ExtLoop1:X-IronPort-AV:Received:Date:From:To:Cc: Subject:Message-ID:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To; bh=sA5GqT3X6+IlWG19cikWbDBjoSWPWXLSk78bC9Dx4xA=; b=wCDGmer38tWK7306e8a63u4jbmoXy3r18qIWFLBx3EC7JyREu+gsvm4+77cGNCAr9gg1 kmGxlNkt0rjzebvinN5I/su0jkOb/Qc+HtBw8xzSKG2kspjhhNlXfUPrheRMGrIzm7B3b HmDC76Z3Ak8VIUR828LrxOAZivbALbG6TOJ6hbfU6QukCJnPd1XbMQvFH9t7RWJr1bkLr 8LceoDp084p5GhTw5tYiG2bqZRXLS8O2xn2Y/ATYkgASwSMVIPXKnAqXkcP3v+eCTmT1u krzrkXo2pYb05fGyZpd2qwq4EIdvVS9lLCrSDC0UO8peEECMI4T/NO3JZO8Vkj5GIzw== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=EZnoo3NZ; arc=none smtp.remote-ip=192.198.163.13 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AAFCE606D4AF for ; Fri, 13 Nov 2026 17:51:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org AAFCE606D4AF Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=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.a=rsa-sha256 header.s=Intel header.b=EZnoo3NZ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1794592304; x=1826128304; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=ot8aUgvttzN3zhP6CmenM57WhZx/wtpRsYm0cuIyEHE=; b=EZnoo3NZvmcGgFi7IcJyP/rwtnkdlDaQW+LwCM4/YQcTOmJgwO6Nupa+ qC07ooTjBVhDBHIv6gJAJkbYWsxMXQ+rEeBQGQJWhCZYuP+TH2hs521UX Q3EtH9OipKHa8CMkDM1wYKt5RHuyjMANaOtif/f/qiSqfk92b0c6FC799 E+xMS7DEuCR+WHRI5riTys2W2EtTYjD0cC03wXQtHzDO2LN3LYaZ6/L46 OQqDeGs/UWpYjZfeCSQFoRjUvf2L9On1I/Tw36pOF2ZFMD58aR79/atqD AF55cL/gHMIYZRuhLjInL+Ny2rAOoW3tfpzTBXk7TTHexzHSdRdC2pRL9 A==; X-CSE-ConnectionGUID: +zSNn/ZVSrWHGUQfE3Lcsw== X-CSE-MsgGUID: lSk6L70VTtS2pA3dSu6beQ== X-IronPort-AV: E=McAfee;i="6800,10657,11965"; a="3396820" X-IronPort-AV: E=Sophos;i="6.27,212,1787036400"; d="scan'208";a="3396820" Received: from fmviesa007.fm.intel.com ([10.60.135.147]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Nov 2026 09:51:43 -0800 X-CSE-ConnectionGUID: RWBCcPdcRdOXUO4f8jkJ1g== X-CSE-MsgGUID: PepsrX++TK6EbR3/6QVo0g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.27,212,1787036400"; d="scan'208";a="9410690" Received: from black.igk.intel.com ([10.91.253.5]) by fmviesa007.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Nov 2026 09:51:40 -0800 Date: Fri, 13 Nov 2026 18:51:36 +0100 From: Raag Jadav To: Matt Roper Cc: Rodrigo Vivi , Arnd Bergmann , Matthew Brost , Thomas =?iso-8859-1?Q?Hellstr=F6m?= , David Airlie , Simona Vetter , Lucas De Marchi , Riana Tauro , Arnd Bergmann , Matthew Auld , Shuicheng Lin , Armin Wolf , Zhanjun Dong , Michal Wajdeczko , Piotr =?iso-8859-1?Q?Pi=F3rkowski?= , Tejas Upadhyay , intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] drm: xe: select configfs Message-ID: References: <20261026102603.2045493-1-arnd@kernel.org> <20261113162212.GB7214@mdroper-desk1> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20261113162212.GB7214@mdroper-desk1> On Fri, Nov 13, 2026 at 08:22:12AM -0800, Matt Roper wrote: > On Wed, Nov 11, 2026 at 02:01:45PM -0500, Rodrigo Vivi wrote: > > On Mon, Oct 26, 2026 at 11:25:50AM +0100, Arnd Bergmann wrote: > > > From: Arnd Bergmann > > > > > > The original addition of configfs to xe missed a compile-time dependency, > > > which leads to a link failure when configfs is enabled as a loadable module: > > > > > > ld.lld-21: error: undefined symbol: xe_configfs_get_survivability_mode > > > >>> referenced by xe_survivability_mode.c:224 > > > >>> drivers/gpu/drm/xe/xe_survivability_mode.o:(xe_survivability_mode_is_requested) in archive vmlinux.a > > > > > > A recent workaround added a 'IS_REACHABLE()' check around the calls into > > > configfs, which makes it link in this configuration, but this is generally > > > a bad idea because it makes the actual behavior inconsistent and confusing > > > to users that expect configfs to work if both xe and configfs are enabled. > > > > > > Use 'select CONFIGFS_FS' instead, like every other configfs user does, > > > and remove the unnecessary stub functions. There is little practical > > > difference here as anyone using XE graphics is likely to have a complex > > > configuration that already selects configfs anyway, and the link error > > > or the IS_REACHABLE() would only manifest during randconfig testing. > > > > > > Fixes: 30499cbd7961 ("drm/xe: Fix build with DRM_XE=y and CONFIGFS_FS=m") > > > Fixes: 16280ded45fb ("drm/xe: Add configfs to enable survivability mode") > > > Signed-off-by: Arnd Bergmann > > > --- > > > drivers/gpu/drm/xe/Kconfig | 1 + > > > drivers/gpu/drm/xe/xe_configfs.h | 30 ------------------------------ > > > 2 files changed, 1 insertion(+), 30 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/xe/Kconfig b/drivers/gpu/drm/xe/Kconfig > > > index 4fc8abdc5cb6..b52a8dc28f97 100644 > > > --- a/drivers/gpu/drm/xe/Kconfig > > > +++ b/drivers/gpu/drm/xe/Kconfig > > > @@ -11,6 +11,7 @@ config DRM_XE > > > # the shmem_readpage() which depends upon tmpfs > > > select SHMEM > > > select TMPFS > > > + select CONFIGFS_FS > > > > Perhaps another option would be what Jani had suggested: > > > > config DRM_XE_CONFIGFS > > def_bool y > > depends on DRM_XE && CONFIGFS_FS > > depends on CONFIGFS_FS=y || DRM_XE=m > > > > But anyway, we are depending more and more on the configfs for > > production choices. So, let's go with you select and close this > > for good. > > I really don't think this patch was the way we wanted to go. > IS_REACHABLE was giving us exactly the behavior that we wanted, but now > we're getting behavior that we did not want. Xe absolutely does not > depend on configfs in any way. _If_ configfs is there we'll enable some > config options in it, but none of those are mandatory for our driver as > a whole. We're perfectly happy to build and run without configfs if > it's not selected in the config. We're also happy to build and run > without configfs functionality if the user wanted Xe built directly into > the kernel, but configfs was built as an unreachable module solely for > other non-Xe purposes. > > While this change won't matter to 99% of the cases where someone is > running with a typical distro kernel, this is the kind of thing that > makes embedded users unhappy since they're very carefully managing their > configurations and we've taken away their ability to avoid configfs now. +1'ing on this. People go to great lengths to save a few bytes, only to be undone by a non-essential config. Raag