diff mbox series

[1/2] iio: adc: aspeed: Remove the trim valid dts property.

Message ID 20221031113208.19194-1-billy_tsai@aspeedtech.com
State Accepted
Commit fdd0d6b2eb35c83d6b1226ad20b346a4b45ddfb8
Headers show
Series [1/2] iio: adc: aspeed: Remove the trim valid dts property. | expand

Commit Message

Billy Tsai Oct. 31, 2022, 11:32 a.m. UTC
The dts property "aspeed,trim-data-valid" is used to determin whether to
read the OTP register. If the image with the aspeed,trim-data-vali
install to the chip without valid trimming data the adc controller will
become confused. This patch use the default otp value 0 as a criterion
for determining whether trimming data is valid instead of the dts
property. The chip with actually trimming value is 0 should be filter out.

Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
---
 drivers/iio/adc/aspeed_adc.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

Comments

Billy Tsai Nov. 7, 2022, 2:34 a.m. UTC | #1
On 2022/11/6, 10:50 PM, "Jonathan Cameron" <jic23@kernel.org> wrote:

    On Mon, 31 Oct 2022 19:32:07 +0800
    Billy Tsai <billy_tsai@aspeedtech.com> wrote:

    > > The dts property "aspeed,trim-data-valid" is used to determin whether to
    > > read the OTP register. If the image with the aspeed,trim-data-vali
    > > install to the chip without valid trimming data the adc controller will
    > > become confused. This patch use the default otp value 0 as a criterion
    > > for determining whether trimming data is valid instead of the dts
    > > property. The chip with actually trimming value is 0 should be filter out.

    > Hi Billy,

    > I'm not sure I correctly follow the patch description.  Would the following
    > be an accurate description?

    > The dts property "aspeed,trim-data-valid" is currently used to determine
    > whether to read trimming data from the OTP register. If this is set on
    > a device without valid trimming data in the OTP the ADC will not function
    > correctly. This patch drops he use of this property and instead uses the
    > default (unprogrammed) OTP value of 0 to detect when a fallback value of
    > 0x8 should be used rather then the value read from the OTP.
Hi Jonathan,

Yes, it's correct.

    > Also, is this a bug fix we need to backport?  If so please provide a fixes
    > tag.

I will provide the fixes tag in next version of patch.

Thanks

Best Regards,
Billy Tsai
diff mbox series

Patch

diff --git a/drivers/iio/adc/aspeed_adc.c b/drivers/iio/adc/aspeed_adc.c
index ffae64f39221..0f065f0bb8e7 100644
--- a/drivers/iio/adc/aspeed_adc.c
+++ b/drivers/iio/adc/aspeed_adc.c
@@ -201,6 +201,8 @@  static int aspeed_adc_set_trim_data(struct iio_dev *indio_dev)
 				((scu_otp) &
 				 (data->model_data->trim_locate->field)) >>
 				__ffs(data->model_data->trim_locate->field);
+			if (!trimming_val)
+				trimming_val = 0x8;
 		}
 		dev_dbg(data->dev,
 			"trimming val = %d, offset = %08x, fields = %08x\n",
@@ -562,12 +564,9 @@  static int aspeed_adc_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
-	if (of_find_property(data->dev->of_node, "aspeed,trim-data-valid",
-			     NULL)) {
-		ret = aspeed_adc_set_trim_data(indio_dev);
-		if (ret)
-			return ret;
-	}
+	ret = aspeed_adc_set_trim_data(indio_dev);
+	if (ret)
+		return ret;
 
 	if (of_find_property(data->dev->of_node, "aspeed,battery-sensing",
 			     NULL)) {