All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Anup Patel <apatel@ventanamicro.com>
Cc: "Michael Turquette" <mturquette@baylibre.com>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Jassi Brar" <jassisinghbrar@gmail.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"Mika Westerberg" <mika.westerberg@linux.intel.com>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Bartosz Golaszewski" <brgl@bgdev.pl>,
	"Uwe Kleine-König" <ukleinek@kernel.org>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Len Brown" <lenb@kernel.org>,
	"Sunil V L" <sunilvl@ventanamicro.com>,
	"Rahul Pathak" <rpathak@ventanamicro.com>,
	"Leyfoon Tan" <leyfoon.tan@starfivetech.com>,
	"Atish Patra" <atish.patra@linux.dev>,
	"Andrew Jones" <ajones@ventanamicro.com>,
	"Samuel Holland" <samuel.holland@sifive.com>,
	"Anup Patel" <anup@brainfault.org>,
	linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
	linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 09/23] clk: Add clock driver for the RISC-V RPMI clock service group
Date: Mon, 23 Jun 2025 12:06:44 +0300	[thread overview]
Message-ID: <aFkZJKnweqBi64b8@smile.fi.intel.com> (raw)
In-Reply-To: <20250618121358.503781-10-apatel@ventanamicro.com>

On Wed, Jun 18, 2025 at 05:43:44PM +0530, Anup Patel wrote:
> From: Rahul Pathak <rpathak@ventanamicro.com>
> 
> The RPMI specification defines a clock service group which can be
> accessed via SBI MPXY extension or dedicated S-mode RPMI transport.
> 
> Add mailbox client based clock driver for the RISC-V RPMI clock
> service group.

...

> +#include <linux/clk-provider.h>
> +#include <linux/err.h>
> +#include <linux/mailbox_client.h>
> +#include <linux/mailbox/riscv-rpmi-message.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/types.h>
> +#include <linux/slab.h>
> +#include <linux/wordpart.h>

...

> +enum rpmi_clk_config {
> +	RPMI_CLK_DISABLE = 0,
> +	RPMI_CLK_ENABLE = 1

It's still unclear if this enum can be expanded in the future (and no, you may
not answer this either). Hence, to reduce potential churn in the future, leave
the trailing comma here.

> +};

...

> +union rpmi_clk_rates {
> +	u64 discrete[RPMI_CLK_DISCRETE_MAX_NUM_RATES];
> +	struct {
> +		u64 min;
> +		u64 max;
> +		u64 step;
> +	} linear;

Have you looked at the linear_range.h? Why can it not be (re-)used here?

> +};

...

> +static u32 rpmi_clk_get_num_clocks(struct rpmi_clk_context *context)
> +{
> +	struct rpmi_get_num_clocks_rx rx;
> +	struct rpmi_mbox_message msg;
> +	int ret;
> +
> +	rpmi_mbox_init_send_with_response(&msg, RPMI_CLK_SRV_GET_NUM_CLOCKS,
> +					  NULL, 0, &rx, sizeof(rx));

...here

> +	ret = rpmi_mbox_send_message(context->chan, &msg);
> +

This blank line should be rather ^^^

> +	if (ret || rx.status)
> +		return 0;

Why rx.status can't be checked before calling to a sending message?
Sounds like the rpmi_mbox_init_send_with_response() links rx to msg somehow.
If this is the case, use msg here, otherwise move the check to be in the
correct place.

Seems the same question to the all similar checks in the code.

> +	return le32_to_cpu(rx.num_clocks);
> +}

...

> +static int rpmi_clk_get_supported_rates(u32 clkid, struct rpmi_clk *rpmi_clk)
> +{
> +	struct rpmi_clk_context *context = rpmi_clk->context;
> +	struct rpmi_clk_rate_discrete *rate_discrete;
> +	struct rpmi_clk_rate_linear *rate_linear;
> +	struct rpmi_get_supp_rates_rx *rx __free(kfree) = NULL;
> +	struct rpmi_get_supp_rates_tx tx;
> +	struct rpmi_mbox_message msg;

> +	size_t clk_rate_idx = 0;

This kind of assignments is hard to maintain and it's mistake prone in case
some additional code is injected in the future that might reuse it.

> +	int ret, rateidx, j;
> +
> +	tx.clkid = cpu_to_le32(clkid);
> +	tx.clk_rate_idx = 0;
> +
> +	/*
> +	 * Make sure we allocate rx buffer sufficient to be accommodate all
> +	 * the rates sent in one RPMI message.
> +	 */
> +	rx = kzalloc(context->max_msg_data_size, GFP_KERNEL);
> +	if (!rx)
> +		return -ENOMEM;
> +
> +	rpmi_mbox_init_send_with_response(&msg, RPMI_CLK_SRV_GET_SUPPORTED_RATES,
> +					  &tx, sizeof(tx), rx, context->max_msg_data_size);
> +	ret = rpmi_mbox_send_message(context->chan, &msg);
> +	if (ret)
> +		return ret;
> +	if (rx->status)
> +		return rpmi_to_linux_error(le32_to_cpu(rx->status));
> +	if (!le32_to_cpu(rx->returned))
> +		return -EINVAL;
> +
> +	if (rpmi_clk->type == RPMI_CLK_DISCRETE) {
> +		rate_discrete = (struct rpmi_clk_rate_discrete *)rx->rates;
> +
> +		for (rateidx = 0; rateidx < le32_to_cpu(rx->returned); rateidx++) {
> +			rpmi_clk->rates->discrete[rateidx] =
> +				rpmi_clkrate_u64(le32_to_cpu(rate_discrete[rateidx].hi),
> +						 le32_to_cpu(rate_discrete[rateidx].lo));
> +		}
> +
> +		/*
> +		 * Keep sending the request message until all
> +		 * the rates are received.
> +		 */
> +		while (le32_to_cpu(rx->remaining)) {
> +			clk_rate_idx += le32_to_cpu(rx->returned);
> +			tx.clk_rate_idx = cpu_to_le32(clk_rate_idx);
> +
> +			rpmi_mbox_init_send_with_response(&msg,
> +							  RPMI_CLK_SRV_GET_SUPPORTED_RATES,
> +							  &tx, sizeof(tx),
> +							  rx, context->max_msg_data_size);
> +			ret = rpmi_mbox_send_message(context->chan, &msg);
> +			if (ret)
> +				return ret;
> +			if (rx->status)
> +				return rpmi_to_linux_error(le32_to_cpu(rx->status));
> +			if (!le32_to_cpu(rx->returned))
> +				return -EINVAL;
> +
> +			for (j = 0; j < le32_to_cpu(rx->returned); j++) {
> +				if (rateidx >= clk_rate_idx + le32_to_cpu(rx->returned))
> +					break;
> +				rpmi_clk->rates->discrete[rateidx++] =
> +					rpmi_clkrate_u64(le32_to_cpu(rate_discrete[j].hi),
> +							 le32_to_cpu(rate_discrete[j].lo));
> +			}
> +		}
> +	} else if (rpmi_clk->type == RPMI_CLK_LINEAR) {
> +		rate_linear = (struct rpmi_clk_rate_linear *)rx->rates;
> +
> +		rpmi_clk->rates->linear.min = rpmi_clkrate_u64(le32_to_cpu(rate_linear->min_hi),
> +							       le32_to_cpu(rate_linear->min_lo));
> +		rpmi_clk->rates->linear.max = rpmi_clkrate_u64(le32_to_cpu(rate_linear->max_hi),
> +							       le32_to_cpu(rate_linear->max_lo));
> +		rpmi_clk->rates->linear.step = rpmi_clkrate_u64(le32_to_cpu(rate_linear->step_hi),
> +								le32_to_cpu(rate_linear->step_lo));
> +	}
> +
> +	return 0;
> +}

...

> +static int rpmi_clk_determine_rate(struct clk_hw *hw,
> +				   struct clk_rate_request *req)
> +{
> +	struct rpmi_clk *rpmi_clk = to_rpmi_clk(hw);
> +	u64 fmin, fmax, ftmp;
> +
> +	/*
> +	 * Keep the requested rate if the clock format
> +	 * is of discrete type. Let the platform which
> +	 * is actually controlling the clock handle that.
> +	 */
> +	if (rpmi_clk->type == RPMI_CLK_DISCRETE)
> +		return 0;
> +
> +	fmin = rpmi_clk->rates->linear.min;
> +	fmax = rpmi_clk->rates->linear.max;
> +
> +	if (req->rate <= fmin) {
> +		req->rate = fmin;
> +		return 0;

> +	} else if (req->rate >= fmax) {

Redundant 'else', but I see the wish to tight the conditional together.

> +		req->rate = fmax;
> +		return 0;
> +	}
> +
> +	ftmp = req->rate - fmin;
> +	ftmp += rpmi_clk->rates->linear.step - 1;
> +	do_div(ftmp, rpmi_clk->rates->linear.step);
> +
> +	req->rate = ftmp * rpmi_clk->rates->linear.step + fmin;
> +
> +	return 0;
> +}

...

> +static void rpmi_clk_disable(struct clk_hw *hw)
> +{
> +	struct rpmi_clk *rpmi_clk = to_rpmi_clk(hw);
> +	struct rpmi_clk_context *context = rpmi_clk->context;
> +	struct rpmi_mbox_message msg;
> +	struct rpmi_set_config_tx tx;
> +	struct rpmi_set_config_rx rx;
> +	int ret;
> +
> +	tx.config = cpu_to_le32(RPMI_CLK_DISABLE);
> +	tx.clkid = cpu_to_le32(rpmi_clk->id);
> +
> +	rpmi_mbox_init_send_with_response(&msg, RPMI_CLK_SRV_SET_CONFIG,
> +					  &tx, sizeof(tx), &rx, sizeof(rx));
> +	ret = rpmi_mbox_send_message(context->chan, &msg);
> +	if (ret || rx.status)
> +		pr_err("Failed to disable clk-%u\n", rpmi_clk->id);

Close to useless message. You may improve it by splitting to two and printing
rx.status in one and ret in the other with different text. Or drop it.

> +}

