* Re: [PATCH] drm/xe: Make xe build dependent on STAGING.
[not found] <20230509151008.1434683-1-rodrigo.vivi@intel.com>
@ 2023-05-09 16:56 ` Lucas De Marchi
2023-05-10 8:23 ` Greg Kroah-Hartman
0 siblings, 1 reply; 2+ messages in thread
From: Lucas De Marchi @ 2023-05-09 16:56 UTC (permalink / raw)
To: Rodrigo Vivi
Cc: intel-xe, Mauro Carvalho Chehab, Radoslaw Szwichtenberg,
Maciej Ramotowski, Kamil Konieczny, Greg Kroah-Hartman,
linux-staging, dri-devel
On Tue, May 09, 2023 at 11:10:08AM -0400, Rodrigo Vivi wrote:
>As documented in drivers/staging/Kconfig:
>
>STAGING means "that these drivers are under heavy development" and
>"may contain userspace interfaces that most likely will be changed
>in the near future."
>
>As explained in Documentation/gpu/rfc/xe.rst:
>
>"
>Xe driver will be protected with both STAGING Kconfig and force_probe.
>Changes in the uAPI are expected while the driver is behind these
>protections. STAGING will be removed when the driver uAPI gets to a
>mature state where we can guarantee the ‘no regression’ rule.
>Then force_probe will be lifted only for future platforms that will be
>productized with Xe driver, but not with i915.
>"
>
>Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
>Cc: Lucas De Marchi <lucas.demarchi@intel.com>
>Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
>Cc: Maciej Ramotowski <maciej.ramotowski@intel.com>
>Cc: Kamil Konieczny <kamil.konieczny@linux.intel.com>
>Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
I agree with the idea, but I was expecting a few more hits:
$ git grep "\bSTAGING\b" -- '*Kconfig'
drivers/gpu/drm/nouveau/Kconfig: depends on STAGING
drivers/gpu/drm/tegra/Kconfig: depends on STAGING
drivers/staging/Kconfig:menuconfig STAGING
drivers/staging/Kconfig:if STAGING
drivers/staging/Kconfig:endif # STAGING
drivers/staging/vme_user/Kconfig: depends on STAGING && PCI
drivers/staging/vme_user/Kconfig: depends on STAGING && VME_BUS
Are we doing something wrong here? Documentation/process/2.Process.rst
talks about drivers under staging/ directory rather than drivers
depending on CONFIG_STAGING.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-staging@lists.linux.dev
Cc: dri-devel@lists.freedesktop.org
Lucas De Marchi
>---
> drivers/gpu/drm/xe/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/drivers/gpu/drm/xe/Kconfig b/drivers/gpu/drm/xe/Kconfig
>index f6f3b491d162..1a410edd38e4 100644
>--- a/drivers/gpu/drm/xe/Kconfig
>+++ b/drivers/gpu/drm/xe/Kconfig
>@@ -2,6 +2,7 @@
> config DRM_XE
> tristate "Intel Xe Graphics"
> depends on DRM && PCI && MMU
>+ depends on STAGING
> select INTERVAL_TREE
> # we need shmfs for the swappable backing store, and in particular
> # the shmem_readpage() which depends upon tmpfs
>--
>2.39.2
>
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] drm/xe: Make xe build dependent on STAGING.
2023-05-09 16:56 ` [PATCH] drm/xe: Make xe build dependent on STAGING Lucas De Marchi
@ 2023-05-10 8:23 ` Greg Kroah-Hartman
0 siblings, 0 replies; 2+ messages in thread
From: Greg Kroah-Hartman @ 2023-05-10 8:23 UTC (permalink / raw)
To: Lucas De Marchi
Cc: Rodrigo Vivi, intel-xe, Mauro Carvalho Chehab,
Radoslaw Szwichtenberg, Maciej Ramotowski, Kamil Konieczny,
linux-staging, dri-devel
On Tue, May 09, 2023 at 09:56:33AM -0700, Lucas De Marchi wrote:
> On Tue, May 09, 2023 at 11:10:08AM -0400, Rodrigo Vivi wrote:
> > As documented in drivers/staging/Kconfig:
> >
> > STAGING means "that these drivers are under heavy development" and
> > "may contain userspace interfaces that most likely will be changed
> > in the near future."
> >
> > As explained in Documentation/gpu/rfc/xe.rst:
> >
> > "
> > Xe driver will be protected with both STAGING Kconfig and force_probe.
> > Changes in the uAPI are expected while the driver is behind these
> > protections. STAGING will be removed when the driver uAPI gets to a
> > mature state where we can guarantee the ‘no regression’ rule.
> > Then force_probe will be lifted only for future platforms that will be
> > productized with Xe driver, but not with i915.
> > "
> >
> > Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
> > Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> > Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
> > Cc: Maciej Ramotowski <maciej.ramotowski@intel.com>
> > Cc: Kamil Konieczny <kamil.konieczny@linux.intel.com>
> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
>
> I agree with the idea, but I was expecting a few more hits:
>
> $ git grep "\bSTAGING\b" -- '*Kconfig'
> drivers/gpu/drm/nouveau/Kconfig: depends on STAGING
> drivers/gpu/drm/tegra/Kconfig: depends on STAGING
> drivers/staging/Kconfig:menuconfig STAGING
> drivers/staging/Kconfig:if STAGING
> drivers/staging/Kconfig:endif # STAGING
> drivers/staging/vme_user/Kconfig: depends on STAGING && PCI
> drivers/staging/vme_user/Kconfig: depends on STAGING && VME_BUS
>
> Are we doing something wrong here? Documentation/process/2.Process.rst
> talks about drivers under staging/ directory rather than drivers
> depending on CONFIG_STAGING.
Yes, you are doing something wrong here :)
CONFIG_STAGING is only to be used for drivers/staging/. But I will not
take drm drivers into that directory as the DRM developers don't want me
to (and that's wonderful, no objection from me).
If you just use the CONFIG dependancy here you will not get the taint
flag set properly if they are out of that directory (and you want that
taint flag, TAINT_CRAP is there for that reason.)
But hey, it's your subsystem, if you want to depend on this random
config variable, wonderful! But realize that it means nothing, and has
nothing to do with user/kernel api stability issues at all.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2023-05-10 8:24 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20230509151008.1434683-1-rodrigo.vivi@intel.com>
2023-05-09 16:56 ` [PATCH] drm/xe: Make xe build dependent on STAGING Lucas De Marchi
2023-05-10 8:23 ` Greg Kroah-Hartman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).