From: Michael Ellerman <mpe@ellerman.id.au>
To: Andrew Donnellan <ajd@linux.ibm.com>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-scsi@vger.kernel.org
Cc: fbarrat@linux.ibm.com, ukrishn@linux.ibm.com, manoj@linux.ibm.com
Subject: Re: [PATCH 2/2] MAINTAINERS: Make cxl obsolete
Date: Fri, 03 May 2024 20:31:24 +1000 [thread overview]
Message-ID: <87le4ruqyr.fsf@mail.lhotse> (raw)
In-Reply-To: <2492716e18c515e21b855305c0bc760057dbcf7a.camel@linux.ibm.com>
Andrew Donnellan <ajd@linux.ibm.com> writes:
> On Fri, 2024-05-03 at 13:15 +1000, Andrew Donnellan wrote:
>> This doesn't seem quite right to me, I don't think we can just
>> redefine
>> CONFIG_CXL as a bool, but I'll do something like this. Probably won't
>> bother for CXLFLASH since they'll see it for CXL anyway, but I might
>> add a warning message on probe to both drivers.
>
> The more I look at how to do this, the more issues I see, though
> perhaps because I personally use olddefconfig more than I use
> oldconfig.
>
> Without changing the default to n, running olddefconfig is liable to
> switch CXL back on in configs where the user has disabled it.
Yes that's true.
> Conversely, if the user has set CXL=y rather than CXL=m, I'm not sure
> if there's any way to make it such that olddefconfig doesn't reset one
> symbol or the other to the default m.
>
> Honestly, I'm very tempted to be a little more aggressive and a) not
> bother with trying to play games with symbols, b) change the default to
> n in this release, c) add a warning printed on probe, and see whether
> anyone complains.
You mean just changing CXL to default n?
The problem is that has no effect on folks with existing configs. Those
of us who build from defconfigs will have it turned off, but any actual
users with existing configs will just still have it enabled.
I'm not really convinced printing warnings does much. I guess an actual
WARN_ON might work, but only if someone is watching the console.
> We could also print a message during the build itself, though that kind
> of noise is liable to break things in other ways?
More likely to break some CI somewhere, and a good chance it isn't even
seen by a human unless they're paying close attention to the build
output.
> It would be kind of nice if kbuild had some way to mark a symbol for
> deprecation which could print a warning during configuration.
Yeah, though it suffers from the same problem that there's a good chance
no one notices.
The below I think works. It does print a warning about CXL changing from
tristate to bool, but that seems harmless.
In all cases olddefconfig will turn CXL off, whether it was on, off
or =m beforehand. A fresh defconfig has it off. The only way to turn it
on is explicitly.
cheers
diff --git a/drivers/misc/cxl/Kconfig b/drivers/misc/cxl/Kconfig
index 5efc4151bf58..e62c16cc7292 100644
--- a/drivers/misc/cxl/Kconfig
+++ b/drivers/misc/cxl/Kconfig
@@ -9,11 +9,18 @@ config CXL_BASE
select PPC_64S_HASH_MMU
config CXL
- tristate "Support for IBM Coherent Accelerators (CXL)"
+ def_bool y
+ depends on DEPRECATED_CXL
+
+config DEPRECATED_CXL
+ tristate "Deprecated support for IBM Coherent Accelerators (CXL)"
depends on PPC_POWERNV && PCI_MSI && EEH
select CXL_BASE
- default m
+ default n
help
+ The cxl driver is no longer actively maintained and we intend to
+ remove it in a future kernel release.
+
Select this option to enable driver support for IBM Coherent
Accelerators (CXL). CXL is otherwise known as Coherent Accelerator
Processor Interface (CAPI). CAPI allows accelerators in FPGAs to be
next prev parent reply other threads:[~2024-05-03 10:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-09 3:10 [PATCH 1/2] MAINTAINERS: Make cxlflash obsolete Andrew Donnellan
2024-04-09 3:10 ` [PATCH 2/2] MAINTAINERS: Make cxl obsolete Andrew Donnellan
2024-04-09 4:37 ` Michael Ellerman
2024-04-09 5:53 ` Christophe Leroy
2024-04-10 11:38 ` Michael Ellerman
2024-04-10 23:43 ` Finn Thain
2024-05-03 3:15 ` Andrew Donnellan
2024-05-03 7:55 ` Andrew Donnellan
2024-05-03 10:31 ` Michael Ellerman [this message]
2024-04-25 1:57 ` [PATCH 1/2] MAINTAINERS: Make cxlflash obsolete Martin K. Petersen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87le4ruqyr.fsf@mail.lhotse \
--to=mpe@ellerman.id.au \
--cc=ajd@linux.ibm.com \
--cc=fbarrat@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=manoj@linux.ibm.com \
--cc=ukrishn@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 read-only IMAP folder(s) and NNTP newsgroup(s).