mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: AngeloGioacchino Del Regno  <angelogioacchino.delregno@collabora.com>
To: Chunfeng Yun <chunfeng.yun@mediatek.com>
Cc: mathias.nyman@intel.com, gregkh@linuxfoundation.org,
	matthias.bgg@gmail.com, linux-usb@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: host: xhci-mtk: Simplify supplies handling with regulator_bulk
Date: Mon, 7 Feb 2022 11:00:18 +0100	[thread overview]
Message-ID: <02d0dba2-ffc8-1bf1-d8a7-f7fa19f2c7ed@collabora.com> (raw)
In-Reply-To: <91bb8078e2d0824c325eb3819e59cdcb65b68a4e.camel@mediatek.com>

Il 20/01/22 07:50, Chunfeng Yun ha scritto:
> On Tue, 2022-01-18 at 14:33 +0100, AngeloGioacchino Del Regno wrote:
>> Remove the custom functions xhci_mtk_ldos_{enable,disable}() by
>> switching to using regulator_bulk to perform the very same thing,
>> as the regulators are always either both enabled or both disabled.
>>
>> Signed-off-by: AngeloGioacchino Del Regno <
>> angelogioacchino.delregno@collabora.com>
>> ---
>>   drivers/usb/host/xhci-mtk.c | 56 ++++++++++++-----------------------
>> --
>>   drivers/usb/host/xhci-mtk.h |  4 +--
>>   2 files changed, 20 insertions(+), 40 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-
>> mtk.c
>> index 62c835d446be..3b81931e5b77 100644
>> --- a/drivers/usb/host/xhci-mtk.c
>> +++ b/drivers/usb/host/xhci-mtk.c
>> @@ -395,31 +395,6 @@ static int xhci_mtk_clks_get(struct xhci_hcd_mtk
>> *mtk)
>>   	return devm_clk_bulk_get_optional(mtk->dev, BULK_CLKS_NUM,
>> clks);
>>   }
>>   
>> -static int xhci_mtk_ldos_enable(struct xhci_hcd_mtk *mtk)
>> -{
>> -	int ret;
>> -
>> -	ret = regulator_enable(mtk->vbus);
>> -	if (ret) {
>> -		dev_err(mtk->dev, "failed to enable vbus\n");
>> -		return ret;
>> -	}
>> -
>> -	ret = regulator_enable(mtk->vusb33);
>> -	if (ret) {
>> -		dev_err(mtk->dev, "failed to enable vusb33\n");
>> -		regulator_disable(mtk->vbus);
>> -		return ret;
>> -	}
>> -	return 0;
>> -}
>> -
>> -static void xhci_mtk_ldos_disable(struct xhci_hcd_mtk *mtk)
>> -{
>> -	regulator_disable(mtk->vbus);
>> -	regulator_disable(mtk->vusb33);
>> -}
>> -
>>   static void xhci_mtk_quirks(struct device *dev, struct xhci_hcd
>> *xhci)
>>   {
>>   	struct usb_hcd *hcd = xhci_to_hcd(xhci);
>> @@ -475,6 +450,10 @@ static int xhci_mtk_setup(struct usb_hcd *hcd)
>>   	return ret;
>>   }
>>   
>> +static const char * const xhci_mtk_supply_names[] = {
>> +	"vusb33", "vbus",
>> +};
>> +
>>   static const struct xhci_driver_overrides xhci_mtk_overrides
>> __initconst = {
>>   	.reset = xhci_mtk_setup,
>>   	.add_endpoint = xhci_mtk_add_ep,
>> @@ -507,17 +486,18 @@ static int xhci_mtk_probe(struct
>> platform_device *pdev)
>>   		return -ENOMEM;
>>   
>>   	mtk->dev = dev;
>> -	mtk->vbus = devm_regulator_get(dev, "vbus");
>> -	if (IS_ERR(mtk->vbus)) {
>> -		dev_err(dev, "fail to get vbus\n");
>> -		return PTR_ERR(mtk->vbus);
>> -	}
>> +	mtk->num_supplies = ARRAY_SIZE(xhci_mtk_supply_names);
>> +	mtk->supplies = devm_kcalloc(dev, mtk->num_supplies,
>> +				     sizeof(*mtk->supplies),
>> GFP_KERNEL);
>> +	if (!mtk->supplies)
>> +		return -ENOMEM;
>>   
>> -	mtk->vusb33 = devm_regulator_get(dev, "vusb33");
>> -	if (IS_ERR(mtk->vusb33)) {
>> -		dev_err(dev, "fail to get vusb33\n");
>> -		return PTR_ERR(mtk->vusb33);
>> -	}
>> +	regulator_bulk_set_supply_names(mtk->supplies,
>> xhci_mtk_supply_names,
>> +					mtk->num_supplies);
>> +
>> +	ret = devm_regulator_bulk_get(dev, mtk->num_supplies, mtk-
>>> supplies);
>> +	if (ret)
>> +		return dev_err_probe(dev, ret, "Failed to get
>> regulators\n");
>>   
>>   	ret = xhci_mtk_clks_get(mtk);
>>   	if (ret)
>> @@ -558,7 +538,7 @@ static int xhci_mtk_probe(struct platform_device
>> *pdev)
>>   	pm_runtime_enable(dev);
>>   	pm_runtime_get_sync(dev);
>>   
>> -	ret = xhci_mtk_ldos_enable(mtk);
>> +	ret = regulator_bulk_enable(mtk->num_supplies, mtk->supplies);
>>   	if (ret)
>>   		goto disable_pm;
>>   
>> @@ -667,7 +647,7 @@ static int xhci_mtk_probe(struct platform_device
>> *pdev)
>>   	clk_bulk_disable_unprepare(BULK_CLKS_NUM, mtk->clks);
>>   
>>   disable_ldos:
>> -	xhci_mtk_ldos_disable(mtk);
>> +	regulator_bulk_disable(mtk->num_supplies, mtk->supplies);
>>   
>>   disable_pm:
>>   	pm_runtime_put_noidle(dev);
>> @@ -695,7 +675,7 @@ static int xhci_mtk_remove(struct platform_device
>> *pdev)
>>   	usb_put_hcd(hcd);
>>   	xhci_mtk_sch_exit(mtk);
>>   	clk_bulk_disable_unprepare(BULK_CLKS_NUM, mtk->clks);
>> -	xhci_mtk_ldos_disable(mtk);
>> +	regulator_bulk_disable(mtk->num_supplies, mtk->supplies);
>>   
>>   	pm_runtime_disable(dev);
>>   	pm_runtime_put_noidle(dev);
>> diff --git a/drivers/usb/host/xhci-mtk.h b/drivers/usb/host/xhci-
>> mtk.h
>> index 4b1ea89f959a..9b78cd2ba0ac 100644
>> --- a/drivers/usb/host/xhci-mtk.h
>> +++ b/drivers/usb/host/xhci-mtk.h
>> @@ -150,9 +150,9 @@ struct xhci_hcd_mtk {
>>   	int num_u3_ports;
>>   	int u2p_dis_msk;
>>   	int u3p_dis_msk;
>> -	struct regulator *vusb33;
>> -	struct regulator *vbus;
>>   	struct clk_bulk_data clks[BULK_CLKS_NUM];
>> +	struct regulator_bulk_data *supplies;
>> +	u8 num_supplies;
> Could you please help to change it like as clock bulk?
> 
> 1. #define BULK_REGULATORS_NUM 2; then define @supplies array,
> 
>          struct regulator_bulk_data supplies[BULK_REGULATORS_NUM];
> 
> 2. also add a helper to get regulator bulk; e.g.
> 
> static int xhci_mtk_regulators_get(struct xhci_hcd_mtk *mtk)
> {
>      struct regulator_bulk_data *supplies = mtk->supplies;
> 
>      supplies[0].supply = "vusb33";
>      supplies[1].supply = "vbus";
> 
>      return devm_regulator_bulk_get(mtk->dev, BUL
> K_REGULATORS_NUM, supplies);
> }

Hello Chunfeng,
I chose to go for this way to enhance the implementation flexibility: like that,
any future SoC that needs different regulators (more vregs, less, different names)
will simply need a new array of vreg names, like:

static const char * const xhci_mtk_mtxxxx_supply_names[] = {
	"vusb33", "vbus", "another-supply", "and-another-one",
};

Other than enhancing flexibility, this will also make sure that we don't allocate
more regulator_bulk_data entries than needed, enhancing memory usage.

Your proposal, though, is valid if you are sure that future SoCs will have only
and always these two power supplies and nothing else...

Regards,
Angelo

> 
> Thanks a lot
> 
> 
>>   	unsigned int has_ippc:1;
>>   	unsigned int lpm_support:1;
>>   	unsigned int u2_lpm_disable:1;
> 

  reply	other threads:[~2022-02-07 10:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-18 13:33 AngeloGioacchino Del Regno
2022-01-20  6:50 ` Chunfeng Yun
2022-02-07 10:00   ` AngeloGioacchino Del Regno [this message]
2022-02-14  7:44     ` Chunfeng Yun

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=02d0dba2-ffc8-1bf1-d8a7-f7fa19f2c7ed@collabora.com \
    --to=angelogioacchino.delregno@collabora.com \
    --cc=chunfeng.yun@mediatek.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=matthias.bgg@gmail.com \
    /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®