All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chunfeng Yun <chunfeng.yun@mediatek.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: cy_huang <u0084500@gmail.com>, <heikki.krogerus@linux.intel.com>,
	<matthias.bgg@gmail.com>, <robh+dt@kernel.org>,
	<gregkh@linuxfoundation.org>, <linux-usb@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <cy_huang@richtek.com>,
	<gene_chen@richtek.com>, <devicetree@vger.kernel.org>
Subject: Re: [PATCH 1/2] usb typec: tcpci: mt6360: Add vsafe0v support and external vbus supply control
Date: Tue, 19 Jan 2021 15:33:32 +0800	[thread overview]
Message-ID: <1611041612.12761.9.camel@mhfsdcap03> (raw)
In-Reply-To: <3a4a88a9-f0e3-2b65-9df4-6c1d4e3f1c14@roeck-us.net>

On Sun, 2021-01-17 at 09:43 -0800, Guenter Roeck wrote:
> On 1/15/21 6:13 AM, cy_huang wrote:
> > From: ChiYuan Huang <cy_huang@richtek.com>
> > 
> > MT6360 not support for TCPC command to control source and sink.
> 
> does not
> 
> > Uses external 5V vbus regulator as the vbus source control.
> > 
> Use
> 
> > Also adds the capability to report vsafe0v.
> > 
> add
> 
> So far this driver works without regulator. Unless I am missing something,
> this patch makes regulator support mandatory, meaning existing code will fail.
If don't provide vbus-supply in DTS, regulator framework will provide a
dummy regulator, so the code will not fail.
> I am not sure if that is appropriate/acceptable. Can we be sure that this will
> work for existing users of this driver ?

