[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <005801cb4998$b526d9f0$66f8800a@maildom.okisemi.com>
Date: Wed, 1 Sep 2010 14:44:09 +0900
From: "Masayuki Ohtake" <masa-korg@....okisemi.com>
To: "Joe Perches" <joe@...ches.com>
Cc: "Jean Delvare \(PC drivers, core\)" <khali@...ux-fr.org>,
"Ben Dooks \(embedded platforms\)" <ben-linux@...ff.org>,
"Crane Cai" <crane.cai@....com>,
"Samuel Ortiz" <sameo@...ux.intel.com>,
"Linus Walleij" <linus.walleij@...ricsson.com>,
"Ralf Baechle" <ralf@...ux-mips.org>,
"srinidhi kasagar" <srinidhi.kasagar@...ricsson.com>,
<linux-i2c@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
"Wang Yong Y\"" <yong.y.wang@...el.com>,
"Wang Qi\"" <qi.wang@...el.com>,
"Andrew\"" <andrew.chih.howe.khor@...el.com>,
<arjan@...ux.intel.com>,
"Tomoya MORINAGA" <morinaga526@....okisemi.com>,
"Arnd Bergmann" <arnd@...db.de>
Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_I2C driver to 2.6.35
Hi Joe,
Thank you for your comments.
Best Regards,
Ohtake(OKISemi)
----- Original Message -----
From: "Joe Perches" <joe@...ches.com>
To: "Masayuki Ohtake" <masa-korg@....okisemi.com>
Cc: "Jean Delvare (PC drivers, core)" <khali@...ux-fr.org>; "Ben Dooks (embedded platforms)" <ben-linux@...ff.org>;
"Crane Cai" <crane.cai@....com>; "Samuel Ortiz" <sameo@...ux.intel.com>; "Linus Walleij" <linus.walleij@...ricsson.com>;
"Ralf Baechle" <ralf@...ux-mips.org>; "srinidhi kasagar" <srinidhi.kasagar@...ricsson.com>; <linux-i2c@...r.kernel.org>;
<linux-kernel@...r.kernel.org>; "Wang Yong Y"" <yong.y.wang@...el.com>; "Wang Qi"" <qi.wang@...el.com>; "Andrew""
<andrew.chih.howe.khor@...el.com>; <arjan@...ux.intel.com>; "Tomoya MORINAGA" <morinaga526@....okisemi.com>; "Arnd
Bergmann" <arnd@...db.de>
Sent: Wednesday, September 01, 2010 2:24 PM
Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_I2C driver to 2.6.35
> On Wed, 2010-09-01 at 14:08 +0900, Masayuki Ohtake wrote:
> > I have a question.
> > Current our I2C driver has the following 2 patterns dev_err().
> > (1) dev_err(adap->pch_adapter.dev.parent, "...");
> > (2) dev_err(&pdev->dev, "...");
> > > #define pch_err(adap, fmt, arg...) \
> > > dev_err(adap->pch_adapter.dev.parent, fmt, ##arg)
> > In case of using the above code, pattern (1) can apply, but (2) can't.
> > As to (2),
> > Should we use as dev_err or define another macro?
>
> Hello Ohtake.
>
> To me, it's a visual complexity vs std pattern trade-off.
>
> A 2 level dereference like dev_info(&dev->dev, ...)
> isn't overly difficult to read.
> 3 or more dereferences can be harder and a bit error prone.
> So I would only use pch_<level> for (1) and dev_err for (2).
>
> There are also times when there are additional standard
> arguments that you want to prefix to dev_<level> calls
> and that can be simplified with a custom XXX_<level>
> define for dev_<level>
>
> Look at the current uses in the tree and see what you like.
>
> $ grep -rP --include=*.[ch] "#define\s*.+\s+dev_[a-z]{3,7}\s*\(" *
>
> These aren't requirements, do what you think best.
>
> cheers, Joe
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists