From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: unlisted-recipients:; (no To-header on input)
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
Matthew Garrett <mjg59@srcf.ucam.org>
Subject: Re: [PATCH 2/2] x86 platform driver: intelligent power sharing driver
Date: Tue, 11 May 2010 11:18:54 -0700 [thread overview]
Message-ID: <20100511111854.658a5520@virtuousgeek.org> (raw)
In-Reply-To: <20100511075919.39b768fc@virtuousgeek.org>
On Tue, 11 May 2010 07:59:19 -0700
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Mon, 10 May 2010 22:00:46 -0400
> Andrew Morton <akpm@linux-foundation.org> wrote:
> > > +#define thm_readb(off) readb(ips->regmap + (off))
> > > +#define thm_readw(off) readw(ips->regmap + (off))
> > > +#define thm_readl(off) readl(ips->regmap + (off))
> > > +#define thm_readq(off) readq(ips->regmap + (off))
> > > +
> > > +#define thm_writeb(off, val) writeb((val), ips->regmap + (off))
> > > +#define thm_writew(off, val) writew((val), ips->regmap + (off))
> > > +#define thm_writel(off, val) writel((val), ips->regmap + (off))
> >
> > ick.
> >
> > static inline unsigned short thm_readw(struct ips_driver *ips, unsigned offset)
> > {
> > readw(ips->regmap + offset);
> > }
> >
> > would be nicer.
>
> Yes, it would.
No, I take that back, it just means more typing. This idiom of
expecting a given variable to be declared for the IO routines to work
is pretty common in drivers, and saves a bunch of redundant "(ips,"
everywhere...
> > afacit these messages might come out at one-per-five-seconds max?
> >
> > I bet the driver blows up and someone's logs get spammed ;)
>
> Possibly. :) I added these at the request of Pavel; I could make them
> just print one time though...
These should be dev_warn instead anyway.
Updated patch on its way.
--
Jesse Barnes, Intel Open Source Technology Center
WARNING: multiple messages have this Message-ID (diff)
From: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
Matthew Garrett <mjg59@srcf.ucam.org>
Subject: Re: [PATCH 2/2] x86 platform driver: intelligent power sharing driver
Date: Tue, 11 May 2010 11:18:54 -0700 [thread overview]
Message-ID: <20100511111854.658a5520@virtuousgeek.org> (raw)
In-Reply-To: <20100511075919.39b768fc@virtuousgeek.org>
On Tue, 11 May 2010 07:59:19 -0700
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Mon, 10 May 2010 22:00:46 -0400
> Andrew Morton <akpm@linux-foundation.org> wrote:
> > > +#define thm_readb(off) readb(ips->regmap + (off))
> > > +#define thm_readw(off) readw(ips->regmap + (off))
> > > +#define thm_readl(off) readl(ips->regmap + (off))
> > > +#define thm_readq(off) readq(ips->regmap + (off))
> > > +
> > > +#define thm_writeb(off, val) writeb((val), ips->regmap + (off))
> > > +#define thm_writew(off, val) writew((val), ips->regmap + (off))
> > > +#define thm_writel(off, val) writel((val), ips->regmap + (off))
> >
> > ick.
> >
> > static inline unsigned short thm_readw(struct ips_driver *ips, unsigned offset)
> > {
> > readw(ips->regmap + offset);
> > }
> >
> > would be nicer.
>
> Yes, it would.
No, I take that back, it just means more typing. This idiom of
expecting a given variable to be declared for the IO routines to work
is pretty common in drivers, and saves a bunch of redundant "(ips,"
everywhere...
> > afacit these messages might come out at one-per-five-seconds max?
> >
> > I bet the driver blows up and someone's logs get spammed ;)
>
> Possibly. :) I added these at the request of Pavel; I could make them
> just print one time though...
These should be dev_warn instead anyway.
Updated patch on its way.
--
Jesse Barnes, Intel Open Source Technology Center
next prev parent reply other threads:[~2010-05-11 18:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-10 21:25 Intelligent power sharing driver Jesse Barnes
2010-05-10 21:26 ` [PATCH 1/2] timer: add on-stack deferrable timer interfaces Jesse Barnes
2010-05-10 21:26 ` [PATCH 2/2] x86 platform driver: intelligent power sharing driver Jesse Barnes
2010-05-11 2:00 ` Andrew Morton
2010-05-11 2:00 ` Andrew Morton
2010-05-11 14:59 ` Jesse Barnes
2010-05-11 18:18 ` Jesse Barnes [this message]
2010-05-11 18:18 ` Jesse Barnes
2010-05-11 15:38 ` Andrew Morton
2010-05-11 15:38 ` Andrew Morton
2010-05-11 18:59 ` Jesse Barnes
2010-05-14 22:41 ` Jesse Barnes
2010-05-15 8:54 ` Andy Isaacson
2010-05-15 16:29 ` Jesse Barnes
2010-05-15 16:29 ` Jesse Barnes
-- strict thread matches above, loose matches on Subject: below --
2010-03-26 23:29 [RFC] Intelligent " Jesse Barnes
2010-03-26 23:29 ` [PATCH 2/2] x86 platform driver: intelligent " Jesse Barnes
2010-04-13 19:24 ` Pavel Machek
2010-04-13 19:40 ` Jesse Barnes
2010-04-13 19:40 ` Jesse Barnes
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=20100511111854.658a5520@virtuousgeek.org \
--to=jbarnes@virtuousgeek.org \
--cc=akpm@linux-foundation.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
/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.