> +static int rpmi_clk_probe(struct platform_device *pdev)
> +{
> +	int ret;
> +	unsigned int num_clocks, i;
> +	struct clk_hw_onecell_data *clk_data;
> +	struct rpmi_clk_context *context;
> +	struct rpmi_mbox_message msg;
> +	struct clk_hw *hw_ptr;
> +	struct device *dev = &pdev->dev;
> +
> +	context = devm_kzalloc(dev, sizeof(*context), GFP_KERNEL);
> +	if (!context)
> +		return -ENOMEM;
> +	context->dev = dev;
> +	platform_set_drvdata(pdev, context);
> +
> +	context->client.dev		= context->dev;
> +	context->client.rx_callback	= NULL;
> +	context->client.tx_block	= false;
> +	context->client.knows_txdone	= true;
> +	context->client.tx_tout		= 0;
> +
> +	context->chan = mbox_request_channel(&context->client, 0);
> +	if (IS_ERR(context->chan))
> +		return PTR_ERR(context->chan);

Here is an incorrect order of the freeing resources. Besides that, wrapping the
mbox_free_channel() into managed resources reduces this code by more
than 10 LoCs! At bare minimum if will fix the bug,

> +	rpmi_mbox_init_get_attribute(&msg, RPMI_MBOX_ATTR_SPEC_VERSION);
> +	ret = rpmi_mbox_send_message(context->chan, &msg);
> +	if (ret) {
> +		mbox_free_channel(context->chan);
> +		return dev_err_probe(dev, ret, "Failed to get spec version\n");
> +	}
> +	if (msg.attr.value < RPMI_MKVER(1, 0)) {
> +		mbox_free_channel(context->chan);
> +		return dev_err_probe(dev, -EINVAL,
> +				     "msg protocol version mismatch, expected 0x%x, found 0x%x\n",
> +				     RPMI_MKVER(1, 0), msg.attr.value);
> +	}
> +
> +	rpmi_mbox_init_get_attribute(&msg, RPMI_MBOX_ATTR_SERVICEGROUP_ID);
> +	ret = rpmi_mbox_send_message(context->chan, &msg);
> +	if (ret) {
> +		mbox_free_channel(context->chan);
> +		return dev_err_probe(dev, ret, "Failed to get service group ID\n");
> +	}
> +	if (msg.attr.value != RPMI_SRVGRP_CLOCK) {
> +		mbox_free_channel(context->chan);
> +		return dev_err_probe(dev, -EINVAL,
> +				     "service group match failed, expected 0x%x, found 0x%x\n",
> +				     RPMI_SRVGRP_CLOCK, msg.attr.value);
> +	}
> +
> +	rpmi_mbox_init_get_attribute(&msg, RPMI_MBOX_ATTR_SERVICEGROUP_VERSION);
> +	ret = rpmi_mbox_send_message(context->chan, &msg);
> +	if (ret) {
> +		mbox_free_channel(context->chan);
> +		return dev_err_probe(dev, ret, "Failed to get service group version\n");
> +	}
> +	if (msg.attr.value < RPMI_MKVER(1, 0)) {
> +		mbox_free_channel(context->chan);
> +		return dev_err_probe(dev, -EINVAL,
> +				     "service group version failed, expected 0x%x, found 0x%x\n",
> +				     RPMI_MKVER(1, 0), msg.attr.value);
> +	}
> +
> +	rpmi_mbox_init_get_attribute(&msg, RPMI_MBOX_ATTR_MAX_MSG_DATA_SIZE);
> +	ret = rpmi_mbox_send_message(context->chan, &msg);
> +	if (ret) {
> +		mbox_free_channel(context->chan);
> +		return dev_err_probe(dev, ret, "Failed to get max message data size\n");
> +	}
> +
> +	context->max_msg_data_size = msg.attr.value;
> +	num_clocks = rpmi_clk_get_num_clocks(context);
> +	if (!num_clocks) {
> +		mbox_free_channel(context->chan);
> +		return dev_err_probe(dev, -ENODEV, "No clocks found\n");
> +	}
> +
> +	clk_data = devm_kzalloc(dev, struct_size(clk_data, hws, num_clocks),
> +				GFP_KERNEL);

(The above mention problem comes here after the successful allocation of
 clk_data but failing of any further code.

> +	if (!clk_data) {
> +		mbox_free_channel(context->chan);
> +		return dev_err_probe(dev, -ENOMEM, "No memory for clock data\n");
> +	}
> +	clk_data->num = num_clocks;
> +
> +	for (i = 0; i < clk_data->num; i++) {
> +		hw_ptr = rpmi_clk_enumerate(context, i);
> +		if (IS_ERR(hw_ptr)) {
> +			mbox_free_channel(context->chan);
> +			return dev_err_probe(dev, PTR_ERR(hw_ptr),
> +					     "failed to register clk-%d\n", i);
> +		}
> +		clk_data->hws[i] = hw_ptr;
> +	}
> +
> +	ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get, clk_data);
> +	if (ret) {
> +		mbox_free_channel(context->chan);
> +		return dev_err_probe(dev, ret, "failed to register clock HW provider\n");
> +	}
> +
> +	return 0;
> +}

...

> +static void rpmi_clk_remove(struct platform_device *pdev)
> +{
> +	struct rpmi_clk_context *context = platform_get_drvdata(pdev);
> +
> +	mbox_free_channel(context->chan);
> +}

This function will be gone. See above.

-- 
With Best Regards,
Andy Shevchenko



WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Anup Patel <apatel@ventanamicro.com>
Cc: "Jassi Brar" <jassisinghbrar@gmail.com>,
	"Atish Patra" <atish.patra@linux.dev>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Uwe Kleine-König" <ukleinek@kernel.org>,
	linux-riscv@lists.infradead.org, linux-clk@vger.kernel.org,
	"Rob Herring" <robh@kernel.org>,
	"Anup Patel" <anup@brainfault.org>,
	"Bartosz Golaszewski" <brgl@bgdev.pl>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Andrew Jones" <ajones@ventanamicro.com>,
	devicetree@vger.kernel.org, "Conor Dooley" <conor+dt@kernel.org>,
	"Leyfoon Tan" <leyfoon.tan@starfivetech.com>,
	"Paul Walmsley" <paul.walmsley@sifive.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Mika Westerberg" <mika.westerberg@linux.intel.com>,
	"Stephen Boyd" <sboyd@kernel.org>,
	linux-kernel@vger.kernel.org,
	"Samuel Holland" <samuel.holland@sifive.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Rahul Pathak" <rpathak@ventanamicro.com>,
	"Len Brown" <lenb@kernel.org>
Subject: Re: [PATCH v6 09/23] clk: Add clock driver for the RISC-V RPMI clock service group
Date: Mon, 23 Jun 2025 12:06:44 +0300	[thread overview]
Message-ID: <aFkZJKnweqBi64b8@smile.fi.intel.com> (raw)
In-Reply-To: <20250618121358.503781-10-apatel@ventanamicro.com>

On Wed, Jun 18, 2025 at 05:43:44PM +0530, Anup Patel wrote:
> From: Rahul Pathak <rpathak@ventanamicro.com>
> 
> The RPMI specification defines a clock service group which can be
> accessed via SBI MPXY extension or dedicated S-mode RPMI transport.
> 
> Add mailbox client based clock driver for the RISC-V RPMI clock
> service group.

...

> +#include <linux/clk-provider.h>
> +#include <linux/err.h>
> +#include <linux/mailbox_client.h>
> +#include <linux/mailbox/riscv-rpmi-message.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/types.h>
> +#include <linux/slab.h>
> +#include <linux/wordpart.h>

...

> +enum rpmi_clk_config {
> +	RPMI_CLK_DISABLE = 0,
> +	RPMI_CLK_ENABLE = 1

It's still unclear if this enum can be expanded in the future (and no, you may
not answer this either). Hence, to reduce potential churn in the future, leave
the trailing comma here.

> +};

...

> +union rpmi_clk_rates {
> +	u64 discrete[RPMI_CLK_DISCRETE_MAX_NUM_RATES];
> +	struct {
> +		u64 min;
> +		u64 max;
> +		u64 step;
> +	} linear;

Have you looked at the linear_range.h? Why can it not be (re-)used here?

> +};

...

> +static u32 rpmi_clk_get_num_clocks(struct rpmi_clk_context *context)
> +{
> +	struct rpmi_get_num_clocks_rx rx;
> +	struct rpmi_mbox_message msg;
> +	int ret;
> +
> +	rpmi_mbox_init_send_with_response(&msg, RPMI_CLK_SRV_GET_NUM_CLOCKS,
> +					  NULL, 0, &rx, sizeof(rx));

...here

> +	ret = rpmi_mbox_send_message(context->chan, &msg);
> +

This blank line should be rather ^^^

> +	if (ret || rx.status)
> +		return 0;

Why rx.status can't be checked before calling to a sending message?
Sounds like the rpmi_mbox_init_send_with_response() links rx to msg somehow.
If this is the case, use msg here, otherwise move the check to be in the
correct place.

Seems the same question to the all similar checks in the code.

> +	return le32_to_cpu(rx.num_clocks);
> +}

...

> +static int rpmi_clk_get_supported_rates(u32 clkid, struct rpmi_clk *rpmi_clk)
> +{
> +	struct rpmi_clk_context *context = rpmi_clk->context;
> +	struct rpmi_clk_rate_discrete *rate_discrete;
> +	struct rpmi_clk_rate_linear *rate_linear;
> +	struct rpmi_get_supp_rates_rx *rx __free(kfree) = NULL;
> +	struct rpmi_get_supp_rates_tx tx;
> +	struct rpmi_mbox_message msg;

> +	size_t clk_rate_idx = 0;

This kind of assignments is hard to maintain and it's mistake prone in case
some additional code is injected in the future that might reuse it.

> +	int ret, rateidx, j;
> +
> +	tx.clkid = cpu_to_le32(clkid);
> +	tx.clk_rate_idx = 0;
> +
> +	/*
> +	 * Make sure we allocate rx buffer sufficient to be accommodate all
> +	 * the rates sent in one RPMI message.
> +	 */
> +	rx = kzalloc(context->max_msg_data_size, GFP_KERNEL);
> +	if (!rx)
> +		return -ENOMEM;
> +
> +	rpmi_mbox_init_send_with_response(&msg, RPMI_CLK_SRV_GET_SUPPORTED_RATES,
> +					  &tx, sizeof(tx), rx, context->max_msg_data_size);
> +	ret = rpmi_mbox_send_message(context->chan, &msg);
> +	if (ret)
> +		return ret;
> +	if (rx->status)
> +		return rpmi_to_linux_error(le32_to_cpu(rx->status));
> +	if (!le32_to_cpu(rx->returned))
> +		return -EINVAL;
> +
> +	if (rpmi_clk->type == RPMI_CLK_DISCRETE) {
> +		rate_discrete = (struct rpmi_clk_rate_discrete *)rx->rates;
> +
> +		for (rateidx = 0; rateidx < le32_to_cpu(rx->returned); rateidx++) {
> +			rpmi_clk->rates->discrete[rateidx] =
> +				rpmi_clkrate_u64(le32_to_cpu(rate_discrete[rateidx].hi),
> +						 le32_to_cpu(rate_discrete[rateidx].lo));
> +		}
> +
> +		/*
> +		 * Keep sending the request message until all
> +		 * the rates are received.
> +		 */
> +		while (le32_to_cpu(rx->remaining)) {
> +			clk_rate_idx += le32_to_cpu(rx->returned);
> +			tx.clk_rate_idx = cpu_to_le32(clk_rate_idx);
> +
> +			rpmi_mbox_init_send_with_response(&msg,
> +							  RPMI_CLK_SRV_GET_SUPPORTED_RATES,
> +							  &tx, sizeof(tx),
> +							  rx, context->max_msg_data_size);
> +			ret = rpmi_mbox_send_message(context->chan, &msg);
> +			if (ret)
> +				return ret;
> +			if (rx->status)
> +				return rpmi_to_linux_error(le32_to_cpu(rx->status));
> +			if (!le32_to_cpu(rx->returned))
> +				return -EINVAL;
> +
> +			for (j = 0; j < le32_to_cpu(rx->returned); j++) {
> +				if (rateidx >= clk_rate_idx + le32_to_cpu(rx->returned))
> +					break;
> +				rpmi_clk->rates->discrete[rateidx++] =
> +					rpmi_clkrate_u64(le32_to_cpu(rate_discrete[j].hi),
> +							 le32_to_cpu(rate_discrete[j].lo));
> +			}
> +		}
> +	} else if (rpmi_clk->type == RPMI_CLK_LINEAR) {
> +		rate_linear = (struct rpmi_clk_rate_linear *)rx->rates;
> +
> +		rpmi_clk->rates->linear.min = rpmi_clkrate_u64(le32_to_cpu(rate_linear->min_hi),
> +							       le32_to_cpu(rate_linear->min_lo));
> +		rpmi_clk->rates->linear.max = rpmi_clkrate_u64(le32_to_cpu(rate_linear->max_hi),
> +							       le32_to_cpu(rate_linear->max_lo));
> +		rpmi_clk->rates->linear.step = rpmi_clkrate_u64(le32_to_cpu(rate_linear->step_hi),
> +								le32_to_cpu(rate_linear->step_lo));
> +	}
> +
> +	return 0;
> +}

...

> +static int rpmi_clk_determine_rate(struct clk_hw *hw,
> +				   struct clk_rate_request *req)
> +{
> +	struct rpmi_clk *rpmi_clk = to_rpmi_clk(hw);
> +	u64 fmin, fmax, ftmp;
> +
> +	/*
> +	 * Keep the requested rate if the clock format
> +	 * is of discrete type. Let the platform which
> +	 * is actually controlling the clock handle that.
> +	 */
> +	if (rpmi_clk->type == RPMI_CLK_DISCRETE)
> +		return 0;
> +
> +	fmin = rpmi_clk->rates->linear.min;
> +	fmax = rpmi_clk->rates->linear.max;
> +
> +	if (req->rate <= fmin) {
> +		req->rate = fmin;
> +		return 0;

> +	} else if (req->rate >= fmax) {

Redundant 'else', but I see the wish to tight the conditional together.

> +		req->rate = fmax;
> +		return 0;
> +	}
> +
> +	ftmp = req->rate - fmin;
> +	ftmp += rpmi_clk->rates->linear.step - 1;
> +	do_div(ftmp, rpmi_clk->rates->linear.step);
> +
> +	req->rate = ftmp * rpmi_clk->rates->linear.step + fmin;
> +
> +	return 0;
> +}

