When kernel.h is used in the headers it adds a lot into dependency hell,
especially when there are circular dependencies are involved.
Replace kernel.h inclusion with the list of what is really being used.
Signed-off-by: Andy Shevchenko <[email protected]>
---
include/sound/madera-pdata.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/sound/madera-pdata.h b/include/sound/madera-pdata.h
index e3060f48f108..58398d80c3de 100644
--- a/include/sound/madera-pdata.h
+++ b/include/sound/madera-pdata.h
@@ -9,7 +9,7 @@
#ifndef MADERA_CODEC_PDATA_H
#define MADERA_CODEC_PDATA_H
-#include <linux/kernel.h>
+#include <linux/types.h>
#define MADERA_MAX_INPUT 6
#define MADERA_MAX_MUXED_CHANNELS 4
--
2.35.1
On 03/06/2022 18:07, Andy Shevchenko wrote:
> When kernel.h is used in the headers it adds a lot into dependency hell,
> especially when there are circular dependencies are involved.
>
> Replace kernel.h inclusion with the list of what is really being used.
>
> Signed-off-by: Andy Shevchenko <[email protected]>
> ---
Reviewed-by: Richard Fitzgerald <[email protected]>
On Mon, Jun 06, 2022 at 10:29:59AM +0100, Richard Fitzgerald wrote:
> On 03/06/2022 18:07, Andy Shevchenko wrote:
> > When kernel.h is used in the headers it adds a lot into dependency hell,
> > especially when there are circular dependencies are involved.
> >
> > Replace kernel.h inclusion with the list of what is really being used.
>
> Reviewed-by: Richard Fitzgerald <[email protected]>
Thanks!
It's a month passed without any other news about this patch.
Is this a problem in the MAINTAINERS database?
Who should take this?
+Cc: Liam, Mark
--
With Best Regards,
Andy Shevchenko
On Sun, Jul 03, 2022 at 06:36:48PM +0300, Andy Shevchenko wrote:
> On Mon, Jun 06, 2022 at 10:29:59AM +0100, Richard Fitzgerald wrote:
> > On 03/06/2022 18:07, Andy Shevchenko wrote:
> > > When kernel.h is used in the headers it adds a lot into dependency hell,
> > > especially when there are circular dependencies are involved.
> > > Replace kernel.h inclusion with the list of what is really being used.
> > Reviewed-by: Richard Fitzgerald <[email protected]>
> Thanks!
> It's a month passed without any other news about this patch.
> Is this a problem in the MAINTAINERS database?
> Who should take this?
> +Cc: Liam, Mark
If you needed to add me to the CC I've not seen the patch...
As documented in submitting-patches.rst please send patches to the
maintainers for the code you would like to change. The normal kernel
workflow is that people apply patches from their inboxes, if they aren't
copied they are likely to not see the patch at all and it is much more
difficult to apply patches.
Please don't send content free pings and please allow a reasonable time
for review. People get busy, go on holiday, attend conferences and so
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review. If there have been
review comments then people may be waiting for those to be addressed.
Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, so sending again is generally a better approach though there are
some other maintainers who like them - if in doubt look at how patches
for the subsystem are normally handled.
On Mon, Jul 4, 2022 at 12:45 PM Mark Brown <[email protected]> wrote:
>
> On Sun, Jul 03, 2022 at 06:36:48PM +0300, Andy Shevchenko wrote:
> > On Mon, Jun 06, 2022 at 10:29:59AM +0100, Richard Fitzgerald wrote:
> > > On 03/06/2022 18:07, Andy Shevchenko wrote:
>
> > > > When kernel.h is used in the headers it adds a lot into dependency hell,
> > > > especially when there are circular dependencies are involved.
>
> > > > Replace kernel.h inclusion with the list of what is really being used.
>
> > > Reviewed-by: Richard Fitzgerald <[email protected]>
>
> > Thanks!
>
> > It's a month passed without any other news about this patch.
> > Is this a problem in the MAINTAINERS database?
>
> > Who should take this?
>
> > +Cc: Liam, Mark
>
> If you needed to add me to the CC I've not seen the patch...
> for review. People get busy, go on holiday, attend conferences and so
The question here is about MAINTAINERS. That's why you are in Cc list.
Do we have an issue in MAINTAINERS that causes you being not see the
patch?
--
With Best Regards,
Andy Shevchenko
On Mon, Jul 04, 2022 at 05:30:41PM +0200, Andy Shevchenko wrote:
> On Mon, Jul 4, 2022 at 12:45 PM Mark Brown <[email protected]> wrote:
> > > +Cc: Liam, Mark
> > If you needed to add me to the CC I've not seen the patch...
> > for review. People get busy, go on holiday, attend conferences and so
> The question here is about MAINTAINERS. That's why you are in Cc list.
> Do we have an issue in MAINTAINERS that causes you being not see the
> patch?
I have no idea, all that's showing up in my inbox is these content free
pings. You'd have to ask whoever didn't send the patch to me.
On Mon, Jul 4, 2022 at 5:35 PM Mark Brown <[email protected]> wrote:
> On Mon, Jul 04, 2022 at 05:30:41PM +0200, Andy Shevchenko wrote:
> > On Mon, Jul 4, 2022 at 12:45 PM Mark Brown <[email protected]> wrote:
>
> > > > +Cc: Liam, Mark
>
> > > If you needed to add me to the CC I've not seen the patch...
> > > for review. People get busy, go on holiday, attend conferences and so
>
> > The question here is about MAINTAINERS. That's why you are in Cc list.
> > Do we have an issue in MAINTAINERS that causes you being not see the
> > patch?
>
> I have no idea, all that's showing up in my inbox is these content free
> pings. You'd have to ask whoever didn't send the patch to me.
Let me rephrase my question (it's not so related to this patch).
How does the ASoC works in terms of MAINTAINERS records?
I found that there are files that are related to the sound/soc/* one
way or another, but listed only in a certain record of MAINTAINERS
without being listed as part of ASoC record. Does it mean I have to
always remember to add ASoC maintainers to each patch that touches one
of such files and doesn't provide them? OR do we need to fix
MAINTAINERS for such files by listing them in the ASoC record?
--
With Best Regards,
Andy Shevchenko
On Mon, Jul 04, 2022 at 05:51:44PM +0200, Andy Shevchenko wrote:
> I found that there are files that are related to the sound/soc/* one
> way or another, but listed only in a certain record of MAINTAINERS
> without being listed as part of ASoC record. Does it mean I have to
> always remember to add ASoC maintainers to each patch that touches one
> of such files and doesn't provide them? OR do we need to fix
> MAINTAINERS for such files by listing them in the ASoC record?
Presumably one of those two will be required, yes.
On Fri, 3 Jun 2022 20:07:07 +0300, Andy Shevchenko wrote:
> When kernel.h is used in the headers it adds a lot into dependency hell,
> especially when there are circular dependencies are involved.
>
> Replace kernel.h inclusion with the list of what is really being used.
>
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: madera: Replace kernel.h with the necessary inclusions
commit: dcc165d6179c3934b93b8c3bffde1ed9710fd7ef
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark