linux-kernel - Re: [PATCH v6 1/2] ASoC: sunxi: Add Allwinner H6 Digital MIC driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20210817071220.idoxpwzbpemdjqdz@gilmour>
Date:   Tue, 17 Aug 2021 09:12:20 +0200
From:   Maxime Ripard <maxime@...no.tech>
To:     班涛 <fengzheng923@...il.com>
Cc:     lgirdwood@...il.com, Mark Brown <broonie@...nel.org>,
        perex@...ex.cz, tiwai@...e.com, wens@...e.org,
        jernej.skrabec@...il.com, p.zabel@...gutronix.de,
        Samuel Holland <samuel@...lland.org>, krzk@...nel.org,
        linux-kernel@...r.kernel.org, alsa-devel@...a-project.org,
        linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev
Subject: Re: [PATCH v6 1/2] ASoC: sunxi: Add Allwinner H6 Digital MIC driver

Hi,

On Sun, Aug 01, 2021 at 05:47:46PM +0800, 班涛 wrote:
> > > +     /* DMIC num is N+1 */
> > > +     regmap_update_bits(host->regmap, SUN50I_DMIC_CH_NUM,
> > > +                        SUN50I_DMIC_CH_NUM_N_MASK,
> > > +                        SUN50I_DMIC_CH_NUM_N(channels - 1));
> > > +     host->chan_en = (1 << channels) - 1;
> > > +     regmap_write(host->regmap, SUN50I_DMIC_HPF_CTRL, host->chan_en);
> >
> > Do we need to store the channels bitmask in the main structure? It looks
> > fairly easy to generate, so I guess we could just use a macro
> 
> I need to store channels bitmask and use it in sun50i_dmic_trigger function.

But you don't need it outside of hw_params. The channel setup is
typically done in hw_params, not in the trigger hook.

[...]

> > > +     /* Clocks */
> > > +     host->bus_clk = devm_clk_get(&pdev->dev, "bus");
> > > +     if (IS_ERR(host->bus_clk))
> > > +             return dev_err_probe(&pdev->dev, PTR_ERR(host->bus_clk),
> > > +                                  "failed to get bus clock.\n");
> > > +
> > > +     host->dmic_clk = devm_clk_get(&pdev->dev, "mod");
> > > +     if (IS_ERR(host->dmic_clk))
> > > +             return dev_err_probe(&pdev->dev, PTR_ERR(host->dmic_clk),
> > > +                                  "failed to get dmic clock.\n");
> > > +
> > > +     host->dma_params_rx.addr = res->start + SUN50I_DMIC_DATA;
> > > +     host->dma_params_rx.maxburst = 8;
> > > +
> > > +     platform_set_drvdata(pdev, host);
> > > +
> > > +     host->rst = devm_reset_control_get_optional_exclusive(&pdev->dev, NULL);
> > > +     if (IS_ERR(host->rst))
> > > +             return dev_err_probe(&pdev->dev, PTR_ERR(host->rst),
> > > +                                  "Failed to get reset.\n");
> >
> > Your binding states that the reset is mandatory so you don't need the
> > optional variant.
> >
> > > +     reset_control_deassert(host->rst);
> >
> > Can't this be moved to the runtime_pm hooks?
> 
> Is this necessary? I see that most of the driver files execute
> reset_control_deassert in the probe function, and reset_control_assert
> in the remove function.

Your driver seems to not rely on the fact that the device remains
powered between each run anyway, so yeah, that way you will completely
power it down.

> >
> > > +     ret = devm_snd_soc_register_component(&pdev->dev,
> > > +                             &sun50i_dmic_component, &sun50i_dmic_dai, 1);
> >
> > Your second line should be aligned on the opening parenthesis
> >
> > > +     if (ret)
> > > +             return dev_err_probe(&pdev->dev, ret,
> > > +                                  "failed to register component.\n");
> > > +
> > > +     pm_runtime_enable(&pdev->dev);
> > > +     if (!pm_runtime_enabled(&pdev->dev)) {
> > > +             ret = sun50i_dmic_runtime_resume(&pdev->dev);
> > > +             if (ret)
> > > +                     goto err_unregister;
> > > +     }
> >
> > We have a depends on PM on some drivers already, so I guess it would
> > just make sense to add one more here instead of dealing with whether
> > runtime_pm is compiled in or not.
> 
> I don't understand. I am referring to the sun4i-spdif.c file. Which
> driver files should I refer to?

That whole logic is there to enable the device is CONFIG_PM is not
enabled (and thus the calls to pm_runtime_* won't do anything).

Just add a depends on PM to your Kconfig entry, and call
pm_runtime_enable there.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)