From: ebiederm@xmission.com (Eric W. Biederman)
To: vgoyal@in.ibm.com
Cc: Kumar Gala <galak@kernel.crashing.org>,
Arjan van de Ven <arjan@infradead.org>,
linux kernel mailing list <linux-kernel@vger.kernel.org>,
Fastboot mailing list <fastboot@lists.osdl.org>,
Morton Andrew Morton <akpm@osdl.org>,
gregkh@suse.de
Subject: Re: [RFC][PATCH] Expanding the size of "start" and "end" field in "struct resource"
Date: Wed, 15 Mar 2006 13:58:00 -0700 [thread overview]
Message-ID: <m1k6avfmsn.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20060315203200.GB7465@in.ibm.com> (Vivek Goyal's message of "Wed, 15 Mar 2006 15:32:00 -0500")
Vivek Goyal <vgoyal@in.ibm.com> writes:
> Few problems which I have noticed so far.
>
> - Many printk() warnings. Wherever start and end are being printed,
> the format specifier being used is %lx. Needs to be changed to %Lx.
Sane, but we need to check the 64bit case as well.
> - Some folks save a pointer of type (unsigned long *) to start and end field
> and then try to operate on it. This pointer type shall have to be changed
> to something like u64*.
>
> unsigned long *port, *end, *tport, *tend;
> port = &dev->res.port_resource[idx].start;
Weird.
> - Some folks cast "start" to a pointer and then use it. Compiler gives warning.
>
> addr_reg = (void __iomem *) addr->start;
I'm not familiar enough with that part of the code off the top of my head
but that except for a few helper functions that kind of behavior should
be pretty much forbidden.
This feels like entering the guts of ugly barely working drivers at
the moment.
Eric
next prev parent reply other threads:[~2006-03-15 21:34 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-15 19:31 Vivek Goyal
2006-03-15 19:48 ` Kumar Gala
2006-03-15 19:57 ` Arjan van de Ven
2006-03-15 20:01 ` Kumar Gala
2006-03-15 20:10 ` Kumar Gala
2006-03-15 20:13 ` Eric W. Biederman
2006-03-15 20:28 ` Kumar Gala
2006-03-15 20:37 ` Eric W. Biederman
2006-03-15 20:32 ` Vivek Goyal
2006-03-15 20:58 ` Eric W. Biederman [this message]
2006-03-15 21:57 ` David S. Miller
2006-03-15 20:53 ` Benjamin LaHaise
2006-03-15 21:05 ` Kumar Gala
2006-03-15 21:13 ` Benjamin LaHaise
2006-03-15 21:29 ` Eric W. Biederman
2006-03-15 21:28 ` Benjamin LaHaise
2006-03-15 21:50 ` Eric W. Biederman
2006-03-15 22:13 ` Andrew Morton
2006-03-15 22:18 ` David S. Miller
2006-03-15 21:59 ` Eric W. Biederman
2006-03-15 22:07 ` Benjamin LaHaise
2006-03-16 14:45 ` Eric W. Biederman
2006-03-15 21:30 ` Kumar Gala
2006-03-15 21:35 ` hackmiester / Hunter Fuller
2006-03-15 21:31 ` Eric W. Biederman
2006-03-15 21:15 ` Eric W. Biederman
2006-03-15 21:26 ` linux-os (Dick Johnson)
2006-03-15 21:37 ` Eric W. Biederman
2006-03-15 22:08 ` 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=m1k6avfmsn.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@osdl.org \
--cc=arjan@infradead.org \
--cc=fastboot@lists.osdl.org \
--cc=galak@kernel.crashing.org \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=vgoyal@in.ibm.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
all inboxes | Powered by JetHome®