x86/rtc: Remove unused intel-mid.h
PATCH 1/1 x86/rtc: Remove unused intel-mid.h
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.
--- arch/x86/kernel/rtc.c | 1 - 1 file changed, 1 deletion(-)
arch/x86/kernel/rtc.c +0 -1
@@ -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
Signature · 1 line
2.43.0.rc1.1.gbec44491f096
Quoted 3 lines · Andy Shevchenko
intel-mid.his 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?
Quoted 5 lines · Dave Hansen
Quoted 3 lines · Andy Shevchenko
intel-mid.his 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.
Quoted 8 lines
Indeed.
intel-mid.hprovides 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 ifCONFIG_X86_INTEL_MID=yso 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.
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 4 lines · Andy Shevchenko
Quoted 2 lines
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.
Quoted 8 lines · Dave Hansen
Quoted 4 lines · Andy Shevchenko
Quoted 2 lines
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.
Quoted 1 line
I'll stick this in the x86 queue.
Thank you!
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 5 lines · Andy Shevchenko
Quoted 2 lines
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.
Quoted 7 lines · Dave Hansen
Quoted 5 lines · Andy Shevchenko
Quoted 2 lines
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.
Quoted 6 lines
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.
Quoted 2 lines
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.
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 2 lines · Andy Shevchenko
Quoted 1 line · Dave Hansen
On 3/5/24 08:31, Andy Shevchenko wrote:
...
Quoted 3 lines
Quoted 1 line
I'll stick this in the x86 queue.
Thank you!
Any updates here?
Signature · 2 lines
With Best Regards, Andy Shevchenko