...

> +static void rpmi_clk_disable(struct clk_hw *hw)
> +{
> +	struct rpmi_clk *rpmi_clk = to_rpmi_clk(hw);
> +	struct rpmi_clk_context *context = rpmi_clk->context;
> +	struct rpmi_mbox_message msg;
> +	struct rpmi_set_config_tx tx;
> +	struct rpmi_set_config_rx rx;
> +	int ret;
> +
> +	tx.config = cpu_to_le32(RPMI_CLK_DISABLE);
> +	tx.clkid = cpu_to_le32(rpmi_clk->id);
> +
> +	rpmi_mbox_init_send_with_response(&msg, RPMI_CLK_SRV_SET_CONFIG,
> +					  &tx, sizeof(tx), &rx, sizeof(rx));
> +	ret = rpmi_mbox_send_message(context->chan, &msg);
> +	if (ret || rx.status)
> +		pr_err("Failed to disable clk-%u\n", rpmi_clk->id);

Close to useless message. You may improve it by splitting to two and printing
rx.status in one and ret in the other with different text. Or drop it.

> +}

> +static int rpmi_clk_probe(struct platform_device *pdev)
> +{
> +	int ret;
> +	unsigned int num_clocks, i;
> +	struct clk_hw_onecell_data *clk_data;
> +	struct rpmi_clk_context *context;
> +	struct rpmi_mbox_message msg;
> +	struct clk_hw *hw_ptr;
> +	struct device *dev = &pdev->dev;
> +
> +	context = devm_kzalloc(dev, sizeof(*context), GFP_KERNEL);
> +	if (!context)
> +		return -ENOMEM;
> +	context->dev = dev;
> +	platform_set_drvdata(pdev, context);
> +
> +	context->client.dev		= context->dev;
> +	context->client.rx_callback	= NULL;
> +	context->client.tx_block	= false;
> +	context->client.knows_txdone	= true;
> +	context->client.tx_tout		= 0;
> +
> +	context->chan = mbox_request_channel(&context->client, 0);
> +	if (IS_ERR(context->chan))
> +		return PTR_ERR(context->chan);

Here is an incorrect order of the freeing resources. Besides that, wrapping the
mbox_free_channel() into managed resources reduces this code by more
than 10 LoCs! At bare minimum if will fix the bug,

> +	rpmi_mbox_init_get_attribute(&msg, RPMI_MBOX_ATTR_SPEC_VERSION);
> +	ret = rpmi_mbox_send_message(context->chan, &msg);
> +	if (ret) {
> +		mbox_free_channel(context->chan);
> +		return dev_err_probe(dev, ret, "Failed to get spec version\n");
> +	}
> +	if (msg.attr.value < RPMI_MKVER(1, 0)) {
> +		mbox_free_channel(context->chan);
> +		return dev_err_probe(dev, -EINVAL,
> +				     "msg protocol version mismatch, expected 0x%x, found 0x%x\n",
> +				     RPMI_MKVER(1, 0), msg.attr.value);
> +	}
> +
> +	rpmi_mbox_init_get_attribute(&msg, RPMI_MBOX_ATTR_SERVICEGROUP_ID);
> +	ret = rpmi_mbox_send_message(context->chan, &msg);
> +	if (ret) {
> +		mbox_free_channel(context->chan);
> +		return dev_err_probe(dev, ret, "Failed to get service group ID\n");
> +	}
> +	if (msg.attr.value != RPMI_SRVGRP_CLOCK) {
> +		mbox_free_channel(context->chan);
> +		return dev_err_probe(dev, -EINVAL,
> +				     "service group match failed, expected 0x%x, found 0x%x\n",
> +				     RPMI_SRVGRP_CLOCK, msg.attr.value);
> +	}
> +
> +	rpmi_mbox_init_get_attribute(&msg, RPMI_MBOX_ATTR_SERVICEGROUP_VERSION);
> +	ret = rpmi_mbox_send_message(context->chan, &msg);
> +	if (ret) {
> +		mbox_free_channel(context->chan);
> +		return dev_err_probe(dev, ret, "Failed to get service group version\n");
> +	}
> +	if (msg.attr.value < RPMI_MKVER(1, 0)) {
> +		mbox_free_channel(context->chan);
> +		return dev_err_probe(dev, -EINVAL,
> +				     "service group version failed, expected 0x%x, found 0x%x\n",
> +				     RPMI_MKVER(1, 0), msg.attr.value);
> +	}
> +
> +	rpmi_mbox_init_get_attribute(&msg, RPMI_MBOX_ATTR_MAX_MSG_DATA_SIZE);
> +	ret = rpmi_mbox_send_message(context->chan, &msg);
> +	if (ret) {
> +		mbox_free_channel(context->chan);
> +		return dev_err_probe(dev, ret, "Failed to get max message data size\n");
> +	}
> +
> +	context->max_msg_data_size = msg.attr.value;
> +	num_clocks = rpmi_clk_get_num_clocks(context);
> +	if (!num_clocks) {
> +		mbox_free_channel(context->chan);
> +		return dev_err_probe(dev, -ENODEV, "No clocks found\n");
> +	}
> +
> +	clk_data = devm_kzalloc(dev, struct_size(clk_data, hws, num_clocks),
> +				GFP_KERNEL);

(The above mention problem comes here after the successful allocation of
 clk_data but failing of any further code.

> +	if (!clk_data) {
> +		mbox_free_channel(context->chan);
> +		return dev_err_probe(dev, -ENOMEM, "No memory for clock data\n");
> +	}
> +	clk_data->num = num_clocks;
> +
> +	for (i = 0; i < clk_data->num; i++) {
> +		hw_ptr = rpmi_clk_enumerate(context, i);
> +		if (IS_ERR(hw_ptr)) {
> +			mbox_free_channel(context->chan);
> +			return dev_err_probe(dev, PTR_ERR(hw_ptr),
> +					     "failed to register clk-%d\n", i);
> +		}
> +		clk_data->hws[i] = hw_ptr;
> +	}
> +
> +	ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get, clk_data);
> +	if (ret) {
> +		mbox_free_channel(context->chan);
> +		return dev_err_probe(dev, ret, "failed to register clock HW provider\n");
> +	}
> +
> +	return 0;
> +}

