All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chunfeng Yun <chunfeng.yun@mediatek.com>
To: Thierry Reding <treding@nvidia.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Paul Cercueil <paul@crapouillou.net>,
	Lee Jones <lee.jones@linaro.org>, <linux-usb@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>
Subject: Re: [PATCH v2 3/3] Revert "usb: common: usb-conn-gpio: Make VBUS supply optional"
Date: Mon, 24 May 2021 13:51:51 +0800	[thread overview]
Message-ID: <1621835511.26501.14.camel@mhfsdcap03> (raw)
In-Reply-To: <YKezl0nlWFQhLyf/@orome.fritz.box>

On Fri, 2021-05-21 at 15:20 +0200, Thierry Reding wrote:
> On Wed, May 19, 2021 at 02:39:46PM +0800, Chunfeng Yun wrote:
> > Vbus is already an optional supply, if the vbus-supply is not
> > provided in DTS, will use a dummy regulator,
> 
> That statement is not entirely correct. The dummy regulator is
> substituted only if the supply is in fact not optional. The idea behind
> that is to allow DTS files that don't specify all required regulators to
> get away with it, based on the assumption that the supply is one of
> those always-on supplies that are often not described in DTS.
Yes, you are right.
But from the point of result, it indeed can help to handle the absent
regulator.
> 
> > the warning log is as below:
> > "supply vbus not found, using dummy regulator"
> 
> And the reason why we get that warning is to point out that the DTS has
> a bug and that it should be fixed (by adding a proper regulator to take
> the place of the dummy).
> 
> > This reverts commit 4ddf1ac79e5f082451cd549283d2eb7559ab6ca9.
> 
> But if you read the description of that commit, the purpose of that
> patch was in fact to make the supply completely optional in the case
> where we already have the VBUS supply specified for the USB port that
> the connector is parented to.
Could you please give an example you mentioned?

It seems prefer to provide vbus supply in connector instead of port
according to dt-binding

Thanks

> 
> So in that case the DTS doesn't have the bug because the VBUS supply is
> already specified for the USB port and therefore it doesn't have to be
> specified in the USB connector again. In fact, specifying it twice can
> lead to a situation where the USB port may not be able to switch the
> VBUS supply on or off because the setting might conflict with that of
> the USB connector.

