Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1678362 > unrolled thread

[PATCH 5/6] i2c: pca-platform: use device_property_read_u32

Started byChris Packham <chris.packham@alliedtelesis.co.nz>
First post2017-06-30 03:00 +0200
Last post2017-07-04 16:10 +0200
Articles 6 — 4 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 5/6] i2c: pca-platform: use device_property_read_u32 Chris Packham <chris.packham@alliedtelesis.co.nz> - 2017-06-30 03:00 +0200
    Re: [PATCH 5/6] i2c: pca-platform: use device_property_read_u32 Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-06-30 10:50 +0200
      Re: [PATCH 5/6] i2c: pca-platform: use device_property_read_u32 Wolfram Sang <wsa@the-dreams.de> - 2017-06-30 11:10 +0200
        Re: [PATCH 5/6] i2c: pca-platform: use device_property_read_u32 Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-06-30 13:00 +0200
          Re: [PATCH 5/6] i2c: pca-platform: use device_property_read_u32 Chris Packham <Chris.Packham@alliedtelesis.co.nz> - 2017-07-03 00:00 +0200
            Re: [PATCH 5/6] i2c: pca-platform: use device_property_read_u32 Wolfram Sang <wsa@the-dreams.de> - 2017-07-04 16:10 +0200

#1678362 — [PATCH 5/6] i2c: pca-platform: use device_property_read_u32

FromChris Packham <chris.packham@alliedtelesis.co.nz>
Date2017-06-30 03:00 +0200
Subject[PATCH 5/6] i2c: pca-platform: use device_property_read_u32
Message-ID<tXSrT-6F8-11@gated-at.bofh.it>
Use device_property_read_u32 instead of of_property_read_u32_index to
lookup the "clock-frequency" property.

Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
 drivers/i2c/busses/i2c-pca-platform.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/i2c/busses/i2c-pca-platform.c b/drivers/i2c/busses/i2c-pca-platform.c
index 1e3c247de8f8..80420f753a87 100644
--- a/drivers/i2c/busses/i2c-pca-platform.c
+++ b/drivers/i2c/busses/i2c-pca-platform.c
@@ -176,13 +176,12 @@ static int i2c_pca_pf_probe(struct platform_device *pdev)
 	if (platform_data) {
 		i2c->adap.timeout = platform_data->timeout;
 		i2c->algo_data.i2c_clock = platform_data->i2c_clock_speed;
-	} else if (np) {
-		i2c->adap.timeout = HZ;
-		of_property_read_u32_index(np, "clock-frequency", 0,
-					   &i2c->algo_data.i2c_clock);
 	} else {
 		i2c->adap.timeout = HZ;
-		i2c->algo_data.i2c_clock = 59000;
+		ret = device_property_read_u32(&pdev->dev, "clock-frequency",
+					       &i2c->algo_data.i2c_clock);
+		if (ret)
+			i2c->algo_data.i2c_clock = 59000;
 	}
 
 	i2c->gpio = devm_gpiod_get_optional(&pdev->dev, "reset-gpios", GPIOD_OUT_LOW);
-- 
2.13.0

[toc] | [next] | [standalone]

#1678601

FromAndy Shevchenko <andy.shevchenko@gmail.com>
Date2017-06-30 10:50 +0200
Message-ID<tXZMJ-39Q-13@gated-at.bofh.it>
In reply to#1678362
On Fri, Jun 30, 2017 at 3:54 AM, Chris Packham
<chris.packham@alliedtelesis.co.nz> wrote:
> Use device_property_read_u32 instead of of_property_read_u32_index to
> lookup the "clock-frequency" property.

My comments below.

>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
>  drivers/i2c/busses/i2c-pca-platform.c | 9 ++++-----
>  1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-pca-platform.c b/drivers/i2c/busses/i2c-pca-platform.c
> index 1e3c247de8f8..80420f753a87 100644
> --- a/drivers/i2c/busses/i2c-pca-platform.c
> +++ b/drivers/i2c/busses/i2c-pca-platform.c
> @@ -176,13 +176,12 @@ static int i2c_pca_pf_probe(struct platform_device *pdev)

