from:"Wesley"

Some Qualcomm PMICs have the capability to source the VBUS output to
connected peripherals.  This driver will register a regulator to the
regulator list to enable or disable this source by an external driver.

Signed-off-by: Wesley Cheng 
---
 drivers/regulator/Kconfig   | 10 +++
 drivers/regulator/Makefile  |  1 +
 drivers/regulator/qcom_usb_vbus-regulator.c | 97 +
 3 files changed, 108 insertions(+)
 create mode 100644 drivers/regulator/qcom_usb_vbus-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 074a2ef55943..273d85a45263 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -797,6 +797,16 @@ config REGULATOR_QCOM_SPMI
  Qualcomm SPMI PMICs as a module. The module will be named
  "qcom_spmi-regulator".
 
+config REGULATOR_QCOM_USB_VBUS
+   tristate "Qualcomm USB Vbus regulator driver"
+   depends on SPMI || COMPILE_TEST
+   help
+ If you say yes to this option, support will be included for the
+ regulator used to enable the VBUS output.
+
+ Say M here if you want to include support for enabling the VBUS output
+ as a module. The module will be named "qcom_usb_vbus_regulator".
+
 config REGULATOR_RC5T583
tristate "RICOH RC5T583 Power regulators"
depends on MFD_RC5T583
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index c0d6b96ebd78..cbab28aa7b56 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -89,6 +89,7 @@ obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_SPMI) += qcom_spmi-regulator.o
+obj-$(CONFIG_REGULATOR_QCOM_USB_VBUS) += qcom_usb_vbus-regulator.o
 obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o
 obj-$(CONFIG_REGULATOR_PFUZE100) += pfuze100-regulator.o
 obj-$(CONFIG_REGULATOR_PV88060) += pv88060-regulator.o
diff --git a/drivers/regulator/qcom_usb_vbus-regulator.c 
b/drivers/regulator/qcom_usb_vbus-regulator.c
new file mode 100644
index ..342d92373598
--- /dev/null
+++ b/drivers/regulator/qcom_usb_vbus-regulator.c
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: GPL-2.0-only
+//
+// Qualcomm PMIC VBUS output regulator driver
+//
+// Copyright (c) 2020, The Linux Foundation. All rights reserved.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CMD_OTG0x40
+#define OTG_EN BIT(0)
+#define OTG_CFG0x53
+#define OTG_EN_SRC_CFG BIT(1)
+
+static const struct regulator_ops qcom_usb_vbus_reg_ops = {
+   .enable = regulator_enable_regmap,
+   .disable = regulator_disable_regmap,
+   .is_enabled = regulator_is_enabled_regmap,
+};
+
+static struct regulator_desc qcom_usb_vbus_rdesc = {
+   .name = "usb_vbus",
+   .ops = &qcom_usb_vbus_reg_ops,
+   .owner = THIS_MODULE,
+   .type = REGULATOR_VOLTAGE,
+};
+
+static int qcom_usb_vbus_regulator_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct regulator_dev *rdev;
+   struct regmap *regmap;
+   struct regulator_config config = { };
+   struct regulator_init_data *init_data;
+   int ret;
+   u32 base;
+
+   ret = of_property_read_u32(dev->of_node, "reg", &base);
+   if (ret < 0) {
+   dev_err(dev, "no base address found\n");
+   return ret;
+   }
+
+   regmap = dev_get_regmap(dev->parent, NULL);
+   if (regmap) {
+   dev_err(dev, "Failed to get regmap\n");
+   return -ENOENT;
+   }
+
+   init_data = of_get_regulator_init_data(dev, dev->of_node,
+  &qcom_usb_vbus_rdesc);
+   if (!init_data)
+   return -ENOMEM;
+
+   qcom_usb_vbus_rdesc.enable_reg = base + CMD_OTG;
+   qcom_usb_vbus_rdesc.enable_mask = OTG_EN;
+   config.dev = dev;
+   config.init_data = init_data;
+   config.regmap = regmap;
+
+   rdev = devm_regulator_register(dev, &qcom_usb_vbus_rdesc, &config);
+   if (IS_ERR(rdev)) {
+   ret = PTR_ERR(rdev);
+   dev_err(dev, "not able to register vbus reg %d\n", ret);
+   return ret;
+   }
+
+   /* Disable HW logic for VBUS enable */
+   regmap_update_bits(regmap, base + OTG_CFG, OTG_EN_SRC_CFG, 0);
+
+   return 0;
+}
+
+static const struct of_device_id qcom_usb_vbus_regulator_match[] = {
+   { .compatible = "qcom,pm8150b-vbus-reg" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, qcom_usb_vbus_regulator_match);
+
+static struct platform_driver qcom_usb

[PATCH v5 2/6] dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding

Introduce the dt-binding for enabling USB type C orientation and role
detection using the PM8150B.  The driver will be responsible for receiving
the interrupt at a state change on the CC lines, reading the orientation/role,
and communicating this information to the remote clients, which can include
a role switch node and a type C switch.

Signed-off-by: Wesley Cheng 
---
 .../bindings/usb/qcom,pmic-typec.yaml | 130 ++
 1 file changed, 130 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml

diff --git a/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml 
b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
new file mode 100644
index ..735b1f74664b
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
@@ -0,0 +1,130 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/usb/qcom,pmic-typec.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Qualcomm PMIC based USB type C Detection Driver
+
+maintainers:
+  - Wesley Cheng 
+
+description: |
+  Qualcomm PMIC Type C Detect
+
+properties:
+  compatible:
+enum:
+  - qcom,pm8150b-usb-typec
+
+  reg:
+maxItems: 1
+description: Type C base address
+
+  interrupts:
+maxItems: 1
+description: CC change interrupt from PMIC
+
+  connector:
+description: Connector type for remote endpoints
+type: object
+$ref: /schemas/connector/usb-connector.yaml#
+
+properties:
+  compatible:
+enum:
+  - usb-c-connector
+
+  power-role:
+   enum:
+ - dual
+ - source
+ - sink
+
+  data-role:
+enum:
+  - dual
+  - host
+  - device
+
+  ports:
+description: Remote endpoint connections
+type: object
+
+properties:
+  port@0:
+description: Remote endpoints for the High Speed path
+type: object
+
+  port@1:
+description: Remote endpoints for the Super Speed path
+type: object
+
+properties:
+  endpoint@0:
+description: Connection to USB type C mux node
+type: object
+
+properties:
+  remote-endpoint:
+maxItems: 1
+description: Node reference to the type C mux
+
+  endpoint@1:
+description: Connection to role switch node
+type: object
+
+properties:
+  remote-endpoint:
+maxItems: 1
+description: Node reference to the role switch node
+
+required:
+  - compatible
+
+required:
+  - compatible
+  - interrupts
+  - connector
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+pm8150b {
+#address-cells = <1>;
+#size-cells = <0>;
+pm8150b_typec: typec@1500 {
+compatible = "qcom,pm8150b-usb-typec";
+reg = <0x1500>;
+interrupts = <0x2 0x15 0x5 IRQ_TYPE_EDGE_RISING>;
+
+connector {
+compatible = "usb-c-connector";
+power-role = "dual";
+data-role = "dual";
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+reg = <0>;
+};
+port@1 {
+reg = <1>;
+#address-cells = <1>;
+#size-cells = <0>;
+usb3_data_ss: endpoint@0 {
+reg = <0>;
+remote-endpoint = <&qmp_ss_mux>;
+};
+usb3_role: endpoint@1 {
+reg = <1>;
+remote-endpoint = <&dwc3_drd_switch>;
+};
+};
+};
+};
+};
+};
+...
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v5 0/6] Introduce PMIC based USB type C detection

Changes in v5:
 - Fix dt_binding_check warning/error in qcom,pmic-typec.yaml

Changes in v4:
 - Modified qcom,pmic-typec binding to include the SS mux and the DRD remote
   endpoint nodes underneath port@1, which is assigned to the SSUSB path
   according to usb-connector
 - Added usb-connector reference to the typec dt-binding
 - Added tags to the usb type c and vbus nodes
 - Removed "qcom" tags from type c and vbus nodes
 - Modified Kconfig module name, and removed module alias from the typec driver
 
Changes in v3:
 - Fix driver reference to match driver name in Kconfig for
   qcom_usb_vbus-regulator.c
 - Utilize regulator bitmap helpers for enable, disable and is enabled calls in
   qcom_usb_vbus-regulator.c
 - Use of_get_regulator_init_data() to initialize regulator init data, and to
   set constraints in qcom_usb_vbus-regulator.c
 - Remove the need for a local device structure in the vbus regulator driver
 
Changes in v2:
 - Use devm_kzalloc() in qcom_pmic_typec_probe()
 - Add checks to make sure return value of typec_find_port_power_role() is
   valid
 - Added a VBUS output regulator driver, which will be used by the PMIC USB
   type c driver to enable/disable the source
 - Added logic to control vbus source from the PMIC type c driver when
   UFP/DFP is detected
 - Added dt-binding for this new regulator driver
 - Fixed Kconfig typec notation to match others
 - Leave type C block disabled until enabled by a platform DTS

Add the required drivers for implementing type C orientation and role
detection using the Qualcomm PMIC.  Currently, PMICs such as the PM8150B
have an integrated type C block, which can be utilized for this.  This
series adds the dt-binding, PMIC type C driver, and DTS nodes.

The PMIC type C driver will register itself as a type C port w/ a
registered type C switch for orientation, and will fetch a USB role switch
handle for the role notifications.  It will also have the ability to enable
the VBUS output to any connected devices based on if the device is behaving
as a UFP or DFP.

Wesley Cheng (6):
  usb: typec: Add QCOM PMIC typec detection driver
  dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding
  arm64: boot: dts: qcom: pm8150b: Add node for USB type C block
  regulator: Add support for QCOM PMIC VBUS booster
  dt-bindings: regulator: Add dt-binding for QCOM PMIC VBUS output
regulator
  arm64: boot: dts: qcom: pm8150b: Add DTS node for PMIC VBUS booster

 .../regulator/qcom,usb-vbus-regulator.yaml|  41 +++
 .../bindings/usb/qcom,pmic-typec.yaml | 130 +
 arch/arm64/boot/dts/qcom/pm8150b.dtsi |  13 +
 arch/arm64/boot/dts/qcom/sm8150-mtp.dts   |   4 +
 drivers/regulator/Kconfig |  10 +
 drivers/regulator/Makefile|   1 +
 drivers/regulator/qcom_usb_vbus-regulator.c   |  97 ++
 drivers/usb/typec/Kconfig |  12 +
 drivers/usb/typec/Makefile|   1 +
 drivers/usb/typec/qcom-pmic-typec.c   | 275 ++
 10 files changed, 584 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
 create mode 100644 Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
 create mode 100644 drivers/regulator/qcom_usb_vbus-regulator.c
 create mode 100644 drivers/usb/typec/qcom-pmic-typec.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v5 1/6] usb: typec: Add QCOM PMIC typec detection driver

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 attains a handle to the VBUS output regulator, so it
can enable/disable the VBUS source when acting as a host/device.

Signed-off-by: Wesley Cheng 
Acked-by: Heikki Krogerus 
---
 drivers/usb/typec/Kconfig   |  12 ++
 drivers/usb/typec/Makefile  |   1 +
 drivers/usb/typec/qcom-pmic-typec.c | 275 
 3 files changed, 288 insertions(+)
 create mode 100644 drivers/usb/typec/qcom-pmic-typec.c

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index b4f2aac7ae8a..595c14766e99 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -72,6 +72,18 @@ 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 Type-C driver"
+   depends on ARCH_QCOM
+   help
+ Driver for supporting role switch over the Qualcomm PMIC.  This will
+ handle the USB Type-C role and orientation detection reported by the
+ QCOM PMIC if the PMIC has the capability to handle USB 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 7753a5c3cd46..cceffd987643 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 ..5ae3af03c638
--- /dev/null
+++ b/drivers/usb/typec/qcom-pmic-typec.c
@@ -0,0 +1,275 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TYPEC_MISC_STATUS  0xb
+#define CC_ATTACHEDBIT(0)
+#define CC_ORIENTATION BIT(1)
+#define SNK_SRC_MODE   BIT(6)
+#define TYPEC_MODE_CFG 0x44
+#define TYPEC_DISABLE_CMD  BIT(0)
+#define EN_SNK_ONLYBIT(1)
+#define EN_SRC_ONLYBIT(2)
+#define TYPEC_VCONN_CONTROL0x46
+#define VCONN_EN_SRC   BIT(0)
+#define VCONN_EN_VAL   BIT(1)
+#define TYPEC_EXIT_STATE_CFG   0x50
+#define SEL_SRC_UPPER_REF  BIT(2)
+#define TYPEC_INTR_EN_CFG_10x5e
+#define TYPEC_INTR_EN_CFG_1_MASK   GENMASK(7, 0)
+
+struct qcom_pmic_typec {
+   struct device   *dev;
+   struct fwnode_handle*fwnode;
+   struct regmap   *regmap;
+   u32 base;
+
+   struct typec_capability *cap;
+   struct typec_port   *port;
+   struct usb_role_switch *role_sw;
+
+   struct regulator*vbus_reg;
+   boolvbus_enabled;
+};
+
+static void qcom_pmic_typec_enable_vbus_regulator(struct qcom_pmic_typec
+   *qcom_usb, bool enable)
+{
+   int ret = 0;
+
+   if (enable == qcom_usb->vbus_enabled)
+   return;
+
+   if (!qcom_usb->vbus_reg) {
+   qcom_usb->vbus_reg = devm_regulator_get(qcom_usb->dev,
+   "usb_vbus");
+   if (IS_ERR(qcom_usb->vbus_reg)) {
+   qcom_usb->vbus_reg = NULL;
+   return;
+   }
+   }
+
+   if (enable) {
+   ret = regulator_enable(qcom_usb->vbus_reg);
+   if (ret)
+   return;
+   } else {
+   ret = regulator_disable(qcom_usb->vbus_reg);
+   if (ret)
+   return;
+   }
+   qcom_usb->vbus_enabled = enable;
+}
+
+static void qcom_pmic_typec_check_connection(struct qcom_pmic_typec *qcom_usb)
+{
+   enum typec_orientation orientation;
+   enum usb_role role;
+   unsigned int stat;
+   bool enable_vbus;
+
+   regmap_read(qcom_usb->regmap, qcom_usb->base + TYPEC_MISC_STATUS,
+   &stat);
+
+   if (stat

[PATCH v5 6/6] arm64: boot: dts: qcom: pm8150b: Add DTS node for PMIC VBUS booster

Add the required DTS node for the USB VBUS output regulator, which is
available on PM8150B.  This will provide the VBUS source to connected
peripherals.

Signed-off-by: Wesley Cheng 
---
 arch/arm64/boot/dts/qcom/pm8150b.dtsi   | 6 ++
 arch/arm64/boot/dts/qcom/sm8150-mtp.dts | 4 
 2 files changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi 
b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
index 91b870345dda..18f64bca73bc 100644
--- a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
@@ -22,6 +22,12 @@ power-on@800 {
status = "disabled";
};
 
+pm8150b_vbus: dcdc@1100 {
+   compatible = "qcom,pm8150b-vbus-reg";
+   status = "disabled";
+   reg = <0x1100>;
+   };
+
pm8150b_typec: typec@1500 {
compatible = "qcom,pm8150b-usb-typec";
status = "disabled";
diff --git a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts 
b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
index 6c6325c3af59..ba3b5b802954 100644
--- a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
@@ -409,6 +409,10 @@ &ufs_mem_phy {
vdda-pll-max-microamp = <19000>;
 };
 
+&pm8150b_vbus {
+   status = "okay";
+};
+
 &usb_1_hsphy {
status = "okay";
vdda-pll-supply = <&vdd_usb_hs_core>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v5 5/6] dt-bindings: regulator: Add dt-binding for QCOM PMIC VBUS output regulator

This describes how to enable the Qualcomm PMIC VBUS booster used for
providing power to connected USB peripherals when the USB role is host
mode.  The driver itself will register the vbus_usb regulator, so that
external drivers can utilize the enable/disable regulator APIs.

Signed-off-by: Wesley Cheng 
---
 .../regulator/qcom,usb-vbus-regulator.yaml| 41 +++
 1 file changed, 41 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml

diff --git 
a/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml 
b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
new file mode 100644
index ..12ed98c28aaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/qcom,usb-vbus-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: The Qualcomm PMIC VBUS output regulator driver
+
+maintainers:
+  - Wesley Cheng 
+
+description: |
+  This regulator driver controls the VBUS output by the Qualcomm PMIC.  This
+  regulator will be enabled in situations where the device is required to
+  provide power to the connected peripheral.
+
+properties:
+  compatible:
+enum:
+  - qcom,pm8150b-vbus-reg
+
+  reg:
+maxItems: 1
+description: VBUS output base address
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+ pm8150b {
+#address-cells = <1>;
+#size-cells = <0>;
+pm8150b_vbus: dcdc@1100 {
+compatible = "qcom,pm8150b-vbus-reg";
+reg = <0x1100>;
+};
+ };
+...
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v5 3/6] arm64: boot: dts: qcom: pm8150b: Add node for USB type C block

The PM8150B has a dedicated USB type C block, which can be used for type C
orientation and role detection.  Create the reference node to this type C
block for further use.

Signed-off-by: Wesley Cheng 
---
 arch/arm64/boot/dts/qcom/pm8150b.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi 
b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
index 322379d5c31f..91b870345dda 100644
--- a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
@@ -22,6 +22,13 @@ power-on@800 {
status = "disabled";
};
 
+   pm8150b_typec: typec@1500 {
+   compatible = "qcom,pm8150b-usb-typec";
+   status = "disabled";
+   reg = <0x1500>;
+   interrupts = <0x2 0x15 0x5 IRQ_TYPE_EDGE_RISING>;
+   };
+
adc@3100 {
compatible = "qcom,spmi-adc5";
reg = <0x3100>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: PE module: 'not' logic conditions will match on non-PE files - should pe functions first check if file is PE ?

2020-07-01 Thread Wesley Shields

This is likely due to the change made recently where comparing with UNDEFINED 
values now evaluates to false. It used to evaluate to UNDEFINED.

> But shouldn't pe module conditions check first if the file is a PE header or 
> valid base PE, then fail if the file isn't ?

Functions in the pe module do check if they are accessing UNDEFINED fields and 
return UNDEFINED accordingly. This is the behavior of things like 
"pe.exports()" and others. In your case you have a couple of things going on...

1) You are using "pe.section_index()" which will return UNDEFINED on a non-PE 
file. This means you are accessing pe.sections[UNDEFINED] which is also 
UNDEFINED.

2) You are then accessing the name attribute of an UNDEFINED value which is 
also resulting in an UNDEFINED value.

3) You end up with 'not UNDEFINED contains ".text"' which as of a somewhat 
recent change evaluates to "not false".

This is all because of a recent change where comparisons (including contains) 
with UNDEFINED values result in false.

It's arguable that this is the right change (and to be honest, I don't remember 
why it was changed) but one thing you can do is prefix your condition with 
"pe.is_pe and ..."

-- WXS

> On Jul 1, 2020, at 2:34 PM, Wes Hurd <13hu...@gmail.com> wrote:
> 
> Hi,
> 
> Wanted to post here before raising an issue on github project:
> 
> To reproduce:
> import "pe"
> 
> rule pe_on_nonpe
> {
> condition:
>   not pe.sections[pe.section_index(pe.entry_point)].name contains ".text"
> }
> 
> 
> 
> Run on non-PE file (e.g. Excel document zip)
> yara pe_on_nonpe.yara excel_doc.xlsx
> The rule matches on non-PE files
> 
> But shouldn't pe module conditions check first if the file is a PE header or 
> valid base PE, then fail if the file isn't ? 
> So pe.sections implies the file is PE, does check for valid PE first 
> 
> Regards,
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "YARA" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to yara-project+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/yara-project/558ba95d-4f7c-4bd7-a8bb-71fab8c97db0o%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"YARA" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to yara-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/yara-project/8BDBC9BC-BC20-43F3-86E7-2915154EB077%40atarininja.org.

Re: [casper] Compiling for roach2 on RHEL7

2020-06-30 Thread Wesley New

As someone who has tried plenty of combinations of Matlab, Xilinx and OS
versions over the years with varying success. I would recommend installing
a VM with the supported versions. If you are keen to maximize compile
resources try using lxc or chroot.

Good luck.

On Tue, 30 Jun 2020, 10:55 PM Jonathon Kocz,  wrote:

> Hi Michael,
>
> You might be able to get 2014b to play nicely with the toolflow, but 2013b
> was the last supported version for ISE 14.7, so it would be better to go
> with that if you can. What sort of OS errors are you getting?
>
> One alternative, if you can't get RHEL to work, might be to create a VM of
> e.g. ubuntu 16.04 or similar to spin up when you need to do ROACH2 work.
>
> Cheers,
> Jonathon
>
>
>
> On Tue, 30 Jun 2020 at 13:29, Michael D'Cruze <
> michael.dcr...@manchester.ac.uk> wrote:
>
>> Hi everyone,
>>
>>
>>
>> I’m clutching at straws a little, but I’ve recently obtained a RHEL7
>> system for use with the Vivado toolflow. What we’d really like is to be
>> able to compile models using the “old” ISE toolflow on this new machine. I
>> wondered if anyone had been able to make this happen? I’ve got RHEL 7.8,
>> various Matlab versions, and ISE 14.7.
>>
>>
>>
>> There appear to be some fairly fundamental compatibility issues between
>> the OS and Matlab versions prior to 2014b, though I’m going to ask our
>> local IT support to look at this. Versions at least 2016b and later throw a
>> tantrum when casper_xps is run. 2014b is the most promising at the moment,
>> getting a fair way through casper_xps before complaining about certain
>> Matlab files requiring absolute paths. An internet search doesn’t yield
>> anything promising.
>>
>>
>>
>> Anyway, if you’ve been able to make a combination similar to what I’ve
>> got work correctly, please get in touch.
>>
>>
>>
>> Thanks!
>> Michael
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "casper@lists.berkeley.edu" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to casper+unsubscr...@lists.berkeley.edu.
>> To view this discussion on the web visit
>> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/DB6PR0102MB263086FDADB5B0F733879740AC6F0%40DB6PR0102MB2630.eurprd01.prod.exchangelabs.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups "
> casper@lists.berkeley.edu" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to casper+unsubscr...@lists.berkeley.edu.
> To view this discussion on the web visit
> https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAPU71P-Jt8Ua8LGeaTp5SLM04aEhCk9-wDE1i8p%3DqJfoVb_ftA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"casper@lists.berkeley.edu" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to casper+unsubscr...@lists.berkeley.edu.
To view this discussion on the web visit 
https://groups.google.com/a/lists.berkeley.edu/d/msgid/casper/CAE2vkmUtocNgRvZzEkrCgU2hvfPqg_NuyZfS4ry4Wrg0-xKeOw%40mail.gmail.com.

[Mpi-forum] Agenda / Votes for 2020-07-01

2020-06-30 Thread Wesley Bland via mpi-forum

Hi all,

Thanks for another good virtual meeting today. The schedule of plenaries and 
votes for tomorrow has been updated after today’s readings to include necessary 
no-no readings and to add and remove votes as necessary.

So tomorrow morning before the voting block, there will be these no-no readings:

#167: Dan - Error - Section 3.3.2 - p. 38 - Replace C process (no-no)
#252: Dan - Clarification - Section 3.2.2 - p. 27 - Datatype Footnote (no-no)
#190: Dan - Update - Section 3.7.5 - p. 60 - Replace C-bias with LIS (no-no)

These readings are considered complete along with the no-no changes made during 
the reading itself (do not require a no-no reading):

#263: Wesley - Clarification - Section 11.7 - p. 482 - MPI Exception 
Clarification (no-no)
#181: George - Oversight - Section 8.7 - p. 383 - Escape Spaces in Arguments 
(no-no)
#254: George - Clarification - Example 4.17 - p. 128 - Example Comment (no-no)

These readings will be voted on as originally read:

#179: Joseph - Omission - p. 440 - WIN_DETATCH Binding Fix (errata)
#178: Joseph - Omission - p. 439 - WIN_ATTACH_ Binding Fix (errata)
#218: Wesley - Update - Section 17.1 - p. 635 - Update Backward Incompatibility 
Text (errata)
#262: Wesley - Clarification - Section 11.3.5 - p. 458 - Error in Status Field 
Clarification (errata)
#171: George - Error in text - Section 4.1.1 - p. 87 - INTEGER*8 Extension 
(errata)
#257: Julien - Clarification - Section 5.1 - p. 144 - Collective 
Synchronization (errata)
#182: Julien - Question - Section 5.12.4 - p. 206 - MPI_ISCATTERV sendcounts 
and displs Consistency (errata)

You can find the sample ballot for tomorrow here: 
https://www.jotform.com/build/201614072992151 
<https://www.jotform.com/build/201614072992151> 

After the voting block starts, we’ll do the following plenaries in this order:

Reading - 120 - MPI_Cart_create_weighted / Topology aware Cartesian 
communicators - Rolf
Errata Readings - Read all errata tickets up for vote in the order of above
Reading - 57 - Deprecate MPI_HOST - Julien
Reading - 259 - Clarification - Section 8.5 - p. 377 - Error Class and Code 
Advice to Implementors - Wesley
Discussion - Next Meeting(s) and Timeline - Martin

As you can see, we still have quite a few things we need to complete tomorrow 
so we’ll be starting on time and moving quickly. I’d encourage minor comments 
(e.g. typos and small word-smithing discussions) to use GitHub to allow time 
for all of the topics.

If anyone has any corrections for the list above, please let Martin and I know 
and we’ll get everything updated.

Thanks,
Wes___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Re: Apache Beam a Complete Guide - Review?

2020-06-29 Thread Wesley Peng





Rion Williams wrote:

The three authors of Streaming Systems are folks that work on Google’s Dataflow 
Project, which for all intents and purposes is essentially an implementation of 
the Beam Model. Two of them are members of the Beam PMC (essentially a steering 
committee for the project) and you’ll frequently see them if you are active 
within the mailing lists here.

As mentioned earlier in the thread, I can’t recommend Streaming Systems enough. 
If you are curious about Beam or want to dig into it, it’s the best book you’ll 
find on the topic.


Thanks for this info Rion.

Re: Apache Beam a Complete Guide - Review?

2020-06-29 Thread Wesley Peng


Hi Luke

Luke Cwik wrote:
The author for Apache Beam A Complete Guide does not have good reviews 
on Amazon for their other books and as you mentioned no reviews for this 
one.


I would second the Streaming Systems book as the authors directly worked 
on Apache Beam.



So, can Apache beam team in google write a book directly for the project 
users?


Thanks.

RE: [cayugabirds-l] Bobolinks

2020-06-29 Thread Wesley M. Hochachka

I have a small amount of first-hand experience of searching for Bobolink nests 
during a study of the effects of habitat fragmentation on nesting success.  My 
impression is that Bobolink nests can be extremely difficult to find, and I 
would discourage attempts to find a Bobolink nest for the purpose of casual 
observation.  Adult Bobolinks have several behaviors that make nest finding 
difficult, including:

  *   Male activity is only loosely associated with nest locations.  A male can 
be activity singing in one area, actively foraging in another, and with their 
nest in yet another area entirely, within an overall area of several acres.
  *   Female Bobolinks can walk for tens of yards, both to and from their 
nests, making the location at which a female lands only a loose indicator of 
where her nest actually is.
  *   Localizing a nest is potentially best done by flushing a female from her 
nest (so that she has no time to walk away before taking flight).  Flushing 
birds of their nests is a standard methodology for grassland bird researchers, 
using a rope dragged through the grass between two people walking parallel 
lines.

In summary, just finding a Bobolink nest can take a substantial amount of time 
(hours), and cause major damage to habitat in the general vicinity of a nest 
(and potentially result in destruction of the nest).  Personally, I think that 
the potential costs to attempting to find a nest would on average outweigh any 
benefits.  Having written that, the nests of some individual birds are much 
easier to find than would be typical for a species, although I cannot think of 
any way to predict from birds’ behavior when a nest could be easily found 
(except maybe when the nestlings are so old and loud that they would be 
fledging imminently).

Wesley Hochachka




From: bounce-124741359-3494...@list.cornell.edu 
 On Behalf Of Susan Henne
Sent: Monday, June 29, 2020 5:05 PM
To: CAYUGABIRDS-L 
Subject: [cayugabirds-l] Bobolinks

For almost 10 days, there has been a male Bobolink in a meadow in front of my 
house.  I would assume there is a nest in the thick of the tall grass as his 
vocalizations usually get a busy response.  I have yet to see or ID a female or 
young.  The grass is tall and quite dense so maybe this will be the secret to 
their successful brood.  Has anyone had experience observing nestlings?  Can 
anyone suggest some good resources about their behavior?

Thanks
Sue Henne
Ellis Hollow

--
Cayugabirds-L List Info:
Welcome and Basics<http://www.northeastbirding.com/CayugabirdsWELCOME>
Rules and Information<http://www.northeastbirding.com/CayugabirdsRULES>
Subscribe, Configuration and 
Leave<http://www.northeastbirding.com/CayugabirdsSubscribeConfigurationLeave.htm>
Archives:
The Mail 
Archive<http://www.mail-archive.com/cayugabirds-l@cornell.edu/maillist.html>
Surfbirds<http://www.surfbirds.com/birdingmail/Group/Cayugabirds>
BirdingOnThe.Net<http://birdingonthe.net/mailinglists/CAYU.html>
Please submit your observations to eBird<http://ebird.org/content/ebird/>!
--

--

Cayugabirds-L List Info:
http://www.NortheastBirding.com/CayugabirdsWELCOME
http://www.NortheastBirding.com/CayugabirdsRULES
http://www.NortheastBirding.com/CayugabirdsSubscribeConfigurationLeave.htm

ARCHIVES:
1) http://www.mail-archive.com/cayugabirds-l@cornell.edu/maillist.html
2) http://www.surfbirds.com/birdingmail/Group/Cayugabirds
3) http://birdingonthe.net/mailinglists/CAYU.html

Please submit your observations to eBird:
http://ebird.org/content/ebird/

--

Re: [Mpi-forum] Agenda and Ballots for Tomorrow

2020-06-29 Thread Wesley Bland via mpi-forum

One quick addendum / clarification to this:

We will not have the first vote on "#120 - MPI_Cart_create_weighted / Topology 
aware Cartesian communicators” on Tuesday. We will only have the “no-no” vote 
on Tuesday.

If the “no-no” vote passes on Tuesday, we will have the first vote for "#120 - 
MPI_Cart_create_weighted / Topology aware Cartesian communicators” on Wednesday.

If there’s any confusion, you can see the two ballots here:

Tuesday - https://www.jotform.com/build/201804215921143 
<https://www.jotform.com/build/201804215921143>
Wednesday - https://www.jotform.com/build/201614072992151 
<https://www.jotform.com/build/201614072992151>

Note that you can’t actually vote yet. Your personalized link for voting will 
be sent out tomorrow during the voting block.

Thanks,
Wes

> On Jun 29, 2020, at 2:00 PM, Martin Schulz via mpi-forum 
>  wrote:
> 
> Hi all,
> 
> Thanks for a first, quite productive session today.
> 
> Just a quick preview for tomorrow: we will start with a discussion on ticket 
> #120 by Rolf and the proposed NoNo Vote text. 
> 
> The voting block will open at 9:30 and will stay open until 10:00, at which 
> time Wesley will announce the results - for the block tomorrow, we’ll include 
> the procedural votes, the NoNos, as well as all first and second votes. If 
> you are the owner of one of those, please be prepared to briefly introduce 
> it, if requested. 
> 
> For the rest of the day, we will then focus on errata readings, so we can 
> vote on them on Wednesday. The agenda lists the order - we grouped them by 
> owner, so we don’t have to switch speakers that often - please take a look at 
> this if you own an errata ticket.
> 
> Thanks and talk to you all tomorrow,
> 
> Martin
> 
> 
> —
> Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems
> Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching
> Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ)
> Email: schu...@in.tum.de
> 
> ___
> mpi-forum mailing list
> mpi-forum@lists.mpi-forum.org
> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

[UPDATE] crystal-0.35.1

2020-06-29 Thread Wesley Moxam

Updates lang/crystal port to v0.35.1

Crystal is working towards a v1.0 release, and v0.35 brought some small
language changes and some polish to the stdlib.

It's worth noting that Crystal Shards now depends on crystal-molinillo
(which is a shard).

-- W


crystal-0.35.1.diff
Description: Binary data

Re: Apache Beam a Complete Guide - Review?

2020-06-28 Thread Wesley Peng


Hi Rion

Rion Williams wrote:
I considered that one as well but was in the same boat in terms of not 
pulling the trigger (lack of reviews, price point, etc.). I eventually 
landed on Streaming Systems, which I highly, highly recommend if you 
want to learn more about the Beam model:


- http://streamingsystems.net/

I don’t think there’s a better book that I’ve come across that focuses 
on it more (and if there is one, I’d love to know about it). I wrote a 
blog post that includes a short-review of it if you want a slightly 
longer summary (http://rion.io/2020/05/09/an-education-in-streaming/), 
but again - I highly recommend checking it out if you hadn’t already.


Thanks for the answer. I will check the resource you gave above.

Regards.

Apache Beam a Complete Guide - Review?

2020-06-28 Thread Wesley Peng


Hello

Has anyone bought this book? Can you give a simple review, good or not?

https://www.thriftbooks.com/w/apache-beam-a-complete-guide---2020-edition/26243355/item/36997139/

I want to buy a book for beam the specific topic, but this book seems 
too new to have enough reviews.


Thanks.

Re: [prometheus-users] Re: not able to see metrics from query browser even though end point is up and showing metrics through curl

2020-06-28 Thread Wesley Peng


Hi

Brian Candler wrote:

"up" missing - scraping not configured.
"up" has value 0 - unable to communicate or data is bad.
"up" has value 1 - maybe partial scrape

Check logs at prometheus and exporter; check traffic between prometheus 
and exporter with tcpdump.


Can you show a sample tcpdump syntax for this purpose?

Thanks.

--
You received this message because you are subscribed to the Google Groups 
"Prometheus Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to prometheus-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-users/130d9158-d6d7-f49f-1884-b2dd1f66e314%40pobox.com.

Re: unsubscribe

2020-06-27 Thread Wesley Peng

please send an empty email to: user-unsubscr...@spark.apache.org to 
unsubscribe yourself from the list.



Sri Kris wrote:
Sent from Mail  for 
Windows 10




-
To unsubscribe e-mail: user-unsubscr...@spark.apache.org

[PATCH v4 0/6] Introduce PMIC based USB type C detection

Changes in v4:
 - Modified qcom,pmic-typec binding to include the SS mux and the DRD remote
   endpoint nodes underneath port@1, which is assigned to the SSUSB path
   according to usb-connector
 - Added usb-connector reference to the typec dt-binding
 - Added tags to the usb type c and vbus nodes
 - Removed "qcom" tags from type c and vbus nodes
 - Modified Kconfig module name, and removed module alias from the typec driver
 
Changes in v3:
 - Fix driver reference to match driver name in Kconfig for
   qcom_usb_vbus-regulator.c
 - Utilize regulator bitmap helpers for enable, disable and is enabled calls in
   qcom_usb_vbus-regulator.c
 - Use of_get_regulator_init_data() to initialize regulator init data, and to
   set constraints in qcom_usb_vbus-regulator.c
 - Remove the need for a local device structure in the vbus regulator driver
 
Changes in v2:
 - Use devm_kzalloc() in qcom_pmic_typec_probe()
 - Add checks to make sure return value of typec_find_port_power_role() is
   valid
 - Added a VBUS output regulator driver, which will be used by the PMIC USB
   type c driver to enable/disable the source
 - Added logic to control vbus source from the PMIC type c driver when
   UFP/DFP is detected
 - Added dt-binding for this new regulator driver
 - Fixed Kconfig typec notation to match others
 - Leave type C block disabled until enabled by a platform DTS

Add the required drivers for implementing type C orientation and role
detection using the Qualcomm PMIC.  Currently, PMICs such as the PM8150B
have an integrated type C block, which can be utilized for this.  This
series adds the dt-binding, PMIC type C driver, and DTS nodes.

The PMIC type C driver will register itself as a type C port w/ a
registered type C switch for orientation, and will fetch a USB role switch
handle for the role notifications.  It will also have the ability to enable
the VBUS output to any connected devices based on if the device is behaving
as a UFP or DFP.

Wesley Cheng (6):
  usb: typec: Add QCOM PMIC typec detection driver
  dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding
  arm64: boot: dts: qcom: pm8150b: Add node for USB type C block
  regulator: Add support for QCOM PMIC VBUS booster
  dt-bindings: regulator: Add dt-binding for QCOM PMIC VBUS output
regulator
  arm64: boot: dts: qcom: pm8150b: Add DTS node for PMIC VBUS booster

 .../regulator/qcom,usb-vbus-regulator.yaml|  41 +++
 .../bindings/usb/qcom,pmic-typec.yaml | 113 +++
 arch/arm64/boot/dts/qcom/pm8150b.dtsi |  13 +
 arch/arm64/boot/dts/qcom/sm8150-mtp.dts   |   4 +
 drivers/regulator/Kconfig |  10 +
 drivers/regulator/Makefile|   1 +
 drivers/regulator/qcom_usb_vbus-regulator.c   |  97 ++
 drivers/usb/typec/Kconfig |  12 +
 drivers/usb/typec/Makefile|   1 +
 drivers/usb/typec/qcom-pmic-typec.c   | 275 ++
 10 files changed, 567 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
 create mode 100644 Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
 create mode 100644 drivers/regulator/qcom_usb_vbus-regulator.c
 create mode 100644 drivers/usb/typec/qcom-pmic-typec.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v4 6/6] arm64: boot: dts: qcom: pm8150b: Add DTS node for PMIC VBUS booster

Add the required DTS node for the USB VBUS output regulator, which is
available on PM8150B.  This will provide the VBUS source to connected
peripherals.

Signed-off-by: Wesley Cheng 
---
 arch/arm64/boot/dts/qcom/pm8150b.dtsi   | 6 ++
 arch/arm64/boot/dts/qcom/sm8150-mtp.dts | 4 
 2 files changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi 
b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
index 91b870345dda..18f64bca73bc 100644
--- a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
@@ -22,6 +22,12 @@ power-on@800 {
status = "disabled";
};
 
+pm8150b_vbus: dcdc@1100 {
+   compatible = "qcom,pm8150b-vbus-reg";
+   status = "disabled";
+   reg = <0x1100>;
+   };
+
pm8150b_typec: typec@1500 {
compatible = "qcom,pm8150b-usb-typec";
status = "disabled";
diff --git a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts 
b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
index 6c6325c3af59..ba3b5b802954 100644
--- a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
@@ -409,6 +409,10 @@ &ufs_mem_phy {
vdda-pll-max-microamp = <19000>;
 };
 
+&pm8150b_vbus {
+   status = "okay";
+};
+
 &usb_1_hsphy {
status = "okay";
vdda-pll-supply = <&vdd_usb_hs_core>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v4 4/6] regulator: Add support for QCOM PMIC VBUS booster

Some Qualcomm PMICs have the capability to source the VBUS output to
connected peripherals.  This driver will register a regulator to the
regulator list to enable or disable this source by an external driver.

Signed-off-by: Wesley Cheng 
---
 drivers/regulator/Kconfig   | 10 +++
 drivers/regulator/Makefile  |  1 +
 drivers/regulator/qcom_usb_vbus-regulator.c | 97 +
 3 files changed, 108 insertions(+)
 create mode 100644 drivers/regulator/qcom_usb_vbus-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 074a2ef55943..273d85a45263 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -797,6 +797,16 @@ config REGULATOR_QCOM_SPMI
  Qualcomm SPMI PMICs as a module. The module will be named
  "qcom_spmi-regulator".
 
+config REGULATOR_QCOM_USB_VBUS
+   tristate "Qualcomm USB Vbus regulator driver"
+   depends on SPMI || COMPILE_TEST
+   help
+ If you say yes to this option, support will be included for the
+ regulator used to enable the VBUS output.
+
+ Say M here if you want to include support for enabling the VBUS output
+ as a module. The module will be named "qcom_usb_vbus_regulator".
+
 config REGULATOR_RC5T583
tristate "RICOH RC5T583 Power regulators"
depends on MFD_RC5T583
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index c0d6b96ebd78..cbab28aa7b56 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -89,6 +89,7 @@ obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_SPMI) += qcom_spmi-regulator.o
+obj-$(CONFIG_REGULATOR_QCOM_USB_VBUS) += qcom_usb_vbus-regulator.o
 obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o
 obj-$(CONFIG_REGULATOR_PFUZE100) += pfuze100-regulator.o
 obj-$(CONFIG_REGULATOR_PV88060) += pv88060-regulator.o
diff --git a/drivers/regulator/qcom_usb_vbus-regulator.c 
b/drivers/regulator/qcom_usb_vbus-regulator.c
new file mode 100644
index ..342d92373598
--- /dev/null
+++ b/drivers/regulator/qcom_usb_vbus-regulator.c
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: GPL-2.0-only
+//
+// Qualcomm PMIC VBUS output regulator driver
+//
+// Copyright (c) 2020, The Linux Foundation. All rights reserved.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CMD_OTG0x40
+#define OTG_EN BIT(0)
+#define OTG_CFG0x53
+#define OTG_EN_SRC_CFG BIT(1)
+
+static const struct regulator_ops qcom_usb_vbus_reg_ops = {
+   .enable = regulator_enable_regmap,
+   .disable = regulator_disable_regmap,
+   .is_enabled = regulator_is_enabled_regmap,
+};
+
+static struct regulator_desc qcom_usb_vbus_rdesc = {
+   .name = "usb_vbus",
+   .ops = &qcom_usb_vbus_reg_ops,
+   .owner = THIS_MODULE,
+   .type = REGULATOR_VOLTAGE,
+};
+
+static int qcom_usb_vbus_regulator_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct regulator_dev *rdev;
+   struct regmap *regmap;
+   struct regulator_config config = { };
+   struct regulator_init_data *init_data;
+   int ret;
+   u32 base;
+
+   ret = of_property_read_u32(dev->of_node, "reg", &base);
+   if (ret < 0) {
+   dev_err(dev, "no base address found\n");
+   return ret;
+   }
+
+   regmap = dev_get_regmap(dev->parent, NULL);
+   if (regmap) {
+   dev_err(dev, "Failed to get regmap\n");
+   return -ENOENT;
+   }
+
+   init_data = of_get_regulator_init_data(dev, dev->of_node,
+  &qcom_usb_vbus_rdesc);
+   if (!init_data)
+   return -ENOMEM;
+
+   qcom_usb_vbus_rdesc.enable_reg = base + CMD_OTG;
+   qcom_usb_vbus_rdesc.enable_mask = OTG_EN;
+   config.dev = dev;
+   config.init_data = init_data;
+   config.regmap = regmap;
+
+   rdev = devm_regulator_register(dev, &qcom_usb_vbus_rdesc, &config);
+   if (IS_ERR(rdev)) {
+   ret = PTR_ERR(rdev);
+   dev_err(dev, "not able to register vbus reg %d\n", ret);
+   return ret;
+   }
+
+   /* Disable HW logic for VBUS enable */
+   regmap_update_bits(regmap, base + OTG_CFG, OTG_EN_SRC_CFG, 0);
+
+   return 0;
+}
+
+static const struct of_device_id qcom_usb_vbus_regulator_match[] = {
+   { .compatible = "qcom,pm8150b-vbus-reg" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, qcom_usb_vbus_regulator_match);
+
+static struct platform_driver qcom_usb

[PATCH v4 3/6] arm64: boot: dts: qcom: pm8150b: Add node for USB type C block

The PM8150B has a dedicated USB type C block, which can be used for type C
orientation and role detection.  Create the reference node to this type C
block for further use.

Signed-off-by: Wesley Cheng 
---
 arch/arm64/boot/dts/qcom/pm8150b.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi 
b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
index 322379d5c31f..91b870345dda 100644
--- a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
@@ -22,6 +22,13 @@ power-on@800 {
status = "disabled";
};
 
+   pm8150b_typec: typec@1500 {
+   compatible = "qcom,pm8150b-usb-typec";
+   status = "disabled";
+   reg = <0x1500>;
+   interrupts = <0x2 0x15 0x5 IRQ_TYPE_EDGE_RISING>;
+   };
+
adc@3100 {
compatible = "qcom,spmi-adc5";
reg = <0x3100>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v4 5/6] dt-bindings: regulator: Add dt-binding for QCOM PMIC VBUS output regulator

This describes how to enable the Qualcomm PMIC VBUS booster used for
providing power to connected USB peripherals when the USB role is host
mode.  The driver itself will register the vbus_usb regulator, so that
external drivers can utilize the enable/disable regulator APIs.

Signed-off-by: Wesley Cheng 
---
 .../regulator/qcom,usb-vbus-regulator.yaml| 41 +++
 1 file changed, 41 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml

diff --git 
a/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml 
b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
new file mode 100644
index ..12ed98c28aaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/qcom,usb-vbus-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: The Qualcomm PMIC VBUS output regulator driver
+
+maintainers:
+  - Wesley Cheng 
+
+description: |
+  This regulator driver controls the VBUS output by the Qualcomm PMIC.  This
+  regulator will be enabled in situations where the device is required to
+  provide power to the connected peripheral.
+
+properties:
+  compatible:
+enum:
+  - qcom,pm8150b-vbus-reg
+
+  reg:
+maxItems: 1
+description: VBUS output base address
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+ pm8150b {
+#address-cells = <1>;
+#size-cells = <0>;
+pm8150b_vbus: dcdc@1100 {
+compatible = "qcom,pm8150b-vbus-reg";
+reg = <0x1100>;
+};
+ };
+...
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v4 2/6] dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding

Introduce the dt-binding for enabling USB type C orientation and role
detection using the PM8150B.  The driver will be responsible for receiving
the interrupt at a state change on the CC lines, reading the orientation/role,
and communicating this information to the remote clients, which can include
a role switch node and a type C switch.

Signed-off-by: Wesley Cheng 
---
 .../bindings/usb/qcom,pmic-typec.yaml | 126 ++
 1 file changed, 126 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml

diff --git a/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml 
b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
new file mode 100644
index ..6714fb2e6b08
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
@@ -0,0 +1,126 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/usb/qcom,pmic-typec.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Qualcomm PMIC based USB type C Detection Driver
+
+maintainers:
+  - Wesley Cheng 
+
+description: |
+  Qualcomm PMIC Type C Detect
+
+properties:
+  compatible:
+enum:
+  - qcom,pm8150b-usb-typec
+
+  reg:
+maxItems: 1
+description: Type C base address
+
+  interrupts:
+maxItems: 1
+description: CC change interrupt from PMIC
+
+  connector:
+description: Connector type for remote endpoints
+type: object
+$ref: /schemas/connector/usb-connector.yaml#
+
+properties:
+  compatible:
+enum:
+  - usb-c-connector
+
+  power-role:
+   enum:
+ - dual
+ - source
+ - sink
+
+  data-role:
+enum:
+  - dual
+  - host
+  - device
+
+  ports:
+description: Remote endpoint connections
+type: object
+
+properties:
+  port@0:
+description: Remote endpoints for the High Speed path
+type: object
+
+  port@1:
+description: Remote endpoints for the Super Speed path
+type: object
+
+properties:
+  endpoint@0:
+description: Connection to USB type C mux node
+type: object
+
+properties:
+  remote-endpoint:
+maxItems: 1
+description: Node reference to the type C mux
+
+  endpoint@1:
+description: Connection to role switch node
+type: object
+
+properties:
+  remote-endpoint:
+maxItems: 1
+description: Node reference to the role switch node
+
+required:
+  - compatible
+
+required:
+  - compatible
+  - interrupts
+  - connector
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+pm8150b {
+#address-cells = <1>;
+#size-cells = <0>;
+pm8150b_typec: typec@1500 {
+compatible = "qcom,pm8150b-usb-typec";
+reg = <0x1500>;
+interrupts = <0x2 0x15 0x5 IRQ_TYPE_EDGE_RISING>;
+
+connector {
+compatible = "usb-c-connector";
+power-role = "dual";
+data-role = "dual";
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+reg = <0>;
+};
+port@1 {
+reg = <1>;
+usb3_data_ss: endpoint@0 {
+remote-endpoint = <&qmp_ss_mux>;
+};
+usb3_role: endpoint@1 {
+remote-endpoint = <&dwc3_drd_switch>;
+};
+};
+};
+};
+};
+};
+...
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v4 1/6] usb: typec: Add QCOM PMIC typec detection driver

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 attains a handle to the VBUS output regulator, so it
can enable/disable the VBUS source when acting as a host/device.

Signed-off-by: Wesley Cheng 
---
 drivers/usb/typec/Kconfig   |  12 ++
 drivers/usb/typec/Makefile  |   1 +
 drivers/usb/typec/qcom-pmic-typec.c | 275 
 3 files changed, 288 insertions(+)
 create mode 100644 drivers/usb/typec/qcom-pmic-typec.c

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index b4f2aac7ae8a..595c14766e99 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -72,6 +72,18 @@ 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 Type-C driver"
+   depends on ARCH_QCOM
+   help
+ Driver for supporting role switch over the Qualcomm PMIC.  This will
+ handle the USB Type-C role and orientation detection reported by the
+ QCOM PMIC if the PMIC has the capability to handle USB 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 7753a5c3cd46..cceffd987643 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 ..5ae3af03c638
--- /dev/null
+++ b/drivers/usb/typec/qcom-pmic-typec.c
@@ -0,0 +1,275 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TYPEC_MISC_STATUS  0xb
+#define CC_ATTACHEDBIT(0)
+#define CC_ORIENTATION BIT(1)
+#define SNK_SRC_MODE   BIT(6)
+#define TYPEC_MODE_CFG 0x44
+#define TYPEC_DISABLE_CMD  BIT(0)
+#define EN_SNK_ONLYBIT(1)
+#define EN_SRC_ONLYBIT(2)
+#define TYPEC_VCONN_CONTROL0x46
+#define VCONN_EN_SRC   BIT(0)
+#define VCONN_EN_VAL   BIT(1)
+#define TYPEC_EXIT_STATE_CFG   0x50
+#define SEL_SRC_UPPER_REF  BIT(2)
+#define TYPEC_INTR_EN_CFG_10x5e
+#define TYPEC_INTR_EN_CFG_1_MASK   GENMASK(7, 0)
+
+struct qcom_pmic_typec {
+   struct device   *dev;
+   struct fwnode_handle*fwnode;
+   struct regmap   *regmap;
+   u32 base;
+
+   struct typec_capability *cap;
+   struct typec_port   *port;
+   struct usb_role_switch *role_sw;
+
+   struct regulator*vbus_reg;
+   boolvbus_enabled;
+};
+
+static void qcom_pmic_typec_enable_vbus_regulator(struct qcom_pmic_typec
+   *qcom_usb, bool enable)
+{
+   int ret = 0;
+
+   if (enable == qcom_usb->vbus_enabled)
+   return;
+
+   if (!qcom_usb->vbus_reg) {
+   qcom_usb->vbus_reg = devm_regulator_get(qcom_usb->dev,
+   "usb_vbus");
+   if (IS_ERR(qcom_usb->vbus_reg)) {
+   qcom_usb->vbus_reg = NULL;
+   return;
+   }
+   }
+
+   if (enable) {
+   ret = regulator_enable(qcom_usb->vbus_reg);
+   if (ret)
+   return;
+   } else {
+   ret = regulator_disable(qcom_usb->vbus_reg);
+   if (ret)
+   return;
+   }
+   qcom_usb->vbus_enabled = enable;
+}
+
+static void qcom_pmic_typec_check_connection(struct qcom_pmic_typec *qcom_usb)
+{
+   enum typec_orientation orientation;
+   enum usb_role role;
+   unsigned int stat;
+   bool enable_vbus;
+
+   regmap_read(qcom_usb->regmap, qcom_usb->base + TYPEC_MISC_STATUS,
+   &stat);
+
+   if (stat & CC_ATTACHED) {
+   orientation = ((stat &a

Re: I need to study Python

2020-06-26 Thread Wesley Peng


Pick a book like Core Python Programming, read it and do coding follow it.

regards.

sinanp...@gmail.com wrote:

Hey, I'm a completely noob.
I want to learn python, how can i or where can i study python?


--
https://mail.python.org/mailman/listinfo/python-list

[PATCH v3 2/2] phy: qcom-snps: Add a set mode callback

The set mode handler is used to keep track of the current role of the
device.  This is used for enabling certain resources within the PHY
depending on if the device is behaving as a host or device.

Signed-off-by: Wesley Cheng 
---
 drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c 
b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
index 152d8633f4ea..ae4bac024c7b 100644
--- a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
+++ b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
@@ -77,6 +77,7 @@ static const char * const qcom_snps_hsphy_vreg_names[] = {
  * @phy_reset: phy reset control
  * @vregs: regulator supplies bulk data
  * @phy_initialized: if PHY has been initialized correctly
+ * @mode: contains the current mode the PHY is in
  */
 struct qcom_snps_hsphy {
struct phy *phy;
@@ -88,6 +89,7 @@ struct qcom_snps_hsphy {
struct regulator_bulk_data vregs[SNPS_HS_NUM_VREGS];
 
bool phy_initialized;
+   enum phy_mode mode;
 };
 
 static inline void qcom_snps_hsphy_write_mask(void __iomem *base, u32 offset,
@@ -161,6 +163,15 @@ static int __maybe_unused 
qcom_snps_hsphy_runtime_resume(struct device *dev)
return 0;
 }
 
+static int qcom_snps_hsphy_set_mode(struct phy *phy, enum phy_mode mode,
+   int submode)
+{
+   struct qcom_snps_hsphy *hsphy = phy_get_drvdata(phy);
+
+   hsphy->mode = mode;
+   return 0;
+}
+
 static int qcom_snps_hsphy_init(struct phy *phy)
 {
struct qcom_snps_hsphy *hsphy = phy_get_drvdata(phy);
@@ -258,6 +269,7 @@ static int qcom_snps_hsphy_exit(struct phy *phy)
 static const struct phy_ops qcom_snps_hsphy_gen_ops = {
.init   = qcom_snps_hsphy_init,
.exit   = qcom_snps_hsphy_exit,
+   .set_mode   = qcom_snps_hsphy_set_mode,
.owner  = THIS_MODULE,
 };
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 1/2] phy: qcom-snps: Add runtime suspend and resume handlers

Allow for the PHY to be put into a powered down state when possible.
Add the required suspend and resume callbacks, which will determine
what resources can be turned off depending on the cable status.

Signed-off-by: Wesley Cheng 
Reviewed-by: Vinod Koul 
---
 drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 73 +++
 1 file changed, 73 insertions(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c 
b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
index 4d74045271eb..152d8633f4ea 100644
--- a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
+++ b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
@@ -104,6 +104,63 @@ static inline void qcom_snps_hsphy_write_mask(void __iomem 
*base, u32 offset,
readl_relaxed(base + offset);
 }
 
+static int qcom_snps_hsphy_suspend(struct qcom_snps_hsphy *hsphy)
+{
+   dev_dbg(&hsphy->phy->dev, "Suspend QCOM SNPS PHY\n");
+
+   if (hsphy->mode == PHY_MODE_USB_HOST) {
+   /* Enable auto-resume to meet remote wakeup timing */
+   qcom_snps_hsphy_write_mask(hsphy->base,
+  USB2_PHY_USB_PHY_HS_PHY_CTRL2,
+  USB2_AUTO_RESUME,
+  USB2_AUTO_RESUME);
+   usleep_range(500, 1000);
+   qcom_snps_hsphy_write_mask(hsphy->base,
+  USB2_PHY_USB_PHY_HS_PHY_CTRL2,
+  0, USB2_AUTO_RESUME);
+   }
+
+   clk_disable_unprepare(hsphy->cfg_ahb_clk);
+   return 0;
+}
+
+static int qcom_snps_hsphy_resume(struct qcom_snps_hsphy *hsphy)
+{
+   int ret;
+
+   dev_dbg(&hsphy->phy->dev, "Resume QCOM SNPS PHY, mode\n");
+
+   ret = clk_prepare_enable(hsphy->cfg_ahb_clk);
+   if (ret) {
+   dev_err(&hsphy->phy->dev, "failed to enable cfg ahb clock\n");
+   return ret;
+   }
+
+   return 0;
+}
+
+static int __maybe_unused qcom_snps_hsphy_runtime_suspend(struct device *dev)
+{
+   struct qcom_snps_hsphy *hsphy = dev_get_drvdata(dev);
+
+   if (!hsphy->phy_initialized)
+   return 0;
+
+   qcom_snps_hsphy_suspend(hsphy);
+   return 0;
+}
+
+static int __maybe_unused qcom_snps_hsphy_runtime_resume(struct device *dev)
+{
+   struct qcom_snps_hsphy *hsphy = dev_get_drvdata(dev);
+
+   if (!hsphy->phy_initialized)
+   return 0;
+
+   qcom_snps_hsphy_resume(hsphy);
+   return 0;
+}
+
 static int qcom_snps_hsphy_init(struct phy *phy)
 {
struct qcom_snps_hsphy *hsphy = phy_get_drvdata(phy);
@@ -212,6 +269,11 @@ static const struct of_device_id 
qcom_snps_hsphy_of_match_table[] = {
 };
 MODULE_DEVICE_TABLE(of, qcom_snps_hsphy_of_match_table);
 
+static const struct dev_pm_ops qcom_snps_hsphy_pm_ops = {
+   SET_RUNTIME_PM_OPS(qcom_snps_hsphy_runtime_suspend,
+  qcom_snps_hsphy_runtime_resume, NULL)
+};
+
 static int qcom_snps_hsphy_probe(struct platform_device *pdev)
 {
struct device *dev = &pdev->dev;
@@ -255,6 +317,14 @@ static int qcom_snps_hsphy_probe(struct platform_device 
*pdev)
return ret;
}
 
+   pm_runtime_set_active(dev);
+   pm_runtime_enable(dev);
+   /*
+* Prevent runtime pm from being ON by default. Users can enable
+* it using power/control in sysfs.
+*/
+   pm_runtime_forbid(dev);
+
generic_phy = devm_phy_create(dev, NULL, &qcom_snps_hsphy_gen_ops);
if (IS_ERR(generic_phy)) {
ret = PTR_ERR(generic_phy);
@@ -269,6 +339,8 @@ static int qcom_snps_hsphy_probe(struct platform_device 
*pdev)
phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
if (!IS_ERR(phy_provider))
dev_dbg(dev, "Registered Qcom-SNPS HS phy\n");
+   else
+   pm_runtime_disable(dev);
 
return PTR_ERR_OR_ZERO(phy_provider);
 }
@@ -277,6 +349,7 @@ static struct platform_driver qcom_snps_hsphy_driver = {
.probe  = qcom_snps_hsphy_probe,
.driver = {
.name   = "qcom-snps-hs-femto-v2-phy",
+   .pm = &qcom_snps_hsphy_pm_ops,
.of_match_table = qcom_snps_hsphy_of_match_table,
},
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 0/2] phy: qcom-snps: Add runtime suspend and resume handlers

Changes in v3:
 - Fixed strict checkpatch warnings due to alignment
 - Remove debug artifacts from prints
 - Split the set mode callback addition to another patch
 - Removed suspended parameter

Changes in v2:
 - Addressed checkpatch alignment/line length warnings.
 - Removed superfluous init in qcom_snps_hsphy_resume().

Adds a set mode callback and runtime suspend/resume handlers to the
phy-qcom-snps-femto-v2 driver.  The set mode is used to enable certain
power management features in the PHY during suspend/resume.

Wesley Cheng (2):
  phy: qcom-snps: Add runtime suspend and resume handlers
  phy: qcom-snps: Add a set mode callback

 drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 85 +++
 1 file changed, 85 insertions(+)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2] phy: qcom-snps: Add runtime suspend and resume handlers




On 6/24/2020 5:21 AM, Vinod Koul wrote:
> Hi Wesley,
> 
> On 21-05-20, 18:50, Wesley Cheng wrote:
>> Allow for the PHY to be put into a powered down state when possible.
>> Add the required suspend and resume callbacks, which will determine
>> what resources can be turned off depending on the cable status.
>>
>> Signed-off-by: Wesley Cheng 
>>
>> ---
>> Changes in v2:
>>  - Addressed checkpatch alignment/line length warnings.
>>  - Removed superfluous init in qcom_snps_hsphy_resume().
>>
>>  drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 100 
>> ++
>>  1 file changed, 100 insertions(+)
>>
>> diff --git a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c 
>> b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
>> index 4d74045..0a4e77af 100644
>> --- a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
>> +++ b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
>> @@ -76,7 +76,9 @@
>>   * @iface_clk: phy interface clock
>>   * @phy_reset: phy reset control
>>   * @vregs: regulator supplies bulk data
>> + * @suspended: PHY is in the suspended state
>>   * @phy_initialized: if PHY has been initialized correctly
>> + * @mode: contains the current mode the PHY is in
>>   */
>>  struct qcom_snps_hsphy {
>>  struct phy *phy;
>> @@ -87,7 +89,9 @@ struct qcom_snps_hsphy {
>>  struct reset_control *phy_reset;
>>  struct regulator_bulk_data vregs[SNPS_HS_NUM_VREGS];
>>  
>> +bool suspended;
>>  bool phy_initialized;
>> +enum phy_mode mode;
>>  };
>>  
>>  static inline void qcom_snps_hsphy_write_mask(void __iomem *base, u32 
>> offset,
>> @@ -104,6 +108,84 @@ static inline void qcom_snps_hsphy_write_mask(void 
>> __iomem *base, u32 offset,
>>  readl_relaxed(base + offset);
>>  }
>>  
>> +static int qcom_snps_hsphy_suspend(struct qcom_snps_hsphy *hsphy)
>> +{
>> +if (hsphy->suspended)
>> +return 0;
> 
> Am still not convinced why this would be called when we are already
> suspended :)
> 

Hi Vinod,

OK, we can remove it for now, and if its really required further on, we
can re-add.

>> +
>> +dev_dbg(&hsphy->phy->dev, "Suspend QCOM SNPS PHY, mode:%d\n",
>> +hsphy->mode);
> 
> Remove debug artifacts here?
> 

Sure, can do that.

>> +
>> +if (hsphy->mode == PHY_MODE_USB_HOST) {
>> +/* Enable auto-resume to meet remote wakeup timing */
>> +qcom_snps_hsphy_write_mask(hsphy->base,
>> +USB2_PHY_USB_PHY_HS_PHY_CTRL2,
>> +USB2_AUTO_RESUME,
>> +USB2_AUTO_RESUME);
> 
> Lets align the lines above to opening brace please..
> If you run checkpatch with --strict option you would get this CHECK: 
> Alignment should match open parenthesis
> 

OK, got it.  Fixed a few other spacing warnings as well.

>> +usleep_range(500, 1000);
>> +qcom_snps_hsphy_write_mask(hsphy->base,
>> +USB2_PHY_USB_PHY_HS_PHY_CTRL2,
>> +0, USB2_AUTO_RESUME);
>> +}
>> +
>> +clk_disable_unprepare(hsphy->cfg_ahb_clk);
>> +hsphy->suspended = true;
>> +
>> +return 0;
>> +}
>> +
>> +static int qcom_snps_hsphy_resume(struct qcom_snps_hsphy *hsphy)
>> +{
>> +int ret;
>> +
>> +if (!hsphy->suspended)
>> +return 0;
>> +
>> +dev_dbg(&hsphy->phy->dev, "Resume QCOM SNPS PHY, mode:%d\n",
>> +hsphy->mode);
> 
> here as well
> 

Done.

>> +
>> +ret = clk_prepare_enable(hsphy->cfg_ahb_clk);
>> +if (ret) {
>> +dev_err(&hsphy->phy->dev,
>> +"failed to enable cfg ahb clock, %d\n", ret);
> 
> single line should be okay now :)
> 

Yep!

>> +return ret;
>> +}
>> +
>> +hsphy->suspended = false;
>> +return 0;
>> +}
>> +
>> +static int __maybe_unused qcom_snps_hsphy_runtime_suspend(struct device 
>> *dev)
>> +{
>> +struct qcom_snps_hsphy *hsphy = dev_get_drvdata(dev);
>> +
>> +if (!hsphy->phy_initialized)
>> +return 0;
>> +
>> +qcom_snps_hsphy_suspend(hsphy);
>> +return 0;
>> +}
>> +
>> +static int __maybe_unused qcom_snps_h

Re: NiFi 1.11 - High repository storage usage

2020-06-25 Thread Wesley C. Dias de Oliveira

Hi, Valentina.

I've experienced the same issue on an old installation.

In my case, it was related to memory usage.

The system begins to dump things to the disk when there's no available
memory.

Have you checked the memory( params?

# JVM memory settings
java.arg.2=-Xms512m
java.arg.3=-Xmx512m






Em qui., 25 de jun. de 2020 às 09:50, Valentina Ivanova <
valentina.ivan...@ri.se> escreveu:

> Hello!
>
> I see (screenshot attached) quite high (86%) storage usage for all three
> Flow File, Content & Provenance Repositories in the System Diagnostics.
> When I check the size of the respective folders on the disk they don't even
> add up to 12,24 GB shown on the screenshot.
> I also have the following settings for the content repository in
> nifi.properties:
> nifi.content.repository.archive.max.retention.period=12 hours
> nifi.content.repository.archive.max.usage.percentage=50%
> nifi.content.repository.archive.enabled=true
> nifi.content.repository.always.sync=false
>
>
> So I am wondering where these numbers are coming from and how to reduce
> the storage utilization (I assume such high utilization will impact the
> performance)? Why is the content repository usage 86% even though the
> max.usage.percentage is set at 50%.
>
> Many thanks in advance & all the best
>
> Valentina
>
>
>
>

-- 
Grato,
Wesley C. Dias de Oliveira.

Linux User nº 576838.

[Mpi-forum] Meeting Registration Reminder and Voting Guidelines

2020-06-24 Thread Wesley Bland via mpi-forum

Action Items:

1. Register for the meeting next week if you haven’t already.
2. Confirm that you are able to use the voting link and arrange who will vote
from your org.

===

Hi all,

I just wanted to send out one final reminder for people to register for next
week’s MPI Forum meeting. There are still a few orgs who usually attend but
have not registered.

https://forms.gle/65bMTDiUQBmbJgjs9

The MPI Forum procedures state that you must both register and attend the
meeting before the first voting block in order to be officially counted and to
be eligible to vote. The first voting block is Tuesday at 9:30 AM Central US so
that means you will need to have attended at least some portion of the Monday
meeting and/or the very beginning of the Tuesday meeting in order to be
eligible to vote in either voting block at the meeting.

If you’re not sure if you’ve registered, you can find the list of people here:

https://www.mpi-forum.org/meetings/2020/06/attendance

We will also be using the same voting system as from the last exceptional
virtual meeting in May (JotForm). My understanding is that you will need to
enable Javascript in your browser in order for this to work. If you’d like to
double check that the voting page will work for you this time, you can use the
voting page from last time using this link:

https://form.jotform.com/201253678123047?participantId=a1b2c3d4&name=Test_Name&org=Test_Org

When the voting block opens, I’ll be sending an automated email to the address
you used to register with a personalized link for your ballot. If you didn’t
provide an email address (I forgot to add an email address to the original
registration form), I’ll be using the one you’ve usually been using for the MPI
Forum. If you want to change the email address that I use, email me directly
and let me know.

Remember that each organization only gets one vote (not one per person). So for
those organizations with more than one representative, please make arrangements
ahead of time to determine who will be casting the ballot for your
organization. If I get more than one ballot from an organization, I will
discard all but one of them (probably the first, maybe the last).

As always, if you have any questions or comments or think I’ve made any
mistakes, please let me know on email or Slack.

Thanks,
Wes___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

[RFC v4 1/3] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements

Some devices have USB compositions which may require multiple endpoints
that support EP bursting.  HW defined TX FIFO sizes may not always be
sufficient for these compositions.  By utilizing flexible TX FIFO
allocation, this allows for endpoints to request the required FIFO depth to
achieve higher bandwidth.  With some higher bMaxBurst configurations, using
a larger TX FIFO size results in better TX throughput.

Ensure that one TX FIFO is reserved for every IN endpoint.  This allows for
the FIFO logic to prevent running out of FIFO space.

Signed-off-by: Wesley Cheng 
---
 drivers/usb/dwc3/core.c   |   2 +
 drivers/usb/dwc3/core.h   |   8 +++
 drivers/usb/dwc3/ep0.c|  37 +++-
 drivers/usb/dwc3/gadget.c | 115 ++
 4 files changed, 161 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index edc17155cb2b..cca555493929 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1304,6 +1304,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
&tx_thr_num_pkt_prd);
device_property_read_u8(dev, "snps,tx-max-burst-prd",
&tx_max_burst_prd);
+   dwc->needs_fifo_resize = device_property_read_bool(dev,
+   "tx-fifo-resize");
 
dwc->disable_scramble_quirk = device_property_read_bool(dev,
"snps,disable_scramble_quirk");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 4c171a8e215f..ce0bf288b6ac 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -675,6 +675,7 @@ struct dwc3_event_buffer {
  * isochronous START TRANSFER command failure workaround
  * @start_cmd_status: the status of testing START TRANSFER command with
  * combo_num = 'b00
+ * @fifo_depth: allocated TXFIFO depth
  */
 struct dwc3_ep {
struct usb_ep   endpoint;
@@ -727,6 +728,7 @@ struct dwc3_ep {
/* For isochronous START TRANSFER workaround only */
u8  combo_num;
int start_cmd_status;
+   int fifo_depth;
 };
 
 enum dwc3_phy {
@@ -1004,6 +1006,7 @@ struct dwc3_scratchpad_array {
  * 1   - utmi_l1_suspend_n
  * @is_fpga: true when we are using the FPGA board
  * @pending_events: true when we have pending IRQs to be handled
+ * @needs_fifo_resize: not all users might want fifo resizing, flag it
  * @pullups_connected: true when Run/Stop bit is set
  * @setup_packet_pending: true when there's a Setup Packet in FIFO. Workaround
  * @three_stage_setup: set if we perform a three phase setup
@@ -1044,6 +1047,8 @@ struct dwc3_scratchpad_array {
  * @dis_metastability_quirk: set to disable metastability quirk.
  * @imod_interval: set the interrupt moderation interval in 250ns
  * increments or 0 to disable.
+ * @last_fifo_depth: total TXFIFO depth of all enabled USB IN/INT endpoints
+ * @num_ep_resized: the number of TX FIFOs that have already been resized
  */
 struct dwc3 {
struct work_struct  drd_work;
@@ -1204,6 +1209,7 @@ struct dwc3 {
unsignedis_utmi_l1_suspend:1;
unsignedis_fpga:1;
unsignedpending_events:1;
+   unsignedneeds_fifo_resize:1;
unsignedpullups_connected:1;
unsignedsetup_packet_pending:1;
unsignedthree_stage_setup:1;
@@ -1236,6 +1242,8 @@ struct dwc3 {
unsigneddis_metastability_quirk:1;
 
u16 imod_interval;
+   int last_fifo_depth;
+   int num_ep_resized;
 };
 
 #define INCRX_BURST_MODE 0
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 6dee4dabc0a4..76db9b530861 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -601,8 +601,9 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct 
usb_ctrlrequest *ctrl)
 {
enum usb_device_state state = dwc->gadget.state;
u32 cfg;
-   int ret;
+   int ret, num, size;
u32 reg;
+   struct dwc3_ep *dep;
 
cfg = le16_to_cpu(ctrl->wValue);
 
@@ -611,6 +612,40 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct 
usb_ctrlrequest *ctrl)
return -EINVAL;
 
case USB_STATE_ADDRESS:
+   /*
+* If tx-fifo-resize flag is not set for the controller, then
+* do not clear existing allocated TXFIFO since we do not
+* allocate it again in dwc3_gadget_resize_tx_fifos
+*/
+   if (dwc->needs_fifo_resize) {
+   /* Read ep0IN related TXFIFO size */
+   dep = dwc->eps[1];
+   size = dwc3_readl(dwc->reg

[RFC v4 3/3] dt-bindings: usb: dwc3: Add entry for tx-fifo-resize

Re-introduce the comment for the tx-fifo-resize setting for the DWC3
controller.  This allows for vendors to control if they require the TX FIFO
resizing logic on their HW, as the default FIFO size configurations may
already be sufficient.

Signed-off-by: Wesley Cheng 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/usb/dwc3.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 9946ff9ba735..489f5da83744 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -105,7 +105,7 @@ Optional properties:
1-16 (DWC_usb31 programming guide section 1.2.3) to
enable periodic ESS TX threshold.
 
- -  tx-fifo-resize: determines if the FIFO *has* to be reallocated.
+ - tx-fifo-resize: determines if the FIFO *has* to be reallocated.
  - snps,incr-burst-type-adjustment: Value for INCR burst type of GSBUSCFG0
register, undefined length INCR burst type enable and 
INCRx type.
When just one value, which means INCRX burst mode 
enabled. When
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[RFC v4 0/3] Re-introduce TX FIFO resize for larger EP bursting

Changes in V4:
 - Removed struct dwc3* as an argument for dwc3_gadget_resize_tx_fifos()
 - Removed WARN_ON(1) in case we run out of fifo space
 
Changes in V3:
 - Removed "Reviewed-by" tags
 - Renamed series back to RFC
 - Modified logic to ensure that fifo_size is reset if we pass the minimum
   threshold.  Tested with binding multiple FDs requesting 6 FIFOs.

Changes in V2:
 - Modified TXFIFO resizing logic to ensure that each EP is reserved a
   FIFO.
 - Removed dev_dbg() prints and fixed typos from patches
 - Added some more description on the dt-bindings commit message

Currently, there is no functionality to allow for resizing the TXFIFOs, and
relying on the HW default setting for the TXFIFO depth.  In most cases, the
HW default is probably sufficient, but for USB compositions that contain
multiple functions that require EP bursting, the default settings
might not be enough.  Also to note, the current SW will assign an EP to a
function driver w/o checking to see if the TXFIFO size for that particular
EP is large enough. (this is a problem if there are multiple HW defined
values for the TXFIFO size)

It is mentioned in the SNPS databook that a minimum of TX FIFO depth = 3
is required for an EP that supports bursting.  Otherwise, there may be
frequent occurences of bursts ending.  For high bandwidth functions,
such as data tethering (protocols that support data aggregation), mass
storage, and media transfer protocol (over FFS), the bMaxBurst value can be
large, and a bigger TXFIFO depth may prove to be beneficial in terms of USB
throughput. (which can be associated to system access latency, etc...)  It
allows for a more consistent burst of traffic, w/o any interruptions, as
data is readily available in the FIFO.

With testing done using the mass storage function driver, the results show
that with a larger TXFIFO depth, the bandwidth increased significantly.

Test Parameters:
 - Platform: Qualcomm SM8150
 - bMaxBurst = 6
 - USB req size = 256kB
 - Num of USB reqs = 16
 - USB Speed = Super-Speed
 - Function Driver: Mass Storage (w/ ramdisk)
 - Test Application: CrystalDiskMark

Results:

TXFIFO Depth = 3 max packets

Test Case | Data Size | AVG tput (in MB/s)
---
Sequential|1 GB x | 
Read  |9 loops| 193.60
  |   | 195.86
  |   | 184.77
  |   | 193.60
---

TXFIFO Depth = 6 max packets

Test Case | Data Size | AVG tput (in MB/s)
---
Sequential|1 GB x | 
Read  |9 loops| 287.35
  |   | 304.94
  |   | 289.64
  |   | 293.61
-------

Wesley Cheng (3):
  usb: dwc3: Resize TX FIFOs to meet EP bursting requirements
  arm64: boot: dts: qcom: sm8150: Enable dynamic TX FIFO resize logic
  dt-bindings: usb: dwc3: Add entry for tx-fifo-resize

 .../devicetree/bindings/usb/dwc3.txt  |   2 +-
 arch/arm64/boot/dts/qcom/sm8150.dtsi  |   1 +
 drivers/usb/dwc3/core.c   |   2 +
 drivers/usb/dwc3/core.h   |   8 ++
 drivers/usb/dwc3/ep0.c|  37 +-
 drivers/usb/dwc3/gadget.c | 115 ++
 6 files changed, 163 insertions(+), 2 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[RFC v4 2/3] arm64: boot: dts: qcom: sm8150: Enable dynamic TX FIFO resize logic

Enable the flexible TX FIFO resize logic on SM8150.  Using a larger TX FIFO
SZ can help account for situations when system latency is greater than the
USB bus transmission latency.

Signed-off-by: Wesley Cheng 
---
 arch/arm64/boot/dts/qcom/sm8150.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi 
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index a36512d1f6a1..c28523313955 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -708,6 +708,7 @@ usb_1_dwc3: dwc3@a60 {
interrupts = ;
snps,dis_u2_susphy_quirk;
snps,dis_enblslpm_quirk;
+   tx-fifo-resize;
phys = <&usb_1_hsphy>, <&usb_1_ssphy>;
phy-names = "usb2-phy", "usb3-phy";
};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: Symbol.await proposal

2020-06-22 Thread Wesley Oliver

> Hi,
>
> That doesn't work, kinda work in javascript world where the function has
> finite, fixed set of arguments, were there is a definition of last one.
> Typescript helps a lot with that, because
> it can ensure to a higher degree, that types are correct, js on its own,
> loose so you have less guarantees of the binding.
> Just have to assume that every function has like a callback by convention,
> if it doesn't then break things again.
> Typescript does help.
>
> function anyArguments(callback) {
>  let args = [...arguments];
> // args.length > 99 and callback is the 1st parameters.
> }
>
> You can check out this is want project setup, that allow us to peace meal
> upgrade to ts.
> https://github.com/wesleyolis/configFactoryLoaderAndValidator
> Few additional pointers:
> type AnyJS = any; / this allow you keep track of intentional usage, so
> search codebase later.
>  If you have old library with no types, then basically import the new
> library with types under a different alias name,
> then have both old and new versions and peace meal upgrade as required.
>
> Kind Regards,
>
> Wesley Oliver
>
>
>
> On Mon, Jun 22, 2020 at 10:13 PM Jamie  wrote:
>
>> One of the common refactorings I do is:
>>
>> let file1 = await readFile(filename1)
>> let file2 = await readFile(filename2)
>> // to
>> let [file1, file2] = await Promise.all([
>>   readFile(filename1),
>>   readFile(filename2),
>> ])
>>
>> I would be very confused if refactoring it in this way made my code break
>> because of some implicit behavior around `await` specifically.
>>
>> I have seen some APIs that switch to promises when a callback argument is
>> not provided. Is this not a sufficient solution?
>>
>> On Mon, Jun 22, 2020 at 12:22 PM James M Snell  wrote:
>>
>>> For many legacy code bases that are based on callbacks mechanisms like
>>> node.js' promisify function are required to help facilitate the transition
>>> from callback centric code to Promise-centric. A lot of the time, these can
>>> follow straightforward rules without requiring customization. However, at
>>> other times it is necessary for user code to provide custom implementations
>>> of the Promise-version of the function.
>>>
>>> In Node.js, we accomplish this by allowing a function to have a symbol
>>> attached whose value is an alternative function that is returned by the
>>> promisify function
>>>
>>> For instance,
>>>
>>>   function myFunction(foo, bar, callback) {
>>> callback(null, foo, bar);
>>>   }
>>>   myFunction[util.customPromisifySymbol] = async function(foo, bar) {
>>> return [foo, bar];
>>>   }
>>>
>>>   const { promisify } = require('util');
>>>   const mine = promisify(myFunction);
>>>   (async () => console.log(await mine('a','b')))();
>>>
>>> As a convenience built into the language, it would be nice to be able to
>>> short-circuit the need to call promisify with a special language-level
>>> Symbol used specifically for this purpose:
>>>
>>>   function myFunction(foo, bar, callback) {
>>> callback(null, foo, bar);
>>>   }
>>>   myFunction[Symbol.await] = async function(foo, bar) {
>>> return [foo, bar];
>>>   }
>>>
>>>   (async () => console.log(await myFunction('a','b')))();
>>>
>>> The idea here is that if the function being awaited has the
>>> [Symbol.await] property whose value is a function, then that function is
>>> called when the await keyword is used. That is,
>>>
>>>   myFunction('a', 'b', callback); // Invokes myFunction directly
>>>   await myFunction('a', 'b');  // Invokes myFunction[Symbol.await]
>>>
>>> if the Symbol.await property is not set or is not callable, then it
>>> would fallback to default behavior.
>>>
>>> Automatic handling of this binding should also happen but has some
>>> technical detail to work out:
>>>
>>>   const obj = {
>>> a: 1,
>>> foo() {}
>>>   };
>>>   obj.foo[Symbol.await] = async function() {
>>> return this.a;
>>>   }
>>>   await obj.foo();  // Calls await obj.foo[Symbol.await] with bound this
>>>
>>> This approach would make it far easier for legacy code bases to make the
>>> transition to async/await syntax while maintaining

Re: Symbol.await proposal

2020-06-22 Thread Wesley Oliver

Hi,

The one interesting case you have to look at dealing with, is the one I
came across where by the call of a function can return a results and will
then later async call the callback in the future.
Because with the proposal above, you have lost the ability to, return the
return result and callback results you have return {execReturn:...,
awaitResult:}, this doesn't happen offen.

I think one approach that you could take but wouldn't always work, check
for additional the call back parameter, then either return Promisification
or you do the call back execution.
a wrapper would help with that.

The other could also look at a special import syntax for modules, whereby
methods are automatically promisified, with this wrap approach or shallow
copy.

The problem is that for a function that can accept in javascript any number
of parameters, arguments, were is no finite number of arguments,  you can't
be certain that there is a callback or if the last parameter
is indeed a param. One could do type check on the last parameter, otherwise
you have a naming convention for functions, to avoid the confusion,
provided you could check the key(name)
Promise all suffers the same problem with the last parameter, it is a
convention.

Kind Regards,

Wesley Oliver

On Mon, Jun 22, 2020 at 9:21 PM James M Snell  wrote:

> For many legacy code bases that are based on callbacks mechanisms like
> node.js' promisify function are required to help facilitate the transition
> from callback centric code to Promise-centric. A lot of the time, these can
> follow straightforward rules without requiring customization. However, at
> other times it is necessary for user code to provide custom implementations
> of the Promise-version of the function.
>
> In Node.js, we accomplish this by allowing a function to have a symbol
> attached whose value is an alternative function that is returned by the
> promisify function
>
> For instance,
>
>   function myFunction(foo, bar, callback) {
> callback(null, foo, bar);
>   }
>   myFunction[util.customPromisifySymbol] = async function(foo, bar) {
> return [foo, bar];
>   }
>
>   const { promisify } = require('util');
>   const mine = promisify(myFunction);
>   (async () => console.log(await mine('a','b')))();
>
> As a convenience built into the language, it would be nice to be able to
> short-circuit the need to call promisify with a special language-level
> Symbol used specifically for this purpose:
>
>   function myFunction(foo, bar, callback) {
> callback(null, foo, bar);
>   }
>   myFunction[Symbol.await] = async function(foo, bar) {
> return [foo, bar];
>   }
>
>   (async () => console.log(await myFunction('a','b')))();
>
> The idea here is that if the function being awaited has the [Symbol.await]
> property whose value is a function, then that function is called when the
> await keyword is used. That is,
>
>   myFunction('a', 'b', callback); // Invokes myFunction directly
>   await myFunction('a', 'b');  // Invokes myFunction[Symbol.await]
>
> if the Symbol.await property is not set or is not callable, then it would
> fallback to default behavior.
>
> Automatic handling of this binding should also happen but has some
> technical detail to work out:
>
>   const obj = {
> a: 1,
> foo() {}
>   };
>   obj.foo[Symbol.await] = async function() {
> return this.a;
>   }
>   await obj.foo();  // Calls await obj.foo[Symbol.await] with bound this
>
> This approach would make it far easier for legacy code bases to make the
> transition to async/await syntax while maintaining legacy compat.
>
> Before writing up a formal proposal, I wanted to solicit some feedback on
> this approach to see what folks thought.
>
> - James
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>

-- 

GitHub:https://github.com/wesleyolis
LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
Blog/Website:https://sites.google.com/site/wiprogamming/Home
Skype: wezley_oliver
MSN messenger: wesley.o...@gmail.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Symbol.await proposal

2020-06-22 Thread Wesley Oliver

rs will return a promisified method
>
> const promise = Promisify(object, 'method');const results = await 
> promise(param1, param2, param3, param3);
>
>
> <https://github.com/wesleyolis/BlueBirdObjectOrientatedPromisification#promises-return-type-can-also-be-overloaded>Promises
> Return type can also be overloaded
>
> Requires spesifying both Promise Return type and callback method type.
>
> const promise = Promisify<{results : ''},(() => void)>(method);
>
>
> <https://github.com/wesleyolis/BlueBirdObjectOrientatedPromisification#promise-with-returntype-some-weird-libaries>Promise
> with ReturnType, some weird libaries.
>
> const promise = PromisifyReturn(...);let returnType = 
> {}promise(,returnType);
> console.log(returnType['executeResult']);
>
>
> On Mon, Jun 22, 2020 at 9:21 PM James M Snell  wrote:
>
>> For many legacy code bases that are based on callbacks mechanisms like
>> node.js' promisify function are required to help facilitate the transition
>> from callback centric code to Promise-centric. A lot of the time, these can
>> follow straightforward rules without requiring customization. However, at
>> other times it is necessary for user code to provide custom implementations
>> of the Promise-version of the function.
>>
>> In Node.js, we accomplish this by allowing a function to have a symbol
>> attached whose value is an alternative function that is returned by the
>> promisify function
>>
>> For instance,
>>
>>   function myFunction(foo, bar, callback) {
>> callback(null, foo, bar);
>>   }
>>   myFunction[util.customPromisifySymbol] = async function(foo, bar) {
>> return [foo, bar];
>>   }
>>
>>   const { promisify } = require('util');
>>   const mine = promisify(myFunction);
>>   (async () => console.log(await mine('a','b')))();
>>
>> As a convenience built into the language, it would be nice to be able to
>> short-circuit the need to call promisify with a special language-level
>> Symbol used specifically for this purpose:
>>
>>   function myFunction(foo, bar, callback) {
>> callback(null, foo, bar);
>>   }
>>   myFunction[Symbol.await] = async function(foo, bar) {
>> return [foo, bar];
>>   }
>>
>>   (async () => console.log(await myFunction('a','b')))();
>>
>> The idea here is that if the function being awaited has the
>> [Symbol.await] property whose value is a function, then that function is
>> called when the await keyword is used. That is,
>>
>>   myFunction('a', 'b', callback); // Invokes myFunction directly
>>   await myFunction('a', 'b');  // Invokes myFunction[Symbol.await]
>>
>> if the Symbol.await property is not set or is not callable, then it would
>> fallback to default behavior.
>>
>> Automatic handling of this binding should also happen but has some
>> technical detail to work out:
>>
>>   const obj = {
>> a: 1,
>> foo() {}
>>   };
>>   obj.foo[Symbol.await] = async function() {
>> return this.a;
>>   }
>>   await obj.foo();  // Calls await obj.foo[Symbol.await] with bound this
>>
>> This approach would make it far easier for legacy code bases to make the
>> transition to async/await syntax while maintaining legacy compat.
>>
>> Before writing up a formal proposal, I wanted to solicit some feedback on
>> this approach to see what folks thought.
>>
>> - James
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> --
> 
> GitHub:https://github.com/wesleyolis
> LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
> Blog/Website:https://sites.google.com/site/wiprogamming/Home
> Skype: wezley_oliver
> MSN messenger: wesley.o...@gmail.com
>


-- 

GitHub:https://github.com/wesleyolis
LinkedIn:https://www.linkedin.com/in/wesley-walter-anton-oliver-85466613b/
Blog/Website:https://sites.google.com/site/wiprogamming/Home
Skype: wezley_oliver
MSN messenger: wesley.o...@gmail.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [PATCH v3 2/6] dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding

2020-06-22 Thread Wesley Cheng




On 6/18/2020 3:23 PM, Rob Herring wrote:
> On Thu, Jun 18, 2020 at 2:09 PM Wesley Cheng  wrote:
>>
>>
>> On 6/18/2020 11:33 AM, Rob Herring wrote:
>>> On Wed, Jun 17, 2020 at 12:02 PM Wesley Cheng  wrote:
>>>
>>> You are duplicating everything in usb-connector.yaml. You should have
>>> a $ref to it.
>>>
>>
>> Hi Rob,
>>
>> Sure, I will add a reference to that doc.
>>
>>>
>>> This is wrong. The connector binding says port 0 is the connection the
>>> USB HS controller.
>>>
>>> What's a type C mux node? Is there a binding for that? There's an
>>> ongoing discussion with the CrOS folks on how to describe Alt mode
>>> mux/switches.
>>
>> I reviewed the connector binding previously, and couldn't seem to come
>> up with a model which fit a design where the type C controller (ie the
>> entity which does the CC orientation and role detection) does not have
>> the SS lane mux included.  The SS lane mux is the HW which handles the
>> selection of the SS lanes to utilize based on cable orientation.
> 
> The intent was the controller would be the parent node of the connector.
> 

Hi Rob,

Correct, I agree with that point, and in the changes uploaded, the QCOM
PMIC type C controller will be the parent node for the connector.

> How the SS lane mux is represented is what needs to be figured out. I
> don't know what that looks like, but it needs to be something that
> works for multiple designs. Ideally, that's an extension of the
> existing 'usb-c-connector' binding, but if there's good reasons to
> redesign it that can happen.
> 
> Rob
> 

We probably wouldn't need to redesign it, but maybe if we can remove the
connector port assignments requirement, it would allow for some
flexibility.  From my knowledge, I don't think any driver is actually
utilizing or checking the port number assignments, so there isn't a
limitation on what could be defined in there.

Here's a simplified diagram of the FUSB302 reference design from the
data sheet.  The I2C bus is just for CSR access to the FUSB302.

   ___   ___
__|FUSB302| |SOC|
   |  |Type C | |   |
   |  |Cntrl  |__I2C___ |   |
   |  |___| |   |
 ___   ||   |
|   |__ CC1/2 _||   |
|   |__ HS DP/DM __ |   |
|   |   |   |
    |   |
|   |__ SS RX/TX1 |FUSB304 |__SS RX/TX_ |   |
|   |__ SS RX/TX2 |USB Mux ||___|
|   | ||
|   |
|___|


Otherwise, we can just simply add another port definition for external
SS lane muxes if possible.

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: GridIoManager compile error(2.8.0)

2020-06-21 Thread Wesley





38797715 wrote:
I downloaded the source code of version 2.8.1, but found that it could 
not be compiled successfully, and there were compilation errors in the 
code.


We just use the binary package, won't compile that by ourselves. :)

regards

Re: Unsubscribe

2020-06-21 Thread Wesley


please send an empty email to:
dev-unsubscr...@spark.apache.org
user-unsubscr...@spark.apache.org

for unsubscribing yourself from the lists.

Thanks.


-
To unsubscribe e-mail: user-unsubscr...@spark.apache.org

Re: [PATCH v3 2/6] dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding

2020-06-18 Thread Wesley Cheng

On 6/18/2020 11:33 AM, Rob Herring wrote:
> On Wed, Jun 17, 2020 at 12:02 PM Wesley Cheng  wrote:
> 
> You are duplicating everything in usb-connector.yaml. You should have
> a $ref to it.
> 

Hi Rob,

Sure, I will add a reference to that doc.

> 
> This is wrong. The connector binding says port 0 is the connection the
> USB HS controller.
> 
> What's a type C mux node? Is there a binding for that? There's an
> ongoing discussion with the CrOS folks on how to describe Alt mode
> mux/switches.

I reviewed the connector binding previously, and couldn't seem to come
up with a model which fit a design where the type C controller (ie the
entity which does the CC orientation and role detection) does not have
the SS lane mux included.  The SS lane mux is the HW which handles the
selection of the SS lanes to utilize based on cable orientation.

I looked at the FUSB302 TCPM driver, which doesn't have an integrated SS
lane mux, and relies on an external FUSB340 switch to handle the
polarity, but seems that in the fusb302.c driver it doesn't implement
the polarity handler.  They might possibly have a HW output signal which
controls the mux directly, but I'm not sure on that.

Anyway, if someone wanted to take a SW approach and program an external
mux, this model doesn't seem to allow that.  This is somewhat unrelated
to the DP AUX mode switching, as that probably will only come into the
picture after the policy engine has detected there is a DP adapter
connected, whereas this is applicable to non DP/alt mode situations.

Thanks!

>> +type: object
>> +
>> +properties:
>> +  remote-endpoint:
>> +maxItems: 1
>> +description: Node reference to the type C mux
>> +
>> +  endpoint@1:
>> +description: Connection to role switch node
> 
> Again, what's this?
> 

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re:

2020-06-17 Thread Wesley

Please send an empty email to: user-unsubscr...@hive.apache.org for 
unsubscribing yourself. Thanks.




user-unsubscribe

[PATCH v3 5/6] dt-bindings: regulator: Add dt-binding for QCOM PMIC VBUS output regulator

This describes how to enable the Qualcomm PMIC VBUS booster used for
providing power to connected USB peripherals when the USB role is host
mode.  The driver itself will register the vbus_usb regulator, so that
external drivers can utilize the enable/disable regulator APIs.

Signed-off-by: Wesley Cheng 
---
 .../regulator/qcom,usb-vbus-regulator.yaml| 41 +++
 1 file changed, 41 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml

diff --git 
a/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml 
b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
new file mode 100644
index ..2fa76111cfb9
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/qcom,usb-vbus-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: The Qualcomm PMIC VBUS output regulator driver
+
+maintainers:
+  - Wesley Cheng 
+
+description: |
+  This regulator driver controls the VBUS output by the Qualcomm PMIC.  This
+  regulator will be enabled in situations where the device is required to
+  provide power to the connected peripheral.
+
+properties:
+  compatible:
+enum:
+  - qcom,pm8150b-vbus-reg
+
+  reg:
+maxItems: 1
+description: VBUS output base address
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+ pm8150b {
+#address-cells = <1>;
+#size-cells = <0>;
+qcom,dcdc@1100 {
+compatible = "qcom,pm8150b-vbus-reg";
+reg = <0x1100>;
+};
+ };
+...
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 0/6] Introduce PMIC based USB type C detection

Changes in v3:
 - Fix driver reference to match driver name in Kconfig for
   qcom_usb_vbus-regulator.c
 - Utilize regulator bitmap helpers for enable, disable and is enabled calls in
   qcom_usb_vbus-regulator.c
 - Use of_get_regulator_init_data() to initialize regulator init data, and to
   set constraints in qcom_usb_vbus-regulator.c
 - Remove the need for a local device structure in the vbus regulator driver
 
Changes in v2:
 - Use devm_kzalloc() in qcom_pmic_typec_probe()
 - Add checks to make sure return value of typec_find_port_power_role() is
   valid
 - Added a VBUS output regulator driver, which will be used by the PMIC USB
   type c driver to enable/disable the source
 - Added logic to control vbus source from the PMIC type c driver when
   UFP/DFP is detected
 - Added dt-binding for this new regulator driver
 - Fixed Kconfig typec notation to match others
 - Leave type C block disabled until enabled by a platform DTS

Add the required drivers for implementing type C orientation and role
detection using the Qualcomm PMIC.  Currently, PMICs such as the PM8150B
have an integrated type C block, which can be utilized for this.  This
series adds the dt-binding, PMIC type C driver, and DTS nodes.

The PMIC type C driver will register itself as a type C port w/ a
registered type C switch for orientation, and will fetch a USB role switch
handle for the role notifications.  It will also have the ability to enable
the VBUS output to any connected devices based on if the device is behaving
as a UFP or DFP.

Wesley Cheng (6):
  usb: typec: Add QCOM PMIC typec detection driver
  dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding
  arm64: boot: dts: qcom: pm8150b: Add node for USB type C block
  regulator: Add support for QCOM PMIC VBUS booster
  dt-bindings: regulator: Add dt-binding for QCOM PMIC VBUS output
regulator
  arm64: boot: dts: qcom: pm8150b: Add DTS node for PMIC VBUS booster

 .../regulator/qcom,usb-vbus-regulator.yaml|  41 +++
 .../bindings/usb/qcom,pmic-typec.yaml | 117 
 arch/arm64/boot/dts/qcom/pm8150b.dtsi |  14 +
 arch/arm64/boot/dts/qcom/sm8150-mtp.dts   |   7 +
 drivers/regulator/Kconfig |  10 +
 drivers/regulator/Makefile|   1 +
 drivers/regulator/qcom_usb_vbus-regulator.c   | 100 +++
 drivers/usb/typec/Kconfig |  12 +
 drivers/usb/typec/Makefile|   1 +
 drivers/usb/typec/qcom-pmic-typec.c   | 275 ++
 10 files changed, 578 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
 create mode 100644 Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
 create mode 100644 drivers/regulator/qcom_usb_vbus-regulator.c
 create mode 100644 drivers/usb/typec/qcom-pmic-typec.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 6/6] arm64: boot: dts: qcom: pm8150b: Add DTS node for PMIC VBUS booster

Add the required DTS node for the USB VBUS output regulator, which is
available on PM8150B.  This will provide the VBUS source to connected
peripherals.

Signed-off-by: Wesley Cheng 
---
 arch/arm64/boot/dts/qcom/pm8150b.dtsi   | 6 ++
 arch/arm64/boot/dts/qcom/sm8150-mtp.dts | 7 +++
 2 files changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi 
b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
index ec44a8bc2f84..b7274d9d7341 100644
--- a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
@@ -22,6 +22,12 @@ power-on@800 {
status = "disabled";
};
 
+   qcom,dcdc@1100 {
+   compatible = "qcom,pm8150b-vbus-reg";
+   status = "disabled";
+   reg = <0x1100>;
+   };
+
qcom,typec@1500 {
compatible = "qcom,pm8150b-usb-typec";
status = "disabled";
diff --git a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts 
b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
index 6c6325c3af59..3845d19893eb 100644
--- a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
@@ -426,6 +426,13 @@ &usb_1 {
status = "okay";
 };
 
+&spmi_bus {
+   pmic@2 {
+   qcom,dcdc@1100 {
+   status = "okay";
+   };
+};
+
 &usb_1_dwc3 {
dr_mode = "peripheral";
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 3/6] arm64: boot: dts: qcom: pm8150b: Add node for USB type C block

The PM8150B has a dedicated USB type C block, which can be used for type C
orientation and role detection.  Create the reference node to this type C
block for further use.

Signed-off-by: Wesley Cheng 
---
 arch/arm64/boot/dts/qcom/pm8150b.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi 
b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
index 322379d5c31f..ec44a8bc2f84 100644
--- a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
@@ -22,6 +22,14 @@ power-on@800 {
status = "disabled";
};
 
+   qcom,typec@1500 {
+   compatible = "qcom,pm8150b-usb-typec";
+   status = "disabled";
+   reg = <0x1500>;
+   interrupts =
+   <0x2 0x15 0x5 IRQ_TYPE_EDGE_RISING>;
+   };
+
adc@3100 {
compatible = "qcom,spmi-adc5";
reg = <0x3100>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 2/6] dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding

Introduce the dt-binding for enabling USB type C orientation and role
detection using the PM8150B.  The driver will be responsible for receiving
the interrupt at a state change on the CC lines, reading the orientation/role,
and communicating this information to the remote clients, which can include
a role switch node and a type C switch.

Signed-off-by: Wesley Cheng 
---
 .../bindings/usb/qcom,pmic-typec.yaml | 117 ++
 1 file changed, 117 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml

diff --git a/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml 
b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
new file mode 100644
index ..085b4547d75a
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
@@ -0,0 +1,117 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/usb/qcom,pmic-typec.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Qualcomm PMIC based USB type C Detection Driver
+
+maintainers:
+  - Wesley Cheng 
+
+description: |
+  Qualcomm PMIC Type C Detect
+
+properties:
+  compatible:
+enum:
+  - qcom,pm8150b-usb-typec
+
+  reg:
+maxItems: 1
+description: Type C base address
+
+  interrupts:
+maxItems: 1
+description: CC change interrupt from PMIC
+
+  connector:
+description: Connector type for remote endpoints
+type: object
+
+properties:
+  compatible:
+enum:
+  - usb-c-connector
+
+  power-role:
+   enum:
+ - dual
+ - source
+ - sink
+
+  data-role:
+enum:
+  - dual
+  - host
+  - device
+
+  port:
+description: Remote endpoint connections
+type: object
+
+properties:
+  endpoint@0:
+description: Connection to USB type C mux node
+type: object
+
+properties:
+  remote-endpoint:
+maxItems: 1
+description: Node reference to the type C mux
+
+  endpoint@1:
+description: Connection to role switch node
+type: object
+
+properties:
+  remote-endpoint:
+maxItems: 1
+description: Node reference to the role switch node
+
+required:
+  - compatible
+
+required:
+  - compatible
+  - interrupts
+  - connector
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+pm8150b {
+#address-cells = <1>;
+#size-cells = <0>;
+qcom,typec@1500 {
+compatible = "qcom,pm8150b-usb-typec";
+reg = <0x1500>;
+interrupts =
+<0x2 0x15 0x5 IRQ_TYPE_EDGE_RISING>;
+
+connector {
+compatible = "usb-c-connector";
+power-role = "dual";
+data-role = "dual";
+port {
+#address-cells = <1>;
+#size-cells = <0>;
+usb3_data_ss: endpoint@0 {
+reg = <0>;
+remote-endpoint =
+<&qmp_ss_mux>;
+};
+
+usb3_role: endpoint@1 {
+
+reg = <1>;
+remote-endpoint =
+<&dwc3_drd_switch>;
+};
+};
+};
+};
+};
+...
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3 1/6] usb: typec: Add QCOM PMIC typec detection driver

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 attains a handle to the VBUS output regulator, so it
can enable/disable the VBUS source when acting as a host/device.

Signed-off-by: Wesley Cheng 
---
 drivers/usb/typec/Kconfig   |  12 ++
 drivers/usb/typec/Makefile  |   1 +
 drivers/usb/typec/qcom-pmic-typec.c | 275 
 3 files changed, 288 insertions(+)
 create mode 100644 drivers/usb/typec/qcom-pmic-typec.c

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index b4f2aac7ae8a..595c14766e99 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -72,6 +72,18 @@ 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 Type-C driver"
+   depends on ARCH_QCOM
+   help
+ Driver for supporting role switch over the Qualcomm PMIC.  This will
+ handle the USB Type-C role and orientation detection reported by the
+ QCOM PMIC if the PMIC has the capability to handle USB 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 7753a5c3cd46..cceffd987643 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 ..5ae3af03c638
--- /dev/null
+++ b/drivers/usb/typec/qcom-pmic-typec.c
@@ -0,0 +1,275 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TYPEC_MISC_STATUS  0xb
+#define CC_ATTACHEDBIT(0)
+#define CC_ORIENTATION BIT(1)
+#define SNK_SRC_MODE   BIT(6)
+#define TYPEC_MODE_CFG 0x44
+#define TYPEC_DISABLE_CMD  BIT(0)
+#define EN_SNK_ONLYBIT(1)
+#define EN_SRC_ONLYBIT(2)
+#define TYPEC_VCONN_CONTROL0x46
+#define VCONN_EN_SRC   BIT(0)
+#define VCONN_EN_VAL   BIT(1)
+#define TYPEC_EXIT_STATE_CFG   0x50
+#define SEL_SRC_UPPER_REF  BIT(2)
+#define TYPEC_INTR_EN_CFG_10x5e
+#define TYPEC_INTR_EN_CFG_1_MASK   GENMASK(7, 0)
+
+struct qcom_pmic_typec {
+   struct device   *dev;
+   struct fwnode_handle*fwnode;
+   struct regmap   *regmap;
+   u32 base;
+
+   struct typec_capability *cap;
+   struct typec_port   *port;
+   struct usb_role_switch *role_sw;
+
+   struct regulator*vbus_reg;
+   boolvbus_enabled;
+};
+
+static void qcom_pmic_typec_enable_vbus_regulator(struct qcom_pmic_typec
+   *qcom_usb, bool enable)
+{
+   int ret = 0;
+
+   if (enable == qcom_usb->vbus_enabled)
+   return;
+
+   if (!qcom_usb->vbus_reg) {
+   qcom_usb->vbus_reg = devm_regulator_get(qcom_usb->dev,
+   "usb_vbus");
+   if (IS_ERR(qcom_usb->vbus_reg)) {
+   qcom_usb->vbus_reg = NULL;
+   return;
+   }
+   }
+
+   if (enable) {
+   ret = regulator_enable(qcom_usb->vbus_reg);
+   if (ret)
+   return;
+   } else {
+   ret = regulator_disable(qcom_usb->vbus_reg);
+   if (ret)
+   return;
+   }
+   qcom_usb->vbus_enabled = enable;
+}
+
+static void qcom_pmic_typec_check_connection(struct qcom_pmic_typec *qcom_usb)
+{
+   enum typec_orientation orientation;
+   enum usb_role role;
+   unsigned int stat;
+   bool enable_vbus;
+
+   regmap_read(qcom_usb->regmap, qcom_usb->base + TYPEC_MISC_STATUS,
+   &stat);
+
+   if (stat & CC_ATTACHED) {
+   orientation = ((stat &a

[PATCH v3 4/6] regulator: Add support for QCOM PMIC VBUS booster

Some Qualcomm PMICs have the capability to source the VBUS output to
connected peripherals.  This driver will register a regulator to the
regulator list to enable or disable this source by an external driver.

Signed-off-by: Wesley Cheng 
---
 drivers/regulator/Kconfig   |  10 ++
 drivers/regulator/Makefile  |   1 +
 drivers/regulator/qcom_usb_vbus-regulator.c | 100 
 3 files changed, 111 insertions(+)
 create mode 100644 drivers/regulator/qcom_usb_vbus-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 074a2ef55943..79d6b7596f0b 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -797,6 +797,16 @@ config REGULATOR_QCOM_SPMI
  Qualcomm SPMI PMICs as a module. The module will be named
  "qcom_spmi-regulator".
 
+config REGULATOR_QCOM_USB_VBUS
+   tristate "Qualcomm USB Vbus regulator driver"
+   depends on SPMI || COMPILE_TEST
+   help
+ If you say yes to this option, support will be included for the
+ regulator used to enable the VBUS output.
+
+ Say M here if you want to include support for enabling the VBUS output
+ as a module. The module will be named "qcom_usb_vbus-regulator".
+
 config REGULATOR_RC5T583
tristate "RICOH RC5T583 Power regulators"
depends on MFD_RC5T583
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index c0d6b96ebd78..cbab28aa7b56 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -89,6 +89,7 @@ obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_SPMI) += qcom_spmi-regulator.o
+obj-$(CONFIG_REGULATOR_QCOM_USB_VBUS) += qcom_usb_vbus-regulator.o
 obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o
 obj-$(CONFIG_REGULATOR_PFUZE100) += pfuze100-regulator.o
 obj-$(CONFIG_REGULATOR_PV88060) += pv88060-regulator.o
diff --git a/drivers/regulator/qcom_usb_vbus-regulator.c 
b/drivers/regulator/qcom_usb_vbus-regulator.c
new file mode 100644
index ..fa7a3d891808
--- /dev/null
+++ b/drivers/regulator/qcom_usb_vbus-regulator.c
@@ -0,0 +1,100 @@
+// SPDX-License-Identifier: GPL-2.0-only
+//
+// Qualcomm PMIC VBUS output regulator driver
+//
+// Copyright (c) 2020, The Linux Foundation. All rights reserved.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CMD_OTG0x40
+#define OTG_EN BIT(0)
+#define OTG_CFG0x53
+#define OTG_EN_SRC_CFG BIT(1)
+
+static const struct regulator_ops qcom_usb_vbus_reg_ops = {
+   .enable = regulator_enable_regmap,
+   .disable = regulator_disable_regmap,
+   .is_enabled = regulator_is_enabled_regmap,
+};
+
+static struct regulator_desc qcom_usb_vbus_rdesc = {
+   .name = "usb_vbus",
+   .ops = &qcom_usb_vbus_reg_ops,
+   .owner = THIS_MODULE,
+   .type = REGULATOR_VOLTAGE,
+};
+
+static const struct of_device_id qcom_usb_vbus_regulator_match[] = {
+   { .compatible = "qcom,pm8150b-vbus-reg" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, qcom_usb_vbus_regulator_match);
+
+static int qcom_usb_vbus_regulator_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct regulator_dev *rdev;
+   struct regmap   *regmap;
+   struct regulator_config config = { };
+   struct regulator_init_data *init_data;
+   int ret;
+   u32 base;
+
+   ret = of_property_read_u32(dev->of_node, "reg", &base);
+   if (ret < 0) {
+   dev_err(dev, "no base address found\n");
+   return ret;
+   }
+
+   regmap = dev_get_regmap(dev->parent, NULL);
+   if (regmap) {
+   dev_err(dev, "Failed to get regmap\n");
+   return -ENOENT;
+   }
+
+   init_data = of_get_regulator_init_data(dev, dev->of_node,
+  &qcom_usb_vbus_rdesc);
+   if (!init_data)
+   return -ENOMEM;
+
+   qcom_usb_vbus_rdesc.enable_reg = base + CMD_OTG;
+   qcom_usb_vbus_rdesc.enable_mask = OTG_EN;
+   config.dev = dev;
+   config.init_data = init_data;
+   config.regmap = regmap;
+
+   rdev = devm_regulator_register(dev, &qcom_usb_vbus_rdesc, &config);
+   if (IS_ERR(rdev)) {
+   ret = PTR_ERR(rdev);
+   dev_err(dev, "not able to register vbus reg %d\n", ret);
+   return ret;
+   }
+
+   platform_set_drvdata(pdev, rdev);
+
+   /* Disable HW logic for VBUS enable */
+   regmap_update_bits(regmap, base + OTG_CFG, OTG_EN_SRC_CFG, 0);
+
+   return 0;

[Desktop-packages] [Bug 1840725] Re: Microphone not working in Ubuntu 18.04.3 LTS on new hp-spectre-x360-convertible-15 laptop

2020-06-16 Thread Wesley Batista Santos

The comment #65 was what worked for me.

https://bugs.launchpad.net/ubuntu/+source/alsa-
driver/+bug/1840725/comments/65


My OS installation is Kubuntu 18.04.

Additional and more detailed info about my laptop:

```
$ uname -a
Linux ioku 5.3.0-59-generic #53~18.04.1-Ubuntu SMP Thu Jun 4 14:58:26 UTC 2020 
x86_64 x86_64 x86_64 GNU/Linux


$ sudo dmidecode -t system
# dmidecode 3.1
Getting SMBIOS data from sysfs.
SMBIOS 3.1.1 present.

Handle 0x0012, DMI type 1, 27 bytes
System Information
Manufacturer: LENOVO
Product Name: 20QDCTO1WW
Version: ThinkPad X1 Carbon 7th
Serial Number: PF1E44X3
UUID: 06E257CC-238A-11B2-A85C-ECF7951B56CA
Wake-up Type: Power Switch
SKU Number: LENOVO_MT_20QD_BU_Think_FM_ThinkPad X1 Carbon 7th
Family: ThinkPad X1 Carbon 7th

Handle 0x0027, DMI type 12, 5 bytes
System Configuration Options

Handle 0x0037, DMI type 15, 31 bytes
System Event Log
Area Length: 1586 bytes
Header Start Offset: 0x
Header Length: 16 bytes
Data Start Offset: 0x0010
Access Method: General-purpose non-volatile data functions
Access Address: 0x00F0
Status: Valid, Not Full
Change Token: 0x0062
Header Format: Type 1
Supported Log Type Descriptors: 4
Descriptor 1: POST error
Data Format 1: POST results bitmap
Descriptor 2: PCI system error
Data Format 2: None
Descriptor 3: System reconfigured
Data Format 3: None
Descriptor 4: Log area reset/cleared
Data Format 4: None


$ arecord -l
 List of CAPTURE Hardware Devices 
card 0: sofsklhdacard [sof-skl_hda_card], device 0: HDA Analog (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofsklhdacard [sof-skl_hda_card], device 1: HDA Digital (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofsklhdacard [sof-skl_hda_card], device 6: DMIC32 (*) []
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 0: sofsklhdacard [sof-skl_hda_card], device 7: DMIC16 (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

```

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to alsa-driver in Ubuntu.
https://bugs.launchpad.net/bugs/1840725

Title:
  Microphone not working in Ubuntu 18.04.3 LTS on new hp-
  spectre-x360-convertible-15 laptop

Status in alsa-driver package in Ubuntu:
  Confirmed

Bug description:
  Internal Microphone does not work in Ubuntu 18.04.3 LTS in a new hp-
  spectre-x360-convertible-15 laptop. The microphone works perfectly on
  Windows 10 (present in Dual boot mode).

  Initially, Internal Microphone was not even detected but installing
  alsa-tools-gui and overriding pin 0x12 to the Internal Microphone
  fixed that issue. [Pin 0x13 does not work and causes static in a
  headphone if it is plugged in.]

  Microphone is not able to pick up any sound. I changed levels/settings in 
alsamixer, pavucontrol without any success:
  In alsamixer: Experimented with levels ranging from very low to very high for 
Internal Mic, Capture, etc.
  In pavucontrol: Set the Internal Mic as a fallback device, unlocked the 
channels for the mic, experimented with reducing the level for one of the 
channels (reduced right mic level to Silence while keeping the left mic level 
normal/high and vice versa).

  alsa-info:
  http://alsa-project.org/db/?f=cf6d3ccc6372f955da7d99df07afbcb31d5a6c7f

  arecord -l
   List of CAPTURE Hardware Devices 
  card 0: PCH [HDA Intel PCH], device 0: ALC285 Analog [ALC285 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1840725/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1840725] Re: Microphone not working in Ubuntu 18.04.3 LTS on new hp-spectre-x360-convertible-15 laptop

2020-06-16 Thread Wesley Batista Santos

The comment #65 was what worked for me.

https://bugs.launchpad.net/ubuntu/+source/alsa-
driver/+bug/1840725/comments/65


My OS installation is Kubuntu 18.04.

Additional and more detailed info about my laptop:

```
$ uname -a
Linux ioku 5.3.0-59-generic #53~18.04.1-Ubuntu SMP Thu Jun 4 14:58:26 UTC 2020 
x86_64 x86_64 x86_64 GNU/Linux


$ sudo dmidecode -t system
# dmidecode 3.1
Getting SMBIOS data from sysfs.
SMBIOS 3.1.1 present.

Handle 0x0012, DMI type 1, 27 bytes
System Information
Manufacturer: LENOVO
Product Name: 20QDCTO1WW
Version: ThinkPad X1 Carbon 7th
Serial Number: PF1E44X3
UUID: 06E257CC-238A-11B2-A85C-ECF7951B56CA
Wake-up Type: Power Switch
SKU Number: LENOVO_MT_20QD_BU_Think_FM_ThinkPad X1 Carbon 7th
Family: ThinkPad X1 Carbon 7th

Handle 0x0027, DMI type 12, 5 bytes
System Configuration Options

Handle 0x0037, DMI type 15, 31 bytes
System Event Log
Area Length: 1586 bytes
Header Start Offset: 0x
Header Length: 16 bytes
Data Start Offset: 0x0010
Access Method: General-purpose non-volatile data functions
Access Address: 0x00F0
Status: Valid, Not Full
Change Token: 0x0062
Header Format: Type 1
Supported Log Type Descriptors: 4
Descriptor 1: POST error
Data Format 1: POST results bitmap
Descriptor 2: PCI system error
Data Format 2: None
Descriptor 3: System reconfigured
Data Format 3: None
Descriptor 4: Log area reset/cleared
Data Format 4: None


$ arecord -l
 List of CAPTURE Hardware Devices 
card 0: sofsklhdacard [sof-skl_hda_card], device 0: HDA Analog (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofsklhdacard [sof-skl_hda_card], device 1: HDA Digital (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofsklhdacard [sof-skl_hda_card], device 6: DMIC32 (*) []
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 0: sofsklhdacard [sof-skl_hda_card], device 7: DMIC16 (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

```

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to alsa-driver in Ubuntu.
https://bugs.launchpad.net/bugs/1840725

Title:
  Microphone not working in Ubuntu 18.04.3 LTS on new hp-
  spectre-x360-convertible-15 laptop

Status in alsa-driver package in Ubuntu:
  Confirmed

Bug description:
  Internal Microphone does not work in Ubuntu 18.04.3 LTS in a new hp-
  spectre-x360-convertible-15 laptop. The microphone works perfectly on
  Windows 10 (present in Dual boot mode).

  Initially, Internal Microphone was not even detected but installing
  alsa-tools-gui and overriding pin 0x12 to the Internal Microphone
  fixed that issue. [Pin 0x13 does not work and causes static in a
  headphone if it is plugged in.]

  Microphone is not able to pick up any sound. I changed levels/settings in 
alsamixer, pavucontrol without any success:
  In alsamixer: Experimented with levels ranging from very low to very high for 
Internal Mic, Capture, etc.
  In pavucontrol: Set the Internal Mic as a fallback device, unlocked the 
channels for the mic, experimented with reducing the level for one of the 
channels (reduced right mic level to Silence while keeping the left mic level 
normal/high and vice versa).

  alsa-info:
  http://alsa-project.org/db/?f=cf6d3ccc6372f955da7d99df07afbcb31d5a6c7f

  arecord -l
   List of CAPTURE Hardware Devices 
  card 0: PCH [HDA Intel PCH], device 0: ALC285 Analog [ALC285 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1840725/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Bug 1840725] Re: Microphone not working in Ubuntu 18.04.3 LTS on new hp-spectre-x360-convertible-15 laptop

2020-06-16 Thread Wesley Batista Santos

The comment #65 was what worked for me.

https://bugs.launchpad.net/ubuntu/+source/alsa-
driver/+bug/1840725/comments/65


My OS installation is Kubuntu 18.04.

Additional and more detailed info about my laptop:

```
$ uname -a
Linux ioku 5.3.0-59-generic #53~18.04.1-Ubuntu SMP Thu Jun 4 14:58:26 UTC 2020 
x86_64 x86_64 x86_64 GNU/Linux


$ sudo dmidecode -t system
# dmidecode 3.1
Getting SMBIOS data from sysfs.
SMBIOS 3.1.1 present.

Handle 0x0012, DMI type 1, 27 bytes
System Information
Manufacturer: LENOVO
Product Name: 20QDCTO1WW
Version: ThinkPad X1 Carbon 7th
Serial Number: PF1E44X3
UUID: 06E257CC-238A-11B2-A85C-ECF7951B56CA
Wake-up Type: Power Switch
SKU Number: LENOVO_MT_20QD_BU_Think_FM_ThinkPad X1 Carbon 7th
Family: ThinkPad X1 Carbon 7th

Handle 0x0027, DMI type 12, 5 bytes
System Configuration Options

Handle 0x0037, DMI type 15, 31 bytes
System Event Log
Area Length: 1586 bytes
Header Start Offset: 0x
Header Length: 16 bytes
Data Start Offset: 0x0010
Access Method: General-purpose non-volatile data functions
Access Address: 0x00F0
Status: Valid, Not Full
Change Token: 0x0062
Header Format: Type 1
Supported Log Type Descriptors: 4
Descriptor 1: POST error
Data Format 1: POST results bitmap
Descriptor 2: PCI system error
Data Format 2: None
Descriptor 3: System reconfigured
Data Format 3: None
Descriptor 4: Log area reset/cleared
Data Format 4: None


$ arecord -l
 List of CAPTURE Hardware Devices 
card 0: sofsklhdacard [sof-skl_hda_card], device 0: HDA Analog (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofsklhdacard [sof-skl_hda_card], device 1: HDA Digital (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofsklhdacard [sof-skl_hda_card], device 6: DMIC32 (*) []
  Subdevices: 0/1
  Subdevice #0: subdevice #0
card 0: sofsklhdacard [sof-skl_hda_card], device 7: DMIC16 (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

```

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1840725

Title:
  Microphone not working in Ubuntu 18.04.3 LTS on new hp-
  spectre-x360-convertible-15 laptop

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1840725/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [rdo-dev] [RDO Trunk] Renamed centos8-train builders in RDO Trunk

2020-06-16 Thread Wesley Hayutin

On Tue, Jun 16, 2020 at 11:34 AM Javier Pena  wrote:

> Dear all,
>
> A couple weeks ago, we created a new component-enabled centos8-train
> builder for RDO Trunk, using
> https://trunk.rdoproject.org/centos8-train-components as its URL.
>
> Today, we have renamed it to be the official centos8-train builder, and
> the previous non-component-enabled one has been renamed to
> centos8-train-old. To summarize:
>
> - https://trunk.rdoproject.org/centos8-train-old is the old,
> non-componentized URL
> - https://trunk.rdoproject.org/centos8-train is the new,
> component-enabled URL
>
> The TripleO CI team will work on a new component-based promotion pipeline
> for the new centos8-train builder, so we will have promoted content soon.
>
> If you were using any repo from the previous URL, and now it fails, you
> just need to add the "-old" suffix. In the future, we expect everyone to
> use the new
> component-enabled centos8-train builder, and delete the old one. Note that
> this only affects CentOS8-based builders.
>
> If you find any trouble, please do not hesitate to contact us.
>
> Regards,
> Javier
>

Awesome news Javier!
Thanks for the work and the email :)


>
> ___
> dev mailing list
> dev@lists.rdoproject.org
> http://lists.rdoproject.org/mailman/listinfo/dev
>
> To unsubscribe: dev-unsubscr...@lists.rdoproject.org
>
>
___
dev mailing list
dev@lists.rdoproject.org
http://lists.rdoproject.org/mailman/listinfo/dev

To unsubscribe: dev-unsubscr...@lists.rdoproject.org

Re: [PATCH v2 4/6] regulator: Add support for QCOM PMIC VBUS booster

2020-06-15 Thread Wesley Cheng




On 6/15/2020 5:00 AM, Mark Brown wrote:
> On Fri, Jun 12, 2020 at 04:19:16PM -0700, Wesley Cheng wrote:
> 
>> +++ b/drivers/regulator/qcom_usb_vbus-regulator.c
>> @@ -0,0 +1,147 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (c) 2020, The Linux Foundation. All rights reserved.
>> + */
> 
> Please make the entire comment a C++ one so things look more
> intentional.
> 

Hi Mark,

Sure, will do.

>> +static int qcom_usb_vbus_enable(struct regulator_dev *rdev)
>> +{
> 
>> +static int qcom_usb_vbus_disable(struct regulator_dev *rdev)
>> +{
> 
>> +static int qcom_usb_vbus_is_enabled(struct regulator_dev *rdev)
>> +{
> 
> These operations can all be replaced by regulator_is_enabled_regmap()
> and friends.
> 

Got it.  This simplifies the driver a lot.  Thanks for the tip.

>> +init_data.constraints.valid_ops_mask |= REGULATOR_CHANGE_STATUS;
> 
> No, this is broken - regulators should not override the constraints the
> machine sets.
> 

Understood.  I decided to go with of_get_regulator_init_data() to
initialize the init_data parameter.  This should take care of the
constraint settings.


-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 4/6] regulator: Add support for QCOM PMIC VBUS booster

2020-06-15 Thread Wesley Cheng




On 6/12/2020 8:28 PM, Randy Dunlap wrote:
> On 6/12/20 4:19 PM, Wesley Cheng wrote:
>> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
>> index 074a2ef55943..f9165f9f9051 100644
>> --- a/drivers/regulator/Kconfig
>> +++ b/drivers/regulator/Kconfig
>> @@ -797,6 +797,16 @@ config REGULATOR_QCOM_SPMI
>>Qualcomm SPMI PMICs as a module. The module will be named
>>"qcom_spmi-regulator".
>>  
>> +config REGULATOR_QCOM_USB_VBUS
>> +tristate "Qualcomm USB Vbus regulator driver"
>> +depends on SPMI || COMPILE_TEST
>> +help
>> +  If you say yes to this option, support will be included for the
>> +  regulator used to enable the VBUS output.
>> +
>> +  Say M here if you want to include support for enabling the VBUS output
>> +  as a module. The module will be named "qcom_usb-regulator".
> 
> Hi,
> Shouldn't that module name match what is in the Makefile?
> 
> 

Thanks, Randy.  Missed this as I was going back and forth on the file
name.  Thanks for the catch.

>> +
>>  config REGULATOR_RC5T583
>>  tristate "RICOH RC5T583 Power regulators"
>>  depends on MFD_RC5T583
>> diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
>> index c0d6b96ebd78..cbab28aa7b56 100644
>> --- a/drivers/regulator/Makefile
>> +++ b/drivers/regulator/Makefile
>> @@ -89,6 +89,7 @@ obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
>>  obj-$(CONFIG_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o
>>  obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
>>  obj-$(CONFIG_REGULATOR_QCOM_SPMI) += qcom_spmi-regulator.o
>> +obj-$(CONFIG_REGULATOR_QCOM_USB_VBUS) += qcom_usb_vbus-regulator.o
>>  obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o
>>  obj-$(CONFIG_REGULATOR_PFUZE100) += pfuze100-regulator.o
>>  obj-$(CONFIG_REGULATOR_PV88060) += pv88060-regulator.o
> 
> 
> thanks.
> 

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[Mpi-forum] MPI Forum - June 2020 Exceptional Virtual Meeting Votes

2020-06-15 Thread Wesley Bland via mpi-forum

Hi all,

Vote and reading announcements for the upcoming June meeting are now closed. 
Since we have many more ballots than usual, I wanted to draw folks attention to 
the list of all of the ballots for this meeting so people can double-check my 
work. We currently have 29 ballots on the schedule (glad we’ll be voting online 
this time) with some of every type of ballot. Please go through the list and 
make sure that I’ve included any thing you might have announced or been 
involved in. If there’s any problems, contact me directly so we can get these 
fixed quickly.

I’m also including a link to the sample ballot so everyone can make sure it 
works for them. This form won’t actually work yet since it doesn’t include your 
name and org. That will get filled in when I send your special URL during 
voting time. In the meantime, you can make sure that the page loads properly 
for you and I’m not missing anything. As a reminder, make sure that only one 
person at your org submits the ballot to represent that org (otherwise I’ll 
just pick a random one that comes in when I’m tallying the votes). Go ahead and 
discuss that now with anyone else from your org that may have registered.

Meeting Registration List: 
https://www.mpi-forum.org/meetings/2020/06/attendance 
 
Ballot List: https://www.mpi-forum.org/meetings/2020/06/votes 
 
Sample Ballot: https://form.jotform.com/201614072992151 


Thanks,
Wes___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

[PATCH v2 1/6] usb: typec: Add QCOM PMIC typec detection driver

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 attains a handle to the VBUS output regulator, so it
can enable/disable the VBUS source when acting as a host/device.

Signed-off-by: Wesley Cheng 
---
 drivers/usb/typec/Kconfig   |  12 ++
 drivers/usb/typec/Makefile  |   1 +
 drivers/usb/typec/qcom-pmic-typec.c | 275 
 3 files changed, 288 insertions(+)
 create mode 100644 drivers/usb/typec/qcom-pmic-typec.c

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index b4f2aac7ae8a..595c14766e99 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -72,6 +72,18 @@ 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 Type-C driver"
+   depends on ARCH_QCOM
+   help
+ Driver for supporting role switch over the Qualcomm PMIC.  This will
+ handle the USB Type-C role and orientation detection reported by the
+ QCOM PMIC if the PMIC has the capability to handle USB 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 7753a5c3cd46..cceffd987643 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 ..5ae3af03c638
--- /dev/null
+++ b/drivers/usb/typec/qcom-pmic-typec.c
@@ -0,0 +1,275 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TYPEC_MISC_STATUS  0xb
+#define CC_ATTACHEDBIT(0)
+#define CC_ORIENTATION BIT(1)
+#define SNK_SRC_MODE   BIT(6)
+#define TYPEC_MODE_CFG 0x44
+#define TYPEC_DISABLE_CMD  BIT(0)
+#define EN_SNK_ONLYBIT(1)
+#define EN_SRC_ONLYBIT(2)
+#define TYPEC_VCONN_CONTROL0x46
+#define VCONN_EN_SRC   BIT(0)
+#define VCONN_EN_VAL   BIT(1)
+#define TYPEC_EXIT_STATE_CFG   0x50
+#define SEL_SRC_UPPER_REF  BIT(2)
+#define TYPEC_INTR_EN_CFG_10x5e
+#define TYPEC_INTR_EN_CFG_1_MASK   GENMASK(7, 0)
+
+struct qcom_pmic_typec {
+   struct device   *dev;
+   struct fwnode_handle*fwnode;
+   struct regmap   *regmap;
+   u32 base;
+
+   struct typec_capability *cap;
+   struct typec_port   *port;
+   struct usb_role_switch *role_sw;
+
+   struct regulator*vbus_reg;
+   boolvbus_enabled;
+};
+
+static void qcom_pmic_typec_enable_vbus_regulator(struct qcom_pmic_typec
+   *qcom_usb, bool enable)
+{
+   int ret = 0;
+
+   if (enable == qcom_usb->vbus_enabled)
+   return;
+
+   if (!qcom_usb->vbus_reg) {
+   qcom_usb->vbus_reg = devm_regulator_get(qcom_usb->dev,
+   "usb_vbus");
+   if (IS_ERR(qcom_usb->vbus_reg)) {
+   qcom_usb->vbus_reg = NULL;
+   return;
+   }
+   }
+
+   if (enable) {
+   ret = regulator_enable(qcom_usb->vbus_reg);
+   if (ret)
+   return;
+   } else {
+   ret = regulator_disable(qcom_usb->vbus_reg);
+   if (ret)
+   return;
+   }
+   qcom_usb->vbus_enabled = enable;
+}
+
+static void qcom_pmic_typec_check_connection(struct qcom_pmic_typec *qcom_usb)
+{
+   enum typec_orientation orientation;
+   enum usb_role role;
+   unsigned int stat;
+   bool enable_vbus;
+
+   regmap_read(qcom_usb->regmap, qcom_usb->base + TYPEC_MISC_STATUS,
+   &stat);
+
+   if (stat & CC_ATTACHED) {
+   orientation = ((stat &a

[PATCH v2 4/6] regulator: Add support for QCOM PMIC VBUS booster

Some Qualcomm PMICs have the capability to source the VBUS output to
connected peripherals.  This driver will register a regulator to the
regulator list to enable or disable this source by an external driver.

Signed-off-by: Wesley Cheng 
---
 drivers/regulator/Kconfig   |  10 ++
 drivers/regulator/Makefile  |   1 +
 drivers/regulator/qcom_usb_vbus-regulator.c | 147 
 3 files changed, 158 insertions(+)
 create mode 100644 drivers/regulator/qcom_usb_vbus-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 074a2ef55943..f9165f9f9051 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -797,6 +797,16 @@ config REGULATOR_QCOM_SPMI
  Qualcomm SPMI PMICs as a module. The module will be named
  "qcom_spmi-regulator".
 
+config REGULATOR_QCOM_USB_VBUS
+   tristate "Qualcomm USB Vbus regulator driver"
+   depends on SPMI || COMPILE_TEST
+   help
+ If you say yes to this option, support will be included for the
+ regulator used to enable the VBUS output.
+
+ Say M here if you want to include support for enabling the VBUS output
+ as a module. The module will be named "qcom_usb-regulator".
+
 config REGULATOR_RC5T583
tristate "RICOH RC5T583 Power regulators"
depends on MFD_RC5T583
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index c0d6b96ebd78..cbab28aa7b56 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -89,6 +89,7 @@ obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_SPMI) += qcom_spmi-regulator.o
+obj-$(CONFIG_REGULATOR_QCOM_USB_VBUS) += qcom_usb_vbus-regulator.o
 obj-$(CONFIG_REGULATOR_PALMAS) += palmas-regulator.o
 obj-$(CONFIG_REGULATOR_PFUZE100) += pfuze100-regulator.o
 obj-$(CONFIG_REGULATOR_PV88060) += pv88060-regulator.o
diff --git a/drivers/regulator/qcom_usb_vbus-regulator.c 
b/drivers/regulator/qcom_usb_vbus-regulator.c
new file mode 100644
index ..2b8129a04684
--- /dev/null
+++ b/drivers/regulator/qcom_usb_vbus-regulator.c
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CMD_OTG0x40
+#define OTG_EN BIT(0)
+#define OTG_CFG0x53
+#define OTG_EN_SRC_CFG BIT(1)
+
+struct qcom_vbus {
+   struct device   *dev;
+   u32 base;
+   struct regmap   *regmap;
+   struct regulator_dev *usb_vbus_reg;
+};
+
+static int qcom_usb_vbus_enable(struct regulator_dev *rdev)
+{
+   struct qcom_vbus *vbus_out = rdev_get_drvdata(rdev);
+   int rc;
+
+   rc = regmap_update_bits(vbus_out->regmap, vbus_out->base + CMD_OTG,
+   OTG_EN, OTG_EN);
+   if (rc)
+   dev_err(vbus_out->dev, "failed to enable usb_vbus\n");
+
+   return rc;
+}
+
+static int qcom_usb_vbus_disable(struct regulator_dev *rdev)
+{
+   struct qcom_vbus *vbus_out = rdev_get_drvdata(rdev);
+   int rc;
+
+   rc = regmap_update_bits(vbus_out->regmap, vbus_out->base + CMD_OTG,
+   OTG_EN, 0);
+   if (rc)
+   dev_err(vbus_out->dev, "failed to disable usb_vbus\n");
+
+   return rc;
+}
+
+static int qcom_usb_vbus_is_enabled(struct regulator_dev *rdev)
+{
+   struct qcom_vbus *vbus_out = rdev_get_drvdata(rdev);
+   unsigned int value = 0;
+   int rc;
+
+   rc = regmap_read(vbus_out->regmap, vbus_out->base + CMD_OTG, &value);
+   if (rc)
+   dev_err(vbus_out->dev, "failed to read OTG_CTL\n");
+
+   return !!(value & OTG_EN);
+}
+
+static const struct regulator_ops qcom_usb_vbus_reg_ops = {
+   .enable = qcom_usb_vbus_enable,
+   .disable = qcom_usb_vbus_disable,
+   .is_enabled = qcom_usb_vbus_is_enabled,
+};
+
+static const struct regulator_desc qcom_usb_vbus_rdesc = {
+   .name = "usb_vbus",
+   .ops = &qcom_usb_vbus_reg_ops,
+   .owner = THIS_MODULE,
+   .type = REGULATOR_VOLTAGE,
+};
+
+static const struct of_device_id qcom_usb_vbus_regulator_match[] = {
+   { .compatible = "qcom,pm8150b-vbus-reg" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, qcom_usb_vbus_regulator_match);
+
+static int qcom_usb_vbus_regulator_probe(struct platform_device *pdev)
+{
+   struct qcom_vbus *vbus_out;
+   struct device *dev = &pdev->dev;
+   struct regulator_config config = { };
+   struct regulator_init_d

[PATCH v2 6/6] arm64: boot: dts: qcom: pm8150b: Add DTS node for PMIC VBUS booster

Add the required DTS node for the USB VBUS output regulator, which is
available on PM8150B.  This will provide the VBUS source to connected
peripherals.

Signed-off-by: Wesley Cheng 
---
 arch/arm64/boot/dts/qcom/pm8150b.dtsi   | 6 ++
 arch/arm64/boot/dts/qcom/sm8150-mtp.dts | 7 +++
 2 files changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi 
b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
index ec44a8bc2f84..b7274d9d7341 100644
--- a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
@@ -22,6 +22,12 @@ power-on@800 {
status = "disabled";
};
 
+   qcom,dcdc@1100 {
+   compatible = "qcom,pm8150b-vbus-reg";
+   status = "disabled";
+   reg = <0x1100>;
+   };
+
qcom,typec@1500 {
compatible = "qcom,pm8150b-usb-typec";
status = "disabled";
diff --git a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts 
b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
index 6c6325c3af59..3845d19893eb 100644
--- a/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sm8150-mtp.dts
@@ -426,6 +426,13 @@ &usb_1 {
status = "okay";
 };
 
+&spmi_bus {
+   pmic@2 {
+   qcom,dcdc@1100 {
+   status = "okay";
+   };
+};
+
 &usb_1_dwc3 {
dr_mode = "peripheral";
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 2/6] dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding

Introduce the dt-binding for enabling USB type C orientation and role
detection using the PM8150B.  The driver will be responsible for receiving
the interrupt at a state change on the CC lines, reading the orientation/role,
and communicating this information to the remote clients, which can include
a role switch node and a type C switch.

Signed-off-by: Wesley Cheng 
---
 .../bindings/usb/qcom,pmic-typec.yaml | 117 ++
 1 file changed, 117 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml

diff --git a/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml 
b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
new file mode 100644
index ..085b4547d75a
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
@@ -0,0 +1,117 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/usb/qcom,pmic-typec.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Qualcomm PMIC based USB type C Detection Driver
+
+maintainers:
+  - Wesley Cheng 
+
+description: |
+  Qualcomm PMIC Type C Detect
+
+properties:
+  compatible:
+enum:
+  - qcom,pm8150b-usb-typec
+
+  reg:
+maxItems: 1
+description: Type C base address
+
+  interrupts:
+maxItems: 1
+description: CC change interrupt from PMIC
+
+  connector:
+description: Connector type for remote endpoints
+type: object
+
+properties:
+  compatible:
+enum:
+  - usb-c-connector
+
+  power-role:
+   enum:
+ - dual
+ - source
+ - sink
+
+  data-role:
+enum:
+  - dual
+  - host
+  - device
+
+  port:
+description: Remote endpoint connections
+type: object
+
+properties:
+  endpoint@0:
+description: Connection to USB type C mux node
+type: object
+
+properties:
+  remote-endpoint:
+maxItems: 1
+description: Node reference to the type C mux
+
+  endpoint@1:
+description: Connection to role switch node
+type: object
+
+properties:
+  remote-endpoint:
+maxItems: 1
+description: Node reference to the role switch node
+
+required:
+  - compatible
+
+required:
+  - compatible
+  - interrupts
+  - connector
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+pm8150b {
+#address-cells = <1>;
+#size-cells = <0>;
+qcom,typec@1500 {
+compatible = "qcom,pm8150b-usb-typec";
+reg = <0x1500>;
+interrupts =
+<0x2 0x15 0x5 IRQ_TYPE_EDGE_RISING>;
+
+connector {
+compatible = "usb-c-connector";
+power-role = "dual";
+data-role = "dual";
+port {
+#address-cells = <1>;
+#size-cells = <0>;
+usb3_data_ss: endpoint@0 {
+reg = <0>;
+remote-endpoint =
+<&qmp_ss_mux>;
+};
+
+usb3_role: endpoint@1 {
+
+reg = <1>;
+remote-endpoint =
+<&dwc3_drd_switch>;
+};
+};
+};
+};
+};
+...
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 5/6] dt-bindings: regulator: Add dt-binding for QCOM PMIC VBUS output regulator

This describes how to enable the Qualcomm PMIC VBUS booster used for
providing power to connected USB peripherals when the USB role is host
mode.  The driver itself will register the vbus_usb regulator, so that
external drivers can utilize the enable/disable regulator APIs.

Signed-off-by: Wesley Cheng 
---
 .../regulator/qcom,usb-vbus-regulator.yaml| 41 +++
 1 file changed, 41 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml

diff --git 
a/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml 
b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
new file mode 100644
index ..2fa76111cfb9
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
@@ -0,0 +1,41 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/qcom,usb-vbus-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: The Qualcomm PMIC VBUS output regulator driver
+
+maintainers:
+  - Wesley Cheng 
+
+description: |
+  This regulator driver controls the VBUS output by the Qualcomm PMIC.  This
+  regulator will be enabled in situations where the device is required to
+  provide power to the connected peripheral.
+
+properties:
+  compatible:
+enum:
+  - qcom,pm8150b-vbus-reg
+
+  reg:
+maxItems: 1
+description: VBUS output base address
+
+required:
+  - compatible
+
+additionalProperties: false
+
+examples:
+  - |
+ pm8150b {
+#address-cells = <1>;
+#size-cells = <0>;
+qcom,dcdc@1100 {
+compatible = "qcom,pm8150b-vbus-reg";
+reg = <0x1100>;
+};
+ };
+...
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 0/6] Introduce PMIC based USB type C detection

Changes in v2:
 - Use devm_kzalloc() in qcom_pmic_typec_probe()
 - Add checks to make sure return value of typec_find_port_power_role() is
   valid
 - Added a VBUS output regulator driver, which will be used by the PMIC USB
   type c driver to enable/disable the source
 - Added logic to control vbus source from the PMIC type c driver when
   UFP/DFP is detected
 - Added dt-binding for this new regulator driver
 - Fixed Kconfig typec notation to match others
 - Leave type C block disabled until enabled by a platform DTS

Add the required drivers for implementing type C orientation and role
detection using the Qualcomm PMIC.  Currently, PMICs such as the PM8150B
have an integrated type C block, which can be utilized for this.  This
series adds the dt-binding, PMIC type C driver, and DTS nodes.

The PMIC type C driver will register itself as a type C port w/ a
registered type C switch for orientation, and will fetch a USB role switch
handle for the role notifications.  It will also have the ability to enable
the VBUS output to any connected devices based on if the device is behaving
as a UFP or DFP.

Wesley Cheng (6):
  usb: typec: Add QCOM PMIC typec detection driver
  dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding
  arm64: boot: dts: qcom: pm8150b: Add node for USB type C block
  regulator: Add support for QCOM PMIC VBUS booster
  dt-bindings: regulator: Add dt-binding for QCOM PMIC VBUS output
regulator
  arm64: boot: dts: qcom: pm8150b: Add DTS node for PMIC VBUS booster

 .../regulator/qcom,usb-vbus-regulator.yaml|  41 +++
 .../bindings/usb/qcom,pmic-typec.yaml | 117 
 arch/arm64/boot/dts/qcom/pm8150b.dtsi |  13 +
 arch/arm64/boot/dts/qcom/sm8150-mtp.dts   |   7 +
 drivers/regulator/Kconfig |  10 +
 drivers/regulator/Makefile|   1 +
 drivers/regulator/qcom_usb_vbus-regulator.c   | 147 ++
 drivers/usb/typec/Kconfig |  12 +
 drivers/usb/typec/Makefile|   1 +
 drivers/usb/typec/qcom-pmic-typec.c   | 275 ++
 10 files changed, 624 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/qcom,usb-vbus-regulator.yaml
 create mode 100644 Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
 create mode 100644 drivers/regulator/qcom_usb_vbus-regulator.c
 create mode 100644 drivers/usb/typec/qcom-pmic-typec.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 3/6] arm64: boot: dts: qcom: pm8150b: Add node for USB type C block

The PM8150B has a dedicated USB type C block, which can be used for type C
orientation and role detection.  Create the reference node to this type C
block for further use.

Signed-off-by: Wesley Cheng 
---
 arch/arm64/boot/dts/qcom/pm8150b.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi 
b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
index 322379d5c31f..ec44a8bc2f84 100644
--- a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
@@ -22,6 +22,14 @@ power-on@800 {
status = "disabled";
};
 
+   qcom,typec@1500 {
+   compatible = "qcom,pm8150b-usb-typec";
+   status = "disabled";
+   reg = <0x1500>;
+   interrupts =
+   <0x2 0x15 0x5 IRQ_TYPE_EDGE_RISING>;
+   };
+
adc@3100 {
compatible = "qcom,spmi-adc5";
reg = <0x3100>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

2020-06-11 Thread Wesley Cheng

On 6/10/2020 12:37 PM, Bjorn Andersson wrote:
>> 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
> 

Hi Bjorn/Jack,

I have removed the need for referencing other base addresses other than
the type C block within the  driver, and have moved the DCDC set to be
handled by another regulator driver, which solely controls the vbus
output.  The type C driver will control the vbus output using the
regulator APIs.  Thanks for the input.

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

2020-06-11 Thread Wesley Cheng




On 6/9/2020 7:27 PM, Jun Li wrote:
>> +static int qcom_pmic_typec_probe(struct platform_device *pdev)
>> +{
>> +   struct device *dev = &pdev->dev;
>> +   struct qcom_pmic_typec *qcom_usb;
>> +   struct typec_capability *cap;
>> +   const char *buf;
>> +   int ret, irq, role;
>> +
>> +   qcom_usb = kzalloc(sizeof(*qcom_usb), GFP_KERNEL);
> 
> devm_kzalloc().
> 

Hi Jun,

Thanks for the input.  I have replaced with devm_kzalloc() as you
recommended.

>> +   if (!qcom_usb)
>> +   return -ENOMEM;
>> +
>> +   qcom_usb->dev = dev;
>> +
>> +   qcom_usb->regmap = dev_get_regmap(dev->parent, NULL);
>> +   if (!qcom_usb->regmap) {
>> +   dev_err(dev, "Failed to get regmap\n");
>> +   return -EINVAL;
>> +   }
>> +
>> +   irq = platform_get_irq(pdev, 0);
>> +   if (irq < 0) {
>> +   dev_err(dev, "Failed to get CC irq\n");
>> +   return -EINVAL;
>> +   }
>> +
>> +   ret = devm_request_irq(qcom_usb->dev, irq, qcom_pmic_typec_interrupt,
>> +  IRQF_SHARED, "qcom-pmic-typec", qcom_usb);
>> +   if (ret) {
>> +   dev_err(&pdev->dev, "Could not request IRQ\n");
>> +   return ret;
>> +   }
>> +
>> +   qcom_usb->fwnode = device_get_named_child_node(dev, "connector");
>> +   if (!qcom_usb->fwnode)
>> +   return -EINVAL;
>> +
>> +   cap = kzalloc(sizeof(*cap), GFP_KERNEL);
> 
> devm_kzalloc().
> 
>> +   if (!cap) {
>> +   ret = -ENOMEM;
>> +   goto err_put_node;
>> +   }
>> +
>> +   ret = fwnode_property_read_string(qcom_usb->fwnode, "power-role", 
>> &buf);
>> +   if (!ret)
>> +   role = typec_find_port_power_role(buf);
> 
> if (role < 0)
> 


Added a check for role <0, if so, set to SNK as well
>> +   else
>> +   role = TYPEC_PORT_SNK;
>> +   cap->type = role;
>> +
>> +   ret = fwnode_property_read_string(qcom_usb->fwnode, "data-role", 
>> &buf);
>> +   if (!ret)
>> +   role = typec_find_port_data_role(buf);
> 
> if (role < 0)
> 

Added a check for role <0, if so, set to UFP as well
>> +   else
>> +   role = TYPEC_PORT_UFP;
>> +   cap->data = role;
>> +
>> +   cap->prefer_role = -1;
> 
> TYPEC_NO_PREFERRED_ROLE
> 

Done.
>> +   cap->fwnode = qcom_usb->fwnode;
>> +   qcom_usb->port = typec_register_port(dev, cap);
>> +   if (IS_ERR(qcom_usb->port)) {
>> +   dev_err(dev, "Failed to register type c port %d\n",
>> +   IS_ERR(qcom_usb->port));
>> +   ret = PTR_ERR(qcom_usb->port);
> 
> dev_err(dev, , ret)?
> 
> Li Jun

Agreed.  Thanks!

>> +   goto err_put_node;
>> +   }
>> +
>> +   qcom_usb->cap = cap;
>> +
>> +   qcom_usb->role_sw = fwnode_usb_role_switch_get(qcom_usb->fwnode);
>> +   if (IS_ERR(qcom_usb->role_sw)) {
>> +   if (PTR_ERR(qcom_usb->role_sw) != -EPROBE_DEFER)
>> +   dev_err(dev, "failed to get role switch\n");
>> +   ret = PTR_ERR(qcom_usb->role_sw);
>> +   goto err_typec_port;
>> +   }
>> +
>> +   INIT_WORK(&qcom_usb->bh_work, qcom_pmic_typec_bh_work);
>> +   platform_set_drvdata(pdev, qcom_usb);
>> +   qcom_pmic_typec_typec_hw_init(qcom_usb);
>> +
>> +   queue_work(system_power_efficient_wq, &qcom_usb->bh_work);
>> +
>> +   return 0;
>> +
>> +err_typec_port:
>> +   typec_unregister_port(qcom_usb->port);
>> +err_put_node:
>> +   fwnode_handle_put(qcom_usb->fwnode);
>> +
>> +   return ret;
>> +}
>> +
>> +static int qcom_pmic_typec_remove(struct platform_device *pdev)
>> +{
>> +   struct qcom_pmic_typec *qcom_usb = platform_get_drvdata(pdev);
>> +
>> +   cancel_work_sync(&qcom_usb->bh_work);
>> +   usb_role_switch_set_role(qcom_usb->role_sw, USB_ROLE_NONE);
>> +   qcom_pmic_typec_vbus_disable(qcom_usb);
>> +
>> +   typec_unregister_port(qcom_usb->port);
>> +   usb_role_switch_put(qcom_usb->role_sw);
>> +   fwnode_handle_put(qcom_usb->fwnode);
>> +
>> +   return 0;
>> +}
>> +
>> +static const struct of_device_id qcom_pmic_typec_table[] = {
>> +   { .compatible = "qcom,pm8150b-usb-typec" },
>> +   { },
>> +};
>> +MODULE_DEVICE_TABLE(of, qcom_pmic_typec_table);
>> +
>> +static struct platform_driver qcom_pmic_typec = {
>> +   .driver = {
>> +   .name = "qcom,pmic-typec",
>> +   .of_match_table = qcom_pmic_typec_table,
>> +   },
>> +   .probe = qcom_pmic_typec_probe,
>> +   .remove = qcom_pmic_typec_remove,
>> +};
>> +
>> +module_platform_driver(qcom_pmic_typec);
>> +
>> +MODULE_DESCRIPTION("QCOM PMIC USB type C driver");
>> +MODULE_LICENSE("GPL v2");
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>>

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Fo

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

2020-06-11 Thread Wesley Cheng




On 6/9/2020 2:20 PM, Randy Dunlap wrote:
> On 6/9/20 1:58 PM, Wesley Cheng wrote:
>> 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.
>>
> 
> Hi,
> Please spell "Type-C" like all of the other drivers do.
> 
>> +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"

Hi Randy,

Will do.

Thanks
> 
> 

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[cobirds] Unfortunate birding at Bud Mielke Reservoir. Loveland, larimer county

2020-06-11 Thread Jace Wesley Brasher

The farmers are mowing the fields north and south of  Bud Mielke Reservoir in
loveland( location of eastern meadowlark, Dickcissel, and bobolink nests).
Unfortunately this means any possible nests are being destroyed.

Jace brasher
Loveland
Larimer county

-- 
You received this message because you are subscribed to the Google Groups 
"Colorado Birds" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to cobirds+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/cobirds/CAP7yTyiMnO7wL9S8CPN2ama8fPGc0ejzchrQUA1uhN3VcYYa2A%40mail.gmail.com.

[Mpi-forum] Procedures Reading and Vote Announcements for June 2020 Meeting

2020-06-10 Thread Wesley Bland via mpi-forum

Hi all,

I’d like to announce formal readings and votes for the procedures changes that 
I read earlier today. For both of these proposals, I’ve made changes based on 
the feedback from the group so they are hopefully both acceptable to everyone. 
Please have a look and make any comments on the PR before Monday if there’s 
anything that’s still unclear.

Proceedings PR #6  - Update to 
RCM/FRM rules for GitHub
Proceedings PR #7  - Add 
procedures for officer elections

Thanks,
Wes___
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

[PATCH 1/3] usb: typec: Add QCOM PMIC typec detection driver

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
drivers can enable the VBUS source when acting as a source/host.

Signed-off-by: Wesley Cheng 
---
 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 000..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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DCDC_BASE  0x1100
+#define CMD_OTG(DCDC_BASE + 0x40)
+#define OTG_EN BIT(0)
+#define OTG_CFG(DCDC_BASE + 0x53)
+#define OTG_EN_SRC_CFG BIT(1)
+
+#define USB_BASE   0x1300
+#define TYPE_C_CFG_REG (USB_BASE + 0x58)
+#define BC12_START_ON_CC   BIT(7)
+
+#define TYPEC_BASE 0x1500
+#define TYPEC_MISC_STATUS  (TYPEC_BASE + 0xb)
+#define CC_ATTACHEDBIT(0)
+#define CC_ORIENTATION BIT(1)
+#define SNK_SRC_MODE   BIT(6)
+#define TYPEC_MODE_CFG (TYPEC_BASE + 0x44)
+#define TYPEC_DISABLE_CMD  BIT(0)
+#define EN_SNK_ONLYBIT(1)
+#define EN_SRC_ONLYBIT(2)
+#define EN_TRY_SNK BIT(4)
+#define TYPEC_VCONN_CONTROL(TYPEC_BASE + 0x46)
+#define VCONN_EN_SRC   BIT(0)
+#define VCONN_EN_VAL   BIT(1)
+#define TYPEC_EXIT_STATE_CFG   (TYPEC_BASE + 0x50)
+#define SEL_SRC_UPPER_REF  BIT(2)
+#define TYPEC_INTR_EN_CFG_1(TYPEC_BASE + 0x5e)
+#define TYPEC_INTR_EN_CFG_1_MASK   GENMASK(0, 7)
+
+struct qcom_pmic_typec {
+   struct device   *dev;
+   struct fwnode_handle*fwnode;
+   struct regmap   *regmap;
+   struct work_struct  bh_work;
+
+   struct typec_capability *cap;
+   struct typec_port   *port;
+   struct usb_role_switch *role_sw;
+
+   struct regulator_desc usb_vbus_rdesc;
+   struct regulator_dev *usb_vbus_reg;
+};
+
+static int qcom_pmic_typec_vbus_enable(struct qcom_pmic_typec *qcom_usb)
+{
+   int rc;
+
+   rc = regmap_update_bits(qcom_usb->regmap, CMD_OTG, OTG_EN, OTG_EN);
+   if (rc)
+   dev_err(qcom_usb->dev, "failed to update OTG_CTL\n");
+
+   return rc;
+}
+
+static int qcom_pmic_typec_vbus_disable(struct qcom_pmic_typec *qcom_usb)
+{
+   int rc;
+
+   rc = regmap_update_bits(qcom_usb->regmap, CMD_OTG, OTG_EN, 0);
+   if (rc)
+   dev_err(qcom_usb->dev, "failed to update OTG_CTL\n");
+
+   return rc;
+}
+
+void qcom_pmic_typec_bh_work(struct work_struct *w)
+{
+   struct qcom_pmic_typec *qcom_usb = container_of(w,
+

[PATCH 3/3] arm64: boot: dts: qcom: pm8150b: Add node for USB type C block

The PM8150B has a dedicated USB type C block, which can be used for type C
orientation and role detection.  Create the reference node to this type C
block for further use.

Signed-off-by: Wesley Cheng 
---
 arch/arm64/boot/dts/qcom/pm8150b.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/pm8150b.dtsi 
b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
index 40b5d75..7364d6b 100644
--- a/arch/arm64/boot/dts/qcom/pm8150b.dtsi
+++ b/arch/arm64/boot/dts/qcom/pm8150b.dtsi
@@ -22,6 +22,13 @@
status = "disabled";
};
 
+   qcom,typec@1500 {
+   compatible = "qcom,pm8150b-usb-typec";
+   reg = <0x1500>;
+   interrupts =
+   <0x2 0x15 0x5 IRQ_TYPE_EDGE_RISING>;
+   };
+
adc@3100 {
compatible = "qcom,spmi-adc5";
reg = <0x3100>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 0/3] Introduce PMIC based USB type C detection

Add the required drivers for implementing type C orientation and role
detection using the Qualcomm PMIC.  Currently, PMICs such as the PM8150B
have an integrated type C block, which can be utilized for this.  This
series adds the dt-binding, PMIC type C driver, and DTS nodes.

The PMIC type C driver will register itself as a type C port w/ a
registered type C switch for orientation, and will fetch a USB role switch
handle for the role notifications.  It will also have the ability to enable
the VBUS output to any connected devices based on if the device is behaving
as a UFP or DFP.

Wesley Cheng (3):
  usb: typec: Add QCOM PMIC typec detection driver
  dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding
  arm64: boot: dts: qcom: pm8150b: Add node for USB type C block

 .../devicetree/bindings/usb/qcom,pmic-typec.yaml   | 118 +
 arch/arm64/boot/dts/qcom/pm8150b.dtsi  |   7 +
 drivers/usb/typec/Kconfig  |  11 +
 drivers/usb/typec/Makefile |   1 +
 drivers/usb/typec/qcom-pmic-typec.c| 278 +
 5 files changed, 415 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
 create mode 100644 drivers/usb/typec/qcom-pmic-typec.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 2/3] dt-bindings: usb: Add Qualcomm PMIC type C controller dt-binding