intel-mid.h is providing some core parts of the South Complex PM,
which are usually are not used by individual drivers. In particular,
this driver doesn't use it, so simply remove the unused header.
Signed-off-by: Andy Shevchenko <[email protected]>
---
arch/x86/kernel/rtc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/x86/kernel/rtc.c b/arch/x86/kernel/rtc.c
index 2e7066980f3e..51a849a79c98 100644
--- a/arch/x86/kernel/rtc.c
+++ b/arch/x86/kernel/rtc.c
@@ -10,7 +10,6 @@
#include <asm/vsyscall.h>
#include <asm/x86_init.h>
#include <asm/time.h>
-#include <asm/intel-mid.h>
#include <asm/setup.h>
#ifdef CONFIG_X86_32
--
2.43.0.rc1.1.gbec44491f096
On 3/5/24 08:10, Andy Shevchenko wrote:
> intel-mid.h is providing some core parts of the South Complex PM,
> which are usually are not used by individual drivers. In particular,
> this driver doesn't use it, so simply remove the unused header.
Indeed. intel-mid.h provides a pretty small amount of stuff and it's
included in quite a few random-looking spots. There's also gunk that's
only compiled in if CONFIG_X86_INTEL_MID=y so if anyone _did_ somehow
use any of those functions in generic code, they'd probably be creating
compile problems.
Any chance you'd like to look a _bit_ more widely and just clean up all
of the unnecessary intel-mid.h #includes that are scattered around?
On 3/5/24 08:31, Andy Shevchenko wrote:
>> Any chance you'd like to look a _bit_ more widely and just clean up all
>> of the unnecessary intel-mid.h #includes that are scattered around?
> All relative patches just have been sent. They are independent, hence sent
> separately. Please, apply, what you can, if there is no objection.
Ahh, thanks for the context. Any chance you could share that up front
next time? ;)
I'll stick this in the x86 queue.
On Tue, Mar 05, 2024 at 08:34:59AM -0800, Dave Hansen wrote:
> On 3/5/24 08:31, Andy Shevchenko wrote:
> >> Any chance you'd like to look a _bit_ more widely and just clean up all
> >> of the unnecessary intel-mid.h #includes that are scattered around?
> > All relative patches just have been sent. They are independent, hence sent
> > separately. Please, apply, what you can, if there is no objection.
> Ahh, thanks for the context. Any chance you could share that up front
> next time? ;)
Hmm... I'm not sure how. If it's a cover letter, then it requires a series,
which seems an overkill, commenting on a single patch sounds a bit weird to
me.
> I'll stick this in the x86 queue.
Thank you!
--
With Best Regards,
Andy Shevchenko
On 3/5/24 08:36, Andy Shevchenko wrote:
>> Ahh, thanks for the context. Any chance you could share that up front
>> next time? ????
> Hmm... I'm not sure how. If it's a cover letter, then it requires a series,
> which seems an overkill, commenting on a single patch sounds a bit weird to
> me.
I honestly don't care how you do it. You could send all the patches in
a series and ask the individual maintainers to pick them up
individually. Or send cc all the maintainers and ask _one_ of them to
pick up all of the patches. Or just mention in the changelog of the
singleton patch that it's part of a (slightly) larger effort, then Link:
over to the other related ones.
Seriously, the only way to go wrong is to just pretend that this patch
*is* a singleton when it's not.
On Tue, Mar 05, 2024 at 08:43:47AM -0800, Dave Hansen wrote:
> On 3/5/24 08:36, Andy Shevchenko wrote:
> >> Ahh, thanks for the context. Any chance you could share that up front
> >> next time? ????
> > Hmm... I'm not sure how. If it's a cover letter, then it requires a series,
> > which seems an overkill, commenting on a single patch sounds a bit weird to
> > me.
>
> I honestly don't care how you do it. You could send all the patches in
> a series and ask the individual maintainers to pick them up
> individually. Or send cc all the maintainers and ask _one_ of them to
> pick up all of the patches. Or just mention in the changelog of the
> singleton patch that it's part of a (slightly) larger effort, then Link:
> over to the other related ones.
Got it.
> Seriously, the only way to go wrong is to just pretend that this patch
> *is* a singleton when it's not.
But technically speaking it is completely independent. TBH it is the _first_
time I ever got such a request from a maintainer. But okay, sending in a series
to be picked up separately sounds like in use: I have heard about such series
more than once.
--
With Best Regards,
Andy Shevchenko
On Tue, Mar 05, 2024 at 08:21:32AM -0800, Dave Hansen wrote:
> On 3/5/24 08:10, Andy Shevchenko wrote:
> > intel-mid.h is providing some core parts of the South Complex PM,
> > which are usually are not used by individual drivers. In particular,
> > this driver doesn't use it, so simply remove the unused header.
>
> Indeed. intel-mid.h provides a pretty small amount of stuff and it's
> included in quite a few random-looking spots. There's also gunk that's
> only compiled in if CONFIG_X86_INTEL_MID=y so if anyone _did_ somehow
> use any of those functions in generic code, they'd probably be creating
> compile problems.
>
> Any chance you'd like to look a _bit_ more widely and just clean up all
> of the unnecessary intel-mid.h #includes that are scattered around?
All relative patches just have been sent. They are independent, hence sent
separately. Please, apply, what you can, if there is no objection.
--
With Best Regards,
Andy Shevchenko
On Tue, Mar 05, 2024 at 06:36:43PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 05, 2024 at 08:34:59AM -0800, Dave Hansen wrote:
> > On 3/5/24 08:31, Andy Shevchenko wrote:
..
> > I'll stick this in the x86 queue.
>
> Thank you!
Any updates here?
--
With Best Regards,
Andy Shevchenko