>         if (platform_data) {
>                 i2c->adap.timeout = platform_data->timeout;
>                 i2c->algo_data.i2c_clock = platform_data->i2c_clock_speed;

>         } else {
>                 i2c->adap.timeout = HZ;
> -               i2c->algo_data.i2c_clock = 59000;
> +               ret = device_property_read_u32(&pdev->dev, "clock-frequency",
> +                                              &i2c->algo_data.i2c_clock);
> +               if (ret)
> +                       i2c->algo_data.i2c_clock = 59000;

My idea is to get rid of legacy platform data completely.
That's why I suggested device_* in the first place.

In similar way like you did with GPIO lookup table, you may use
PROPERTY_ENTRY*() macros in the board files.

Does it make sense?

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1678613

FromWolfram Sang <wsa@the-dreams.de>
Date2017-06-30 11:10 +0200
Message-ID<tY066-3v8-3@gated-at.bofh.it>
In reply to#1678601

[Multipart message — attachments visible in raw view] — view raw

> > -               i2c->algo_data.i2c_clock = 59000;
> > +               ret = device_property_read_u32(&pdev->dev, "clock-frequency",
> > +                                              &i2c->algo_data.i2c_clock);
> > +               if (ret)
> > +                       i2c->algo_data.i2c_clock = 59000;
> 
> My idea is to get rid of legacy platform data completely.
> That's why I suggested device_* in the first place.
> 
> In similar way like you did with GPIO lookup table, you may use
> PROPERTY_ENTRY*() macros in the board files.
> 
> Does it make sense?

Frankly, I am not a big fan of converting board files if we cannot test
the changes.

[toc] | [prev] | [next] | [standalone]

#1678694

FromAndy Shevchenko <andy.shevchenko@gmail.com>
Date2017-06-30 13:00 +0200
Message-ID<tY1Ox-4rm-7@gated-at.bofh.it>
In reply to#1678613
On Fri, Jun 30, 2017 at 12:03 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
>
>> > -               i2c->algo_data.i2c_clock = 59000;
>> > +               ret = device_property_read_u32(&pdev->dev, "clock-frequency",
>> > +                                              &i2c->algo_data.i2c_clock);
>> > +               if (ret)
>> > +                       i2c->algo_data.i2c_clock = 59000;
>>
>> My idea is to get rid of legacy platform data completely.
>> That's why I suggested device_* in the first place.
>>
>> In similar way like you did with GPIO lookup table, you may use
>> PROPERTY_ENTRY*() macros in the board files.
>>
>> Does it make sense?
>
> Frankly, I am not a big fan of converting board files if we cannot test
> the changes.

So, if no one is using that old boards, should we really take care
more than just compile test?

P.S. Legacy platform data makes a burden of development nowadays.
Built-in device properties API (as a part of Unified Device
Properties) is exactly for getting rid of legacy stuff and make things
much cleaner.

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1679571

FromChris Packham <Chris.Packham@alliedtelesis.co.nz>
Date2017-07-03 00:00 +0200
Message-ID<tYV4l-88R-17@gated-at.bofh.it>
In reply to#1678694
On 30/06/17 22:56, Andy Shevchenko wrote:
> On Fri, Jun 30, 2017 at 12:03 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
>>
>>>> -               i2c->algo_data.i2c_clock = 59000;
>>>> +               ret = device_property_read_u32(&pdev->dev, "clock-frequency",
>>>> +                                              &i2c->algo_data.i2c_clock);
>>>> +               if (ret)
>>>> +                       i2c->algo_data.i2c_clock = 59000;
>>>
>>> My idea is to get rid of legacy platform data completely.
>>> That's why I suggested device_* in the first place.
>>>
>>> In similar way like you did with GPIO lookup table, you may use
>>> PROPERTY_ENTRY*() macros in the board files.
>>>
>>> Does it make sense?
>>
>> Frankly, I am not a big fan of converting board files if we cannot test
>> the changes.
> 
> So, if no one is using that old boards, should we really take care
> more than just compile test?
> 
> P.S. Legacy platform data makes a burden of development nowadays.
> Built-in device properties API (as a part of Unified Device
> Properties) is exactly for getting rid of legacy stuff and make things
> much cleaner.

We could probably go with an approach of making the device properties 
the default which would suit the new style and leave the platform_data 
to override things if it is present.

If/when the older platforms go away we can drop struct 
i2c_pca9564_pf_platform_data.

[toc] | [prev] | [next] | [standalone]

#1681001

FromWolfram Sang <wsa@the-dreams.de>
Date2017-07-04 16:10 +0200
Message-ID<tZwGC-Oa-31@gated-at.bofh.it>
In reply to#1679571

[Multipart message — attachments visible in raw view] — view raw

> >> Frankly, I am not a big fan of converting board files if we cannot test
> >> the changes.
> > 
> > So, if no one is using that old boards, should we really take care
> > more than just compile test?
> > 
> > P.S. Legacy platform data makes a burden of development nowadays.
> > Built-in device properties API (as a part of Unified Device
> > Properties) is exactly for getting rid of legacy stuff and make things
> > much cleaner.
> 
> We could probably go with an approach of making the device properties 
> the default which would suit the new style and leave the platform_data 
> to override things if it is present.
> 
> If/when the older platforms go away we can drop struct 
> i2c_pca9564_pf_platform_data.

I don't have a super strong opinion, so we can discuss this for 4.14.
For 4.13, I picked the two easy patches already. Thanks!

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web