June 2019 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] aplay: fix memory leak when setup_chmap() fail
by GitHub pull_request - opened 23 Jun '19

23 Jun '19

alsa-project/alsa-utils pull request #21 was opened from chunxuxiao: setup_chmap() will return with error number if hw_map calloc fail or channels doesn't match with hw_params, but memory free was ignored when error occurs. this summit has been Reviewed-by @takaswie Request URL : https://github.com/alsa-project/alsa-utils/pull/21 Patch URL : https://github.com/alsa-project/alsa-utils/pull/21.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

[alsa-devel] [PATCH 1/5] sound: SoC: sof: no need to check return value of debugfs_create functions
by Greg Kroah-Hartman 23 Jun '19

23 Jun '19

When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Cc: Liam Girdwood <lgirdwood(a)gmail.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: Jaroslav Kysela <perex(a)perex.cz> Cc: Takashi Iwai <tiwai(a)suse.com> Cc: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Cc: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Cc: alsa-devel(a)alsa-project.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/soc/sof/debug.c | 32 ++++++++++---------------------- sound/soc/sof/sof-priv.h | 1 - sound/soc/sof/trace.c | 9 ++------- 3 files changed, 12 insertions(+), 30 deletions(-) diff --git a/sound/soc/sof/debug.c b/sound/soc/sof/debug.c index 55f1d808dba0..429daa0dc9bf 100644 --- a/sound/soc/sof/debug.c +++ b/sound/soc/sof/debug.c @@ -77,8 +77,7 @@ static ssize_t sof_dfsentry_read(struct file *file, char __user *buffer, if (!pm_runtime_active(sdev->dev) && dfse->access_type == SOF_DEBUGFS_ACCESS_D0_ONLY) { dev_err(sdev->dev, - "error: debugfs entry %s cannot be read in DSP D3\n", - dfse->dfsentry->d_name.name); + "error: debugfs entry cannot be read in DSP D3\n"); kfree(buf); return -EINVAL; } @@ -142,17 +141,11 @@ int snd_sof_debugfs_io_item(struct snd_sof_dev *sdev, } #endif - dfse->dfsentry = debugfs_create_file(name, 0444, sdev->debugfs_root, - dfse, &sof_dfs_fops); - if (!dfse->dfsentry) { - /* can't rely on debugfs, only log error and keep going */ - dev_err(sdev->dev, "error: cannot create debugfs entry %s\n", - name); - } else { - /* add to dfsentry list */ - list_add(&dfse->list, &sdev->dfsentry_list); + debugfs_create_file(name, 0444, sdev->debugfs_root, dfse, + &sof_dfs_fops); - } + /* add to dfsentry list */ + list_add(&dfse->list, &sdev->dfsentry_list); return 0; } @@ -177,16 +170,11 @@ int snd_sof_debugfs_buf_item(struct snd_sof_dev *sdev, dfse->size = size; dfse->sdev = sdev; - dfse->dfsentry = debugfs_create_file(name, 0444, sdev->debugfs_root, - dfse, &sof_dfs_fops); - if (!dfse->dfsentry) { - /* can't rely on debugfs, only log error and keep going */ - dev_err(sdev->dev, "error: cannot create debugfs entry %s\n", - name); - } else { - /* add to dfsentry list */ - list_add(&dfse->list, &sdev->dfsentry_list); - } + debugfs_create_file(name, 0444, sdev->debugfs_root, dfse, + &sof_dfs_fops); + + /* add to dfsentry list */ + list_add(&dfse->list, &sdev->dfsentry_list); return 0; } diff --git a/sound/soc/sof/sof-priv.h b/sound/soc/sof/sof-priv.h index 1e85d6f9c5c3..d0f7cc3ddcbf 100644 --- a/sound/soc/sof/sof-priv.h +++ b/sound/soc/sof/sof-priv.h @@ -217,7 +217,6 @@ enum sof_debugfs_access_type { /* FS entry for debug files that can expose DSP memories, registers */ struct snd_sof_dfsentry { - struct dentry *dfsentry; size_t size; enum sof_dfsentry_type type; /* diff --git a/sound/soc/sof/trace.c b/sound/soc/sof/trace.c index d588e4b70fad..2986d9a563b0 100644 --- a/sound/soc/sof/trace.c +++ b/sound/soc/sof/trace.c @@ -119,13 +119,8 @@ static int trace_debugfs_create(struct snd_sof_dev *sdev) dfse->size = sdev->dmatb.bytes; dfse->sdev = sdev; - dfse->dfsentry = debugfs_create_file("trace", 0444, sdev->debugfs_root, - dfse, &sof_dfs_trace_fops); - if (!dfse->dfsentry) { - /* can't rely on debugfs, only log error and keep going */ - dev_err(sdev->dev, - "error: cannot create debugfs entry for trace\n"); - } + debugfs_create_file("trace", 0444, sdev->debugfs_root, dfse, + &sof_dfs_trace_fops); return 0; } -- 2.22.0

