Re: [PATCH] ASoC: atmel: ATMEL drivers depend on HAS

linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed

* Re: [PATCH] ASoC: atmel: ATMEL drivers depend on HAS_DMA
       [not found] <20210530204851.3372-1-rdunlap@infradead.org>
@ 2021-06-27 22:28 ` Randy Dunlap
  2021-06-28 13:02   ` Mark Brown
  0 siblings, 1 reply; 4+ messages in thread
From: Randy Dunlap @ 2021-06-27 22:28 UTC (permalink / raw)
  To: LKML
  Cc: Codrin Ciubotariu, alsa-devel, Liam Girdwood, Mark Brown,
	Bo Shen, Michał Mirosław, Alexandre Belloni

[adding LKML]

ping?

thanks.

On 5/30/21 1:48 PM, Randy Dunlap wrote:
> On a config (such as arch/sh/) which does not set HAS_DMA when MMU
> is not set, several ATMEL ASoC drivers select symbols that cause
> kconfig warnings. There is one "depends on HAS_DMA" here but several
> more are needed to prevent kconfig warnings since 'select' does not
> recognize any dependencies.
> 
> Fix the following kconfig warnings:
> 
> WARNING: unmet direct dependencies detected for SND_ATMEL_SOC_PDC
>   Depends on [n]: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && HAS_DMA [=n]
>   Selected by [m]:
>   - SND_ATMEL_SOC_SSC [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m]
>   - SND_ATMEL_SOC_SSC_PDC [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && ATMEL_SSC [=m]
> 
> WARNING: unmet direct dependencies detected for SND_ATMEL_SOC_SSC_PDC
>   Depends on [n]: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && ATMEL_SSC [=m] && HAS_DMA [=n]
>   Selected by [m]:
>   - SND_AT91_SOC_SAM9G20_WM8731 [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && (ARCH_AT91 || COMPILE_TEST [=y]) && ATMEL_SSC [=m] && SND_SOC_I2C_AND_SPI [=m]
> 
> WARNING: unmet direct dependencies detected for SND_ATMEL_SOC_SSC
>   Depends on [n]: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && HAS_DMA [=n]
>   Selected by [m]:
>   - SND_ATMEL_SOC_SSC_DMA [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && ATMEL_SSC [=m]
> 
> WARNING: unmet direct dependencies detected for SND_ATMEL_SOC_SSC_DMA
>   Depends on [n]: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && ATMEL_SSC [=m] && HAS_DMA [=n]
>   Selected by [m]:
>   - SND_ATMEL_SOC_WM8904 [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && (ARCH_AT91 || COMPILE_TEST [=y]) && ATMEL_SSC [=m] && I2C [=m]
>   - SND_AT91_SOC_SAM9X5_WM8731 [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && (ARCH_AT91 || COMPILE_TEST [=y]) && ATMEL_SSC [=m] && SND_SOC_I2C_AND_SPI [=m]
> 
> Fixes: 3951e4aae2ce ("ASoC: atmel-pcm: dma support based on pcm dmaengine")
> Fixes: 18291410557f ("ASoC: atmel: enable SOC_SSC_PDC and SOC_SSC_DMA in Kconfig")
> Fixes: 061981ff8cc8 ("ASoC: atmel: properly select dma driver state")
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> Cc: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
> Cc: alsa-devel@alsa-project.org
> Cc: Liam Girdwood <lgirdwood@gmail.com>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Bo Shen <voice.shen@atmel.com>
> Cc: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> ---
>  sound/soc/atmel/Kconfig |    6 ++++++
>  1 file changed, 6 insertions(+)
> 
> --- linux-next-20210528.orig/sound/soc/atmel/Kconfig
> +++ linux-next-20210528/sound/soc/atmel/Kconfig
> @@ -19,12 +19,14 @@ config SND_ATMEL_SOC_DMA
>  
>  config SND_ATMEL_SOC_SSC
>  	tristate
> +	depends on HAS_DMA
>  	select SND_ATMEL_SOC_DMA
>  	select SND_ATMEL_SOC_PDC
>  
>  config SND_ATMEL_SOC_SSC_PDC
>  	tristate "SoC PCM DAI support for AT91 SSC controller using PDC"
>  	depends on ATMEL_SSC
> +	depends on HAS_DMA
>  	select SND_ATMEL_SOC_PDC
>  	select SND_ATMEL_SOC_SSC
>  	help
> @@ -34,6 +36,7 @@ config SND_ATMEL_SOC_SSC_PDC
>  config SND_ATMEL_SOC_SSC_DMA
>  	tristate "SoC PCM DAI support for AT91 SSC controller using DMA"
>  	depends on ATMEL_SSC
> +	depends on HAS_DMA
>  	select SND_ATMEL_SOC_DMA
>  	select SND_ATMEL_SOC_SSC
>  	help
> @@ -44,6 +47,7 @@ config SND_AT91_SOC_SAM9G20_WM8731
>  	tristate "SoC Audio support for WM8731-based At91sam9g20 evaluation board"
>  	depends on ARCH_AT91 || COMPILE_TEST
>  	depends on ATMEL_SSC && SND_SOC_I2C_AND_SPI
> +	depends on HAS_DMA
>  	select SND_ATMEL_SOC_SSC_PDC
>  	select SND_SOC_WM8731
>  	help
> @@ -54,6 +58,7 @@ config SND_ATMEL_SOC_WM8904
>  	tristate "Atmel ASoC driver for boards using WM8904 codec"
>  	depends on ARCH_AT91 || COMPILE_TEST
>  	depends on ATMEL_SSC && I2C
> +	depends on HAS_DMA
>  	select SND_ATMEL_SOC_SSC_DMA
>  	select SND_SOC_WM8904
>  	help
> @@ -64,6 +69,7 @@ config SND_AT91_SOC_SAM9X5_WM8731
>  	tristate "SoC Audio support for WM8731-based at91sam9x5 board"
>  	depends on ARCH_AT91 || COMPILE_TEST
>  	depends on ATMEL_SSC && SND_SOC_I2C_AND_SPI
> +	depends on HAS_DMA
>  	select SND_ATMEL_SOC_SSC_DMA
>  	select SND_SOC_WM8731
>  	help
> 


-- 
~Randy
Reported-by: Randy Dunlap <rdunlap@infradead.org>
https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] ASoC: atmel: ATMEL drivers depend on HAS_DMA
  2021-06-27 22:28 ` [PATCH] ASoC: atmel: ATMEL drivers depend on HAS_DMA Randy Dunlap
@ 2021-06-28 13:02   ` Mark Brown
  2021-06-28 16:03     ` Randy Dunlap
  0 siblings, 1 reply; 4+ messages in thread
From: Mark Brown @ 2021-06-28 13:02 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: LKML, Codrin Ciubotariu, alsa-devel, Liam Girdwood, Bo Shen,
	Michał Mirosław, Alexandre Belloni

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]

On Sun, Jun 27, 2021 at 03:28:59PM -0700, Randy Dunlap wrote:
> [adding LKML]
> 
> ping?

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] ASoC: atmel: ATMEL drivers depend on HAS_DMA
  2021-06-28 13:02   ` Mark Brown
@ 2021-06-28 16:03     ` Randy Dunlap
  2021-06-28 16:35       ` Mark Brown
  0 siblings, 1 reply; 4+ messages in thread
From: Randy Dunlap @ 2021-06-28 16:03 UTC (permalink / raw)
  To: Mark Brown
  Cc: LKML, Codrin Ciubotariu, alsa-devel, Liam Girdwood, Bo Shen,
	Michał Mirosław, Alexandre Belloni

On 6/28/21 6:02 AM, Mark Brown wrote:
> On Sun, Jun 27, 2021 at 03:28:59PM -0700, Randy Dunlap wrote:
>> [adding LKML]
>>
>> ping?
> 
> 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.

a. The entire email/patch was there. Should I put the ping _after_ the patch?
Would that help?

b. What do you consider a reasonable time?  The patch was sent 28 days
prior to this gentle ping.

> 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.
> 

Yes, I shall resend the patch. Thanks.

-- 
~Randy


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] ASoC: atmel: ATMEL drivers depend on HAS_DMA
  2021-06-28 16:03     ` Randy Dunlap
@ 2021-06-28 16:35       ` Mark Brown
  0 siblings, 0 replies; 4+ messages in thread
From: Mark Brown @ 2021-06-28 16:35 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: LKML, Codrin Ciubotariu, alsa-devel, Liam Girdwood, Bo Shen,
	Michał Mirosław, Alexandre Belloni

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]

On Mon, Jun 28, 2021 at 09:03:25AM -0700, Randy Dunlap wrote:
> On 6/28/21 6:02 AM, Mark Brown wrote:

> > 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 

> a. The entire email/patch was there. Should I put the ping _after_ the patch?
> Would that help?

Never send content free pings of any kind.  There's an "and" there.
Quoted patches can't be applied.

> b. What do you consider a reasonable time?  The patch was sent 28 days
> prior to this gentle ping.

As the mail you are replying to suggests this depends on the patch, some
things are more urgent than others, and in any case like I say content
free pings no matter how content free are just nose.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-06-28 16:36 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20210530204851.3372-1-rdunlap@infradead.org>
2021-06-27 22:28 ` [PATCH] ASoC: atmel: ATMEL drivers depend on HAS_DMA Randy Dunlap
2021-06-28 13:02   ` Mark Brown
2021-06-28 16:03     ` Randy Dunlap
2021-06-28 16:35       ` Mark Brown

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).