From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Binbin Zhou <zhoubinbin@loongson.cn>
Cc: Wolfram Sang <wsa@kernel.org>,
Wolfram Sang <wsa+renesas@sang-engineering.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
linux-i2c@vger.kernel.org, loongarch@lists.linux.dev,
devicetree@vger.kernel.org, Huacai Chen <chenhuacai@loongson.cn>,
WANG Xuerui <kernel@xen0n.name>, Arnd Bergmann <arnd@arndb.de>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Jianmin Lv <lvjianmin@loongson.cn>
Subject: Re: [PATCH V3 4/5] i2c: ls2x: Add driver for Loongson-2K/LS7A I2C controller
Date: Fri, 25 Nov 2022 12:41:27 +0200 [thread overview]
Message-ID: <Y4Cb19PM97M9HaiB@smile.fi.intel.com> (raw)
In-Reply-To: <822356908305580d601e5b3e424371ed7f220b85.1669359515.git.zhoubinbin@loongson.cn>
On Fri, Nov 25, 2022 at 04:55:20PM +0800, Binbin Zhou wrote:
> This I2C module is integrated into the Loongson-2K SoCs and Loongson
> LS7A bridge chip.
...
Missing bits.h.
> +#include <linux/completion.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/i2c.h>
> +#include <linux/init.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
There is no user of this header.
Why?
> +#include <linux/platform_device.h>
...
> +/* LS2X I2C clock frequency 50M */
> +#define HZ_PER_MHZ (50 * 1000000)
units.h ?
...
> +struct ls2x_i2c_dev {
> + struct device *dev;
> + void __iomem *base;
> + int irq;
> + u32 bus_clk_rate;
> + struct completion cmd_complete;
> + struct i2c_adapter adapter;
Check if moving this to be the first field makes code generation better
(bloat-o-meter is your friend).
> + unsigned int suspended:1;
> +};
> + return ls2x_i2c_send_byte(adap, LS2X_CR_STOP);
> +}
...
> +static int ls2x_i2c_start(struct i2c_adapter *adap, struct i2c_msg *msgs)
> +{
> + struct ls2x_i2c_dev *dev = i2c_get_adapdata(adap);
> + unsigned char addr = i2c_8bit_addr_from_msg(msgs);
> +
> + reinit_completion(&dev->cmd_complete);
> + addr |= (msgs->flags & I2C_M_RD) ? 1 : 0;
Why is this needed?
> + writeb(addr, dev->base + I2C_LS2X_TXR);
> +
> + return ls2x_i2c_send_byte(adap, (LS2X_CR_START | LS2X_CR_WRITE));
> +}
...
> + while (len--) {
> + if (len == 0)
> + cmd |= LS2X_CR_ACK;
> +
> + writeb(cmd, dev->base + I2C_LS2X_CR);
Can be written as
writeb(cmd | (len ? 0 : LS2X_CR_ACK), dev->base + I2C_LS2X_CR);
but it's up to you.
> + time_left = wait_for_completion_timeout(&dev->cmd_complete,
> + adap->timeout);
> + if (unlikely(!time_left)) {
> + dev_err(dev->dev, "transaction timeout\n");
> + return -ETIMEDOUT;
> + }
> +
> + *buf++ = readb(dev->base + I2C_LS2X_RXR);
> + }
...
> + for (retry = 0; retry < adap->retries; retry++) {
> +
Unneeded blank line.
> + ret = ls2x_i2c_doxfer(adap, msgs, num);
> + if (ret != -EAGAIN)
> + return ret;
> +
> + dev_dbg(dev->dev, "Retrying transmission (%d)\n", retry);
> + udelay(100);
> + }
Can something from iopoll.h be utilized here?
...
> + if (iflag & LS2X_SR_IF) {
> + writeb(LS2X_CR_IACK, dev->base + I2C_LS2X_CR);
> + complete(&dev->cmd_complete);
> + } else
> + return IRQ_NONE;
Use usual pattern: checking for error condition first.
if (!(iflag & LS2X_SR_IF))
return IRQ_NONE;
writeb(LS2X_CR_IACK, dev->base + I2C_LS2X_CR);
complete(&dev->cmd_complete);
> + return IRQ_HANDLED;
...
> + writeb((val & 0xff00) >> 8, dev->base + I2C_LS2X_PRER_HI);
What ' & 0xff00' part is for?
...
> + dev = devm_kzalloc(&pdev->dev,
> + sizeof(struct ls2x_i2c_dev), GFP_KERNEL);
sizeof(*dev) and make it one line.
> + if (unlikely(!dev))
Why unlikely()?
> + return -ENOMEM;
...
> + dev->irq = platform_get_irq(pdev, 0);
> + if (unlikely(dev->irq <= 0))
Why 'unlikely()'? Why == 0 is here?
> + return -ENODEV;
...
> + r = devm_request_irq(&pdev->dev, dev->irq, ls2x_i2c_isr,
> + IRQF_SHARED, "ls2x-i2c", dev);
> + if (unlikely(r)) {
Why 'unlikely()'? You must explain all likely() / unlikely() use in the code.
> + dev_err(dev->dev, "failure requesting irq %i\n", dev->irq);
> + return r;
return dev_err_probe(...);
> + }
...
> + /*
> + * The I2C controller has a fixed I2C bus frequency by default, but to
> + * be compatible with more client devices, we can obtain the set I2C
> + * bus frequency from ACPI or FDT.
> + */
> + dev->bus_clk_rate = i2c_acpi_find_bus_speed(&pdev->dev);
> + if (!dev->bus_clk_rate)
> + device_property_read_u32(&pdev->dev, "clock-frequency",
> + &dev->bus_clk_rate);
This should be done via
i2c_parse_fw_timings(&pdev->dev, ...);
no?
...
> + adap->dev.of_node = pdev->dev.of_node;
> + ACPI_COMPANION_SET(&adap->dev, ACPI_COMPANION(&pdev->dev));
device_set_node()
...
> + /* i2c device drivers may be active on return from add_adapter() */
> + r = i2c_add_adapter(adap);
> + if (r) {
> + dev_err(dev->dev, "failure adding adapter\n");
> + return r;
return dev_err_probe(...);
> + }
...
> +static int __maybe_unused ls2x_i2c_suspend_noirq(struct device *dev)
No __maybe_unused, use proper PM macros and definitions.
(look for pm_ptr() / pm_sleep_ptr() and corresponding defines)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct ls2x_i2c_dev *i2c_dev = platform_get_drvdata(pdev);
> +
> + i2c_dev->suspended = 1;
> +
> + return 0;
> +}
> +
> +static int __maybe_unused ls2x_i2c_resume(struct device *dev)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct ls2x_i2c_dev *i2c_dev = platform_get_drvdata(pdev);
> +
> + i2c_dev->suspended = 0;
> + ls2x_i2c_reginit(i2c_dev);
> +
> + return 0;
> +}
> +
> +static const struct dev_pm_ops ls2x_i2c_dev_pm_ops = {
> + SET_SYSTEM_SLEEP_PM_OPS(ls2x_i2c_suspend_noirq, ls2x_i2c_resume)
> +};
As per above.
...
> +static const struct of_device_id ls2x_i2c_id_table[] = {
> + { .compatible = "loongson,ls2k-i2c" },
> + { .compatible = "loongson,ls7a-i2c" },
> + { /* sentinel */ },
No comma for terminator entry.
> +};
...
> + { "LOON0004", 0 },
', 0' is redundant.
...
> +static struct platform_driver ls2x_i2c_driver = {
> + .probe = ls2x_i2c_probe,
> + .remove = ls2x_i2c_remove,
> + .driver = {
> + .name = "ls2x-i2c",
> + .owner = THIS_MODULE,
Why?
> + .pm = &ls2x_i2c_dev_pm_ops,
> + .of_match_table = ls2x_i2c_id_table,
> + .acpi_match_table = ls2x_i2c_acpi_match,
> + },
> +};
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2022-11-25 10:41 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-25 8:54 [PATCH V3 0/5] i2c: ls2x: Add support for the Loongson-2K/LS7A I2C controller Binbin Zhou
2022-11-25 8:54 ` [PATCH V3 1/5] i2c: gpio: Fix potential unused warning for 'i2c_gpio_dt_ids' Binbin Zhou
2022-11-25 10:21 ` Andy Shevchenko
2022-11-25 10:35 ` Arnd Bergmann
2022-11-25 8:54 ` [PATCH V3 2/5] i2c: gpio: Add support on ACPI-based system Binbin Zhou
2022-11-25 10:23 ` Andy Shevchenko
2022-11-28 1:28 ` Binbin Zhou
2022-11-25 8:54 ` [PATCH V3 3/5] dt-bindings: i2c: add bindings for Loongson LS2X I2C Binbin Zhou
2022-11-27 20:49 ` Krzysztof Kozlowski
2022-11-28 12:24 ` Binbin Zhou
2022-11-28 12:37 ` Krzysztof Kozlowski
2022-11-28 14:15 ` Krzysztof Kozlowski
2022-11-29 13:24 ` Binbin Zhou
2022-11-27 20:50 ` Krzysztof Kozlowski
2022-11-25 8:55 ` [PATCH V3 4/5] i2c: ls2x: Add driver for Loongson-2K/LS7A I2C controller Binbin Zhou
2022-11-25 10:41 ` Andy Shevchenko [this message]
2022-11-28 12:03 ` Binbin Zhou
2022-11-28 13:24 ` Andy Shevchenko
2022-11-29 11:34 ` Binbin Zhou
2022-11-29 12:53 ` Andy Shevchenko
2022-11-29 13:19 ` Binbin Zhou
2022-11-25 11:02 ` kernel test robot
2022-11-25 8:55 ` [PATCH V3 5/5] LoongArch: Enable LS2X I2C in loongson3_defconfig Binbin Zhou
2022-11-26 22:25 ` [PATCH V3 3/5] dt-bindings: i2c: add bindings for Loongson LS2X I2C Rob Herring
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=Y4Cb19PM97M9HaiB@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=arnd@arndb.de \
--cc=chenhuacai@loongson.cn \
--cc=devicetree@vger.kernel.org \
--cc=kernel@xen0n.name \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-i2c@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=lvjianmin@loongson.cn \
--cc=mika.westerberg@linux.intel.com \
--cc=robh+dt@kernel.org \
--cc=wsa+renesas@sang-engineering.com \
--cc=wsa@kernel.org \
--cc=zhoubinbin@loongson.cn \
/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.