All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Masayuki Ohtake" <masa-korg@dsn.okisemi.com>
To: "Joe Perches" <joe@perches.com>
Cc: "Jean Delvare \(PC drivers, core\)" <khali@linux-fr.org>,
	"Ben Dooks \(embedded platforms\)" <ben-linux@fluff.org>,
	"Crane Cai" <crane.cai@amd.com>,
	"Samuel Ortiz" <sameo@linux.intel.com>,
	"Linus Walleij" <linus.walleij@stericsson.com>,
	"Ralf Baechle" <ralf@linux-mips.org>,
	"srinidhi kasagar" <srinidhi.kasagar@stericsson.com>,
	<linux-i2c@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	"Wang Yong Y\"" <yong.y.wang@intel.com>,
	"Wang Qi\"" <qi.wang@intel.com>,
	"Andrew\"" <andrew.chih.howe.khor@intel.com>,
	<arjan@linux.intel.com>,
	"Tomoya MORINAGA" <morinaga526@dsn.okisemi.com>,
	"Arnd Bergmann" <arnd@arndb.de>
Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_I2C driver to 2.6.35
Date: Wed, 1 Sep 2010 14:08:32 +0900	[thread overview]
Message-ID: <001e01cb4993$bc0d75d0$66f8800a@maildom.okisemi.com> (raw)
In-Reply-To: 1283309032.1797.123.camel@Joe-Laptop

Hi Joe,

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?

Thanks, Ohtake(OKISemi)

----- Original Message ----- 
From: "Joe Perches" <joe@perches.com>
To: "Masayuki Ohtak" <masa-korg@dsn.okisemi.com>
Cc: "Jean Delvare (PC drivers, core)" <khali@linux-fr.org>; "Ben Dooks (embedded platforms)" <ben-linux@fluff.org>;
"Crane Cai" <crane.cai@amd.com>; "Samuel Ortiz" <sameo@linux.intel.com>; "Linus Walleij" <linus.walleij@stericsson.com>;
"Ralf Baechle" <ralf@linux-mips.org>; "srinidhi kasagar" <srinidhi.kasagar@stericsson.com>; <linux-i2c@vger.kernel.org>;
<linux-kernel@vger.kernel.org>; "Wang Yong Y"" <yong.y.wang@intel.com>; "Wang Qi"" <qi.wang@intel.com>; "Andrew""
<andrew.chih.howe.khor@intel.com>; <arjan@linux.intel.com>; "Tomoya MORINAGA" <morinaga526@dsn.okisemi.com>; "Arnd
Bergmann" <arnd@arndb.de>
Sent: Wednesday, September 01, 2010 11:43 AM
Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_I2C driver to 2.6.35


