linux-kernel - Re: [PATCH 1/3] usb: typec: Add QCOM PMIC typec detection driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 10 Jun 2020 12:37:57 -0700
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Jack Pham <jackp@...eaurora.org>
Cc:     Wesley Cheng <wcheng@...eaurora.org>,
        heikki.krogerus@...ux.intel.com, gregkh@...uxfoundation.org,
        mark.rutland@....com, robh+dt@...nel.org, agross@...nel.org,
        linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-usb@...r.kernel.org,
        bryan.odonoghue@...aro.org
Subject: Re: [PATCH 1/3] usb: typec: Add QCOM PMIC typec detection driver

On Tue 09 Jun 18:20 PDT 2020, Jack Pham wrote:

> Hi Wesley,
> 
> On Tue, Jun 09, 2020 at 01:58:49PM -0700, Wesley Cheng wrote:
> > The QCOM SPMI typec driver handles the role and orientation detection, and
> > notifies client drivers using the USB role switch framework.   It registers
> > as a typec port, so orientation can be communicated using the typec switch
> > APIs.  The driver also registers the VBUS output regulator, so client
> 
> Doesn't look like it.. As we discussed in earlier revisions we decided
> to drop the regulator.
> 
> > drivers can enable the VBUS source when acting as a source/host.
> > 
> > Signed-off-by: Wesley Cheng <wcheng@...eaurora.org>
> > ---
> >  drivers/usb/typec/Kconfig           |  11 ++
> >  drivers/usb/typec/Makefile          |   1 +
> >  drivers/usb/typec/qcom-pmic-typec.c | 278 ++++++++++++++++++++++++++++++++++++
> >  3 files changed, 290 insertions(+)
> >  create mode 100644 drivers/usb/typec/qcom-pmic-typec.c
> > 
> > diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
> > index 559dd06..8de2520 100644
> > --- a/drivers/usb/typec/Kconfig
> > +++ b/drivers/usb/typec/Kconfig
> > @@ -73,6 +73,17 @@ config TYPEC_TPS6598X
> >  	  If you choose to build this driver as a dynamically linked module, the
> >  	  module will be called tps6598x.ko.
> >  
> > +config TYPEC_QCOM_PMIC
> > +	tristate "Qualcomm PMIC USB typec driver"
> > +	depends on ARCH_QCOM
> > +	help
> > +	  Driver for supporting role switch over the Qualcomm PMIC.  This will
> > +	  handle the type C role and orientation detection reported by the QCOM
> > +	  PMIC if the PMIC has the capability to handle type C detection.
> > +
> > +	  It will also enable the VBUS output to connected devices when a
> > +	  DFP connection is made.
> > +
> >  source "drivers/usb/typec/mux/Kconfig"
> >  
> >  source "drivers/usb/typec/altmodes/Kconfig"
> > diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
> > index 7753a5c3..cceffd9 100644
> > --- a/drivers/usb/typec/Makefile
> > +++ b/drivers/usb/typec/Makefile
> > @@ -6,4 +6,5 @@ obj-$(CONFIG_TYPEC_TCPM)	+= tcpm/
> >  obj-$(CONFIG_TYPEC_UCSI)	+= ucsi/
> >  obj-$(CONFIG_TYPEC_HD3SS3220)	+= hd3ss3220.o
> >  obj-$(CONFIG_TYPEC_TPS6598X)	+= tps6598x.o
> > +obj-$(CONFIG_TYPEC_QCOM_PMIC)	+= qcom-pmic-typec.o
> >  obj-$(CONFIG_TYPEC)		+= mux/
> > diff --git a/drivers/usb/typec/qcom-pmic-typec.c b/drivers/usb/typec/qcom-pmic-typec.c
> > new file mode 100644
> > index 0000000..ce6319c
> > --- /dev/null
> > +++ b/drivers/usb/typec/qcom-pmic-typec.c
> > @@ -0,0 +1,278 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2020, The Linux Foundation. All rights reserved.
> > + */
> > +
> > +#include <linux/err.h>
> > +#include <linux/regmap.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/slab.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/of_irq.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/of_device.h>
> > +#include <linux/usb/role.h>
> > +#include <linux/usb/typec_mux.h>
> > +#include <linux/workqueue.h>
> > +#include <linux/regulator/consumer.h>
> > +#include <linux/regulator/driver.h>
> > +#include <linux/regulator/machine.h>
> > +
> > +#define DCDC_BASE			0x1100
> 
> along with USB_BASE @ 0x1300, is it ok to allow this driver to access
> registers outside of its 'reg' base (0x1500 according to the DT
> bindings)?
> 

Depending on how entangled a future driver for the charger blocks would
be one could either just upstream a dcdc regulator driver to control
vbus today, or a "lite version" of a charging driver exposing just the
vbus regulator.

Either way I would prefer this over poking the register directly from
this driver, as it will make it tricky to migrate to a proper charger
driver later.

Regards,
Bjorn