From: Krzysztof Kozlowski <krzk@kernel.org>
To: Harendra Gautam <harendra.gautam@oss.qualcomm.com>,
Srinivas Kandagatla <srini@kernel.org>
Cc: Mark Brown <broonie@kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
linux-sound@vger.kernel.org, linux-arm-msm@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 10/13] ASoC: qcom: Add QAIF regmap, DT parsing and platform init
Date: Fri, 5 Jun 2026 13:02:45 +0200 [thread overview]
Message-ID: <0f0fe294-a6c8-4b2d-a038-9f699845ab58@kernel.org> (raw)
In-Reply-To: <20260605103739.3557573-11-harendra.gautam@oss.qualcomm.com>
On 05/06/2026 12:37, Harendra Gautam wrote:
> +int asoc_qcom_qaif_cpu_platform_probe(struct platform_device *pdev)
> +{
> + struct qaif_drv_data *drvdata;
> + struct resource *res;
> + const struct qaif_variant *variant;
> + struct device *dev = &pdev->dev;
> + const struct of_device_id *match;
> + int ret, i, dai_id, idx;
> + bool variant_init_done = false;
> +
> + dev_dbg(dev, "%s\n", __func__);
NAK, see further. This is clear, old known antipattern. Don't send such
code anymore.
> + drvdata = devm_kzalloc(dev, sizeof(struct qaif_drv_data), GFP_KERNEL);
sizeof(*), and with third argument - lack of dev_err_probe - means you
just sent us old junk vendor code.
That's waste of the time - we will have to point you all standard
issues, we solved already years ago.
No. Drop all this code and start from current kernel code as your base
so you won't be repeating same old poor patterns.
> + if (!drvdata)
> + return -ENOMEM;
> + platform_set_drvdata(pdev, drvdata);
> +
> + match = of_match_device(dev->driver->of_match_table, dev);
> + if (!match || !match->data)
> + return -EINVAL;
> +
> + drvdata->variant = (const struct qaif_variant *)match->data;
Why do you need to cast?
> + variant = drvdata->variant;
> + if (!variant) {
> + dev_err(dev, "No variant data\n");
Is it a possible condition? Probably no, so why printing messages?
> + return -EINVAL;
> + }
> +
> + ret = of_qaif_parse_aif_intf_cfg(dev, drvdata);
> + if (ret) {
> + dev_err(dev, "Failed to parse aif interfaces: %d\n", ret);
> + return -EINVAL;
> + }
> +
> + drvdata->audio_qaif =
> + devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(drvdata->audio_qaif))
> + return PTR_ERR(drvdata->audio_qaif);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res)
> + return -EINVAL;
> +
> + audio_qaif_regmap_config.max_register = resource_size(res);
> +
> + drvdata->audio_qaif_map = devm_regmap_init_mmio(dev, drvdata->audio_qaif,
> + &audio_qaif_regmap_config);
Your code is barely readable.
> + if (IS_ERR(drvdata->audio_qaif_map))
> + return PTR_ERR(drvdata->audio_qaif_map);
> +
> + ret = of_qaif_cdc_dma_clks_parse(dev, drvdata);
> + if (ret) {
> + dev_err(dev, "failed to get cdc dma clocks %d\n", ret);
> + return ret;
> + }
> +
> + if (variant->init) {
> + ret = variant->init(pdev);
> + if (ret) {
> + dev_err(dev, "error initializing variant: %d\n", ret);
> + return ret;
> + }
> + variant_init_done = true;
> + }
> +
> + for (i = 0; i < variant->num_dai; i++) {
> + dai_id = variant->dai_driver[i].id;
> + if (is_cif_dma_port(dai_id))
> + continue;
> + idx = variant->get_dma_idx(dai_id);
> + if (idx < 0)
> + continue;
> +
> + drvdata->mi2s_bit_clk[idx] = devm_clk_get(dev,
> + variant->dai_bit_clk_names[idx]);
> + if (IS_ERR(drvdata->mi2s_bit_clk[idx])) {
> + dev_err(dev,
> + "error getting %s: %ld\n",
> + variant->dai_bit_clk_names[idx],
> + PTR_ERR(drvdata->mi2s_bit_clk[idx]));
> + ret = PTR_ERR(drvdata->mi2s_bit_clk[idx]);
Heh....
> + goto err;
> + }
> + }
> +
> + ret = qaif_aif_cpu_init_bitfields(dev, drvdata->audio_qaif_map);
> + if (ret) {
> + dev_err(dev, "error init cif bitfield: %d\n", ret);
> + goto err;
> + }
> +
> + ret = qaif_aif_cfg_cpu_init_bitfields(dev, drvdata->audio_qaif_map);
> + if (ret) {
> + dev_err(dev, "error init aif_intfctl field: %d\n", ret);
> + goto err;
> + }
> +
> + ret = qaif_cif_cpu_init_bitfields(dev, drvdata->audio_qaif_map);
> + if (ret) {
> + dev_err(dev, "error init cif bitfield: %d\n", ret);
> + goto err;
> + }
> +
> + ret = devm_snd_soc_register_component(dev, &qaif_cpu_comp_driver,
> + variant->dai_driver,
> + variant->num_dai);
> + if (ret) {
> + dev_err(dev, "error registering cpu driver: %d\n", ret);
Why aren't you using modern style? dev_err_probe?
> + goto err;
> + }
> +
> + ret = asoc_qcom_qaif_platform_register(pdev);
> + if (ret) {
> + dev_err(dev, "error registering platform driver: %d\n", ret);
> + goto err;
> + }
> + dev_dbg(&pdev->dev, "%s: QAIF CPU-Platform Driver Registered Successfully\n", __func__);
Drop. This does not look like useful printk message. Drivers should be
silent on success:
https://elixir.bootlin.com/linux/v6.15-rc7/source/Documentation/process/coding-style.rst#L913
https://elixir.bootlin.com/linux/v6.15-rc7/source/Documentation/process/debugging/driver_development_debugging_guide.rst#L79
Especially trivial probe successes are useless - core handles it.
> +err:
> + if (ret && variant_init_done && variant->exit)
> + variant->exit(pdev);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(asoc_qcom_qaif_cpu_platform_probe);
Every exported function should have kerneldoc.
> +
> +void asoc_qcom_qaif_cpu_platform_remove(struct platform_device *pdev)
> +{
> + struct qaif_drv_data *drvdata = platform_get_drvdata(pdev);
> +
> + if (drvdata->variant->exit)
> + drvdata->variant->exit(pdev);
> +}
> +EXPORT_SYMBOL_GPL(asoc_qcom_qaif_cpu_platform_remove);
> +
Best regards,
Krzysztof
next prev parent reply other threads:[~2026-06-05 11:02 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-05 10:37 [PATCH 0/13] ASoC: qcom: Add QAIF driver for Shikra audio platform Harendra Gautam
2026-06-05 10:37 ` [PATCH 1/13] dt-bindings: sound: Add Qualcomm QAIF DAI ID header Harendra Gautam
2026-06-05 10:42 ` Krzysztof Kozlowski
2026-06-05 10:37 ` [PATCH 2/13] dt-bindings: sound: Add Qualcomm QAIF binding Harendra Gautam
2026-06-05 10:46 ` Krzysztof Kozlowski
2026-06-05 10:51 ` Krzysztof Kozlowski
2026-06-24 7:02 ` Harendra Gautam
2026-06-05 11:27 ` Rob Herring (Arm)
2026-06-23 12:30 ` Harendra Gautam
2026-06-09 9:57 ` Konrad Dybcio
2026-06-23 12:26 ` Harendra Gautam
2026-06-23 15:48 ` Konrad Dybcio
2026-06-24 6:59 ` Harendra Gautam
2026-06-25 12:11 ` Konrad Dybcio
2026-06-27 5:20 ` Harendra Gautam
2026-06-16 19:59 ` Srinivas Kandagatla
2026-06-23 12:17 ` Harendra Gautam
2026-06-05 10:37 ` [PATCH 3/13] MAINTAINERS: Add Qualcomm QAIF driver entry Harendra Gautam
2026-06-05 10:52 ` Krzysztof Kozlowski
2026-06-05 10:37 ` [PATCH 4/13] ASoC: qcom: Add QAIF hardware register map Harendra Gautam
2026-06-05 10:37 ` [PATCH 5/13] ASoC: qcom: Add QAIF shared data structures and variant interface Harendra Gautam
2026-06-16 20:28 ` Srinivas Kandagatla
[not found] ` <CAC-tS8BvfQOLhwicBJ986UqTTZGmiYDbg5MVA54ScUsYLb-dog@mail.gmail.com>
2026-06-23 8:11 ` Harendra Gautam
2026-06-05 10:37 ` [PATCH 6/13] ASoC: qcom: Add QAIF CIF (CDC DMA) DAI ops Harendra Gautam
2026-06-05 10:37 ` [PATCH 7/13] ASoC: qcom: Add QAIF AIF " Harendra Gautam
2026-06-05 10:37 ` [PATCH 8/13] ASoC: qcom: Add generic of_xlate_dai_name helper to common Harendra Gautam
2026-06-05 10:37 ` [PATCH 9/13] ASoC: qcom: lpass-cpu: Use asoc_qcom_of_xlate_dai_name helper Harendra Gautam
2026-06-05 10:37 ` [PATCH 10/13] ASoC: qcom: Add QAIF regmap, DT parsing and platform init Harendra Gautam
2026-06-05 11:02 ` Krzysztof Kozlowski [this message]
2026-06-05 10:37 ` [PATCH 11/13] ASoC: qcom: Add QAIF PCM operations Harendra Gautam
2026-06-05 10:37 ` [PATCH 12/13] ASoC: qcom: Add QAIF IRQ handling, suspend/resume and platform register Harendra Gautam
2026-06-05 10:37 ` [PATCH 13/13] ASoC: qcom: Add Shikra QAIF support Harendra Gautam
2026-06-05 10:58 ` Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0f0fe294-a6c8-4b2d-a038-9f699845ab58@kernel.org \
--to=krzk@kernel.org \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=harendra.gautam@oss.qualcomm.com \
--cc=krzk+dt@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=robh@kernel.org \
--cc=srini@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®