> 
> Thanks,
> Guenter
> 
> > Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
> > ---
> >  drivers/usb/typec/tcpm/tcpci_mt6360.c | 29 +++++++++++++++++++++++++++++
> >  1 file changed, 29 insertions(+)
> > 
> > diff --git a/drivers/usb/typec/tcpm/tcpci_mt6360.c b/drivers/usb/typec/tcpm/tcpci_mt6360.c
> > index f1bd9e0..0edf4b6 100644
> > --- a/drivers/usb/typec/tcpm/tcpci_mt6360.c
> > +++ b/drivers/usb/typec/tcpm/tcpci_mt6360.c
> > @@ -11,6 +11,7 @@
> >  #include <linux/of.h>
> >  #include <linux/platform_device.h>
> >  #include <linux/regmap.h>
> > +#include <linux/regulator/consumer.h>
> >  #include <linux/usb/tcpm.h>
> >  
> >  #include "tcpci.h"
> > @@ -36,6 +37,7 @@ struct mt6360_tcpc_info {
> >  	struct tcpci_data tdata;
> >  	struct tcpci *tcpci;
> >  	struct device *dev;
> > +	struct regulator *vbus;
> >  	int irq;
> >  };
> >  
> > @@ -51,6 +53,27 @@ static inline int mt6360_tcpc_write16(struct regmap *regmap,
> >  	return regmap_raw_write(regmap, reg, &val, sizeof(u16));
> >  }
> >  
> > +static int mt6360_tcpc_set_vbus(struct tcpci *tcpci, struct tcpci_data *data, bool src, bool snk)
> > +{
> > +	struct mt6360_tcpc_info *mti = container_of(data, struct mt6360_tcpc_info, tdata);
> > +	int ret;
> > +
> > +	/* To correctly handle the already enabled vbus and disable its supply first */
> > +	if (regulator_is_enabled(mti->vbus)) {
> > +		ret = regulator_disable(mti->vbus);
> > +		if (ret)
> > +			return ret;
> > +	}
> 
> Is it really a good idea to disable vbus if it happens to be already enabled
> and there is (another ?) request to enable it ?
> 
> > +
> > +	if (src) {
> > +		ret = regulator_enable(mti->vbus);
> > +		if (ret)
> > +			return ret;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> >  static int mt6360_tcpc_init(struct tcpci *tcpci, struct tcpci_data *tdata)
> >  {
> >  	struct regmap *regmap = tdata->regmap;
> > @@ -138,7 +161,13 @@ static int mt6360_tcpc_probe(struct platform_device *pdev)
> >  	if (mti->irq < 0)
> >  		return mti->irq;
> >  
> > +	mti->vbus = devm_regulator_get(&pdev->dev, "vbus");
> > +	if (IS_ERR(mti->vbus))
> > +		return PTR_ERR(mti->vbus);
> > +
> >  	mti->tdata.init = mt6360_tcpc_init;
> > +	mti->tdata.set_vbus = mt6360_tcpc_set_vbus;
> > +	mti->tdata.vbus_vsafe0v = 1;
> >  	mti->tcpci = tcpci_register_port(&pdev->dev, &mti->tdata);
> >  	if (IS_ERR(mti->tcpci)) {
> >  		dev_err(&pdev->dev, "Failed to register tcpci port\n");
> > 
> 


WARNING: multiple messages have this Message-ID (diff)
From: Chunfeng Yun <chunfeng.yun@mediatek.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: gene_chen@richtek.com, devicetree@vger.kernel.org,
	heikki.krogerus@linux.intel.com, cy_huang <u0084500@gmail.com>,
	gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org, cy_huang@richtek.com,
	robh+dt@kernel.org, linux-mediatek@lists.infradead.org,
	matthias.bgg@gmail.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] usb typec: tcpci: mt6360: Add vsafe0v support and external vbus supply control
Date: Tue, 19 Jan 2021 15:33:32 +0800	[thread overview]
Message-ID: <1611041612.12761.9.camel@mhfsdcap03> (raw)
In-Reply-To: <3a4a88a9-f0e3-2b65-9df4-6c1d4e3f1c14@roeck-us.net>

On Sun, 2021-01-17 at 09:43 -0800, Guenter Roeck wrote:
> On 1/15/21 6:13 AM, cy_huang wrote:
> > From: ChiYuan Huang <cy_huang@richtek.com>
> > 
> > MT6360 not support for TCPC command to control source and sink.
> 
> does not
> 
> > Uses external 5V vbus regulator as the vbus source control.
> > 
> Use
> 
> > Also adds the capability to report vsafe0v.
> > 
> add
> 
> So far this driver works without regulator. Unless I am missing something,
> this patch makes regulator support mandatory, meaning existing code will fail.
If don't provide vbus-supply in DTS, regulator framework will provide a
dummy regulator, so the code will not fail.
> I am not sure if that is appropriate/acceptable. Can we be sure that this will
> work for existing users of this driver ?

> 
> Thanks,
> Guenter
> 
> > Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
> > ---
> >  drivers/usb/typec/tcpm/tcpci_mt6360.c | 29 +++++++++++++++++++++++++++++
> >  1 file changed, 29 insertions(+)
> > 
> > diff --git a/drivers/usb/typec/tcpm/tcpci_mt6360.c b/drivers/usb/typec/tcpm/tcpci_mt6360.c
> > index f1bd9e0..0edf4b6 100644
> > --- a/drivers/usb/typec/tcpm/tcpci_mt6360.c
> > +++ b/drivers/usb/typec/tcpm/tcpci_mt6360.c
> > @@ -11,6 +11,7 @@
> >  #include <linux/of.h>
> >  #include <linux/platform_device.h>
> >  #include <linux/regmap.h>
> > +#include <linux/regulator/consumer.h>
> >  #include <linux/usb/tcpm.h>
> >  
> >  #include "tcpci.h"
> > @@ -36,6 +37,7 @@ struct mt6360_tcpc_info {
> >  	struct tcpci_data tdata;
> >  	struct tcpci *tcpci;
> >  	struct device *dev;
> > +	struct regulator *vbus;
> >  	int irq;
> >  };
> >  
> > @@ -51,6 +53,27 @@ static inline int mt6360_tcpc_write16(struct regmap *regmap,
> >  	return regmap_raw_write(regmap, reg, &val, sizeof(u16));
> >  }
> >  
> > +static int mt6360_tcpc_set_vbus(struct tcpci *tcpci, struct tcpci_data *data, bool src, bool snk)
> > +{
> > +	struct mt6360_tcpc_info *mti = container_of(data, struct mt6360_tcpc_info, tdata);
> > +	int ret;
> > +
> > +	/* To correctly handle the already enabled vbus and disable its supply first */
> > +	if (regulator_is_enabled(mti->vbus)) {
> > +		ret = regulator_disable(mti->vbus);
> > +		if (ret)
> > +			return ret;
> > +	}
> 
> Is it really a good idea to disable vbus if it happens to be already enabled
> and there is (another ?) request to enable it ?
> 
> > +
> > +	if (src) {
> > +		ret = regulator_enable(mti->vbus);
> > +		if (ret)
> > +			return ret;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> >  static int mt6360_tcpc_init(struct tcpci *tcpci, struct tcpci_data *tdata)
> >  {
> >  	struct regmap *regmap = tdata->regmap;
> > @@ -138,7 +161,13 @@ static int mt6360_tcpc_probe(struct platform_device *pdev)
> >  	if (mti->irq < 0)
> >  		return mti->irq;
> >  
> > +	mti->vbus = devm_regulator_get(&pdev->dev, "vbus");
> > +	if (IS_ERR(mti->vbus))
> > +		return PTR_ERR(mti->vbus);
> > +
> >  	mti->tdata.init = mt6360_tcpc_init;
> > +	mti->tdata.set_vbus = mt6360_tcpc_set_vbus;
> > +	mti->tdata.vbus_vsafe0v = 1;
> >  	mti->tcpci = tcpci_register_port(&pdev->dev, &mti->tdata);
> >  	if (IS_ERR(mti->tcpci)) {
> >  		dev_err(&pdev->dev, "Failed to register tcpci port\n");
> > 
> 

_______________________________________________
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: Guenter Roeck <linux@roeck-us.net>
Cc: gene_chen@richtek.com, devicetree@vger.kernel.org,
	heikki.krogerus@linux.intel.com, cy_huang <u0084500@gmail.com>,
	gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org, cy_huang@richtek.com,
	robh+dt@kernel.org, linux-mediatek@lists.infradead.org,
	matthias.bgg@gmail.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/2] usb typec: tcpci: mt6360: Add vsafe0v support and external vbus supply control
Date: Tue, 19 Jan 2021 15:33:32 +0800	[thread overview]
Message-ID: <1611041612.12761.9.camel@mhfsdcap03> (raw)
In-Reply-To: <3a4a88a9-f0e3-2b65-9df4-6c1d4e3f1c14@roeck-us.net>

On Sun, 2021-01-17 at 09:43 -0800, Guenter Roeck wrote:
> On 1/15/21 6:13 AM, cy_huang wrote:
> > From: ChiYuan Huang <cy_huang@richtek.com>
> > 
> > MT6360 not support for TCPC command to control source and sink.
> 
> does not
> 
> > Uses external 5V vbus regulator as the vbus source control.
> > 
> Use
> 
> > Also adds the capability to report vsafe0v.
> > 
> add
> 
> So far this driver works without regulator. Unless I am missing something,
> this patch makes regulator support mandatory, meaning existing code will fail.
If don't provide vbus-supply in DTS, regulator framework will provide a
dummy regulator, so the code will not fail.
> I am not sure if that is appropriate/acceptable. Can we be sure that this will
> work for existing users of this driver ?

> 
> Thanks,
> Guenter
> 
> > Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
> > ---
> >  drivers/usb/typec/tcpm/tcpci_mt6360.c | 29 +++++++++++++++++++++++++++++
> >  1 file changed, 29 insertions(+)
> > 
> > diff --git a/drivers/usb/typec/tcpm/tcpci_mt6360.c b/drivers/usb/typec/tcpm/tcpci_mt6360.c
> > index f1bd9e0..0edf4b6 100644
> > --- a/drivers/usb/typec/tcpm/tcpci_mt6360.c
> > +++ b/drivers/usb/typec/tcpm/tcpci_mt6360.c
> > @@ -11,6 +11,7 @@
> >  #include <linux/of.h>
> >  #include <linux/platform_device.h>
> >  #include <linux/regmap.h>
> > +#include <linux/regulator/consumer.h>
> >  #include <linux/usb/tcpm.h>
> >  
> >  #include "tcpci.h"
> > @@ -36,6 +37,7 @@ struct mt6360_tcpc_info {
> >  	struct tcpci_data tdata;
> >  	struct tcpci *tcpci;
> >  	struct device *dev;
> > +	struct regulator *vbus;
> >  	int irq;
> >  };
> >  
> > @@ -51,6 +53,27 @@ static inline int mt6360_tcpc_write16(struct regmap *regmap,
> >  	return regmap_raw_write(regmap, reg, &val, sizeof(u16));
> >  }
> >  
> > +static int mt6360_tcpc_set_vbus(struct tcpci *tcpci, struct tcpci_data *data, bool src, bool snk)
> > +{
> > +	struct mt6360_tcpc_info *mti = container_of(data, struct mt6360_tcpc_info, tdata);
> > +	int ret;
> > +
> > +	/* To correctly handle the already enabled vbus and disable its supply first */
> > +	if (regulator_is_enabled(mti->vbus)) {
> > +		ret = regulator_disable(mti->vbus);
> > +		if (ret)
> > +			return ret;
> > +	}
> 
> Is it really a good idea to disable vbus if it happens to be already enabled
> and there is (another ?) request to enable it ?
> 
> > +
> > +	if (src) {
> > +		ret = regulator_enable(mti->vbus);
> > +		if (ret)
> > +			return ret;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> >  static int mt6360_tcpc_init(struct tcpci *tcpci, struct tcpci_data *tdata)
> >  {
> >  	struct regmap *regmap = tdata->regmap;
> > @@ -138,7 +161,13 @@ static int mt6360_tcpc_probe(struct platform_device *pdev)
> >  	if (mti->irq < 0)
> >  		return mti->irq;
> >  
> > +	mti->vbus = devm_regulator_get(&pdev->dev, "vbus");
> > +	if (IS_ERR(mti->vbus))
> > +		return PTR_ERR(mti->vbus);
> > +
> >  	mti->tdata.init = mt6360_tcpc_init;
> > +	mti->tdata.set_vbus = mt6360_tcpc_set_vbus;
> > +	mti->tdata.vbus_vsafe0v = 1;
> >  	mti->tcpci = tcpci_register_port(&pdev->dev, &mti->tdata);
> >  	if (IS_ERR(mti->tcpci)) {
> >  		dev_err(&pdev->dev, "Failed to register tcpci port\n");
> > 
> 

_______________________________________________
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-01-19  7:36 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-15 14:13 [PATCH 1/2] usb typec: tcpci: mt6360: Add vsafe0v support and external vbus supply control cy_huang
2021-01-15 14:13 ` cy_huang
2021-01-15 14:13 ` cy_huang
2021-01-15 14:13 ` [PATCH 2/2] usb typec: tcpci: mt6360: Add vbus supply into dt-binding description cy_huang
2021-01-15 14:13   ` cy_huang
2021-01-15 14:13   ` cy_huang
2021-01-17 15:45   ` Rob Herring
2021-01-17 15:45     ` Rob Herring
2021-01-17 15:45     ` Rob Herring
2021-01-18  8:33     ` ChiYuan Huang
2021-01-18  8:33       ` ChiYuan Huang
2021-01-18  8:33       ` ChiYuan Huang
2021-01-19 23:10   ` Rob Herring
2021-01-19 23:10     ` Rob Herring
2021-01-19 23:10     ` Rob Herring
2021-01-20  1:50     ` ChiYuan Huang
2021-01-20  1:50       ` ChiYuan Huang
2021-01-20  1:50       ` ChiYuan Huang
2021-01-17 17:43 ` [PATCH 1/2] usb typec: tcpci: mt6360: Add vsafe0v support and external vbus supply control Guenter Roeck
2021-01-17 17:43   ` Guenter Roeck
2021-01-17 17:43   ` Guenter Roeck
2021-01-18  8:28   ` ChiYuan Huang
2021-01-18  8:28     ` ChiYuan Huang
2021-01-18  8:28     ` ChiYuan Huang
2021-01-19  7:37     ` Chunfeng Yun
2021-01-19  7:37       ` Chunfeng Yun
2021-01-19  7:37       ` Chunfeng Yun
2021-01-19  8:23       ` ChiYuan Huang
2021-01-19  8:23         ` ChiYuan Huang
2021-01-19  8:23         ` ChiYuan Huang
2021-03-29 14:12         ` ChiYuan Huang
2021-03-29 14:12           ` ChiYuan Huang
2021-03-29 14:12           ` ChiYuan Huang
2021-01-19  7:33   ` Chunfeng Yun [this message]
2021-01-19  7:33     ` Chunfeng Yun
2021-01-19  7:33     ` Chunfeng Yun
2021-01-19  8:21     ` ChiYuan Huang
2021-01-19  8:21       ` ChiYuan Huang
2021-01-19  8:21       ` ChiYuan Huang

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=1611041612.12761.9.camel@mhfsdcap03 \
    --to=chunfeng.yun@mediatek.com \
    --cc=cy_huang@richtek.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gene_chen@richtek.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.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=linux@roeck-us.net \
    --cc=matthias.bgg@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=u0084500@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 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.