[PATCH v3 1/3] input: pm8xxx-vib: refactor to easily support new SPMI vibrator

[PATCH v3 1/3] input: pm8xxx-vib: refactor to easily support new SPMI vibrator

[Fenglin Wu]

Currently, all vibrator control register addresses are hard coded,
including the base address and the offset, it's not flexible to support
new SPMI vibrator module which is usually included in different PMICs
with different base address. Refactor this by introducing the HW type
terminology and contain the register offsets/masks/shifts in reg_filed
data structures corresponding to each vibrator type, and the base address
value defined in 'reg' property will be added for SPMI vibrators.

Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
---
 drivers/input/misc/pm8xxx-vibrator.c | 130 ++++++++++++++++-----------
 1 file changed, 77 insertions(+), 53 deletions(-)

diff --git a/drivers/input/misc/pm8xxx-vibrator.c b/drivers/input/misc/pm8xxx-vibrator.c
index 04cb87efd799..77bb0018d4e1 100644
--- a/drivers/input/misc/pm8xxx-vibrator.c
+++ b/drivers/input/misc/pm8xxx-vibrator.c
@@ -12,36 +12,36 @@
 #include <linux/regmap.h>
 #include <linux/slab.h>
 
+#define SSBI_VIB_DRV_EN_MANUAL_MASK	0xfc
+#define SSBI_VIB_DRV_LEVEL_MASK		0xf8
+#define SSBI_VIB_DRV_SHIFT		3
+#define SPMI_VIB_DRV_LEVEL_MASK		0xff
+#define SPMI_VIB_DRV_SHIFT		0
+
 #define VIB_MAX_LEVEL_mV	(3100)
 #define VIB_MIN_LEVEL_mV	(1200)
 #define VIB_MAX_LEVELS		(VIB_MAX_LEVEL_mV - VIB_MIN_LEVEL_mV)
 
 #define MAX_FF_SPEED		0xff
 