5 20

[alsa-devel] aplay: fix a possible memory leak
by GitHub pull_request - opened 23 Jun '19

23 Jun '19

alsa-project/alsa-utils pull request #20 was opened from chunxuxiao: Fix a possible memory leak in function setup_chmap(void). Memory free was ignored when the function return an error. Request URL : https://github.com/alsa-project/alsa-utils/pull/20 Patch URL : https://github.com/alsa-project/alsa-utils/pull/20.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

[alsa-devel] [PATCH 0/8] ALSA: firewire: minor code refactoring and bug
by Takashi Sakamoto 21 Jun '19

21 Jun '19

Hi, During a couple of weeks, I added code refactoring to all of drivers in ALSA firewire stack. But I can find some rooms for additional code refactoring and some bugs. This patchset is for them. Takashi Sakamoto (8): ALSA: firewire-tascam: unify stop and release method for duplex streams ALSA: fireface: unify stop and release method for duplex streams ALSA: firewire-motu: unify stop and release method for duplex streams ALSA: firewire-digi00x: unify stop and release method for duplex streams ALSA: dice: unify stop and release method for duplex streams ALSA: bebob: ensure to release isochronous resources in pcm.hw_params callback ALSA: fireworks: ensure to release isochronous resources in pcm.hw_params callback ALSA: oxfw: ensure to release isochronous resources in pcm.hw_params callback sound/firewire/bebob/bebob_stream.c | 3 +++ sound/firewire/dice/dice-midi.c | 1 - sound/firewire/dice/dice-pcm.c | 1 - sound/firewire/dice/dice-stream.c | 8 ++------ sound/firewire/dice/dice.h | 1 - sound/firewire/digi00x/digi00x-midi.c | 1 - sound/firewire/digi00x/digi00x-pcm.c | 1 - sound/firewire/digi00x/digi00x-stream.c | 14 +++++--------- sound/firewire/digi00x/digi00x.h | 1 - sound/firewire/fireface/ff-pcm.c | 1 - sound/firewire/fireface/ff-stream.c | 14 +++++--------- sound/firewire/fireface/ff.h | 1 - sound/firewire/fireworks/fireworks_stream.c | 3 +++ sound/firewire/motu/motu-midi.c | 1 - sound/firewire/motu/motu-pcm.c | 1 - sound/firewire/motu/motu-stream.c | 14 +++++--------- sound/firewire/motu/motu.h | 1 - sound/firewire/oxfw/oxfw-stream.c | 2 ++ sound/firewire/tascam/tascam-pcm.c | 1 - sound/firewire/tascam/tascam-stream.c | 14 +++++--------- sound/firewire/tascam/tascam.h | 1 - 21 files changed, 30 insertions(+), 55 deletions(-) -- 2.20.1

2 9

[alsa-devel] Question about pinctrl_pm_select_xxx()
by Kuninori Morimoto 21 Jun '19

21 Jun '19