> 
> So unless there's a real reason why this is needed, I don't think this
> should be applied.
> 
> Thierry
> 
> > Cc: Thierry Reding <treding@nvidia.com>
> > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> > ---
> > v2: remove unused variable "need_vbus"
> > ---
> >  drivers/usb/common/usb-conn-gpio.c | 30 ++++++------------------------
> >  1 file changed, 6 insertions(+), 24 deletions(-)
> > 
> > diff --git a/drivers/usb/common/usb-conn-gpio.c b/drivers/usb/common/usb-conn-gpio.c
> > index dfbbc4f51ed6..65d89140cd19 100644
> > --- a/drivers/usb/common/usb-conn-gpio.c
> > +++ b/drivers/usb/common/usb-conn-gpio.c
> > @@ -91,14 +91,14 @@ static void usb_conn_detect_cable(struct work_struct *work)
> >  		return;
> >  	}
> >  
> > -	if (info->last_role == USB_ROLE_HOST && info->vbus)
> > +	if (info->last_role == USB_ROLE_HOST)
> >  		regulator_disable(info->vbus);
> >  
> >  	ret = usb_role_switch_set_role(info->role_sw, role);
> >  	if (ret)
> >  		dev_err(info->dev, "failed to set role: %d\n", ret);
> >  
> > -	if (role == USB_ROLE_HOST && info->vbus) {
> > +	if (role == USB_ROLE_HOST) {
> >  		ret = regulator_enable(info->vbus);
> >  		if (ret)
> >  			dev_err(info->dev, "enable vbus regulator failed\n");
> > @@ -106,9 +106,8 @@ static void usb_conn_detect_cable(struct work_struct *work)
> >  
> >  	info->last_role = role;
> >  
> > -	if (info->vbus)
> > -		dev_dbg(info->dev, "vbus regulator is %s\n",
> > -			regulator_is_enabled(info->vbus) ? "enabled" : "disabled");
> > +	dev_dbg(info->dev, "vbus regulator is %s\n",
> > +		regulator_is_enabled(info->vbus) ? "enabled" : "disabled");
> >  
> >  	power_supply_changed(info->charger);
> >  }
> > @@ -175,7 +174,6 @@ static int usb_conn_probe(struct platform_device *pdev)
> >  {
> >  	struct device *dev = &pdev->dev;
> >  	struct usb_conn_info *info;
> > -	bool need_vbus = true;
> >  	int ret = 0;
> >  
> >  	info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL);
> > @@ -205,23 +203,7 @@ static int usb_conn_probe(struct platform_device *pdev)
> >  
> >  	INIT_DELAYED_WORK(&info->dw_det, usb_conn_detect_cable);
> >  
> > -	/*
> > -	 * If the USB connector is a child of a USB port and that port already provides the VBUS
> > -	 * supply, there's no need for the USB connector to provide it again.
> > -	 */
> > -	if (dev->parent && dev->parent->of_node) {
> > -		if (of_find_property(dev->parent->of_node, "vbus-supply", NULL))
> > -			need_vbus = false;
> > -	}
> > -
> > -	if (!need_vbus) {
> > -		info->vbus = devm_regulator_get_optional(dev, "vbus");
> > -		if (PTR_ERR(info->vbus) == -ENODEV)
> > -			info->vbus = NULL;
> > -	} else {
> > -		info->vbus = devm_regulator_get(dev, "vbus");
> > -	}
> > -
> > +	info->vbus = devm_regulator_get(dev, "vbus");
> >  	if (IS_ERR(info->vbus)) {
> >  		ret = PTR_ERR(info->vbus);
> >  		return dev_err_probe(dev, ret, "failed to get vbus :%d\n", ret);
> > @@ -288,7 +270,7 @@ static int usb_conn_remove(struct platform_device *pdev)
> >  
> >  	cancel_delayed_work_sync(&info->dw_det);
> >  
> > -	if (info->last_role == USB_ROLE_HOST && info->vbus)
> > +	if (info->last_role == USB_ROLE_HOST)
> >  		regulator_disable(info->vbus);
> >  
> >  	usb_role_switch_put(info->role_sw);
> > -- 
> > 2.18.0
> > 


WARNING: multiple messages have this Message-ID (diff)
From: Chunfeng Yun <chunfeng.yun@mediatek.com>
To: Thierry Reding <treding@nvidia.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Paul Cercueil <paul@crapouillou.net>,
	Lee Jones <lee.jones@linaro.org>, <linux-usb@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>
Subject: Re: [PATCH v2 3/3] Revert "usb: common: usb-conn-gpio: Make VBUS supply optional"
Date: Mon, 24 May 2021 13:51:51 +0800	[thread overview]
Message-ID: <1621835511.26501.14.camel@mhfsdcap03> (raw)
In-Reply-To: <YKezl0nlWFQhLyf/@orome.fritz.box>

On Fri, 2021-05-21 at 15:20 +0200, Thierry Reding wrote:
> On Wed, May 19, 2021 at 02:39:46PM +0800, Chunfeng Yun wrote:
> > Vbus is already an optional supply, if the vbus-supply is not
> > provided in DTS, will use a dummy regulator,
> 
> That statement is not entirely correct. The dummy regulator is
> substituted only if the supply is in fact not optional. The idea behind
> that is to allow DTS files that don't specify all required regulators to
> get away with it, based on the assumption that the supply is one of
> those always-on supplies that are often not described in DTS.
Yes, you are right.
But from the point of result, it indeed can help to handle the absent
regulator.
> 
> > the warning log is as below:
> > "supply vbus not found, using dummy regulator"
> 
> And the reason why we get that warning is to point out that the DTS has
> a bug and that it should be fixed (by adding a proper regulator to take
> the place of the dummy).
> 
> > This reverts commit 4ddf1ac79e5f082451cd549283d2eb7559ab6ca9.
> 
> But if you read the description of that commit, the purpose of that
> patch was in fact to make the supply completely optional in the case
> where we already have the VBUS supply specified for the USB port that
> the connector is parented to.
Could you please give an example you mentioned?

It seems prefer to provide vbus supply in connector instead of port
according to dt-binding

Thanks

> 
> So in that case the DTS doesn't have the bug because the VBUS supply is
> already specified for the USB port and therefore it doesn't have to be
> specified in the USB connector again. In fact, specifying it twice can
> lead to a situation where the USB port may not be able to switch the
> VBUS supply on or off because the setting might conflict with that of
> the USB connector.

> 
> So unless there's a real reason why this is needed, I don't think this
> should be applied.
> 
> Thierry
> 
> > Cc: Thierry Reding <treding@nvidia.com>
> > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> > ---
> > v2: remove unused variable "need_vbus"
> > ---
> >  drivers/usb/common/usb-conn-gpio.c | 30 ++++++------------------------
> >  1 file changed, 6 insertions(+), 24 deletions(-)
> > 
> > diff --git a/drivers/usb/common/usb-conn-gpio.c b/drivers/usb/common/usb-conn-gpio.c
> > index dfbbc4f51ed6..65d89140cd19 100644
> > --- a/drivers/usb/common/usb-conn-gpio.c
> > +++ b/drivers/usb/common/usb-conn-gpio.c
> > @@ -91,14 +91,14 @@ static void usb_conn_detect_cable(struct work_struct *work)
> >  		return;
> >  	}
> >  
> > -	if (info->last_role == USB_ROLE_HOST && info->vbus)
> > +	if (info->last_role == USB_ROLE_HOST)
> >  		regulator_disable(info->vbus);
> >  
> >  	ret = usb_role_switch_set_role(info->role_sw, role);
> >  	if (ret)
> >  		dev_err(info->dev, "failed to set role: %d\n", ret);
> >  
> > -	if (role == USB_ROLE_HOST && info->vbus) {
> > +	if (role == USB_ROLE_HOST) {
> >  		ret = regulator_enable(info->vbus);
> >  		if (ret)
> >  			dev_err(info->dev, "enable vbus regulator failed\n");
> > @@ -106,9 +106,8 @@ static void usb_conn_detect_cable(struct work_struct *work)
> >  
> >  	info->last_role = role;
> >  
> > -	if (info->vbus)
> > -		dev_dbg(info->dev, "vbus regulator is %s\n",
> > -			regulator_is_enabled(info->vbus) ? "enabled" : "disabled");
> > +	dev_dbg(info->dev, "vbus regulator is %s\n",
> > +		regulator_is_enabled(info->vbus) ? "enabled" : "disabled");
> >  
> >  	power_supply_changed(info->charger);
> >  }
> > @@ -175,7 +174,6 @@ static int usb_conn_probe(struct platform_device *pdev)
> >  {
> >  	struct device *dev = &pdev->dev;
> >  	struct usb_conn_info *info;
> > -	bool need_vbus = true;
> >  	int ret = 0;
> >  
> >  	info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL);
> > @@ -205,23 +203,7 @@ static int usb_conn_probe(struct platform_device *pdev)
> >  
> >  	INIT_DELAYED_WORK(&info->dw_det, usb_conn_detect_cable);
> >  
> > -	/*
> > -	 * If the USB connector is a child of a USB port and that port already provides the VBUS
> > -	 * supply, there's no need for the USB connector to provide it again.
> > -	 */
> > -	if (dev->parent && dev->parent->of_node) {
> > -		if (of_find_property(dev->parent->of_node, "vbus-supply", NULL))
> > -			need_vbus = false;
> > -	}
> > -
> > -	if (!need_vbus) {
> > -		info->vbus = devm_regulator_get_optional(dev, "vbus");
> > -		if (PTR_ERR(info->vbus) == -ENODEV)
> > -			info->vbus = NULL;
> > -	} else {
> > -		info->vbus = devm_regulator_get(dev, "vbus");
> > -	}
> > -
> > +	info->vbus = devm_regulator_get(dev, "vbus");
> >  	if (IS_ERR(info->vbus)) {
> >  		ret = PTR_ERR(info->vbus);
> >  		return dev_err_probe(dev, ret, "failed to get vbus :%d\n", ret);
> > @@ -288,7 +270,7 @@ static int usb_conn_remove(struct platform_device *pdev)
> >  
> >  	cancel_delayed_work_sync(&info->dw_det);
> >  
> > -	if (info->last_role == USB_ROLE_HOST && info->vbus)
> > +	if (info->last_role == USB_ROLE_HOST)
> >  		regulator_disable(info->vbus);
> >  
> >  	usb_role_switch_put(info->role_sw);
> > -- 
> > 2.18.0
> > 

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

WARNING: multiple messages have this Message-ID (diff)
From: Chunfeng Yun <chunfeng.yun@mediatek.com>
To: Thierry Reding <treding@nvidia.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Paul Cercueil <paul@crapouillou.net>,
	Lee Jones <lee.jones@linaro.org>, <linux-usb@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>
Subject: Re: [PATCH v2 3/3] Revert "usb: common: usb-conn-gpio: Make VBUS supply optional"
Date: Mon, 24 May 2021 13:51:51 +0800	[thread overview]
Message-ID: <1621835511.26501.14.camel@mhfsdcap03> (raw)
In-Reply-To: <YKezl0nlWFQhLyf/@orome.fritz.box>

On Fri, 2021-05-21 at 15:20 +0200, Thierry Reding wrote:
> On Wed, May 19, 2021 at 02:39:46PM +0800, Chunfeng Yun wrote:
> > Vbus is already an optional supply, if the vbus-supply is not
> > provided in DTS, will use a dummy regulator,
> 
> That statement is not entirely correct. The dummy regulator is
> substituted only if the supply is in fact not optional. The idea behind
> that is to allow DTS files that don't specify all required regulators to
> get away with it, based on the assumption that the supply is one of
> those always-on supplies that are often not described in DTS.
Yes, you are right.
But from the point of result, it indeed can help to handle the absent
regulator.
> 
> > the warning log is as below:
> > "supply vbus not found, using dummy regulator"
> 
> And the reason why we get that warning is to point out that the DTS has
> a bug and that it should be fixed (by adding a proper regulator to take
> the place of the dummy).
> 
> > This reverts commit 4ddf1ac79e5f082451cd549283d2eb7559ab6ca9.
> 
> But if you read the description of that commit, the purpose of that
> patch was in fact to make the supply completely optional in the case
> where we already have the VBUS supply specified for the USB port that
> the connector is parented to.
Could you please give an example you mentioned?

It seems prefer to provide vbus supply in connector instead of port
according to dt-binding

Thanks

> 
> So in that case the DTS doesn't have the bug because the VBUS supply is
> already specified for the USB port and therefore it doesn't have to be
> specified in the USB connector again. In fact, specifying it twice can
> lead to a situation where the USB port may not be able to switch the
> VBUS supply on or off because the setting might conflict with that of
> the USB connector.

> 
> So unless there's a real reason why this is needed, I don't think this
> should be applied.
> 
> Thierry
> 
> > Cc: Thierry Reding <treding@nvidia.com>
> > Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> > ---
> > v2: remove unused variable "need_vbus"
> > ---
> >  drivers/usb/common/usb-conn-gpio.c | 30 ++++++------------------------
> >  1 file changed, 6 insertions(+), 24 deletions(-)
> > 
> > diff --git a/drivers/usb/common/usb-conn-gpio.c b/drivers/usb/common/usb-conn-gpio.c
> > index dfbbc4f51ed6..65d89140cd19 100644
> > --- a/drivers/usb/common/usb-conn-gpio.c
> > +++ b/drivers/usb/common/usb-conn-gpio.c
> > @@ -91,14 +91,14 @@ static void usb_conn_detect_cable(struct work_struct *work)
> >  		return;
> >  	}
> >  
> > -	if (info->last_role == USB_ROLE_HOST && info->vbus)
> > +	if (info->last_role == USB_ROLE_HOST)
> >  		regulator_disable(info->vbus);
> >  
> >  	ret = usb_role_switch_set_role(info->role_sw, role);
> >  	if (ret)
> >  		dev_err(info->dev, "failed to set role: %d\n", ret);
> >  
> > -	if (role == USB_ROLE_HOST && info->vbus) {
> > +	if (role == USB_ROLE_HOST) {
> >  		ret = regulator_enable(info->vbus);
> >  		if (ret)
> >  			dev_err(info->dev, "enable vbus regulator failed\n");
> > @@ -106,9 +106,8 @@ static void usb_conn_detect_cable(struct work_struct *work)
> >  
> >  	info->last_role = role;
> >  
> > -	if (info->vbus)
> > -		dev_dbg(info->dev, "vbus regulator is %s\n",
> > -			regulator_is_enabled(info->vbus) ? "enabled" : "disabled");
> > +	dev_dbg(info->dev, "vbus regulator is %s\n",
> > +		regulator_is_enabled(info->vbus) ? "enabled" : "disabled");
> >  
> >  	power_supply_changed(info->charger);
> >  }
> > @@ -175,7 +174,6 @@ static int usb_conn_probe(struct platform_device *pdev)
> >  {
> >  	struct device *dev = &pdev->dev;
> >  	struct usb_conn_info *info;
> > -	bool need_vbus = true;
> >  	int ret = 0;
> >  
> >  	info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL);
> > @@ -205,23 +203,7 @@ static int usb_conn_probe(struct platform_device *pdev)
> >  
> >  	INIT_DELAYED_WORK(&info->dw_det, usb_conn_detect_cable);
> >  
> > -	/*
> > -	 * If the USB connector is a child of a USB port and that port already provides the VBUS
> > -	 * supply, there's no need for the USB connector to provide it again.
> > -	 */
> > -	if (dev->parent && dev->parent->of_node) {
> > -		if (of_find_property(dev->parent->of_node, "vbus-supply", NULL))
> > -			need_vbus = false;
> > -	}
> > -
> > -	if (!need_vbus) {
> > -		info->vbus = devm_regulator_get_optional(dev, "vbus");
> > -		if (PTR_ERR(info->vbus) == -ENODEV)
> > -			info->vbus = NULL;
> > -	} else {
> > -		info->vbus = devm_regulator_get(dev, "vbus");
> > -	}
> > -
> > +	info->vbus = devm_regulator_get(dev, "vbus");
> >  	if (IS_ERR(info->vbus)) {
> >  		ret = PTR_ERR(info->vbus);
> >  		return dev_err_probe(dev, ret, "failed to get vbus :%d\n", ret);
> > @@ -288,7 +270,7 @@ static int usb_conn_remove(struct platform_device *pdev)
> >  
> >  	cancel_delayed_work_sync(&info->dw_det);
> >  
> > -	if (info->last_role == USB_ROLE_HOST && info->vbus)
> > +	if (info->last_role == USB_ROLE_HOST)
> >  		regulator_disable(info->vbus);
> >  
> >  	usb_role_switch_put(info->role_sw);
> > -- 
> > 2.18.0
> > 

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

  parent reply	other threads:[~2021-05-24  5:52 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-19  6:39 [PATCH v2 1/3] usb: common: usb-conn-gpio: fix NULL pointer dereference of charger Chunfeng Yun
2021-05-19  6:39 ` Chunfeng Yun
2021-05-19  6:39 ` Chunfeng Yun
2021-05-19  6:39 ` [PATCH v2 2/3] usb: common: usb-conn-gpio: use dev_err_probe() to print log Chunfeng Yun
2021-05-19  6:39   ` Chunfeng Yun
2021-05-19  6:39   ` Chunfeng Yun
2021-05-19  6:39 ` [PATCH v2 3/3] Revert "usb: common: usb-conn-gpio: Make VBUS supply optional" Chunfeng Yun
2021-05-19  6:39   ` Chunfeng Yun
2021-05-19  6:39   ` Chunfeng Yun
2021-05-21 13:20   ` Thierry Reding
2021-05-21 13:20     ` Thierry Reding
2021-05-21 13:20     ` Thierry Reding
2021-05-21 18:06     ` Greg Kroah-Hartman
2021-05-21 18:06       ` Greg Kroah-Hartman
2021-05-21 18:06       ` Greg Kroah-Hartman
2021-05-24  5:51     ` Chunfeng Yun [this message]
2021-05-24  5:51       ` Chunfeng Yun
2021-05-24  5:51       ` Chunfeng Yun
2021-05-25 11:36       ` Thierry Reding
2021-05-25 11:36         ` Thierry Reding
2021-05-25 11:36         ` Thierry Reding
2021-05-26  1:44         ` Chunfeng Yun
2021-05-26  1:44           ` Chunfeng Yun
2021-05-26  1: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=1621835511.26501.14.camel@mhfsdcap03 \
    --to=chunfeng.yun@mediatek.com \
    --cc=broonie@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --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=matthias.bgg@gmail.com \
    --cc=paul@crapouillou.net \
    --cc=treding@nvidia.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 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.