Hi,
Changes since v1:
1. Mutex unlock fix in patch 8/13.
Best regards,
Krzysztof
Convert the ptn-5150 extcon driver bindings to DT schema format using
json-schema. The differences with original bindings document:
- Use "gpios" suffix for the "int" and "vbus" gpio,
- Skip generic "pinctrl" property as it is not really required.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
.../bindings/extcon/extcon-ptn5150.txt | 27 ----------
.../bindings/extcon/extcon-ptn5150.yaml | 53 +++++++++++++++++++
2 files changed, 53 insertions(+), 27 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml
diff --git a/Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt
deleted file mode 100644
index 936fbdf12815..000000000000
--- a/Documentation/devicetree/bindings/extcon/extcon-ptn5150.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-* PTN5150 CC (Configuration Channel) Logic device
-
-PTN5150 is a small thin low power CC logic chip supporting the USB Type-C
-connector application with CC control logic detection and indication functions.
-It is interfaced to the host controller using an I2C interface.
-
-Required properties:
-- compatible: should be "nxp,ptn5150"
-- reg: specifies the I2C slave address of the device
-- int-gpio: should contain a phandle and GPIO specifier for the GPIO pin
- connected to the PTN5150's INTB pin.
-- vbus-gpio: should contain a phandle and GPIO specifier for the GPIO pin which
- is used to control VBUS.
-- pinctrl-names : a pinctrl state named "default" must be defined.
-- pinctrl-0 : phandle referencing pin configuration of interrupt and vbus
- control.
-
-Example:
- ptn5150@1d {
- compatible = "nxp,ptn5150";
- reg = <0x1d>;
- int-gpio = <&msmgpio 78 GPIO_ACTIVE_HIGH>;
- vbus-gpio = <&msmgpio 148 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&ptn5150_default>;
- status = "okay";
- };
diff --git a/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml
new file mode 100644
index 000000000000..f6316f12028b
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/extcon/extcon-ptn5150.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PTN5150 CC (Configuration Channel) Logic device
+
+maintainers:
+ - Krzysztof Kozlowski <[email protected]>
+
+description: |
+ PTN5150 is a small thin low power CC logic chip supporting the USB Type-C
+ connector application with CC control logic detection and indication
+ functions. It is interfaced to the host controller using an I2C interface.
+
+properties:
+ compatible:
+ const: nxp,ptn5150
+
+ int-gpios:
+ description:
+ GPIO pin (input) connected to the PTN5150's INTB pin.
+
+ reg:
+ maxItems: 1
+
+ vbus-gpios:
+ description:
+ GPIO pin (output) used to control VBUS.
+
+required:
+ - compatible
+ - int-gpios
+ - reg
+ - vbus-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ptn5150@1d {
+ compatible = "nxp,ptn5150";
+ reg = <0x1d>;
+ int-gpios = <&msmgpio 78 GPIO_ACTIVE_HIGH>;
+ vbus-gpios = <&msmgpio 148 GPIO_ACTIVE_HIGH>;
+ };
+ };
--
2.17.1
Interrupts do not have to be always GPIO based so instead of expecting
"int-gpios" property and converting the GPIO to an interrupt, just
accept any interrupt via generic "interrupts" property.
Mark the old "int-gpios" as deprecated.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
.../devicetree/bindings/extcon/extcon-ptn5150.yaml | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml
index f6316f12028b..1ddc97db3e61 100644
--- a/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml
+++ b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml
@@ -19,8 +19,13 @@ properties:
const: nxp,ptn5150
int-gpios:
+ deprecated: true
description:
GPIO pin (input) connected to the PTN5150's INTB pin.
+ Use "interrupts" instead.
+
+ interrupts:
+ maxItems: 1
reg:
maxItems: 1
@@ -31,7 +36,7 @@ properties:
required:
- compatible
- - int-gpios
+ - interrupts
- reg
- vbus-gpios
@@ -40,6 +45,7 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
@@ -47,7 +53,8 @@ examples:
ptn5150@1d {
compatible = "nxp,ptn5150";
reg = <0x1d>;
- int-gpios = <&msmgpio 78 GPIO_ACTIVE_HIGH>;
+ interrupt-parent = <&msmgpio>;
+ interrupts = <78 IRQ_TYPE_LEVEL_HIGH>;
vbus-gpios = <&msmgpio 148 GPIO_ACTIVE_HIGH>;
};
};
--
2.17.1
The ptn5150 driver always prints device type on probe but as raw hex,
without any translation to meaningful description. This is useful only
for board bring up time so lower the verbosity to debug.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
drivers/extcon/extcon-ptn5150.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
index 3b99ad41b06e..a57fef384a29 100644
--- a/drivers/extcon/extcon-ptn5150.c
+++ b/drivers/extcon/extcon-ptn5150.c
@@ -199,8 +199,8 @@ static int ptn5150_init_dev_type(struct ptn5150_info *info)
version_id = ((reg_data & PTN5150_REG_DEVICE_ID_VERSION_MASK) >>
PTN5150_REG_DEVICE_ID_VERSION_SHIFT);
- dev_info(info->dev, "Device type: version: 0x%x, vendor: 0x%x\n",
- version_id, vendor_id);
+ dev_dbg(info->dev, "Device type: version: 0x%x, vendor: 0x%x\n",
+ version_id, vendor_id);
/* Clear any existing interrupts */
ret = regmap_read(info->regmap, PTN5150_REG_INT_STATUS, ®_data);
--
2.17.1
Add Krzysztof Kozlowski as maintainer of NXP PTN5150A CC/extcon driver
to provide review, feedback and testing.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index f2eb17cd3953..48cb5162a94a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12431,6 +12431,13 @@ F: drivers/iio/gyro/fxas21002c_core.c
F: drivers/iio/gyro/fxas21002c_i2c.c
F: drivers/iio/gyro/fxas21002c_spi.c
+NXP PTN5150A CC LOGIC AND EXTCON DRIVER
+M: Krzysztof Kozlowski <[email protected]>
+L: [email protected]
+S: Maintained
+F: Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml
+F: drivers/extcon/extcon-ptn5150.c
+
NXP SGTL5000 DRIVER
M: Fabio Estevam <[email protected]>
L: [email protected] (moderated for non-subscribers)
--
2.17.1
The 'struct i2c_device_id' argument of probe function is not used, so
convert the driver to simpler 'probe_new' interface.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
drivers/extcon/extcon-ptn5150.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
index 690d878c65f1..8ba706fad887 100644
--- a/drivers/extcon/extcon-ptn5150.c
+++ b/drivers/extcon/extcon-ptn5150.c
@@ -218,8 +218,7 @@ static int ptn5150_init_dev_type(struct ptn5150_info *info)
return 0;
}
-static int ptn5150_i2c_probe(struct i2c_client *i2c,
- const struct i2c_device_id *id)
+static int ptn5150_i2c_probe(struct i2c_client *i2c)
{
struct device *dev = &i2c->dev;
struct device_node *np = i2c->dev.of_node;
@@ -334,7 +333,7 @@ static struct i2c_driver ptn5150_i2c_driver = {
.name = "ptn5150",
.of_match_table = ptn5150_dt_match,
},
- .probe = ptn5150_i2c_probe,
+ .probe_new = ptn5150_i2c_probe,
.id_table = ptn5150_i2c_id,
};
module_i2c_driver(ptn5150_i2c_driver);
--
2.17.1
Use module_i2c_driver() to simplify driver init boilerplate.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
drivers/extcon/extcon-ptn5150.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
index c8611ff90990..690d878c65f1 100644
--- a/drivers/extcon/extcon-ptn5150.c
+++ b/drivers/extcon/extcon-ptn5150.c
@@ -337,12 +337,7 @@ static struct i2c_driver ptn5150_i2c_driver = {
.probe = ptn5150_i2c_probe,
.id_table = ptn5150_i2c_id,
};
-
-static int __init ptn5150_i2c_init(void)
-{
- return i2c_add_driver(&ptn5150_i2c_driver);
-}
-subsys_initcall(ptn5150_i2c_init);
+module_i2c_driver(ptn5150_i2c_driver);
MODULE_DESCRIPTION("NXP PTN5150 CC logic Extcon driver");
MODULE_AUTHOR("Vijai Kumar K <[email protected]>");
--
2.17.1
There is no point to print deferred probe (and its failures to get
resources) as an error. In case of multiple probe tries this would
pollute the dmesg.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
drivers/extcon/extcon-ptn5150.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
index 008e664d8d56..c8611ff90990 100644
--- a/drivers/extcon/extcon-ptn5150.c
+++ b/drivers/extcon/extcon-ptn5150.c
@@ -243,7 +243,7 @@ static int ptn5150_i2c_probe(struct i2c_client *i2c,
dev_info(dev, "No VBUS GPIO, ignoring VBUS control\n");
info->vbus_gpiod = NULL;
} else {
- dev_err(dev, "failed to get VBUS GPIO\n");
+ dev_err_probe(dev, ret, "failed to get VBUS GPIO\n");
return ret;
}
}
@@ -255,8 +255,8 @@ static int ptn5150_i2c_probe(struct i2c_client *i2c,
info->regmap = devm_regmap_init_i2c(i2c, &ptn5150_regmap_config);
if (IS_ERR(info->regmap)) {
ret = PTR_ERR(info->regmap);
- dev_err(info->dev, "failed to allocate register map: %d\n",
- ret);
+ dev_err_probe(info->dev, ret, "failed to allocate register map: %d\n",
+ ret);
return ret;
}
@@ -265,8 +265,9 @@ static int ptn5150_i2c_probe(struct i2c_client *i2c,
} else {
info->int_gpiod = devm_gpiod_get(&i2c->dev, "int", GPIOD_IN);
if (IS_ERR(info->int_gpiod)) {
- dev_err(dev, "failed to get INT GPIO\n");
- return PTR_ERR(info->int_gpiod);
+ ret = PTR_ERR(info->int_gpiod);
+ dev_err_probe(dev, ret, "failed to get INT GPIO\n");
+ return ret;
}
info->irq = gpiod_to_irq(info->int_gpiod);
--
2.17.1
Interrupts do not have to be always GPIO based so instead of expecting
"int-gpios" property and converting the GPIO to an interrupt, just
accept any interrupt via generic "interrupts" property.
Keep support for old "int-gpios" for backward compatibility.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
drivers/extcon/extcon-ptn5150.c | 33 ++++++++++++++++++---------------
1 file changed, 18 insertions(+), 15 deletions(-)
diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
index 5f5252752644..12e52ddbd77e 100644
--- a/drivers/extcon/extcon-ptn5150.c
+++ b/drivers/extcon/extcon-ptn5150.c
@@ -239,11 +239,6 @@ static int ptn5150_i2c_probe(struct i2c_client *i2c,
info->dev = &i2c->dev;
info->i2c = i2c;
- info->int_gpiod = devm_gpiod_get(&i2c->dev, "int", GPIOD_IN);
- if (IS_ERR(info->int_gpiod)) {
- dev_err(dev, "failed to get INT GPIO\n");
- return PTR_ERR(info->int_gpiod);
- }
info->vbus_gpiod = devm_gpiod_get(&i2c->dev, "vbus", GPIOD_IN);
if (IS_ERR(info->vbus_gpiod)) {
dev_err(dev, "failed to get VBUS GPIO\n");
@@ -267,22 +262,30 @@ static int ptn5150_i2c_probe(struct i2c_client *i2c,
return ret;
}
- if (info->int_gpiod) {
+ if (i2c->irq > 0) {
+ info->irq = i2c->irq;
+ } else {
+ info->int_gpiod = devm_gpiod_get(&i2c->dev, "int", GPIOD_IN);
+ if (IS_ERR(info->int_gpiod)) {
+ dev_err(dev, "failed to get INT GPIO\n");
+ return PTR_ERR(info->int_gpiod);
+ }
+
info->irq = gpiod_to_irq(info->int_gpiod);
if (info->irq < 0) {
dev_err(dev, "failed to get INTB IRQ\n");
return info->irq;
}
+ }
- ret = devm_request_threaded_irq(dev, info->irq, NULL,
- ptn5150_irq_handler,
- IRQF_TRIGGER_FALLING |
- IRQF_ONESHOT,
- i2c->name, info);
- if (ret < 0) {
- dev_err(dev, "failed to request handler for INTB IRQ\n");
- return ret;
- }
+ ret = devm_request_threaded_irq(dev, info->irq, NULL,
+ ptn5150_irq_handler,
+ IRQF_TRIGGER_FALLING |
+ IRQF_ONESHOT,
+ i2c->name, info);
+ if (ret < 0) {
+ dev_err(dev, "failed to request handler for INTB IRQ\n");
+ return ret;
}
/* Allocate extcon device */
--
2.17.1
Instead of obtaining GPIO as input and configuring it right after to
output-low, just use proper GPIOD_OUT_LOW flag. Code is smaller and
simpler.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
drivers/extcon/extcon-ptn5150.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
index 12e52ddbd77e..3b99ad41b06e 100644
--- a/drivers/extcon/extcon-ptn5150.c
+++ b/drivers/extcon/extcon-ptn5150.c
@@ -239,16 +239,11 @@ static int ptn5150_i2c_probe(struct i2c_client *i2c,
info->dev = &i2c->dev;
info->i2c = i2c;
- info->vbus_gpiod = devm_gpiod_get(&i2c->dev, "vbus", GPIOD_IN);
+ info->vbus_gpiod = devm_gpiod_get(&i2c->dev, "vbus", GPIOD_OUT_LOW);
if (IS_ERR(info->vbus_gpiod)) {
dev_err(dev, "failed to get VBUS GPIO\n");
return PTR_ERR(info->vbus_gpiod);
}
- ret = gpiod_direction_output(info->vbus_gpiod, 0);
- if (ret) {
- dev_err(dev, "failed to set VBUS GPIO direction\n");
- return -EINVAL;
- }
mutex_init(&info->mutex);
--
2.17.1
The PTN5150 chip can be used in hardware designs with only reporting of
USB Type-C connection, without the VBUS control. The driver however
unconditionally expected 'vbus-gpios'.
Since all uses of the VBUS GPIO descriptor are NULL safe, the code can
accept missing GPIO and provide only extcon status reporting.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
drivers/extcon/extcon-ptn5150.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
index 342973726565..008e664d8d56 100644
--- a/drivers/extcon/extcon-ptn5150.c
+++ b/drivers/extcon/extcon-ptn5150.c
@@ -238,8 +238,14 @@ static int ptn5150_i2c_probe(struct i2c_client *i2c,
info->i2c = i2c;
info->vbus_gpiod = devm_gpiod_get(&i2c->dev, "vbus", GPIOD_OUT_LOW);
if (IS_ERR(info->vbus_gpiod)) {
- dev_err(dev, "failed to get VBUS GPIO\n");
- return PTR_ERR(info->vbus_gpiod);
+ ret = PTR_ERR(info->vbus_gpiod);
+ if (ret == -ENOENT) {
+ dev_info(dev, "No VBUS GPIO, ignoring VBUS control\n");
+ info->vbus_gpiod = NULL;
+ } else {
+ dev_err(dev, "failed to get VBUS GPIO\n");
+ return ret;
+ }
}
mutex_init(&info->mutex);
--
2.17.1
The PTN5150 chip can be used in hardware designs with only reporting of
USB Type-C connection, without the VBUS control.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml
index 1ddc97db3e61..4b0f414486d2 100644
--- a/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml
+++ b/Documentation/devicetree/bindings/extcon/extcon-ptn5150.yaml
@@ -32,13 +32,13 @@ properties:
vbus-gpios:
description:
- GPIO pin (output) used to control VBUS.
+ GPIO pin (output) used to control VBUS. If skipped, no such control
+ takes place.
required:
- compatible
- interrupts
- reg
- - vbus-gpios
additionalProperties: false
--
2.17.1
When machine boots up, the USB could be already in OTG mode. In such
case there will be no interrupt coming to ptn5150 device and driver will
report default state of nothing connected. Detection of USB connection
would happen on first unplug of the cable.
Factor out code for checking current connection mode and call it right
after probe so the existing USB mode will be properly reported.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
Changes since v1:
1. Remove copied mutex_unlock
---
drivers/extcon/extcon-ptn5150.c | 92 ++++++++++++++++++---------------
1 file changed, 49 insertions(+), 43 deletions(-)
diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
index a57fef384a29..342973726565 100644
--- a/drivers/extcon/extcon-ptn5150.c
+++ b/drivers/extcon/extcon-ptn5150.c
@@ -5,6 +5,7 @@
// Based on extcon-sm5502.c driver
// Copyright (c) 2018-2019 by Vijai Kumar K
// Author: Vijai Kumar K <[email protected]>
+// Copyright (c) 2020 Krzysztof Kozlowski <[email protected]>
#include <linux/err.h>
#include <linux/i2c.h>
@@ -83,12 +84,49 @@ static const struct regmap_config ptn5150_regmap_config = {
.max_register = PTN5150_REG_END,
};
+static void ptn5150_check_state(struct ptn5150_info *info)
+{
+ unsigned int port_status, reg_data, vbus;
+ int ret;
+
+ ret = regmap_read(info->regmap, PTN5150_REG_CC_STATUS, ®_data);
+ if (ret) {
+ dev_err(info->dev, "failed to read CC STATUS %d\n", ret);
+ return;
+ }
+
+ port_status = ((reg_data &
+ PTN5150_REG_CC_PORT_ATTACHMENT_MASK) >>
+ PTN5150_REG_CC_PORT_ATTACHMENT_SHIFT);
+
+ switch (port_status) {
+ case PTN5150_DFP_ATTACHED:
+ extcon_set_state_sync(info->edev, EXTCON_USB_HOST, false);
+ gpiod_set_value_cansleep(info->vbus_gpiod, 0);
+ extcon_set_state_sync(info->edev, EXTCON_USB, true);
+ break;
+ case PTN5150_UFP_ATTACHED:
+ extcon_set_state_sync(info->edev, EXTCON_USB, false);
+ vbus = ((reg_data & PTN5150_REG_CC_VBUS_DETECTION_MASK) >>
+ PTN5150_REG_CC_VBUS_DETECTION_SHIFT);
+ if (vbus)
+ gpiod_set_value_cansleep(info->vbus_gpiod, 0);
+ else
+ gpiod_set_value_cansleep(info->vbus_gpiod, 1);
+
+ extcon_set_state_sync(info->edev, EXTCON_USB_HOST, true);
+ break;
+ default:
+ dev_err(info->dev, "Unknown Port status : %x\n", port_status);
+ break;
+ }
+}
+
static void ptn5150_irq_work(struct work_struct *work)
{
struct ptn5150_info *info = container_of(work,
struct ptn5150_info, irq_work);
int ret = 0;
- unsigned int reg_data;
unsigned int int_status;
if (!info->edev)
@@ -96,13 +134,6 @@ static void ptn5150_irq_work(struct work_struct *work)
mutex_lock(&info->mutex);
- ret = regmap_read(info->regmap, PTN5150_REG_CC_STATUS, ®_data);
- if (ret) {
- dev_err(info->dev, "failed to read CC STATUS %d\n", ret);
- mutex_unlock(&info->mutex);
- return;
- }
-
/* Clear interrupt. Read would clear the register */
ret = regmap_read(info->regmap, PTN5150_REG_INT_STATUS, &int_status);
if (ret) {
@@ -116,41 +147,7 @@ static void ptn5150_irq_work(struct work_struct *work)
cable_attach = int_status & PTN5150_REG_INT_CABLE_ATTACH_MASK;
if (cable_attach) {
- unsigned int port_status;
- unsigned int vbus;
-
- port_status = ((reg_data &
- PTN5150_REG_CC_PORT_ATTACHMENT_MASK) >>
- PTN5150_REG_CC_PORT_ATTACHMENT_SHIFT);
-
- switch (port_status) {
- case PTN5150_DFP_ATTACHED:
- extcon_set_state_sync(info->edev,
- EXTCON_USB_HOST, false);
- gpiod_set_value_cansleep(info->vbus_gpiod, 0);
- extcon_set_state_sync(info->edev, EXTCON_USB,
- true);
- break;
- case PTN5150_UFP_ATTACHED:
- extcon_set_state_sync(info->edev, EXTCON_USB,
- false);
- vbus = ((reg_data &
- PTN5150_REG_CC_VBUS_DETECTION_MASK) >>
- PTN5150_REG_CC_VBUS_DETECTION_SHIFT);
- if (vbus)
- gpiod_set_value_cansleep(info->vbus_gpiod, 0);
- else
- gpiod_set_value_cansleep(info->vbus_gpiod, 1);
-
- extcon_set_state_sync(info->edev,
- EXTCON_USB_HOST, true);
- break;
- default:
- dev_err(info->dev,
- "Unknown Port status : %x\n",
- port_status);
- break;
- }
+ ptn5150_check_state(info);
} else {
extcon_set_state_sync(info->edev,
EXTCON_USB_HOST, false);
@@ -302,6 +299,14 @@ static int ptn5150_i2c_probe(struct i2c_client *i2c,
if (ret)
return -EINVAL;
+ /*
+ * Update current extcon state if for example OTG connection was there
+ * before the probe
+ */
+ mutex_lock(&info->mutex);
+ ptn5150_check_state(info);
+ mutex_unlock(&info->mutex);
+
return 0;
}
@@ -334,4 +339,5 @@ subsys_initcall(ptn5150_i2c_init);
MODULE_DESCRIPTION("NXP PTN5150 CC logic Extcon driver");
MODULE_AUTHOR("Vijai Kumar K <[email protected]>");
+MODULE_AUTHOR("Krzysztof Kozlowski <[email protected]>");
MODULE_LICENSE("GPL v2");
--
2.17.1
The driver uses atomic version of gpiod_set_value() without any real
reason. It is called in a workqueue under mutex so it could sleep
there. Changing it to "can_sleep" flavor allows to use the driver with
all GPIO chips.
Fixes: 4ed754de2d66 ("extcon: Add support for ptn5150 extcon driver")
Cc: <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
---
drivers/extcon/extcon-ptn5150.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/extcon/extcon-ptn5150.c b/drivers/extcon/extcon-ptn5150.c
index d1c997599390..5f5252752644 100644
--- a/drivers/extcon/extcon-ptn5150.c
+++ b/drivers/extcon/extcon-ptn5150.c
@@ -127,7 +127,7 @@ static void ptn5150_irq_work(struct work_struct *work)
case PTN5150_DFP_ATTACHED:
extcon_set_state_sync(info->edev,
EXTCON_USB_HOST, false);
- gpiod_set_value(info->vbus_gpiod, 0);
+ gpiod_set_value_cansleep(info->vbus_gpiod, 0);
extcon_set_state_sync(info->edev, EXTCON_USB,
true);
break;
@@ -138,9 +138,9 @@ static void ptn5150_irq_work(struct work_struct *work)
PTN5150_REG_CC_VBUS_DETECTION_MASK) >>
PTN5150_REG_CC_VBUS_DETECTION_SHIFT);
if (vbus)
- gpiod_set_value(info->vbus_gpiod, 0);
+ gpiod_set_value_cansleep(info->vbus_gpiod, 0);
else
- gpiod_set_value(info->vbus_gpiod, 1);
+ gpiod_set_value_cansleep(info->vbus_gpiod, 1);
extcon_set_state_sync(info->edev,
EXTCON_USB_HOST, true);
@@ -156,7 +156,7 @@ static void ptn5150_irq_work(struct work_struct *work)
EXTCON_USB_HOST, false);
extcon_set_state_sync(info->edev,
EXTCON_USB, false);
- gpiod_set_value(info->vbus_gpiod, 0);
+ gpiod_set_value_cansleep(info->vbus_gpiod, 0);
}
}
--
2.17.1
I no longer have the setup for testing. The changes look good to me.
Reviewed-by: Vijai Kumar K <[email protected]>
Thanks,
Vijai Kumar K
On Mon, Aug 17, 2020 at 12:30 PM Krzysztof Kozlowski <[email protected]> wrote:
>
> Hi,
>
> Changes since v1:
> 1. Mutex unlock fix in patch 8/13.
>
> Best regards,
> Krzysztof
Hi,
Thank you for the patches and optimized the code as well.
I have applied your patches and tested, it's working fine
with few minor changes as per Intel's LGM board.
can I send the patches along with patches or we need to wait until
your patch get merge?
Please suggest to me go further, Thanks!
On 17/8/2020 2:59 pm, Krzysztof Kozlowski wrote:
> Hi,
>
> Changes since v1:
> 1. Mutex unlock fix in patch 8/13.
>
> Best regards,
> Krzysztof
>
On Mon, Aug 24, 2020 at 06:36:04PM +0800, Ramuthevar, Vadivel MuruganX wrote:
> Hi,
>
> Thank you for the patches and optimized the code as well.
> I have applied your patches and tested, it's working fine
> with few minor changes as per Intel's LGM board.
>
> can I send the patches along with patches or we need to wait until
> your patch get merge?
You can just base your patches on top of mine, send them and mention in
cover letter that they are based on these series (with link to
discussion).
Best regards,
Krzysztof
Hi Krzysztof,
On 8/17/20 3:59 PM, Krzysztof Kozlowski wrote:
> Hi,
>
> Changes since v1:
> 1. Mutex unlock fix in patch 8/13.
>
> Best regards,
> Krzysztof
>
>
Applied them. Thanks.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Hi,
On 8/24/20 7:36 PM, Ramuthevar, Vadivel MuruganX wrote:
> Hi,
>
> Thank you for the patches and optimized the code as well.
> I have applied your patches and tested, it's working fine
> with few minor changes as per Intel's LGM board.
Thanks for the test.
>
> can I send the patches along with patches or we need to wait until
> your patch get merge?
>
> Please suggest to me go further, Thanks!
I applied these patches. You better to send your patches
based on extcon-next. Thanks.
>
> On 17/8/2020 2:59 pm, Krzysztof Kozlowski wrote:
>> Hi,
>>
>> Changes since v1:
>> 1. Mutex unlock fix in patch 8/13.
>>
>> Best regards,
>> Krzysztof
>>
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Hi,
On 24/8/2020 6:38 pm, Krzysztof Kozlowski wrote:
> On Mon, Aug 24, 2020 at 06:36:04PM +0800, Ramuthevar, Vadivel MuruganX wrote:
>> Hi,
>>
>> Thank you for the patches and optimized the code as well.
>> I have applied your patches and tested, it's working fine
>> with few minor changes as per Intel's LGM board.
>>
>> can I send the patches along with patches or we need to wait until
>> your patch get merge?
>
> You can just base your patches on top of mine, send them and mention in
> cover letter that they are based on these series (with link to
> discussion).
Thank you very for the confirmation, sure will do the rebase over your
patch and sent.
Regards
Vadivel
>
> Best regards,
> Krzysztof
>
Hi Chanwoo,
On 8/24/20 6:28 AM, Chanwoo Choi wrote:
> Hi,
>
> On 8/24/20 7:36 PM, Ramuthevar, Vadivel MuruganX wrote:
>> Hi,
>>
>> Thank you for the patches and optimized the code as well.
>> I have applied your patches and tested, it's working fine
>> with few minor changes as per Intel's LGM board.
>
> Thanks for the test.
>
>>
>> can I send the patches along with patches or we need to wait until
>> your patch get merge?
>>
>> Please suggest to me go further, Thanks!
>
> I applied these patches. You better to send your patches
> based on extcon-next. Thanks.
I am not sure what happened, but the $id and $schema got morphed in the patch
on linux-next, 000ce2ad3c96 ("dt-bindings: extcon: ptn5150: Convert binding to
DT schema"), when compared to Krzysztof's original patch.
This is causing dtbs_check to fail in general on linux-next,
UPD include/config/kernel.release
CHKDT Documentation/devicetree/bindings/processed-schema-examples.json
Traceback (most recent call last):
File
"/home/suman/.local/lib/python3.6/site-packages/jsonschema/validators.py", line
774, in resolve_from_url
document = self.store[url]
File "/home/suman/.local/lib/python3.6/site-packages/jsonschema/_utils.py",
line 22, in __getitem__
return self.store[self.normalize(uri)]
KeyError:
'https://protect2.fireeye.com/url?k=59835ffc-05905d01-59822c67-0cc47a336902-306bd2691e458c36&q=1&u=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File
"/home/suman/.local/lib/python3.6/site-packages/jsonschema/validators.py", line
777, in resolve_from_url
document = self.resolve_remote(url)
File
"/home/suman/.local/lib/python3.6/site-packages/jsonschema/validators.py", line
860, in resolve_remote
result = requests.get(uri).json()
File "/usr/lib/python3/dist-packages/requests/models.py", line 892, in json
return complexjson.loads(self.text, **kwargs)
File "/usr/lib/python3/dist-packages/simplejson/__init__.py", line 518, in loads
return _default_decoder.decode(s)
File "/usr/lib/python3/dist-packages/simplejson/decoder.py", line 370, in decode
obj, end = self.raw_decode(s)
File "/usr/lib/python3/dist-packages/simplejson/decoder.py", line 400, in
raw_decode
return self.scan_once(s, idx=_w(s, idx).end())
simplejson.errors.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/suman/.local/bin/dt-doc-validate", line 67, in <module>
ret = check_doc(f)
File "/home/suman/.local/bin/dt-doc-validate", line 33, in check_doc
for error in sorted(dtschema.DTValidator.iter_schema_errors(testtree),
key=lambda e: e.linecol):
File "/home/suman/.local/lib/python3.6/site-packages/dtschema/lib.py", line
663, in iter_schema_errors
meta_schema = cls.resolver.resolve_from_url(schema['$schema'])
File
"/home/suman/.local/lib/python3.6/site-packages/jsonschema/validators.py", line
779, in resolve_from_url
raise exceptions.RefResolutionError(exc)
jsonschema.exceptions.RefResolutionError: Expecting value: line 1 column 1 (char 0)
Documentation/devicetree/bindings/Makefile:52: recipe for target
'Documentation/devicetree/bindings/processed-schema-examples.json' failed
make[1]: *** [Documentation/devicetree/bindings/processed-schema-examples.json]
Error 123
Makefile:1366: recipe for target 'dt_binding_check' failed
make: *** [dt_binding_check] Error 2
regards
Suman
>
>>
>> On 17/8/2020 2:59 pm, Krzysztof Kozlowski wrote:
>>> Hi,
>>>
>>> Changes since v1:
>>> 1. Mutex unlock fix in patch 8/13.
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>
>>
>
>
Hi Suman,
On 8/27/20 6:56 AM, Suman Anna wrote:
> Hi Chanwoo,
>
> On 8/24/20 6:28 AM, Chanwoo Choi wrote:
>> Hi,
>>
>> On 8/24/20 7:36 PM, Ramuthevar, Vadivel MuruganX wrote:
>>> Hi,
>>>
>>> Thank you for the patches and optimized the code as well.
>>> I have applied your patches and tested, it's working fine
>>> with few minor changes as per Intel's LGM board.
>>
>> Thanks for the test.
>>
>>>
>>> can I send the patches along with patches or we need to wait until
>>> your patch get merge?
>>>
>>> Please suggest to me go further, Thanks!
>>
>> I applied these patches. You better to send your patches
>> based on extcon-next. Thanks.
>
> I am not sure what happened, but the $id and $schema got morphed in the patch
> on linux-next, 000ce2ad3c96 ("dt-bindings: extcon: ptn5150: Convert binding to
> DT schema"), when compared to Krzysztof's original patch.
It is my fault because of the company's firewall.
I updated and pushed it. Thanks.
>
> This is causing dtbs_check to fail in general on linux-next,
> UPD include/config/kernel.release
> CHKDT Documentation/devicetree/bindings/processed-schema-examples.json
> Traceback (most recent call last):
> File
> "/home/suman/.local/lib/python3.6/site-packages/jsonschema/validators.py", line
> 774, in resolve_from_url
> document = self.store[url]
> File "/home/suman/.local/lib/python3.6/site-packages/jsonschema/_utils.py",
> line 22, in __getitem__
> return self.store[self.normalize(uri)]
> KeyError:
> 'https://protect2.fireeye.com/url?k=59835ffc-05905d01-59822c67-0cc47a336902-306bd2691e458c36&q=1&u=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
> File
> "/home/suman/.local/lib/python3.6/site-packages/jsonschema/validators.py", line
> 777, in resolve_from_url
> document = self.resolve_remote(url)
> File
> "/home/suman/.local/lib/python3.6/site-packages/jsonschema/validators.py", line
> 860, in resolve_remote
> result = requests.get(uri).json()
> File "/usr/lib/python3/dist-packages/requests/models.py", line 892, in json
> return complexjson.loads(self.text, **kwargs)
> File "/usr/lib/python3/dist-packages/simplejson/__init__.py", line 518, in loads
> return _default_decoder.decode(s)
> File "/usr/lib/python3/dist-packages/simplejson/decoder.py", line 370, in decode
> obj, end = self.raw_decode(s)
> File "/usr/lib/python3/dist-packages/simplejson/decoder.py", line 400, in
> raw_decode
> return self.scan_once(s, idx=_w(s, idx).end())
> simplejson.errors.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
> File "/home/suman/.local/bin/dt-doc-validate", line 67, in <module>
> ret = check_doc(f)
> File "/home/suman/.local/bin/dt-doc-validate", line 33, in check_doc
> for error in sorted(dtschema.DTValidator.iter_schema_errors(testtree),
> key=lambda e: e.linecol):
> File "/home/suman/.local/lib/python3.6/site-packages/dtschema/lib.py", line
> 663, in iter_schema_errors
> meta_schema = cls.resolver.resolve_from_url(schema['$schema'])
> File
> "/home/suman/.local/lib/python3.6/site-packages/jsonschema/validators.py", line
> 779, in resolve_from_url
> raise exceptions.RefResolutionError(exc)
> jsonschema.exceptions.RefResolutionError: Expecting value: line 1 column 1 (char 0)
> Documentation/devicetree/bindings/Makefile:52: recipe for target
> 'Documentation/devicetree/bindings/processed-schema-examples.json' failed
> make[1]: *** [Documentation/devicetree/bindings/processed-schema-examples.json]
> Error 123
> Makefile:1366: recipe for target 'dt_binding_check' failed
> make: *** [dt_binding_check] Error 2
>
> regards
> Suman
>
>>
>>>
>>> On 17/8/2020 2:59 pm, Krzysztof Kozlowski wrote:
>>>> Hi,
>>>>
>>>> Changes since v1:
>>>> 1. Mutex unlock fix in patch 8/13.
>>>>
>>>> Best regards,
>>>> Krzysztof
>>>>
>>>
>>>
>>
>>
>
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics