All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ryan Brue" <ryanbrue.dev@gmail.com>
Cc: mfd@lists.linux.dev, devicetree@vger.kernel.org,
	linux-rtc@vger.kernel.org, robh@kernel.org, conor+dt@kernel.org,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	lee@kernel.org
Subject: Re: [PATCH 2/2] rtc: mt6397: provide the 32 kHz output as a clock
Date: Mon, 02 Nov 2026 05:44:50 +0000	[thread overview]
Message-ID: <sashiko-outbox-192928@kernel.org> (raw)
In-Reply-To: <20261101-rbrue-suez-upstreaming-mt6397-rtc-32k-v1-2-9758f38d7053@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] rtc: mt6397: NULL dereference of rtc->data in mtk_rtc_register_clkout()
--

commit 7a674b1fa23c59043354cce078b81b55651fd9c2
Author: Ryan Brue <ryanbrue.dev@gmail.com>

rtc: mt6397: provide the 32 kHz output as a clock

This commit registers the MT6397 RTC's 32 kHz output gated by RTC_CON.F32KOB
as a clock provider when the RTC node specifies #clock-cells, allowing client
devices such as Wi-Fi/Bluetooth combo chips to enable their sleep clock.

> diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
> index d6e156516aa6c..5130fecffa7b4 100644
> --- a/drivers/rtc/rtc-mt6397.c
> +++ b/drivers/rtc/rtc-mt6397.c
[ ... ]
> @@ -317,6 +318,84 @@ static int mtk_rtc_nvram_write(void *priv, unsigned int offset, void *val,
[ ... ]
> +/* The 32 kHz output the PMIC drives to other chips, such as a combo chip */
> +static int mtk_rtc_register_clkout(struct device *dev, struct mt6397_rtc *rtc)
> +{
> +	struct clk_init_data init = {
> +		.name = "mt6397-rtc-32k",
> +		.ops = &mtk_rtc_clkout_ops,
> +	};
> +	int ret;
> +
> +	if (!rtc->data->con || !of_property_present(dev->of_node, "#clock-cells"))
> +		return 0;

[Severity: High]
Can this dereference a NULL rtc->data pointer during mtk_rtc_probe()?

In drivers/mfd/mt6397-core.c, mt6397_devs[] unconditionally registers the
mt6397-rtc MFD cell:

    {
        .name = "mt6397-rtc",
        .num_resources = ARRAY_SIZE(mt6397_rtc_resources),
        .resources = mt6397_rtc_resources,
        .of_compatible = "mediatek,mt6397-rtc",
    }

On MT6397 boards whose Device Tree omits the optional mediatek,mt6397-rtc
child node under the PMIC node (such as mt8173-evb.dts and mt8135-evbp1.dts),
mfd_add_device() registers the mt6397-rtc platform device with
pdev->dev.of_node set to NULL. Because mtk_rtc_driver has .driver.name set to
"mt6397-rtc" and no id_table, platform_match() binds the device via the
driver-name fallback and invokes mtk_rtc_probe():

drivers/rtc/rtc-mt6397.c:mtk_rtc_probe() {
    ...
    rtc->data = of_device_get_match_data(&pdev->dev);
    ...
    ret = mtk_rtc_register_clkout(&pdev->dev, rtc);
}

When pdev->dev.of_node is NULL, of_device_get_match_data() returns NULL.
Previously, mtk_rtc_probe() never dereferenced rtc->data during probe,
whereas mtk_rtc_register_clkout() now evaluates !rtc->data->con before
checking dev->of_node or whether rtc->data is NULL.

Should mtk_rtc_register_clkout() check !rtc->data (or check
of_property_present() first), or should mtk_rtc_probe() handle a NULL
rtc->data?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261101-rbrue-suez-upstreaming-mt6397-rtc-32k-v1-0-9758f38d7053@gmail.com?part=2

  reply	other threads:[~2026-11-02  5:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-02  5:33 [PATCH 0/2] rtc: mt6397: provide the RTC's 32 kHz output as a clock Ryan Brue
2026-11-02  5:33 ` [PATCH 1/2] dt-bindings: mfd: mediatek: mt6397: describe the RTC's 32 kHz output Ryan Brue
2026-11-02  5:37   ` sashiko-bot
2026-11-02  7:47   ` Krzysztof Kozlowski
2026-11-02  5:33 ` [PATCH 2/2] rtc: mt6397: provide the 32 kHz output as a clock Ryan Brue
2026-11-02  5:44   ` sashiko-bot [this message]
2026-11-02 14:36     ` Ryan Brue

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=sashiko-outbox-192928@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=alexandre.belloni@bootlin.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=lee@kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=mfd@lists.linux.dev \
    --cc=robh@kernel.org \
    --cc=ryanbrue.dev@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.