-struct pm8xxx_regs {
-	unsigned int enable_addr;
-	unsigned int enable_mask;
+enum pm8xxx_vib_type {
+	SSBI_VIB,
+	SPMI_VIB_GEN1,
+};
 
-	unsigned int drv_addr;
-	unsigned int drv_mask;
-	unsigned int drv_shift;
-	unsigned int drv_en_manual_mask;
+enum {
+	VIB_DRV_REG,
+	VIB_EN_REG,
+	VIB_MAX_REG,
 };
 
-static const struct pm8xxx_regs pm8058_regs = {
-	.drv_addr = 0x4A,
-	.drv_mask = 0xf8,
-	.drv_shift = 3,
-	.drv_en_manual_mask = 0xfc,
+static struct reg_field ssbi_vib_regs[VIB_MAX_REG] = {
+	REG_FIELD(0xf8, 0, 7),
 };
 
-static struct pm8xxx_regs pm8916_regs = {
-	.enable_addr = 0xc046,
-	.enable_mask = BIT(7),
-	.drv_addr = 0xc041,
-	.drv_mask = 0x1F,
-	.drv_shift = 0,
-	.drv_en_manual_mask = 0,
+static struct reg_field spmi_vib_gen1_regs[VIB_MAX_REG] = {
+	REG_FIELD(0x41, 0, 4),
+	REG_FIELD(0x46, 7, 7),
 };
 
 /**
@@ -58,12 +58,12 @@ static struct pm8xxx_regs pm8916_regs = {
 struct pm8xxx_vib {
 	struct input_dev *vib_input_dev;
 	struct work_struct work;
-	struct regmap *regmap;
-	const struct pm8xxx_regs *regs;
+	struct regmap_field *r_fields[VIB_MAX_REG];
 	int speed;
 	int level;
 	bool active;
 	u8  reg_vib_drv;
+	enum pm8xxx_vib_type hw_type;
 };
 
 /**
@@ -75,22 +75,27 @@ static int pm8xxx_vib_set(struct pm8xxx_vib *vib, bool on)
 {
 	int rc;
 	unsigned int val = vib->reg_vib_drv;
-	const struct pm8xxx_regs *regs = vib->regs;
+	u32 mask = SPMI_VIB_DRV_LEVEL_MASK;
+	u32 shift = SPMI_VIB_DRV_SHIFT;
+
+	if (vib->hw_type == SSBI_VIB) {
+		mask = SSBI_VIB_DRV_LEVEL_MASK;
+		shift = SSBI_VIB_DRV_SHIFT;
+	}
 
 	if (on)
-		val |= (vib->level << regs->drv_shift) & regs->drv_mask;
+		val |= (vib->level << shift) & mask;
 	else
-		val &= ~regs->drv_mask;
+		val &= ~mask;
 
-	rc = regmap_write(vib->regmap, regs->drv_addr, val);
+	rc = regmap_field_write(vib->r_fields[VIB_DRV_REG], val);
 	if (rc < 0)
 		return rc;
 
 	vib->reg_vib_drv = val;
 
-	if (regs->enable_mask)
-		rc = regmap_update_bits(vib->regmap, regs->enable_addr,
-					regs->enable_mask, on ? ~0 : 0);
+	if (vib->hw_type != SSBI_VIB)
+		rc = regmap_field_write(vib->r_fields[VIB_EN_REG], on);
 
 	return rc;
 }
@@ -102,13 +107,6 @@ static int pm8xxx_vib_set(struct pm8xxx_vib *vib, bool on)
 static void pm8xxx_work_handler(struct work_struct *work)
 {
 	struct pm8xxx_vib *vib = container_of(work, struct pm8xxx_vib, work);
-	const struct pm8xxx_regs *regs = vib->regs;
-	int rc;
-	unsigned int val;
-
-	rc = regmap_read(vib->regmap, regs->drv_addr, &val);
-	if (rc < 0)
-		return;
 
 	/*
 	 * pmic vibrator supports voltage ranges from 1.2 to 3.1V, so
@@ -168,38 +166,65 @@ static int pm8xxx_vib_probe(struct platform_device *pdev)
 {
 	struct pm8xxx_vib *vib;
 	struct input_dev *input_dev;
-	int error;
+	struct device *dev = &pdev->dev;
+	struct regmap *regmap;
+	struct reg_field *regs;
+	int error, i;
 	unsigned int val;
-	const struct pm8xxx_regs *regs;
+	u32 reg_base;
 
-	vib = devm_kzalloc(&pdev->dev, sizeof(*vib), GFP_KERNEL);
+	vib = devm_kzalloc(dev, sizeof(*vib), GFP_KERNEL);
 	if (!vib)
 		return -ENOMEM;
 
-	vib->regmap = dev_get_regmap(pdev->dev.parent, NULL);
-	if (!vib->regmap)
+	regmap = dev_get_regmap(dev->parent, NULL);
+	if (!regmap)
 		return -ENODEV;
 
-	input_dev = devm_input_allocate_device(&pdev->dev);
+	input_dev = devm_input_allocate_device(dev);
 	if (!input_dev)
 		return -ENOMEM;
 
 	INIT_WORK(&vib->work, pm8xxx_work_handler);
 	vib->vib_input_dev = input_dev;
 
-	regs = of_device_get_match_data(&pdev->dev);
+	vib->hw_type = (enum pm8xxx_vib_type)of_device_get_match_data(dev);
 
-	/* operate in manual mode */
-	error = regmap_read(vib->regmap, regs->drv_addr, &val);
+	regs = ssbi_vib_regs;
+	if (vib->hw_type != SSBI_VIB) {
+		error = fwnode_property_read_u32(dev->fwnode, "reg", &reg_base);
+		if (error < 0) {
+			dev_err(dev, "Failed to read reg address, rc=%d\n", error);
+			return error;
+		}
+
+		if (vib->hw_type == SPMI_VIB_GEN1)
+			regs = spmi_vib_gen1_regs;
+
+		for (i = 0; i < VIB_MAX_REG; i++)
+			if (regs[i].reg != 0)
+				regs[i].reg += reg_base;
+	}
+
+	error = devm_regmap_field_bulk_alloc(dev, regmap, vib->r_fields, regs, VIB_MAX_REG);
 	if (error < 0)
+	{
+		dev_err(dev, "Failed to allocate regmap failed, rc=%d\n", error);
 		return error;
+	}
 
-	val &= regs->drv_en_manual_mask;
-	error = regmap_write(vib->regmap, regs->drv_addr, val);
+	error = regmap_field_read(vib->r_fields[VIB_DRV_REG], &val);
 	if (error < 0)
 		return error;
 
-	vib->regs = regs;
+	/* operate in manual mode */
+	if (vib->hw_type == SSBI_VIB) {
+		val &= SSBI_VIB_DRV_EN_MANUAL_MASK;
+		error = regmap_field_write(vib->r_fields[VIB_DRV_REG], val);
+		if (error < 0)
+			return error;
+	}
+
 	vib->reg_vib_drv = val;
 
 	input_dev->name = "pm8xxx_vib_ffmemless";
@@ -211,14 +236,13 @@ static int pm8xxx_vib_probe(struct platform_device *pdev)
 	error = input_ff_create_memless(input_dev, NULL,
 					pm8xxx_vib_play_effect);
 	if (error) {
-		dev_err(&pdev->dev,
-			"couldn't register vibrator as FF device\n");
+		dev_err(dev, "couldn't register vibrator as FF device\n");
 		return error;
 	}
 
 	error = input_register_device(input_dev);
 	if (error) {
-		dev_err(&pdev->dev, "couldn't register input device\n");
+		dev_err(dev, "couldn't register input device\n");
 		return error;
 	}
 
@@ -239,9 +263,9 @@ static int pm8xxx_vib_suspend(struct device *dev)
 static DEFINE_SIMPLE_DEV_PM_OPS(pm8xxx_vib_pm_ops, pm8xxx_vib_suspend, NULL);
 
 static const struct of_device_id pm8xxx_vib_id_table[] = {
-	{ .compatible = "qcom,pm8058-vib", .data = &pm8058_regs },
-	{ .compatible = "qcom,pm8921-vib", .data = &pm8058_regs },
-	{ .compatible = "qcom,pm8916-vib", .data = &pm8916_regs },
+	{ .compatible = "qcom,pm8058-vib", .data = (void *)SSBI_VIB },
+	{ .compatible = "qcom,pm8921-vib", .data = (void *)SSBI_VIB },
+	{ .compatible = "qcom,pm8916-vib", .data = (void *)SPMI_VIB_GEN1 },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, pm8xxx_vib_id_table);
-- 
2.25.1

[PATCH v3 2/3] dt-bindings: input: qcom,pm8xxx-vib: add new SPMI vibrator module

[Fenglin Wu]

Add compatible string 'qcom,spmi-vib-gen2' for vibrator module inside
PMI632, PMI7250B, PM7325B, PM7550BA. Also, add 'qcom,spmi-vib-gen1'
string for the SPMI vibrator inside PM8916 to maintain the completeness
of the hardware version history for SPMI vibrators.

Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
---
 .../bindings/input/qcom,pm8xxx-vib.yaml        | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
index c8832cd0d7da..ab778714ad29 100644
--- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
+++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
@@ -11,10 +11,20 @@ maintainers:
 
 properties:
   compatible:
-    enum:
-      - qcom,pm8058-vib
-      - qcom,pm8916-vib
-      - qcom,pm8921-vib
+    oneOf:
+      - enum:
+          - qcom,pm8058-vib
+          - qcom,pm8916-vib
+          - qcom,pm8921-vib
+          - qcom,spmi-vib-gen1
+          - qcom,spmi-vib-gen2
+      - items:
+          - enum:
+              - qcom,pmi632-vib
+              - qcom,pm7250b-vib
+              - qcom,pm7325b-vib
+              - qcom,pm7550b-vib
+          - const: qcom,spmi-vib-gen2
 
   reg:
     maxItems: 1
-- 
2.25.1

[PATCH v3 3/3] input: pm8xxx-vibrator: add new SPMI vibrator support

[Fenglin Wu]

Add new SPMI vibrator module which is very similar to the SPMI vibrator
module inside PM8916 but just has a finer drive voltage step (1mV vs
100mV) hence its drive level control is expanded to across 2 registers.
Name the module as 'qcom,spmi-vib-gen2', and it can be found in
following Qualcomm PMICs: PMI632, PM7250B, PM7325B, PM7550BA. Also, add
a compatible string 'qcom,spmi-vib-gen1' for SPMI vibrator inside PM8916
to maintain the completeness of the hardware version history.

Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
---
 drivers/input/misc/pm8xxx-vibrator.c | 37 ++++++++++++++++++++++++++--
 1 file changed, 35 insertions(+), 2 deletions(-)

diff --git a/drivers/input/misc/pm8xxx-vibrator.c b/drivers/input/misc/pm8xxx-vibrator.c
index 77bb0018d4e1..2cbccc5c6cf3 100644
--- a/drivers/input/misc/pm8xxx-vibrator.c
+++ b/drivers/input/misc/pm8xxx-vibrator.c
@@ -17,6 +17,8 @@
 #define SSBI_VIB_DRV_SHIFT		3
 #define SPMI_VIB_DRV_LEVEL_MASK		0xff
 #define SPMI_VIB_DRV_SHIFT		0
+#define SPMI_VIB_DRV2_LEVEL_MASK	0x0f
+#define SPMI_VIB_DRV2_SHIFT		8
 
 #define VIB_MAX_LEVEL_mV	(3100)
 #define VIB_MIN_LEVEL_mV	(1200)
@@ -27,11 +29,13 @@
 enum pm8xxx_vib_type {
 	SSBI_VIB,
 	SPMI_VIB_GEN1,
+	SPMI_VIB_GEN2,
 };
 
 enum {
 	VIB_DRV_REG,
 	VIB_EN_REG,
+	VIB_DRV2_REG,
 	VIB_MAX_REG,
 };
 
@@ -44,6 +48,12 @@ static struct reg_field spmi_vib_gen1_regs[VIB_MAX_REG] = {
 	REG_FIELD(0x46, 7, 7),
 };
 
+static struct reg_field spmi_vib_gen2_regs[VIB_MAX_REG] = {
+	REG_FIELD(0x40, 0, 7),
+	REG_FIELD(0x46, 7, 7),
+	REG_FIELD(0x41, 0, 3),
+};
+
 /**
  * struct pm8xxx_vib - structure to hold vibrator data
  * @vib_input_dev: input device supporting force feedback
@@ -94,6 +104,22 @@ static int pm8xxx_vib_set(struct pm8xxx_vib *vib, bool on)
 
 	vib->reg_vib_drv = val;
 
+	if (vib->hw_type == SPMI_VIB_GEN2) {
+		mask = SPMI_VIB_DRV2_LEVEL_MASK;
+		shift = SPMI_VIB_DRV2_SHIFT;
+
+		if (on)
+			val = (vib->level >> shift) & mask;
+		else
+			val = 0;
+
+		rc = regmap_field_write(vib->r_fields[VIB_DRV2_REG], val);
+		if (rc < 0)
+			return rc;
+
+		vib->reg_vib_drv |= val << shift;
+	}
+
 	if (vib->hw_type != SSBI_VIB)
 		rc = regmap_field_write(vib->r_fields[VIB_EN_REG], on);
 
@@ -116,10 +142,13 @@ static void pm8xxx_work_handler(struct work_struct *work)
 		vib->active = true;
 		vib->level = ((VIB_MAX_LEVELS * vib->speed) / MAX_FF_SPEED) +
 						VIB_MIN_LEVEL_mV;
-		vib->level /= 100;
+		if (vib->hw_type != SPMI_VIB_GEN2)
+			vib->level /= 100;
 	} else {
 		vib->active = false;
-		vib->level = VIB_MIN_LEVEL_mV / 100;
+		vib->level = VIB_MIN_LEVEL_mV;
+		if (vib->hw_type != SPMI_VIB_GEN2)
+			vib->level /= 100;
 	}
 
 	pm8xxx_vib_set(vib, vib->active);
@@ -200,6 +229,8 @@ static int pm8xxx_vib_probe(struct platform_device *pdev)
 
 		if (vib->hw_type == SPMI_VIB_GEN1)
 			regs = spmi_vib_gen1_regs;
+		else
+			regs = spmi_vib_gen2_regs;
 
 		for (i = 0; i < VIB_MAX_REG; i++)
 			if (regs[i].reg != 0)
@@ -266,6 +297,8 @@ static const struct of_device_id pm8xxx_vib_id_table[] = {
 	{ .compatible = "qcom,pm8058-vib", .data = (void *)SSBI_VIB },
 	{ .compatible = "qcom,pm8921-vib", .data = (void *)SSBI_VIB },
 	{ .compatible = "qcom,pm8916-vib", .data = (void *)SPMI_VIB_GEN1 },
+	{ .compatible = "qcom,spmi-vib-gen1", .data = (void *)SPMI_VIB_GEN1 },
+	{ .compatible = "qcom,spmi-vib-gen2", .data = (void *)SPMI_VIB_GEN2 },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, pm8xxx_vib_id_table);
-- 
2.25.1

Re: [PATCH v3 1/3] input: pm8xxx-vib: refactor to easily support new SPMI vibrator

[Krzysztof Kozlowski]

On 25/07/2023 07:41, Fenglin Wu wrote:
> Currently, all vibrator control register addresses are hard coded,
> including the base address and the offset, it's not flexible to support
> new SPMI vibrator module which is usually included in different PMICs
> with different base address. Refactor this by introducing the HW type
> terminology and contain the register offsets/masks/shifts in reg_filed
> data structures corresponding to each vibrator type, and the base address
> value defined in 'reg' property will be added for SPMI vibrators.
> 
> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
> ---
>  drivers/input/misc/pm8xxx-vibrator.c | 130 ++++++++++++++++-----------
>  1 file changed, 77 insertions(+), 53 deletions(-)
> 
> diff --git a/drivers/input/misc/pm8xxx-vibrator.c b/drivers/input/misc/pm8xxx-vibrator.c
> index 04cb87efd799..77bb0018d4e1 100644
> --- a/drivers/input/misc/pm8xxx-vibrator.c
> +++ b/drivers/input/misc/pm8xxx-vibrator.c
> @@ -12,36 +12,36 @@
>  #include <linux/regmap.h>
>  #include <linux/slab.h>
>  
> +#define SSBI_VIB_DRV_EN_MANUAL_MASK	0xfc
> +#define SSBI_VIB_DRV_LEVEL_MASK		0xf8
> +#define SSBI_VIB_DRV_SHIFT		3
> +#define SPMI_VIB_DRV_LEVEL_MASK		0xff
> +#define SPMI_VIB_DRV_SHIFT		0
> +
>  #define VIB_MAX_LEVEL_mV	(3100)
>  #define VIB_MIN_LEVEL_mV	(1200)
>  #define VIB_MAX_LEVELS		(VIB_MAX_LEVEL_mV - VIB_MIN_LEVEL_mV)
>  
>  #define MAX_FF_SPEED		0xff
>  
> -struct pm8xxx_regs {
> -	unsigned int enable_addr;
> -	unsigned int enable_mask;
> +enum pm8xxx_vib_type {
> +	SSBI_VIB,
> +	SPMI_VIB_GEN1,
> +};
>  
> -	unsigned int drv_addr;
> -	unsigned int drv_mask;
> -	unsigned int drv_shift;
> -	unsigned int drv_en_manual_mask;
> +enum {
> +	VIB_DRV_REG,
> +	VIB_EN_REG,
> +	VIB_MAX_REG,
>  };
>  
> -static const struct pm8xxx_regs pm8058_regs = {
> -	.drv_addr = 0x4A,
> -	.drv_mask = 0xf8,
> -	.drv_shift = 3,
> -	.drv_en_manual_mask = 0xfc,
> +static struct reg_field ssbi_vib_regs[VIB_MAX_REG] = {

Change from const to non-const is wrong. How do you support multiple
devices? No, this is way too fragile now.

...

>  
>  	/*
>  	 * pmic vibrator supports voltage ranges from 1.2 to 3.1V, so
> @@ -168,38 +166,65 @@ static int pm8xxx_vib_probe(struct platform_device *pdev)
>  {
>  	struct pm8xxx_vib *vib;
>  	struct input_dev *input_dev;
> -	int error;
> +	struct device *dev = &pdev->dev;
> +	struct regmap *regmap;
> +	struct reg_field *regs;
> +	int error, i;
>  	unsigned int val;
> -	const struct pm8xxx_regs *regs;
> +	u32 reg_base;
>  
> -	vib = devm_kzalloc(&pdev->dev, sizeof(*vib), GFP_KERNEL);
> +	vib = devm_kzalloc(dev, sizeof(*vib), GFP_KERNEL);

Not really related. Split cleanup from new features.

>  	if (!vib)
>  		return -ENOMEM;
>  
> -	vib->regmap = dev_get_regmap(pdev->dev.parent, NULL);
> -	if (!vib->regmap)
> +	regmap = dev_get_regmap(dev->parent, NULL);
> +	if (!regmap)
>  		return -ENODEV;
>  
> -	input_dev = devm_input_allocate_device(&pdev->dev);
> +	input_dev = devm_input_allocate_device(dev);
>  	if (!input_dev)
>  		return -ENOMEM;
>  
>  	INIT_WORK(&vib->work, pm8xxx_work_handler);
>  	vib->vib_input_dev = input_dev;
>  
> -	regs = of_device_get_match_data(&pdev->dev);
> +	vib->hw_type = (enum pm8xxx_vib_type)of_device_get_match_data(dev);
>  
> -	/* operate in manual mode */
> -	error = regmap_read(vib->regmap, regs->drv_addr, &val);
> +	regs = ssbi_vib_regs;
> +	if (vib->hw_type != SSBI_VIB) {
> +		error = fwnode_property_read_u32(dev->fwnode, "reg", &reg_base);
> +		if (error < 0) {
> +			dev_err(dev, "Failed to read reg address, rc=%d\n", error);
> +			return error;
> +		}
> +
> +		if (vib->hw_type == SPMI_VIB_GEN1)
> +			regs = spmi_vib_gen1_regs;
> +
> +		for (i = 0; i < VIB_MAX_REG; i++)
> +			if (regs[i].reg != 0)
> +				regs[i].reg += reg_base;
> +	}
> +
> +	error = devm_regmap_field_bulk_alloc(dev, regmap, vib->r_fields, regs, VIB_MAX_REG);
>  	if (error < 0)
> +	{

That's not a Linux coding style.

Please run scripts/checkpatch.pl and fix reported warnings. Some
warnings can be ignored, but the code here looks like it needs a fix.
Feel free to get in touch if the warning is not clear.

> +		dev_err(dev, "Failed to allocate regmap failed, rc=%d\n", error);

No need to print errors on allocation failures.

>  		return error;
> +	}
>  
> -	val &= regs->drv_en_manual_mask;
> -	error = regmap_write(vib->regmap, regs->drv_addr, val);
> +	error = regmap_field_read(vib->r_fields[VIB_DRV_REG], &val);
>  	if (error < 0)
>  		return error;


Best regards,
Krzysztof

Re: [PATCH v3 2/3] dt-bindings: input: qcom,pm8xxx-vib: add new SPMI vibrator module

[Krzysztof Kozlowski]

On 25/07/2023 07:41, Fenglin Wu wrote:
> Add compatible string 'qcom,spmi-vib-gen2' for vibrator module inside
> PMI632, PMI7250B, PM7325B, PM7550BA. Also, add 'qcom,spmi-vib-gen1'
> string for the SPMI vibrator inside PM8916 to maintain the completeness
> of the hardware version history for SPMI vibrators.
> 
> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
> ---
>  .../bindings/input/qcom,pm8xxx-vib.yaml        | 18 ++++++++++++++----
>  1 file changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
> index c8832cd0d7da..ab778714ad29 100644
> --- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
> +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
> @@ -11,10 +11,20 @@ maintainers:
>  
>  properties:
>    compatible:
> -    enum:
> -      - qcom,pm8058-vib
> -      - qcom,pm8916-vib
> -      - qcom,pm8921-vib
> +    oneOf:
> +      - enum:
> +          - qcom,pm8058-vib
> +          - qcom,pm8916-vib
> +          - qcom,pm8921-vib
> +          - qcom,spmi-vib-gen1
> +          - qcom,spmi-vib-gen2

Generic compatibles should not be alone. Drop both lines.

> +      - items:
> +          - enum:
> +              - qcom,pmi632-vib
> +              - qcom,pm7250b-vib
> +              - qcom,pm7325b-vib
> +              - qcom,pm7550b-vib
> +          - const: qcom,spmi-vib-gen2


Best regards,
Krzysztof

Re: [PATCH v3 1/3] input: pm8xxx-vib: refactor to easily support new SPMI vibrator

[Fenglin Wu]

On 7/25/2023 1:52 PM, Krzysztof Kozlowski wrote:
> On 25/07/2023 07:41, Fenglin Wu wrote:
>> Currently, all vibrator control register addresses are hard coded,
>> including the base address and the offset, it's not flexible to support
>> new SPMI vibrator module which is usually included in different PMICs
>> with different base address. Refactor this by introducing the HW type
>> terminology and contain the register offsets/masks/shifts in reg_filed
>> data structures corresponding to each vibrator type, and the base address
>> value defined in 'reg' property will be added for SPMI vibrators.
>>
>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>> ---
>>   drivers/input/misc/pm8xxx-vibrator.c | 130 ++++++++++++++++-----------
>>   1 file changed, 77 insertions(+), 53 deletions(-)
>>
>> diff --git a/drivers/input/misc/pm8xxx-vibrator.c b/drivers/input/misc/pm8xxx-vibrator.c
>> index 04cb87efd799..77bb0018d4e1 100644
>> --- a/drivers/input/misc/pm8xxx-vibrator.c
>> +++ b/drivers/input/misc/pm8xxx-vibrator.c
>> @@ -12,36 +12,36 @@
>>   #include <linux/regmap.h>
>>   #include <linux/slab.h>
>>   
>> +#define SSBI_VIB_DRV_EN_MANUAL_MASK	0xfc
>> +#define SSBI_VIB_DRV_LEVEL_MASK		0xf8
>> +#define SSBI_VIB_DRV_SHIFT		3
>> +#define SPMI_VIB_DRV_LEVEL_MASK		0xff
>> +#define SPMI_VIB_DRV_SHIFT		0
>> +
>>   #define VIB_MAX_LEVEL_mV	(3100)
>>   #define VIB_MIN_LEVEL_mV	(1200)
>>   #define VIB_MAX_LEVELS		(VIB_MAX_LEVEL_mV - VIB_MIN_LEVEL_mV)
>>   
>>   #define MAX_FF_SPEED		0xff
>>   
>> -struct pm8xxx_regs {
>> -	unsigned int enable_addr;
>> -	unsigned int enable_mask;
>> +enum pm8xxx_vib_type {
>> +	SSBI_VIB,
>> +	SPMI_VIB_GEN1,
>> +};
>>   
>> -	unsigned int drv_addr;
>> -	unsigned int drv_mask;
>> -	unsigned int drv_shift;
>> -	unsigned int drv_en_manual_mask;
>> +enum {
>> +	VIB_DRV_REG,
>> +	VIB_EN_REG,
>> +	VIB_MAX_REG,
>>   };
>>   
>> -static const struct pm8xxx_regs pm8058_regs = {
>> -	.drv_addr = 0x4A,
>> -	.drv_mask = 0xf8,
>> -	.drv_shift = 3,
>> -	.drv_en_manual_mask = 0xfc,
>> +static struct reg_field ssbi_vib_regs[VIB_MAX_REG] = {
> 
> Change from const to non-const is wrong. How do you support multiple
> devices? No, this is way too fragile now.
> 

The register definition is no longer used as the match data, hw_type is 
used.

The last suggestion was getting the register base address from the DT 
and it has to be added into the offset of SPMI vibrator registers 
(either in the previous hard-coded format or the later the reg_filed 
data structure), so it's not appropriated to make it constant.

I don't understand this question: "How do you support multiple devices?" 
For SSBI vibrator, since all the registers are fixed, and I would assume 
that there is no chance to support multiple vibrator devices on the same 
SSBI bus. If they are not on the same bus, the regmap device will be 
different while the registers definition is the same, and we are still 
able to support multiple devices, right?
The similar story for SPMI vibrators and it can support multiple devices 
if they are located on different SPMI bus, or even if they are on the 
same SPMI bus but just having different SID or PID.

> ...
> 
>>   
>>   	/*
>>   	 * pmic vibrator supports voltage ranges from 1.2 to 3.1V, so
>> @@ -168,38 +166,65 @@ static int pm8xxx_vib_probe(struct platform_device *pdev)
>>   {
>>   	struct pm8xxx_vib *vib;
>>   	struct input_dev *input_dev;
>> -	int error;
>> +	struct device *dev = &pdev->dev;
>> +	struct regmap *regmap;
>> +	struct reg_field *regs;
>> +	int error, i;
>>   	unsigned int val;
>> -	const struct pm8xxx_regs *regs;
>> +	u32 reg_base;
>>   
>> -	vib = devm_kzalloc(&pdev->dev, sizeof(*vib), GFP_KERNEL);
>> +	vib = devm_kzalloc(dev, sizeof(*vib), GFP_KERNEL);
> 
> Not really related. Split cleanup from new features.
Okay, will keep as it is.
> 
>>   	if (!vib)
>>   		return -ENOMEM;
>>   
>> -	vib->regmap = dev_get_regmap(pdev->dev.parent, NULL);
>> -	if (!vib->regmap)
>> +	regmap = dev_get_regmap(dev->parent, NULL);
>> +	if (!regmap)
>>   		return -ENODEV;
>>   
>> -	input_dev = devm_input_allocate_device(&pdev->dev);
>> +	input_dev = devm_input_allocate_device(dev);
>>   	if (!input_dev)
>>   		return -ENOMEM;
>>   
>>   	INIT_WORK(&vib->work, pm8xxx_work_handler);
>>   	vib->vib_input_dev = input_dev;
>>   
>> -	regs = of_device_get_match_data(&pdev->dev);
>> +	vib->hw_type = (enum pm8xxx_vib_type)of_device_get_match_data(dev);
>>   
>> -	/* operate in manual mode */
>> -	error = regmap_read(vib->regmap, regs->drv_addr, &val);
>> +	regs = ssbi_vib_regs;
>> +	if (vib->hw_type != SSBI_VIB) {
>> +		error = fwnode_property_read_u32(dev->fwnode, "reg", &reg_base);
>> +		if (error < 0) {
>> +			dev_err(dev, "Failed to read reg address, rc=%d\n", error);
>> +			return error;
>> +		}
>> +
>> +		if (vib->hw_type == SPMI_VIB_GEN1)
>> +			regs = spmi_vib_gen1_regs;
>> +
>> +		for (i = 0; i < VIB_MAX_REG; i++)
>> +			if (regs[i].reg != 0)
>> +				regs[i].reg += reg_base;
>> +	}
>> +
>> +	error = devm_regmap_field_bulk_alloc(dev, regmap, vib->r_fields, regs, VIB_MAX_REG);
>>   	if (error < 0)
>> +	{
> 
> That's not a Linux coding style.
> 
> Please run scripts/checkpatch.pl and fix reported warnings. Some
> warnings can be ignored, but the code here looks like it needs a fix.
> Feel free to get in touch if the warning is not clear.
> 
>> +		dev_err(dev, "Failed to allocate regmap failed, rc=%d\n", error);
> 
> No need to print errors on allocation failures.
> 
Will fix it.
Thanks

>>   		return error;
>> +	}
>>   
>> -	val &= regs->drv_en_manual_mask;
>> -	error = regmap_write(vib->regmap, regs->drv_addr, val);
>> +	error = regmap_field_read(vib->r_fields[VIB_DRV_REG], &val);
>>   	if (error < 0)
>>   		return error;
> 
> 
> Best regards,
> Krzysztof
> 

Re: [PATCH v3 2/3] dt-bindings: input: qcom,pm8xxx-vib: add new SPMI vibrator module

[Fenglin Wu]

On 7/25/2023 1:53 PM, Krzysztof Kozlowski wrote:
> On 25/07/2023 07:41, Fenglin Wu wrote:
>> Add compatible string 'qcom,spmi-vib-gen2' for vibrator module inside
>> PMI632, PMI7250B, PM7325B, PM7550BA. Also, add 'qcom,spmi-vib-gen1'
>> string for the SPMI vibrator inside PM8916 to maintain the completeness
>> of the hardware version history for SPMI vibrators.
>>
>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>> ---
>>   .../bindings/input/qcom,pm8xxx-vib.yaml        | 18 ++++++++++++++----
>>   1 file changed, 14 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>> index c8832cd0d7da..ab778714ad29 100644
>> --- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>> +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>> @@ -11,10 +11,20 @@ maintainers:
>>   
>>   properties:
>>     compatible:
>> -    enum:
>> -      - qcom,pm8058-vib
>> -      - qcom,pm8916-vib
>> -      - qcom,pm8921-vib
>> +    oneOf:
>> +      - enum:
>> +          - qcom,pm8058-vib
>> +          - qcom,pm8916-vib
>> +          - qcom,pm8921-vib
>> +          - qcom,spmi-vib-gen1
>> +          - qcom,spmi-vib-gen2
> 
> Generic compatibles should not be alone. Drop both lines.

Sure. I will remove 'qcom,spmi-vib-gen2'.
Should I also keep 'qcom,spmi-vib-gen1' as generic compatible and move 
'qcom,pm8916-vib' as its fallback as following?

   compatible:
     oneOf:
       - enum:
           - qcom,pm8058-vib
           - qcom,pm8921-vib
       - items:
           - enum:
               - qcom,pm8916-vib
           - const: qcom,spmi-vib-gen1
       - items:
           - enum:
               - qcom,pmi632-vib
               - qcom,pm7250b-vib
               - qcom,pm7325b-vib
               - qcom,pm7550b-vib
           - const: qcom,spmi-vib-gen2

I saw 'qcom,pm8916-vib' has been used in multiple DTS files and updating 
it as a fallback will result updating those DTS files as well.
Or please help to suggest if there is any way to keep 'qcom,pm8916-vib' 
and 'qcom,spmi-vib-gen1' compatible without updating existing DTS nodes.

Thanks

> 
>> +      - items:
>> +          - enum:
>> +              - qcom,pmi632-vib
>> +              - qcom,pm7250b-vib
>> +              - qcom,pm7325b-vib
>> +              - qcom,pm7550b-vib
>> +          - const: qcom,spmi-vib-gen2
> 
> 
> Best regards,
> Krzysztof
> 

Re: [PATCH v3 1/3] input: pm8xxx-vib: refactor to easily support new SPMI vibrator

[kernel test robot]

Hi Fenglin,

kernel test robot noticed the following build warnings:

[auto build test WARNING on dtor-input/next]
[also build test WARNING on dtor-input/for-linus linus/master v6.5-rc3 next-20230725]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Fenglin-Wu/input-pm8xxx-vib-refactor-to-easily-support-new-SPMI-vibrator/20230725-134504
base:   https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
patch link:    https://lore.kernel.org/r/20230725054138.129497-2-quic_fenglinw%40quicinc.com
patch subject: [PATCH v3 1/3] input: pm8xxx-vib: refactor to easily support new SPMI vibrator
config: x86_64-buildonly-randconfig-r002-20230725 (https://download.01.org/0day-ci/archive/20230725/202307251741.PMtlVAgD-lkp@intel.com/config)
compiler: clang version 15.0.7 (https://github.com/llvm/llvm-project.git 8dfdcc7b7bf66834a761bd8de445840ef68e4d1a)
reproduce: (https://download.01.org/0day-ci/archive/20230725/202307251741.PMtlVAgD-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202307251741.PMtlVAgD-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> drivers/input/misc/pm8xxx-vibrator.c:190:17: warning: cast to smaller integer type 'enum pm8xxx_vib_type' from 'const void *' [-Wvoid-pointer-to-enum-cast]
           vib->hw_type = (enum pm8xxx_vib_type)of_device_get_match_data(dev);
                          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   1 warning generated.


vim +190 drivers/input/misc/pm8xxx-vibrator.c

   163	
   164	static int pm8xxx_vib_probe(struct platform_device *pdev)
   165	{
   166		struct pm8xxx_vib *vib;
   167		struct input_dev *input_dev;
   168		struct device *dev = &pdev->dev;
   169		struct regmap *regmap;
   170		struct reg_field *regs;
   171		int error, i;
   172		unsigned int val;
   173		u32 reg_base;
   174	
   175		vib = devm_kzalloc(dev, sizeof(*vib), GFP_KERNEL);
   176		if (!vib)
   177			return -ENOMEM;
   178	
   179		regmap = dev_get_regmap(dev->parent, NULL);
   180		if (!regmap)
   181			return -ENODEV;
   182	
   183		input_dev = devm_input_allocate_device(dev);
   184		if (!input_dev)
   185			return -ENOMEM;
   186	
   187		INIT_WORK(&vib->work, pm8xxx_work_handler);
   188		vib->vib_input_dev = input_dev;
   189	
 > 190		vib->hw_type = (enum pm8xxx_vib_type)of_device_get_match_data(dev);
   191	
   192		regs = ssbi_vib_regs;
   193		if (vib->hw_type != SSBI_VIB) {
   194			error = fwnode_property_read_u32(dev->fwnode, "reg", &reg_base);
   195			if (error < 0) {
   196				dev_err(dev, "Failed to read reg address, rc=%d\n", error);
   197				return error;
   198			}
   199	
   200			if (vib->hw_type == SPMI_VIB_GEN1)
   201				regs = spmi_vib_gen1_regs;
   202	
   203			for (i = 0; i < VIB_MAX_REG; i++)
   204				if (regs[i].reg != 0)
   205					regs[i].reg += reg_base;
   206		}
   207	
   208		error = devm_regmap_field_bulk_alloc(dev, regmap, vib->r_fields, regs, VIB_MAX_REG);
   209		if (error < 0)
   210		{
   211			dev_err(dev, "Failed to allocate regmap failed, rc=%d\n", error);
   212			return error;
   213		}
   214	
   215		error = regmap_field_read(vib->r_fields[VIB_DRV_REG], &val);
   216		if (error < 0)
   217			return error;
   218	
   219		/* operate in manual mode */
   220		if (vib->hw_type == SSBI_VIB) {
   221			val &= SSBI_VIB_DRV_EN_MANUAL_MASK;
   222			error = regmap_field_write(vib->r_fields[VIB_DRV_REG], val);
   223			if (error < 0)
   224				return error;
   225		}
   226	
   227		vib->reg_vib_drv = val;
   228	
   229		input_dev->name = "pm8xxx_vib_ffmemless";
   230		input_dev->id.version = 1;
   231		input_dev->close = pm8xxx_vib_close;
   232		input_set_drvdata(input_dev, vib);
   233		input_set_capability(vib->vib_input_dev, EV_FF, FF_RUMBLE);
   234	
   235		error = input_ff_create_memless(input_dev, NULL,
   236						pm8xxx_vib_play_effect);
   237		if (error) {
   238			dev_err(dev, "couldn't register vibrator as FF device\n");
   239			return error;
   240		}
   241	
   242		error = input_register_device(input_dev);
   243		if (error) {
   244			dev_err(dev, "couldn't register input device\n");
   245			return error;
   246		}
   247	
   248		platform_set_drvdata(pdev, vib);
   249		return 0;
   250	}
   251	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH v3 1/3] input: pm8xxx-vib: refactor to easily support new SPMI vibrator

[Krzysztof Kozlowski]

On 25/07/2023 08:16, Fenglin Wu wrote:
>>>   
>>> -static const struct pm8xxx_regs pm8058_regs = {
>>> -	.drv_addr = 0x4A,
>>> -	.drv_mask = 0xf8,
>>> -	.drv_shift = 3,
>>> -	.drv_en_manual_mask = 0xfc,
>>> +static struct reg_field ssbi_vib_regs[VIB_MAX_REG] = {
>>
>> Change from const to non-const is wrong. How do you support multiple
>> devices? No, this is way too fragile now.
>>
> 
> The register definition is no longer used as the match data, hw_type is 
> used.
> 
> The last suggestion was getting the register base address from the DT 
> and it has to be added into the offset of SPMI vibrator registers 
> (either in the previous hard-coded format or the later the reg_filed 
> data structure), so it's not appropriated to make it constant.
> 
> I don't understand this question: "How do you support multiple devices?" 
> For SSBI vibrator, since all the registers are fixed, and I would assume 
> that there is no chance to support multiple vibrator devices on the same 
> SSBI bus. If they are not on the same bus, the regmap device will be 
> different while the registers definition is the same, and we are still 
> able to support multiple devices, right?

No, you have static memory. One device probes and changes static memory
to reg+=base1. Second device probes and changes the same to reg+=base2.

> The similar story for SPMI vibrators and it can support multiple devices 
> if they are located on different SPMI bus, or even if they are on the 
> same SPMI bus but just having different SID or PID.

Sorry, such code cannot go in. These must stay const and you must write
driver without any static allocations or singleton-like patterns.


Best regards,
Krzysztof

Re: [PATCH v3 1/3] input: pm8xxx-vib: refactor to easily support new SPMI vibrator

[Krzysztof Kozlowski]

On 25/07/2023 12:01, kernel test robot wrote:
> Hi Fenglin,
> 
> kernel test robot noticed the following build warnings:
> 
> [auto build test WARNING on dtor-input/next]
> [also build test WARNING on dtor-input/for-linus linus/master v6.5-rc3 next-20230725]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
> 
> url:    https://github.com/intel-lab-lkp/linux/commits/Fenglin-Wu/input-pm8xxx-vib-refactor-to-easily-support-new-SPMI-vibrator/20230725-134504
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
> patch link:    https://lore.kernel.org/r/20230725054138.129497-2-quic_fenglinw%40quicinc.com
> patch subject: [PATCH v3 1/3] input: pm8xxx-vib: refactor to easily support new SPMI vibrator
> config: x86_64-buildonly-randconfig-r002-20230725 (https://download.01.org/0day-ci/archive/20230725/202307251741.PMtlVAgD-lkp@intel.com/config)
> compiler: clang version 15.0.7 (https://github.com/llvm/llvm-project.git 8dfdcc7b7bf66834a761bd8de445840ef68e4d1a)
> reproduce: (https://download.01.org/0day-ci/archive/20230725/202307251741.PMtlVAgD-lkp@intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202307251741.PMtlVAgD-lkp@intel.com/
> 
> All warnings (new ones prefixed by >>):
> 
>>> drivers/input/misc/pm8xxx-vibrator.c:190:17: warning: cast to smaller integer type 'enum pm8xxx_vib_type' from 'const void *' [-Wvoid-pointer-to-enum-cast]
>            vib->hw_type = (enum pm8xxx_vib_type)of_device_get_match_data(dev);
>                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    1 warning generated.
> 

Remember to fix all the warnings.

Best regards,
Krzysztof

Re: [PATCH v3 2/3] dt-bindings: input: qcom,pm8xxx-vib: add new SPMI vibrator module

[Krzysztof Kozlowski]

On 25/07/2023 08:26, Fenglin Wu wrote:
> 
> 
> On 7/25/2023 1:53 PM, Krzysztof Kozlowski wrote:
>> On 25/07/2023 07:41, Fenglin Wu wrote:
>>> Add compatible string 'qcom,spmi-vib-gen2' for vibrator module inside
>>> PMI632, PMI7250B, PM7325B, PM7550BA. Also, add 'qcom,spmi-vib-gen1'
>>> string for the SPMI vibrator inside PM8916 to maintain the completeness
>>> of the hardware version history for SPMI vibrators.
>>>
>>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>>> ---
>>>   .../bindings/input/qcom,pm8xxx-vib.yaml        | 18 ++++++++++++++----
>>>   1 file changed, 14 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>>> index c8832cd0d7da..ab778714ad29 100644
>>> --- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>>> +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>>> @@ -11,10 +11,20 @@ maintainers:
>>>   
>>>   properties:
>>>     compatible:
>>> -    enum:
>>> -      - qcom,pm8058-vib
>>> -      - qcom,pm8916-vib
>>> -      - qcom,pm8921-vib
>>> +    oneOf:
>>> +      - enum:
>>> +          - qcom,pm8058-vib
>>> +          - qcom,pm8916-vib
>>> +          - qcom,pm8921-vib
>>> +          - qcom,spmi-vib-gen1
>>> +          - qcom,spmi-vib-gen2
>>
>> Generic compatibles should not be alone. Drop both lines.
> 
> Sure. I will remove 'qcom,spmi-vib-gen2'.
> Should I also keep 'qcom,spmi-vib-gen1' as generic compatible and move 
> 'qcom,pm8916-vib' as its fallback as following?

I would drop all of generic ones. Entirely remove qcom,spmi-vib-gen2 and
qcom,spmi-vib-gen1.

Use device specific compatibles names only. As fallback and as first
compatible.

Best regards,
Krzysztof

Re: [PATCH v3 1/3] input: pm8xxx-vib: refactor to easily support new SPMI vibrator

[Fenglin Wu]

On 7/27/2023 3:07 PM, Krzysztof Kozlowski wrote:
> On 25/07/2023 08:16, Fenglin Wu wrote:
>>>>    
>>>> -static const struct pm8xxx_regs pm8058_regs = {
>>>> -	.drv_addr = 0x4A,
>>>> -	.drv_mask = 0xf8,
>>>> -	.drv_shift = 3,
>>>> -	.drv_en_manual_mask = 0xfc,
>>>> +static struct reg_field ssbi_vib_regs[VIB_MAX_REG] = {
>>>
>>> Change from const to non-const is wrong. How do you support multiple
>>> devices? No, this is way too fragile now.
>>>
>>
>> The register definition is no longer used as the match data, hw_type is
>> used.
>>
>> The last suggestion was getting the register base address from the DT
>> and it has to be added into the offset of SPMI vibrator registers
>> (either in the previous hard-coded format or the later the reg_filed
>> data structure), so it's not appropriated to make it constant.
>>
>> I don't understand this question: "How do you support multiple devices?"
>> For SSBI vibrator, since all the registers are fixed, and I would assume
>> that there is no chance to support multiple vibrator devices on the same
>> SSBI bus. If they are not on the same bus, the regmap device will be
>> different while the registers definition is the same, and we are still
>> able to support multiple devices, right?
> 
> No, you have static memory. One device probes and changes static memory
> to reg+=base1. Second device probes and changes the same to reg+=base2.

Thanks, got it.  I can update it with following 2 options:

1) keep the register definition in 'reg_filed' data structure and make 
it constant, copy it to a dynamically allocated memory before adding the 
'reg_base' to the '.reg' variable.

2) Define the register offsets as constant data and add the 'reg_base' 
to the 'reg' while using 'regmap_read()'/'regmap_write()' functions.

which one is the preferred way?

> 
>> The similar story for SPMI vibrators and it can support multiple devices
>> if they are located on different SPMI bus, or even if they are on the
>> same SPMI bus but just having different SID or PID.
> 
> Sorry, such code cannot go in. These must stay const and you must write
> driver without any static allocations or singleton-like patterns.
> 
> 
> Best regards,
> Krzysztof
> 

Re: [PATCH v3 1/3] input: pm8xxx-vib: refactor to easily support new SPMI vibrator

[Krzysztof Kozlowski]

On 27/07/2023 09:43, Fenglin Wu wrote:
> 
> 
> On 7/27/2023 3:07 PM, Krzysztof Kozlowski wrote:
>> On 25/07/2023 08:16, Fenglin Wu wrote:
>>>>>    
>>>>> -static const struct pm8xxx_regs pm8058_regs = {
>>>>> -	.drv_addr = 0x4A,
>>>>> -	.drv_mask = 0xf8,
>>>>> -	.drv_shift = 3,
>>>>> -	.drv_en_manual_mask = 0xfc,
>>>>> +static struct reg_field ssbi_vib_regs[VIB_MAX_REG] = {
>>>>
>>>> Change from const to non-const is wrong. How do you support multiple
>>>> devices? No, this is way too fragile now.
>>>>
>>>
>>> The register definition is no longer used as the match data, hw_type is
>>> used.
>>>
>>> The last suggestion was getting the register base address from the DT
>>> and it has to be added into the offset of SPMI vibrator registers
>>> (either in the previous hard-coded format or the later the reg_filed
>>> data structure), so it's not appropriated to make it constant.
>>>
>>> I don't understand this question: "How do you support multiple devices?"
>>> For SSBI vibrator, since all the registers are fixed, and I would assume
>>> that there is no chance to support multiple vibrator devices on the same
>>> SSBI bus. If they are not on the same bus, the regmap device will be
>>> different while the registers definition is the same, and we are still
>>> able to support multiple devices, right?
>>
>> No, you have static memory. One device probes and changes static memory
>> to reg+=base1. Second device probes and changes the same to reg+=base2.
> 
> Thanks, got it.  I can update it with following 2 options:
> 
> 1) keep the register definition in 'reg_filed' data structure and make 
> it constant, copy it to a dynamically allocated memory before adding the 
> 'reg_base' to the '.reg' variable.
> 
> 2) Define the register offsets as constant data and add the 'reg_base' 
> to the 'reg' while using 'regmap_read()'/'regmap_write()' functions.
> 
> which one is the preferred way?

Depends on the code. I am not sure if 2 would work with regmap_fields.
OTOH, I wonder if the device could just create its own regmap instead of
using parents? Then there would be no need of this offset dance.

Anyway, adding offset only for some variants seems also not needed. You
should add offset to each variant, because each device has this offset.

Best regards,
Krzysztof

Re: [PATCH v3 1/3] input: pm8xxx-vib: refactor to easily support new SPMI vibrator

[Fenglin Wu]

On 7/27/2023 5:22 PM, Krzysztof Kozlowski wrote:
> On 27/07/2023 09:43, Fenglin Wu wrote:
>>
>>
>> On 7/27/2023 3:07 PM, Krzysztof Kozlowski wrote:
>>> On 25/07/2023 08:16, Fenglin Wu wrote:
>>>>>>     
>>>>>> -static const struct pm8xxx_regs pm8058_regs = {
>>>>>> -	.drv_addr = 0x4A,
>>>>>> -	.drv_mask = 0xf8,
>>>>>> -	.drv_shift = 3,
>>>>>> -	.drv_en_manual_mask = 0xfc,
>>>>>> +static struct reg_field ssbi_vib_regs[VIB_MAX_REG] = {
>>>>>
>>>>> Change from const to non-const is wrong. How do you support multiple
>>>>> devices? No, this is way too fragile now.
>>>>>
>>>>
>>>> The register definition is no longer used as the match data, hw_type is
>>>> used.
>>>>
>>>> The last suggestion was getting the register base address from the DT
>>>> and it has to be added into the offset of SPMI vibrator registers
>>>> (either in the previous hard-coded format or the later the reg_filed
>>>> data structure), so it's not appropriated to make it constant.
>>>>
>>>> I don't understand this question: "How do you support multiple devices?"
>>>> For SSBI vibrator, since all the registers are fixed, and I would assume
>>>> that there is no chance to support multiple vibrator devices on the same
>>>> SSBI bus. If they are not on the same bus, the regmap device will be
>>>> different while the registers definition is the same, and we are still
>>>> able to support multiple devices, right?
>>>
>>> No, you have static memory. One device probes and changes static memory
>>> to reg+=base1. Second device probes and changes the same to reg+=base2.
>>
>> Thanks, got it.  I can update it with following 2 options:
>>
>> 1) keep the register definition in 'reg_filed' data structure and make
>> it constant, copy it to a dynamically allocated memory before adding the
>> 'reg_base' to the '.reg' variable.
>>
>> 2) Define the register offsets as constant data and add the 'reg_base'
>> to the 'reg' while using 'regmap_read()'/'regmap_write()' functions.
>>
>> which one is the preferred way?
> 
> Depends on the code. I am not sure if 2 would work with regmap_fields.
> OTOH, I wonder if the device could just create its own regmap instead of
> using parents? Then there would be no need of this offset dance.
> 
> Anyway, adding offset only for some variants seems also not needed. You
> should add offset to each variant, because each device has this offset.
> 
> Best regards,
> Krzysztof
> Thanks for the suggestion.

The Qualcomm SPMI device has to use the 'regmap' from its parent with 16 
'reg_bits' and 8 'val_bits' config, the higher 8-bit 'reg_bits' is the 
peripheral ID (PID) and it could be different in different PMICs even 
for the same type of HW module, and (PID << 8) is the 'reg_base' here.

I assume that you are not in favor of copying the constant data into a 
dynamic allocated memory, so I will go with option 2.
Thanks