> On Wed, 2010-09-01 at 11:26 +0900, Masayuki Ohtak wrote:
> > I2C driver of Topcliff PCH
> > +++ b/drivers/i2c/busses/i2c-pch.c
> []
> > +static void pch_init(struct i2c_algo_pch_data *adap)
> []
> > + if (pch_i2c_speed == FAST_MODE_CLK) {
> > + reg_value |= FAST_MODE_EN;
> > + dev_dbg(adap->pch_adapter.dev.parent, "Fast mode enabled\n");
> > + }
>
> Just a suggestion below, ignore it at your pleasure...
>
> These dev_<level> calls might be easier to read if you had
> some #defines like:
>
> #define pch_dbg(adap, fmt, arg...) \
> dev_dbg(adap->pch_adapter.dev.parent, fmt, ##arg)
> #define pch_err(adap, fmt, arg...) \
> dev_err(adap->pch_adapter.dev.parent, fmt, ##arg)
> #define pch_info(adap, fmt, arg...) \
> dev_info(adap->pch_adapter.dev.parent, fmt, ##arg)
>
> then the last dev_dbg becomes:
>
> pch_dbg(adap, "Fast mode enabled\n");
>
> Many modules use similar wrapper #defines.
>
> > + dev_dbg(adap->pch_adapter.dev.parent,
> > + "%s: I2CCTL=%x pch_i2cbc=%x pch_i2ctmr=%x Enable interrupts\n",
> > + __func__, ioread32(p + PCH_I2CCTL),
> > + pch_i2cbc, pch_i2ctmr);
>
> pch_dbg(adap, etc...)
>
> etc.
>
> cheers, Joe
>



WARNING: multiple messages have this Message-ID (diff)
From: "Masayuki Ohtake" <masa-korg-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
To: Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
Cc: "Jean Delvare (PC drivers,
	core)" <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>,
	"Ben Dooks (embedded platforms)"
	<ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>,
	Crane Cai <crane.cai-5C7GfCeVMHo@public.gmane.org>,
	Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	Linus Walleij
	<linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>,
	Ralf Baechle <ralf-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org>,
	srinidhi kasagar
	<srinidhi.kasagar-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"Wang Yong Y\""
	<yong.y.wang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	"Wang Qi\"" <qi.wang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	"Andrew\""
	<andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	arjan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
	Tomoya MORINAGA
	<morinaga526-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_I2C driver to 2.6.35
Date: Wed, 1 Sep 2010 14:08:32 +0900	[thread overview]
Message-ID: <001e01cb4993$bc0d75d0$66f8800a@maildom.okisemi.com> (raw)
In-Reply-To: 1283309032.1797.123.camel@Joe-Laptop

Hi Joe,

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?

Thanks, Ohtake(OKISemi)

----- Original Message ----- 
From: "Joe Perches" <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
To: "Masayuki Ohtak" <masa-korg-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
Cc: "Jean Delvare (PC drivers, core)" <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>; "Ben Dooks (embedded platforms)" <ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>;
"Crane Cai" <crane.cai-5C7GfCeVMHo@public.gmane.org>; "Samuel Ortiz" <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>; "Linus Walleij" <linus.walleij-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>;
"Ralf Baechle" <ralf-6z/3iImG2C8G8FEW9MqTrA@public.gmane.org>; "srinidhi kasagar" <srinidhi.kasagar-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>; <linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>;
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; "Wang Yong Y"" <yong.y.wang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>; "Wang Qi"" <qi.wang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>; "Andrew""
<andrew.chih.howe.khor-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>; <arjan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>; "Tomoya MORINAGA" <morinaga526-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>; "Arnd
Bergmann" <arnd-r2nGTMty4D4@public.gmane.org>
Sent: Wednesday, September 01, 2010 11:43 AM
Subject: Re: [MeeGo-Dev][PATCH] Topcliff: Update PCH_I2C driver to 2.6.35


> On Wed, 2010-09-01 at 11:26 +0900, Masayuki Ohtak wrote:
> > I2C driver of Topcliff PCH
> > +++ b/drivers/i2c/busses/i2c-pch.c
> []
> > +static void pch_init(struct i2c_algo_pch_data *adap)
> []
> > + if (pch_i2c_speed == FAST_MODE_CLK) {
> > + reg_value |= FAST_MODE_EN;
> > + dev_dbg(adap->pch_adapter.dev.parent, "Fast mode enabled\n");
> > + }
>
> Just a suggestion below, ignore it at your pleasure...
>
> These dev_<level> calls might be easier to read if you had
> some #defines like:
>
> #define pch_dbg(adap, fmt, arg...) \
> dev_dbg(adap->pch_adapter.dev.parent, fmt, ##arg)
> #define pch_err(adap, fmt, arg...) \
> dev_err(adap->pch_adapter.dev.parent, fmt, ##arg)
> #define pch_info(adap, fmt, arg...) \
> dev_info(adap->pch_adapter.dev.parent, fmt, ##arg)
>
> then the last dev_dbg becomes:
>
> pch_dbg(adap, "Fast mode enabled\n");
>
> Many modules use similar wrapper #defines.
>
> > + dev_dbg(adap->pch_adapter.dev.parent,
> > + "%s: I2CCTL=%x pch_i2cbc=%x pch_i2ctmr=%x Enable interrupts\n",
> > + __func__, ioread32(p + PCH_I2CCTL),
> > + pch_i2cbc, pch_i2ctmr);
>
> pch_dbg(adap, etc...)
>
> etc.
>
> cheers, Joe
>

  parent reply	other threads:[~2010-09-01  5:08 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-01  2:26 [MeeGo-Dev][PATCH] Topcliff: Update PCH_I2C driver to 2.6.35 Masayuki Ohtak
2010-09-01  2:43 ` Joe Perches
2010-09-01  2:43   ` Joe Perches
2010-09-01  4:16   ` Masayuki Ohtake
2010-09-01  4:16     ` Masayuki Ohtake
2010-09-01  5:08   ` Masayuki Ohtake [this message]
2010-09-01  5:08     ` Masayuki Ohtake
2010-09-01  5:24     ` Joe Perches
2010-09-01  5:44       ` Masayuki Ohtake
2010-09-01  5:44         ` Masayuki Ohtake
2010-09-01 19:44 ` Linus Walleij
2010-09-01 19:44   ` Linus Walleij
2010-09-03  3:12   ` Masayuki Ohtake
2010-09-03  3:12     ` Masayuki Ohtake
  -- strict thread matches above, loose matches on Subject: below --
2010-09-06  1:31 Masayuki Ohtak
2010-09-06  1:31 ` Masayuki Ohtak
2010-09-06  1:10 Masayuki Ohtak
2010-09-06  1:10 ` Masayuki Ohtak
2010-09-03 10:19 Masayuki Ohtak
2010-09-03 10:19 ` Masayuki Ohtak
2010-09-03 12:36 ` Alan Cox
2010-09-03 12:36   ` Alan Cox
2010-09-03 12:26   ` Wolfram Sang
2010-09-03 12:26     ` Wolfram Sang
2010-09-06  0:44     ` Masayuki Ohtake
2010-09-06  0:44       ` Masayuki Ohtake
2010-09-06  0:43   ` Masayuki Ohtake
2010-09-06  0:43     ` Masayuki Ohtake
2010-09-07 23:55 ` Ben Dooks
2010-09-07 23:55   ` Ben Dooks
2010-09-08 12:06   ` Masayuki Ohtake
2010-09-08 12:06     ` Masayuki Ohtake
2010-09-03  7:15 Masayuki Ohtak
2010-09-03  7:15 ` Masayuki Ohtak
2010-09-03  8:10 ` Joe Perches
2010-09-03  8:10   ` Joe Perches
2010-09-03 10:01   ` Masayuki Ohtake
2010-09-03 10:01     ` Masayuki Ohtake
2010-09-03  3:19 Masayuki Ohtak
2010-09-03  3:19 ` Masayuki Ohtak
2010-09-03  4:38 ` Joe Perches
2010-09-03  4:38   ` Joe Perches
2010-09-03  8:39 ` Linus WALLEIJ
     [not found] ` <4C80692E.80004-ECg8zkTtlr0C6LszWs/t0g@public.gmane.org>
2010-09-03  8:39   ` Linus WALLEIJ
2010-09-01  2:26 Masayuki Ohtak
     [not found] <4C5B9094.5090205@dsn.okisemi.com>
     [not found] ` <4C5B9229.1040403@linux.intel.com>
2010-09-01  1:50   ` Masayuki Ohtake
     [not found] ` <20100806142418.GA4921@suse.de>
2010-09-01  1:57   ` Masayuki Ohtake

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='001e01cb4993$bc0d75d0$66f8800a@maildom.okisemi.com' \
    --to=masa-korg@dsn.okisemi.com \
    --cc=andrew.chih.howe.khor@intel.com \
    --cc=arjan@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=ben-linux@fluff.org \
    --cc=crane.cai@amd.com \
    --cc=joe@perches.com \
    --cc=khali@linux-fr.org \
    --cc=linus.walleij@stericsson.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=morinaga526@dsn.okisemi.com \
    --cc=qi.wang@intel.com \
    --cc=ralf@linux-mips.org \
    --cc=sameo@linux.intel.com \
    --cc=srinidhi.kasagar@stericsson.com \
    --cc=yong.y.wang@intel.com \
    /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.