...

> +static void rpmi_clk_remove(struct platform_device *pdev)
> +{
> +	struct rpmi_clk_context *context = platform_get_drvdata(pdev);
> +
> +	mbox_free_channel(context->chan);
> +}

This function will be gone. See above.

-- 
With Best Regards,
Andy Shevchenko



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  parent reply	other threads:[~2025-06-23  9:06 UTC|newest]

Thread overview: 90+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-18 12:13 [PATCH v6 00/23] Linux SBI MPXY and RPMI drivers Anup Patel
2025-06-18 12:13 ` Anup Patel
2025-06-18 12:13 ` [PATCH v6 01/23] dt-bindings: mailbox: Add bindings for RPMI shared memory transport Anup Patel
2025-06-18 12:13   ` Anup Patel
2025-06-18 12:13 ` [PATCH v6 02/23] dt-bindings: mailbox: Add bindings for RISC-V SBI MPXY extension Anup Patel
2025-06-18 12:13   ` Anup Patel
2025-06-18 12:13 ` [PATCH v6 03/23] RISC-V: Add defines for the SBI message proxy extension Anup Patel
2025-06-18 12:13   ` Anup Patel
2025-06-24  6:58   ` Atish Patra
2025-06-24  6:58     ` Atish Patra
2025-06-18 12:13 ` [PATCH v6 04/23] mailbox: Add common header for RPMI messages sent via mailbox Anup Patel
2025-06-18 12:13   ` Anup Patel
2025-06-18 12:13 ` [PATCH v6 05/23] mailbox: Allow controller specific mapping using fwnode Anup Patel
2025-06-18 12:13   ` Anup Patel
2025-06-23  8:45   ` Andy Shevchenko
2025-06-23  8:45     ` Andy Shevchenko
2025-07-01  6:50     ` Anup Patel
2025-07-01  6:50       ` Anup Patel
2025-06-18 12:13 ` [PATCH v6 06/23] mailbox: Add RISC-V SBI message proxy (MPXY) based mailbox driver Anup Patel
2025-06-18 12:13   ` Anup Patel
2025-06-23  8:50   ` Andy Shevchenko
2025-06-23  8:50     ` Andy Shevchenko
2025-07-01  7:02     ` Anup Patel
2025-07-01  7:02       ` Anup Patel
2025-06-18 12:13 ` [PATCH v6 07/23] dt-bindings: clock: Add RPMI clock service message proxy bindings Anup Patel
2025-06-18 12:13   ` Anup Patel
2025-06-21 21:00   ` Stephen Boyd
2025-06-21 21:00     ` Stephen Boyd
2025-06-23  3:45     ` Anup Patel
2025-06-23  3:45       ` Anup Patel
2025-06-18 12:13 ` [PATCH v6 08/23] dt-bindings: clock: Add RPMI clock service controller bindings Anup Patel
2025-06-18 12:13   ` Anup Patel
2025-06-21 21:05   ` Stephen Boyd
2025-06-21 21:05     ` Stephen Boyd
2025-06-18 12:13 ` [PATCH v6 09/23] clk: Add clock driver for the RISC-V RPMI clock service group Anup Patel
2025-06-18 12:13   ` Anup Patel
2025-06-21 21:04   ` Stephen Boyd
2025-06-21 21:04     ` Stephen Boyd
2025-06-23  9:06   ` Andy Shevchenko [this message]
2025-06-23  9:06     ` Andy Shevchenko
2025-06-26  7:02     ` Rahul Pathak
2025-06-26  7:02       ` Rahul Pathak
2025-06-26 14:08       ` Andy Shevchenko
2025-06-26 14:08         ` Andy Shevchenko
2025-06-27 15:06         ` Rahul Pathak
2025-06-27 15:06           ` Rahul Pathak
2025-06-27 15:58           ` Andy Shevchenko
2025-06-27 15:58             ` Andy Shevchenko
2025-06-18 12:13 ` [PATCH v6 10/23] dt-bindings: Add RPMI system MSI message proxy bindings Anup Patel
2025-06-18 12:13   ` Anup Patel
2025-06-18 12:13 ` [PATCH v6 11/23] dt-bindings: Add RPMI system MSI interrupt controller bindings Anup Patel
2025-06-18 12:13   ` Anup Patel
2025-06-18 12:13 ` [PATCH v6 12/23] irqchip: Add driver for the RPMI system MSI service group Anup Patel
2025-06-18 12:13   ` Anup Patel
2025-06-18 12:13 ` [PATCH v6 13/23] ACPI: property: Refactor acpi_fwnode_get_reference_args() Anup Patel
2025-06-18 12:13   ` Anup Patel
2025-06-23  9:08   ` Andy Shevchenko
2025-06-23  9:08     ` Andy Shevchenko
2025-06-23 10:20     ` Rafael J. Wysocki
2025-06-23 10:20       ` Rafael J. Wysocki
2025-06-18 12:13 ` [PATCH v6 14/23] ACPI: property: Add support for cells property Anup Patel
2025-06-18 12:13   ` Anup Patel
2025-06-23  9:14   ` Andy Shevchenko
2025-06-23  9:14     ` Andy Shevchenko
2025-06-30  5:17     ` Sunil V L
2025-06-30  5:17       ` Sunil V L
2025-06-18 12:13 ` [PATCH v6 15/23] ACPI: scan: Update honor list for RPMI System MSI Anup Patel
2025-06-18 12:13   ` Anup Patel
2025-06-18 12:13 ` [PATCH v6 16/23] ACPI: RISC-V: Create interrupt controller list in sorted order Anup Patel
2025-06-18 12:13   ` Anup Patel
2025-06-18 12:13 ` [PATCH v6 17/23] ACPI: RISC-V: Add support to update gsi range Anup Patel
2025-06-18 12:13   ` Anup Patel
2025-06-18 12:13 ` [PATCH v6 18/23] ACPI: RISC-V: Add RPMI System MSI to GSI mapping Anup Patel
2025-06-18 12:13   ` Anup Patel
2025-06-18 12:13 ` [PATCH v6 19/23] irqchip/irq-riscv-imsic-early: Export imsic_acpi_get_fwnode() Anup Patel
2025-06-18 12:13   ` Anup Patel
2025-06-18 12:13 ` [PATCH v6 20/23] mailbox/riscv-sbi-mpxy: Add ACPI support Anup Patel
2025-06-18 12:13   ` Anup Patel
2025-06-18 12:13 ` [PATCH v6 21/23] irqchip/riscv-rpmi-sysmsi: " Anup Patel
2025-06-18 12:13   ` Anup Patel
2025-06-18 12:13 ` [PATCH v6 22/23] RISC-V: Enable GPIO keyboard and event device in RV64 defconfig Anup Patel
2025-06-18 12:13   ` Anup Patel
2025-06-18 12:13 ` [PATCH v6 23/23] MAINTAINERS: Add entry for RISC-V RPMI and MPXY drivers Anup Patel
2025-06-18 12:13   ` Anup Patel
2025-06-22 16:26 ` [PATCH v6 00/23] Linux SBI MPXY and RPMI drivers Jassi Brar
2025-06-22 16:26   ` Jassi Brar
2025-06-23  8:51   ` Andy Shevchenko
2025-06-23  8:51     ` Andy Shevchenko
2025-07-02  5:12   ` Anup Patel
2025-07-02  5:12     ` Anup Patel

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=aFkZJKnweqBi64b8@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=ajones@ventanamicro.com \
    --cc=anup@brainfault.org \
    --cc=apatel@ventanamicro.com \
    --cc=atish.patra@linux.dev \
    --cc=brgl@bgdev.pl \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jassisinghbrar@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=lenb@kernel.org \
    --cc=leyfoon.tan@starfivetech.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=mturquette@baylibre.com \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=rpathak@ventanamicro.com \
    --cc=samuel.holland@sifive.com \
    --cc=sboyd@kernel.org \
    --cc=sunilvl@ventanamicro.com \
    --cc=tglx@linutronix.de \
    --cc=ukleinek@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 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.