public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Joe Perches <joe@perches.com>
Cc: "Mark A. Allyn" <mark.a.allyn@intel.com>,
	linux-kernel@vger.kernel.org, alan@linux.intel.com,
	jayant.mangalampalli@intel.com, venkat.r.gokulrangan@intel.com
Subject: Re: Re-send (What else needs to be done to the sep driver (staging/sep))
Date: Wed, 13 Apr 2011 15:46:21 -0700	[thread overview]
Message-ID: <20110413224621.GA4909@kroah.com> (raw)
In-Reply-To: <1302733836.11415.42.camel@Joe-Laptop>

On Wed, Apr 13, 2011 at 03:30:36PM -0700, Joe Perches wrote:
> On Wed, 2011-04-13 at 15:23 -0700, Greg KH wrote:
> > Ick, no, never use your own macros, just use the "real" things like is
> > done in this driver.  If it's a pain to get to that pointer, then use a
> > temporary variable in the code and then use it.
> > 
> > Otherwise, no, I don't like this patch at all, sorry.
> 
> I think you're simply incorrect here.
> 
> There are lots of other uses like netdev_<foo>
> where <foo>_<level> takes a particular pointer type.
> 
> This is a structure that contains a pointer to
> another structure than contains a struct device.
> 
> You might also look at the macros the USB subsystem
> uses for message logging.
> 
> Hey, aren't you the USB maintainer?

Yes, and over time we have been moving away from using those macros.  I
don't like seeing every individual driver have its own way of handling
debug macros, that's crazy.

For larger stuff like networking, yes, they can do that, and that's
fine.  They also were doing this before the dev_* macros came along,
just like USB did, so there is historical precident there.

But again, not for a new driver, don't redefine the existing macros just
because you don't like typing a few extra characters...

thanks,

greg k-h

  reply	other threads:[~2011-04-13 22:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-13 21:29 Re-send (What else needs to be done to the sep driver (staging/sep)) Mark A. Allyn
2011-04-13 21:56 ` Randy Dunlap
2011-04-13 22:22   ` Mark A. Allyn
2011-04-13 22:46     ` Greg KH
2011-04-13 23:41     ` Joe Perches
2011-04-13 21:56 ` Joe Perches
2011-04-13 22:23   ` Greg KH
2011-04-13 22:30     ` Joe Perches
2011-04-13 22:46       ` Greg KH [this message]
2011-04-13 23:12         ` Joe Perches
2011-04-14 14:46           ` Allyn, Mark A
2011-04-14 14:55             ` Alan Cox
2011-04-14 14:57               ` Allyn, Mark A
2011-04-26  0:40 ` Greg KH

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=20110413224621.GA4909@kroah.com \
    --to=greg@kroah.com \
    --cc=alan@linux.intel.com \
    --cc=jayant.mangalampalli@intel.com \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.a.allyn@intel.com \
    --cc=venkat.r.gokulrangan@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox