linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Donnellan <ajd@linux.ibm.com>
To: Michael Ellerman <mpe@ellerman.id.au>,
	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 17:55:03 +1000	[thread overview]
Message-ID: <2492716e18c515e21b855305c0bc760057dbcf7a.camel@linux.ibm.com> (raw)
In-Reply-To: <33cf08b4fe751af156b1a7c17f69a0ca37dc5eed.camel@linux.ibm.com>

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.

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.

We could also print a message during the build itself, though that kind
of noise is liable to break things in other ways?

It would be kind of nice if kbuild had some way to mark a symbol for
deprecation which could print a warning during configuration.

-- 
Andrew Donnellan    OzLabs, ADL Canberra
ajd@linux.ibm.com   IBM Australia Limited

  reply	other threads:[~2024-05-03  7:56 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 [this message]
2024-05-03 10:31         ` Michael Ellerman
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=2492716e18c515e21b855305c0bc760057dbcf7a.camel@linux.ibm.com \
    --to=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=mpe@ellerman.id.au \
    --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 NNTP newsgroup(s).