linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tang Bin <tangbin@cmss.chinamobile.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: wsa@the-dreams.de, o.rempel@pengutronix.de, ardb@kernel.org,
	linux-i2c@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] i2c: drivers: Avoid unnecessary check inefm32_i2c_probe()
Date: Thu, 16 Apr 2020 17:00:21 +0800	[thread overview]
Message-ID: <145d0ba7-fca4-20f6-a6e2-6fc370bc9a57@cmss.chinamobile.com> (raw)
In-Reply-To: <20200416065014.7umocf2aohz6q2nn@pengutronix.de>

Hi Uwe:

On 2020/4/16 14:50, Uwe Kleine-König wrote:
>>>> diff --git a/drivers/i2c/busses/i2c-efm32.c b/drivers/i2c/busses/i2c-efm32.c
>>>> index 4de31fae7..4786ef6b2 100644
>>>> --- a/drivers/i2c/busses/i2c-efm32.c
>>>> +++ b/drivers/i2c/busses/i2c-efm32.c
>>>> @@ -312,9 +312,6 @@ static int efm32_i2c_probe(struct platform_device *pdev)
>>>>    	int ret;
>>>>    	u32 clkdiv;
>>>> -	if (!np)
>>>> -		return -EINVAL;
>>>> -
>>> I don't care much about this change. While the statement that this
>>> driver is only instantiated on dt platforms is probably right,
>>> explicitly checking for it might still prevent surprises later, serves
>>> as explicit statement for the driver reader that non-dt isn't supposed
>>> to work and given that the check is cheap I tend slightly to just keep
>>> it.
>>>
>> In this driver, the function efm32_i2c_probe() can be triggered only if the
>> platform_device and platform_driver matches,  and the matching condition is
>> DTS. It's my opinion.
> I admit I didn't recheck, but I think the driver will also be matched on
> non-dt platforms that provide an "efm32-i2c" device.

Year, I agree with you, the driver should be matched on dt or non-dt 
platforms. But for non-dt platforms, I think this driver may need minor 
changes, after all, it is just suitable for the dt platforms right now. 
That's my shallow opinions.

Thanks for your patient guidance and reply, thank you. I think you are 
also a good teacher, thanks.

Tang Bin

>




  reply	other threads:[~2020-04-16  8:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-15 14:06 [PATCH] i2c: drivers: Avoid unnecessary check in efm32_i2c_probe() Tang Bin
2020-04-15 14:31 ` Uwe Kleine-König
2020-04-16  1:30   ` [PATCH] i2c: drivers: Avoid unnecessary check inefm32_i2c_probe() Tang Bin
2020-04-16  6:50     ` Uwe Kleine-König
2020-04-16  9:00       ` Tang Bin [this message]
2020-05-22 15:07 ` [PATCH] i2c: drivers: Avoid unnecessary check in efm32_i2c_probe() Wolfram Sang

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=145d0ba7-fca4-20f6-a6e2-6fc370bc9a57@cmss.chinamobile.com \
    --to=tangbin@cmss.chinamobile.com \
    --cc=ardb@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=u.kleine-koenig@pengutronix.de \
    --cc=wsa@the-dreams.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).