From: "Gabriel L. Somlo" <gsomlo@gmail.com>
To: Jean Delvare <jdelvare@suse.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
Karol Gugala <kgugala@antmicro.com>,
Mateusz Holenko <mholenko@antmicro.com>,
Joel Stanley <joel@jms.id.au>
Subject: Re: [PATCH] drivers/soc/litex: drop obsolete dependency on COMPILE_TEST
Date: Thu, 16 Nov 2023 09:34:38 -0500 [thread overview]
Message-ID: <ZVYofpygbLMCN7lI@errol.ini.cmu.edu> (raw)
In-Reply-To: <20231116150357.6a2fa8f9@endymion.delvare>
On Thu, Nov 16, 2023 at 03:03:57PM +0100, Jean Delvare wrote:
> Hi Gabriel,
>
> On Fri, 25 Nov 2022 09:00:02 -0500, Gabriel L. Somlo wrote:
> > On Thu, Nov 24, 2022 at 04:16:18PM +0100, Jean Delvare wrote:
> > > Since commit 0166dc11be91 ("of: make CONFIG_OF user selectable"), it
> > > is possible to test-build any driver which depends on OF on any
> > > architecture by explicitly selecting OF. Therefore depending on
> > > COMPILE_TEST as an alternative is no longer needed.
> > >
> > > It is actually better to always build such drivers with OF enabled,
> > > so that the test builds are closer to how each driver will actually be
> > > built on its intended target. Building them without OF may not test
> > > much as the compiler will optimize out potentially large parts of the
> > > code. In the worst case, this could even pop false positive warnings.
> > > Dropping COMPILE_TEST here improves the quality of our testing and
> > > avoids wasting time on non-existent issues.
> > >
> > > As a minor optimization, this also lets us drop of_match_ptr() and
> > > ifdef-guarding, as we now know what they will resolve to, we might as
> > > well save cpp some work.
> >
> > Acked-by: Gabriel Somlo <gsomlo@gmail.com>
>
> Despite your ack, this patch was never committed. Was it forgotten
> somehow? Should I resubmit?
AFAIK, LiteX is too small to have its own direct path into Linus's
upstream tree, and so far any changes to LiteX specific kernel code
were filtered upstream through the respective dedicated subsystems
affected (e.g., mmc, networking, block, etc.).
IIRC Joel (cc-ed) might have been involved in the upstreaming of the
original LiteX soc driver -- is that correct? If so, which way did it
end up going upstream, and can we replicate that for Jean's patch?
Thanks much,
--Gabriel
> Thanks,
> --
> Jean Delvare
> SUSE L3 Support
next prev parent reply other threads:[~2023-11-16 14:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-24 15:16 Jean Delvare
2022-11-25 14:00 ` Gabriel L. Somlo
2023-11-16 14:03 ` Jean Delvare
2023-11-16 14:34 ` Gabriel L. Somlo [this message]
2023-12-20 20:36 ` Gabriel L. Somlo
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=ZVYofpygbLMCN7lI@errol.ini.cmu.edu \
--to=gsomlo@gmail.com \
--cc=jdelvare@suse.de \
--cc=joel@jms.id.au \
--cc=kgugala@antmicro.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mholenko@antmicro.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
all inboxes | Powered by JetHome®