All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: <linux-i2c@vger.kernel.org>, Wolfram Sang <wsa@kernel.org>,
	Niyas Sait <niyas.sait@linaro.org>,
	Klaus Jensen <its@irrelevant.dk>,
	Andy Shevchenko <andy@kernel.org>, <linux-acpi@vger.kernel.org>,
	Jeremy Kerr <jk@codeconstruct.com.au>,
	Matt Johnston <matt@codeconstruct.com.au>,
	Shesha Bhushan Sreenivasamurthy <sheshas@marvell.com>,
	<linux-cxl@vger.kernel.org>, <linuxarm@huawei.com>,
	"Viacheslav A . Dubeyko" <viacheslav.dubeyko@bytedance.com>
Subject: Re: [RFC PATCH 3/6] i2c: aspeed: switch to generic fw properties.
Date: Tue, 30 May 2023 15:16:48 +0100	[thread overview]
Message-ID: <20230530151648.00007d32@Huawei.com> (raw)
In-Reply-To: <CAHp75Vd3ARzzWjWV=cRRghHKXMFWkrRXBa2ssCGRCZAqDEAjAA@mail.gmail.com>

On Sat, 27 May 2023 00:11:09 +0300
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Thu, May 25, 2023 at 6:23 PM Jonathan Cameron
> <Jonathan.Cameron@huawei.com> wrote:
> >
> > Not tested on device tree but works nicely for ACPI :)  

I was planning to abandon these as 'on list for anyone who
cared' but now you've reviewed them I guess I better do
an RFC v2 :)

> 
> Needs a better commit message obviously :-)

:)

> 
> ...
> 
> > -       ret = of_property_read_u32(pdev->dev.of_node,
> > +       ret = device_property_read_u32(&pdev->dev,
> >                                    "bus-frequency", &bus->bus_frequency);  
> 
> Oh, please avoid double effort, i.e. go further and use I²C core APIs
> for the timings. Oh, wait, do they use non-standard property?!

yup :(

Though it is documented as having a default of 100kHz in the devicetree
binding so the original code shouldn't be calling dev_err() and should
just do:

	bus->frequency = I2C_MAX_STANDARD_MODE_FREQ;
	device_property_read_u32(&pdev->dev,
				 "bus-frequency, &bus->frequency);

Fixing that is an unrelated change though. I'll do it for dt
in a precusor patch then carry that forward to here.

> 
> ...
> 
> > +       bus->get_clk_reg_val = (u32 (*)(struct device *, u32))
> > +               device_get_match_data(&pdev->dev);  
> 
> Personally I prefer using pointers in driver_data so we can avoid
> ambiguity for the 0/NULL value returned by this call. But if 0 value
> is considered invalid here, it's probably fine.

It is a pointer, just a function pointer rather than to a structure.
I could wrap it up in a structure but that would be an unrelated
driver change so at very least a separate patch. 

> 
> > +       if (!bus->get_clk_reg_val)
> >                 bus->get_clk_reg_val = aspeed_i2c_24xx_get_clk_reg_val;
> > -       else
> > -               bus->get_clk_reg_val = (u32 (*)(struct device *, u32))
> > -                               match->data;  
> 
> 


  reply	other threads:[~2023-05-30 14:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-25 15:21 [RFC PATCH 0/6] i2c: Enabling use of aspeed-i2c with ACPI Jonathan Cameron
2023-05-25 15:21 ` [RFC PATCH 1/6] i2c: acpi: set slave mode flag Jonathan Cameron
2023-05-26 19:43   ` Andy Shevchenko
2023-05-25 15:21 ` [RFC PATCH 2/6] i2c: aspeed: Use platform_get_irq() instead of opencoding Jonathan Cameron
2023-05-26 21:06   ` Andy Shevchenko
2023-05-25 15:22 ` [RFC PATCH 3/6] i2c: aspeed: switch to generic fw properties Jonathan Cameron
2023-05-26 21:11   ` Andy Shevchenko
2023-05-30 14:16     ` Jonathan Cameron [this message]
2023-05-25 15:22 ` [RFC PATCH 4/6] i2c: aspeed: Set the fwnode for the adap->dev Jonathan Cameron
2023-05-26 21:13   ` Andy Shevchenko
2023-05-25 15:22 ` [RFC PATCH 5/6] HACK: i2c: aspeed: Comment the clock and reset out Jonathan Cameron
2023-05-26 21:16   ` Andy Shevchenko
2023-05-30 14:40     ` Jonathan Cameron
2023-05-26 23:36   ` kernel test robot
2023-05-25 15:22 ` [RFC PATCH 6/6] HACK: i2c: aspeed: Enable build without COMPILE_TEST Jonathan Cameron
2023-05-26 10:37   ` kernel test robot
2023-05-26 21:30   ` kernel test robot
2023-05-30 14:44   ` Jonathan Cameron
2023-05-25 16:18 ` [RFC PATCH 0/6] i2c: Enabling use of aspeed-i2c with ACPI Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230530151648.00007d32@Huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=andy@kernel.org \
    --cc=its@irrelevant.dk \
    --cc=jk@codeconstruct.com.au \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=matt@codeconstruct.com.au \
    --cc=niyas.sait@linaro.org \
    --cc=sheshas@marvell.com \
    --cc=viacheslav.dubeyko@bytedance.com \
    --cc=wsa@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.