Hi ALSA ML I noticed pinctrl_pm_select_xxx() unbalance. I think these are paired function pinctrl_pm_select_default_state() pinctrl_pm_select_sleep_state() I can find pinctrl_pm_select_sleep_state() for component at snd_soc_suspend(). int snd_soc_suspend(struct device *dev) { ... if (!snd_soc_component_is_suspended(component)) { switch (snd_soc_dapm_get_bias_level(dapm)) { ... case SND_SOC_BIAS_OFF: ... /* deactivate pins to sleep state */ => pinctrl_pm_select_sleep_state(component->dev); break; } ... } ... } But, I can't find its paired pinctrl_pm_select_default_state(). It looks strange for me. Is this really needed ?? And about pinctrl_pm_select_xxx() for CPU/Codec DAI, Many places are calling pinctrl_pm_select_xxx() for both CPU/Codec. snd_soc_suspend() cares only CPU only, but snd_soc_resume() cares both. Is this bug ?? int snd_soc_suspend(struct device *dev) { ... for_each_card_rtds(card, rtd) { /* deactivate pins to sleep state */ => pinctrl_pm_select_sleep_state(cpu_dai->dev); } ... } int snd_soc_resume(struct device *dev) { ... for_each_card_rtds(card, rtd) { ... if (cpu_dai->active) => pinctrl_pm_select_default_state(cpu_dai->dev); for_each_rtd_codec_dai(rtd, i, codec_dai) { if (codec_dai->active) => pinctrl_pm_select_default_state(codec_dai->dev); } } ... } Thank you for your help !! Best regards --- Kuninori Morimoto

2 6

[alsa-devel] [PATCH] ASoC: rk3399_gru_sound: Support 32, 44.1 and 88.2 kHz sample rates
by Enric Balletbo i Serra 20 Jun '19

20 Jun '19

According to the datasheet the max98357a also supports 32, 44.1 and 88.2 kHz sample rate. This support was also introduced recently by commit fdf34366d324 ("ASoC: max98357a: add missing supported rates"). This patch adds support for these rates also for the machine driver so we get rid of the errors like the below and we are able to play files using these sample rates. rk3399-gru-sound sound: rockchip_sound_max98357a_hw_params() doesn't support this sample rate: 44100 rk3399-gru-sound sound: ASoC: machine hw_params failed: -22 Signed-off-by: Enric Balletbo i Serra <enric.balletbo(a)collabora.com> --- sound/soc/rockchip/rk3399_gru_sound.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/soc/rockchip/rk3399_gru_sound.c b/sound/soc/rockchip/rk3399_gru_sound.c index 3d0cc6e90d7b..8dfe1a560e42 100644 --- a/sound/soc/rockchip/rk3399_gru_sound.c +++ b/sound/soc/rockchip/rk3399_gru_sound.c @@ -59,7 +59,10 @@ static int rockchip_sound_max98357a_hw_params(struct snd_pcm_substream *substrea switch (params_rate(params)) { case 8000: case 16000: + case 32000: + case 44100: case 48000: + case 88200: case 96000: mclk = params_rate(params) * SOUND_FS; break; -- 2.20.1

3 2

[alsa-devel] [PATCH] ASoC: stm32: dfsdm: add 16 bits audio record support
by Olivier Moysan 20 Jun '19

20 Jun '19

Add support of audio 16 bits format record to STM32 DFSDM driver. Signed-off-by: Olivier Moysan <olivier.moysan(a)st.com> --- sound/soc/stm/stm32_adfsdm.c | 49 +++++++++++++++++++++++++++++++++++--------- 1 file changed, 39 insertions(+), 10 deletions(-) diff --git a/sound/soc/stm/stm32_adfsdm.c b/sound/soc/stm/stm32_adfsdm.c index cc517e007039..3c9a9deec9af 100644 --- a/sound/soc/stm/stm32_adfsdm.c +++ b/sound/soc/stm/stm32_adfsdm.c @@ -45,7 +45,7 @@ struct stm32_adfsdm_priv { static const struct snd_pcm_hardware stm32_adfsdm_pcm_hw = { .info = SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_PAUSE, - .formats = SNDRV_PCM_FMTBIT_S32_LE, + .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S32_LE, .rate_min = 8000, .rate_max = 32000, @@ -141,7 +141,8 @@ static const struct snd_soc_dai_driver stm32_adfsdm_dai = { .capture = { .channels_min = 1, .channels_max = 1, - .formats = SNDRV_PCM_FMTBIT_S32_LE, + .formats = SNDRV_PCM_FMTBIT_S16_LE | + SNDRV_PCM_FMTBIT_S32_LE, .rates = (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_16000 | SNDRV_PCM_RATE_32000), }, @@ -152,30 +153,58 @@ static const struct snd_soc_component_driver stm32_adfsdm_dai_component = { .name = "stm32_dfsdm_audio", }; +static void memcpy_32to16(void *dest, const void *src, size_t n) +{ + unsigned int i = 0; + u16 *d = (u16 *)dest, *s = (u16 *)src; + + s++; + for (i = n; i > 0; i--) { + *d++ = *s++; + s++; + } +} + static int stm32_afsdm_pcm_cb(const void *data, size_t size, void *private) { struct stm32_adfsdm_priv *priv = private; struct snd_soc_pcm_runtime *rtd = priv->substream->private_data; u8 *pcm_buff = priv->pcm_buff; u8 *src_buff = (u8 *)data; - unsigned int buff_size = snd_pcm_lib_buffer_bytes(priv->substream); - unsigned int period_size = snd_pcm_lib_period_bytes(priv->substream); unsigned int old_pos = priv->pos; - unsigned int cur_size = size; + size_t buff_size = snd_pcm_lib_buffer_bytes(priv->substream); + size_t period_size = snd_pcm_lib_period_bytes(priv->substream); + size_t cur_size, src_size = size; + snd_pcm_format_t format = priv->substream->runtime->format; + + if (format == SNDRV_PCM_FORMAT_S16_LE) + src_size >>= 1; + cur_size = src_size; dev_dbg(rtd->dev, "%s: buff_add :%pK, pos = %d, size = %zu\n", - __func__, &pcm_buff[priv->pos], priv->pos, size); + __func__, &pcm_buff[priv->pos], priv->pos, src_size); - if ((priv->pos + size) > buff_size) { - memcpy(&pcm_buff[priv->pos], src_buff, buff_size - priv->pos); + if ((priv->pos + src_size) > buff_size) { + if (format == SNDRV_PCM_FORMAT_S16_LE) + memcpy_32to16(&pcm_buff[priv->pos], src_buff, + buff_size - priv->pos); + else + memcpy(&pcm_buff[priv->pos], src_buff, + buff_size - priv->pos); cur_size -= buff_size - priv->pos; priv->pos = 0; } - memcpy(&pcm_buff[priv->pos], &src_buff[size - cur_size], cur_size); + if (format == SNDRV_PCM_FORMAT_S16_LE) + memcpy_32to16(&pcm_buff[priv->pos], + &src_buff[src_size - cur_size], cur_size); + else + memcpy(&pcm_buff[priv->pos], &src_buff[src_size - cur_size], + cur_size); + priv->pos = (priv->pos + cur_size) % buff_size; - if (cur_size != size || (old_pos && (old_pos % period_size < size))) + if (cur_size != src_size || (old_pos && (old_pos % period_size < size))) snd_pcm_period_elapsed(priv->substream); return 0; -- 2.7.4

2 1

[alsa-devel] [PATCH 0/2] ASoC: pcm3168a: Enable multiple digital port usage
by Peter Ujfalusi 20 Jun '19

20 Jun '19

Hi, On my board the pcm3168a's DIN1/2/3/4 and DOUT1/2/3 is connected to separate McASP serializers. I can run the audio in DIN1/DOUT1 mode (DSP_A, and switching between TDM and normal mode), but I need to run the codec in multi DIN/DOUT mode which was not possible as the driver is hardwired to DIN1/DOUT1 mode. Use the set_tdm_slots we get information on the number of slots per FS so we can use this to decide if we need to use multiple digital ports in parallel or to use single ones in TDM mode. The default mode remains DIN1/DOUT1. Regards, Peter --- Peter Ujfalusi (2): ASoC: pcm3168a: Rename min_frame_size to slot_width ASoC: pcm3168a: Add support for multi DIN/DOUT with TDM slots parameter sound/soc/codecs/pcm3168a.c | 41 ++++++++++++++++++++++++++----------- 1 file changed, 29 insertions(+), 12 deletions(-) -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

2 3

[alsa-devel] [PATCH 0/2] ASoC: ti: davinci-mcasp: Fixes for multi serializer setup
by Peter Ujfalusi 20 Jun '19

20 Jun '19

Hi, Now that I have access to a board with codec using multiple digital inputs and outputs (pcm3168a) I found these two issues with the McASP driver: - unused pins needs to be set as inactive - the tdm mask is not set correctly when multiple serializers are enabled and needed Regards, Peter --- Peter Ujfalusi (2): ASoC: ti: davinci-mcasp: Set unused serializers as INACTIVE ASoC: ti: davinci-mcasp: Fix slot mask settings when using multiple AXRs sound/soc/ti/davinci-mcasp.c | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

2 4

Re: [alsa-devel] [PATCH v2 02/10] mfd / platform: cros_ec: Move cros-ec core driver out from MFD
by Chanwoo Choi 20 Jun '19

20 Jun '19

Hi Enric, For extcon parth, Acked-by: Chanwoo Choi <cw00.choi(a)samsung.com> Best Regards, Chanwoo Choi On 19. 6. 15. 오전 1:36, Enric Balletbo i Serra wrote: > Now, the ChromeOS EC core driver has nothing related to an MFD device, so > move that driver from the MFD subsystem to the platform/chrome subsystem. > > Signed-off-by: Enric Balletbo i Serra <enric.balletbo(a)collabora.com> > Acked-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> > Acked-by: Thierry Reding <thierry.reding(a)gmail.com> > Acked-by: Mark Brown <broonie(a)kernel.org> > Acked-by: Wolfram Sang <wsa(a)the-dreams.de> > Acked-by: Neil Armstrong <narmstrong(a)baylibre.com> > Acked-by: Alexandre Belloni <alexandre.belloni(a)bootlin.com> > Acked-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> > Acked-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com> > Acked-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> > Acked-by: Sebastian Reichel <sebastian.reichel(a)collabora.com> > --- > > Changes in v2: None > > drivers/extcon/Kconfig | 2 +- > drivers/hid/Kconfig | 2 +- > drivers/i2c/busses/Kconfig | 2 +- > drivers/iio/common/cros_ec_sensors/Kconfig | 2 +- > drivers/input/keyboard/Kconfig | 2 +- > drivers/media/platform/Kconfig | 3 +-- > drivers/mfd/Kconfig | 14 +------------- > drivers/mfd/Makefile | 2 -- > drivers/platform/chrome/Kconfig | 21 +++++++++++++++++---- > drivers/platform/chrome/Makefile | 1 + > drivers/{mfd => platform/chrome}/cros_ec.c | 0 > drivers/power/supply/Kconfig | 2 +- > drivers/pwm/Kconfig | 2 +- > drivers/rtc/Kconfig | 2 +- > sound/soc/qcom/Kconfig | 2 +- > 15 files changed, 29 insertions(+), 30 deletions(-) > rename drivers/{mfd => platform/chrome}/cros_ec.c (100%) > > diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig > index de06fafb52ff..5b0996b10d40 100644 > --- a/drivers/extcon/Kconfig > +++ b/drivers/extcon/Kconfig > @@ -168,7 +168,7 @@ config EXTCON_USB_GPIO > > config EXTCON_USBC_CROS_EC > tristate "ChromeOS Embedded Controller EXTCON support" > - depends on MFD_CROS_EC > + depends on CROS_EC > help > Say Y here to enable USB Type C cable detection extcon support when > using Chrome OS EC based USB Type-C ports. > diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig > index c3c390ca3690..b8022c158cb7 100644 > --- a/drivers/hid/Kconfig > +++ b/drivers/hid/Kconfig > @@ -375,7 +375,7 @@ config HOLTEK_FF > > config HID_GOOGLE_HAMMER > tristate "Google Hammer Keyboard" > - depends on USB_HID && LEDS_CLASS && MFD_CROS_EC > + depends on USB_HID && LEDS_CLASS && CROS_EC > ---help--- > Say Y here if you have a Google Hammer device. > > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig > index 26186439db6b..f2c2ab7eeffa 100644 > --- a/drivers/i2c/busses/Kconfig > +++ b/drivers/i2c/busses/Kconfig > @@ -1335,7 +1335,7 @@ config I2C_SIBYTE > > config I2C_CROS_EC_TUNNEL > tristate "ChromeOS EC tunnel I2C bus" > - depends on MFD_CROS_EC > + depends on CROS_EC > help > If you say yes here you get an I2C bus that will tunnel i2c commands > through to the other side of the ChromeOS EC to the i2c bus > diff --git a/drivers/iio/common/cros_ec_sensors/Kconfig b/drivers/iio/common/cros_ec_sensors/Kconfig > index 135f6825903f..c7d5b140491f 100644 > --- a/drivers/iio/common/cros_ec_sensors/Kconfig > +++ b/drivers/iio/common/cros_ec_sensors/Kconfig > @@ -3,7 +3,7 @@ > # > config IIO_CROS_EC_SENSORS_CORE > tristate "ChromeOS EC Sensors Core" > - depends on SYSFS && MFD_CROS_EC > + depends on SYSFS && CROS_EC > select IIO_BUFFER > select IIO_TRIGGERED_BUFFER > help > diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig > index 82398827b64f..fb843b56d439 100644 > --- a/drivers/input/keyboard/Kconfig > +++ b/drivers/input/keyboard/Kconfig > @@ -728,7 +728,7 @@ config KEYBOARD_W90P910 > config KEYBOARD_CROS_EC > tristate "ChromeOS EC keyboard" > select INPUT_MATRIXKMAP > - depends on MFD_CROS_EC > + depends on CROS_EC > help > Say Y here to enable the matrix keyboard used by ChromeOS devices > and implemented on the ChromeOS EC. You must enable one bus option > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig > index 011c1c2fcf19..9883526c5ff0 100644 > --- a/drivers/media/platform/Kconfig > +++ b/drivers/media/platform/Kconfig > @@ -557,10 +557,9 @@ if CEC_PLATFORM_DRIVERS > > config VIDEO_CROS_EC_CEC > tristate "ChromeOS EC CEC driver" > - depends on MFD_CROS_EC > + depends on CROS_EC > select CEC_CORE > select CEC_NOTIFIER > - select CHROME_PLATFORMS > select CROS_EC_PROTO > help > If you say yes here you will get support for the > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index 294d9567cc71..5bcf0af6471d 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -210,21 +210,9 @@ config MFD_AXP20X_RSB > components like regulators or the PEK (Power Enable Key) under the > corresponding menus. > > -config MFD_CROS_EC > - tristate "ChromeOS Embedded Controller" > - select MFD_CORE > - select CHROME_PLATFORMS > - select CROS_EC_PROTO > - depends on X86 || ARM || ARM64 || COMPILE_TEST > - help > - If you say Y here you get support for the ChromeOS Embedded > - Controller (EC) providing keyboard, battery and power services. > - You also need to enable the driver for the bus you are using. The > - protocol for talking to the EC is defined by the bus driver. > - > config MFD_CROS_EC_CHARDEV > tristate "Chrome OS Embedded Controller userspace device interface" > - depends on MFD_CROS_EC > + depends on CROS_EC > ---help--- > This driver adds support to talk with the ChromeOS EC from userspace. > > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > index 52b1a90ff515..32327dc6bb45 100644 > --- a/drivers/mfd/Makefile > +++ b/drivers/mfd/Makefile > @@ -13,8 +13,6 @@ obj-$(CONFIG_MFD_ASIC3) += asic3.o tmio_core.o > obj-$(CONFIG_ARCH_BCM2835) += bcm2835-pm.o > obj-$(CONFIG_MFD_BCM590XX) += bcm590xx.o > obj-$(CONFIG_MFD_BD9571MWV) += bd9571mwv.o > -cros_ec_core-objs := cros_ec.o > -obj-$(CONFIG_MFD_CROS_EC) += cros_ec_core.o > obj-$(CONFIG_MFD_CROS_EC_CHARDEV) += cros_ec_dev.o > obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o > > diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig > index 997317d2f2b9..1e7a10500b3f 100644 > --- a/drivers/platform/chrome/Kconfig > +++ b/drivers/platform/chrome/Kconfig > @@ -49,9 +49,22 @@ config CHROMEOS_TBMC > To compile this driver as a module, choose M here: the > module will be called chromeos_tbmc. > > +config CROS_EC > + tristate "ChromeOS Embedded Controller" > + select CROS_EC_PROTO > + depends on X86 || ARM || ARM64 || COMPILE_TEST > + help > + If you say Y here you get support for the ChromeOS Embedded > + Controller (EC) providing keyboard, battery and power services. > + You also need to enable the driver for the bus you are using. The > + protocol for talking to the EC is defined by the bus driver. > + > + To compile this driver as a module, choose M here: the > + module will be called cros_ec. > + > config CROS_EC_I2C > tristate "ChromeOS Embedded Controller (I2C)" > - depends on MFD_CROS_EC && I2C > + depends on CROS_EC && I2C > > help > If you say Y here, you get support for talking to the ChromeOS > @@ -61,7 +74,7 @@ config CROS_EC_I2C > > config CROS_EC_RPMSG > tristate "ChromeOS Embedded Controller (rpmsg)" > - depends on MFD_CROS_EC && RPMSG && OF > + depends on CROS_EC && RPMSG && OF > help > If you say Y here, you get support for talking to the ChromeOS EC > through rpmsg. This uses a simple byte-level protocol with a > @@ -73,7 +86,7 @@ config CROS_EC_RPMSG > > config CROS_EC_SPI > tristate "ChromeOS Embedded Controller (SPI)" > - depends on MFD_CROS_EC && SPI > + depends on CROS_EC && SPI > > ---help--- > If you say Y here, you get support for talking to the ChromeOS EC > @@ -83,7 +96,7 @@ config CROS_EC_SPI > > config CROS_EC_LPC > tristate "ChromeOS Embedded Controller (LPC)" > - depends on MFD_CROS_EC && ACPI && (X86 || COMPILE_TEST) > + depends on CROS_EC && ACPI && (X86 || COMPILE_TEST) > help > If you say Y here, you get support for talking to the ChromeOS EC > over an LPC bus. This uses a simple byte-level protocol with a > diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile > index 1b2f1dcfcd5c..f69e0be98bd6 100644 > --- a/drivers/platform/chrome/Makefile > +++ b/drivers/platform/chrome/Makefile > @@ -6,6 +6,7 @@ CFLAGS_cros_ec_trace.o:= -I$(src) > obj-$(CONFIG_CHROMEOS_LAPTOP) += chromeos_laptop.o > obj-$(CONFIG_CHROMEOS_PSTORE) += chromeos_pstore.o > obj-$(CONFIG_CHROMEOS_TBMC) += chromeos_tbmc.o > +obj-$(CONFIG_CROS_EC) += cros_ec.o > obj-$(CONFIG_CROS_EC_I2C) += cros_ec_i2c.o > obj-$(CONFIG_CROS_EC_RPMSG) += cros_ec_rpmsg.o > obj-$(CONFIG_CROS_EC_SPI) += cros_ec_spi.o > diff --git a/drivers/mfd/cros_ec.c b/drivers/platform/chrome/cros_ec.c > similarity index 100% > rename from drivers/mfd/cros_ec.c > rename to drivers/platform/chrome/cros_ec.c > diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig > index 26dacdab03cc..4c60cf22dbd7 100644 > --- a/drivers/power/supply/Kconfig > +++ b/drivers/power/supply/Kconfig > @@ -655,7 +655,7 @@ config CHARGER_RT9455 > > config CHARGER_CROS_USBPD > tristate "ChromeOS EC based USBPD charger" > - depends on MFD_CROS_EC > + depends on CROS_EC > default n > help > Say Y here to enable ChromeOS EC based USBPD charger > diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig > index 1311b54089be..a7edd9cc35eb 100644 > --- a/drivers/pwm/Kconfig > +++ b/drivers/pwm/Kconfig > @@ -144,7 +144,7 @@ config PWM_CRC > > config PWM_CROS_EC > tristate "ChromeOS EC PWM driver" > - depends on MFD_CROS_EC > + depends on CROS_EC > help > PWM driver for exposing a PWM attached to the ChromeOS Embedded > Controller. > diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig > index 7b8e156dbf38..a4ed24b6ecdf 100644 > --- a/drivers/rtc/Kconfig > +++ b/drivers/rtc/Kconfig > @@ -1264,7 +1264,7 @@ config RTC_DRV_ZYNQMP > > config RTC_DRV_CROS_EC > tristate "Chrome OS EC RTC driver" > - depends on MFD_CROS_EC > + depends on CROS_EC > help > If you say yes here you will get support for the > Chrome OS Embedded Controller's RTC. > diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig > index b1764af858ba..34636f5b2cd5 100644 > --- a/sound/soc/qcom/Kconfig > +++ b/sound/soc/qcom/Kconfig > @@ -98,7 +98,7 @@ config SND_SOC_MSM8996 > > config SND_SOC_SDM845 > tristate "SoC Machine driver for SDM845 boards" > - depends on QCOM_APR && MFD_CROS_EC && I2C > + depends on QCOM_APR && CROS_EC && I2C > select SND_SOC_QDSP6 > select SND_SOC_QCOM_COMMON > select SND_SOC_RT5663 > -- Best Regards, Chanwoo Choi Samsung Electronics

1 0