mbox series

[RFC,v3,0/7] i2c: Enabling use of aspeed-i2c with ACPI

Message ID 20230531100600.13543-1-Jonathan.Cameron@huawei.com
Headers show
Series i2c: Enabling use of aspeed-i2c with ACPI | expand

Message

Jonathan Cameron May 31, 2023, 10:05 a.m. UTC
v3:
 - More improvements from Andy, called out in the individual patches.

Obviously I am sending this much quicker than would normally make sense.

Whilst Andy was kind enough to provide review I never really expected
anyone to look at these in depth, I just needed them public so I could
tell people to use them. However I don't want to loose the improvements
from Andy's review.

Hence still RFC though if people like the first 6 patches, they may be
worth picking up anyway.

I'm planning to forget about these entirely for a few weeks at least
and work on the other parts of the stack this enables and a general
huge backlog of things I've been ignoring.

Comments

Andy Shevchenko May 31, 2023, 5:45 p.m. UTC | #1
On Wed, May 31, 2023 at 1:08 PM Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
>
> Moving over to generic firmware properties allows this driver to
> get closer to working out of the box with both device tree and
> other firmware options, such as ACPI via PRP0001.
>
> Tested only via QEMU emulation.

...

>  static int aspeed_i2c_probe_bus(struct platform_device *pdev)
>  {
> -       const struct of_device_id *match;

With

  struct device *dev = &pdev->dev;

...

> +       device_property_read_u32(&pdev->dev,
> +                                "bus-frequency", &bus->bus_frequency);

This can take one or both parameters on one line.

...

> +       bus->get_clk_reg_val =
> +               (aspeed_get_clk_reg_val_cb)device_get_match_data(&pdev->dev);

This one as well I believe.

Also others, but it can be done in a separate patch.
Jonathan Cameron June 1, 2023, 9:08 a.m. UTC | #2
On Wed, 31 May 2023 20:45:08 +0300
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Wed, May 31, 2023 at 1:08 PM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> >
> > Moving over to generic firmware properties allows this driver to
> > get closer to working out of the box with both device tree and
> > other firmware options, such as ACPI via PRP0001.
> >
> > Tested only via QEMU emulation.  
> 
> ...
> 
> >  static int aspeed_i2c_probe_bus(struct platform_device *pdev)
> >  {
> > -       const struct of_device_id *match;  
> 
> With
> 
>   struct device *dev = &pdev->dev;
> 
> ...
> 
> > +       device_property_read_u32(&pdev->dev,
> > +                                "bus-frequency", &bus->bus_frequency);  
> 
> This can take one or both parameters on one line.
> 
> ...
> 
> > +       bus->get_clk_reg_val =
> > +               (aspeed_get_clk_reg_val_cb)device_get_match_data(&pdev->dev);  
> 
> This one as well I believe.
> 
> Also others, but it can be done in a separate patch.
> 

I thought about it, but decided out of scope for this set.
I'm not aiming for too much general tidying!

Jonathan