[PATCH v1 1/1] ASoC: madera: Replace kernel.h with the necessary inclusions
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 andriy.shevchenko@linux.intel.com --- 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
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 andriy.shevchenko@linux.intel.com
Reviewed-by: Richard Fitzgerald rf@opensource.cirrus.com
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 rf@opensource.cirrus.com
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
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 rf@opensource.cirrus.com
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 broonie@kernel.org 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 rf@opensource.cirrus.com
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?
On Mon, Jul 04, 2022 at 05:30:41PM +0200, Andy Shevchenko wrote:
On Mon, Jul 4, 2022 at 12:45 PM Mark Brown broonie@kernel.org 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 broonie@kernel.org 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 broonie@kernel.org 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?
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
participants (4)
-
Andy Shevchenko -
Andy Shevchenko -
Mark Brown -
Richard Fitzgerald