* [PATCH] vt: add an event interface
@ 2009-07-02 11:36 Alan Cox
2009-07-03 6:45 ` Ingo Molnar
2009-07-21 16:23 ` Lennart Poettering
0 siblings, 2 replies; 60+ messages in thread
From: Alan Cox @ 2009-07-02 11:36 UTC (permalink / raw)
To: lennart, linux-kernel
Lennart how does this fit your needs - this replaces the existing wait
active hack with a race free one and adds other events with a proper
infrastructure for them.
From: Alan Cox <alan@linux.intel.com>
This is needed and requested in various forms for ConsoleKit, screenblank
handling and the like so do the job with a single interface. Also build the
interface so that unlike VT_WAITACTIVE and friends it won't miss events.
Signed-off-by: Alan Cox <alan@linux.intel.com>
---
drivers/char/vt.c | 4 +
drivers/char/vt_ioctl.c | 181 ++++++++++++++++++++++++++++++++++-------------
include/linux/vt.h | 14 ++++
include/linux/vt_kern.h | 3 +
kernel/power/console.c | 4 +
5 files changed, 152 insertions(+), 54 deletions(-)
diff --git a/drivers/char/vt.c b/drivers/char/vt.c
index d9113b4..e3ddefa 100644
--- a/drivers/char/vt.c
+++ b/drivers/char/vt.c
@@ -251,7 +251,6 @@ static void notify_update(struct vc_data *vc)
struct vt_notifier_param param = { .vc = vc };
atomic_notifier_call_chain(&vt_notifier_list, VT_UPDATE, ¶m);
}
-
/*
* Low-Level Functions
*/
@@ -938,6 +937,7 @@ static int vc_do_resize(struct tty_struct *tty, struct vc_data *vc,
if (CON_IS_VISIBLE(vc))
update_screen(vc);
+ vt_event_post(VT_EVENT_RESIZE, vc->vc_num, vc->vc_num);
return err;
}
@@ -3646,6 +3646,7 @@ void do_blank_screen(int entering_gfx)
blank_state = blank_vesa_wait;
mod_timer(&console_timer, jiffies + vesa_off_interval);
}
+ vt_event_post(VT_EVENT_BLANK, vc->vc_num, vc->vc_num);
}
EXPORT_SYMBOL(do_blank_screen);
@@ -3690,6 +3691,7 @@ void do_unblank_screen(int leaving_gfx)
console_blank_hook(0);
set_palette(vc);
set_cursor(vc);
+ vt_event_post(VT_EVENT_UNBLANK, vc->vc_num, vc->vc_num);
}
EXPORT_SYMBOL(do_unblank_screen);
diff --git a/drivers/char/vt_ioctl.c b/drivers/char/vt_ioctl.c
index 7539bed..c70eec8 100644
--- a/drivers/char/vt_ioctl.c
+++ b/drivers/char/vt_ioctl.c
@@ -61,6 +61,129 @@ extern struct tty_driver *console_driver;
static void complete_change_console(struct vc_data *vc);
/*
+ * User space VT_EVENT handlers
+ */
+
+struct vt_event_wait {
+ struct list_head list;
+ struct vt_event event;
+ int done;
+};
+
+static LIST_HEAD(vt_events);
+static DEFINE_SPINLOCK(vt_event_lock);
+static DECLARE_WAIT_QUEUE_HEAD(vt_event_waitqueue);
+
+/**
+ * vt_event_post
+ * @event: the event that occurred
+ * @old: old console
+ * @new: new console
+ *
+ * Post an VT event to interested VT handlers
+ */
+
+void vt_event_post(unsigned int event, unsigned int old, unsigned int new)
+{
+ struct list_head *pos, *head;
+ unsigned long flags;
+ int wake = 0;
+
+ spin_lock_irqsave(&vt_event_lock, flags);
+ head = &vt_events;
+
+ list_for_each(pos, head) {
+ struct vt_event_wait *ve = list_entry(pos,
+ struct vt_event_wait, list);
+ if (ve->event.event != event)
+ continue;
+ ve->event.old = old;
+ ve->event.new = new;
+ wake = 1;
+ ve->done = 1;
+ }
+ spin_unlock_irqrestore(&vt_event_lock, flags);
+ if (wake)
+ wake_up_interruptible(&vt_event_waitqueue);
+}
+
+/**
+ * vt_event_wait - wait for an event
+ * @vw: our event
+ *
+ * Waits for an event to occur which completes our vt_event_wait
+ * structure. On return the structure has wv->done set to 1 for success
+ * or 0 if some event such as a signal ended the wait.
+ */
+
+static void vt_event_wait(struct vt_event_wait *vw)
+{
+ unsigned long flags;
+ /* Prepare the event */
+ INIT_LIST_HEAD(&vw->list);
+ vw->done = 0;
+ /* Queue our event */
+ spin_lock_irqsave(&vt_event_lock, flags);
+ list_add(&vw->list, &vt_events);
+ spin_unlock_irqrestore(&vt_event_lock, flags);
+ /* Wait for it to pass */
+ wait_event_interruptible(vt_event_waitqueue, vw->done);
+ /* Dequeue it */
+ spin_lock_irqsave(&vt_event_lock, flags);
+ list_del(&vw->list);
+ spin_unlock_irqrestore(&vt_event_lock, flags);
+}
+
+/**
+ * vt_event_wait_ioctl - event ioctl handler
+ * @arg: argument to ioctl
+ *
+ * Implement the VT_WAITEVENT ioctl using the VT event interface
+ */
+
+static int vt_event_wait_ioctl(unsigned long arg)
+{
+ struct vt_event_wait vw;
+
+ if (copy_from_user(&vw.event, (void __user *)arg, sizeof(struct vt_event)))
+ return -EFAULT;
+ /* Highest supported event for now */
+ if(vw.event.event > VT_MAX_EVENT)
+ return -EINVAL;
+
+ vt_event_wait(&vw);
+ /* If it occurred report it */
+ if (vw.done) {
+ if(copy_to_user((void __user *)arg, &vw.event, sizeof(struct vt_event)))
+ return -EFAULT;
+ return 0;
+ }
+ return -EINTR;
+}
+
+/**
+ * vt_event_wait_internal - internal event handler
+ * @event: event code
+ * @n: new console
+ *
+ * Internal helper for event waits. Used to implement the legacy
+ * event waiting ioctls in terms of events
+ */
+
+int vt_event_wait_internal(int event, int n)
+{
+ struct vt_event_wait vw;
+
+ vw.event.event = event;
+ do {
+ vt_event_wait(&vw);
+ if(vw.done == 0)
+ return -EINTR;
+ } while(n != -1 && n != vw.event.new);
+ return 0;
+}
+
+/*
* these are the valid i/o ports we're allowed to change. they map all the
* video ports
*/
@@ -359,6 +482,8 @@ do_unimap_ioctl(int cmd, struct unimapdesc __user *user_ud, int perm, struct vc_
return 0;
}
+
+
/*
* We handle the console-specific ioctl's here. We allow the
* capability to modify any console, not just the fg_console.
@@ -850,7 +975,7 @@ int vt_ioctl(struct tty_struct *tty, struct file * file,
if (arg == 0 || arg > MAX_NR_CONSOLES)
ret = -ENXIO;
else
- ret = vt_waitactive(arg - 1);
+ ret = vt_event_wait_internal(VT_EVENT_SWITCH, arg);
break;
/*
@@ -1158,6 +1283,9 @@ int vt_ioctl(struct tty_struct *tty, struct file * file,
ret = put_user(vc->vc_hi_font_mask,
(unsigned short __user *)arg);
break;
+ case VT_WAITEVENT:
+ ret = vt_event_wait_ioctl(arg);
+ break;
default:
ret = -ENOIOCTLCMD;
}
@@ -1169,54 +1297,6 @@ eperm:
goto out;
}
-/*
- * Sometimes we want to wait until a particular VT has been activated. We
- * do it in a very simple manner. Everybody waits on a single queue and
- * get woken up at once. Those that are satisfied go on with their business,
- * while those not ready go back to sleep. Seems overkill to add a wait
- * to each vt just for this - usually this does nothing!
- */
-static DECLARE_WAIT_QUEUE_HEAD(vt_activate_queue);
-
-/*
- * Sleeps until a vt is activated, or the task is interrupted. Returns
- * 0 if activation, -EINTR if interrupted by a signal handler.
- */
-int vt_waitactive(int vt)
-{
- int retval;
- DECLARE_WAITQUEUE(wait, current);
-
- add_wait_queue(&vt_activate_queue, &wait);
- for (;;) {
- retval = 0;
-
- /*
- * Synchronize with redraw_screen(). By acquiring the console
- * semaphore we make sure that the console switch is completed
- * before we return. If we didn't wait for the semaphore, we
- * could return at a point where fg_console has already been
- * updated, but the console switch hasn't been completed.
- */
- acquire_console_sem();
- set_current_state(TASK_INTERRUPTIBLE);
- if (vt == fg_console) {
- release_console_sem();
- break;
- }
- release_console_sem();
- retval = -ERESTARTNOHAND;
- if (signal_pending(current))
- break;
- schedule();
- }
- remove_wait_queue(&vt_activate_queue, &wait);
- __set_current_state(TASK_RUNNING);
- return retval;
-}
-
-#define vt_wake_waitactive() wake_up(&vt_activate_queue)
-
void reset_vc(struct vc_data *vc)
{
vc->vc_mode = KD_TEXT;
@@ -1261,6 +1341,7 @@ void vc_SAK(struct work_struct *work)
static void complete_change_console(struct vc_data *vc)
{
unsigned char old_vc_mode;
+ int old = fg_console;
last_console = fg_console;
@@ -1324,7 +1405,7 @@ static void complete_change_console(struct vc_data *vc)
/*
* Wake anyone waiting for their VT to activate
*/
- vt_wake_waitactive();
+ vt_event_post(VT_EVENT_SWITCH, old, vc->vc_num);
return;
}
diff --git a/include/linux/vt.h b/include/linux/vt.h
index 02c1c02..ba2c0f1 100644
--- a/include/linux/vt.h
+++ b/include/linux/vt.h
@@ -74,4 +74,18 @@ struct vt_consize {
#define VT_UNLOCKSWITCH 0x560C /* allow vt switching */
#define VT_GETHIFONTMASK 0x560D /* return hi font mask */
+struct vt_event {
+ unsigned int event;
+#define VT_EVENT_SWITCH 0 /* Console switch */
+#define VT_EVENT_BLANK 1 /* Screen blank */
+#define VT_EVENT_UNBLANK 2 /* Screen unblank */
+#define VT_EVENT_RESIZE 3 /* Resize display */
+#define VT_MAX_EVENT 3
+ unsigned int old; /* Old console */
+ unsigned int new; /* New console (if changing) */
+ unsigned int pad[4]; /* Padding for expansion */
+};
+
+#define VT_WAITEVENT 0x560E /* Wait for an event */
+
#endif /* _LINUX_VT_H */
diff --git a/include/linux/vt_kern.h b/include/linux/vt_kern.h
index 2f11134..5d78fc4 100644
--- a/include/linux/vt_kern.h
+++ b/include/linux/vt_kern.h
@@ -91,7 +91,8 @@ int con_copy_unimap(struct vc_data *dst_vc, struct vc_data *src_vc);
#endif
/* vt.c */
-int vt_waitactive(int vt);
+void vt_event_post(unsigned int event, unsigned int old, unsigned int new);
+int vt_event_wait_internal(int event, int n);
void change_console(struct vc_data *new_vc);
void reset_vc(struct vc_data *vc);
extern int unbind_con_driver(const struct consw *csw, int first, int last,
diff --git a/kernel/power/console.c b/kernel/power/console.c
index a3961b2..0e41600 100644
--- a/kernel/power/console.c
+++ b/kernel/power/console.c
@@ -60,7 +60,7 @@ int pm_prepare_console(void)
}
release_console_sem();
- if (vt_waitactive(SUSPEND_CONSOLE)) {
+ if (vt_event_wait_internal(VT_EVENT_SWITCH, SUSPEND_CONSOLE)) {
pr_debug("Suspend: Can't switch VCs.");
return 1;
}
@@ -79,7 +79,7 @@ void pm_restore_console(void)
set_console(orig_fgconsole);
release_console_sem();
- if (vt_waitactive(orig_fgconsole)) {
+ if (vt_event_wait_internal(VT_EVENT_SWITCH, orig_fgconsole)) {
pr_debug("Resume: Can't switch VCs.");
return;
}
^ permalink raw reply related [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-02 11:36 [PATCH] vt: add an event interface Alan Cox
@ 2009-07-03 6:45 ` Ingo Molnar
2009-07-03 9:08 ` Alan Cox
2009-07-21 16:23 ` Lennart Poettering
1 sibling, 1 reply; 60+ messages in thread
From: Ingo Molnar @ 2009-07-03 6:45 UTC (permalink / raw)
To: Alan Cox; +Cc: lennart, linux-kernel, Andrew Morton
* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> Lennart how does this fit your needs - this replaces the existing wait
> active hack with a race free one and adds other events with a proper
> infrastructure for them.
>
> From: Alan Cox <alan@linux.intel.com>
>
> This is needed and requested in various forms for ConsoleKit, screenblank
> handling and the like so do the job with a single interface. Also build the
> interface so that unlike VT_WAITACTIVE and friends it won't miss events.
>
> Signed-off-by: Alan Cox <alan@linux.intel.com>
> ---
>
> drivers/char/vt.c | 4 +
> drivers/char/vt_ioctl.c | 181 ++++++++++++++++++++++++++++++++++-------------
> include/linux/vt.h | 14 ++++
> include/linux/vt_kern.h | 3 +
> kernel/power/console.c | 4 +
> 5 files changed, 152 insertions(+), 54 deletions(-)
Just a side-note, please run new patches through
scripts/checkpatch.pl:
total: 4 errors, 2 warnings, 0 checks, 294 lines checked
all four errors it flagged should be fixed.
Even the two warnings about over-long lines show real problem areas
that could be improved:
- the copy_from_user() in vt_event_wait_ioctl() could be shortened
if we didnt pass in an unsigned long (which is pointless anyway).
The cast to void __user * should be done in the ioctl
demultiplexer vt_ioctl(), and the ioctl ugliness should not
invade cleaner child functions such as vt_event_wait_ioctl().
- same for vt_event_wait_ioctl() - it passes in a type damaged by
ioctl's limitations. Such type limitations and ioctl demuxing
artifacts should be kept local to vt_ioctl().
Thanks,
Ingo
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 6:45 ` Ingo Molnar
@ 2009-07-03 9:08 ` Alan Cox
2009-07-03 9:16 ` Ingo Molnar
0 siblings, 1 reply; 60+ messages in thread
From: Alan Cox @ 2009-07-03 9:08 UTC (permalink / raw)
To: Ingo Molnar; +Cc: lennart, linux-kernel, Andrew Morton
> Just a side-note, please run new patches through
> scripts/checkpatch.pl:
>
> total: 4 errors, 2 warnings, 0 checks, 294 lines checked
Given the code doesn't currently *work* yet but is a first draft its
hardly important and there are better uses of time than playing
checkpatch policeman.
> - the copy_from_user() in vt_event_wait_ioctl() could be shortened
> if we didnt pass in an unsigned long (which is pointless anyway).
> The cast to void __user * should be done in the ioctl
> demultiplexer vt_ioctl(), and the ioctl ugliness should not
> invade cleaner child functions such as vt_event_wait_ioctl().
>
> - same for vt_event_wait_ioctl() - it passes in a type damaged by
> ioctl's limitations. Such type limitations and ioctl demuxing
> artifacts should be kept local to vt_ioctl().
That had already occurred to me. The events should also become a mask so
you can wait for several at once. What I wanted to know was whether such
an interface actually meets Lennart's requirements.
Alan
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 9:08 ` Alan Cox
@ 2009-07-03 9:16 ` Ingo Molnar
2009-07-03 9:44 ` Alan Cox
0 siblings, 1 reply; 60+ messages in thread
From: Ingo Molnar @ 2009-07-03 9:16 UTC (permalink / raw)
To: Alan Cox; +Cc: lennart, linux-kernel, Andrew Morton
* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > Just a side-note, please run new patches through
> > scripts/checkpatch.pl:
> >
> > total: 4 errors, 2 warnings, 0 checks, 294 lines checked
>
> Given the code doesn't currently *work* yet but is a first draft
> its hardly important and there are better uses of time than
> playing checkpatch policeman.
Well i noticed such details in your final commits that go upstream
as well - you dont appear to be making full use of the patch quality
tools we have.
(Also, the patch carried your Signed-off-by - which we add if we
consider patches worthy for upstream.)
I'd have made similar comments had a newbie submitted this patch as
well - i dont think you should be held to lower standards than
newbies - in fact by all means you should be held to a higher
standard as you serve as a role model. I hope you dont regard
constructive review feedback as 'policing' you.
Also, some of the warnings were relevant beyond pure stylistic
details:
> > - the copy_from_user() in vt_event_wait_ioctl() could be shortened
> > if we didnt pass in an unsigned long (which is pointless anyway).
> > The cast to void __user * should be done in the ioctl
> > demultiplexer vt_ioctl(), and the ioctl ugliness should not
> > invade cleaner child functions such as vt_event_wait_ioctl().
> >
> > - same for vt_event_wait_ioctl() - it passes in a type damaged by
> > ioctl's limitations. Such type limitations and ioctl demuxing
> > artifacts should be kept local to vt_ioctl().
>
> That had already occurred to me. The events should also become a
> mask so you can wait for several at once. What I wanted to know
> was whether such an interface actually meets Lennart's
> requirements.
Ingo
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 9:16 ` Ingo Molnar
@ 2009-07-03 9:44 ` Alan Cox
2009-07-03 9:54 ` Ingo Molnar
0 siblings, 1 reply; 60+ messages in thread
From: Alan Cox @ 2009-07-03 9:44 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linux-kernel, Andrew Morton
> Well i noticed such details in your final commits that go upstream
> as well - you dont appear to be making full use of the patch quality
> tools we have.
Quite often deliberately. A lot of the tty patches keep whatever style
they are patching. You'll then see a single big patch to clean the style
of the entire file up instead of creating the horrible mishmashes of
styles found in some of the code.
> (Also, the patch carried your Signed-off-by - which we add if we
> consider patches worthy for upstream.)
Fair point
Alan
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 9:44 ` Alan Cox
@ 2009-07-03 9:54 ` Ingo Molnar
2009-07-03 10:06 ` Alan Cox
0 siblings, 1 reply; 60+ messages in thread
From: Ingo Molnar @ 2009-07-03 9:54 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel, Andrew Morton
* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > Well i noticed such details in your final commits that go upstream
> > as well - you dont appear to be making full use of the patch quality
> > tools we have.
>
> Quite often deliberately. A lot of the tty patches keep whatever
> style they are patching. You'll then see a single big patch to
> clean the style of the entire file up instead of creating the
> horrible mishmashes of styles found in some of the code.
That's a really broken method IMO, as you basically allow crap (and
get used to allowing crap) instead of just saying: "no crap from me
from today on, ever".
Your method leads to stuff like this in a recent commit:
| commit a6614999e800cf3a134ce93ea46ef837e3c0e76e
| Author: Alan Cox <alan@redhat.com>
| Date: Fri Jan 2 13:46:50 2009 +0000
|
| tty: Introduce some close helpers for ports
+ if( tty->count == 1 && port->count != 1) {
+ printk(KERN_WARNING
+ "tty_port_close_start: tty->count = 1 port count = %d.\n",
+ port->count);
+ port->count = 1;
+ }
+ if (--port->count < 0) {
+ printk(KERN_WARNING "tty_port_close_start: count = %d\n",
+ port->count);
+ port->count = 0;
+ }
Look at how the first branch does 'if( ' while the second one does
the proper 'if ('. It literally hurts the eye - and if it does not
hurt yours it better should ;-)
There is absolutely no justification for stuff like that. It is not
about 'preserving the existing style' - it's inconsistent style in
the same hunk.
Also note the inconsistent printk-ing lines, mutiliated by line
warps. The use of pr_warning() would solve it:
+ if (tty->count == 1 && port->count != 1) {
+ pr_warning("tty_port_close_start: tty->count = 1 port count = %d.\n", port->count);
+ port->count = 1;
+ }
+ if (--port->count < 0) {
+ pr_warning("tty_port_close_start: count = %d\n", port->count);
+ port->count = 0;
+ }
'Allow crap now, we'll fix it later' is a bad policy IMHO. New code
(or old code moved into a new spot) added should always be nice.
Note, there are occasional bogus checkpatch warnings and borderline
cases (as with any tool - for example it will emit a col-80 warning
about my pr_warning() example above and that warning should be
ignored), where checkpatch should be ignored - but this is not one
of them.
Ingo
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 9:54 ` Ingo Molnar
@ 2009-07-03 10:06 ` Alan Cox
2009-07-03 10:22 ` Ingo Molnar
0 siblings, 1 reply; 60+ messages in thread
From: Alan Cox @ 2009-07-03 10:06 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linux-kernel, Andrew Morton
> Your method leads to stuff like this in a recent commit:
Which is a cut and paste of code from the originals into the helper.
> Also note the inconsistent printk-ing lines, mutiliated by line
> warps. The use of pr_warning() would solve it:
Send patches if it bugs you that much. It's rather lower on my agenda
than pressing things like "if I do xyz to a tty then 2.6.29 crashes"
grade sutff.
Alan
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 10:06 ` Alan Cox
@ 2009-07-03 10:22 ` Ingo Molnar
2009-07-03 10:44 ` Alan Cox
0 siblings, 1 reply; 60+ messages in thread
From: Ingo Molnar @ 2009-07-03 10:22 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel, Andrew Morton
* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > Your method leads to stuff like this in a recent commit:
>
> Which is a cut and paste of code from the originals into the
> helper.
and this changes my points how? It's not like it's hard to fix, and
the code is moved non-trivially anyway, it's better to have it nicer
if we touch it anyway.
> > Also note the inconsistent printk-ing lines, mutiliated by line
> > warps. The use of pr_warning() would solve it:
>
> Send patches if it bugs you that much. [...]
I find that a rather flippant attitude to kernel code quality
issues.
Also, isnt it a double standard: why should newbies be held to
higher standards than you hold yourself to?
Please just fix problems like everyone else is expected to fix it
too and you wont get such review feedback.
Ingo
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 10:22 ` Ingo Molnar
@ 2009-07-03 10:44 ` Alan Cox
2009-07-03 13:17 ` Ingo Molnar
0 siblings, 1 reply; 60+ messages in thread
From: Alan Cox @ 2009-07-03 10:44 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linux-kernel, Andrew Morton
> > Which is a cut and paste of code from the originals into the
> > helper.
>
> and this changes my points how? It's not like it's hard to fix, and
> the code is moved non-trivially anyway, it's better to have it nicer
> if we touch it anyway.
Its called engineering and good practice. The old code was correct. The
paste of it is therefore most likely to be correct. Furthermore patches
shouldn't mix clean up with other changes. So doing it as one is most
definitely bad practice.
> > > Also note the inconsistent printk-ing lines, mutiliated by line
> > > warps. The use of pr_warning() would solve it:
> >
> > Send patches if it bugs you that much. [...]
>
> I find that a rather flippant attitude to kernel code quality
> issues.
I have better uses for my time than fiddling with pr_warning(). Fixing
real bugs for example, bugs that crash your system, broken locking that
goes back to Linux 2.2 and DaveM's original push of lock_kernel out of
IRQ paths
> Also, isnt it a double standard: why should newbies be held to
> higher standards than you hold yourself to?
Why should anyone be held up to bogus standards ?
To bend an appropriate metaphor Ingo - you are trying to criticize the
paint finish of the bike shed while some of us are still replacing the
rusted and corroded beams.
If it was a new bike shed you might be in order, but at the moment the
tty layer is rescue archaeology and I'm spending my time doing useful
things like fixing the real bugs and getting from where we are now to
somewhere useful without causing too much carnage on the way. pr_warning
is an end of the journey polishing job.
The x86 experience doesn't translate here - Andi left you a well
maintained, well polished starting point. Nobody has been maintaining tty
for years.
Alan
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 10:44 ` Alan Cox
@ 2009-07-03 13:17 ` Ingo Molnar
2009-07-03 13:37 ` Alan Cox
0 siblings, 1 reply; 60+ messages in thread
From: Ingo Molnar @ 2009-07-03 13:17 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel, Andrew Morton
* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > > Which is a cut and paste of code from the originals into the
> > > helper.
> >
> > and this changes my points how? It's not like it's hard to fix,
> > and the code is moved non-trivially anyway, it's better to have
> > it nicer if we touch it anyway.
>
> Its called engineering and good practice. The old code was
> correct. The paste of it is therefore most likely to be correct.
> Furthermore patches shouldn't mix clean up with other changes. So
> doing it as one is most definitely bad practice.
So you cannot do such trivial cleanups safely and validate the
result?
> > > > Also note the inconsistent printk-ing lines, mutiliated by
> > > > line warps. The use of pr_warning() would solve it:
> > >
> > > Send patches if it bugs you that much. [...]
> >
> > I find that a rather flippant attitude to kernel code quality
> > issues.
>
> I have better uses for my time than fiddling with pr_warning().
> Fixing real bugs for example, bugs that crash your system, broken
> locking that goes back to Linux 2.2 and DaveM's original push of
> lock_kernel out of IRQ paths
That does not make you exempt from the rules everyone else seems to
be able to follow though ...
> > Also, isnt it a double standard: why should newbies be held to
> > higher standards than you hold yourself to?
>
> Why should anyone be held up to bogus standards ?
I came across this patch of yours on lkml and noticed a few problems
- checkpatch noticed a few more. Is the reviewing of patches and the
commenting on unclean patches a 'bogus standard'? Do we have some
separate standard just for you?
> To bend an appropriate metaphor Ingo - you are trying to criticize
> the paint finish of the bike shed while some of us are still
> replacing the rusted and corroded beams.
> [...]
That metaphor is quite inapposite: type safety and clean coding
standards are way more relevant than just 'paint finish'.
To use a car analogy: if you ever open an engine, regardless of how
corroded it is on the outside, the first thing you will learn is to
work extremely cleanly - otherwise the pistons might get stuck and
the engine blows pretty quickly - or even if you are lucky you've
got a lot more wear and more fuel consumption.
Or to advance your bike-shed metaphor some more: today's rusty and
corroded items are the result of missing anti-corrosion efforts in
the past ...
> If it was a new bike shed you might be in order, but at the moment
> the tty layer is rescue archaeology and I'm spending my time doing
> useful things like fixing the real bugs and getting from where we
> are now to somewhere useful without causing too much carnage on
> the way. pr_warning is an end of the journey polishing job.
>
> The x86 experience doesn't translate here - Andi left you a well
> maintained, well polished starting point. Nobody has been
> maintaining tty for years.
Well, you might not have that experience because you did not take
part in it, but in my first hand experience the x86 situation and
unification translates pretty well to this situation: it was left in
quite a mess and one of the things we learned along the way is that
'temporary crap' is all but temporary and that the sanest
engineering choice is to just produce clean patches.
You might discover that yourself with the TTY layer ... or you might
come to a different conclusion. We'll see.
Anyway ... all i did was to comment on a somewhat deficient patch
that you submitted to lkml. If you dont want review feedback and if
you feel embarrased and defensive by getting it then please dont
send out slightly-messy signed-off patches to lkml, it's simple as
that.
Ingo
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 13:17 ` Ingo Molnar
@ 2009-07-03 13:37 ` Alan Cox
2009-07-03 14:47 ` Ingo Molnar
2009-07-03 16:10 ` [PATCH] vt: add an event interface Ingo Molnar
0 siblings, 2 replies; 60+ messages in thread
From: Alan Cox @ 2009-07-03 13:37 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linux-kernel, Andrew Morton
> > Its called engineering and good practice. The old code was
> > correct. The paste of it is therefore most likely to be correct.
> > Furthermore patches shouldn't mix clean up with other changes. So
> > doing it as one is most definitely bad practice.
>
> So you cannot do such trivial cleanups safely and validate the
> result?
What part of not mixing clean-up with other changes didn't you
understand ?
I'll do them when I am doing the cleanups not midstream. Thats how the
tty layer work has been done so far and I don't plan to change policy now
because the policy is working well with entire files getting shifted to
coding style not just patches of them. It keeps the code consistently
styled.
> I came across this patch of yours on lkml and noticed a few problems
> - checkpatch noticed a few more. Is the reviewing of patches and the
> commenting on unclean patches a 'bogus standard'? Do we have some
> separate standard just for you?
checkpatch is a tool, not a religion. Quite frankly the way some people
behave with it is a disgrace and it puts people off contributing to the
kernel when their 500 line driver gets nothing but emails from people
saying "that space is wrong". At least in your case you can actually
program and your opinion comes from real practise and experience - which
is more than a lot of the self appointed codingstyle police can say.
> Or to advance your bike-shed metaphor some more: today's rusty and
> corroded items are the result of missing anti-corrosion efforts in
> the past ...
So you want to paint it first and then do the engineering ? To give you a
simple example - the tty layer uses pr_warning/pr_err etc *nowhere*. Not
one. I could spend a day changing them all but it would be a stupid
project because many of those printk calls will change by the time we are
finished and don't you think it would be a lot saner if tty_port
structures grew a device pointer and errors at the physical side got
reported with dev_err and friends ?
So I have no time for makework. It might be a good way to get top of the
"patches commited this month" game but it doesn't fix the real problems.
There is a start and an end, and doing things in the wrong order is just
sloppy.
> Anyway ... all i did was to comment on a somewhat deficient patch
> that you submitted to lkml. If you dont want review feedback and if
> you feel embarrased and defensive by getting it then please dont
> send out slightly-messy signed-off patches to lkml, it's simple as
> that.
The message I thought was quite clear about what I was asking for. The
fact you complained about spaces and missed the fact it couldn't even
work was "enlightening" in terms of code review.
Alan
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 13:37 ` Alan Cox
@ 2009-07-03 14:47 ` Ingo Molnar
2009-07-03 15:02 ` Alan Cox
2009-07-03 16:10 ` [PATCH] vt: add an event interface Ingo Molnar
1 sibling, 1 reply; 60+ messages in thread
From: Ingo Molnar @ 2009-07-03 14:47 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel, Andrew Morton
* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > > Its called engineering and good practice. The old code was
> > > correct. The paste of it is therefore most likely to be
> > > correct. Furthermore patches shouldn't mix clean up with other
> > > changes. So doing it as one is most definitely bad practice.
> >
> > So you cannot do such trivial cleanups safely and validate the
> > result?
>
> What part of not mixing clean-up with other changes didn't you
> understand ? [...]
It's an argument you made on false premises.
The thing is, my review wasnt about old code being moved around. It
was about new code being introduced by you:
+ if (copy_from_user(&vw.event, (void __user *)arg, sizeof(struct vt_event)))
+ return -EFAULT;
+ /* Highest supported event for now */
+ if(vw.event.event > VT_MAX_EVENT)
+ return -EINVAL;
Same pattern as in the old commit: you used differing styles just 3
lines apart in new code and apparently didnt even notice it. So i
dont buy your argument at all that you will do 'cleanups later' as
your patch shows ignorance of the whole concept.
Compromising on quality only results in crap being ingrained, it
results in procrastinating and it results in you submitting new code
with basic problems - the very patch here i commented on.
Nor is you assertion correct that fixing basic issues in it has to
degrade it reliability: it can be done safely. In my experience
striving for quality in such a way improves the end result. (the
exception is when moving around whole files or significant chunks of
code - then we preserve the old one, then move it.)
> > I came across this patch of yours on lkml and noticed a few
> > problems - checkpatch noticed a few more. Is the reviewing of
> > patches and the commenting on unclean patches a 'bogus
> > standard'? Do we have some separate standard just for you?
>
> checkpatch is a tool, not a religion. [...]
The thing is, you didnt really answer my question whether you
consider yourself to be accountable to the same standards of quality
as other upstream kernel contributors?
Obviously checkpatch is not a religion - in fact in my reply i gave
a specific example where checkpatch would complain but that
complaint is wrong. Checkpatch is a tool, and the problem is not
that you are not making use of that tool - the problem is that you
are producing unclean code. If you wrote clean code there would be
no reason for anyone to complain.
So just like the religious application of checkpatch is not
acceptable, is the religious avoidance of checkpatch not acceptable
either ;-)
> [...] Quite frankly the way some people behave with it is a
> disgrace and it puts people off contributing to the kernel when
> their 500 line driver gets nothing but emails from people saying
> "that space is wrong". At least in your case you can actually
> program and your opinion comes from real practise and experience -
> which is more than a lot of the self appointed codingstyle police
> can say.
But you are not a newbie driver submitter, are you? Do you consider
yourself exempt from accepted rules of cleanliness, for new code you
submit?
[...]
> > Anyway ... all i did was to comment on a somewhat deficient
> > patch that you submitted to lkml. If you dont want review
> > feedback and if you feel embarrased and defensive by getting it
> > then please dont send out slightly-messy signed-off patches to
> > lkml, it's simple as that.
>
> The message I thought was quite clear about what I was asking for.
> The fact you complained about spaces and missed the fact it
> couldn't even work was "enlightening" in terms of code review.
Here, in support of advancing a false argument you materially
distort the review i gave you, which, in part, said:
| [...]
|
| The cast to void __user * should be done in the ioctl
| demultiplexer vt_ioctl(), and the ioctl ugliness should not
| invade cleaner child functions such as vt_event_wait_ioctl().
|
| - same for vt_event_wait_ioctl() - it passes in a type damaged by
| ioctl's limitations. Such type limitations and ioctl demuxing
| artifacts should be kept local to vt_ioctl().
This goes beyond 'spaces'. Type cleanliness is the first and most
important thing when designing new interfaces - and you just added a
new unclean interface in form of vt_event_wait_ioctl().
Ingo
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 14:47 ` Ingo Molnar
@ 2009-07-03 15:02 ` Alan Cox
2009-07-03 15:42 ` Ingo Molnar
` (3 more replies)
0 siblings, 4 replies; 60+ messages in thread
From: Alan Cox @ 2009-07-03 15:02 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linux-kernel, Andrew Morton
> It's an argument you made on false premises.
>
> The thing is, my review wasnt about old code being moved around. It
> was about new code being introduced by you:
Ingo, if you've nothing better to do than quote out of context and be
offensive, perhaps you should go fix voyager support or something
productive instead.
The reply section you are quoting was about the code that was moved from
place to place. I stand by that comment - you don't move code from place
to place and reformat, rework it in one go. It's lousy engineering.
>
> + if (copy_from_user(&vw.event, (void __user *)arg, sizeof(struct vt_event)))
> + return -EFAULT;
> + /* Highest supported event for now */
> + if(vw.event.event > VT_MAX_EVENT)
> + return -EINVAL;
>
> Same pattern as in the old commit: you used differing styles just 3
> lines apart in new code and apparently didnt even notice it. So i
> dont buy your argument at all that you will do 'cleanups later' as
> your patch shows ignorance of the whole concept.
Which was a draft patch with a question, it hadn't even been compiled and
it was obvious at first glance it contained errors - yet you didn't
notice that just spaces.
> > checkpatch is a tool, not a religion. [...]
>
> The thing is, you didnt really answer my question whether you
> consider yourself to be accountable to the same standards of quality
> as other upstream kernel contributors?
I did answer it, I guess you didn't like the answer ?
> But you are not a newbie driver submitter, are you? Do you consider
> yourself exempt from accepted rules of cleanliness, for new code you
> submit?
This wasn't code being submitted - which has been pointed out to you
several times.
> > The message I thought was quite clear about what I was asking for.
> > The fact you complained about spaces and missed the fact it
> > couldn't even work was "enlightening" in terms of code review.
>
> Here, in support of advancing a false argument you materially
You mean you think its not relevant that you saw spacing and format
differences but couldn't spot the fact the code had obvious errors and
hadn't been compiled ? Its a sketch no more.
> This goes beyond 'spaces'. Type cleanliness is the first and most
> important thing when designing new interfaces - and you just added a
> new unclean interface in form of vt_event_wait_ioctl().
See comment #1 made in the very first message to you - it was an initial
draft, and if you'd stop trying to cover the fact you were so space and
formatting obsessed you missed the fact it wasn't even compilable code
perhaps we'd get somewhere useful.
Finally look up "Signed-off-by:", if you think it means "this is code I
think is perfection" you are wrong. I quote
"The sign-off is a simple line at the end of the explanation for the
patch, which certifies that you wrote it or otherwise have the right to
pass it on as a open-source patch."
Period and the draft I posted is exactly that.
Now if you'll pardon me I have real work to do while you macdink
space characters.
Alan
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 15:02 ` Alan Cox
@ 2009-07-03 15:42 ` Ingo Molnar
2009-07-03 15:48 ` Ingo Molnar
` (2 subsequent siblings)
3 siblings, 0 replies; 60+ messages in thread
From: Ingo Molnar @ 2009-07-03 15:42 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel, Andrew Morton
* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > It's an argument you made on false premises.
> >
> > The thing is, my review wasnt about old code being moved around. It
> > was about new code being introduced by you:
>
> Ingo, if you've nothing better to do than quote out of context and
> be offensive, perhaps you should go fix voyager support or
> something productive instead.
>
> The reply section you are quoting was about the code that was
> moved from place to place. I stand by that comment - you don't
> move code from place to place and reformat, rework it in one go.
> It's lousy engineering.
Your claim is simply false on its face. This commit:
| commit a6614999e800cf3a134ce93ea46ef837e3c0e76e
| Author: Alan Cox <alan@redhat.com>
| Date: Fri Jan 2 13:46:50 2009 +0000
|
| tty: Introduce some close helpers for ports
did not 'move' the piece of code i quoted around:
+ if( tty->count == 1 && port->count != 1) {
+ printk(KERN_WARNING
+ "tty_port_close_start: tty->count = 1 port count = %d.\n",
+ port->count);
+ port->count = 1;
+ }
+ if (--port->count < 0) {
+ printk(KERN_WARNING "tty_port_close_start: count = %d\n",
+ port->count);
+ port->count = 0;
+ }
it introduces it. This line:
+ if( tty->count == 1 && port->count != 1) {
can be found nowhere else in the commit. You added it.
In fact, if one looks closer, it turns out that:
$ git log -p -1 a6614999e800cf3a134ce93ea46ef837e3c0e76e | grep -iE 'if.*tty->count'
- if (tty->count == 1 && port->port.count != 1) {
- if (tty->count == 1 && port->count != 1)
- if ((tty->count == 1) && (info->port.count != 1)) {
- if ((tty->count == 1) && (port->port.count != 1)) {
- if (tty->count == 1 && port->count != 1)
- if ((tty->count == 1) && (info->port.count != 1)) {
- if ((tty->count == 1) && (info->port.count != 1)) {
- if ((tty->count == 1) && (info->port.count != 1)) {
+ if( tty->count == 1 && port->count != 1) {
that you consolidate 8 separate pieces of code, all of which got
this basic detail right, and you _introduced_ the uncleanliness.
Ingo
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 15:02 ` Alan Cox
2009-07-03 15:42 ` Ingo Molnar
@ 2009-07-03 15:48 ` Ingo Molnar
2009-07-03 16:11 ` Alan Cox
2009-07-03 15:57 ` Ingo Molnar
2009-07-03 15:58 ` Ingo Molnar
3 siblings, 1 reply; 60+ messages in thread
From: Ingo Molnar @ 2009-07-03 15:48 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel, Andrew Morton
* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > The thing is, you didnt really answer my question whether you
> > consider yourself to be accountable to the same standards of
> > quality as other upstream kernel contributors?
>
> I did answer it, I guess you didn't like the answer ?
You did not answer it really, you questioned the validity of the
question:
| > Also, isnt it a double standard: why should newbies be held to
| > higher standards than you hold yourself to?
|
| Why should anyone be held up to bogus standards ?
|
| [...]
So did i get you right that in your opinion sending and writing
clean code is a 'bogus standard'? Sorry about trying to interpret
you here, i have no choice because you did not reply to my question.
I thought the obvious portions of Documentation/CodingStyle applied
to everyone - so it applies to you only if you like it?
Ingo
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 15:02 ` Alan Cox
2009-07-03 15:42 ` Ingo Molnar
2009-07-03 15:48 ` Ingo Molnar
@ 2009-07-03 15:57 ` Ingo Molnar
2009-07-03 15:58 ` Ingo Molnar
3 siblings, 0 replies; 60+ messages in thread
From: Ingo Molnar @ 2009-07-03 15:57 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel, Andrew Morton
* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > It's an argument you made on false premises.
> >
> > The thing is, my review wasnt about old code being moved around. It
> > was about new code being introduced by you:
>
> Ingo, if you've nothing better to do than quote out of context and
> be offensive, perhaps you should go fix voyager support or
> something productive instead.
Btw., i'd like to know which reply of mine you found offensive.
Pointing out when your code is unclean does not count as an offense
on lkml, i hope. The rest was disagreements about how to handle
cleanups - i dont think i made any personal/offensive comment in
this thread, nor do i intend to.
Ingo
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 15:02 ` Alan Cox
` (2 preceding siblings ...)
2009-07-03 15:57 ` Ingo Molnar
@ 2009-07-03 15:58 ` Ingo Molnar
2009-07-03 16:26 ` Alan Cox
3 siblings, 1 reply; 60+ messages in thread
From: Ingo Molnar @ 2009-07-03 15:58 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel, Andrew Morton
* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > It's an argument you made on false premises.
> >
> > The thing is, my review wasnt about old code being moved around. It
> > was about new code being introduced by you:
>
> Ingo, if you've nothing better to do than quote out of context and
> be offensive, perhaps you should go fix voyager support or
> something productive instead.
Another question: i'm wondering why you brought up Voyager support
here. Are you trying to insult me?
Ingo
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 13:37 ` Alan Cox
2009-07-03 14:47 ` Ingo Molnar
@ 2009-07-03 16:10 ` Ingo Molnar
2009-07-03 18:24 ` Alan Cox
1 sibling, 1 reply; 60+ messages in thread
From: Ingo Molnar @ 2009-07-03 16:10 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel, Andrew Morton
* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> [...] Quite frankly the way some people behave with it is a
> disgrace and it puts people off contributing to the kernel when
> their 500 line driver gets nothing but emails from people saying
> "that space is wrong". [...]
I'd like to address your generic argument here because i think it's
interesting.
The thing is, IMO if the author or the affected maintainer(s) are
not willing to do _basic_ cleanup of new drivers, they simply dont
deserve more substantial review.
Why? Because their lack of basic care is a sign that they will
likely be unwilling to expend the (far bigger) effort of actually do
ongoing maintenance of the driver.
drivers/isdn/ is one example of unclean code, which, once it got
upstream, never got cleaned up.
Its also a positive feedback loop: lack of basic cleanups deters
contributors (for example i personally try to stay away from 'weird
looking' code as 'not worth the effort'), which makes the code even
worse ... which then bitrots as kernel facilities slowly change as
the months go on.
So such unclean drivers you mention above should probably go to
drivers/staging/ - that is an effort that tries to de-crappify
drivers before they get mixed into core drivers.
All in one, i dont see at all the harm from people looking at
stylistic issues first - it's an obvious first easy level of trust
to inject into an unknown piece of code - if the reply to that
minimal stylistic review is fixes then it makes sense to inject more
effort into reviewing the driver. If the reply is defiance or
inaction then the reviewer probably should not bother because nobody
cares about his feedback.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 15:48 ` Ingo Molnar
@ 2009-07-03 16:11 ` Alan Cox
2009-07-03 16:24 ` Ingo Molnar
0 siblings, 1 reply; 60+ messages in thread
From: Alan Cox @ 2009-07-03 16:11 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linux-kernel, Andrew Morton
> So did i get you right that in your opinion sending and writing
> clean code is a 'bogus standard'? Sorry about trying to interpret
> you here, i have no choice because you did not reply to my question.
Your definition of "clean code" being ?
> I thought the obvious portions of Documentation/CodingStyle applied
> to everyone - so it applies to you only if you like it?
CodingStyle is a guide - it applies as a guide to people. It's also lower
priority than working code. Which is why for example we have staging.
Linus pretty clearly ruled where the priorities were I think in accepting
staging.
Now my pending queue has a collection of patches that make the
CodingStyle script whine. I don't care because they improve the cyclades
driver and they are heading in the right direction. Funnily enough none
of the vt patches pending make it moan at all having just checkpatched
them for amusement.
I have every intention of sending them upstream because the patch author
has the technical details right, they make the driver better and they fix
bugs.
vt has 329 codingstyle complaints. Most of that code hasn't changed in
years so a policy of pointless macdinking new patches won't change it but
will mess up the internally consistent style. Instead when vt is settled
down and cleaned up it can have a single cleanup pass. Which is what
happened to various of the tty files as they reached that state.
I could whine about spaces and make the author rewrite them and rework
them so that they made the cyclades driver suffer random weird changes
between its format and CodingStyle but would that actually be a
productive use of anyones time - no.
I don't care if you want to run a policy where you refuse x86 improvements
because there is a misplaced space. If it makes you happy so be it. OTOH
I am not going to drive people away from contributing to the kernel by
forgetting that CodingStyle is a guide, or that a lot of existing kernel
code doesn't follow it and is best patched by keeping it in its original
style.
The other thing CodingStyle is doing now is creating code which is utterly
crap but passes the CodingStyle file because some poor low paid sod in a
software shop somewhere has been told to supply a Linux driver that
passes CodingStyle. Note one that is any good, not one that is following
any Linux code guidelines, not even one that is tested. Instead its become
this monster that less Linux literate software businesses are using to
sign off contracts with in some expectation that "hey it passes
CodingStyle it'll go in" and get outraged when it's refused.
If you want to fix the tty layer to be coding style perfect then send
patches, but there are tons of coding style problems in arch/x86 if you
feel so strongly about it.
Alan
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 16:11 ` Alan Cox
@ 2009-07-03 16:24 ` Ingo Molnar
2009-07-03 18:29 ` Alan Cox
0 siblings, 1 reply; 60+ messages in thread
From: Ingo Molnar @ 2009-07-03 16:24 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel, Andrew Morton
* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > So did i get you right that in your opinion sending and writing
> > clean code is a 'bogus standard'? Sorry about trying to
> > interpret you here, i have no choice because you did not reply
> > to my question.
>
> Your definition of "clean code" being ?
Clean code is one that is not unclean. Unclean code is for example
one that does:
+ if( tty->count == 1 && port->count != 1) {
and you pushed that piece of code upstream, and you called
checkpatch a religion - so apparently you were not using that tool
and apparently you think it's fine to push such changes upstream.
I.e. your action proves that you are willing to push unclean code,
and you gave various explanations about why you are not using tools
that can catch such mistake . Am i allowed to express my
disagreement with that notion?
> > I thought the obvious portions of Documentation/CodingStyle
> > applied to everyone - so it applies to you only if you like it?
>
> CodingStyle is a guide - it applies as a guide to people. It's
> also lower priority than working code. Which is why for example we
> have staging. Linus pretty clearly ruled where the priorities were
> I think in accepting staging. [...]
But drivers/char/ is not in drivers/staging/, is it?
If you cite drivers/staging/ an argument to introduce unclean code
into core pieces of Linux then i think you are dead wrong ...
Yes, any textual guide about code is pretty much by definition just
a guide - to be overruled by common sense as usual.
And i dont think there exists a valid interpretation that says that
this introduction of unclean code:
$ git log -p -1 a6614999e800cf3a134ce93ea46ef837e3c0e76e | grep -iE 'if.*tty->count'
- if (tty->count == 1 && port->port.count != 1) {
- if (tty->count == 1 && port->count != 1)
- if ((tty->count == 1) && (info->port.count != 1)) {
- if ((tty->count == 1) && (port->port.count != 1)) {
- if (tty->count == 1 && port->count != 1)
- if ((tty->count == 1) && (info->port.count != 1)) {
- if ((tty->count == 1) && (info->port.count != 1)) {
- if ((tty->count == 1) && (info->port.count != 1)) {
+ if( tty->count == 1 && port->count != 1) {
was warranted by any common-sense argument. You changed well-working
code into something different (and unclean) and you - as you have
repeatedly pointed it out in this thread - disagree with using
checkpatch - why? It makes no technical sense.
Yes, it's all a minor issue in the end - but you chose to argue
about the technical review feedback (which i still consider
correct), not me.
Ingo
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 15:58 ` Ingo Molnar
@ 2009-07-03 16:26 ` Alan Cox
2009-07-03 16:33 ` Ingo Molnar
2009-07-03 16:42 ` Ingo Molnar
0 siblings, 2 replies; 60+ messages in thread
From: Alan Cox @ 2009-07-03 16:26 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linux-kernel, Andrew Morton
> Another question: i'm wondering why you brought up Voyager support
> here. Are you trying to insult me?
[and]
> Pointing out when your code is unclean does not count as an offense
> on lkml, i hope
Nor then I trust does pointing out that voyager needs a bit of work ;)
I've no objection to pointing out unclean code (or to patches). If
someone wants to fix all the printk(KERN_ calls in the tty layer for for
it - great newbie project if a bit tedious I'd be delighted to receive the
patches.
I'm still however utterly incredulous that you'd look at that bit of
proposed code and see a formatting glitch but not that fact it couldn't
possibly work. I'm still glad you did look at it - don't get me wrong.
The way the tty layer work is done is like this and has been for almost
two years
- Identify whats the next best thing to tackle on the giant pile
of sucky turd list
- Rework it
- Debug it
- If it makes that piece of the code completeish whack the entire
file through the coding style process (eg
fe9cd962a62cb5f666cf48b9941d3f3cde134254,
fb100b6ea7bf8a95e52b90cc0dc0ea5744a0a40a etc)
- Whines about > 80 characters get ignored
for text strings
That not only makes it easier to keep consistent internal styles, merge
patches without collision and keep code and style changes apart it means
that stuff gets cleaned up that doesn't otherwise change.
A good example of what happens if you don't is
scripts/checkpatch.pl --file arch/x86/kernel/cpu/mtrr/*c
where the core part of the code isn't changed very much even though the
interfaces completely get reworked. Thus it never gets cleaned up and
reviewed as a whole. The code works, will probably work for years but
never gets looked at as a whole and tidied.
Alan
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 16:26 ` Alan Cox
@ 2009-07-03 16:33 ` Ingo Molnar
2009-07-03 16:42 ` Ingo Molnar
1 sibling, 0 replies; 60+ messages in thread
From: Ingo Molnar @ 2009-07-03 16:33 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel, Andrew Morton
* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > > Ingo, if you've nothing better to do than quote out of context
> > > and be offensive, perhaps you should go fix voyager support or
> > > something productive instead.
> > >
> > Another question: i'm wondering why you brought up Voyager
> > support here. Are you trying to insult me?
>
> [and]
>
> > Pointing out when your code is unclean does not count as an
> > offense on lkml, i hope
>
> Nor then I trust does pointing out that voyager needs a bit of
> work ;)
Voyager is not upstream anymore so i dont understand your point ...
I do think the Voyager code needs a lot of work, and i reviewed the
patches that were submitted. I'm aware of no Voyager patch series
that i find acceptable, and the things i noticed so far already mean
quite a bit of work.
Ingo
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 16:26 ` Alan Cox
2009-07-03 16:33 ` Ingo Molnar
@ 2009-07-03 16:42 ` Ingo Molnar
2009-07-03 22:17 ` Jaswinder Singh Rajput
` (11 more replies)
1 sibling, 12 replies; 60+ messages in thread
From: Ingo Molnar @ 2009-07-03 16:42 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel, Andrew Morton
* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> A good example of what happens if you don't is
>
> scripts/checkpatch.pl --file arch/x86/kernel/cpu/mtrr/*c
>
> where the core part of the code isn't changed very much even
> though the interfaces completely get reworked. Thus it never gets
> cleaned up and reviewed as a whole. The code works, will probably
> work for years but never gets looked at as a whole and tidied.
I think even the MTRR code (which is indeed one of the few x86
places still not fully cleaned up) supports my arguments.
Look at the averages:
errors lines of code errors/KLOC
arch/x86/kernel/cpu/mtrr/amd.c 2 120 16.6
arch/x86/kernel/cpu/mtrr/centaur.c 8 225 35.5
arch/x86/kernel/cpu/mtrr/cleanup.c 0 1102 0
arch/x86/kernel/cpu/mtrr/cyrix.c 10 275 36.3
arch/x86/kernel/cpu/mtrr/generic.c 16 730 21.9
arch/x86/kernel/cpu/mtrr/if.c 11 428 25.7
arch/x86/kernel/cpu/mtrr/main.c 50 751 66.5
arch/x86/kernel/cpu/mtrr/state.c 0 83 0
The arch/x86/kernel/cpu/mtrr/cleanup.c file is a new bit and
relatively clean.
Ingo
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 16:10 ` [PATCH] vt: add an event interface Ingo Molnar
@ 2009-07-03 18:24 ` Alan Cox
0 siblings, 0 replies; 60+ messages in thread
From: Alan Cox @ 2009-07-03 18:24 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linux-kernel, Andrew Morton
> The thing is, IMO if the author or the affected maintainer(s) are
> not willing to do _basic_ cleanup of new drivers, they simply dont
> deserve more substantial review.
That ignores what is actually going on:
Firstly what happens is someone posts a draft of their new driver. What
they get back is
- Mails from people who clearly can't work a compiler but can run
checkpatch and have nothing useful to do, who complain about spaces and
brackets
- Little or no feedback on actual code
What they actually need is
- Feedback on the code - particularly algorithms, areas they could use
kernel library functions better, obvious design flaws
- Feedback on gross style issues ("Dude lose the Hungarian notation") NOT
"Checkpatch says line 151 has a bogus space haha you suck" which is how
the sort of replies they get today must feel. Even things like "here's
a handy indent script". Stupid as it sounds I stopped one driver vendor
throwing in the towel simply because they didn't know about indent,
nobody told them and they thought they'd have to assign one of their
developers to play space pusher.
There is a simple reason for focussing on big code issues (and major
style) first:
If the code has minor style issues then fine for a new driver at the end
of the day it is important to clean it up. That goes even for the stuff
Checkpatch doesn't handle (like taste). There is however no point doing
that for minor style until the code is algorithmically and generally
stylistically in shape because much of what you clean up may not be there
in the final version anyway.
So the world the checkpatch nutters create is one where a newcomer cannot
get useful feedback on their code without fixing every single space, in
order to be told after that actually you know 2/3rds of that code can be
deleted and use the rbtree library instead. That's just wrong and a huge
block to new users. What is worse is for a lot of submissions what you
actually get is the can't work a C compiler checkpatch nutters whining
about silly spaces issues and then when that is finished the actual
submission gets ignored - totally - despite the efforts of a few people
(official hero AKPM notably) to catch them all.
In the case where someone submits a new driver that is elegant code with
minor style problems, then and only then is it appropriate to say "please
tidy that comment to fit 80 columns". It would be nice if the people
doing that could a) program and b) bothered to say things like "nice
code, structure looks right, just needs a final polish" rather than
parroting checkpatch pastes.
(Real world reality check for people here: Faced with a student who hands
in a badly presented first draft of a school assignment with good basic
facts does the teacher
- read out loud each minor spelling mistake for the class to laugh at
or - point out the strong areas, categorise the general weaknesses and
suggest strategies for improvement, and while maybe suggesting
using the spellchecker, believe the student can work that out if
they are told it will be important next time
Its an obvious answer, yet the kernel list is increasingly operating in
the wrong mode and we (all) need to fix that.
)
> So such unclean drivers you mention above should probably go to
> drivers/staging/ - that is an effort that tries to de-crappify
> drivers before they get mixed into core drivers.
Staging is a big help as it provides an idiot evasion system, but most
people submitting initial patches and bits of code don't know about it.
> All in one, i dont see at all the harm from people looking at
> stylistic issues first
Imagine if Shakespeare had first been reviewed from the point of view of
stylistic compliance with the recommended grammar, language and spelling
of his day.
I have one big driver in mind btw which I suspect will hit staging at some
point when released. It passes checkpatch perfectly. Its everything a
checkpatch weenie could dribble over. Its also absolutely godawful. It's
been recommended to go via staging for that reason.
We are going to get lots more wasted effort of that kind unless people
both in the community and outside it stop treating checkpatch as a rule
system, an arbiter of taste and the definition of what goes in tree.
Right now there are people out there writing contracts to "provide a
Linux driver that passes the checkpatch script", not that works or is
good upstream code.
Incidentally if there are people reading this who really enjoy all the
niggly little checkpatch hunting and twiddling its a great use of that
talent to pick off older in tree code and fix it to pass checkpatch. That
code is already in tree, and wants tidying.
Alan
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 16:24 ` Ingo Molnar
@ 2009-07-03 18:29 ` Alan Cox
2009-07-03 18:41 ` Ingo Molnar
0 siblings, 1 reply; 60+ messages in thread
From: Alan Cox @ 2009-07-03 18:29 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linux-kernel, Andrew Morton
> + if( tty->count == 1 && port->count != 1) {
>
> and you pushed that piece of code upstream, and you called
> checkpatch a religion - so apparently you were not using that tool
> and apparently you think it's fine to push such changes upstream.
The discussion started about something else - a piece of non-compilable
proposal code you space reviewed and didn't even notice wasn't
compileable or sane.
I'm sort of amused you went back through my commits to find that example,
and its certainly one that should have been fixed in the final submit. I
can't be bothered to write a perl script to checkpatch all your commits
and I suspect they all pass anyway.
I don't have a problem with that specific example you dug up being wrong.
Its the "take a piece of non compileable initial sketch proposal, bitch
about spaces and clearly not even look at the code itself" bit that
bothers me.
If I'd have received "hey thats crap, your vt_waitactive conversion
can't possibly work, and the console events are all off by one" I'd have
understood it and agreed entirely (with or without the space note)
Alan
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 18:29 ` Alan Cox
@ 2009-07-03 18:41 ` Ingo Molnar
0 siblings, 0 replies; 60+ messages in thread
From: Ingo Molnar @ 2009-07-03 18:41 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel, Andrew Morton
* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > + if( tty->count == 1 && port->count != 1) {
> >
> > and you pushed that piece of code upstream, and you called
> > checkpatch a religion - so apparently you were not using that
> > tool and apparently you think it's fine to push such changes
> > upstream.
>
> The discussion started about something else - a piece of
> non-compilable proposal code you space reviewed and didn't even
> notice wasn't compileable or sane.
>
> I'm sort of amused you went back through my commits to find that
> example, and its certainly one that should have been fixed in the
> final submit. I can't be bothered to write a perl script to
> checkpatch all your commits and I suspect they all pass anyway.
FYI, it took me less than 10 seconds to find that commit, i didnt
have to go to any trouble or perl script - i just searched for the
same bad pattern i saw here.
You should consider putting in some automation into your workflow if
you have some time - it really helps. I was surprised how much
easily fixable crap various measures of automation found in my own
patches. The tools are there to use them, not to ignore, ridicule or
fight them, and for kernel oldbies there's absolutely no valid
excuse to not use them IMHO.
It's a bit sad you are making such a big deal out of my criticism
though. Your criticism about the x86/MTRR code was spot on, mind
doing some more review on arch/x86/?
Ingo
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-03 16:42 ` Ingo Molnar
@ 2009-07-03 22:17 ` Jaswinder Singh Rajput
2009-07-04 2:18 ` [GIT PULL -tip][PATCH 0/9] MTRR fix trivial style patches Jaswinder Singh Rajput
` (10 subsequent siblings)
11 siblings, 0 replies; 60+ messages in thread
From: Jaswinder Singh Rajput @ 2009-07-03 22:17 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Alan Cox, linux-kernel, Andrew Morton
On Fri, 2009-07-03 at 18:42 +0200, Ingo Molnar wrote:
> * Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> > A good example of what happens if you don't is
> >
> > scripts/checkpatch.pl --file arch/x86/kernel/cpu/mtrr/*c
> >
> > where the core part of the code isn't changed very much even
> > though the interfaces completely get reworked. Thus it never gets
> > cleaned up and reviewed as a whole. The code works, will probably
> > work for years but never gets looked at as a whole and tidied.
>
> I think even the MTRR code (which is indeed one of the few x86
> places still not fully cleaned up) supports my arguments.
>
> Look at the averages:
>
> errors lines of code errors/KLOC
> arch/x86/kernel/cpu/mtrr/amd.c 2 120 16.6
> arch/x86/kernel/cpu/mtrr/centaur.c 8 225 35.5
> arch/x86/kernel/cpu/mtrr/cleanup.c 0 1102 0
> arch/x86/kernel/cpu/mtrr/cyrix.c 10 275 36.3
> arch/x86/kernel/cpu/mtrr/generic.c 16 730 21.9
> arch/x86/kernel/cpu/mtrr/if.c 11 428 25.7
> arch/x86/kernel/cpu/mtrr/main.c 50 751 66.5
> arch/x86/kernel/cpu/mtrr/state.c 0 83 0
>
> The arch/x86/kernel/cpu/mtrr/cleanup.c file is a new bit and
> relatively clean.
>
I will fix these ASAP ;-)
Thanks,
--
JSR
^ permalink raw reply [flat|nested] 60+ messages in thread
* [GIT PULL -tip][PATCH 0/9] MTRR fix trivial style patches
2009-07-03 16:42 ` Ingo Molnar
2009-07-03 22:17 ` Jaswinder Singh Rajput
@ 2009-07-04 2:18 ` Jaswinder Singh Rajput
2009-07-04 2:20 ` [PATCH 1/9 -tip] x86: mtrr/amd.c fix trivial style problems Jaswinder Singh Rajput
2009-07-05 18:21 ` [GIT PULL -tip][PATCH 0/9] MTRR fix trivial style patches Ingo Molnar
2009-07-04 10:06 ` [tip:x86/cleanups] x86: Clean up mtrr/amd.c: tip-bot for Jaswinder Singh Rajput
` (9 subsequent siblings)
11 siblings, 2 replies; 60+ messages in thread
From: Jaswinder Singh Rajput @ 2009-07-04 2:18 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Alan Cox, linux-kernel, Andrew Morton, Yinghai Lu
On Fri, 2009-07-03 at 18:42 +0200, Ingo Molnar wrote:
> * Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> > A good example of what happens if you don't is
> >
> > scripts/checkpatch.pl --file arch/x86/kernel/cpu/mtrr/*c
> >
> > where the core part of the code isn't changed very much even
> > though the interfaces completely get reworked. Thus it never gets
> > cleaned up and reviewed as a whole. The code works, will probably
> > work for years but never gets looked at as a whole and tidied.
>
> I think even the MTRR code (which is indeed one of the few x86
> places still not fully cleaned up) supports my arguments.
>
> Look at the averages:
>
> errors lines of code errors/KLOC
> arch/x86/kernel/cpu/mtrr/amd.c 2 120 16.6
> arch/x86/kernel/cpu/mtrr/centaur.c 8 225 35.5
> arch/x86/kernel/cpu/mtrr/cleanup.c 0 1102 0
> arch/x86/kernel/cpu/mtrr/cyrix.c 10 275 36.3
> arch/x86/kernel/cpu/mtrr/generic.c 16 730 21.9
> arch/x86/kernel/cpu/mtrr/if.c 11 428 25.7
> arch/x86/kernel/cpu/mtrr/main.c 50 751 66.5
> arch/x86/kernel/cpu/mtrr/state.c 0 83 0
>
By these trivial mtrr cleanup patches:
errors
arch/x86/kernel/cpu/mtrr/amd.c 0
arch/x86/kernel/cpu/mtrr/centaur.c 0
arch/x86/kernel/cpu/mtrr/cleanup.c 0
arch/x86/kernel/cpu/mtrr/cyrix.c 0
arch/x86/kernel/cpu/mtrr/generic.c 0
arch/x86/kernel/cpu/mtrr/if.c 0
arch/x86/kernel/cpu/mtrr/main.c 0
arch/x86/kernel/cpu/mtrr/state.c 0
The following changes since commit 2137f10fd78ce8540ec4305f4dcd559039444544:
Ingo Molnar (1):
Merge branch 'perfcounters/urgent'
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jaswinder/linux-2.6-top.git master
Jaswinder Singh Rajput (9):
x86: mtrr/amd.c fix trivial style problems
x86: mtrr/centaur.c fix style problems
x86: mtrr/cleanup.c fix trivial style problems
x86: mtrr/cyrix.c fix trivial style problems
x86: mtrr/generic.c fix style problems
x86: mtrr/if.c fix trivial style problems
x86: mtrr/mtrr.h fix trivial style problems
x86: mtrr/state.c fix trivial style problems
x86: mtrr/main.c fix style problems
arch/x86/kernel/cpu/mtrr/amd.c | 7 +-
arch/x86/kernel/cpu/mtrr/centaur.c | 127 +++----------------------
arch/x86/kernel/cpu/mtrr/cleanup.c | 18 ++--
arch/x86/kernel/cpu/mtrr/cyrix.c | 30 +++---
arch/x86/kernel/cpu/mtrr/generic.c | 147 +++++++++++++++-------------
arch/x86/kernel/cpu/mtrr/if.c | 51 +++++++----
arch/x86/kernel/cpu/mtrr/main.c | 185 +++++++++++++++++++-----------------
arch/x86/kernel/cpu/mtrr/mtrr.h | 7 +-
arch/x86/kernel/cpu/mtrr/state.c | 20 +++--
9 files changed, 263 insertions(+), 329 deletions(-)
^ permalink raw reply [flat|nested] 60+ messages in thread
* [PATCH 1/9 -tip] x86: mtrr/amd.c fix trivial style problems
2009-07-04 2:18 ` [GIT PULL -tip][PATCH 0/9] MTRR fix trivial style patches Jaswinder Singh Rajput
@ 2009-07-04 2:20 ` Jaswinder Singh Rajput
2009-07-04 2:20 ` [PATCH 2/9 -tip] x86: mtrr/centaur.c fix " Jaswinder Singh Rajput
2009-07-05 18:21 ` [GIT PULL -tip][PATCH 0/9] MTRR fix trivial style patches Ingo Molnar
1 sibling, 1 reply; 60+ messages in thread
From: Jaswinder Singh Rajput @ 2009-07-04 2:20 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Alan Cox, linux-kernel, Andrew Morton, Yinghai Lu
Fix trivial style problems :
ERROR: trailing whitespace
WARNING: line over 80 characters
ERROR: do not use C99 // comments
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
---
arch/x86/kernel/cpu/mtrr/amd.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/amd.c b/arch/x86/kernel/cpu/mtrr/amd.c
index ee2331b..85105d3 100644
--- a/arch/x86/kernel/cpu/mtrr/amd.c
+++ b/arch/x86/kernel/cpu/mtrr/amd.c
@@ -71,7 +71,7 @@ static void amd_set_mtrr(unsigned int reg, unsigned long base,
/* Set the register to the base, the type (off by one) and an
inverted bitmask of the size The size is the only odd
bit. We are fed say 512K We invert this and we get 111 1111
- 1111 1011 but if you subtract one and invert you get the
+ 1111 1011 but if you subtract one and invert you get the
desired 111 1111 1111 1100 mask
But ~(x - 1) == ~x + 1 == -x. Two's complement rocks! */
@@ -86,7 +86,8 @@ static void amd_set_mtrr(unsigned int reg, unsigned long base,
wrmsr(MSR_K6_UWCCR, regs[0], regs[1]);
}
-static int amd_validate_add_page(unsigned long base, unsigned long size, unsigned int type)
+static int amd_validate_add_page(unsigned long base, unsigned long size,
+ unsigned int type)
{
/* Apply the K6 block alignment and size rules
In order
@@ -115,5 +116,3 @@ int __init amd_init_mtrr(void)
set_mtrr_ops(&amd_mtrr_ops);
return 0;
}
-
-//arch_initcall(amd_mtrr_init);
--
1.6.0.6
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH 2/9 -tip] x86: mtrr/centaur.c fix style problems
2009-07-04 2:20 ` [PATCH 1/9 -tip] x86: mtrr/amd.c fix trivial style problems Jaswinder Singh Rajput
@ 2009-07-04 2:20 ` Jaswinder Singh Rajput
2009-07-04 2:21 ` [PATCH 3/9 -tip] x86: mtrr/cleanup.c fix trivial " Jaswinder Singh Rajput
0 siblings, 1 reply; 60+ messages in thread
From: Jaswinder Singh Rajput @ 2009-07-04 2:20 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Alan Cox, linux-kernel, Andrew Morton, Yinghai Lu
Remove dead code.
and fix trivial style problems:
ERROR: trailing whitespace X 2
WARNING: line over 80 characters X 3
ROR: trailing whitespace
ERROR: do not use C99 // comments X 2
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
---
arch/x86/kernel/cpu/mtrr/centaur.c | 127 ++++--------------------------------
1 files changed, 12 insertions(+), 115 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/centaur.c b/arch/x86/kernel/cpu/mtrr/centaur.c
index cb9aa3a..1350ab3 100644
--- a/arch/x86/kernel/cpu/mtrr/centaur.c
+++ b/arch/x86/kernel/cpu/mtrr/centaur.c
@@ -13,7 +13,7 @@ static u8 centaur_mcr_reserved;
static u8 centaur_mcr_type; /* 0 for winchip, 1 for winchip2 */
/*
- * Report boot time MCR setups
+ * Report boot time MCR setups
*/
static int
@@ -54,7 +54,8 @@ centaur_get_mcr(unsigned int reg, unsigned long *base,
{
*base = centaur_mcr[reg].high >> PAGE_SHIFT;
*size = -(centaur_mcr[reg].low & 0xfffff000) >> PAGE_SHIFT;
- *type = MTRR_TYPE_WRCOMB; /* If it is there, it is write-combining */
+ *type = MTRR_TYPE_WRCOMB; /* write-combining */
+
if (centaur_mcr_type == 1 && ((centaur_mcr[reg].low & 31) & 2))
*type = MTRR_TYPE_UNCACHABLE;
if (centaur_mcr_type == 1 && (centaur_mcr[reg].low & 31) == 25)
@@ -75,12 +76,13 @@ static void centaur_set_mcr(unsigned int reg, unsigned long base,
} else {
high = base << PAGE_SHIFT;
if (centaur_mcr_type == 0)
- low = -size << PAGE_SHIFT | 0x1f; /* only support write-combining... */
+ /* only support write-combining... */
+ low = -size << PAGE_SHIFT | 0x1f;
else {
if (type == MTRR_TYPE_UNCACHABLE)
- low = -size << PAGE_SHIFT | 0x02; /* NC */
+ low = -size << PAGE_SHIFT | 0x02; /* NC */
else
- low = -size << PAGE_SHIFT | 0x09; /* WWO,WC */
+ low = -size << PAGE_SHIFT | 0x09; /* WWO,WC */
}
}
centaur_mcr[reg].high = high;
@@ -88,118 +90,16 @@ static void centaur_set_mcr(unsigned int reg, unsigned long base,
wrmsr(MSR_IDT_MCR0 + reg, low, high);
}
-#if 0
-/*
- * Initialise the later (saner) Winchip MCR variant. In this version
- * the BIOS can pass us the registers it has used (but not their values)
- * and the control register is read/write
- */
-
-static void __init
-centaur_mcr1_init(void)
-{
- unsigned i;
- u32 lo, hi;
-
- /* Unfortunately, MCR's are read-only, so there is no way to
- * find out what the bios might have done.
- */
-
- rdmsr(MSR_IDT_MCR_CTRL, lo, hi);
- if (((lo >> 17) & 7) == 1) { /* Type 1 Winchip2 MCR */
- lo &= ~0x1C0; /* clear key */
- lo |= 0x040; /* set key to 1 */
- wrmsr(MSR_IDT_MCR_CTRL, lo, hi); /* unlock MCR */
- }
-
- centaur_mcr_type = 1;
-
- /*
- * Clear any unconfigured MCR's.
- */
-
- for (i = 0; i < 8; ++i) {
- if (centaur_mcr[i].high == 0 && centaur_mcr[i].low == 0) {
- if (!(lo & (1 << (9 + i))))
- wrmsr(MSR_IDT_MCR0 + i, 0, 0);
- else
- /*
- * If the BIOS set up an MCR we cannot see it
- * but we don't wish to obliterate it
- */
- centaur_mcr_reserved |= (1 << i);
- }
- }
- /*
- * Throw the main write-combining switch...
- * However if OOSTORE is enabled then people have already done far
- * cleverer things and we should behave.
- */
-
- lo |= 15; /* Write combine enables */
- wrmsr(MSR_IDT_MCR_CTRL, lo, hi);
-}
-
-/*
- * Initialise the original winchip with read only MCR registers
- * no used bitmask for the BIOS to pass on and write only control
- */
-
-static void __init
-centaur_mcr0_init(void)
-{
- unsigned i;
-
- /* Unfortunately, MCR's are read-only, so there is no way to
- * find out what the bios might have done.
- */
-
- /* Clear any unconfigured MCR's.
- * This way we are sure that the centaur_mcr array contains the actual
- * values. The disadvantage is that any BIOS tweaks are thus undone.
- *
- */
- for (i = 0; i < 8; ++i) {
- if (centaur_mcr[i].high == 0 && centaur_mcr[i].low == 0)
- wrmsr(MSR_IDT_MCR0 + i, 0, 0);
- }
-
- wrmsr(MSR_IDT_MCR_CTRL, 0x01F0001F, 0); /* Write only */
-}
-
-/*
- * Initialise Winchip series MCR registers
- */
-
-static void __init
-centaur_mcr_init(void)
-{
- struct set_mtrr_context ctxt;
-
- set_mtrr_prepare_save(&ctxt);
- set_mtrr_cache_disable(&ctxt);
-
- if (boot_cpu_data.x86_model == 4)
- centaur_mcr0_init();
- else if (boot_cpu_data.x86_model == 8 || boot_cpu_data.x86_model == 9)
- centaur_mcr1_init();
-
- set_mtrr_done(&ctxt);
-}
-#endif
-
-static int centaur_validate_add_page(unsigned long base,
- unsigned long size, unsigned int type)
+static int centaur_validate_add_page(unsigned long base, unsigned long size,
+ unsigned int type)
{
/*
* FIXME: Winchip2 supports uncached
*/
- if (type != MTRR_TYPE_WRCOMB &&
+ if (type != MTRR_TYPE_WRCOMB &&
(centaur_mcr_type == 0 || type != MTRR_TYPE_UNCACHABLE)) {
- printk(KERN_WARNING
- "mtrr: only write-combining%s supported\n",
- centaur_mcr_type ? " and uncacheable are"
- : " is");
+ pr_warning("mtrr: only write-combining%s supported\n",
+ centaur_mcr_type ? " and uncacheable are" : " is");
return -EINVAL;
}
return 0;
@@ -207,7 +107,6 @@ static int centaur_validate_add_page(unsigned long base,
static struct mtrr_ops centaur_mtrr_ops = {
.vendor = X86_VENDOR_CENTAUR,
-// .init = centaur_mcr_init,
.set = centaur_set_mcr,
.get = centaur_get_mcr,
.get_free_region = centaur_get_free_region,
@@ -220,5 +119,3 @@ int __init centaur_init_mtrr(void)
set_mtrr_ops(¢aur_mtrr_ops);
return 0;
}
-
-//arch_initcall(centaur_init_mtrr);
--
1.6.0.6
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH 3/9 -tip] x86: mtrr/cleanup.c fix trivial style problems
2009-07-04 2:20 ` [PATCH 2/9 -tip] x86: mtrr/centaur.c fix " Jaswinder Singh Rajput
@ 2009-07-04 2:21 ` Jaswinder Singh Rajput
2009-07-04 2:22 ` [PATCH 4/9 -tip] x86: mtrr/cyrix.c " Jaswinder Singh Rajput
0 siblings, 1 reply; 60+ messages in thread
From: Jaswinder Singh Rajput @ 2009-07-04 2:21 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Alan Cox, linux-kernel, Andrew Morton, Yinghai Lu
Fix trivial style problems:
WARNING: Use #include <linux/uaccess.h> instead of <asm/uaccess.h>
WARNING: Use #include <linux/kvm_para.h> instead of <asm/kvm_para.h>
WARNING: consider using strict_strtoul in preference to simple_strtoul
nr_mtrr_spare_reg should be unsigned long
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
---
arch/x86/kernel/cpu/mtrr/cleanup.c | 18 ++++++++----------
1 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c
index 1d584a1..9cbf207 100644
--- a/arch/x86/kernel/cpu/mtrr/cleanup.c
+++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
@@ -24,13 +24,13 @@
#include <linux/cpu.h>
#include <linux/mutex.h>
#include <linux/sort.h>
+#include <linux/uaccess.h>
+#include <linux/kvm_para.h>
#include <asm/e820.h>
#include <asm/mtrr.h>
-#include <asm/uaccess.h>
#include <asm/processor.h>
#include <asm/msr.h>
-#include <asm/kvm_para.h>
#include "mtrr.h"
/* should be related to MTRR_VAR_RANGES nums */
@@ -59,7 +59,7 @@ add_range(struct res_range *range, int nr_range, unsigned long start,
static int __init
add_range_with_merge(struct res_range *range, int nr_range, unsigned long start,
- unsigned long end)
+ unsigned long end)
{
int i;
@@ -577,13 +577,13 @@ static int __init parse_mtrr_gran_size_opt(char *p)
}
early_param("mtrr_gran_size", parse_mtrr_gran_size_opt);
-static int nr_mtrr_spare_reg __initdata =
+static unsigned long nr_mtrr_spare_reg __initdata =
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT;
static int __init parse_mtrr_spare_reg(char *arg)
{
if (arg)
- nr_mtrr_spare_reg = simple_strtoul(arg, NULL, 0);
+ return strict_strtoul(arg, 0, &nr_mtrr_spare_reg);
return 0;
}
@@ -661,7 +661,7 @@ static void __init print_out_mtrr_range_state(void)
start_base = to_size_factor(start_base, &start_factor),
type = range_state[i].type;
- printk(KERN_DEBUG "reg %d, base: %ld%cB, range: %ld%cB, type %s\n",
+ pr_debug("reg %d, base: %ld%cB, range: %ld%cB, type %s\n",
i, start_base, start_factor,
size_base, size_factor,
(type == MTRR_TYPE_UNCACHABLE) ? "UC" :
@@ -699,7 +699,7 @@ static int __init mtrr_need_cleanup(void)
/* check if we only had WB and UC */
if (num[MTRR_TYPE_WRBACK] + num[MTRR_TYPE_UNCACHABLE] !=
- num_var_ranges - num[MTRR_NUM_TYPES])
+ num_var_ranges - num[MTRR_NUM_TYPES])
return 0;
return 1;
@@ -708,8 +708,7 @@ static int __init mtrr_need_cleanup(void)
static unsigned long __initdata range_sums;
static void __init mtrr_calc_range_state(u64 chunk_size, u64 gran_size,
unsigned long extra_remove_base,
- unsigned long extra_remove_size,
- int i)
+ unsigned long extra_remove_size, int i)
{
int num_reg;
static struct res_range range_new[RANGE_NUM];
@@ -1098,4 +1097,3 @@ int __init mtrr_trim_uncached_memory(unsigned long end_pfn)
return 0;
}
-
--
1.6.0.6
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH 4/9 -tip] x86: mtrr/cyrix.c fix trivial style problems
2009-07-04 2:21 ` [PATCH 3/9 -tip] x86: mtrr/cleanup.c fix trivial " Jaswinder Singh Rajput
@ 2009-07-04 2:22 ` Jaswinder Singh Rajput
2009-07-04 2:23 ` [PATCH 5/9 -tip] x86: mtrr/generic.c fix " Jaswinder Singh Rajput
0 siblings, 1 reply; 60+ messages in thread
From: Jaswinder Singh Rajput @ 2009-07-04 2:22 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Alan Cox, linux-kernel, Andrew Morton, Yinghai Lu
Fix trivial style problems :
WARNING: Use #include <linux/io.h> instead of <asm/io.h>
WARNING: line over 80 characters
ERROR: do not initialise statics to 0 or NULL
ERROR: space prohibited after that open parenthesis '(' X 2
ERROR: space prohibited before that close parenthesis ')' X 2
ERROR: trailing whitespace X 2
ERROR: trailing statements should be on next line
ERROR: do not use C99 // comments X 2
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
---
arch/x86/kernel/cpu/mtrr/cyrix.c | 30 ++++++++++++++++--------------
1 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/cyrix.c b/arch/x86/kernel/cpu/mtrr/cyrix.c
index ff14c32..f01c723 100644
--- a/arch/x86/kernel/cpu/mtrr/cyrix.c
+++ b/arch/x86/kernel/cpu/mtrr/cyrix.c
@@ -1,8 +1,8 @@
#include <linux/init.h>
+#include <linux/io.h>
#include <linux/mm.h>
#include <asm/mtrr.h>
#include <asm/msr.h>
-#include <asm/io.h>
#include <asm/processor-cyrix.h>
#include <asm/processor-flags.h>
#include "mtrr.h"
@@ -114,7 +114,10 @@ cyrix_get_free_region(unsigned long base, unsigned long size, int replace_reg)
if (lsize == 0)
return i;
}
- /* ARR0-ARR6 isn't free, try ARR7 but its size must be at least 256K */
+ /*
+ * ARR0-ARR6 isn't free
+ * try ARR7 but its size must be at least 256K
+ */
cyrix_get_arr(i, &lbase, &lsize, <ype);
if ((lsize == 0) && (size >= 0x40))
return i;
@@ -122,21 +125,22 @@ cyrix_get_free_region(unsigned long base, unsigned long size, int replace_reg)
return -ENOSPC;
}
-static u32 cr4 = 0;
-static u32 ccr3;
+static u32 cr4, ccr3;
static void prepare_set(void)
{
u32 cr0;
/* Save value of CR4 and clear Page Global Enable (bit 7) */
- if ( cpu_has_pge ) {
+ if (cpu_has_pge) {
cr4 = read_cr4();
write_cr4(cr4 & ~X86_CR4_PGE);
}
- /* Disable and flush caches. Note that wbinvd flushes the TLBs as
- a side-effect */
+ /*
+ * Disable and flush caches.
+ * Note that wbinvd flushes the TLBs as a side-effect
+ */
cr0 = read_cr0() | X86_CR0_CD;
wbinvd();
write_cr0(cr0);
@@ -157,12 +161,12 @@ static void post_set(void)
/* Cyrix ARRs - everything else was excluded at the top */
setCx86(CX86_CCR3, ccr3);
-
+
/* Enable caches */
write_cr0(read_cr0() & 0xbfffffff);
/* Restore value of CR4 */
- if ( cpu_has_pge )
+ if (cpu_has_pge)
write_cr4(cr4);
}
@@ -178,7 +182,8 @@ static void cyrix_set_arr(unsigned int reg, unsigned long base,
size >>= 6;
size &= 0x7fff; /* make sure arr_size <= 14 */
- for (arr_size = 0; size; arr_size++, size >>= 1) ;
+ for (arr_size = 0; size; arr_size++, size >>= 1)
+ ;
if (reg < 7) {
switch (type) {
@@ -248,7 +253,7 @@ static void cyrix_set_all(void)
for (; i < 7; i++)
setCx86(CX86_CCR4 + i, ccr_state[i]);
for (i = 0; i < 8; i++)
- cyrix_set_arr(i, arr_state[i].base,
+ cyrix_set_arr(i, arr_state[i].base,
arr_state[i].size, arr_state[i].type);
post_set();
@@ -256,7 +261,6 @@ static void cyrix_set_all(void)
static struct mtrr_ops cyrix_mtrr_ops = {
.vendor = X86_VENDOR_CYRIX,
-// .init = cyrix_arr_init,
.set_all = cyrix_set_all,
.set = cyrix_set_arr,
.get = cyrix_get_arr,
@@ -270,5 +274,3 @@ int __init cyrix_init_mtrr(void)
set_mtrr_ops(&cyrix_mtrr_ops);
return 0;
}
-
-//arch_initcall(cyrix_init_mtrr);
--
1.6.0.6
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH 5/9 -tip] x86: mtrr/generic.c fix style problems
2009-07-04 2:22 ` [PATCH 4/9 -tip] x86: mtrr/cyrix.c " Jaswinder Singh Rajput
@ 2009-07-04 2:23 ` Jaswinder Singh Rajput
2009-07-04 2:23 ` [PATCH 6/9 -tip] x86: mtrr/if.c fix trivial " Jaswinder Singh Rajput
0 siblings, 1 reply; 60+ messages in thread
From: Jaswinder Singh Rajput @ 2009-07-04 2:23 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Alan Cox, linux-kernel, Andrew Morton, Yinghai Lu
Use pr_debug and pr_warning where possible.
Rename fixed_range_blocks to mtrrfix_blocks to avoid line breaks.
Fix following trivial style problems:
ERROR: trailing whitespace X 4
WARNING: Use #include <linux/io.h> instead of <asm/io.h>
WARNING: braces {} are not necessary for single statement blocks X 3
ERROR: "foo * bar" should be "foo *bar"
WARNING: line over 80 characters X 6
ERROR: "foo * bar" should be "foo *bar"
ERROR: spaces required around that '=' (ctx:VxO)
ERROR: space required before that '-' (ctx:OxV)
WARNING: suspect code indent for conditional statements (8, 12)
ERROR: spaces required around that '=' (ctx:VxV)
ERROR: do not initialise statics to 0 or NULL
ERROR: space prohibited after that open parenthesis '(' X 2
ERROR: space prohibited before that close parenthesis ')' X 2
ERROR: trailing statements should be on next line
ERROR: return is not a function, parentheses are not required
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
---
arch/x86/kernel/cpu/mtrr/generic.c | 147 +++++++++++++++++++-----------------
1 files changed, 78 insertions(+), 69 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/generic.c b/arch/x86/kernel/cpu/mtrr/generic.c
index 0543f69..1538197 100644
--- a/arch/x86/kernel/cpu/mtrr/generic.c
+++ b/arch/x86/kernel/cpu/mtrr/generic.c
@@ -1,10 +1,12 @@
-/* This only handles 32bit MTRR on 32bit hosts. This is strictly wrong
- because MTRRs can span upto 40 bits (36bits on most modern x86) */
+/*
+ * This only handles 32bit MTRR on 32bit hosts. This is strictly wrong
+ * because MTRRs can span upto 40 bits (36bits on most modern x86)
+ */
#include <linux/init.h>
#include <linux/slab.h>
#include <linux/mm.h>
#include <linux/module.h>
-#include <asm/io.h>
+#include <linux/io.h>
#include <asm/mtrr.h>
#include <asm/msr.h>
#include <asm/system.h>
@@ -15,11 +17,11 @@
#include "mtrr.h"
struct fixed_range_block {
- int base_msr; /* start address of an MTRR block */
- int ranges; /* number of MTRRs in this block */
+ int base_msr; /* start address of an MTRR block */
+ int ranges; /* number of MTRRs in this block */
};
-static struct fixed_range_block fixed_range_blocks[] = {
+static struct fixed_range_block mtrrfix_blocks[] = {
{ MSR_MTRRfix64K_00000, 1 }, /* one 64k MTRR */
{ MSR_MTRRfix16K_80000, 2 }, /* two 16k MTRRs */
{ MSR_MTRRfix4K_C0000, 8 }, /* eight 4k MTRRs */
@@ -104,9 +106,8 @@ u8 mtrr_type_lookup(u64 start, u64 end)
* Look of multiple ranges matching this address and pick type
* as per MTRR precedence
*/
- if (!(mtrr_state.enabled & 2)) {
+ if (!(mtrr_state.enabled & 2))
return mtrr_state.def_type;
- }
prev_match = 0xFF;
for (i = 0; i < num_var_ranges; ++i) {
@@ -125,9 +126,8 @@ u8 mtrr_type_lookup(u64 start, u64 end)
if (start_state != end_state)
return 0xFE;
- if ((start & mask) != (base & mask)) {
+ if ((start & mask) != (base & mask))
continue;
- }
curr_match = mtrr_state.var_ranges[i].base_lo & 0xff;
if (prev_match == 0xFF) {
@@ -148,9 +148,8 @@ u8 mtrr_type_lookup(u64 start, u64 end)
curr_match = MTRR_TYPE_WRTHROUGH;
}
- if (prev_match != curr_match) {
+ if (prev_match != curr_match)
return MTRR_TYPE_UNCACHABLE;
- }
}
if (mtrr_tom2) {
@@ -186,10 +185,9 @@ void fill_mtrr_var_range(unsigned int index,
vr[index].mask_hi = mask_hi;
}
-static void
-get_fixed_ranges(mtrr_type * frs)
+static void get_fixed_ranges(mtrr_type *frs)
{
- unsigned int *p = (unsigned int *) frs;
+ unsigned int *p = (unsigned int *)frs;
int i;
k8_check_syscfg_dram_mod_en();
@@ -217,14 +215,14 @@ static void __init print_fixed_last(void)
if (!last_fixed_end)
return;
- printk(KERN_DEBUG " %05X-%05X %s\n", last_fixed_start,
- last_fixed_end - 1, mtrr_attrib_to_str(last_fixed_type));
+ pr_debug(" %05X-%05X %s\n", last_fixed_start,
+ last_fixed_end - 1, mtrr_attrib_to_str(last_fixed_type));
last_fixed_end = 0;
}
static void __init update_fixed_last(unsigned base, unsigned end,
- mtrr_type type)
+ mtrr_type type)
{
last_fixed_start = base;
last_fixed_end = end;
@@ -259,45 +257,46 @@ static void __init print_mtrr_state(void)
unsigned int i;
int high_width;
- printk(KERN_DEBUG "MTRR default type: %s\n",
- mtrr_attrib_to_str(mtrr_state.def_type));
+ pr_debug("MTRR default type: %s\n",
+ mtrr_attrib_to_str(mtrr_state.def_type));
if (mtrr_state.have_fixed) {
- printk(KERN_DEBUG "MTRR fixed ranges %sabled:\n",
- mtrr_state.enabled & 1 ? "en" : "dis");
+ pr_debug("MTRR fixed ranges %sabled:\n",
+ mtrr_state.enabled & 1 ? "en" : "dis");
print_fixed(0x00000, 0x10000, mtrr_state.fixed_ranges + 0);
for (i = 0; i < 2; ++i)
- print_fixed(0x80000 + i * 0x20000, 0x04000, mtrr_state.fixed_ranges + (i + 1) * 8);
+ print_fixed(0x80000 + i * 0x20000, 0x04000,
+ mtrr_state.fixed_ranges + (i + 1) * 8);
for (i = 0; i < 8; ++i)
- print_fixed(0xC0000 + i * 0x08000, 0x01000, mtrr_state.fixed_ranges + (i + 3) * 8);
+ print_fixed(0xC0000 + i * 0x08000, 0x01000,
+ mtrr_state.fixed_ranges + (i + 3) * 8);
/* tail */
print_fixed_last();
}
- printk(KERN_DEBUG "MTRR variable ranges %sabled:\n",
- mtrr_state.enabled & 2 ? "en" : "dis");
+ pr_debug("MTRR variable ranges %sabled:\n",
+ mtrr_state.enabled & 2 ? "en" : "dis");
if (size_or_mask & 0xffffffffUL)
high_width = ffs(size_or_mask & 0xffffffffUL) - 1;
else
high_width = ffs(size_or_mask>>32) + 32 - 1;
high_width = (high_width - (32 - PAGE_SHIFT) + 3) / 4;
+
for (i = 0; i < num_var_ranges; ++i) {
if (mtrr_state.var_ranges[i].mask_lo & (1 << 11))
- printk(KERN_DEBUG " %u base %0*X%05X000 mask %0*X%05X000 %s\n",
- i,
- high_width,
- mtrr_state.var_ranges[i].base_hi,
- mtrr_state.var_ranges[i].base_lo >> 12,
- high_width,
- mtrr_state.var_ranges[i].mask_hi,
- mtrr_state.var_ranges[i].mask_lo >> 12,
- mtrr_attrib_to_str(mtrr_state.var_ranges[i].base_lo & 0xff));
+ pr_debug(" %u base %0*X%05X000 mask %0*X%05X000 %s\n",
+ i,
+ high_width,
+ mtrr_state.var_ranges[i].base_hi,
+ mtrr_state.var_ranges[i].base_lo >> 12,
+ high_width,
+ mtrr_state.var_ranges[i].mask_hi,
+ mtrr_state.var_ranges[i].mask_lo >> 12,
+ mtrr_attrib_to_str(mtrr_state.var_ranges[i].base_lo & 0xff));
else
- printk(KERN_DEBUG " %u disabled\n", i);
- }
- if (mtrr_tom2) {
- printk(KERN_DEBUG "TOM2: %016llx aka %lldM\n",
- mtrr_tom2, mtrr_tom2>>20);
+ pr_debug(" %u disabled\n", i);
}
+ if (mtrr_tom2)
+ pr_debug("TOM2: %016llx aka %lldM\n", mtrr_tom2, mtrr_tom2>>20);
}
/* Grab all of the MTRR state for this CPU into *state */
@@ -355,11 +354,11 @@ void __init mtrr_state_warn(void)
if (!mask)
return;
if (mask & MTRR_CHANGE_MASK_FIXED)
- printk(KERN_WARNING "mtrr: your CPUs had inconsistent fixed MTRR settings\n");
+ pr_warning("mtrr: your CPUs had inconsistent fixed MTRR settings\n");
if (mask & MTRR_CHANGE_MASK_VARIABLE)
- printk(KERN_WARNING "mtrr: your CPUs had inconsistent variable MTRR settings\n");
+ pr_warning("mtrr: your CPUs had inconsistent variable MTRR settings\n");
if (mask & MTRR_CHANGE_MASK_DEFTYPE)
- printk(KERN_WARNING "mtrr: your CPUs had inconsistent MTRRdefType settings\n");
+ pr_warning("mtrr: your CPUs had inconsistent MTRRdefType settings\n");
printk(KERN_INFO "mtrr: probably your BIOS does not setup all CPUs.\n");
printk(KERN_INFO "mtrr: corrected configuration.\n");
}
@@ -401,7 +400,8 @@ static void set_fixed_range(int msr, bool *changed, unsigned int *msrwords)
*
* Returns: The index of the region on success, else negative on error.
*/
-int generic_get_free_region(unsigned long base, unsigned long size, int replace_reg)
+int
+generic_get_free_region(unsigned long base, unsigned long size, int replace_reg)
{
int i, max;
mtrr_type ltype;
@@ -474,18 +474,18 @@ out_put_cpu:
* set_fixed_ranges - checks & updates the fixed-range MTRRs if they differ from the saved set
* @frs: pointer to fixed-range MTRR values, saved by get_fixed_ranges()
*/
-static int set_fixed_ranges(mtrr_type * frs)
+static int set_fixed_ranges(mtrr_type *frs)
{
- unsigned long long *saved = (unsigned long long *) frs;
+ unsigned long long *saved = (unsigned long long *)frs;
bool changed = false;
- int block=-1, range;
+ int block = -1, range;
k8_check_syscfg_dram_mod_en();
- while (fixed_range_blocks[++block].ranges)
- for (range=0; range < fixed_range_blocks[block].ranges; range++)
- set_fixed_range(fixed_range_blocks[block].base_msr + range,
- &changed, (unsigned int *) saved++);
+ while (mtrrfix_blocks[++block].ranges)
+ for (range = 0; range < mtrrfix_blocks[block].ranges; range++)
+ set_fixed_range(mtrrfix_blocks[block].base_msr + range,
+ &changed, (unsigned int *)saved++);
return changed;
}
@@ -540,7 +540,8 @@ static unsigned long set_mtrr_state(void)
so to set it we fiddle with the saved value */
if ((deftype_lo & 0xff) != mtrr_state.def_type
|| ((deftype_lo & 0xc00) >> 10) != mtrr_state.enabled) {
- deftype_lo = (deftype_lo & ~0xcff) | mtrr_state.def_type | (mtrr_state.enabled << 10);
+ deftype_lo = (deftype_lo & ~0xcff) | mtrr_state.def_type |
+ (mtrr_state.enabled << 10);
change_mask |= MTRR_CHANGE_MASK_DEFTYPE;
}
@@ -548,7 +549,7 @@ static unsigned long set_mtrr_state(void)
}
-static unsigned long cr4 = 0;
+static unsigned long cr4;
static DEFINE_SPINLOCK(set_atomicity_lock);
/*
@@ -562,9 +563,12 @@ static void prepare_set(void) __acquires(set_atomicity_lock)
{
unsigned long cr0;
- /* Note that this is not ideal, since the cache is only flushed/disabled
- for this CPU while the MTRRs are changed, but changing this requires
- more invasive changes to the way the kernel boots */
+ /*
+ * Note that this is not ideal
+ * since the cache is only flushed/disabled for this CPU while the
+ * MTRRs are changed, but changing this requires more invasive
+ * changes to the way the kernel boots
+ */
spin_lock(&set_atomicity_lock);
@@ -574,7 +578,7 @@ static void prepare_set(void) __acquires(set_atomicity_lock)
wbinvd();
/* Save value of CR4 and clear Page Global Enable (bit 7) */
- if ( cpu_has_pge ) {
+ if (cpu_has_pge) {
cr4 = read_cr4();
write_cr4(cr4 & ~X86_CR4_PGE);
}
@@ -596,12 +600,12 @@ static void post_set(void) __releases(set_atomicity_lock)
/* Intel (P6) standard MTRRs */
mtrr_wrmsr(MSR_MTRRdefType, deftype_lo, deftype_hi);
-
+
/* Enable caches */
write_cr0(read_cr0() & 0xbfffffff);
/* Restore value of CR4 */
- if ( cpu_has_pge )
+ if (cpu_has_pge)
write_cr4(cr4);
spin_unlock(&set_atomicity_lock);
}
@@ -629,7 +633,7 @@ static void generic_set_all(void)
set_bit(count, &smp_changes_mask);
mask >>= 1;
}
-
+
}
static void generic_set_mtrr(unsigned int reg, unsigned long base,
@@ -669,23 +673,26 @@ static void generic_set_mtrr(unsigned int reg, unsigned long base,
local_irq_restore(flags);
}
-int generic_validate_add_page(unsigned long base, unsigned long size, unsigned int type)
+int generic_validate_add_page(unsigned long base, unsigned long size,
+ unsigned int type)
{
unsigned long lbase, last;
- /* For Intel PPro stepping <= 7, must be 4 MiB aligned
- and not touch 0x70000000->0x7003FFFF */
+ /*
+ * For Intel PPro stepping <= 7
+ * must be 4 MiB aligned and not touch 0x70000000 -> 0x7003FFFF
+ */
if (is_cpu(INTEL) && boot_cpu_data.x86 == 6 &&
boot_cpu_data.x86_model == 1 &&
boot_cpu_data.x86_mask <= 7) {
if (base & ((1 << (22 - PAGE_SHIFT)) - 1)) {
- printk(KERN_WARNING "mtrr: base(0x%lx000) is not 4 MiB aligned\n", base);
+ pr_warning("mtrr: base(0x%lx000) is not 4 MiB aligned\n", base);
return -EINVAL;
}
if (!(base + size < 0x70000 || base > 0x7003F) &&
(type == MTRR_TYPE_WRCOMB
|| type == MTRR_TYPE_WRBACK)) {
- printk(KERN_WARNING "mtrr: writable mtrr between 0x70000000 and 0x7003FFFF may hang the CPU.\n");
+ pr_warning("mtrr: writable mtrr between 0x70000000 and 0x7003FFFF may hang the CPU.\n");
return -EINVAL;
}
}
@@ -694,9 +701,10 @@ int generic_validate_add_page(unsigned long base, unsigned long size, unsigned i
for base and 1 for last */
last = base + size - 1;
for (lbase = base; !(lbase & 1) && (last & 1);
- lbase = lbase >> 1, last = last >> 1) ;
+ lbase = lbase >> 1, last = last >> 1)
+ ;
if (lbase != last) {
- printk(KERN_WARNING "mtrr: base(0x%lx000) is not aligned on a size(0x%lx000) boundary\n",
+ pr_warning("mtrr: base(0x%lx000) is not aligned on a size(0x%lx000) boundary\n",
base, size);
return -EINVAL;
}
@@ -708,7 +716,7 @@ static int generic_have_wrcomb(void)
{
unsigned long config, dummy;
rdmsr(MSR_MTRRcap, config, dummy);
- return (config & (1 << 10));
+ return config & (1 << 10);
}
int positive_have_wrcomb(void)
@@ -716,7 +724,8 @@ int positive_have_wrcomb(void)
return 1;
}
-/* generic structure...
+/*
+ * generic structure...
*/
struct mtrr_ops generic_mtrr_ops = {
.use_intel_if = 1,
--
1.6.0.6
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH 6/9 -tip] x86: mtrr/if.c fix trivial style problems
2009-07-04 2:23 ` [PATCH 5/9 -tip] x86: mtrr/generic.c fix " Jaswinder Singh Rajput
@ 2009-07-04 2:23 ` Jaswinder Singh Rajput
2009-07-04 2:24 ` [PATCH 7/9 -tip] x86: mtrr/mtrr.h " Jaswinder Singh Rajput
0 siblings, 1 reply; 60+ messages in thread
From: Jaswinder Singh Rajput @ 2009-07-04 2:23 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Alan Cox, linux-kernel, Andrew Morton, Yinghai Lu
Fix :
WARNING: Use #include <linux/uaccess.h> instead of <asm/uaccess.h>
ERROR: trailing whitespace X 7
ERROR: trailing statements should be on next line X 3
WARNING: line over 80 characters X 5
ERROR: space required before the open parenthesis '('
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
---
arch/x86/kernel/cpu/mtrr/if.c | 51 ++++++++++++++++++++++++++--------------
1 files changed, 33 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/if.c b/arch/x86/kernel/cpu/mtrr/if.c
index fb73a52..74a7e54 100644
--- a/arch/x86/kernel/cpu/mtrr/if.c
+++ b/arch/x86/kernel/cpu/mtrr/if.c
@@ -4,7 +4,7 @@
#include <linux/ctype.h>
#include <linux/module.h>
#include <linux/seq_file.h>
-#include <asm/uaccess.h>
+#include <linux/uaccess.h>
#define LINE_SIZE 80
@@ -36,7 +36,7 @@ mtrr_file_add(unsigned long base, unsigned long size,
unsigned int type, bool increment, struct file *file, int page)
{
int reg, max;
- unsigned int *fcount = FILE_FCOUNT(file);
+ unsigned int *fcount = FILE_FCOUNT(file);
max = num_var_ranges;
if (fcount == NULL) {
@@ -109,6 +109,7 @@ mtrr_write(struct file *file, const char __user *buf, size_t len, loff_t * ppos)
ptr = line + linelen - 1;
if (linelen && *ptr == '\n')
*ptr = '\0';
+
if (!strncmp(line, "disable=", 8)) {
reg = simple_strtoul(line + 8, &ptr, 0);
err = mtrr_del_page(reg, 0, 0);
@@ -116,20 +117,27 @@ mtrr_write(struct file *file, const char __user *buf, size_t len, loff_t * ppos)
return err;
return len;
}
+
if (strncmp(line, "base=", 5))
return -EINVAL;
base = simple_strtoull(line + 5, &ptr, 0);
- for (; isspace(*ptr); ++ptr) ;
+ for (; isspace(*ptr); ++ptr)
+ ;
+
if (strncmp(ptr, "size=", 5))
return -EINVAL;
size = simple_strtoull(ptr + 5, &ptr, 0);
if ((base & 0xfff) || (size & 0xfff))
return -EINVAL;
- for (; isspace(*ptr); ++ptr) ;
+ for (; isspace(*ptr); ++ptr)
+ ;
+
if (strncmp(ptr, "type=", 5))
return -EINVAL;
ptr += 5;
- for (; isspace(*ptr); ++ptr) ;
+ for (; isspace(*ptr); ++ptr)
+ ;
+
for (i = 0; i < MTRR_NUM_TYPES; ++i) {
if (strcmp(ptr, mtrr_strings[i]))
continue;
@@ -181,7 +189,9 @@ mtrr_ioctl(struct file *file, unsigned int cmd, unsigned long __arg)
case MTRRIOC32_SET_PAGE_ENTRY:
case MTRRIOC32_DEL_PAGE_ENTRY:
case MTRRIOC32_KILL_PAGE_ENTRY: {
- struct mtrr_sentry32 __user *s32 = (struct mtrr_sentry32 __user *)__arg;
+ struct mtrr_sentry32 __user *s32;
+
+ s32 = (struct mtrr_sentry32 __user *)__arg;
err = get_user(sentry.base, &s32->base);
err |= get_user(sentry.size, &s32->size);
err |= get_user(sentry.type, &s32->type);
@@ -191,7 +201,9 @@ mtrr_ioctl(struct file *file, unsigned int cmd, unsigned long __arg)
}
case MTRRIOC32_GET_ENTRY:
case MTRRIOC32_GET_PAGE_ENTRY: {
- struct mtrr_gentry32 __user *g32 = (struct mtrr_gentry32 __user *)__arg;
+ struct mtrr_gentry32 __user *g32;
+
+ g32 = (struct mtrr_gentry32 __user *)__arg;
err = get_user(gentry.regnum, &g32->regnum);
err |= get_user(gentry.base, &g32->base);
err |= get_user(gentry.size, &g32->size);
@@ -314,7 +326,7 @@ mtrr_ioctl(struct file *file, unsigned int cmd, unsigned long __arg)
if (err)
return err;
- switch(cmd) {
+ switch (cmd) {
case MTRRIOC_GET_ENTRY:
case MTRRIOC_GET_PAGE_ENTRY:
if (copy_to_user(arg, &gentry, sizeof gentry))
@@ -323,7 +335,9 @@ mtrr_ioctl(struct file *file, unsigned int cmd, unsigned long __arg)
#ifdef CONFIG_COMPAT
case MTRRIOC32_GET_ENTRY:
case MTRRIOC32_GET_PAGE_ENTRY: {
- struct mtrr_gentry32 __user *g32 = (struct mtrr_gentry32 __user *)__arg;
+ struct mtrr_gentry32 __user *g32
+
+ g32 = (struct mtrr_gentry32 __user *)__arg;
err = put_user(gentry.base, &g32->base);
err |= put_user(gentry.size, &g32->size);
err |= put_user(gentry.regnum, &g32->regnum);
@@ -359,16 +373,16 @@ static int mtrr_seq_show(struct seq_file *seq, void *offset);
static int mtrr_open(struct inode *inode, struct file *file)
{
- if (!mtrr_if)
+ if (!mtrr_if)
return -EIO;
- if (!mtrr_if->get)
- return -ENXIO;
+ if (!mtrr_if->get)
+ return -ENXIO;
return single_open(file, mtrr_seq_show, NULL);
}
static const struct file_operations mtrr_fops = {
.owner = THIS_MODULE,
- .open = mtrr_open,
+ .open = mtrr_open,
.read = seq_read,
.llseek = seq_lseek,
.write = mtrr_write,
@@ -399,11 +413,12 @@ static int mtrr_seq_show(struct seq_file *seq, void *offset)
factor = 'M';
size >>= 20 - PAGE_SHIFT;
}
- /* RED-PEN: base can be > 32bit */
- len += seq_printf(seq,
- "reg%02i: base=0x%06lx000 (%5luMB), size=%5lu%cB, count=%d: %s\n",
- i, base, base >> (20 - PAGE_SHIFT), size, factor,
- mtrr_usage_table[i], mtrr_attrib_to_str(type));
+ /* RED-PEN: base can be > 32bit */
+ len += seq_printf(seq, "reg%02i: base=0x%06lx000 "
+ "(%5luMB), size=%5lu%cB, count=%d: %s\n",
+ i, base, base >> (20 - PAGE_SHIFT), size,
+ factor, mtrr_usage_table[i],
+ mtrr_attrib_to_str(type));
}
}
return 0;
--
1.6.0.6
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH 7/9 -tip] x86: mtrr/mtrr.h fix trivial style problems
2009-07-04 2:23 ` [PATCH 6/9 -tip] x86: mtrr/if.c fix trivial " Jaswinder Singh Rajput
@ 2009-07-04 2:24 ` Jaswinder Singh Rajput
2009-07-04 2:24 ` [PATCH 8/9 -tip] x86: mtrr/state.c " Jaswinder Singh Rajput
0 siblings, 1 reply; 60+ messages in thread
From: Jaswinder Singh Rajput @ 2009-07-04 2:24 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Alan Cox, linux-kernel, Andrew Morton, Yinghai Lu
Fix :
ERROR: do not use C99 // comments
ERROR: "foo * bar" should be "foo *bar" X 2
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
---
arch/x86/kernel/cpu/mtrr/mtrr.h | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/mtrr.h b/arch/x86/kernel/cpu/mtrr/mtrr.h
index 7538b76..4f334e0 100644
--- a/arch/x86/kernel/cpu/mtrr/mtrr.h
+++ b/arch/x86/kernel/cpu/mtrr/mtrr.h
@@ -14,13 +14,12 @@ extern unsigned int mtrr_usage_table[MTRR_MAX_VAR_RANGES];
struct mtrr_ops {
u32 vendor;
u32 use_intel_if;
-// void (*init)(void);
void (*set)(unsigned int reg, unsigned long base,
unsigned long size, mtrr_type type);
void (*set_all)(void);
void (*get)(unsigned int reg, unsigned long *base,
- unsigned long *size, mtrr_type * type);
+ unsigned long *size, mtrr_type *type);
int (*get_free_region)(unsigned long base, unsigned long size,
int replace_reg);
int (*validate_add_page)(unsigned long base, unsigned long size,
@@ -54,10 +53,10 @@ void fill_mtrr_var_range(unsigned int index,
u32 base_lo, u32 base_hi, u32 mask_lo, u32 mask_hi);
void get_mtrr_state(void);
-extern void set_mtrr_ops(struct mtrr_ops * ops);
+extern void set_mtrr_ops(struct mtrr_ops *ops);
extern u64 size_or_mask, size_and_mask;
-extern struct mtrr_ops * mtrr_if;
+extern struct mtrr_ops *mtrr_if;
#define is_cpu(vnd) (mtrr_if && mtrr_if->vendor == X86_VENDOR_##vnd)
#define use_intel() (mtrr_if && mtrr_if->use_intel_if == 1)
--
1.6.0.6
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH 8/9 -tip] x86: mtrr/state.c fix trivial style problems
2009-07-04 2:24 ` [PATCH 7/9 -tip] x86: mtrr/mtrr.h " Jaswinder Singh Rajput
@ 2009-07-04 2:24 ` Jaswinder Singh Rajput
2009-07-04 2:26 ` [PATCH 9/9 -tip] x86: mtrr/main.c fix " Jaswinder Singh Rajput
0 siblings, 1 reply; 60+ messages in thread
From: Jaswinder Singh Rajput @ 2009-07-04 2:24 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Alan Cox, linux-kernel, Andrew Morton, Yinghai Lu
Fix :
WARNING: Use #include <linux/io.h> instead of <asm/io.h>
WARNING: line over 80 characters X 4
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
---
arch/x86/kernel/cpu/mtrr/state.c | 20 +++++++++++++-------
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/state.c b/arch/x86/kernel/cpu/mtrr/state.c
index 1f5fb15..dcd00f5 100644
--- a/arch/x86/kernel/cpu/mtrr/state.c
+++ b/arch/x86/kernel/cpu/mtrr/state.c
@@ -1,13 +1,12 @@
#include <linux/mm.h>
#include <linux/init.h>
-#include <asm/io.h>
+#include <linux/io.h>
#include <asm/mtrr.h>
#include <asm/msr.h>
#include <asm/processor-cyrix.h>
#include <asm/processor-flags.h>
#include "mtrr.h"
-
/* Put the processor into a state where MTRRs can be safely set */
void set_mtrr_prepare_save(struct set_mtrr_context *ctxt)
{
@@ -35,9 +34,13 @@ void set_mtrr_prepare_save(struct set_mtrr_context *ctxt)
if (use_intel())
/* Save MTRR state */
- rdmsr(MSR_MTRRdefType, ctxt->deftype_lo, ctxt->deftype_hi);
+ rdmsr(MSR_MTRRdefType, ctxt->deftype_lo,
+ ctxt->deftype_hi);
else
- /* Cyrix ARRs - everything else were excluded at the top */
+ /*
+ * Cyrix ARRs -
+ * everything else were excluded at the top
+ */
ctxt->ccr3 = getCx86(CX86_CCR3);
}
}
@@ -64,9 +67,13 @@ void set_mtrr_done(struct set_mtrr_context *ctxt)
/* Restore MTRRdefType */
if (use_intel())
/* Intel (P6) standard MTRRs */
- mtrr_wrmsr(MSR_MTRRdefType, ctxt->deftype_lo, ctxt->deftype_hi);
+ mtrr_wrmsr(MSR_MTRRdefType, ctxt->deftype_lo,
+ ctxt->deftype_hi);
else
- /* Cyrix ARRs - everything else was excluded at the top */
+ /*
+ * Cyrix ARRs -
+ * everything else was excluded at the top
+ */
setCx86(CX86_CCR3, ctxt->ccr3);
/* Enable caches */
@@ -79,4 +86,3 @@ void set_mtrr_done(struct set_mtrr_context *ctxt)
/* Re-enable interrupts locally (if enabled previously) */
local_irq_restore(ctxt->flags);
}
-
--
1.6.0.6
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [PATCH 9/9 -tip] x86: mtrr/main.c fix style problems
2009-07-04 2:24 ` [PATCH 8/9 -tip] x86: mtrr/state.c " Jaswinder Singh Rajput
@ 2009-07-04 2:26 ` Jaswinder Singh Rajput
0 siblings, 0 replies; 60+ messages in thread
From: Jaswinder Singh Rajput @ 2009-07-04 2:26 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Alan Cox, linux-kernel, Andrew Morton, Yinghai Lu
Use pr_debug and pr_warning where possible.
Fix following trivial style problems:
ERROR: trailing whitespace X 25
WARNING: Use #include <linux/uaccess.h> instead of <asm/uaccess.h>
WARNING: Use #include <linux/kvm_para.h> instead of <asm/kvm_para.h>
ERROR: do not initialise externals to 0 or NULL X 2
ERROR: "foo * bar" should be "foo *bar" X 5
ERROR: do not use assignment in if condition X 2
WARNING: line over 80 characters X 8
ERROR: return is not a function, parentheses are not required
WARNING: braces {} are not necessary for any arm of this statement
ERROR: space required before the open parenthesis '(' X 2
ERROR: open brace '{' following function declarations go on the next line
ERROR: space required after that ',' (ctx:VxV) X 8
ERROR: space required before the open parenthesis '(' X 3
ERROR: else should follow close brace '}'
WARNING: space prohibited between function name and open parenthesis '('
WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable X 2
total: 50 errors, 14 warnings
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
---
arch/x86/kernel/cpu/mtrr/main.c | 185 ++++++++++++++++++++------------------
1 files changed, 97 insertions(+), 88 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index 8fc248b..5b22129 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -25,9 +25,9 @@
Operating System Writer's Guide" (Intel document number 242692),
section 11.11.7
- This was cleaned and made readable by Patrick Mochel <mochel@osdl.org>
- on 6-7 March 2002.
- Source: Intel Architecture Software Developers Manual, Volume 3:
+ This was cleaned and made readable by Patrick Mochel <mochel@osdl.org>
+ on 6-7 March 2002.
+ Source: Intel Architecture Software Developers Manual, Volume 3:
System Programming Guide; Section 9.11. (1997 edition - PPro).
*/
@@ -38,30 +38,30 @@
#include <linux/cpu.h>
#include <linux/mutex.h>
#include <linux/sort.h>
+#include <linux/uaccess.h>
+#include <linux/kvm_para.h>
#include <asm/e820.h>
#include <asm/mtrr.h>
-#include <asm/uaccess.h>
#include <asm/processor.h>
#include <asm/msr.h>
-#include <asm/kvm_para.h>
#include "mtrr.h"
-u32 num_var_ranges = 0;
+u32 num_var_ranges;
unsigned int mtrr_usage_table[MTRR_MAX_VAR_RANGES];
static DEFINE_MUTEX(mtrr_mutex);
u64 size_or_mask, size_and_mask;
-static struct mtrr_ops * mtrr_ops[X86_VENDOR_NUM] = {};
+static struct mtrr_ops *mtrr_ops[X86_VENDOR_NUM] = {};
-struct mtrr_ops * mtrr_if = NULL;
+struct mtrr_ops *mtrr_if;
static void set_mtrr(unsigned int reg, unsigned long base,
unsigned long size, mtrr_type type);
-void set_mtrr_ops(struct mtrr_ops * ops)
+void set_mtrr_ops(struct mtrr_ops *ops)
{
if (ops->vendor && ops->vendor < X86_VENDOR_NUM)
mtrr_ops[ops->vendor] = ops;
@@ -72,10 +72,14 @@ static int have_wrcomb(void)
{
struct pci_dev *dev;
u8 rev;
-
- if ((dev = pci_get_class(PCI_CLASS_BRIDGE_HOST << 8, NULL)) != NULL) {
- /* ServerWorks LE chipsets < rev 6 have problems with write-combining
- Don't allow it and leave room for other chipsets to be tagged */
+
+ dev = pci_get_class(PCI_CLASS_BRIDGE_HOST << 8, NULL);
+ if (dev != NULL) {
+ /*
+ * ServerWorks LE chipsets < rev 6 have problems with
+ * write-combining. Don't allow it and leave room for other
+ * chipsets to be tagged
+ */
if (dev->vendor == PCI_VENDOR_ID_SERVERWORKS &&
dev->device == PCI_DEVICE_ID_SERVERWORKS_LE) {
pci_read_config_byte(dev, PCI_CLASS_REVISION, &rev);
@@ -94,8 +98,8 @@ static int have_wrcomb(void)
return 0;
}
pci_dev_put(dev);
- }
- return (mtrr_if->have_wrcomb ? mtrr_if->have_wrcomb() : 0);
+ }
+ return mtrr_if->have_wrcomb ? mtrr_if->have_wrcomb() : 0;
}
/* This function returns the number of variable MTRRs */
@@ -103,9 +107,9 @@ static void __init set_num_var_ranges(void)
{
unsigned long config = 0, dummy;
- if (use_intel()) {
+ if (use_intel())
rdmsr(MSR_MTRRcap, config, dummy);
- } else if (is_cpu(AMD))
+ else if (is_cpu(AMD))
config = 2;
else if (is_cpu(CYRIX) || is_cpu(CENTAUR))
config = 8;
@@ -142,18 +146,18 @@ static void ipi_handler(void *info)
local_irq_save(flags);
atomic_dec(&data->count);
- while(!atomic_read(&data->gate))
+ while (!atomic_read(&data->gate))
cpu_relax();
/* The master has cleared me to execute */
- if (data->smp_reg != ~0U)
- mtrr_if->set(data->smp_reg, data->smp_base,
+ if (data->smp_reg != ~0U)
+ mtrr_if->set(data->smp_reg, data->smp_base,
data->smp_size, data->smp_type);
else
mtrr_if->set_all();
atomic_dec(&data->count);
- while(atomic_read(&data->gate))
+ while (atomic_read(&data->gate))
cpu_relax();
atomic_dec(&data->count);
@@ -161,7 +165,8 @@ static void ipi_handler(void *info)
#endif
}
-static inline int types_compatible(mtrr_type type1, mtrr_type type2) {
+static inline int types_compatible(mtrr_type type1, mtrr_type type2)
+{
return type1 == MTRR_TYPE_UNCACHABLE ||
type2 == MTRR_TYPE_UNCACHABLE ||
(type1 == MTRR_TYPE_WRTHROUGH && type2 == MTRR_TYPE_WRBACK) ||
@@ -176,10 +181,10 @@ static inline int types_compatible(mtrr_type type1, mtrr_type type2) {
* @type: mtrr type
*
* This is kinda tricky, but fortunately, Intel spelled it out for us cleanly:
- *
+ *
* 1. Send IPI to do the following:
* 2. Disable Interrupts
- * 3. Wait for all procs to do so
+ * 3. Wait for all procs to do so
* 4. Enter no-fill cache mode
* 5. Flush caches
* 6. Clear PGE bit
@@ -189,19 +194,20 @@ static inline int types_compatible(mtrr_type type1, mtrr_type type2) {
* 10. Enable all range registers
* 11. Flush all TLBs and caches again
* 12. Enter normal cache mode and reenable caching
- * 13. Set PGE
+ * 13. Set PGE
* 14. Wait for buddies to catch up
* 15. Enable interrupts.
- *
+ *
* What does that mean for us? Well, first we set data.count to the number
* of CPUs. As each CPU disables interrupts, it'll decrement it once. We wait
* until it hits 0 and proceed. We set the data.gate flag and reset data.count.
- * Meanwhile, they are waiting for that flag to be set. Once it's set, each
- * CPU goes through the transition of updating MTRRs. The CPU vendors may each do it
- * differently, so we call mtrr_if->set() callback and let them take care of it.
- * When they're done, they again decrement data->count and wait for data.gate to
- * be reset.
- * When we finish, we wait for data.count to hit 0 and toggle the data.gate flag.
+ * Meanwhile, they are waiting for that flag to be set. Once it's set, each
+ * CPU goes through the transition of updating MTRRs.
+ * The CPU vendors may each do it differently,
+ * so we call mtrr_if->set() callback and let them take care of it.
+ * When they're done, they again decrement data->count and wait for data.gate
+ * to be reset.
+ * When we finish, we wait for data.count to hit 0 and toggle the data.gate flag
* Everyone then enables interrupts and we all continue on.
*
* Note that the mechanism is the same for UP systems, too; all the SMP stuff
@@ -220,7 +226,7 @@ static void set_mtrr(unsigned int reg, unsigned long base,
atomic_set(&data.count, num_booting_cpus() - 1);
/* make sure data.count is visible before unleashing other CPUs */
smp_wmb();
- atomic_set(&data.gate,0);
+ atomic_set(&data.gate, 0);
/* Start the ball rolling on other CPUs */
if (smp_call_function(ipi_handler, &data, 0) != 0)
@@ -228,38 +234,39 @@ static void set_mtrr(unsigned int reg, unsigned long base,
local_irq_save(flags);
- while(atomic_read(&data.count))
+ while (atomic_read(&data.count))
cpu_relax();
/* ok, reset count and toggle gate */
atomic_set(&data.count, num_booting_cpus() - 1);
smp_wmb();
- atomic_set(&data.gate,1);
+ atomic_set(&data.gate, 1);
/* do our MTRR business */
- /* HACK!
+ /*
+ * HACK!
* We use this same function to initialize the mtrrs on boot.
* The state of the boot cpu's mtrrs has been saved, and we want
- * to replicate across all the APs.
+ * to replicate across all the APs.
* If we're doing that @reg is set to something special...
*/
- if (reg != ~0U)
- mtrr_if->set(reg,base,size,type);
+ if (reg != ~0U)
+ mtrr_if->set(reg, base, size, type);
/* wait for the others */
- while(atomic_read(&data.count))
+ while (atomic_read(&data.count))
cpu_relax();
atomic_set(&data.count, num_booting_cpus() - 1);
smp_wmb();
- atomic_set(&data.gate,0);
+ atomic_set(&data.gate, 0);
/*
* Wait here for everyone to have seen the gate change
* So we're the last ones to touch 'data'
*/
- while(atomic_read(&data.count))
+ while (atomic_read(&data.count))
cpu_relax();
local_irq_restore(flags);
@@ -275,7 +282,7 @@ static void set_mtrr(unsigned int reg, unsigned long base,
* Memory type region registers control the caching on newer Intel and
* non Intel processors. This function allows drivers to request an
* MTRR is added. The details and hardware specifics of each processor's
- * implementation are hidden from the caller, but nevertheless the
+ * implementation are hidden from the caller, but nevertheless the
* caller should expect to need to provide a power of two size on an
* equivalent power of two boundary.
*
@@ -301,7 +308,7 @@ static void set_mtrr(unsigned int reg, unsigned long base,
* failures and do not wish system log messages to be sent.
*/
-int mtrr_add_page(unsigned long base, unsigned long size,
+int mtrr_add_page(unsigned long base, unsigned long size,
unsigned int type, bool increment)
{
int i, replace, error;
@@ -310,29 +317,29 @@ int mtrr_add_page(unsigned long base, unsigned long size,
if (!mtrr_if)
return -ENXIO;
-
- if ((error = mtrr_if->validate_add_page(base,size,type)))
+
+ error = mtrr_if->validate_add_page(base, size, type);
+ if (error)
return error;
if (type >= MTRR_NUM_TYPES) {
- printk(KERN_WARNING "mtrr: type: %u invalid\n", type);
+ pr_warning("mtrr: type: %u invalid\n", type);
return -EINVAL;
}
/* If the type is WC, check that this processor supports it */
if ((type == MTRR_TYPE_WRCOMB) && !have_wrcomb()) {
- printk(KERN_WARNING
- "mtrr: your processor doesn't support write-combining\n");
+ pr_warning("mtrr: your processor doesn't support write-combining\n");
return -ENOSYS;
}
if (!size) {
- printk(KERN_WARNING "mtrr: zero sized request\n");
+ pr_warning("mtrr: zero sized request\n");
return -EINVAL;
}
if (base & size_or_mask || size & size_or_mask) {
- printk(KERN_WARNING "mtrr: base or size exceeds the MTRR width\n");
+ pr_warning("mtrr: base or size exceeds the MTRR width\n");
return -EINVAL;
}
@@ -345,32 +352,35 @@ int mtrr_add_page(unsigned long base, unsigned long size,
mutex_lock(&mtrr_mutex);
for (i = 0; i < num_var_ranges; ++i) {
mtrr_if->get(i, &lbase, &lsize, <ype);
- if (!lsize || base > lbase + lsize - 1 || base + size - 1 < lbase)
+ if (!lsize || base > lbase + lsize - 1 ||
+ base + size - 1 < lbase)
continue;
- /* At this point we know there is some kind of overlap/enclosure */
+ /*
+ * At this point we know there is some kind of
+ * overlap/enclosure
+ */
if (base < lbase || base + size - 1 > lbase + lsize - 1) {
- if (base <= lbase && base + size - 1 >= lbase + lsize - 1) {
+ if (base <= lbase &&
+ base + size - 1 >= lbase + lsize - 1) {
/* New region encloses an existing region */
if (type == ltype) {
replace = replace == -1 ? i : -2;
continue;
- }
- else if (types_compatible(type, ltype))
+ } else if (types_compatible(type, ltype))
continue;
}
- printk(KERN_WARNING
- "mtrr: 0x%lx000,0x%lx000 overlaps existing"
- " 0x%lx000,0x%lx000\n", base, size, lbase,
- lsize);
+ pr_warning("mtrr: 0x%lx000,0x%lx000 overlaps existing"
+ " 0x%lx000,0x%lx000\n", base, size, lbase,
+ lsize);
goto out;
}
/* New region is enclosed by an existing region */
if (ltype != type) {
if (types_compatible(type, ltype))
continue;
- printk (KERN_WARNING "mtrr: type mismatch for %lx000,%lx000 old: %s new: %s\n",
- base, size, mtrr_attrib_to_str(ltype),
- mtrr_attrib_to_str(type));
+ pr_warning("mtrr: type mismatch for %lx000,%lx000 old: %s new: %s\n",
+ base, size, mtrr_attrib_to_str(ltype),
+ mtrr_attrib_to_str(type));
goto out;
}
if (increment)
@@ -405,10 +415,8 @@ int mtrr_add_page(unsigned long base, unsigned long size,
static int mtrr_check(unsigned long base, unsigned long size)
{
if ((base & (PAGE_SIZE - 1)) || (size & (PAGE_SIZE - 1))) {
- printk(KERN_WARNING
- "mtrr: size and base must be multiples of 4 kiB\n");
- printk(KERN_DEBUG
- "mtrr: size: 0x%lx base: 0x%lx\n", size, base);
+ pr_warning("mtrr: size and base must be multiples of 4 kiB\n");
+ pr_debug("mtrr: size: 0x%lx base: 0x%lx\n", size, base);
dump_stack();
return -1;
}
@@ -425,7 +433,7 @@ static int mtrr_check(unsigned long base, unsigned long size)
* Memory type region registers control the caching on newer Intel and
* non Intel processors. This function allows drivers to request an
* MTRR is added. The details and hardware specifics of each processor's
- * implementation are hidden from the caller, but nevertheless the
+ * implementation are hidden from the caller, but nevertheless the
* caller should expect to need to provide a power of two size on an
* equivalent power of two boundary.
*
@@ -451,15 +459,15 @@ static int mtrr_check(unsigned long base, unsigned long size)
* failures and do not wish system log messages to be sent.
*/
-int
-mtrr_add(unsigned long base, unsigned long size, unsigned int type,
- bool increment)
+int mtrr_add(unsigned long base, unsigned long size, unsigned int type,
+ bool increment)
{
if (mtrr_check(base, size))
return -EINVAL;
return mtrr_add_page(base >> PAGE_SHIFT, size >> PAGE_SHIFT, type,
increment);
}
+EXPORT_SYMBOL(mtrr_add);
/**
* mtrr_del_page - delete a memory type region
@@ -470,7 +478,7 @@ mtrr_add(unsigned long base, unsigned long size, unsigned int type,
* If register is supplied then base and size are ignored. This is
* how drivers should call it.
*
- * Releases an MTRR region. If the usage count drops to zero the
+ * Releases an MTRR region. If the usage count drops to zero the
* register is freed and the region returns to default state.
* On success the register is returned, on failure a negative error
* code.
@@ -500,22 +508,22 @@ int mtrr_del_page(int reg, unsigned long base, unsigned long size)
}
}
if (reg < 0) {
- printk(KERN_DEBUG "mtrr: no MTRR for %lx000,%lx000 found\n", base,
- size);
+ pr_debug("mtrr: no MTRR for %lx000,%lx000 found\n",
+ base, size);
goto out;
}
}
if (reg >= max) {
- printk(KERN_WARNING "mtrr: register: %d too big\n", reg);
+ pr_warning("mtrr: register: %d too big\n", reg);
goto out;
}
mtrr_if->get(reg, &lbase, &lsize, <ype);
if (lsize < 1) {
- printk(KERN_WARNING "mtrr: MTRR %d not used\n", reg);
+ pr_warning("mtrr: MTRR %d not used\n", reg);
goto out;
}
if (mtrr_usage_table[reg] < 1) {
- printk(KERN_WARNING "mtrr: reg: %d has count=0\n", reg);
+ pr_warning("mtrr: reg: %d has count=0\n", reg);
goto out;
}
if (--mtrr_usage_table[reg] < 1)
@@ -526,6 +534,7 @@ int mtrr_del_page(int reg, unsigned long base, unsigned long size)
put_online_cpus();
return error;
}
+
/**
* mtrr_del - delete a memory type region
* @reg: Register returned by mtrr_add
@@ -535,7 +544,7 @@ int mtrr_del_page(int reg, unsigned long base, unsigned long size)
* If register is supplied then base and size are ignored. This is
* how drivers should call it.
*
- * Releases an MTRR region. If the usage count drops to zero the
+ * Releases an MTRR region. If the usage count drops to zero the
* register is freed and the region returns to default state.
* On success the register is returned, on failure a negative error
* code.
@@ -548,8 +557,6 @@ mtrr_del(int reg, unsigned long base, unsigned long size)
return -EINVAL;
return mtrr_del_page(reg, base >> PAGE_SHIFT, size >> PAGE_SHIFT);
}
-
-EXPORT_SYMBOL(mtrr_add);
EXPORT_SYMBOL(mtrr_del);
/* HACK ALERT!
@@ -576,7 +583,7 @@ struct mtrr_value {
static struct mtrr_value mtrr_value[MTRR_MAX_VAR_RANGES];
-static int mtrr_save(struct sys_device * sysdev, pm_message_t state)
+static int mtrr_save(struct sys_device *sysdev, pm_message_t state)
{
int i;
@@ -589,7 +596,7 @@ static int mtrr_save(struct sys_device * sysdev, pm_message_t state)
return 0;
}
-static int mtrr_restore(struct sys_device * sysdev)
+static int mtrr_restore(struct sys_device *sysdev)
{
int i;
@@ -615,9 +622,9 @@ int __initdata changed_by_mtrr_cleanup;
/**
* mtrr_bp_init - initialize mtrrs on the boot CPU
*
- * This needs to be called early; before any of the other CPUs are
+ * This needs to be called early; before any of the other CPUs are
* initialized (i.e. before smp_init()).
- *
+ *
*/
void __init mtrr_bp_init(void)
{
@@ -628,7 +635,7 @@ void __init mtrr_bp_init(void)
if (cpu_has_mtrr) {
mtrr_if = &generic_mtrr_ops;
- size_or_mask = 0xff000000; /* 36 bits */
+ size_or_mask = 0xff000000; /* 36 bits */
size_and_mask = 0x00f00000;
phys_addr = 36;
@@ -649,9 +656,11 @@ void __init mtrr_bp_init(void)
size_and_mask = ~size_or_mask & 0xfffff00000ULL;
} else if (boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR &&
boot_cpu_data.x86 == 6) {
- /* VIA C* family have Intel style MTRRs, but
- don't support PAE */
- size_or_mask = 0xfff00000; /* 32 bits */
+ /*
+ * VIA C* family have Intel style MTRRs,
+ * but don't support PAE
+ */
+ size_or_mask = 0xfff00000; /* 32 bits */
size_and_mask = 0;
phys_addr = 32;
}
--
1.6.0.6
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [tip:x86/cleanups] x86: Clean up mtrr/amd.c:
2009-07-03 16:42 ` Ingo Molnar
2009-07-03 22:17 ` Jaswinder Singh Rajput
2009-07-04 2:18 ` [GIT PULL -tip][PATCH 0/9] MTRR fix trivial style patches Jaswinder Singh Rajput
@ 2009-07-04 10:06 ` tip-bot for Jaswinder Singh Rajput
2009-07-04 10:06 ` [tip:x86/cleanups] x86: Clean up mtrr/centaur.c tip-bot for Jaswinder Singh Rajput
` (8 subsequent siblings)
11 siblings, 0 replies; 60+ messages in thread
From: tip-bot for Jaswinder Singh Rajput @ 2009-07-04 10:06 UTC (permalink / raw)
To: linux-tip-commits
Cc: linux-kernel, hpa, mingo, yinghai, jaswinder, alan,
jaswinderrajput, akpm, tglx, mingo
Commit-ID: 42204455f160dab0c47f19e1be23f5c927af2d17
Gitweb: http://git.kernel.org/tip/42204455f160dab0c47f19e1be23f5c927af2d17
Author: Jaswinder Singh Rajput <jaswinder@kernel.org>
AuthorDate: Sat, 4 Jul 2009 07:50:00 +0530
Committer: Ingo Molnar <mingo@elte.hu>
CommitDate: Sat, 4 Jul 2009 11:10:45 +0200
x86: Clean up mtrr/amd.c:
Fix trivial style problems :
ERROR: trailing whitespace
WARNING: line over 80 characters
ERROR: do not use C99 // comments
arch/x86/kernel/cpu/mtrr/amd.o:
text data bss dec hex filename
501 32 0 533 215 amd.o.before
501 32 0 533 215 amd.o.after
md5:
62f795eb840ee2d17b03df89e789e76c amd.o.before.asm
62f795eb840ee2d17b03df89e789e76c amd.o.after.asm
Suggested-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Yinghai Lu <yinghai@kernel.org>
LKML-Reference: <20090703164225.GA21447@elte.hu>
[ Also restructured comments to be standard, removed stray return,
converted function description to DocBook style, etc. ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/cpu/mtrr/amd.c | 97 +++++++++++++++++++++-------------------
1 files changed, 51 insertions(+), 46 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/amd.c b/arch/x86/kernel/cpu/mtrr/amd.c
index ee2331b..33af141 100644
--- a/arch/x86/kernel/cpu/mtrr/amd.c
+++ b/arch/x86/kernel/cpu/mtrr/amd.c
@@ -7,15 +7,15 @@
static void
amd_get_mtrr(unsigned int reg, unsigned long *base,
- unsigned long *size, mtrr_type * type)
+ unsigned long *size, mtrr_type *type)
{
unsigned long low, high;
rdmsr(MSR_K6_UWCCR, low, high);
- /* Upper dword is region 1, lower is region 0 */
+ /* Upper dword is region 1, lower is region 0 */
if (reg == 1)
low = high;
- /* The base masks off on the right alignment */
+ /* The base masks off on the right alignment */
*base = (low & 0xFFFE0000) >> PAGE_SHIFT;
*type = 0;
if (low & 1)
@@ -27,74 +27,81 @@ amd_get_mtrr(unsigned int reg, unsigned long *base,
return;
}
/*
- * This needs a little explaining. The size is stored as an
- * inverted mask of bits of 128K granularity 15 bits long offset
- * 2 bits
+ * This needs a little explaining. The size is stored as an
+ * inverted mask of bits of 128K granularity 15 bits long offset
+ * 2 bits.
*
- * So to get a size we do invert the mask and add 1 to the lowest
- * mask bit (4 as its 2 bits in). This gives us a size we then shift
- * to turn into 128K blocks
+ * So to get a size we do invert the mask and add 1 to the lowest
+ * mask bit (4 as its 2 bits in). This gives us a size we then shift
+ * to turn into 128K blocks.
*
- * eg 111 1111 1111 1100 is 512K
+ * eg 111 1111 1111 1100 is 512K
*
- * invert 000 0000 0000 0011
- * +1 000 0000 0000 0100
- * *128K ...
+ * invert 000 0000 0000 0011
+ * +1 000 0000 0000 0100
+ * *128K ...
*/
low = (~low) & 0x1FFFC;
*size = (low + 4) << (15 - PAGE_SHIFT);
- return;
}
-static void amd_set_mtrr(unsigned int reg, unsigned long base,
- unsigned long size, mtrr_type type)
-/* [SUMMARY] Set variable MTRR register on the local CPU.
- <reg> The register to set.
- <base> The base address of the region.
- <size> The size of the region. If this is 0 the region is disabled.
- <type> The type of the region.
- [RETURNS] Nothing.
-*/
+/**
+ * amd_set_mtrr - Set variable MTRR register on the local CPU.
+ *
+ * @reg The register to set.
+ * @base The base address of the region.
+ * @size The size of the region. If this is 0 the region is disabled.
+ * @type The type of the region.
+ *
+ * Returns nothing.
+ */
+static void
+amd_set_mtrr(unsigned int reg, unsigned long base, unsigned long size, mtrr_type type)
{
u32 regs[2];
/*
- * Low is MTRR0 , High MTRR 1
+ * Low is MTRR0, High MTRR 1
*/
rdmsr(MSR_K6_UWCCR, regs[0], regs[1]);
/*
- * Blank to disable
+ * Blank to disable
*/
- if (size == 0)
+ if (size == 0) {
regs[reg] = 0;
- else
- /* Set the register to the base, the type (off by one) and an
- inverted bitmask of the size The size is the only odd
- bit. We are fed say 512K We invert this and we get 111 1111
- 1111 1011 but if you subtract one and invert you get the
- desired 111 1111 1111 1100 mask
-
- But ~(x - 1) == ~x + 1 == -x. Two's complement rocks! */
+ } else {
+ /*
+ * Set the register to the base, the type (off by one) and an
+ * inverted bitmask of the size The size is the only odd
+ * bit. We are fed say 512K We invert this and we get 111 1111
+ * 1111 1011 but if you subtract one and invert you get the
+ * desired 111 1111 1111 1100 mask
+ *
+ * But ~(x - 1) == ~x + 1 == -x. Two's complement rocks!
+ */
regs[reg] = (-size >> (15 - PAGE_SHIFT) & 0x0001FFFC)
| (base << PAGE_SHIFT) | (type + 1);
+ }
/*
- * The writeback rule is quite specific. See the manual. Its
- * disable local interrupts, write back the cache, set the mtrr
+ * The writeback rule is quite specific. See the manual. Its
+ * disable local interrupts, write back the cache, set the mtrr
*/
wbinvd();
wrmsr(MSR_K6_UWCCR, regs[0], regs[1]);
}
-static int amd_validate_add_page(unsigned long base, unsigned long size, unsigned int type)
+static int
+amd_validate_add_page(unsigned long base, unsigned long size, unsigned int type)
{
- /* Apply the K6 block alignment and size rules
- In order
- o Uncached or gathering only
- o 128K or bigger block
- o Power of 2 block
- o base suitably aligned to the power
- */
+ /*
+ * Apply the K6 block alignment and size rules
+ * In order
+ * o Uncached or gathering only
+ * o 128K or bigger block
+ * o Power of 2 block
+ * o base suitably aligned to the power
+ */
if (type > MTRR_TYPE_WRCOMB || size < (1 << (17 - PAGE_SHIFT))
|| (size & ~(size - 1)) - size || (base & (size - 1)))
return -EINVAL;
@@ -115,5 +122,3 @@ int __init amd_init_mtrr(void)
set_mtrr_ops(&amd_mtrr_ops);
return 0;
}
-
-//arch_initcall(amd_mtrr_init);
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [tip:x86/cleanups] x86: Clean up mtrr/centaur.c
2009-07-03 16:42 ` Ingo Molnar
` (2 preceding siblings ...)
2009-07-04 10:06 ` [tip:x86/cleanups] x86: Clean up mtrr/amd.c: tip-bot for Jaswinder Singh Rajput
@ 2009-07-04 10:06 ` tip-bot for Jaswinder Singh Rajput
2009-07-04 10:07 ` [tip:x86/cleanups] x86: Clean up mtrr/cleanup.c tip-bot for Jaswinder Singh Rajput
` (7 subsequent siblings)
11 siblings, 0 replies; 60+ messages in thread
From: tip-bot for Jaswinder Singh Rajput @ 2009-07-04 10:06 UTC (permalink / raw)
To: linux-tip-commits
Cc: linux-kernel, hpa, mingo, yinghai, jaswinder, alan,
jaswinderrajput, akpm, tglx, mingo
Commit-ID: 6c4caa1ab737502190e416b76e6c10d2bf24276a
Gitweb: http://git.kernel.org/tip/6c4caa1ab737502190e416b76e6c10d2bf24276a
Author: Jaswinder Singh Rajput <jaswinder@kernel.org>
AuthorDate: Sat, 4 Jul 2009 07:50:44 +0530
Committer: Ingo Molnar <mingo@elte.hu>
CommitDate: Sat, 4 Jul 2009 11:10:45 +0200
x86: Clean up mtrr/centaur.c
Remove dead code and fix trivial style problems:
ERROR: trailing whitespace X 2
WARNING: line over 80 characters X 3
ROR: trailing whitespace
ERROR: do not use C99 // comments X 2
arch/x86/kernel/cpu/mtrr/centaur.o:
text data bss dec hex filename
605 32 68 705 2c1 centaur.o.before
605 32 68 705 2c1 centaur.o.after
md5:
a4865ea98ce3c163bb1d376a3949b3e3 centaur.o.before.asm
a4865ea98ce3c163bb1d376a3949b3e3 centaur.o.after.asm
Suggested-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Yinghai Lu <yinghai@kernel.org>
LKML-Reference: <20090703164225.GA21447@elte.hu>
[ Standardized comments, DocBook, curly braces, newlines. ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/cpu/mtrr/centaur.c | 168 ++++++++----------------------------
1 files changed, 35 insertions(+), 133 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/centaur.c b/arch/x86/kernel/cpu/mtrr/centaur.c
index cb9aa3a..de89f14 100644
--- a/arch/x86/kernel/cpu/mtrr/centaur.c
+++ b/arch/x86/kernel/cpu/mtrr/centaur.c
@@ -1,7 +1,9 @@
#include <linux/init.h>
#include <linux/mm.h>
+
#include <asm/mtrr.h>
#include <asm/msr.h>
+
#include "mtrr.h"
static struct {
@@ -12,25 +14,25 @@ static struct {
static u8 centaur_mcr_reserved;
static u8 centaur_mcr_type; /* 0 for winchip, 1 for winchip2 */
-/*
- * Report boot time MCR setups
+/**
+ * centaur_get_free_region - Get a free MTRR.
+ *
+ * @base: The starting (base) address of the region.
+ * @size: The size (in bytes) of the region.
+ *
+ * Returns: the index of the region on success, else -1 on error.
*/
-
static int
centaur_get_free_region(unsigned long base, unsigned long size, int replace_reg)
-/* [SUMMARY] Get a free MTRR.
- <base> The starting (base) address of the region.
- <size> The size (in bytes) of the region.
- [RETURNS] The index of the region on success, else -1 on error.
-*/
{
- int i, max;
- mtrr_type ltype;
unsigned long lbase, lsize;
+ mtrr_type ltype;
+ int i, max;
max = num_var_ranges;
if (replace_reg >= 0 && replace_reg < max)
return replace_reg;
+
for (i = 0; i < max; ++i) {
if (centaur_mcr_reserved & (1 << i))
continue;
@@ -38,11 +40,14 @@ centaur_get_free_region(unsigned long base, unsigned long size, int replace_reg)
if (lsize == 0)
return i;
}
+
return -ENOSPC;
}
-void
-mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi)
+/*
+ * Report boot time MCR setups
+ */
+void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi)
{
centaur_mcr[mcr].low = lo;
centaur_mcr[mcr].high = hi;
@@ -54,33 +59,35 @@ centaur_get_mcr(unsigned int reg, unsigned long *base,
{
*base = centaur_mcr[reg].high >> PAGE_SHIFT;
*size = -(centaur_mcr[reg].low & 0xfffff000) >> PAGE_SHIFT;
- *type = MTRR_TYPE_WRCOMB; /* If it is there, it is write-combining */
+ *type = MTRR_TYPE_WRCOMB; /* write-combining */
+
if (centaur_mcr_type == 1 && ((centaur_mcr[reg].low & 31) & 2))
*type = MTRR_TYPE_UNCACHABLE;
if (centaur_mcr_type == 1 && (centaur_mcr[reg].low & 31) == 25)
*type = MTRR_TYPE_WRBACK;
if (centaur_mcr_type == 0 && (centaur_mcr[reg].low & 31) == 31)
*type = MTRR_TYPE_WRBACK;
-
}
-static void centaur_set_mcr(unsigned int reg, unsigned long base,
- unsigned long size, mtrr_type type)
+static void
+centaur_set_mcr(unsigned int reg, unsigned long base,
+ unsigned long size, mtrr_type type)
{
unsigned long low, high;
if (size == 0) {
- /* Disable */
+ /* Disable */
high = low = 0;
} else {
high = base << PAGE_SHIFT;
- if (centaur_mcr_type == 0)
- low = -size << PAGE_SHIFT | 0x1f; /* only support write-combining... */
- else {
+ if (centaur_mcr_type == 0) {
+ /* Only support write-combining... */
+ low = -size << PAGE_SHIFT | 0x1f;
+ } else {
if (type == MTRR_TYPE_UNCACHABLE)
- low = -size << PAGE_SHIFT | 0x02; /* NC */
+ low = -size << PAGE_SHIFT | 0x02; /* NC */
else
- low = -size << PAGE_SHIFT | 0x09; /* WWO,WC */
+ low = -size << PAGE_SHIFT | 0x09; /* WWO, WC */
}
}
centaur_mcr[reg].high = high;
@@ -88,118 +95,16 @@ static void centaur_set_mcr(unsigned int reg, unsigned long base,
wrmsr(MSR_IDT_MCR0 + reg, low, high);
}
-#if 0
-/*
- * Initialise the later (saner) Winchip MCR variant. In this version
- * the BIOS can pass us the registers it has used (but not their values)
- * and the control register is read/write
- */
-
-static void __init
-centaur_mcr1_init(void)
-{
- unsigned i;
- u32 lo, hi;
-
- /* Unfortunately, MCR's are read-only, so there is no way to
- * find out what the bios might have done.
- */
-
- rdmsr(MSR_IDT_MCR_CTRL, lo, hi);
- if (((lo >> 17) & 7) == 1) { /* Type 1 Winchip2 MCR */
- lo &= ~0x1C0; /* clear key */
- lo |= 0x040; /* set key to 1 */
- wrmsr(MSR_IDT_MCR_CTRL, lo, hi); /* unlock MCR */
- }
-
- centaur_mcr_type = 1;
-
- /*
- * Clear any unconfigured MCR's.
- */
-
- for (i = 0; i < 8; ++i) {
- if (centaur_mcr[i].high == 0 && centaur_mcr[i].low == 0) {
- if (!(lo & (1 << (9 + i))))
- wrmsr(MSR_IDT_MCR0 + i, 0, 0);
- else
- /*
- * If the BIOS set up an MCR we cannot see it
- * but we don't wish to obliterate it
- */
- centaur_mcr_reserved |= (1 << i);
- }
- }
- /*
- * Throw the main write-combining switch...
- * However if OOSTORE is enabled then people have already done far
- * cleverer things and we should behave.
- */
-
- lo |= 15; /* Write combine enables */
- wrmsr(MSR_IDT_MCR_CTRL, lo, hi);
-}
-
-/*
- * Initialise the original winchip with read only MCR registers
- * no used bitmask for the BIOS to pass on and write only control
- */
-
-static void __init
-centaur_mcr0_init(void)
-{
- unsigned i;
-
- /* Unfortunately, MCR's are read-only, so there is no way to
- * find out what the bios might have done.
- */
-
- /* Clear any unconfigured MCR's.
- * This way we are sure that the centaur_mcr array contains the actual
- * values. The disadvantage is that any BIOS tweaks are thus undone.
- *
- */
- for (i = 0; i < 8; ++i) {
- if (centaur_mcr[i].high == 0 && centaur_mcr[i].low == 0)
- wrmsr(MSR_IDT_MCR0 + i, 0, 0);
- }
-
- wrmsr(MSR_IDT_MCR_CTRL, 0x01F0001F, 0); /* Write only */
-}
-
-/*
- * Initialise Winchip series MCR registers
- */
-
-static void __init
-centaur_mcr_init(void)
-{
- struct set_mtrr_context ctxt;
-
- set_mtrr_prepare_save(&ctxt);
- set_mtrr_cache_disable(&ctxt);
-
- if (boot_cpu_data.x86_model == 4)
- centaur_mcr0_init();
- else if (boot_cpu_data.x86_model == 8 || boot_cpu_data.x86_model == 9)
- centaur_mcr1_init();
-
- set_mtrr_done(&ctxt);
-}
-#endif
-
-static int centaur_validate_add_page(unsigned long base,
- unsigned long size, unsigned int type)
+static int
+centaur_validate_add_page(unsigned long base, unsigned long size, unsigned int type)
{
/*
- * FIXME: Winchip2 supports uncached
+ * FIXME: Winchip2 supports uncached
*/
- if (type != MTRR_TYPE_WRCOMB &&
+ if (type != MTRR_TYPE_WRCOMB &&
(centaur_mcr_type == 0 || type != MTRR_TYPE_UNCACHABLE)) {
- printk(KERN_WARNING
- "mtrr: only write-combining%s supported\n",
- centaur_mcr_type ? " and uncacheable are"
- : " is");
+ pr_warning("mtrr: only write-combining%s supported\n",
+ centaur_mcr_type ? " and uncacheable are" : " is");
return -EINVAL;
}
return 0;
@@ -207,7 +112,6 @@ static int centaur_validate_add_page(unsigned long base,
static struct mtrr_ops centaur_mtrr_ops = {
.vendor = X86_VENDOR_CENTAUR,
-// .init = centaur_mcr_init,
.set = centaur_set_mcr,
.get = centaur_get_mcr,
.get_free_region = centaur_get_free_region,
@@ -220,5 +124,3 @@ int __init centaur_init_mtrr(void)
set_mtrr_ops(¢aur_mtrr_ops);
return 0;
}
-
-//arch_initcall(centaur_init_mtrr);
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [tip:x86/cleanups] x86: Clean up mtrr/cleanup.c
2009-07-03 16:42 ` Ingo Molnar
` (3 preceding siblings ...)
2009-07-04 10:06 ` [tip:x86/cleanups] x86: Clean up mtrr/centaur.c tip-bot for Jaswinder Singh Rajput
@ 2009-07-04 10:07 ` tip-bot for Jaswinder Singh Rajput
2009-07-04 21:12 ` Yinghai Lu
2009-07-04 10:07 ` [tip:x86/cleanups] x86: Clean up mtrr/cyrix.c tip-bot for Jaswinder Singh Rajput
` (6 subsequent siblings)
11 siblings, 1 reply; 60+ messages in thread
From: tip-bot for Jaswinder Singh Rajput @ 2009-07-04 10:07 UTC (permalink / raw)
To: linux-tip-commits
Cc: linux-kernel, hpa, mingo, yinghai, jaswinder, alan,
jaswinderrajput, akpm, tglx, mingo
Commit-ID: 63f9600fadb10ea739108ae93e3e842d9843c58b
Gitweb: http://git.kernel.org/tip/63f9600fadb10ea739108ae93e3e842d9843c58b
Author: Jaswinder Singh Rajput <jaswinder@kernel.org>
AuthorDate: Sat, 4 Jul 2009 07:51:32 +0530
Committer: Ingo Molnar <mingo@elte.hu>
CommitDate: Sat, 4 Jul 2009 11:10:46 +0200
x86: Clean up mtrr/cleanup.c
Fix trivial style problems:
WARNING: Use #include <linux/uaccess.h> instead of <asm/uaccess.h>
WARNING: Use #include <linux/kvm_para.h> instead of <asm/kvm_para.h>
Also, nr_mtrr_spare_reg should be unsigned long.
arch/x86/kernel/cpu/mtrr/cleanup.o:
text data bss dec hex filename
6241 8992 2056 17289 4389 cleanup.o.before
6241 8992 2056 17289 4389 cleanup.o.after
The md5 has changed:
1a7a27513aef1825236daf29110fe657 cleanup.o.before.asm
bcea358efa2532b6020e338e158447af cleanup.o.after.asm
Because a WARN_ON()'s __LINE__ value changed by 3 lines.
Suggested-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Yinghai Lu <yinghai@kernel.org>
LKML-Reference: <20090703164225.GA21447@elte.hu>
[ Did lots of other cleanups to make the code look more consistent. ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/cpu/mtrr/cleanup.c | 350 ++++++++++++++++++------------------
1 files changed, 176 insertions(+), 174 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c
index 1d584a1..b8aba81 100644
--- a/arch/x86/kernel/cpu/mtrr/cleanup.c
+++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
@@ -1,51 +1,52 @@
-/* MTRR (Memory Type Range Register) cleanup
-
- Copyright (C) 2009 Yinghai Lu
-
- This library is free software; you can redistribute it and/or
- modify it under the terms of the GNU Library General Public
- License as published by the Free Software Foundation; either
- version 2 of the License, or (at your option) any later version.
-
- This library is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- Library General Public License for more details.
-
- You should have received a copy of the GNU Library General Public
- License along with this library; if not, write to the Free
- Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
-*/
-
+/*
+ * MTRR (Memory Type Range Register) cleanup
+ *
+ * Copyright (C) 2009 Yinghai Lu
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Library General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Library General Public License for more details.
+ *
+ * You should have received a copy of the GNU Library General Public
+ * License along with this library; if not, write to the Free
+ * Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
#include <linux/module.h>
#include <linux/init.h>
#include <linux/pci.h>
#include <linux/smp.h>
#include <linux/cpu.h>
-#include <linux/mutex.h>
#include <linux/sort.h>
+#include <linux/mutex.h>
+#include <linux/uaccess.h>
+#include <linux/kvm_para.h>
+#include <asm/processor.h>
#include <asm/e820.h>
#include <asm/mtrr.h>
-#include <asm/uaccess.h>
-#include <asm/processor.h>
#include <asm/msr.h>
-#include <asm/kvm_para.h>
+
#include "mtrr.h"
-/* should be related to MTRR_VAR_RANGES nums */
+/* Should be related to MTRR_VAR_RANGES nums */
#define RANGE_NUM 256
struct res_range {
- unsigned long start;
- unsigned long end;
+ unsigned long start;
+ unsigned long end;
};
static int __init
-add_range(struct res_range *range, int nr_range, unsigned long start,
- unsigned long end)
+add_range(struct res_range *range, int nr_range,
+ unsigned long start, unsigned long end)
{
- /* out of slots */
+ /* Out of slots: */
if (nr_range >= RANGE_NUM)
return nr_range;
@@ -58,12 +59,12 @@ add_range(struct res_range *range, int nr_range, unsigned long start,
}
static int __init
-add_range_with_merge(struct res_range *range, int nr_range, unsigned long start,
- unsigned long end)
+add_range_with_merge(struct res_range *range, int nr_range,
+ unsigned long start, unsigned long end)
{
int i;
- /* try to merge it with old one */
+ /* Try to merge it with old one: */
for (i = 0; i < nr_range; i++) {
unsigned long final_start, final_end;
unsigned long common_start, common_end;
@@ -84,7 +85,7 @@ add_range_with_merge(struct res_range *range, int nr_range, unsigned long start,
return nr_range;
}
- /* need to add that */
+ /* Need to add it: */
return add_range(range, nr_range, start, end);
}
@@ -117,7 +118,7 @@ subtract_range(struct res_range *range, unsigned long start, unsigned long end)
}
if (start > range[j].start && end < range[j].end) {
- /* find the new spare */
+ /* Find the new spare: */
for (i = 0; i < RANGE_NUM; i++) {
if (range[i].end == 0)
break;
@@ -147,13 +148,19 @@ static int __init cmp_range(const void *x1, const void *x2)
}
struct var_mtrr_range_state {
- unsigned long base_pfn;
- unsigned long size_pfn;
- mtrr_type type;
+ unsigned long base_pfn;
+ unsigned long size_pfn;
+ mtrr_type type;
};
static struct var_mtrr_range_state __initdata range_state[RANGE_NUM];
+
static int __initdata debug_print;
+#define Dprintk(x...) do { if (debug_print) printk(KERN_DEBUG x); } while (0)
+
+
+#define BIOS_BUG_MSG KERN_WARNING \
+ "WARNING: BIOS bug: VAR MTRR %d contains strange UC entry under 1M, check with your system vendor!\n"
static int __init
x86_get_mtrr_mem_range(struct res_range *range, int nr_range,
@@ -180,7 +187,7 @@ x86_get_mtrr_mem_range(struct res_range *range, int nr_range,
range[i].start, range[i].end + 1);
}
- /* take out UC ranges */
+ /* Take out UC ranges: */
for (i = 0; i < num_var_ranges; i++) {
type = range_state[i].type;
if (type != MTRR_TYPE_UNCACHABLE &&
@@ -244,10 +251,9 @@ static int __initdata nr_range;
static unsigned long __init sum_ranges(struct res_range *range, int nr_range)
{
- unsigned long sum;
+ unsigned long sum = 0;
int i;
- sum = 0;
for (i = 0; i < nr_range; i++)
sum += range[i].end + 1 - range[i].start;
@@ -288,7 +294,7 @@ struct var_mtrr_state {
static void __init
set_var_mtrr(unsigned int reg, unsigned long basek, unsigned long sizek,
- unsigned char type, unsigned int address_bits)
+ unsigned char type, unsigned int address_bits)
{
u32 base_lo, base_hi, mask_lo, mask_hi;
u64 base, mask;
@@ -301,7 +307,7 @@ set_var_mtrr(unsigned int reg, unsigned long basek, unsigned long sizek,
mask = (1ULL << address_bits) - 1;
mask &= ~((((u64)sizek) << 10) - 1);
- base = ((u64)basek) << 10;
+ base = ((u64)basek) << 10;
base |= type;
mask |= 0x800;
@@ -317,15 +323,14 @@ set_var_mtrr(unsigned int reg, unsigned long basek, unsigned long sizek,
static void __init
save_var_mtrr(unsigned int reg, unsigned long basek, unsigned long sizek,
- unsigned char type)
+ unsigned char type)
{
range_state[reg].base_pfn = basek >> (PAGE_SHIFT - 10);
range_state[reg].size_pfn = sizek >> (PAGE_SHIFT - 10);
range_state[reg].type = type;
}
-static void __init
-set_var_mtrr_all(unsigned int address_bits)
+static void __init set_var_mtrr_all(unsigned int address_bits)
{
unsigned long basek, sizek;
unsigned char type;
@@ -342,11 +347,11 @@ set_var_mtrr_all(unsigned int address_bits)
static unsigned long to_size_factor(unsigned long sizek, char *factorp)
{
- char factor;
unsigned long base = sizek;
+ char factor;
if (base & ((1<<10) - 1)) {
- /* not MB alignment */
+ /* Not MB-aligned: */
factor = 'K';
} else if (base & ((1<<20) - 1)) {
factor = 'M';
@@ -372,11 +377,12 @@ range_to_mtrr(unsigned int reg, unsigned long range_startk,
unsigned long max_align, align;
unsigned long sizek;
- /* Compute the maximum size I can make a range */
+ /* Compute the maximum size with which we can make a range: */
if (range_startk)
max_align = ffs(range_startk) - 1;
else
max_align = 32;
+
align = fls(range_sizek) - 1;
if (align > max_align)
align = max_align;
@@ -386,11 +392,10 @@ range_to_mtrr(unsigned int reg, unsigned long range_startk,
char start_factor = 'K', size_factor = 'K';
unsigned long start_base, size_base;
- start_base = to_size_factor(range_startk,
- &start_factor),
- size_base = to_size_factor(sizek, &size_factor),
+ start_base = to_size_factor(range_startk, &start_factor);
+ size_base = to_size_factor(sizek, &size_factor);
- printk(KERN_DEBUG "Setting variable MTRR %d, "
+ Dprintk("Setting variable MTRR %d, "
"base: %ld%cB, range: %ld%cB, type %s\n",
reg, start_base, start_factor,
size_base, size_factor,
@@ -425,10 +430,11 @@ range_to_mtrr_with_hole(struct var_mtrr_state *state, unsigned long basek,
chunk_sizek = state->chunk_sizek;
gran_sizek = state->gran_sizek;
- /* align with gran size, prevent small block used up MTRRs */
+ /* Align with gran size, prevent small block used up MTRRs: */
range_basek = ALIGN(state->range_startk, gran_sizek);
if ((range_basek > basek) && basek)
return second_sizek;
+
state->range_sizek -= (range_basek - state->range_startk);
range_sizek = ALIGN(state->range_sizek, gran_sizek);
@@ -439,22 +445,21 @@ range_to_mtrr_with_hole(struct var_mtrr_state *state, unsigned long basek,
}
state->range_sizek = range_sizek;
- /* try to append some small hole */
+ /* Try to append some small hole: */
range0_basek = state->range_startk;
range0_sizek = ALIGN(state->range_sizek, chunk_sizek);
- /* no increase */
+ /* No increase: */
if (range0_sizek == state->range_sizek) {
- if (debug_print)
- printk(KERN_DEBUG "rangeX: %016lx - %016lx\n",
- range0_basek<<10,
- (range0_basek + state->range_sizek)<<10);
+ Dprintk("rangeX: %016lx - %016lx\n",
+ range0_basek<<10,
+ (range0_basek + state->range_sizek)<<10);
state->reg = range_to_mtrr(state->reg, range0_basek,
state->range_sizek, MTRR_TYPE_WRBACK);
return 0;
}
- /* only cut back, when it is not the last */
+ /* Only cut back when it is not the last: */
if (sizek) {
while (range0_basek + range0_sizek > (basek + sizek)) {
if (range0_sizek >= chunk_sizek)
@@ -470,16 +475,16 @@ range_to_mtrr_with_hole(struct var_mtrr_state *state, unsigned long basek,
second_try:
range_basek = range0_basek + range0_sizek;
- /* one hole in the middle */
+ /* One hole in the middle: */
if (range_basek > basek && range_basek <= (basek + sizek))
second_sizek = range_basek - basek;
if (range0_sizek > state->range_sizek) {
- /* one hole in middle or at end */
+ /* One hole in middle or at the end: */
hole_sizek = range0_sizek - state->range_sizek - second_sizek;
- /* hole size should be less than half of range0 size */
+ /* Hole size should be less than half of range0 size: */
if (hole_sizek >= (range0_sizek >> 1) &&
range0_sizek >= chunk_sizek) {
range0_sizek -= chunk_sizek;
@@ -491,32 +496,30 @@ second_try:
}
if (range0_sizek) {
- if (debug_print)
- printk(KERN_DEBUG "range0: %016lx - %016lx\n",
- range0_basek<<10,
- (range0_basek + range0_sizek)<<10);
+ Dprintk("range0: %016lx - %016lx\n",
+ range0_basek<<10,
+ (range0_basek + range0_sizek)<<10);
state->reg = range_to_mtrr(state->reg, range0_basek,
range0_sizek, MTRR_TYPE_WRBACK);
}
if (range0_sizek < state->range_sizek) {
- /* need to handle left over */
+ /* Need to handle left over range: */
range_sizek = state->range_sizek - range0_sizek;
- if (debug_print)
- printk(KERN_DEBUG "range: %016lx - %016lx\n",
- range_basek<<10,
- (range_basek + range_sizek)<<10);
+ Dprintk("range: %016lx - %016lx\n",
+ range_basek<<10,
+ (range_basek + range_sizek)<<10);
+
state->reg = range_to_mtrr(state->reg, range_basek,
range_sizek, MTRR_TYPE_WRBACK);
}
if (hole_sizek) {
hole_basek = range_basek - hole_sizek - second_sizek;
- if (debug_print)
- printk(KERN_DEBUG "hole: %016lx - %016lx\n",
- hole_basek<<10,
- (hole_basek + hole_sizek)<<10);
+ Dprintk("hole: %016lx - %016lx\n",
+ hole_basek<<10,
+ (hole_basek + hole_sizek)<<10);
state->reg = range_to_mtrr(state->reg, hole_basek,
hole_sizek, MTRR_TYPE_UNCACHABLE);
}
@@ -537,23 +540,23 @@ set_var_mtrr_range(struct var_mtrr_state *state, unsigned long base_pfn,
basek = base_pfn << (PAGE_SHIFT - 10);
sizek = size_pfn << (PAGE_SHIFT - 10);
- /* See if I can merge with the last range */
+ /* See if I can merge with the last range: */
if ((basek <= 1024) ||
(state->range_startk + state->range_sizek == basek)) {
unsigned long endk = basek + sizek;
state->range_sizek = endk - state->range_startk;
return;
}
- /* Write the range mtrrs */
+ /* Write the range mtrrs: */
if (state->range_sizek != 0)
second_sizek = range_to_mtrr_with_hole(state, basek, sizek);
- /* Allocate an msr */
+ /* Allocate an msr: */
state->range_startk = basek + second_sizek;
state->range_sizek = sizek - second_sizek;
}
-/* mininum size of mtrr block that can take hole */
+/* Mininum size of mtrr block that can take hole: */
static u64 mtrr_chunk_size __initdata = (256ULL<<20);
static int __init parse_mtrr_chunk_size_opt(char *p)
@@ -565,7 +568,7 @@ static int __init parse_mtrr_chunk_size_opt(char *p)
}
early_param("mtrr_chunk_size", parse_mtrr_chunk_size_opt);
-/* granity of mtrr of block */
+/* Granularity of mtrr of block: */
static u64 mtrr_gran_size __initdata;
static int __init parse_mtrr_gran_size_opt(char *p)
@@ -577,7 +580,7 @@ static int __init parse_mtrr_gran_size_opt(char *p)
}
early_param("mtrr_gran_size", parse_mtrr_gran_size_opt);
-static int nr_mtrr_spare_reg __initdata =
+static unsigned long nr_mtrr_spare_reg __initdata =
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT;
static int __init parse_mtrr_spare_reg(char *arg)
@@ -586,7 +589,6 @@ static int __init parse_mtrr_spare_reg(char *arg)
nr_mtrr_spare_reg = simple_strtoul(arg, NULL, 0);
return 0;
}
-
early_param("mtrr_spare_reg_nr", parse_mtrr_spare_reg);
static int __init
@@ -594,8 +596,8 @@ x86_setup_var_mtrrs(struct res_range *range, int nr_range,
u64 chunk_size, u64 gran_size)
{
struct var_mtrr_state var_state;
- int i;
int num_reg;
+ int i;
var_state.range_startk = 0;
var_state.range_sizek = 0;
@@ -605,17 +607,18 @@ x86_setup_var_mtrrs(struct res_range *range, int nr_range,
memset(range_state, 0, sizeof(range_state));
- /* Write the range etc */
- for (i = 0; i < nr_range; i++)
+ /* Write the range: */
+ for (i = 0; i < nr_range; i++) {
set_var_mtrr_range(&var_state, range[i].start,
range[i].end - range[i].start + 1);
+ }
- /* Write the last range */
+ /* Write the last range: */
if (var_state.range_sizek != 0)
range_to_mtrr_with_hole(&var_state, 0, 0);
num_reg = var_state.reg;
- /* Clear out the extra MTRR's */
+ /* Clear out the extra MTRR's: */
while (var_state.reg < num_var_ranges) {
save_var_mtrr(var_state.reg, 0, 0, 0);
var_state.reg++;
@@ -625,11 +628,11 @@ x86_setup_var_mtrrs(struct res_range *range, int nr_range,
}
struct mtrr_cleanup_result {
- unsigned long gran_sizek;
- unsigned long chunk_sizek;
- unsigned long lose_cover_sizek;
- unsigned int num_reg;
- int bad;
+ unsigned long gran_sizek;
+ unsigned long chunk_sizek;
+ unsigned long lose_cover_sizek;
+ unsigned int num_reg;
+ int bad;
};
/*
@@ -645,10 +648,10 @@ static unsigned long __initdata min_loss_pfn[RANGE_NUM];
static void __init print_out_mtrr_range_state(void)
{
- int i;
char start_factor = 'K', size_factor = 'K';
unsigned long start_base, size_base;
mtrr_type type;
+ int i;
for (i = 0; i < num_var_ranges; i++) {
@@ -676,10 +679,10 @@ static int __init mtrr_need_cleanup(void)
int i;
mtrr_type type;
unsigned long size;
- /* extra one for all 0 */
+ /* Extra one for all 0: */
int num[MTRR_NUM_TYPES + 1];
- /* check entries number */
+ /* Check entries number: */
memset(num, 0, sizeof(num));
for (i = 0; i < num_var_ranges; i++) {
type = range_state[i].type;
@@ -693,88 +696,86 @@ static int __init mtrr_need_cleanup(void)
num[type]++;
}
- /* check if we got UC entries */
+ /* Check if we got UC entries: */
if (!num[MTRR_TYPE_UNCACHABLE])
return 0;
- /* check if we only had WB and UC */
+ /* Check if we only had WB and UC */
if (num[MTRR_TYPE_WRBACK] + num[MTRR_TYPE_UNCACHABLE] !=
- num_var_ranges - num[MTRR_NUM_TYPES])
+ num_var_ranges - num[MTRR_NUM_TYPES])
return 0;
return 1;
}
static unsigned long __initdata range_sums;
-static void __init mtrr_calc_range_state(u64 chunk_size, u64 gran_size,
- unsigned long extra_remove_base,
- unsigned long extra_remove_size,
- int i)
+
+static void __init
+mtrr_calc_range_state(u64 chunk_size, u64 gran_size,
+ unsigned long x_remove_base,
+ unsigned long x_remove_size, int i)
{
- int num_reg;
static struct res_range range_new[RANGE_NUM];
- static int nr_range_new;
unsigned long range_sums_new;
+ static int nr_range_new;
+ int num_reg;
- /* convert ranges to var ranges state */
- num_reg = x86_setup_var_mtrrs(range, nr_range,
- chunk_size, gran_size);
+ /* Convert ranges to var ranges state: */
+ num_reg = x86_setup_var_mtrrs(range, nr_range, chunk_size, gran_size);
- /* we got new setting in range_state, check it */
+ /* We got new setting in range_state, check it: */
memset(range_new, 0, sizeof(range_new));
nr_range_new = x86_get_mtrr_mem_range(range_new, 0,
- extra_remove_base, extra_remove_size);
+ x_remove_base, x_remove_size);
range_sums_new = sum_ranges(range_new, nr_range_new);
result[i].chunk_sizek = chunk_size >> 10;
result[i].gran_sizek = gran_size >> 10;
result[i].num_reg = num_reg;
+
if (range_sums < range_sums_new) {
- result[i].lose_cover_sizek =
- (range_sums_new - range_sums) << PSHIFT;
+ result[i].lose_cover_sizek = (range_sums_new - range_sums) << PSHIFT;
result[i].bad = 1;
- } else
- result[i].lose_cover_sizek =
- (range_sums - range_sums_new) << PSHIFT;
+ } else {
+ result[i].lose_cover_sizek = (range_sums - range_sums_new) << PSHIFT;
+ }
- /* double check it */
+ /* Double check it: */
if (!result[i].bad && !result[i].lose_cover_sizek) {
- if (nr_range_new != nr_range ||
- memcmp(range, range_new, sizeof(range)))
- result[i].bad = 1;
+ if (nr_range_new != nr_range || memcmp(range, range_new, sizeof(range)))
+ result[i].bad = 1;
}
- if (!result[i].bad && (range_sums - range_sums_new <
- min_loss_pfn[num_reg])) {
- min_loss_pfn[num_reg] =
- range_sums - range_sums_new;
- }
+ if (!result[i].bad && (range_sums - range_sums_new < min_loss_pfn[num_reg]))
+ min_loss_pfn[num_reg] = range_sums - range_sums_new;
}
static void __init mtrr_print_out_one_result(int i)
{
- char gran_factor, chunk_factor, lose_factor;
unsigned long gran_base, chunk_base, lose_base;
+ char gran_factor, chunk_factor, lose_factor;
gran_base = to_size_factor(result[i].gran_sizek, &gran_factor),
chunk_base = to_size_factor(result[i].chunk_sizek, &chunk_factor),
lose_base = to_size_factor(result[i].lose_cover_sizek, &lose_factor),
- printk(KERN_INFO "%sgran_size: %ld%c \tchunk_size: %ld%c \t",
- result[i].bad ? "*BAD*" : " ",
- gran_base, gran_factor, chunk_base, chunk_factor);
- printk(KERN_CONT "num_reg: %d \tlose cover RAM: %s%ld%c\n",
- result[i].num_reg, result[i].bad ? "-" : "",
- lose_base, lose_factor);
+
+ pr_info("%sgran_size: %ld%c \tchunk_size: %ld%c \t",
+ result[i].bad ? "*BAD*" : " ",
+ gran_base, gran_factor, chunk_base, chunk_factor);
+ pr_cont("num_reg: %d \tlose cover RAM: %s%ld%c\n",
+ result[i].num_reg, result[i].bad ? "-" : "",
+ lose_base, lose_factor);
}
static int __init mtrr_search_optimal_index(void)
{
- int i;
int num_reg_good;
int index_good;
+ int i;
if (nr_mtrr_spare_reg >= num_var_ranges)
nr_mtrr_spare_reg = num_var_ranges - 1;
+
num_reg_good = -1;
for (i = num_var_ranges - nr_mtrr_spare_reg; i > 0; i--) {
if (!min_loss_pfn[i])
@@ -796,24 +797,24 @@ static int __init mtrr_search_optimal_index(void)
return index_good;
}
-
int __init mtrr_cleanup(unsigned address_bits)
{
- unsigned long extra_remove_base, extra_remove_size;
+ unsigned long x_remove_base, x_remove_size;
unsigned long base, size, def, dummy;
- mtrr_type type;
u64 chunk_size, gran_size;
+ mtrr_type type;
int index_good;
int i;
if (!is_cpu(INTEL) || enable_mtrr_cleanup < 1)
return 0;
+
rdmsr(MSR_MTRRdefType, def, dummy);
def &= 0xff;
if (def != MTRR_TYPE_UNCACHABLE)
return 0;
- /* get it and store it aside */
+ /* Get it and store it aside: */
memset(range_state, 0, sizeof(range_state));
for (i = 0; i < num_var_ranges; i++) {
mtrr_if->get(i, &base, &size, &type);
@@ -822,29 +823,28 @@ int __init mtrr_cleanup(unsigned address_bits)
range_state[i].type = type;
}
- /* check if we need handle it and can handle it */
+ /* Check if we need handle it and can handle it: */
if (!mtrr_need_cleanup())
return 0;
- /* print original var MTRRs at first, for debugging: */
+ /* Print original var MTRRs at first, for debugging: */
printk(KERN_DEBUG "original variable MTRRs\n");
print_out_mtrr_range_state();
memset(range, 0, sizeof(range));
- extra_remove_size = 0;
- extra_remove_base = 1 << (32 - PAGE_SHIFT);
+ x_remove_size = 0;
+ x_remove_base = 1 << (32 - PAGE_SHIFT);
if (mtrr_tom2)
- extra_remove_size =
- (mtrr_tom2 >> PAGE_SHIFT) - extra_remove_base;
- nr_range = x86_get_mtrr_mem_range(range, 0, extra_remove_base,
- extra_remove_size);
+ x_remove_size = (mtrr_tom2 >> PAGE_SHIFT) - x_remove_base;
+
+ nr_range = x86_get_mtrr_mem_range(range, 0, x_remove_base, x_remove_size);
/*
- * [0, 1M) should always be coverred by var mtrr with WB
- * and fixed mtrrs should take effective before var mtrr for it
+ * [0, 1M) should always be covered by var mtrr with WB
+ * and fixed mtrrs should take effect before var mtrr for it:
*/
nr_range = add_range_with_merge(range, nr_range, 0,
(1ULL<<(20 - PAGE_SHIFT)) - 1);
- /* sort the ranges */
+ /* Sort the ranges: */
sort(range, nr_range, sizeof(struct res_range), cmp_range, NULL);
range_sums = sum_ranges(range, nr_range);
@@ -854,7 +854,7 @@ int __init mtrr_cleanup(unsigned address_bits)
if (mtrr_chunk_size && mtrr_gran_size) {
i = 0;
mtrr_calc_range_state(mtrr_chunk_size, mtrr_gran_size,
- extra_remove_base, extra_remove_size, i);
+ x_remove_base, x_remove_size, i);
mtrr_print_out_one_result(i);
@@ -880,7 +880,7 @@ int __init mtrr_cleanup(unsigned address_bits)
continue;
mtrr_calc_range_state(chunk_size, gran_size,
- extra_remove_base, extra_remove_size, i);
+ x_remove_base, x_remove_size, i);
if (debug_print) {
mtrr_print_out_one_result(i);
printk(KERN_INFO "\n");
@@ -890,7 +890,7 @@ int __init mtrr_cleanup(unsigned address_bits)
}
}
- /* try to find the optimal index */
+ /* Try to find the optimal index: */
index_good = mtrr_search_optimal_index();
if (index_good != -1) {
@@ -898,7 +898,7 @@ int __init mtrr_cleanup(unsigned address_bits)
i = index_good;
mtrr_print_out_one_result(i);
- /* convert ranges to var ranges state */
+ /* Convert ranges to var ranges state: */
chunk_size = result[i].chunk_sizek;
chunk_size <<= 10;
gran_size = result[i].gran_sizek;
@@ -941,8 +941,8 @@ early_param("disable_mtrr_trim", disable_mtrr_trim_setup);
* Note this won't check if the MTRRs < 4GB where the magic bit doesn't
* apply to are wrong, but so far we don't know of any such case in the wild.
*/
-#define Tom2Enabled (1U << 21)
-#define Tom2ForceMemTypeWB (1U << 22)
+#define Tom2Enabled (1U << 21)
+#define Tom2ForceMemTypeWB (1U << 22)
int __init amd_special_default_mtrr(void)
{
@@ -952,7 +952,7 @@ int __init amd_special_default_mtrr(void)
return 0;
if (boot_cpu_data.x86 < 0xf || boot_cpu_data.x86 > 0x11)
return 0;
- /* In case some hypervisor doesn't pass SYSCFG through */
+ /* In case some hypervisor doesn't pass SYSCFG through: */
if (rdmsr_safe(MSR_K8_SYSCFG, &l, &h) < 0)
return 0;
/*
@@ -965,19 +965,21 @@ int __init amd_special_default_mtrr(void)
return 0;
}
-static u64 __init real_trim_memory(unsigned long start_pfn,
- unsigned long limit_pfn)
+static u64 __init
+real_trim_memory(unsigned long start_pfn, unsigned long limit_pfn)
{
u64 trim_start, trim_size;
+
trim_start = start_pfn;
trim_start <<= PAGE_SHIFT;
+
trim_size = limit_pfn;
trim_size <<= PAGE_SHIFT;
trim_size -= trim_start;
- return e820_update_range(trim_start, trim_size, E820_RAM,
- E820_RESERVED);
+ return e820_update_range(trim_start, trim_size, E820_RAM, E820_RESERVED);
}
+
/**
* mtrr_trim_uncached_memory - trim RAM not covered by MTRRs
* @end_pfn: ending page frame number
@@ -985,7 +987,7 @@ static u64 __init real_trim_memory(unsigned long start_pfn,
* Some buggy BIOSes don't setup the MTRRs properly for systems with certain
* memory configurations. This routine checks that the highest MTRR matches
* the end of memory, to make sure the MTRRs having a write back type cover
- * all of the memory the kernel is intending to use. If not, it'll trim any
+ * all of the memory the kernel is intending to use. If not, it'll trim any
* memory off the end by adjusting end_pfn, removing it from the kernel's
* allocation pools, warning the user with an obnoxious message.
*/
@@ -994,21 +996,22 @@ int __init mtrr_trim_uncached_memory(unsigned long end_pfn)
unsigned long i, base, size, highest_pfn = 0, def, dummy;
mtrr_type type;
u64 total_trim_size;
-
/* extra one for all 0 */
int num[MTRR_NUM_TYPES + 1];
+
/*
* Make sure we only trim uncachable memory on machines that
* support the Intel MTRR architecture:
*/
if (!is_cpu(INTEL) || disable_mtrr_trim)
return 0;
+
rdmsr(MSR_MTRRdefType, def, dummy);
def &= 0xff;
if (def != MTRR_TYPE_UNCACHABLE)
return 0;
- /* get it and store it aside */
+ /* Get it and store it aside: */
memset(range_state, 0, sizeof(range_state));
for (i = 0; i < num_var_ranges; i++) {
mtrr_if->get(i, &base, &size, &type);
@@ -1017,7 +1020,7 @@ int __init mtrr_trim_uncached_memory(unsigned long end_pfn)
range_state[i].type = type;
}
- /* Find highest cached pfn */
+ /* Find highest cached pfn: */
for (i = 0; i < num_var_ranges; i++) {
type = range_state[i].type;
if (type != MTRR_TYPE_WRBACK)
@@ -1028,13 +1031,13 @@ int __init mtrr_trim_uncached_memory(unsigned long end_pfn)
highest_pfn = base + size;
}
- /* kvm/qemu doesn't have mtrr set right, don't trim them all */
+ /* kvm/qemu doesn't have mtrr set right, don't trim them all: */
if (!highest_pfn) {
printk(KERN_INFO "CPU MTRRs all blank - virtualized system.\n");
return 0;
}
- /* check entries number */
+ /* Check entries number: */
memset(num, 0, sizeof(num));
for (i = 0; i < num_var_ranges; i++) {
type = range_state[i].type;
@@ -1046,11 +1049,11 @@ int __init mtrr_trim_uncached_memory(unsigned long end_pfn)
num[type]++;
}
- /* no entry for WB? */
+ /* No entry for WB? */
if (!num[MTRR_TYPE_WRBACK])
return 0;
- /* check if we only had WB and UC */
+ /* Check if we only had WB and UC: */
if (num[MTRR_TYPE_WRBACK] + num[MTRR_TYPE_UNCACHABLE] !=
num_var_ranges - num[MTRR_NUM_TYPES])
return 0;
@@ -1066,31 +1069,31 @@ int __init mtrr_trim_uncached_memory(unsigned long end_pfn)
}
nr_range = x86_get_mtrr_mem_range(range, nr_range, 0, 0);
+ /* Check the head: */
total_trim_size = 0;
- /* check the head */
if (range[0].start)
total_trim_size += real_trim_memory(0, range[0].start);
- /* check the holes */
+
+ /* Check the holes: */
for (i = 0; i < nr_range - 1; i++) {
if (range[i].end + 1 < range[i+1].start)
total_trim_size += real_trim_memory(range[i].end + 1,
range[i+1].start);
}
- /* check the top */
+
+ /* Check the top: */
i = nr_range - 1;
if (range[i].end + 1 < end_pfn)
total_trim_size += real_trim_memory(range[i].end + 1,
end_pfn);
if (total_trim_size) {
- printk(KERN_WARNING "WARNING: BIOS bug: CPU MTRRs don't cover"
- " all of memory, losing %lluMB of RAM.\n",
- total_trim_size >> 20);
+ pr_warning("WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing %lluMB of RAM.\n", total_trim_size >> 20);
if (!changed_by_mtrr_cleanup)
WARN_ON(1);
- printk(KERN_INFO "update e820 for mtrr\n");
+ pr_info("update e820 for mtrr\n");
update_e820();
return 1;
@@ -1098,4 +1101,3 @@ int __init mtrr_trim_uncached_memory(unsigned long end_pfn)
return 0;
}
-
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [tip:x86/cleanups] x86: Clean up mtrr/cyrix.c
2009-07-03 16:42 ` Ingo Molnar
` (4 preceding siblings ...)
2009-07-04 10:07 ` [tip:x86/cleanups] x86: Clean up mtrr/cleanup.c tip-bot for Jaswinder Singh Rajput
@ 2009-07-04 10:07 ` tip-bot for Jaswinder Singh Rajput
2009-07-04 10:07 ` [tip:x86/cleanups] x86: Clean up mtrr/generic.c tip-bot for Jaswinder Singh Rajput
` (5 subsequent siblings)
11 siblings, 0 replies; 60+ messages in thread
From: tip-bot for Jaswinder Singh Rajput @ 2009-07-04 10:07 UTC (permalink / raw)
To: linux-tip-commits
Cc: linux-kernel, hpa, mingo, yinghai, jaswinder, alan,
jaswinderrajput, akpm, tglx, mingo
Commit-ID: 2311037708c170977506fbcbe0a2ba0c6d221940
Gitweb: http://git.kernel.org/tip/2311037708c170977506fbcbe0a2ba0c6d221940
Author: Jaswinder Singh Rajput <jaswinder@kernel.org>
AuthorDate: Sat, 4 Jul 2009 07:52:08 +0530
Committer: Ingo Molnar <mingo@elte.hu>
CommitDate: Sat, 4 Jul 2009 11:10:47 +0200
x86: Clean up mtrr/cyrix.c
Fix trivial style problems:
WARNING: Use #include <linux/io.h> instead of <asm/io.h>
WARNING: line over 80 characters
ERROR: do not initialise statics to 0 or NULL
ERROR: space prohibited after that open parenthesis '(' X 2
ERROR: space prohibited before that close parenthesis ')' X 2
ERROR: trailing whitespace X 2
ERROR: trailing statements should be on next line
ERROR: do not use C99 // comments X 2
arch/x86/kernel/cpu/mtrr/cyrix.o:
text data bss dec hex filename
1637 32 8 1677 68d cyrix.o.before
1637 32 8 1677 68d cyrix.o.after
md5:
6f52abd06905be3f4cabb5239f9b0ff0 cyrix.o.before.asm
6f52abd06905be3f4cabb5239f9b0ff0 cyrix.o.after.asm
Suggested-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Yinghai Lu <yinghai@kernel.org>
LKML-Reference: <20090703164225.GA21447@elte.hu>
[ Made the code more consistent ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/cpu/mtrr/cyrix.c | 94 ++++++++++++++++++++-----------------
1 files changed, 51 insertions(+), 43 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/cyrix.c b/arch/x86/kernel/cpu/mtrr/cyrix.c
index ff14c32..228d982 100644
--- a/arch/x86/kernel/cpu/mtrr/cyrix.c
+++ b/arch/x86/kernel/cpu/mtrr/cyrix.c
@@ -1,38 +1,40 @@
#include <linux/init.h>
+#include <linux/io.h>
#include <linux/mm.h>
-#include <asm/mtrr.h>
-#include <asm/msr.h>
-#include <asm/io.h>
+
#include <asm/processor-cyrix.h>
#include <asm/processor-flags.h>
+#include <asm/mtrr.h>
+#include <asm/msr.h>
+
#include "mtrr.h"
static void
cyrix_get_arr(unsigned int reg, unsigned long *base,
unsigned long *size, mtrr_type * type)
{
- unsigned long flags;
unsigned char arr, ccr3, rcr, shift;
+ unsigned long flags;
arr = CX86_ARR_BASE + (reg << 1) + reg; /* avoid multiplication by 3 */
- /* Save flags and disable interrupts */
local_irq_save(flags);
ccr3 = getCx86(CX86_CCR3);
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10); /* enable MAPEN */
- ((unsigned char *) base)[3] = getCx86(arr);
- ((unsigned char *) base)[2] = getCx86(arr + 1);
- ((unsigned char *) base)[1] = getCx86(arr + 2);
+ ((unsigned char *)base)[3] = getCx86(arr);
+ ((unsigned char *)base)[2] = getCx86(arr + 1);
+ ((unsigned char *)base)[1] = getCx86(arr + 2);
rcr = getCx86(CX86_RCR_BASE + reg);
- setCx86(CX86_CCR3, ccr3); /* disable MAPEN */
+ setCx86(CX86_CCR3, ccr3); /* disable MAPEN */
- /* Enable interrupts if it was enabled previously */
local_irq_restore(flags);
+
shift = ((unsigned char *) base)[1] & 0x0f;
*base >>= PAGE_SHIFT;
- /* Power of two, at least 4K on ARR0-ARR6, 256K on ARR7
+ /*
+ * Power of two, at least 4K on ARR0-ARR6, 256K on ARR7
* Note: shift==0xf means 4G, this is unsupported.
*/
if (shift)
@@ -76,17 +78,20 @@ cyrix_get_arr(unsigned int reg, unsigned long *base,
}
}
+/*
+ * cyrix_get_free_region - get a free ARR.
+ *
+ * @base: the starting (base) address of the region.
+ * @size: the size (in bytes) of the region.
+ *
+ * Returns: the index of the region on success, else -1 on error.
+*/
static int
cyrix_get_free_region(unsigned long base, unsigned long size, int replace_reg)
-/* [SUMMARY] Get a free ARR.
- <base> The starting (base) address of the region.
- <size> The size (in bytes) of the region.
- [RETURNS] The index of the region on success, else -1 on error.
-*/
{
- int i;
- mtrr_type ltype;
unsigned long lbase, lsize;
+ mtrr_type ltype;
+ int i;
switch (replace_reg) {
case 7:
@@ -107,14 +112,17 @@ cyrix_get_free_region(unsigned long base, unsigned long size, int replace_reg)
cyrix_get_arr(7, &lbase, &lsize, <ype);
if (lsize == 0)
return 7;
- /* Else try ARR0-ARR6 first */
+ /* Else try ARR0-ARR6 first */
} else {
for (i = 0; i < 7; i++) {
cyrix_get_arr(i, &lbase, &lsize, <ype);
if (lsize == 0)
return i;
}
- /* ARR0-ARR6 isn't free, try ARR7 but its size must be at least 256K */
+ /*
+ * ARR0-ARR6 isn't free
+ * try ARR7 but its size must be at least 256K
+ */
cyrix_get_arr(i, &lbase, &lsize, <ype);
if ((lsize == 0) && (size >= 0x40))
return i;
@@ -122,21 +130,22 @@ cyrix_get_free_region(unsigned long base, unsigned long size, int replace_reg)
return -ENOSPC;
}
-static u32 cr4 = 0;
-static u32 ccr3;
+static u32 cr4, ccr3;
static void prepare_set(void)
{
u32 cr0;
/* Save value of CR4 and clear Page Global Enable (bit 7) */
- if ( cpu_has_pge ) {
+ if (cpu_has_pge) {
cr4 = read_cr4();
write_cr4(cr4 & ~X86_CR4_PGE);
}
- /* Disable and flush caches. Note that wbinvd flushes the TLBs as
- a side-effect */
+ /*
+ * Disable and flush caches.
+ * Note that wbinvd flushes the TLBs as a side-effect
+ */
cr0 = read_cr0() | X86_CR0_CD;
wbinvd();
write_cr0(cr0);
@@ -147,22 +156,21 @@ static void prepare_set(void)
/* Cyrix ARRs - everything else was excluded at the top */
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10);
-
}
static void post_set(void)
{
- /* Flush caches and TLBs */
+ /* Flush caches and TLBs */
wbinvd();
/* Cyrix ARRs - everything else was excluded at the top */
setCx86(CX86_CCR3, ccr3);
-
- /* Enable caches */
+
+ /* Enable caches */
write_cr0(read_cr0() & 0xbfffffff);
- /* Restore value of CR4 */
- if ( cpu_has_pge )
+ /* Restore value of CR4 */
+ if (cpu_has_pge)
write_cr4(cr4);
}
@@ -178,7 +186,8 @@ static void cyrix_set_arr(unsigned int reg, unsigned long base,
size >>= 6;
size &= 0x7fff; /* make sure arr_size <= 14 */
- for (arr_size = 0; size; arr_size++, size >>= 1) ;
+ for (arr_size = 0; size; arr_size++, size >>= 1)
+ ;
if (reg < 7) {
switch (type) {
@@ -215,18 +224,18 @@ static void cyrix_set_arr(unsigned int reg, unsigned long base,
prepare_set();
base <<= PAGE_SHIFT;
- setCx86(arr, ((unsigned char *) &base)[3]);
- setCx86(arr + 1, ((unsigned char *) &base)[2]);
- setCx86(arr + 2, (((unsigned char *) &base)[1]) | arr_size);
+ setCx86(arr + 0, ((unsigned char *)&base)[3]);
+ setCx86(arr + 1, ((unsigned char *)&base)[2]);
+ setCx86(arr + 2, (((unsigned char *)&base)[1]) | arr_size);
setCx86(CX86_RCR_BASE + reg, arr_type);
post_set();
}
typedef struct {
- unsigned long base;
- unsigned long size;
- mtrr_type type;
+ unsigned long base;
+ unsigned long size;
+ mtrr_type type;
} arr_state_t;
static arr_state_t arr_state[8] = {
@@ -247,16 +256,17 @@ static void cyrix_set_all(void)
setCx86(CX86_CCR0 + i, ccr_state[i]);
for (; i < 7; i++)
setCx86(CX86_CCR4 + i, ccr_state[i]);
- for (i = 0; i < 8; i++)
- cyrix_set_arr(i, arr_state[i].base,
+
+ for (i = 0; i < 8; i++) {
+ cyrix_set_arr(i, arr_state[i].base,
arr_state[i].size, arr_state[i].type);
+ }
post_set();
}
static struct mtrr_ops cyrix_mtrr_ops = {
.vendor = X86_VENDOR_CYRIX,
-// .init = cyrix_arr_init,
.set_all = cyrix_set_all,
.set = cyrix_set_arr,
.get = cyrix_get_arr,
@@ -270,5 +280,3 @@ int __init cyrix_init_mtrr(void)
set_mtrr_ops(&cyrix_mtrr_ops);
return 0;
}
-
-//arch_initcall(cyrix_init_mtrr);
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [tip:x86/cleanups] x86: Clean up mtrr/generic.c
2009-07-03 16:42 ` Ingo Molnar
` (5 preceding siblings ...)
2009-07-04 10:07 ` [tip:x86/cleanups] x86: Clean up mtrr/cyrix.c tip-bot for Jaswinder Singh Rajput
@ 2009-07-04 10:07 ` tip-bot for Jaswinder Singh Rajput
2009-07-04 10:07 ` [tip:x86/cleanups] x86: Clean up mtrr/if.c tip-bot for Jaswinder Singh Rajput
` (4 subsequent siblings)
11 siblings, 0 replies; 60+ messages in thread
From: tip-bot for Jaswinder Singh Rajput @ 2009-07-04 10:07 UTC (permalink / raw)
To: linux-tip-commits
Cc: linux-kernel, hpa, mingo, yinghai, jaswinder, alan,
jaswinderrajput, akpm, tglx, mingo
Commit-ID: a1a499a39911fcfecbebaba1f38588088909f918
Gitweb: http://git.kernel.org/tip/a1a499a39911fcfecbebaba1f38588088909f918
Author: Jaswinder Singh Rajput <jaswinder@kernel.org>
AuthorDate: Sat, 4 Jul 2009 07:53:00 +0530
Committer: Ingo Molnar <mingo@elte.hu>
CommitDate: Sat, 4 Jul 2009 11:10:47 +0200
x86: Clean up mtrr/generic.c
Fix following trivial style problems:
ERROR: trailing whitespace X 4
WARNING: Use #include <linux/io.h> instead of <asm/io.h>
WARNING: braces {} are not necessary for single statement blocks X 3
ERROR: "foo * bar" should be "foo *bar"
WARNING: line over 80 characters X 6
ERROR: "foo * bar" should be "foo *bar"
ERROR: spaces required around that '=' (ctx:VxO)
ERROR: space required before that '-' (ctx:OxV)
WARNING: suspect code indent for conditional statements (8, 12)
ERROR: spaces required around that '=' (ctx:VxV)
ERROR: do not initialise statics to 0 or NULL
ERROR: space prohibited after that open parenthesis '(' X 2
ERROR: space prohibited before that close parenthesis ')' X 2
ERROR: trailing statements should be on next line
ERROR: return is not a function, parentheses are not required
Also use pr_debug and pr_warning where possible.
arch/x86/kernel/cpu/mtrr/generic.o:
text data bss dec hex filename
5652 77 4224 9953 26e1 generic.o.before
5652 77 4220 9949 26dd generic.o.after
The md5 changed:
b34d6c045f06daa4ed092b90cc760e8f generic.o.before.asm
a490c6251cfd8442fbffecc0e09a573d generic.o.after.asm
Because mtrr_state moved from data to bss, changing its
offsets - and also because __LINE__ numbers changed.
Suggested-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Yinghai Lu <yinghai@kernel.org>
LKML-Reference: <20090703164225.GA21447@elte.hu>
[ Further cleanups to make the code more consistent ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/cpu/mtrr/generic.c | 304 ++++++++++++++++++++----------------
1 files changed, 169 insertions(+), 135 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/generic.c b/arch/x86/kernel/cpu/mtrr/generic.c
index 0543f69..55da0c5 100644
--- a/arch/x86/kernel/cpu/mtrr/generic.c
+++ b/arch/x86/kernel/cpu/mtrr/generic.c
@@ -1,28 +1,34 @@
-/* This only handles 32bit MTRR on 32bit hosts. This is strictly wrong
- because MTRRs can span upto 40 bits (36bits on most modern x86) */
+/*
+ * This only handles 32bit MTRR on 32bit hosts. This is strictly wrong
+ * because MTRRs can span upto 40 bits (36bits on most modern x86)
+ */
+#define DEBUG
+
+#include <linux/module.h>
#include <linux/init.h>
#include <linux/slab.h>
+#include <linux/io.h>
#include <linux/mm.h>
-#include <linux/module.h>
-#include <asm/io.h>
-#include <asm/mtrr.h>
-#include <asm/msr.h>
-#include <asm/system.h>
-#include <asm/cpufeature.h>
+
#include <asm/processor-flags.h>
+#include <asm/cpufeature.h>
#include <asm/tlbflush.h>
+#include <asm/system.h>
+#include <asm/mtrr.h>
+#include <asm/msr.h>
#include <asm/pat.h>
+
#include "mtrr.h"
struct fixed_range_block {
- int base_msr; /* start address of an MTRR block */
- int ranges; /* number of MTRRs in this block */
+ int base_msr; /* start address of an MTRR block */
+ int ranges; /* number of MTRRs in this block */
};
static struct fixed_range_block fixed_range_blocks[] = {
- { MSR_MTRRfix64K_00000, 1 }, /* one 64k MTRR */
- { MSR_MTRRfix16K_80000, 2 }, /* two 16k MTRRs */
- { MSR_MTRRfix4K_C0000, 8 }, /* eight 4k MTRRs */
+ { MSR_MTRRfix64K_00000, 1 }, /* one 64k MTRR */
+ { MSR_MTRRfix16K_80000, 2 }, /* two 16k MTRRs */
+ { MSR_MTRRfix4K_C0000, 8 }, /* eight 4k MTRRs */
{}
};
@@ -30,10 +36,10 @@ static unsigned long smp_changes_mask;
static int mtrr_state_set;
u64 mtrr_tom2;
-struct mtrr_state_type mtrr_state = {};
+struct mtrr_state_type mtrr_state;
EXPORT_SYMBOL_GPL(mtrr_state);
-/**
+/*
* BIOS is expected to clear MtrrFixDramModEn bit, see for example
* "BIOS and Kernel Developer's Guide for the AMD Athlon 64 and AMD
* Opteron Processors" (26094 Rev. 3.30 February 2006), section
@@ -104,9 +110,8 @@ u8 mtrr_type_lookup(u64 start, u64 end)
* Look of multiple ranges matching this address and pick type
* as per MTRR precedence
*/
- if (!(mtrr_state.enabled & 2)) {
+ if (!(mtrr_state.enabled & 2))
return mtrr_state.def_type;
- }
prev_match = 0xFF;
for (i = 0; i < num_var_ranges; ++i) {
@@ -125,9 +130,8 @@ u8 mtrr_type_lookup(u64 start, u64 end)
if (start_state != end_state)
return 0xFE;
- if ((start & mask) != (base & mask)) {
+ if ((start & mask) != (base & mask))
continue;
- }
curr_match = mtrr_state.var_ranges[i].base_lo & 0xff;
if (prev_match == 0xFF) {
@@ -148,9 +152,8 @@ u8 mtrr_type_lookup(u64 start, u64 end)
curr_match = MTRR_TYPE_WRTHROUGH;
}
- if (prev_match != curr_match) {
+ if (prev_match != curr_match)
return MTRR_TYPE_UNCACHABLE;
- }
}
if (mtrr_tom2) {
@@ -164,7 +167,7 @@ u8 mtrr_type_lookup(u64 start, u64 end)
return mtrr_state.def_type;
}
-/* Get the MSR pair relating to a var range */
+/* Get the MSR pair relating to a var range */
static void
get_mtrr_var_range(unsigned int index, struct mtrr_var_range *vr)
{
@@ -172,7 +175,7 @@ get_mtrr_var_range(unsigned int index, struct mtrr_var_range *vr)
rdmsr(MTRRphysMask_MSR(index), vr->mask_lo, vr->mask_hi);
}
-/* fill the MSR pair relating to a var range */
+/* Fill the MSR pair relating to a var range */
void fill_mtrr_var_range(unsigned int index,
u32 base_lo, u32 base_hi, u32 mask_lo, u32 mask_hi)
{
@@ -186,10 +189,9 @@ void fill_mtrr_var_range(unsigned int index,
vr[index].mask_hi = mask_hi;
}
-static void
-get_fixed_ranges(mtrr_type * frs)
+static void get_fixed_ranges(mtrr_type *frs)
{
- unsigned int *p = (unsigned int *) frs;
+ unsigned int *p = (unsigned int *)frs;
int i;
k8_check_syscfg_dram_mod_en();
@@ -217,22 +219,22 @@ static void __init print_fixed_last(void)
if (!last_fixed_end)
return;
- printk(KERN_DEBUG " %05X-%05X %s\n", last_fixed_start,
- last_fixed_end - 1, mtrr_attrib_to_str(last_fixed_type));
+ pr_debug(" %05X-%05X %s\n", last_fixed_start,
+ last_fixed_end - 1, mtrr_attrib_to_str(last_fixed_type));
last_fixed_end = 0;
}
static void __init update_fixed_last(unsigned base, unsigned end,
- mtrr_type type)
+ mtrr_type type)
{
last_fixed_start = base;
last_fixed_end = end;
last_fixed_type = type;
}
-static void __init print_fixed(unsigned base, unsigned step,
- const mtrr_type *types)
+static void __init
+print_fixed(unsigned base, unsigned step, const mtrr_type *types)
{
unsigned i;
@@ -259,54 +261,55 @@ static void __init print_mtrr_state(void)
unsigned int i;
int high_width;
- printk(KERN_DEBUG "MTRR default type: %s\n",
- mtrr_attrib_to_str(mtrr_state.def_type));
+ pr_debug("MTRR default type: %s\n",
+ mtrr_attrib_to_str(mtrr_state.def_type));
if (mtrr_state.have_fixed) {
- printk(KERN_DEBUG "MTRR fixed ranges %sabled:\n",
- mtrr_state.enabled & 1 ? "en" : "dis");
+ pr_debug("MTRR fixed ranges %sabled:\n",
+ mtrr_state.enabled & 1 ? "en" : "dis");
print_fixed(0x00000, 0x10000, mtrr_state.fixed_ranges + 0);
for (i = 0; i < 2; ++i)
- print_fixed(0x80000 + i * 0x20000, 0x04000, mtrr_state.fixed_ranges + (i + 1) * 8);
+ print_fixed(0x80000 + i * 0x20000, 0x04000,
+ mtrr_state.fixed_ranges + (i + 1) * 8);
for (i = 0; i < 8; ++i)
- print_fixed(0xC0000 + i * 0x08000, 0x01000, mtrr_state.fixed_ranges + (i + 3) * 8);
+ print_fixed(0xC0000 + i * 0x08000, 0x01000,
+ mtrr_state.fixed_ranges + (i + 3) * 8);
/* tail */
print_fixed_last();
}
- printk(KERN_DEBUG "MTRR variable ranges %sabled:\n",
- mtrr_state.enabled & 2 ? "en" : "dis");
+ pr_debug("MTRR variable ranges %sabled:\n",
+ mtrr_state.enabled & 2 ? "en" : "dis");
if (size_or_mask & 0xffffffffUL)
high_width = ffs(size_or_mask & 0xffffffffUL) - 1;
else
high_width = ffs(size_or_mask>>32) + 32 - 1;
high_width = (high_width - (32 - PAGE_SHIFT) + 3) / 4;
+
for (i = 0; i < num_var_ranges; ++i) {
if (mtrr_state.var_ranges[i].mask_lo & (1 << 11))
- printk(KERN_DEBUG " %u base %0*X%05X000 mask %0*X%05X000 %s\n",
- i,
- high_width,
- mtrr_state.var_ranges[i].base_hi,
- mtrr_state.var_ranges[i].base_lo >> 12,
- high_width,
- mtrr_state.var_ranges[i].mask_hi,
- mtrr_state.var_ranges[i].mask_lo >> 12,
- mtrr_attrib_to_str(mtrr_state.var_ranges[i].base_lo & 0xff));
+ pr_debug(" %u base %0*X%05X000 mask %0*X%05X000 %s\n",
+ i,
+ high_width,
+ mtrr_state.var_ranges[i].base_hi,
+ mtrr_state.var_ranges[i].base_lo >> 12,
+ high_width,
+ mtrr_state.var_ranges[i].mask_hi,
+ mtrr_state.var_ranges[i].mask_lo >> 12,
+ mtrr_attrib_to_str(mtrr_state.var_ranges[i].base_lo & 0xff));
else
- printk(KERN_DEBUG " %u disabled\n", i);
- }
- if (mtrr_tom2) {
- printk(KERN_DEBUG "TOM2: %016llx aka %lldM\n",
- mtrr_tom2, mtrr_tom2>>20);
+ pr_debug(" %u disabled\n", i);
}
+ if (mtrr_tom2)
+ pr_debug("TOM2: %016llx aka %lldM\n", mtrr_tom2, mtrr_tom2>>20);
}
-/* Grab all of the MTRR state for this CPU into *state */
+/* Grab all of the MTRR state for this CPU into *state */
void __init get_mtrr_state(void)
{
- unsigned int i;
struct mtrr_var_range *vrs;
- unsigned lo, dummy;
unsigned long flags;
+ unsigned lo, dummy;
+ unsigned int i;
vrs = mtrr_state.var_ranges;
@@ -324,6 +327,7 @@ void __init get_mtrr_state(void)
if (amd_special_default_mtrr()) {
unsigned low, high;
+
/* TOP_MEM2 */
rdmsr(MSR_K8_TOP_MEM2, low, high);
mtrr_tom2 = high;
@@ -344,10 +348,9 @@ void __init get_mtrr_state(void)
post_set();
local_irq_restore(flags);
-
}
-/* Some BIOS's are fucked and don't set all MTRRs the same! */
+/* Some BIOS's are messed up and don't set all MTRRs the same! */
void __init mtrr_state_warn(void)
{
unsigned long mask = smp_changes_mask;
@@ -355,28 +358,33 @@ void __init mtrr_state_warn(void)
if (!mask)
return;
if (mask & MTRR_CHANGE_MASK_FIXED)
- printk(KERN_WARNING "mtrr: your CPUs had inconsistent fixed MTRR settings\n");
+ pr_warning("mtrr: your CPUs had inconsistent fixed MTRR settings\n");
if (mask & MTRR_CHANGE_MASK_VARIABLE)
- printk(KERN_WARNING "mtrr: your CPUs had inconsistent variable MTRR settings\n");
+ pr_warning("mtrr: your CPUs had inconsistent variable MTRR settings\n");
if (mask & MTRR_CHANGE_MASK_DEFTYPE)
- printk(KERN_WARNING "mtrr: your CPUs had inconsistent MTRRdefType settings\n");
+ pr_warning("mtrr: your CPUs had inconsistent MTRRdefType settings\n");
+
printk(KERN_INFO "mtrr: probably your BIOS does not setup all CPUs.\n");
printk(KERN_INFO "mtrr: corrected configuration.\n");
}
-/* Doesn't attempt to pass an error out to MTRR users
- because it's quite complicated in some cases and probably not
- worth it because the best error handling is to ignore it. */
+/*
+ * Doesn't attempt to pass an error out to MTRR users
+ * because it's quite complicated in some cases and probably not
+ * worth it because the best error handling is to ignore it.
+ */
void mtrr_wrmsr(unsigned msr, unsigned a, unsigned b)
{
- if (wrmsr_safe(msr, a, b) < 0)
+ if (wrmsr_safe(msr, a, b) < 0) {
printk(KERN_ERR
"MTRR: CPU %u: Writing MSR %x to %x:%x failed\n",
smp_processor_id(), msr, a, b);
+ }
}
/**
- * set_fixed_range - checks & updates a fixed-range MTRR if it differs from the value it should have
+ * set_fixed_range - checks & updates a fixed-range MTRR if it
+ * differs from the value it should have
* @msr: MSR address of the MTTR which should be checked and updated
* @changed: pointer which indicates whether the MTRR needed to be changed
* @msrwords: pointer to the MSR values which the MSR should have
@@ -401,20 +409,23 @@ static void set_fixed_range(int msr, bool *changed, unsigned int *msrwords)
*
* Returns: The index of the region on success, else negative on error.
*/
-int generic_get_free_region(unsigned long base, unsigned long size, int replace_reg)
+int
+generic_get_free_region(unsigned long base, unsigned long size, int replace_reg)
{
- int i, max;
- mtrr_type ltype;
unsigned long lbase, lsize;
+ mtrr_type ltype;
+ int i, max;
max = num_var_ranges;
if (replace_reg >= 0 && replace_reg < max)
return replace_reg;
+
for (i = 0; i < max; ++i) {
mtrr_if->get(i, &lbase, &lsize, <ype);
if (lsize == 0)
return i;
}
+
return -ENOSPC;
}
@@ -434,7 +445,7 @@ static void generic_get_mtrr(unsigned int reg, unsigned long *base,
rdmsr(MTRRphysMask_MSR(reg), mask_lo, mask_hi);
if ((mask_lo & 0x800) == 0) {
- /* Invalid (i.e. free) range */
+ /* Invalid (i.e. free) range */
*base = 0;
*size = 0;
*type = 0;
@@ -471,27 +482,31 @@ out_put_cpu:
}
/**
- * set_fixed_ranges - checks & updates the fixed-range MTRRs if they differ from the saved set
+ * set_fixed_ranges - checks & updates the fixed-range MTRRs if they
+ * differ from the saved set
* @frs: pointer to fixed-range MTRR values, saved by get_fixed_ranges()
*/
-static int set_fixed_ranges(mtrr_type * frs)
+static int set_fixed_ranges(mtrr_type *frs)
{
- unsigned long long *saved = (unsigned long long *) frs;
+ unsigned long long *saved = (unsigned long long *)frs;
bool changed = false;
- int block=-1, range;
+ int block = -1, range;
k8_check_syscfg_dram_mod_en();
- while (fixed_range_blocks[++block].ranges)
- for (range=0; range < fixed_range_blocks[block].ranges; range++)
- set_fixed_range(fixed_range_blocks[block].base_msr + range,
- &changed, (unsigned int *) saved++);
+ while (fixed_range_blocks[++block].ranges) {
+ for (range = 0; range < fixed_range_blocks[block].ranges; range++)
+ set_fixed_range(fixed_range_blocks[block].base_msr + range,
+ &changed, (unsigned int *)saved++);
+ }
return changed;
}
-/* Set the MSR pair relating to a var range. Returns TRUE if
- changes are made */
+/*
+ * Set the MSR pair relating to a var range.
+ * Returns true if changes are made.
+ */
static bool set_mtrr_var_ranges(unsigned int index, struct mtrr_var_range *vr)
{
unsigned int lo, hi;
@@ -501,6 +516,7 @@ static bool set_mtrr_var_ranges(unsigned int index, struct mtrr_var_range *vr)
if ((vr->base_lo & 0xfffff0ffUL) != (lo & 0xfffff0ffUL)
|| (vr->base_hi & (size_and_mask >> (32 - PAGE_SHIFT))) !=
(hi & (size_and_mask >> (32 - PAGE_SHIFT)))) {
+
mtrr_wrmsr(MTRRphysBase_MSR(index), vr->base_lo, vr->base_hi);
changed = true;
}
@@ -526,21 +542,26 @@ static u32 deftype_lo, deftype_hi;
*/
static unsigned long set_mtrr_state(void)
{
- unsigned int i;
unsigned long change_mask = 0;
+ unsigned int i;
- for (i = 0; i < num_var_ranges; i++)
+ for (i = 0; i < num_var_ranges; i++) {
if (set_mtrr_var_ranges(i, &mtrr_state.var_ranges[i]))
change_mask |= MTRR_CHANGE_MASK_VARIABLE;
+ }
if (mtrr_state.have_fixed && set_fixed_ranges(mtrr_state.fixed_ranges))
change_mask |= MTRR_CHANGE_MASK_FIXED;
- /* Set_mtrr_restore restores the old value of MTRRdefType,
- so to set it we fiddle with the saved value */
+ /*
+ * Set_mtrr_restore restores the old value of MTRRdefType,
+ * so to set it we fiddle with the saved value:
+ */
if ((deftype_lo & 0xff) != mtrr_state.def_type
|| ((deftype_lo & 0xc00) >> 10) != mtrr_state.enabled) {
- deftype_lo = (deftype_lo & ~0xcff) | mtrr_state.def_type | (mtrr_state.enabled << 10);
+
+ deftype_lo = (deftype_lo & ~0xcff) | mtrr_state.def_type |
+ (mtrr_state.enabled << 10);
change_mask |= MTRR_CHANGE_MASK_DEFTYPE;
}
@@ -548,33 +569,36 @@ static unsigned long set_mtrr_state(void)
}
-static unsigned long cr4 = 0;
+static unsigned long cr4;
static DEFINE_SPINLOCK(set_atomicity_lock);
/*
- * Since we are disabling the cache don't allow any interrupts - they
- * would run extremely slow and would only increase the pain. The caller must
- * ensure that local interrupts are disabled and are reenabled after post_set()
- * has been called.
+ * Since we are disabling the cache don't allow any interrupts,
+ * they would run extremely slow and would only increase the pain.
+ *
+ * The caller must ensure that local interrupts are disabled and
+ * are reenabled after post_set() has been called.
*/
-
static void prepare_set(void) __acquires(set_atomicity_lock)
{
unsigned long cr0;
- /* Note that this is not ideal, since the cache is only flushed/disabled
- for this CPU while the MTRRs are changed, but changing this requires
- more invasive changes to the way the kernel boots */
+ /*
+ * Note that this is not ideal
+ * since the cache is only flushed/disabled for this CPU while the
+ * MTRRs are changed, but changing this requires more invasive
+ * changes to the way the kernel boots
+ */
spin_lock(&set_atomicity_lock);
- /* Enter the no-fill (CD=1, NW=0) cache mode and flush caches. */
+ /* Enter the no-fill (CD=1, NW=0) cache mode and flush caches. */
cr0 = read_cr0() | X86_CR0_CD;
write_cr0(cr0);
wbinvd();
- /* Save value of CR4 and clear Page Global Enable (bit 7) */
- if ( cpu_has_pge ) {
+ /* Save value of CR4 and clear Page Global Enable (bit 7) */
+ if (cpu_has_pge) {
cr4 = read_cr4();
write_cr4(cr4 & ~X86_CR4_PGE);
}
@@ -582,26 +606,26 @@ static void prepare_set(void) __acquires(set_atomicity_lock)
/* Flush all TLBs via a mov %cr3, %reg; mov %reg, %cr3 */
__flush_tlb();
- /* Save MTRR state */
+ /* Save MTRR state */
rdmsr(MSR_MTRRdefType, deftype_lo, deftype_hi);
- /* Disable MTRRs, and set the default type to uncached */
+ /* Disable MTRRs, and set the default type to uncached */
mtrr_wrmsr(MSR_MTRRdefType, deftype_lo & ~0xcff, deftype_hi);
}
static void post_set(void) __releases(set_atomicity_lock)
{
- /* Flush TLBs (no need to flush caches - they are disabled) */
+ /* Flush TLBs (no need to flush caches - they are disabled) */
__flush_tlb();
/* Intel (P6) standard MTRRs */
mtrr_wrmsr(MSR_MTRRdefType, deftype_lo, deftype_hi);
-
- /* Enable caches */
+
+ /* Enable caches */
write_cr0(read_cr0() & 0xbfffffff);
- /* Restore value of CR4 */
- if ( cpu_has_pge )
+ /* Restore value of CR4 */
+ if (cpu_has_pge)
write_cr4(cr4);
spin_unlock(&set_atomicity_lock);
}
@@ -623,24 +647,27 @@ static void generic_set_all(void)
post_set();
local_irq_restore(flags);
- /* Use the atomic bitops to update the global mask */
+ /* Use the atomic bitops to update the global mask */
for (count = 0; count < sizeof mask * 8; ++count) {
if (mask & 0x01)
set_bit(count, &smp_changes_mask);
mask >>= 1;
}
-
+
}
+/**
+ * generic_set_mtrr - set variable MTRR register on the local CPU.
+ *
+ * @reg: The register to set.
+ * @base: The base address of the region.
+ * @size: The size of the region. If this is 0 the region is disabled.
+ * @type: The type of the region.
+ *
+ * Returns nothing.
+ */
static void generic_set_mtrr(unsigned int reg, unsigned long base,
unsigned long size, mtrr_type type)
-/* [SUMMARY] Set variable MTRR register on the local CPU.
- <reg> The register to set.
- <base> The base address of the region.
- <size> The size of the region. If this is 0 the region is disabled.
- <type> The type of the region.
- [RETURNS] Nothing.
-*/
{
unsigned long flags;
struct mtrr_var_range *vr;
@@ -651,8 +678,10 @@ static void generic_set_mtrr(unsigned int reg, unsigned long base,
prepare_set();
if (size == 0) {
- /* The invalid bit is kept in the mask, so we simply clear the
- relevant mask register to disable a range. */
+ /*
+ * The invalid bit is kept in the mask, so we simply
+ * clear the relevant mask register to disable a range.
+ */
mtrr_wrmsr(MTRRphysMask_MSR(reg), 0, 0);
memset(vr, 0, sizeof(struct mtrr_var_range));
} else {
@@ -669,46 +698,50 @@ static void generic_set_mtrr(unsigned int reg, unsigned long base,
local_irq_restore(flags);
}
-int generic_validate_add_page(unsigned long base, unsigned long size, unsigned int type)
+int generic_validate_add_page(unsigned long base, unsigned long size,
+ unsigned int type)
{
unsigned long lbase, last;
- /* For Intel PPro stepping <= 7, must be 4 MiB aligned
- and not touch 0x70000000->0x7003FFFF */
+ /*
+ * For Intel PPro stepping <= 7
+ * must be 4 MiB aligned and not touch 0x70000000 -> 0x7003FFFF
+ */
if (is_cpu(INTEL) && boot_cpu_data.x86 == 6 &&
boot_cpu_data.x86_model == 1 &&
boot_cpu_data.x86_mask <= 7) {
if (base & ((1 << (22 - PAGE_SHIFT)) - 1)) {
- printk(KERN_WARNING "mtrr: base(0x%lx000) is not 4 MiB aligned\n", base);
+ pr_warning("mtrr: base(0x%lx000) is not 4 MiB aligned\n", base);
return -EINVAL;
}
if (!(base + size < 0x70000 || base > 0x7003F) &&
(type == MTRR_TYPE_WRCOMB
|| type == MTRR_TYPE_WRBACK)) {
- printk(KERN_WARNING "mtrr: writable mtrr between 0x70000000 and 0x7003FFFF may hang the CPU.\n");
+ pr_warning("mtrr: writable mtrr between 0x70000000 and 0x7003FFFF may hang the CPU.\n");
return -EINVAL;
}
}
- /* Check upper bits of base and last are equal and lower bits are 0
- for base and 1 for last */
+ /*
+ * Check upper bits of base and last are equal and lower bits are 0
+ * for base and 1 for last
+ */
last = base + size - 1;
for (lbase = base; !(lbase & 1) && (last & 1);
- lbase = lbase >> 1, last = last >> 1) ;
+ lbase = lbase >> 1, last = last >> 1)
+ ;
if (lbase != last) {
- printk(KERN_WARNING "mtrr: base(0x%lx000) is not aligned on a size(0x%lx000) boundary\n",
- base, size);
+ pr_warning("mtrr: base(0x%lx000) is not aligned on a size(0x%lx000) boundary\n", base, size);
return -EINVAL;
}
return 0;
}
-
static int generic_have_wrcomb(void)
{
unsigned long config, dummy;
rdmsr(MSR_MTRRcap, config, dummy);
- return (config & (1 << 10));
+ return config & (1 << 10);
}
int positive_have_wrcomb(void)
@@ -716,14 +749,15 @@ int positive_have_wrcomb(void)
return 1;
}
-/* generic structure...
+/*
+ * Generic structure...
*/
struct mtrr_ops generic_mtrr_ops = {
- .use_intel_if = 1,
- .set_all = generic_set_all,
- .get = generic_get_mtrr,
- .get_free_region = generic_get_free_region,
- .set = generic_set_mtrr,
- .validate_add_page = generic_validate_add_page,
- .have_wrcomb = generic_have_wrcomb,
+ .use_intel_if = 1,
+ .set_all = generic_set_all,
+ .get = generic_get_mtrr,
+ .get_free_region = generic_get_free_region,
+ .set = generic_set_mtrr,
+ .validate_add_page = generic_validate_add_page,
+ .have_wrcomb = generic_have_wrcomb,
};
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [tip:x86/cleanups] x86: Clean up mtrr/if.c
2009-07-03 16:42 ` Ingo Molnar
` (6 preceding siblings ...)
2009-07-04 10:07 ` [tip:x86/cleanups] x86: Clean up mtrr/generic.c tip-bot for Jaswinder Singh Rajput
@ 2009-07-04 10:07 ` tip-bot for Jaswinder Singh Rajput
2009-07-04 10:07 ` [tip:x86/cleanups] x86: Clean up mtrr/mtrr.h tip-bot for Jaswinder Singh Rajput
` (3 subsequent siblings)
11 siblings, 0 replies; 60+ messages in thread
From: tip-bot for Jaswinder Singh Rajput @ 2009-07-04 10:07 UTC (permalink / raw)
To: linux-tip-commits
Cc: linux-kernel, hpa, mingo, yinghai, jaswinder, alan,
jaswinderrajput, akpm, tglx, mingo
Commit-ID: 26dc67eda19beafb7e5ef2770cec5b3ee5995a8e
Gitweb: http://git.kernel.org/tip/26dc67eda19beafb7e5ef2770cec5b3ee5995a8e
Author: Jaswinder Singh Rajput <jaswinder@kernel.org>
AuthorDate: Sat, 4 Jul 2009 07:53:40 +0530
Committer: Ingo Molnar <mingo@elte.hu>
CommitDate: Sat, 4 Jul 2009 11:19:48 +0200
x86: Clean up mtrr/if.c
Fix:
WARNING: Use #include <linux/uaccess.h> instead of <asm/uaccess.h>
ERROR: trailing whitespace X 7
ERROR: trailing statements should be on next line X 3
WARNING: line over 80 characters X 5
ERROR: space required before the open parenthesis '('
arch/x86/kernel/cpu/mtrr/if.o:
text data bss dec hex filename
2239 4 0 2243 8c3 if.o.before
2239 4 0 2243 8c3 if.o.after
md5:
78d1f2aa4843ec6509c18e2dee54bc7f if.o.before.asm
78d1f2aa4843ec6509c18e2dee54bc7f if.o.after.asm
Suggested-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Yinghai Lu <yinghai@kernel.org>
LKML-Reference: <20090703164225.GA21447@elte.hu>
[ More cleanups to make the code more consistent. ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/cpu/mtrr/if.c | 135 +++++++++++++++++++++++------------------
1 files changed, 76 insertions(+), 59 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/if.c b/arch/x86/kernel/cpu/mtrr/if.c
index fb73a52..08b6ea4 100644
--- a/arch/x86/kernel/cpu/mtrr/if.c
+++ b/arch/x86/kernel/cpu/mtrr/if.c
@@ -1,27 +1,28 @@
-#include <linux/init.h>
-#include <linux/proc_fs.h>
#include <linux/capability.h>
-#include <linux/ctype.h>
-#include <linux/module.h>
#include <linux/seq_file.h>
-#include <asm/uaccess.h>
+#include <linux/uaccess.h>
+#include <linux/proc_fs.h>
+#include <linux/module.h>
+#include <linux/ctype.h>
+#include <linux/init.h>
#define LINE_SIZE 80
#include <asm/mtrr.h>
+
#include "mtrr.h"
#define FILE_FCOUNT(f) (((struct seq_file *)((f)->private_data))->private)
static const char *const mtrr_strings[MTRR_NUM_TYPES] =
{
- "uncachable", /* 0 */
- "write-combining", /* 1 */
- "?", /* 2 */
- "?", /* 3 */
- "write-through", /* 4 */
- "write-protect", /* 5 */
- "write-back", /* 6 */
+ "uncachable", /* 0 */
+ "write-combining", /* 1 */
+ "?", /* 2 */
+ "?", /* 3 */
+ "write-through", /* 4 */
+ "write-protect", /* 5 */
+ "write-back", /* 6 */
};
const char *mtrr_attrib_to_str(int x)
@@ -35,8 +36,8 @@ static int
mtrr_file_add(unsigned long base, unsigned long size,
unsigned int type, bool increment, struct file *file, int page)
{
+ unsigned int *fcount = FILE_FCOUNT(file);
int reg, max;
- unsigned int *fcount = FILE_FCOUNT(file);
max = num_var_ranges;
if (fcount == NULL) {
@@ -61,8 +62,8 @@ static int
mtrr_file_del(unsigned long base, unsigned long size,
struct file *file, int page)
{
- int reg;
unsigned int *fcount = FILE_FCOUNT(file);
+ int reg;
if (!page) {
if ((base & (PAGE_SIZE - 1)) || (size & (PAGE_SIZE - 1)))
@@ -81,13 +82,14 @@ mtrr_file_del(unsigned long base, unsigned long size,
return reg;
}
-/* RED-PEN: seq_file can seek now. this is ignored. */
+/*
+ * seq_file can seek but we ignore it.
+ *
+ * Format of control line:
+ * "base=%Lx size=%Lx type=%s" or "disable=%d"
+ */
static ssize_t
mtrr_write(struct file *file, const char __user *buf, size_t len, loff_t * ppos)
-/* Format of control line:
- "base=%Lx size=%Lx type=%s" OR:
- "disable=%d"
-*/
{
int i, err;
unsigned long reg;
@@ -100,15 +102,18 @@ mtrr_write(struct file *file, const char __user *buf, size_t len, loff_t * ppos)
return -EPERM;
if (!len)
return -EINVAL;
+
memset(line, 0, LINE_SIZE);
if (len > LINE_SIZE)
len = LINE_SIZE;
if (copy_from_user(line, buf, len - 1))
return -EFAULT;
+
linelen = strlen(line);
ptr = line + linelen - 1;
if (linelen && *ptr == '\n')
*ptr = '\0';
+
if (!strncmp(line, "disable=", 8)) {
reg = simple_strtoul(line + 8, &ptr, 0);
err = mtrr_del_page(reg, 0, 0);
@@ -116,28 +121,35 @@ mtrr_write(struct file *file, const char __user *buf, size_t len, loff_t * ppos)
return err;
return len;
}
+
if (strncmp(line, "base=", 5))
return -EINVAL;
+
base = simple_strtoull(line + 5, &ptr, 0);
- for (; isspace(*ptr); ++ptr) ;
+ for (; isspace(*ptr); ++ptr)
+ ;
+
if (strncmp(ptr, "size=", 5))
return -EINVAL;
+
size = simple_strtoull(ptr + 5, &ptr, 0);
if ((base & 0xfff) || (size & 0xfff))
return -EINVAL;
- for (; isspace(*ptr); ++ptr) ;
+ for (; isspace(*ptr); ++ptr)
+ ;
+
if (strncmp(ptr, "type=", 5))
return -EINVAL;
ptr += 5;
- for (; isspace(*ptr); ++ptr) ;
+ for (; isspace(*ptr); ++ptr)
+ ;
+
for (i = 0; i < MTRR_NUM_TYPES; ++i) {
if (strcmp(ptr, mtrr_strings[i]))
continue;
base >>= PAGE_SHIFT;
size >>= PAGE_SHIFT;
- err =
- mtrr_add_page((unsigned long) base, (unsigned long) size, i,
- true);
+ err = mtrr_add_page((unsigned long)base, (unsigned long)size, i, true);
if (err < 0)
return err;
return len;
@@ -181,7 +193,9 @@ mtrr_ioctl(struct file *file, unsigned int cmd, unsigned long __arg)
case MTRRIOC32_SET_PAGE_ENTRY:
case MTRRIOC32_DEL_PAGE_ENTRY:
case MTRRIOC32_KILL_PAGE_ENTRY: {
- struct mtrr_sentry32 __user *s32 = (struct mtrr_sentry32 __user *)__arg;
+ struct mtrr_sentry32 __user *s32;
+
+ s32 = (struct mtrr_sentry32 __user *)__arg;
err = get_user(sentry.base, &s32->base);
err |= get_user(sentry.size, &s32->size);
err |= get_user(sentry.type, &s32->type);
@@ -191,7 +205,9 @@ mtrr_ioctl(struct file *file, unsigned int cmd, unsigned long __arg)
}
case MTRRIOC32_GET_ENTRY:
case MTRRIOC32_GET_PAGE_ENTRY: {
- struct mtrr_gentry32 __user *g32 = (struct mtrr_gentry32 __user *)__arg;
+ struct mtrr_gentry32 __user *g32;
+
+ g32 = (struct mtrr_gentry32 __user *)__arg;
err = get_user(gentry.regnum, &g32->regnum);
err |= get_user(gentry.base, &g32->base);
err |= get_user(gentry.size, &g32->size);
@@ -314,7 +330,7 @@ mtrr_ioctl(struct file *file, unsigned int cmd, unsigned long __arg)
if (err)
return err;
- switch(cmd) {
+ switch (cmd) {
case MTRRIOC_GET_ENTRY:
case MTRRIOC_GET_PAGE_ENTRY:
if (copy_to_user(arg, &gentry, sizeof gentry))
@@ -323,7 +339,9 @@ mtrr_ioctl(struct file *file, unsigned int cmd, unsigned long __arg)
#ifdef CONFIG_COMPAT
case MTRRIOC32_GET_ENTRY:
case MTRRIOC32_GET_PAGE_ENTRY: {
- struct mtrr_gentry32 __user *g32 = (struct mtrr_gentry32 __user *)__arg;
+ struct mtrr_gentry32 __user *g32;
+
+ g32 = (struct mtrr_gentry32 __user *)__arg;
err = put_user(gentry.base, &g32->base);
err |= put_user(gentry.size, &g32->size);
err |= put_user(gentry.regnum, &g32->regnum);
@@ -335,11 +353,10 @@ mtrr_ioctl(struct file *file, unsigned int cmd, unsigned long __arg)
return err;
}
-static int
-mtrr_close(struct inode *ino, struct file *file)
+static int mtrr_close(struct inode *ino, struct file *file)
{
- int i, max;
unsigned int *fcount = FILE_FCOUNT(file);
+ int i, max;
if (fcount != NULL) {
max = num_var_ranges;
@@ -359,22 +376,22 @@ static int mtrr_seq_show(struct seq_file *seq, void *offset);
static int mtrr_open(struct inode *inode, struct file *file)
{
- if (!mtrr_if)
+ if (!mtrr_if)
return -EIO;
- if (!mtrr_if->get)
- return -ENXIO;
+ if (!mtrr_if->get)
+ return -ENXIO;
return single_open(file, mtrr_seq_show, NULL);
}
static const struct file_operations mtrr_fops = {
- .owner = THIS_MODULE,
- .open = mtrr_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .write = mtrr_write,
- .unlocked_ioctl = mtrr_ioctl,
- .compat_ioctl = mtrr_ioctl,
- .release = mtrr_close,
+ .owner = THIS_MODULE,
+ .open = mtrr_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .write = mtrr_write,
+ .unlocked_ioctl = mtrr_ioctl,
+ .compat_ioctl = mtrr_ioctl,
+ .release = mtrr_close,
};
static int mtrr_seq_show(struct seq_file *seq, void *offset)
@@ -388,23 +405,24 @@ static int mtrr_seq_show(struct seq_file *seq, void *offset)
max = num_var_ranges;
for (i = 0; i < max; i++) {
mtrr_if->get(i, &base, &size, &type);
- if (size == 0)
+ if (size == 0) {
mtrr_usage_table[i] = 0;
- else {
- if (size < (0x100000 >> PAGE_SHIFT)) {
- /* less than 1MB */
- factor = 'K';
- size <<= PAGE_SHIFT - 10;
- } else {
- factor = 'M';
- size >>= 20 - PAGE_SHIFT;
- }
- /* RED-PEN: base can be > 32bit */
- len += seq_printf(seq,
- "reg%02i: base=0x%06lx000 (%5luMB), size=%5lu%cB, count=%d: %s\n",
- i, base, base >> (20 - PAGE_SHIFT), size, factor,
- mtrr_usage_table[i], mtrr_attrib_to_str(type));
+ continue;
}
+ if (size < (0x100000 >> PAGE_SHIFT)) {
+ /* less than 1MB */
+ factor = 'K';
+ size <<= PAGE_SHIFT - 10;
+ } else {
+ factor = 'M';
+ size >>= 20 - PAGE_SHIFT;
+ }
+ /* Base can be > 32bit */
+ len += seq_printf(seq, "reg%02i: base=0x%06lx000 "
+ "(%5luMB), size=%5lu%cB, count=%d: %s\n",
+ i, base, base >> (20 - PAGE_SHIFT), size,
+ factor, mtrr_usage_table[i],
+ mtrr_attrib_to_str(type));
}
return 0;
}
@@ -422,6 +440,5 @@ static int __init mtrr_if_init(void)
proc_create("mtrr", S_IWUSR | S_IRUGO, NULL, &mtrr_fops);
return 0;
}
-
arch_initcall(mtrr_if_init);
#endif /* CONFIG_PROC_FS */
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [tip:x86/cleanups] x86: Clean up mtrr/mtrr.h
2009-07-03 16:42 ` Ingo Molnar
` (7 preceding siblings ...)
2009-07-04 10:07 ` [tip:x86/cleanups] x86: Clean up mtrr/if.c tip-bot for Jaswinder Singh Rajput
@ 2009-07-04 10:07 ` tip-bot for Jaswinder Singh Rajput
2009-07-04 10:08 ` [tip:x86/cleanups] x86: Clean up mtrr/state.c tip-bot for Jaswinder Singh Rajput
` (2 subsequent siblings)
11 siblings, 0 replies; 60+ messages in thread
From: tip-bot for Jaswinder Singh Rajput @ 2009-07-04 10:07 UTC (permalink / raw)
To: linux-tip-commits
Cc: linux-kernel, hpa, mingo, yinghai, jaswinder, alan,
jaswinderrajput, akpm, tglx, mingo
Commit-ID: 3ec8dbcb09bb6df83993ca03e88cb85e3aaa8edb
Gitweb: http://git.kernel.org/tip/3ec8dbcb09bb6df83993ca03e88cb85e3aaa8edb
Author: Jaswinder Singh Rajput <jaswinder@kernel.org>
AuthorDate: Sat, 4 Jul 2009 07:54:16 +0530
Committer: Ingo Molnar <mingo@elte.hu>
CommitDate: Sat, 4 Jul 2009 11:19:52 +0200
x86: Clean up mtrr/mtrr.h
Fix:
ERROR: do not use C99 // comments
ERROR: "foo * bar" should be "foo *bar" X 2
Suggested-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Yinghai Lu <yinghai@kernel.org>
LKML-Reference: <20090703164225.GA21447@elte.hu>
[ More tidyups ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/cpu/mtrr/mtrr.h | 19 +++++++++----------
1 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/mtrr.h b/arch/x86/kernel/cpu/mtrr/mtrr.h
index 7538b76..a501dee 100644
--- a/arch/x86/kernel/cpu/mtrr/mtrr.h
+++ b/arch/x86/kernel/cpu/mtrr/mtrr.h
@@ -1,5 +1,5 @@
/*
- * local mtrr defines.
+ * local MTRR defines.
*/
#include <linux/types.h>
@@ -14,13 +14,12 @@ extern unsigned int mtrr_usage_table[MTRR_MAX_VAR_RANGES];
struct mtrr_ops {
u32 vendor;
u32 use_intel_if;
-// void (*init)(void);
void (*set)(unsigned int reg, unsigned long base,
unsigned long size, mtrr_type type);
void (*set_all)(void);
void (*get)(unsigned int reg, unsigned long *base,
- unsigned long *size, mtrr_type * type);
+ unsigned long *size, mtrr_type *type);
int (*get_free_region)(unsigned long base, unsigned long size,
int replace_reg);
int (*validate_add_page)(unsigned long base, unsigned long size,
@@ -39,11 +38,11 @@ extern int positive_have_wrcomb(void);
/* library functions for processor-specific routines */
struct set_mtrr_context {
- unsigned long flags;
- unsigned long cr4val;
- u32 deftype_lo;
- u32 deftype_hi;
- u32 ccr3;
+ unsigned long flags;
+ unsigned long cr4val;
+ u32 deftype_lo;
+ u32 deftype_hi;
+ u32 ccr3;
};
void set_mtrr_done(struct set_mtrr_context *ctxt);
@@ -54,10 +53,10 @@ void fill_mtrr_var_range(unsigned int index,
u32 base_lo, u32 base_hi, u32 mask_lo, u32 mask_hi);
void get_mtrr_state(void);
-extern void set_mtrr_ops(struct mtrr_ops * ops);
+extern void set_mtrr_ops(struct mtrr_ops *ops);
extern u64 size_or_mask, size_and_mask;
-extern struct mtrr_ops * mtrr_if;
+extern struct mtrr_ops *mtrr_if;
#define is_cpu(vnd) (mtrr_if && mtrr_if->vendor == X86_VENDOR_##vnd)
#define use_intel() (mtrr_if && mtrr_if->use_intel_if == 1)
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [tip:x86/cleanups] x86: Clean up mtrr/state.c
2009-07-03 16:42 ` Ingo Molnar
` (8 preceding siblings ...)
2009-07-04 10:07 ` [tip:x86/cleanups] x86: Clean up mtrr/mtrr.h tip-bot for Jaswinder Singh Rajput
@ 2009-07-04 10:08 ` tip-bot for Jaswinder Singh Rajput
2009-07-04 10:08 ` [tip:x86/cleanups] x86: Clean up mtrr/main.c tip-bot for Jaswinder Singh Rajput
2009-07-05 7:57 ` [tip:x86/cleanups] x86: Further clean up of mtrr/generic.c tip-bot for Ingo Molnar
11 siblings, 0 replies; 60+ messages in thread
From: tip-bot for Jaswinder Singh Rajput @ 2009-07-04 10:08 UTC (permalink / raw)
To: linux-tip-commits
Cc: linux-kernel, hpa, mingo, yinghai, jaswinder, alan,
jaswinderrajput, akpm, tglx, mingo
Commit-ID: 09b22c85d59dd935fdfa71655a443785e3f99c18
Gitweb: http://git.kernel.org/tip/09b22c85d59dd935fdfa71655a443785e3f99c18
Author: Jaswinder Singh Rajput <jaswinder@kernel.org>
AuthorDate: Sat, 4 Jul 2009 07:54:53 +0530
Committer: Ingo Molnar <mingo@elte.hu>
CommitDate: Sat, 4 Jul 2009 11:19:53 +0200
x86: Clean up mtrr/state.c
Fix:
WARNING: Use #include <linux/io.h> instead of <asm/io.h>
WARNING: line over 80 characters X 4
arch/x86/kernel/cpu/mtrr/state.o:
text data bss dec hex filename
864 0 0 864 360 state.o.before
864 0 0 864 360 state.o.after
md5:
c5c4364b9aeac74d70111e1e49667a2c state.o.before.asm
c5c4364b9aeac74d70111e1e49667a2c state.o.after.asm
Suggested-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Yinghai Lu <yinghai@kernel.org>
LKML-Reference: <20090703164225.GA21447@elte.hu>
[ More cleanups ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/cpu/mtrr/state.c | 68 ++++++++++++++++++++++---------------
1 files changed, 40 insertions(+), 28 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/state.c b/arch/x86/kernel/cpu/mtrr/state.c
index 1f5fb15..dfc80b4 100644
--- a/arch/x86/kernel/cpu/mtrr/state.c
+++ b/arch/x86/kernel/cpu/mtrr/state.c
@@ -1,24 +1,25 @@
-#include <linux/mm.h>
#include <linux/init.h>
-#include <asm/io.h>
-#include <asm/mtrr.h>
-#include <asm/msr.h>
+#include <linux/io.h>
+#include <linux/mm.h>
+
#include <asm/processor-cyrix.h>
#include <asm/processor-flags.h>
-#include "mtrr.h"
+#include <asm/mtrr.h>
+#include <asm/msr.h>
+#include "mtrr.h"
-/* Put the processor into a state where MTRRs can be safely set */
+/* Put the processor into a state where MTRRs can be safely set */
void set_mtrr_prepare_save(struct set_mtrr_context *ctxt)
{
unsigned int cr0;
- /* Disable interrupts locally */
+ /* Disable interrupts locally */
local_irq_save(ctxt->flags);
if (use_intel() || is_cpu(CYRIX)) {
- /* Save value of CR4 and clear Page Global Enable (bit 7) */
+ /* Save value of CR4 and clear Page Global Enable (bit 7) */
if (cpu_has_pge) {
ctxt->cr4val = read_cr4();
write_cr4(ctxt->cr4val & ~X86_CR4_PGE);
@@ -33,50 +34,61 @@ void set_mtrr_prepare_save(struct set_mtrr_context *ctxt)
write_cr0(cr0);
wbinvd();
- if (use_intel())
- /* Save MTRR state */
+ if (use_intel()) {
+ /* Save MTRR state */
rdmsr(MSR_MTRRdefType, ctxt->deftype_lo, ctxt->deftype_hi);
- else
- /* Cyrix ARRs - everything else were excluded at the top */
+ } else {
+ /*
+ * Cyrix ARRs -
+ * everything else were excluded at the top
+ */
ctxt->ccr3 = getCx86(CX86_CCR3);
+ }
}
}
void set_mtrr_cache_disable(struct set_mtrr_context *ctxt)
{
- if (use_intel())
- /* Disable MTRRs, and set the default type to uncached */
+ if (use_intel()) {
+ /* Disable MTRRs, and set the default type to uncached */
mtrr_wrmsr(MSR_MTRRdefType, ctxt->deftype_lo & 0xf300UL,
ctxt->deftype_hi);
- else if (is_cpu(CYRIX))
- /* Cyrix ARRs - everything else were excluded at the top */
- setCx86(CX86_CCR3, (ctxt->ccr3 & 0x0f) | 0x10);
+ } else {
+ if (is_cpu(CYRIX)) {
+ /* Cyrix ARRs - everything else were excluded at the top */
+ setCx86(CX86_CCR3, (ctxt->ccr3 & 0x0f) | 0x10);
+ }
+ }
}
-/* Restore the processor after a set_mtrr_prepare */
+/* Restore the processor after a set_mtrr_prepare */
void set_mtrr_done(struct set_mtrr_context *ctxt)
{
if (use_intel() || is_cpu(CYRIX)) {
- /* Flush caches and TLBs */
+ /* Flush caches and TLBs */
wbinvd();
- /* Restore MTRRdefType */
- if (use_intel())
+ /* Restore MTRRdefType */
+ if (use_intel()) {
/* Intel (P6) standard MTRRs */
- mtrr_wrmsr(MSR_MTRRdefType, ctxt->deftype_lo, ctxt->deftype_hi);
- else
- /* Cyrix ARRs - everything else was excluded at the top */
+ mtrr_wrmsr(MSR_MTRRdefType, ctxt->deftype_lo,
+ ctxt->deftype_hi);
+ } else {
+ /*
+ * Cyrix ARRs -
+ * everything else was excluded at the top
+ */
setCx86(CX86_CCR3, ctxt->ccr3);
+ }
- /* Enable caches */
+ /* Enable caches */
write_cr0(read_cr0() & 0xbfffffff);
- /* Restore value of CR4 */
+ /* Restore value of CR4 */
if (cpu_has_pge)
write_cr4(ctxt->cr4val);
}
- /* Re-enable interrupts locally (if enabled previously) */
+ /* Re-enable interrupts locally (if enabled previously) */
local_irq_restore(ctxt->flags);
}
-
^ permalink raw reply related [flat|nested] 60+ messages in thread
* [tip:x86/cleanups] x86: Clean up mtrr/main.c
2009-07-03 16:42 ` Ingo Molnar
` (9 preceding siblings ...)
2009-07-04 10:08 ` [tip:x86/cleanups] x86: Clean up mtrr/state.c tip-bot for Jaswinder Singh Rajput
@ 2009-07-04 10:08 ` tip-bot for Jaswinder Singh Rajput
2009-07-05 7:57 ` [tip:x86/cleanups] x86: Further clean up of mtrr/generic.c tip-bot for Ingo Molnar
11 siblings, 0 replies; 60+ messages in thread
From: tip-bot for Jaswinder Singh Rajput @ 2009-07-04 10:08 UTC (permalink / raw)
To: linux-tip-commits
Cc: linux-kernel, hpa, mingo, yinghai, jaswinder, alan,
jaswinderrajput, akpm, tglx, mingo
Commit-ID: dbd51be026eaf84088fdee7fab9f38fa92eef26d
Gitweb: http://git.kernel.org/tip/dbd51be026eaf84088fdee7fab9f38fa92eef26d
Author: Jaswinder Singh Rajput <jaswinder@kernel.org>
AuthorDate: Sat, 4 Jul 2009 07:56:28 +0530
Committer: Ingo Molnar <mingo@elte.hu>
CommitDate: Sat, 4 Jul 2009 11:19:55 +0200
x86: Clean up mtrr/main.c
Fix following trivial style problems:
ERROR: trailing whitespace X 25
WARNING: Use #include <linux/uaccess.h> instead of <asm/uaccess.h>
WARNING: Use #include <linux/kvm_para.h> instead of <asm/kvm_para.h>
ERROR: do not initialise externals to 0 or NULL X 2
ERROR: "foo * bar" should be "foo *bar" X 5
ERROR: do not use assignment in if condition X 2
WARNING: line over 80 characters X 8
ERROR: return is not a function, parentheses are not required
WARNING: braces {} are not necessary for any arm of this statement
ERROR: space required before the open parenthesis '(' X 2
ERROR: open brace '{' following function declarations go on the next line
ERROR: space required after that ',' (ctx:VxV) X 8
ERROR: space required before the open parenthesis '(' X 3
ERROR: else should follow close brace '}'
WARNING: space prohibited between function name and open parenthesis '('
WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable X 2
Also use pr_debug and pr_warning where possible.
total: 50 errors, 14 warnings
arch/x86/kernel/cpu/mtrr/main.o:
text data bss dec hex filename
3668 116 4156 7940 1f04 main.o.before
3668 116 4156 7940 1f04 main.o.after
md5:
e01af2fd28deef77c8d01e71acfbd365 main.o.before.asm
e01af2fd28deef77c8d01e71acfbd365 main.o.after.asm
Suggested-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Yinghai Lu <yinghai@kernel.org>
LKML-Reference: <20090703164225.GA21447@elte.hu>
Cc: Avi Kivity <avi@redhat.com> # Avi, please have a look at the kvm_para.h bit
[ More cleanups ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/cpu/mtrr/main.c | 455 +++++++++++++++++++++------------------
1 files changed, 242 insertions(+), 213 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index 8fc248b..7af0f88 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -25,43 +25,48 @@
Operating System Writer's Guide" (Intel document number 242692),
section 11.11.7
- This was cleaned and made readable by Patrick Mochel <mochel@osdl.org>
- on 6-7 March 2002.
- Source: Intel Architecture Software Developers Manual, Volume 3:
+ This was cleaned and made readable by Patrick Mochel <mochel@osdl.org>
+ on 6-7 March 2002.
+ Source: Intel Architecture Software Developers Manual, Volume 3:
System Programming Guide; Section 9.11. (1997 edition - PPro).
*/
+#define DEBUG
+
+#include <linux/types.h> /* FIXME: kvm_para.h needs this */
+
+#include <linux/kvm_para.h>
+#include <linux/uaccess.h>
#include <linux/module.h>
+#include <linux/mutex.h>
#include <linux/init.h>
+#include <linux/sort.h>
+#include <linux/cpu.h>
#include <linux/pci.h>
#include <linux/smp.h>
-#include <linux/cpu.h>
-#include <linux/mutex.h>
-#include <linux/sort.h>
+#include <asm/processor.h>
#include <asm/e820.h>
#include <asm/mtrr.h>
-#include <asm/uaccess.h>
-#include <asm/processor.h>
#include <asm/msr.h>
-#include <asm/kvm_para.h>
+
#include "mtrr.h"
-u32 num_var_ranges = 0;
+u32 num_var_ranges;
unsigned int mtrr_usage_table[MTRR_MAX_VAR_RANGES];
static DEFINE_MUTEX(mtrr_mutex);
u64 size_or_mask, size_and_mask;
-static struct mtrr_ops * mtrr_ops[X86_VENDOR_NUM] = {};
+static struct mtrr_ops *mtrr_ops[X86_VENDOR_NUM];
-struct mtrr_ops * mtrr_if = NULL;
+struct mtrr_ops *mtrr_if;
static void set_mtrr(unsigned int reg, unsigned long base,
unsigned long size, mtrr_type type);
-void set_mtrr_ops(struct mtrr_ops * ops)
+void set_mtrr_ops(struct mtrr_ops *ops)
{
if (ops->vendor && ops->vendor < X86_VENDOR_NUM)
mtrr_ops[ops->vendor] = ops;
@@ -72,30 +77,36 @@ static int have_wrcomb(void)
{
struct pci_dev *dev;
u8 rev;
-
- if ((dev = pci_get_class(PCI_CLASS_BRIDGE_HOST << 8, NULL)) != NULL) {
- /* ServerWorks LE chipsets < rev 6 have problems with write-combining
- Don't allow it and leave room for other chipsets to be tagged */
+
+ dev = pci_get_class(PCI_CLASS_BRIDGE_HOST << 8, NULL);
+ if (dev != NULL) {
+ /*
+ * ServerWorks LE chipsets < rev 6 have problems with
+ * write-combining. Don't allow it and leave room for other
+ * chipsets to be tagged
+ */
if (dev->vendor == PCI_VENDOR_ID_SERVERWORKS &&
dev->device == PCI_DEVICE_ID_SERVERWORKS_LE) {
pci_read_config_byte(dev, PCI_CLASS_REVISION, &rev);
if (rev <= 5) {
- printk(KERN_INFO "mtrr: Serverworks LE rev < 6 detected. Write-combining disabled.\n");
+ pr_info("mtrr: Serverworks LE rev < 6 detected. Write-combining disabled.\n");
pci_dev_put(dev);
return 0;
}
}
- /* Intel 450NX errata # 23. Non ascending cacheline evictions to
- write combining memory may resulting in data corruption */
+ /*
+ * Intel 450NX errata # 23. Non ascending cacheline evictions to
+ * write combining memory may resulting in data corruption
+ */
if (dev->vendor == PCI_VENDOR_ID_INTEL &&
dev->device == PCI_DEVICE_ID_INTEL_82451NX) {
- printk(KERN_INFO "mtrr: Intel 450NX MMC detected. Write-combining disabled.\n");
+ pr_info("mtrr: Intel 450NX MMC detected. Write-combining disabled.\n");
pci_dev_put(dev);
return 0;
}
pci_dev_put(dev);
- }
- return (mtrr_if->have_wrcomb ? mtrr_if->have_wrcomb() : 0);
+ }
+ return mtrr_if->have_wrcomb ? mtrr_if->have_wrcomb() : 0;
}
/* This function returns the number of variable MTRRs */
@@ -103,12 +114,13 @@ static void __init set_num_var_ranges(void)
{
unsigned long config = 0, dummy;
- if (use_intel()) {
+ if (use_intel())
rdmsr(MSR_MTRRcap, config, dummy);
- } else if (is_cpu(AMD))
+ else if (is_cpu(AMD))
config = 2;
else if (is_cpu(CYRIX) || is_cpu(CENTAUR))
config = 8;
+
num_var_ranges = config & 0xff;
}
@@ -130,10 +142,12 @@ struct set_mtrr_data {
mtrr_type smp_type;
};
+/**
+ * ipi_handler - Synchronisation handler. Executed by "other" CPUs.
+ *
+ * Returns nothing.
+ */
static void ipi_handler(void *info)
-/* [SUMMARY] Synchronisation handler. Executed by "other" CPUs.
- [RETURNS] Nothing.
-*/
{
#ifdef CONFIG_SMP
struct set_mtrr_data *data = info;
@@ -142,18 +156,19 @@ static void ipi_handler(void *info)
local_irq_save(flags);
atomic_dec(&data->count);
- while(!atomic_read(&data->gate))
+ while (!atomic_read(&data->gate))
cpu_relax();
/* The master has cleared me to execute */
- if (data->smp_reg != ~0U)
- mtrr_if->set(data->smp_reg, data->smp_base,
+ if (data->smp_reg != ~0U) {
+ mtrr_if->set(data->smp_reg, data->smp_base,
data->smp_size, data->smp_type);
- else
+ } else {
mtrr_if->set_all();
+ }
atomic_dec(&data->count);
- while(atomic_read(&data->gate))
+ while (atomic_read(&data->gate))
cpu_relax();
atomic_dec(&data->count);
@@ -161,7 +176,8 @@ static void ipi_handler(void *info)
#endif
}
-static inline int types_compatible(mtrr_type type1, mtrr_type type2) {
+static inline int types_compatible(mtrr_type type1, mtrr_type type2)
+{
return type1 == MTRR_TYPE_UNCACHABLE ||
type2 == MTRR_TYPE_UNCACHABLE ||
(type1 == MTRR_TYPE_WRTHROUGH && type2 == MTRR_TYPE_WRBACK) ||
@@ -176,10 +192,10 @@ static inline int types_compatible(mtrr_type type1, mtrr_type type2) {
* @type: mtrr type
*
* This is kinda tricky, but fortunately, Intel spelled it out for us cleanly:
- *
+ *
* 1. Send IPI to do the following:
* 2. Disable Interrupts
- * 3. Wait for all procs to do so
+ * 3. Wait for all procs to do so
* 4. Enter no-fill cache mode
* 5. Flush caches
* 6. Clear PGE bit
@@ -189,26 +205,27 @@ static inline int types_compatible(mtrr_type type1, mtrr_type type2) {
* 10. Enable all range registers
* 11. Flush all TLBs and caches again
* 12. Enter normal cache mode and reenable caching
- * 13. Set PGE
+ * 13. Set PGE
* 14. Wait for buddies to catch up
* 15. Enable interrupts.
- *
+ *
* What does that mean for us? Well, first we set data.count to the number
* of CPUs. As each CPU disables interrupts, it'll decrement it once. We wait
* until it hits 0 and proceed. We set the data.gate flag and reset data.count.
- * Meanwhile, they are waiting for that flag to be set. Once it's set, each
- * CPU goes through the transition of updating MTRRs. The CPU vendors may each do it
- * differently, so we call mtrr_if->set() callback and let them take care of it.
- * When they're done, they again decrement data->count and wait for data.gate to
- * be reset.
- * When we finish, we wait for data.count to hit 0 and toggle the data.gate flag.
+ * Meanwhile, they are waiting for that flag to be set. Once it's set, each
+ * CPU goes through the transition of updating MTRRs.
+ * The CPU vendors may each do it differently,
+ * so we call mtrr_if->set() callback and let them take care of it.
+ * When they're done, they again decrement data->count and wait for data.gate
+ * to be reset.
+ * When we finish, we wait for data.count to hit 0 and toggle the data.gate flag
* Everyone then enables interrupts and we all continue on.
*
* Note that the mechanism is the same for UP systems, too; all the SMP stuff
* becomes nops.
*/
-static void set_mtrr(unsigned int reg, unsigned long base,
- unsigned long size, mtrr_type type)
+static void
+set_mtrr(unsigned int reg, unsigned long base, unsigned long size, mtrr_type type)
{
struct set_mtrr_data data;
unsigned long flags;
@@ -218,121 +235,122 @@ static void set_mtrr(unsigned int reg, unsigned long base,
data.smp_size = size;
data.smp_type = type;
atomic_set(&data.count, num_booting_cpus() - 1);
- /* make sure data.count is visible before unleashing other CPUs */
+
+ /* Make sure data.count is visible before unleashing other CPUs */
smp_wmb();
- atomic_set(&data.gate,0);
+ atomic_set(&data.gate, 0);
- /* Start the ball rolling on other CPUs */
+ /* Start the ball rolling on other CPUs */
if (smp_call_function(ipi_handler, &data, 0) != 0)
panic("mtrr: timed out waiting for other CPUs\n");
local_irq_save(flags);
- while(atomic_read(&data.count))
+ while (atomic_read(&data.count))
cpu_relax();
- /* ok, reset count and toggle gate */
+ /* Ok, reset count and toggle gate */
atomic_set(&data.count, num_booting_cpus() - 1);
smp_wmb();
- atomic_set(&data.gate,1);
+ atomic_set(&data.gate, 1);
- /* do our MTRR business */
+ /* Do our MTRR business */
- /* HACK!
+ /*
+ * HACK!
* We use this same function to initialize the mtrrs on boot.
* The state of the boot cpu's mtrrs has been saved, and we want
- * to replicate across all the APs.
+ * to replicate across all the APs.
* If we're doing that @reg is set to something special...
*/
- if (reg != ~0U)
- mtrr_if->set(reg,base,size,type);
+ if (reg != ~0U)
+ mtrr_if->set(reg, base, size, type);
- /* wait for the others */
- while(atomic_read(&data.count))
+ /* Wait for the others */
+ while (atomic_read(&data.count))
cpu_relax();
atomic_set(&data.count, num_booting_cpus() - 1);
smp_wmb();
- atomic_set(&data.gate,0);
+ atomic_set(&data.gate, 0);
/*
* Wait here for everyone to have seen the gate change
* So we're the last ones to touch 'data'
*/
- while(atomic_read(&data.count))
+ while (atomic_read(&data.count))
cpu_relax();
local_irq_restore(flags);
}
/**
- * mtrr_add_page - Add a memory type region
- * @base: Physical base address of region in pages (in units of 4 kB!)
- * @size: Physical size of region in pages (4 kB)
- * @type: Type of MTRR desired
- * @increment: If this is true do usage counting on the region
+ * mtrr_add_page - Add a memory type region
+ * @base: Physical base address of region in pages (in units of 4 kB!)
+ * @size: Physical size of region in pages (4 kB)
+ * @type: Type of MTRR desired
+ * @increment: If this is true do usage counting on the region
*
- * Memory type region registers control the caching on newer Intel and
- * non Intel processors. This function allows drivers to request an
- * MTRR is added. The details and hardware specifics of each processor's
- * implementation are hidden from the caller, but nevertheless the
- * caller should expect to need to provide a power of two size on an
- * equivalent power of two boundary.
+ * Memory type region registers control the caching on newer Intel and
+ * non Intel processors. This function allows drivers to request an
+ * MTRR is added. The details and hardware specifics of each processor's
+ * implementation are hidden from the caller, but nevertheless the
+ * caller should expect to need to provide a power of two size on an
+ * equivalent power of two boundary.
*
- * If the region cannot be added either because all regions are in use
- * or the CPU cannot support it a negative value is returned. On success
- * the register number for this entry is returned, but should be treated
- * as a cookie only.
+ * If the region cannot be added either because all regions are in use
+ * or the CPU cannot support it a negative value is returned. On success
+ * the register number for this entry is returned, but should be treated
+ * as a cookie only.
*
- * On a multiprocessor machine the changes are made to all processors.
- * This is required on x86 by the Intel processors.
+ * On a multiprocessor machine the changes are made to all processors.
+ * This is required on x86 by the Intel processors.
*
- * The available types are
+ * The available types are
*
- * %MTRR_TYPE_UNCACHABLE - No caching
+ * %MTRR_TYPE_UNCACHABLE - No caching
*
- * %MTRR_TYPE_WRBACK - Write data back in bursts whenever
+ * %MTRR_TYPE_WRBACK - Write data back in bursts whenever
*
- * %MTRR_TYPE_WRCOMB - Write data back soon but allow bursts
+ * %MTRR_TYPE_WRCOMB - Write data back soon but allow bursts
*
- * %MTRR_TYPE_WRTHROUGH - Cache reads but not writes
+ * %MTRR_TYPE_WRTHROUGH - Cache reads but not writes
*
- * BUGS: Needs a quiet flag for the cases where drivers do not mind
- * failures and do not wish system log messages to be sent.
+ * BUGS: Needs a quiet flag for the cases where drivers do not mind
+ * failures and do not wish system log messages to be sent.
*/
-
-int mtrr_add_page(unsigned long base, unsigned long size,
+int mtrr_add_page(unsigned long base, unsigned long size,
unsigned int type, bool increment)
{
+ unsigned long lbase, lsize;
int i, replace, error;
mtrr_type ltype;
- unsigned long lbase, lsize;
if (!mtrr_if)
return -ENXIO;
-
- if ((error = mtrr_if->validate_add_page(base,size,type)))
+
+ error = mtrr_if->validate_add_page(base, size, type);
+ if (error)
return error;
if (type >= MTRR_NUM_TYPES) {
- printk(KERN_WARNING "mtrr: type: %u invalid\n", type);
+ pr_warning("mtrr: type: %u invalid\n", type);
return -EINVAL;
}
- /* If the type is WC, check that this processor supports it */
+ /* If the type is WC, check that this processor supports it */
if ((type == MTRR_TYPE_WRCOMB) && !have_wrcomb()) {
- printk(KERN_WARNING
- "mtrr: your processor doesn't support write-combining\n");
+ pr_warning("mtrr: your processor doesn't support write-combining\n");
return -ENOSYS;
}
if (!size) {
- printk(KERN_WARNING "mtrr: zero sized request\n");
+ pr_warning("mtrr: zero sized request\n");
return -EINVAL;
}
if (base & size_or_mask || size & size_or_mask) {
- printk(KERN_WARNING "mtrr: base or size exceeds the MTRR width\n");
+ pr_warning("mtrr: base or size exceeds the MTRR width\n");
return -EINVAL;
}
@@ -341,36 +359,40 @@ int mtrr_add_page(unsigned long base, unsigned long size,
/* No CPU hotplug when we change MTRR entries */
get_online_cpus();
- /* Search for existing MTRR */
+
+ /* Search for existing MTRR */
mutex_lock(&mtrr_mutex);
for (i = 0; i < num_var_ranges; ++i) {
mtrr_if->get(i, &lbase, &lsize, <ype);
- if (!lsize || base > lbase + lsize - 1 || base + size - 1 < lbase)
+ if (!lsize || base > lbase + lsize - 1 ||
+ base + size - 1 < lbase)
continue;
- /* At this point we know there is some kind of overlap/enclosure */
+ /*
+ * At this point we know there is some kind of
+ * overlap/enclosure
+ */
if (base < lbase || base + size - 1 > lbase + lsize - 1) {
- if (base <= lbase && base + size - 1 >= lbase + lsize - 1) {
+ if (base <= lbase &&
+ base + size - 1 >= lbase + lsize - 1) {
/* New region encloses an existing region */
if (type == ltype) {
replace = replace == -1 ? i : -2;
continue;
- }
- else if (types_compatible(type, ltype))
+ } else if (types_compatible(type, ltype))
continue;
}
- printk(KERN_WARNING
- "mtrr: 0x%lx000,0x%lx000 overlaps existing"
- " 0x%lx000,0x%lx000\n", base, size, lbase,
- lsize);
+ pr_warning("mtrr: 0x%lx000,0x%lx000 overlaps existing"
+ " 0x%lx000,0x%lx000\n", base, size, lbase,
+ lsize);
goto out;
}
- /* New region is enclosed by an existing region */
+ /* New region is enclosed by an existing region */
if (ltype != type) {
if (types_compatible(type, ltype))
continue;
- printk (KERN_WARNING "mtrr: type mismatch for %lx000,%lx000 old: %s new: %s\n",
- base, size, mtrr_attrib_to_str(ltype),
- mtrr_attrib_to_str(type));
+ pr_warning("mtrr: type mismatch for %lx000,%lx000 old: %s new: %s\n",
+ base, size, mtrr_attrib_to_str(ltype),
+ mtrr_attrib_to_str(type));
goto out;
}
if (increment)
@@ -378,7 +400,7 @@ int mtrr_add_page(unsigned long base, unsigned long size,
error = i;
goto out;
}
- /* Search for an empty MTRR */
+ /* Search for an empty MTRR */
i = mtrr_if->get_free_region(base, size, replace);
if (i >= 0) {
set_mtrr(i, base, size, type);
@@ -393,8 +415,9 @@ int mtrr_add_page(unsigned long base, unsigned long size,
mtrr_usage_table[replace] = 0;
}
}
- } else
- printk(KERN_INFO "mtrr: no more MTRRs available\n");
+ } else {
+ pr_info("mtrr: no more MTRRs available\n");
+ }
error = i;
out:
mutex_unlock(&mtrr_mutex);
@@ -405,10 +428,8 @@ int mtrr_add_page(unsigned long base, unsigned long size,
static int mtrr_check(unsigned long base, unsigned long size)
{
if ((base & (PAGE_SIZE - 1)) || (size & (PAGE_SIZE - 1))) {
- printk(KERN_WARNING
- "mtrr: size and base must be multiples of 4 kiB\n");
- printk(KERN_DEBUG
- "mtrr: size: 0x%lx base: 0x%lx\n", size, base);
+ pr_warning("mtrr: size and base must be multiples of 4 kiB\n");
+ pr_debug("mtrr: size: 0x%lx base: 0x%lx\n", size, base);
dump_stack();
return -1;
}
@@ -416,66 +437,64 @@ static int mtrr_check(unsigned long base, unsigned long size)
}
/**
- * mtrr_add - Add a memory type region
- * @base: Physical base address of region
- * @size: Physical size of region
- * @type: Type of MTRR desired
- * @increment: If this is true do usage counting on the region
+ * mtrr_add - Add a memory type region
+ * @base: Physical base address of region
+ * @size: Physical size of region
+ * @type: Type of MTRR desired
+ * @increment: If this is true do usage counting on the region
*
- * Memory type region registers control the caching on newer Intel and
- * non Intel processors. This function allows drivers to request an
- * MTRR is added. The details and hardware specifics of each processor's
- * implementation are hidden from the caller, but nevertheless the
- * caller should expect to need to provide a power of two size on an
- * equivalent power of two boundary.
+ * Memory type region registers control the caching on newer Intel and
+ * non Intel processors. This function allows drivers to request an
+ * MTRR is added. The details and hardware specifics of each processor's
+ * implementation are hidden from the caller, but nevertheless the
+ * caller should expect to need to provide a power of two size on an
+ * equivalent power of two boundary.
*
- * If the region cannot be added either because all regions are in use
- * or the CPU cannot support it a negative value is returned. On success
- * the register number for this entry is returned, but should be treated
- * as a cookie only.
+ * If the region cannot be added either because all regions are in use
+ * or the CPU cannot support it a negative value is returned. On success
+ * the register number for this entry is returned, but should be treated
+ * as a cookie only.
*
- * On a multiprocessor machine the changes are made to all processors.
- * This is required on x86 by the Intel processors.
+ * On a multiprocessor machine the changes are made to all processors.
+ * This is required on x86 by the Intel processors.
*
- * The available types are
+ * The available types are
*
- * %MTRR_TYPE_UNCACHABLE - No caching
+ * %MTRR_TYPE_UNCACHABLE - No caching
*
- * %MTRR_TYPE_WRBACK - Write data back in bursts whenever
+ * %MTRR_TYPE_WRBACK - Write data back in bursts whenever
*
- * %MTRR_TYPE_WRCOMB - Write data back soon but allow bursts
+ * %MTRR_TYPE_WRCOMB - Write data back soon but allow bursts
*
- * %MTRR_TYPE_WRTHROUGH - Cache reads but not writes
+ * %MTRR_TYPE_WRTHROUGH - Cache reads but not writes
*
- * BUGS: Needs a quiet flag for the cases where drivers do not mind
- * failures and do not wish system log messages to be sent.
+ * BUGS: Needs a quiet flag for the cases where drivers do not mind
+ * failures and do not wish system log messages to be sent.
*/
-
-int
-mtrr_add(unsigned long base, unsigned long size, unsigned int type,
- bool increment)
+int mtrr_add(unsigned long base, unsigned long size, unsigned int type,
+ bool increment)
{
if (mtrr_check(base, size))
return -EINVAL;
return mtrr_add_page(base >> PAGE_SHIFT, size >> PAGE_SHIFT, type,
increment);
}
+EXPORT_SYMBOL(mtrr_add);
/**
- * mtrr_del_page - delete a memory type region
- * @reg: Register returned by mtrr_add
- * @base: Physical base address
- * @size: Size of region
+ * mtrr_del_page - delete a memory type region
+ * @reg: Register returned by mtrr_add
+ * @base: Physical base address
+ * @size: Size of region
*
- * If register is supplied then base and size are ignored. This is
- * how drivers should call it.
+ * If register is supplied then base and size are ignored. This is
+ * how drivers should call it.
*
- * Releases an MTRR region. If the usage count drops to zero the
- * register is freed and the region returns to default state.
- * On success the register is returned, on failure a negative error
- * code.
+ * Releases an MTRR region. If the usage count drops to zero the
+ * register is freed and the region returns to default state.
+ * On success the register is returned, on failure a negative error
+ * code.
*/
-
int mtrr_del_page(int reg, unsigned long base, unsigned long size)
{
int i, max;
@@ -500,22 +519,22 @@ int mtrr_del_page(int reg, unsigned long base, unsigned long size)
}
}
if (reg < 0) {
- printk(KERN_DEBUG "mtrr: no MTRR for %lx000,%lx000 found\n", base,
- size);
+ pr_debug("mtrr: no MTRR for %lx000,%lx000 found\n",
+ base, size);
goto out;
}
}
if (reg >= max) {
- printk(KERN_WARNING "mtrr: register: %d too big\n", reg);
+ pr_warning("mtrr: register: %d too big\n", reg);
goto out;
}
mtrr_if->get(reg, &lbase, &lsize, <ype);
if (lsize < 1) {
- printk(KERN_WARNING "mtrr: MTRR %d not used\n", reg);
+ pr_warning("mtrr: MTRR %d not used\n", reg);
goto out;
}
if (mtrr_usage_table[reg] < 1) {
- printk(KERN_WARNING "mtrr: reg: %d has count=0\n", reg);
+ pr_warning("mtrr: reg: %d has count=0\n", reg);
goto out;
}
if (--mtrr_usage_table[reg] < 1)
@@ -526,33 +545,31 @@ int mtrr_del_page(int reg, unsigned long base, unsigned long size)
put_online_cpus();
return error;
}
+
/**
- * mtrr_del - delete a memory type region
- * @reg: Register returned by mtrr_add
- * @base: Physical base address
- * @size: Size of region
+ * mtrr_del - delete a memory type region
+ * @reg: Register returned by mtrr_add
+ * @base: Physical base address
+ * @size: Size of region
*
- * If register is supplied then base and size are ignored. This is
- * how drivers should call it.
+ * If register is supplied then base and size are ignored. This is
+ * how drivers should call it.
*
- * Releases an MTRR region. If the usage count drops to zero the
- * register is freed and the region returns to default state.
- * On success the register is returned, on failure a negative error
- * code.
+ * Releases an MTRR region. If the usage count drops to zero the
+ * register is freed and the region returns to default state.
+ * On success the register is returned, on failure a negative error
+ * code.
*/
-
-int
-mtrr_del(int reg, unsigned long base, unsigned long size)
+int mtrr_del(int reg, unsigned long base, unsigned long size)
{
if (mtrr_check(base, size))
return -EINVAL;
return mtrr_del_page(reg, base >> PAGE_SHIFT, size >> PAGE_SHIFT);
}
-
-EXPORT_SYMBOL(mtrr_add);
EXPORT_SYMBOL(mtrr_del);
-/* HACK ALERT!
+/*
+ * HACK ALERT!
* These should be called implicitly, but we can't yet until all the initcall
* stuff is done...
*/
@@ -576,29 +593,28 @@ struct mtrr_value {
static struct mtrr_value mtrr_value[MTRR_MAX_VAR_RANGES];
-static int mtrr_save(struct sys_device * sysdev, pm_message_t state)
+static int mtrr_save(struct sys_device *sysdev, pm_message_t state)
{
int i;
for (i = 0; i < num_var_ranges; i++) {
- mtrr_if->get(i,
- &mtrr_value[i].lbase,
- &mtrr_value[i].lsize,
- &mtrr_value[i].ltype);
+ mtrr_if->get(i, &mtrr_value[i].lbase,
+ &mtrr_value[i].lsize,
+ &mtrr_value[i].ltype);
}
return 0;
}
-static int mtrr_restore(struct sys_device * sysdev)
+static int mtrr_restore(struct sys_device *sysdev)
{
int i;
for (i = 0; i < num_var_ranges; i++) {
- if (mtrr_value[i].lsize)
- set_mtrr(i,
- mtrr_value[i].lbase,
- mtrr_value[i].lsize,
- mtrr_value[i].ltype);
+ if (mtrr_value[i].lsize) {
+ set_mtrr(i, mtrr_value[i].lbase,
+ mtrr_value[i].lsize,
+ mtrr_value[i].ltype);
+ }
}
return 0;
}
@@ -615,26 +631,29 @@ int __initdata changed_by_mtrr_cleanup;
/**
* mtrr_bp_init - initialize mtrrs on the boot CPU
*
- * This needs to be called early; before any of the other CPUs are
+ * This needs to be called early; before any of the other CPUs are
* initialized (i.e. before smp_init()).
- *
+ *
*/
void __init mtrr_bp_init(void)
{
u32 phys_addr;
+
init_ifs();
phys_addr = 32;
if (cpu_has_mtrr) {
mtrr_if = &generic_mtrr_ops;
- size_or_mask = 0xff000000; /* 36 bits */
+ size_or_mask = 0xff000000; /* 36 bits */
size_and_mask = 0x00f00000;
phys_addr = 36;
- /* This is an AMD specific MSR, but we assume(hope?) that
- Intel will implement it to when they extend the address
- bus of the Xeon. */
+ /*
+ * This is an AMD specific MSR, but we assume(hope?) that
+ * Intel will implement it to when they extend the address
+ * bus of the Xeon.
+ */
if (cpuid_eax(0x80000000) >= 0x80000008) {
phys_addr = cpuid_eax(0x80000008) & 0xff;
/* CPUID workaround for Intel 0F33/0F34 CPU */
@@ -649,9 +668,11 @@ void __init mtrr_bp_init(void)
size_and_mask = ~size_or_mask & 0xfffff00000ULL;
} else if (boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR &&
boot_cpu_data.x86 == 6) {
- /* VIA C* family have Intel style MTRRs, but
- don't support PAE */
- size_or_mask = 0xfff00000; /* 32 bits */
+ /*
+ * VIA C* family have Intel style MTRRs,
+ * but don't support PAE
+ */
+ size_or_mask = 0xfff00000; /* 32 bits */
size_and_mask = 0;
phys_addr = 32;
}
@@ -694,7 +715,6 @@ void __init mtrr_bp_init(void)
changed_by_mtrr_cleanup = 1;
mtrr_if->set_all();
}
-
}
}
}
@@ -706,12 +726,17 @@ void mtrr_ap_init(void)
if (!mtrr_if || !use_intel())
return;
/*
- * Ideally we should hold mtrr_mutex here to avoid mtrr entries changed,
- * but this routine will be called in cpu boot time, holding the lock
- * breaks it. This routine is called in two cases: 1.very earily time
- * of software resume, when there absolutely isn't mtrr entry changes;
- * 2.cpu hotadd time. We let mtrr_add/del_page hold cpuhotplug lock to
- * prevent mtrr entry changes
+ * Ideally we should hold mtrr_mutex here to avoid mtrr entries
+ * changed, but this routine will be called in cpu boot time,
+ * holding the lock breaks it.
+ *
+ * This routine is called in two cases:
+ *
+ * 1. very earily time of software resume, when there absolutely
+ * isn't mtrr entry changes;
+ *
+ * 2. cpu hotadd time. We let mtrr_add/del_page hold cpuhotplug
+ * lock to prevent mtrr entry changes
*/
local_irq_save(flags);
@@ -732,19 +757,23 @@ static int __init mtrr_init_finialize(void)
{
if (!mtrr_if)
return 0;
+
if (use_intel()) {
if (!changed_by_mtrr_cleanup)
mtrr_state_warn();
- } else {
- /* The CPUs haven't MTRR and seem to not support SMP. They have
- * specific drivers, we use a tricky method to support
- * suspend/resume for them.
- * TBD: is there any system with such CPU which supports
- * suspend/resume? if no, we should remove the code.
- */
- sysdev_driver_register(&cpu_sysdev_class,
- &mtrr_sysdev_driver);
+ return 0;
}
+
+ /*
+ * The CPU has no MTRR and seems to not support SMP. They have
+ * specific drivers, we use a tricky method to support
+ * suspend/resume for them.
+ *
+ * TBD: is there any system with such CPU which supports
+ * suspend/resume? If no, we should remove the code.
+ */
+ sysdev_driver_register(&cpu_sysdev_class, &mtrr_sysdev_driver);
+
return 0;
}
subsys_initcall(mtrr_init_finialize);
^ permalink raw reply related [flat|nested] 60+ messages in thread
* Re: [tip:x86/cleanups] x86: Clean up mtrr/cleanup.c
2009-07-04 10:07 ` [tip:x86/cleanups] x86: Clean up mtrr/cleanup.c tip-bot for Jaswinder Singh Rajput
@ 2009-07-04 21:12 ` Yinghai Lu
2009-07-05 0:27 ` Ingo Molnar
0 siblings, 1 reply; 60+ messages in thread
From: Yinghai Lu @ 2009-07-04 21:12 UTC (permalink / raw)
To: mingo, hpa, linux-kernel, yinghai, jaswinder, alan,
jaswinderrajput, akpm, tglx, mingo
Cc: linux-tip-commits
tip-bot for Jaswinder Singh Rajput wrote:
> Commit-ID: 63f9600fadb10ea739108ae93e3e842d9843c58b
> Gitweb: http://git.kernel.org/tip/63f9600fadb10ea739108ae93e3e842d9843c58b
> Author: Jaswinder Singh Rajput <jaswinder@kernel.org>
> AuthorDate: Sat, 4 Jul 2009 07:51:32 +0530
> Committer: Ingo Molnar <mingo@elte.hu>
> CommitDate: Sat, 4 Jul 2009 11:10:46 +0200
>
> x86: Clean up mtrr/cleanup.c
>
> Fix trivial style problems:
>
> WARNING: Use #include <linux/uaccess.h> instead of <asm/uaccess.h>
> WARNING: Use #include <linux/kvm_para.h> instead of <asm/kvm_para.h>
>
> Also, nr_mtrr_spare_reg should be unsigned long.
>
> arch/x86/kernel/cpu/mtrr/cleanup.o:
>
> text data bss dec hex filename
> 6241 8992 2056 17289 4389 cleanup.o.before
> 6241 8992 2056 17289 4389 cleanup.o.after
>
> The md5 has changed:
> 1a7a27513aef1825236daf29110fe657 cleanup.o.before.asm
> bcea358efa2532b6020e338e158447af cleanup.o.after.asm
>
> Because a WARN_ON()'s __LINE__ value changed by 3 lines.
>
> Suggested-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Yinghai Lu <yinghai@kernel.org>
> LKML-Reference: <20090703164225.GA21447@elte.hu>
> [ Did lots of other cleanups to make the code look more consistent. ]
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
>
>
> ---
> arch/x86/kernel/cpu/mtrr/cleanup.c | 350 ++++++++++++++++++------------------
> 1 files changed, 176 insertions(+), 174 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c
> index 1d584a1..b8aba81 100644
> --- a/arch/x86/kernel/cpu/mtrr/cleanup.c
> +++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
> @@ -1,51 +1,52 @@
> -/* MTRR (Memory Type Range Register) cleanup
> -
> - Copyright (C) 2009 Yinghai Lu
> -
> - This library is free software; you can redistribute it and/or
> - modify it under the terms of the GNU Library General Public
> - License as published by the Free Software Foundation; either
> - version 2 of the License, or (at your option) any later version.
> -
> - This library is distributed in the hope that it will be useful,
> - but WITHOUT ANY WARRANTY; without even the implied warranty of
> - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> - Library General Public License for more details.
> -
> - You should have received a copy of the GNU Library General Public
> - License along with this library; if not, write to the Free
> - Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> -*/
> -
> +/*
> + * MTRR (Memory Type Range Register) cleanup
> + *
> + * Copyright (C) 2009 Yinghai Lu
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Library General Public
> + * License as published by the Free Software Foundation; either
> + * version 2 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Library General Public License for more details.
> + *
> + * You should have received a copy of the GNU Library General Public
> + * License along with this library; if not, write to the Free
> + * Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> #include <linux/module.h>
> #include <linux/init.h>
> #include <linux/pci.h>
> #include <linux/smp.h>
> #include <linux/cpu.h>
> -#include <linux/mutex.h>
> #include <linux/sort.h>
> +#include <linux/mutex.h>
> +#include <linux/uaccess.h>
> +#include <linux/kvm_para.h>
>
> +#include <asm/processor.h>
> #include <asm/e820.h>
> #include <asm/mtrr.h>
> -#include <asm/uaccess.h>
> -#include <asm/processor.h>
> #include <asm/msr.h>
> -#include <asm/kvm_para.h>
> +
> #include "mtrr.h"
>
> -/* should be related to MTRR_VAR_RANGES nums */
> +/* Should be related to MTRR_VAR_RANGES nums */
> #define RANGE_NUM 256
>
> struct res_range {
> - unsigned long start;
> - unsigned long end;
> + unsigned long start;
> + unsigned long end;
> };
>
> static int __init
> -add_range(struct res_range *range, int nr_range, unsigned long start,
> - unsigned long end)
> +add_range(struct res_range *range, int nr_range,
> + unsigned long start, unsigned long end)
> {
> - /* out of slots */
> + /* Out of slots: */
> if (nr_range >= RANGE_NUM)
> return nr_range;
>
> @@ -58,12 +59,12 @@ add_range(struct res_range *range, int nr_range, unsigned long start,
> }
>
> static int __init
> -add_range_with_merge(struct res_range *range, int nr_range, unsigned long start,
> - unsigned long end)
> +add_range_with_merge(struct res_range *range, int nr_range,
> + unsigned long start, unsigned long end)
> {
> int i;
>
> - /* try to merge it with old one */
> + /* Try to merge it with old one: */
> for (i = 0; i < nr_range; i++) {
> unsigned long final_start, final_end;
> unsigned long common_start, common_end;
> @@ -84,7 +85,7 @@ add_range_with_merge(struct res_range *range, int nr_range, unsigned long start,
> return nr_range;
> }
>
> - /* need to add that */
> + /* Need to add it: */
> return add_range(range, nr_range, start, end);
> }
>
> @@ -117,7 +118,7 @@ subtract_range(struct res_range *range, unsigned long start, unsigned long end)
> }
>
> if (start > range[j].start && end < range[j].end) {
> - /* find the new spare */
> + /* Find the new spare: */
> for (i = 0; i < RANGE_NUM; i++) {
> if (range[i].end == 0)
> break;
> @@ -147,13 +148,19 @@ static int __init cmp_range(const void *x1, const void *x2)
> }
>
> struct var_mtrr_range_state {
> - unsigned long base_pfn;
> - unsigned long size_pfn;
> - mtrr_type type;
> + unsigned long base_pfn;
> + unsigned long size_pfn;
> + mtrr_type type;
> };
>
> static struct var_mtrr_range_state __initdata range_state[RANGE_NUM];
> +
> static int __initdata debug_print;
> +#define Dprintk(x...) do { if (debug_print) printk(KERN_DEBUG x); } while (0)
> +
> +
two blank lines?
> +#define BIOS_BUG_MSG KERN_WARNING \
> + "WARNING: BIOS bug: VAR MTRR %d contains strange UC entry under 1M, check with your system vendor!\n"
No user for this
YH
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [tip:x86/cleanups] x86: Clean up mtrr/cleanup.c
2009-07-04 21:12 ` Yinghai Lu
@ 2009-07-05 0:27 ` Ingo Molnar
2009-07-05 6:02 ` Jaswinder Singh Rajput
0 siblings, 1 reply; 60+ messages in thread
From: Ingo Molnar @ 2009-07-05 0:27 UTC (permalink / raw)
To: Yinghai Lu
Cc: mingo, hpa, linux-kernel, jaswinder, alan, jaswinderrajput, akpm,
tglx, linux-tip-commits
* Yinghai Lu <yinghai@kernel.org> wrote:
> > static struct var_mtrr_range_state __initdata range_state[RANGE_NUM];
> > +
> > static int __initdata debug_print;
> > +#define Dprintk(x...) do { if (debug_print) printk(KERN_DEBUG x); } while (0)
> > +
> > +
>
> two blank lines?
ah, yes - i moved them around.
> > +#define BIOS_BUG_MSG KERN_WARNING \
> > + "WARNING: BIOS bug: VAR MTRR %d contains strange UC entry under 1M, check with your system vendor!\n"
>
> No user for this
yeah. Mind sending a patch for these? (and any other things you
might notice)
Ingo
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [tip:x86/cleanups] x86: Clean up mtrr/cleanup.c
2009-07-05 0:27 ` Ingo Molnar
@ 2009-07-05 6:02 ` Jaswinder Singh Rajput
2009-07-05 11:59 ` Pekka Enberg
2009-07-05 18:04 ` Ingo Molnar
0 siblings, 2 replies; 60+ messages in thread
From: Jaswinder Singh Rajput @ 2009-07-05 6:02 UTC (permalink / raw)
To: Ingo Molnar
Cc: Yinghai Lu, mingo, hpa, linux-kernel, alan, jaswinderrajput, akpm,
tglx, linux-tip-commits
On Sun, 2009-07-05 at 02:27 +0200, Ingo Molnar wrote:
> * Yinghai Lu <yinghai@kernel.org> wrote:
>
> > > static struct var_mtrr_range_state __initdata range_state[RANGE_NUM];
> > > +
> > > static int __initdata debug_print;
> > > +#define Dprintk(x...) do { if (debug_print) printk(KERN_DEBUG x); } while (0)
> > > +
> > > +
> >
> > two blank lines?
>
> ah, yes - i moved them around.
>
> > > +#define BIOS_BUG_MSG KERN_WARNING \
> > > + "WARNING: BIOS bug: VAR MTRR %d contains strange UC entry under 1M, check with your system vendor!\n"
> >
> > No user for this
>
> yeah. Mind sending a patch for these? (and any other things you
> might notice)
>
But why you did this stupidity.
I clearly specified that these are trivial clean-ups, if you found any
issue in the patch you should ping me. Instead of adding crap from your
side.
Thanks,
--
JSR
^ permalink raw reply [flat|nested] 60+ messages in thread
* [tip:x86/cleanups] x86: Further clean up of mtrr/generic.c
2009-07-03 16:42 ` Ingo Molnar
` (10 preceding siblings ...)
2009-07-04 10:08 ` [tip:x86/cleanups] x86: Clean up mtrr/main.c tip-bot for Jaswinder Singh Rajput
@ 2009-07-05 7:57 ` tip-bot for Ingo Molnar
11 siblings, 0 replies; 60+ messages in thread
From: tip-bot for Ingo Molnar @ 2009-07-05 7:57 UTC (permalink / raw)
To: linux-tip-commits; +Cc: linux-kernel, hpa, mingo, yinghai, tglx, mingo
Commit-ID: e3d0e69268dffb9676bf0800a60fb3573a723480
Gitweb: http://git.kernel.org/tip/e3d0e69268dffb9676bf0800a60fb3573a723480
Author: Ingo Molnar <mingo@elte.hu>
AuthorDate: Sun, 5 Jul 2009 09:44:11 +0200
Committer: Ingo Molnar <mingo@elte.hu>
CommitDate: Sun, 5 Jul 2009 09:46:10 +0200
x86: Further clean up of mtrr/generic.c
Yinghai noticed that i defined BIOS_BUG_MSG but added no
usage for it. The usage is to clean up this turd in generic.c:
printk(KERN_WARNING "WARNING: BIOS bug: VAR MTRR %d "
"contains strange UC entry under 1M, check "
"with your system vendor!\n", i);
Breaking printk lines in the middle looks ugly, is hard to read
and breaks 'git grep'. Use the BIOS_BUG_MSG instead.
Also complete the moving of structure definitions and variables
to the top of the file.
Reported-by: Yinghai Lu <yinghai@kernel.org>
LKML-Reference: <20090703164225.GA21447@elte.hu>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/cpu/mtrr/cleanup.c | 56 +++++++++++++++++------------------
1 files changed, 27 insertions(+), 29 deletions(-)
diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c
index b8aba81..315738c 100644
--- a/arch/x86/kernel/cpu/mtrr/cleanup.c
+++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
@@ -34,14 +34,37 @@
#include "mtrr.h"
-/* Should be related to MTRR_VAR_RANGES nums */
-#define RANGE_NUM 256
-
struct res_range {
unsigned long start;
unsigned long end;
};
+struct var_mtrr_range_state {
+ unsigned long base_pfn;
+ unsigned long size_pfn;
+ mtrr_type type;
+};
+
+struct var_mtrr_state {
+ unsigned long range_startk;
+ unsigned long range_sizek;
+ unsigned long chunk_sizek;
+ unsigned long gran_sizek;
+ unsigned int reg;
+};
+
+/* Should be related to MTRR_VAR_RANGES nums */
+#define RANGE_NUM 256
+
+static struct res_range __initdata range[RANGE_NUM];
+static int __initdata nr_range;
+
+static struct var_mtrr_range_state __initdata range_state[RANGE_NUM];
+
+static int __initdata debug_print;
+#define Dprintk(x...) do { if (debug_print) printk(KERN_DEBUG x); } while (0)
+
+
static int __init
add_range(struct res_range *range, int nr_range,
unsigned long start, unsigned long end)
@@ -147,18 +170,6 @@ static int __init cmp_range(const void *x1, const void *x2)
return start1 - start2;
}
-struct var_mtrr_range_state {
- unsigned long base_pfn;
- unsigned long size_pfn;
- mtrr_type type;
-};
-
-static struct var_mtrr_range_state __initdata range_state[RANGE_NUM];
-
-static int __initdata debug_print;
-#define Dprintk(x...) do { if (debug_print) printk(KERN_DEBUG x); } while (0)
-
-
#define BIOS_BUG_MSG KERN_WARNING \
"WARNING: BIOS bug: VAR MTRR %d contains strange UC entry under 1M, check with your system vendor!\n"
@@ -200,9 +211,7 @@ x86_get_mtrr_mem_range(struct res_range *range, int nr_range,
if (base < (1<<(20-PAGE_SHIFT)) && mtrr_state.have_fixed &&
(mtrr_state.enabled & 1)) {
/* Var MTRR contains UC entry below 1M? Skip it: */
- printk(KERN_WARNING "WARNING: BIOS bug: VAR MTRR %d "
- "contains strange UC entry under 1M, check "
- "with your system vendor!\n", i);
+ printk(BIOS_BUG_MSG, i);
if (base + size <= (1<<(20-PAGE_SHIFT)))
continue;
size -= (1<<(20-PAGE_SHIFT)) - base;
@@ -244,9 +253,6 @@ x86_get_mtrr_mem_range(struct res_range *range, int nr_range,
return nr_range;
}
-static struct res_range __initdata range[RANGE_NUM];
-static int __initdata nr_range;
-
#ifdef CONFIG_MTRR_SANITIZER
static unsigned long __init sum_ranges(struct res_range *range, int nr_range)
@@ -284,14 +290,6 @@ static int __init mtrr_cleanup_debug_setup(char *str)
}
early_param("mtrr_cleanup_debug", mtrr_cleanup_debug_setup);
-struct var_mtrr_state {
- unsigned long range_startk;
- unsigned long range_sizek;
- unsigned long chunk_sizek;
- unsigned long gran_sizek;
- unsigned int reg;
-};
-
static void __init
set_var_mtrr(unsigned int reg, unsigned long basek, unsigned long sizek,
unsigned char type, unsigned int address_bits)
^ permalink raw reply related [flat|nested] 60+ messages in thread
* Re: [tip:x86/cleanups] x86: Clean up mtrr/cleanup.c
2009-07-05 6:02 ` Jaswinder Singh Rajput
@ 2009-07-05 11:59 ` Pekka Enberg
2009-07-05 13:19 ` Jaswinder Singh Rajput
2009-07-05 18:04 ` Ingo Molnar
1 sibling, 1 reply; 60+ messages in thread
From: Pekka Enberg @ 2009-07-05 11:59 UTC (permalink / raw)
To: Jaswinder Singh Rajput
Cc: Ingo Molnar, Yinghai Lu, mingo, hpa, linux-kernel, alan,
jaswinderrajput, akpm, tglx, linux-tip-commits
Hi Jaswinder,
On Sun, Jul 5, 2009 at 9:02 AM, Jaswinder Singh
Rajput<jaswinder@kernel.org> wrote:
> On Sun, 2009-07-05 at 02:27 +0200, Ingo Molnar wrote:
>> * Yinghai Lu <yinghai@kernel.org> wrote:
>>
>> > > static struct var_mtrr_range_state __initdata range_state[RANGE_NUM];
>> > > +
>> > > static int __initdata debug_print;
>> > > +#define Dprintk(x...) do { if (debug_print) printk(KERN_DEBUG x); } while (0)
>> > > +
>> > > +
>> >
>> > two blank lines?
>>
>> ah, yes - i moved them around.
>>
>> > > +#define BIOS_BUG_MSG KERN_WARNING \
>> > > + "WARNING: BIOS bug: VAR MTRR %d contains strange UC entry under 1M, check with your system vendor!\n"
>> >
>> > No user for this
>>
>> yeah. Mind sending a patch for these? (and any other things you
>> might notice)
>>
>
> But why you did this stupidity.
>
> I clearly specified that these are trivial clean-ups, if you found any
> issue in the patch you should ping me. Instead of adding crap from your
> side.
What's with the attitude? It's perfectly okay for a commiter to change
the patch as long as it's mentioned in the changelog. And that's
usually much faster to do that for minor issues rather than ping the
original submitter and wait for a resend.
Pekka
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [tip:x86/cleanups] x86: Clean up mtrr/cleanup.c
2009-07-05 11:59 ` Pekka Enberg
@ 2009-07-05 13:19 ` Jaswinder Singh Rajput
2009-07-05 20:11 ` Thomas Gleixner
0 siblings, 1 reply; 60+ messages in thread
From: Jaswinder Singh Rajput @ 2009-07-05 13:19 UTC (permalink / raw)
To: Pekka Enberg
Cc: Ingo Molnar, Yinghai Lu, mingo, hpa, linux-kernel, alan,
jaswinderrajput, akpm, tglx, linux-tip-commits
Hello Pekka,
On Sun, 2009-07-05 at 14:59 +0300, Pekka Enberg wrote:
> Hi Jaswinder,
>
> On Sun, Jul 5, 2009 at 9:02 AM, Jaswinder Singh
> Rajput<jaswinder@kernel.org> wrote:
> > On Sun, 2009-07-05 at 02:27 +0200, Ingo Molnar wrote:
> >> * Yinghai Lu <yinghai@kernel.org> wrote:
> >>
> >> > > static struct var_mtrr_range_state __initdata range_state[RANGE_NUM];
> >> > > +
> >> > > static int __initdata debug_print;
> >> > > +#define Dprintk(x...) do { if (debug_print) printk(KERN_DEBUG x); } while (0)
> >> > > +
> >> > > +
> >> >
> >> > two blank lines?
> >>
> >> ah, yes - i moved them around.
> >>
> >> > > +#define BIOS_BUG_MSG KERN_WARNING \
> >> > > + "WARNING: BIOS bug: VAR MTRR %d contains strange UC entry under 1M, check with your system vendor!\n"
> >> >
> >> > No user for this
> >>
> >> yeah. Mind sending a patch for these? (and any other things you
> >> might notice)
> >>
> >
> > But why you did this stupidity.
> >
> > I clearly specified that these are trivial clean-ups, if you found any
> > issue in the patch you should ping me. Instead of adding crap from your
> > side.
>
> What's with the attitude? It's perfectly okay for a commiter to change
> the patch as long as it's mentioned in the changelog. And that's
> usually much faster to do that for minor issues rather than ping the
> original submitter and wait for a resend.
>
I was also thankful to him but then he send me a long email and blamed
me that I wasted his 6 hours to do further cleanup and solve bugs and
other irrelevant things. And told me to not send further patches
otherwise he will ignore it.
He is doing mistakes and blaming others and misusing maintainer-ship.
You still thinks it's perfectly okay.
Thanks,
--
JSR
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [tip:x86/cleanups] x86: Clean up mtrr/cleanup.c
2009-07-05 6:02 ` Jaswinder Singh Rajput
2009-07-05 11:59 ` Pekka Enberg
@ 2009-07-05 18:04 ` Ingo Molnar
1 sibling, 0 replies; 60+ messages in thread
From: Ingo Molnar @ 2009-07-05 18:04 UTC (permalink / raw)
To: Jaswinder Singh Rajput
Cc: Yinghai Lu, mingo, hpa, linux-kernel, alan, jaswinderrajput, akpm,
tglx, linux-tip-commits
* Jaswinder Singh Rajput <jaswinder@kernel.org> wrote:
> On Sun, 2009-07-05 at 02:27 +0200, Ingo Molnar wrote:
> > * Yinghai Lu <yinghai@kernel.org> wrote:
> >
> > > > static struct var_mtrr_range_state __initdata range_state[RANGE_NUM];
> > > > +
> > > > static int __initdata debug_print;
> > > > +#define Dprintk(x...) do { if (debug_print) printk(KERN_DEBUG x); } while (0)
> > > > +
> > > > +
> > >
> > > two blank lines?
> >
> > ah, yes - i moved them around.
> >
> > > > +#define BIOS_BUG_MSG KERN_WARNING \
> > > > + "WARNING: BIOS bug: VAR MTRR %d contains strange UC entry under 1M, check with your system vendor!\n"
> > >
> > > No user for this
> >
> > yeah. Mind sending a patch for these? (and any other things you
> > might notice)
>
> But why you did this stupidity.
Uhm, no. This was an unused define that i made later use of in:
e3d0e69: x86: Further clean up of mtrr/generic.c
Ingo
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [GIT PULL -tip][PATCH 0/9] MTRR fix trivial style patches
2009-07-04 2:18 ` [GIT PULL -tip][PATCH 0/9] MTRR fix trivial style patches Jaswinder Singh Rajput
2009-07-04 2:20 ` [PATCH 1/9 -tip] x86: mtrr/amd.c fix trivial style problems Jaswinder Singh Rajput
@ 2009-07-05 18:21 ` Ingo Molnar
2009-07-05 22:09 ` Jaswinder Singh Rajput
1 sibling, 1 reply; 60+ messages in thread
From: Ingo Molnar @ 2009-07-05 18:21 UTC (permalink / raw)
To: Jaswinder Singh Rajput
Cc: Alan Cox, linux-kernel, Andrew Morton, Yinghai Lu, Pekka Enberg,
Thomas Gleixner, H. Peter Anvin
* Jaswinder Singh Rajput <jaswinder@kernel.org> wrote:
> > I think even the MTRR code (which is indeed one of the few x86
> > places still not fully cleaned up) supports my arguments.
> >
> > Look at the averages:
> >
> > errors lines of code errors/KLOC
> > arch/x86/kernel/cpu/mtrr/amd.c 2 120 16.6
> > arch/x86/kernel/cpu/mtrr/centaur.c 8 225 35.5
> > arch/x86/kernel/cpu/mtrr/cleanup.c 0 1102 0
> > arch/x86/kernel/cpu/mtrr/cyrix.c 10 275 36.3
> > arch/x86/kernel/cpu/mtrr/generic.c 16 730 21.9
> > arch/x86/kernel/cpu/mtrr/if.c 11 428 25.7
> > arch/x86/kernel/cpu/mtrr/main.c 50 751 66.5
> > arch/x86/kernel/cpu/mtrr/state.c 0 83 0
> >
>
> By these trivial mtrr cleanup patches:
> errors
> arch/x86/kernel/cpu/mtrr/amd.c 0
> arch/x86/kernel/cpu/mtrr/centaur.c 0
> arch/x86/kernel/cpu/mtrr/cleanup.c 0
> arch/x86/kernel/cpu/mtrr/cyrix.c 0
> arch/x86/kernel/cpu/mtrr/generic.c 0
> arch/x86/kernel/cpu/mtrr/if.c 0
> arch/x86/kernel/cpu/mtrr/main.c 0
> arch/x86/kernel/cpu/mtrr/state.c 0
>
> The following changes since commit 2137f10fd78ce8540ec4305f4dcd559039444544:
> Ingo Molnar (1):
> Merge branch 'perfcounters/urgent'
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jaswinder/linux-2.6-top.git master
>
> Jaswinder Singh Rajput (9):
> x86: mtrr/amd.c fix trivial style problems
> x86: mtrr/centaur.c fix style problems
> x86: mtrr/cleanup.c fix trivial style problems
> x86: mtrr/cyrix.c fix trivial style problems
> x86: mtrr/generic.c fix style problems
> x86: mtrr/if.c fix trivial style problems
> x86: mtrr/mtrr.h fix trivial style problems
> x86: mtrr/state.c fix trivial style problems
> x86: mtrr/main.c fix style problems
>
> arch/x86/kernel/cpu/mtrr/amd.c | 7 +-
> arch/x86/kernel/cpu/mtrr/centaur.c | 127 +++----------------------
> arch/x86/kernel/cpu/mtrr/cleanup.c | 18 ++--
> arch/x86/kernel/cpu/mtrr/cyrix.c | 30 +++---
> arch/x86/kernel/cpu/mtrr/generic.c | 147 +++++++++++++++-------------
> arch/x86/kernel/cpu/mtrr/if.c | 51 +++++++----
> arch/x86/kernel/cpu/mtrr/main.c | 185 +++++++++++++++++++-----------------
> arch/x86/kernel/cpu/mtrr/mtrr.h | 7 +-
> arch/x86/kernel/cpu/mtrr/state.c | 20 +++--
> 9 files changed, 263 insertions(+), 329 deletions(-)
Jaswinder, i'm going to ignore such pull requests from you in the
future, because your changes are exceedingly painful and you just
dont seem to learn.
This is the Nth incident, and there were a countless number of prior
incidents where i warned you about various classes of avoidable
problems, and you are not showing signs of significant improvements.
To get more specific: in this case too it's the same old problem of
low quality of patches from you again:
- You managed to put _3_ separate bugs into these 'trivial'
cleanups. That is not acceptable. If you cannot make trivial
patches be truly trivial, you should not be doing them really.
- i had to remove/undo/fix some bogus 'fixes' you did in those
patches where you just blindly followed checkpatch instead of
thinking about it for a minute. We dont want checkpatch warriors
- we want people with taste who use it as a tool to keep their
new patches tidy, or who use it as a tool to aid cleanups.
- i had to complete the patches and do all the cleanups you missed
- sometimes on the next time to a change you did. You apparently
only checked checkpatch output - you didnt even look at all the
files for how it all looks like and whether there are other
things in those files that checkpatch missed. You made the files
'checkpatch clean' - but you didnt actually look at whether the
files got cleaned up for good really. You left a half-done
jumbled mess behind you with files that still had inconsistent
looking style in them. Check the deltas of the patches i
committed versus the ones you sent to see the countless cases you
missed. And you cannot even claim to have done the 'trivial'
ones safely - because you did it in a buggy way and because the
final cleanups i did are all trivial too and can be validated.
- i had to double check each commit on the assembly level to prove
that the patches are true cleanups. The new commit logs, size
checks, md5 sums are proof of that due diligence process. You
obviously didnt do any of that - you'd have noticed the bugs you
have put in had you done that.
- i had to edit _all_ your changelogs. Again. You _still_ dont
think about your changelogs, they still suck 90% of the time.
All things considered it took me 6 hours to fix up and complete your
'trivial' patches into which you have put only 3 hours of work:
- your buggy and incomplete cleanups did:
9 files changed, 263 insertions(+), 329 deletions(-)
- the proper, fixed, rounded up, checked, validated and working
cleanups i committed with 6 extra hours of work:
9 files changed, 868 insertions(+), 862 deletions(-)
The MTRR code is a highly critical piece of x86 code and i had to
check assembly dumps manually and compared them to make sure the
changes dont introduce subtle regressions.
The fact is, there is no other way to establish the trust level of
trivial cleanups but to invest this depth of review and this level
of testing and checking. I cannot just review until i find the first
bug or problem and bounce it back to you as a review failure - i
cannot know whether i can trust your next version of the patch and i
cannot check the same trivial cleanups again and again as a machine,
until you manage to submit the correct one.
So i've tested the trustworthyness of your changes for a final time
and you failed this test.
I still committed it all under your name because i kept a fair
amount of your changes so it's all v2 versions of your original
patches - and per kernel convention i noted it in the changelog that
i modified it further (and i didnt want to create 9 more commits,
especially as some of your patches were broken so not bisection
safe) - but this was the last time i went through such an effort
with your patches.
As i warned you _repeatedly_ in the past that you should insert a
lot more effort into patches before sending any patches and before
sending any pull request. Other x86 maintainers warned you about
that too. You seem to prefer five patches a day (a few of which are
inevitably broken) instead of one good patch every five days.
This low level of patch quality just does not scale for maintainers
of a busy tree which has more than a hundred contributors in every
cycle. If i cannot trust a contributor i cannot apply such patches
directly.
All in one, you were making the same kinds of mistakes again and
again, over a many month time-span, and you are causing a
considerable amount of maintainer overhead that is just not
sustainable really.
So this simply does not work in this form. I can work with pretty
much anyone, but there's a final limit to the energy i can invest
into this. Please find some other Linux maintainer who can work with
you and who is willing to apply your patches. If you want to work on
x86 bits please find an x86 developer or maintainer who is willing
to apply your patches or who is willing to give you Reviewed-by tags
before sending them to me.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [tip:x86/cleanups] x86: Clean up mtrr/cleanup.c
2009-07-05 13:19 ` Jaswinder Singh Rajput
@ 2009-07-05 20:11 ` Thomas Gleixner
2009-07-05 22:16 ` Jaswinder Singh Rajput
0 siblings, 1 reply; 60+ messages in thread
From: Thomas Gleixner @ 2009-07-05 20:11 UTC (permalink / raw)
To: Jaswinder Singh Rajput
Cc: Pekka Enberg, Ingo Molnar, Yinghai Lu, mingo, hpa, linux-kernel,
alan, jaswinderrajput, akpm, linux-tip-commits
Jaswinder,
On Sun, 5 Jul 2009, Jaswinder Singh Rajput wrote:
> On Sun, 2009-07-05 at 14:59 +0300, Pekka Enberg wrote:
> > What's with the attitude? It's perfectly okay for a commiter to change
> > the patch as long as it's mentioned in the changelog. And that's
> > usually much faster to do that for minor issues rather than ping the
> > original submitter and wait for a resend.
> >
>
> I was also thankful to him but then he send me a long email and blamed
> me that I wasted his 6 hours to do further cleanup and solve bugs and
> other irrelevant things.
Err, you managed to create _three_ bugs in your trivial cleanup
patches and that's not irrelevant at all. That's a sign of sloppiness
and a pretty good reason not to trust any of your patches at all.
> And told me to not send further patches otherwise he will ignore it.
Right, and he is correct about that. This is not the first time and
you have been asked to be more careful with your patches several times
in the last months. It's _you_ who is not listening and not caring at
all.
> He is doing mistakes and blaming others and misusing maintainer-ship.
Ingo did clean up _your_ mess and there was no mistake at all. He
blames _you_ correctly that _your_ trivial patches are buggy.
There is no misuse at all. Ingo is doing what a responsible maintainer
does: reviewing patches and fixing them up when necessary.
His decision not to take any more cleanup patches from you is just the
result of your unwillingness to listen and to react on the requests
which were made to you from Ingo, myself and others.
Thanks,
tglx
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [GIT PULL -tip][PATCH 0/9] MTRR fix trivial style patches
2009-07-05 18:21 ` [GIT PULL -tip][PATCH 0/9] MTRR fix trivial style patches Ingo Molnar
@ 2009-07-05 22:09 ` Jaswinder Singh Rajput
0 siblings, 0 replies; 60+ messages in thread
From: Jaswinder Singh Rajput @ 2009-07-05 22:09 UTC (permalink / raw)
To: Ingo Molnar
Cc: Alan Cox, linux-kernel, Andrew Morton, Yinghai Lu, Pekka Enberg,
Thomas Gleixner, H. Peter Anvin
On Sun, 2009-07-05 at 20:21 +0200, Ingo Molnar wrote:
> * Jaswinder Singh Rajput <jaswinder@kernel.org> wrote:
>
> - You managed to put _3_ separate bugs into these 'trivial'
> cleanups. That is not acceptable. If you cannot make trivial
> patches be truly trivial, you should not be doing them really.
>
Where is the list of _3_ bugs. If there was bugs you should report to
me. If there are bugs show to me, why are you hiding the details.
So it is your mistake.
> - i had to remove/undo/fix some bogus 'fixes' you did in those
> patches where you just blindly followed checkpatch instead of
> thinking about it for a minute. We dont want checkpatch warriors
> - we want people with taste who use it as a tool to keep their
> new patches tidy, or who use it as a tool to aid cleanups.
>
If there was bogus 'fixes', then you should ignore that patch. Or let me
know I will fix that.
So it is your mistake.
> - i had to complete the patches and do all the cleanups you missed
> - sometimes on the next time to a change you did. You apparently
> only checked checkpatch output - you didnt even look at all the
> files for how it all looks like and whether there are other
> things in those files that checkpatch missed. You made the files
> 'checkpatch clean' - but you didnt actually look at whether the
> files got cleaned up for good really. You left a half-done
> jumbled mess behind you with files that still had inconsistent
> looking style in them. Check the deltas of the patches i
> committed versus the ones you sent to see the countless cases you
> missed. And you cannot even claim to have done the 'trivial'
> ones safely - because you did it in a buggy way and because the
> final cleanups i did are all trivial too and can be validated.
>
If you want more cleanup, you should do in separate patch, why you keep
on changing my patch.
This is a never ending task I can do further clean-ups on your patches
also.
So again it is your mistake.
> - i had to double check each commit on the assembly level to prove
> that the patches are true cleanups. The new commit logs, size
> checks, md5 sums are proof of that due diligence process. You
> obviously didnt do any of that - you'd have noticed the bugs you
> have put in had you done that.
>
Why you did this, you never told me to do so.
So again it is your mistake.
> - i had to edit _all_ your changelogs. Again. You _still_ dont
> think about your changelogs, they still suck 90% of the time.
>
Again this is never ending task, even Linus and Andrew can further
change changelog made by you, it is a personnel flavor.
> All things considered it took me 6 hours to fix up and complete your
> 'trivial' patches into which you have put only 3 hours of work:
>
> - your buggy and incomplete cleanups did:
>
> 9 files changed, 263 insertions(+), 329 deletions(-)
>
> - the proper, fixed, rounded up, checked, validated and working
> cleanups i committed with 6 extra hours of work:
>
> 9 files changed, 868 insertions(+), 862 deletions(-)
>
> The MTRR code is a highly critical piece of x86 code and i had to
> check assembly dumps manually and compared them to make sure the
> changes dont introduce subtle regressions.
>
If you want to do it, you should do in separate patches.
It is again your mistake.
> The fact is, there is no other way to establish the trust level of
> trivial cleanups but to invest this depth of review and this level
> of testing and checking. I cannot just review until i find the first
> bug or problem and bounce it back to you as a review failure - i
> cannot know whether i can trust your next version of the patch and i
> cannot check the same trivial cleanups again and again as a machine,
> until you manage to submit the correct one.
>
> So i've tested the trustworthyness of your changes for a final time
> and you failed this test.
>
You never told me to test in this manner.
> I still committed it all under your name because i kept a fair
> amount of your changes so it's all v2 versions of your original
> patches - and per kernel convention i noted it in the changelog that
> i modified it further (and i didnt want to create 9 more commits,
> especially as some of your patches were broken so not bisection
> safe) - but this was the last time i went through such an effort
> with your patches.
>
Why you committed under my name, I do not need your such help if you
again shout at me.
If there was issue then you should ignore my patches and start from
scratch.
This is again your mistake.
> As i warned you _repeatedly_ in the past that you should insert a
> lot more effort into patches before sending any patches and before
> sending any pull request. Other x86 maintainers warned you about
> that too. You seem to prefer five patches a day (a few of which are
> inevitably broken) instead of one good patch every five days.
>
> This low level of patch quality just does not scale for maintainers
> of a busy tree which has more than a hundred contributors in every
> cycle. If i cannot trust a contributor i cannot apply such patches
> directly.
>
> All in one, you were making the same kinds of mistakes again and
> again, over a many month time-span, and you are causing a
> considerable amount of maintainer overhead that is just not
> sustainable really.
>
If I can spend 10-16 hours in a day and no one is paying to me, I am
spending from my pocket. And I send 5 patches in a day.
For you it will not take more than 5-10 minutes to review my 5 patches.
This is your job, and your are getting salary for it.
You should be thankful to me instead of blaming me.
So again it is your fault.
> So this simply does not work in this form. I can work with pretty
> much anyone, but there's a final limit to the energy i can invest
> into this. Please find some other Linux maintainer who can work with
> you and who is willing to apply your patches. If you want to work on
> x86 bits please find an x86 developer or maintainer who is willing
> to apply your patches or who is willing to give you Reviewed-by tags
> before sending them to me.
>
So you are blaming me for your faults.
I am contributing to open-source from my pocket, because I thought that
open-source people are open-heart (big heart), but now it seems I was
wrong. You are having very little heart and very low tolerance.
Thanks,
--
JSR
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [tip:x86/cleanups] x86: Clean up mtrr/cleanup.c
2009-07-05 20:11 ` Thomas Gleixner
@ 2009-07-05 22:16 ` Jaswinder Singh Rajput
0 siblings, 0 replies; 60+ messages in thread
From: Jaswinder Singh Rajput @ 2009-07-05 22:16 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Pekka Enberg, Ingo Molnar, Yinghai Lu, mingo, hpa, linux-kernel,
alan, jaswinderrajput, akpm, linux-tip-commits
On Sun, 2009-07-05 at 22:11 +0200, Thomas Gleixner wrote:
> Jaswinder,
>
> On Sun, 5 Jul 2009, Jaswinder Singh Rajput wrote:
> > On Sun, 2009-07-05 at 14:59 +0300, Pekka Enberg wrote:
> > > What's with the attitude? It's perfectly okay for a commiter to change
> > > the patch as long as it's mentioned in the changelog. And that's
> > > usually much faster to do that for minor issues rather than ping the
> > > original submitter and wait for a resend.
> > >
> >
> > I was also thankful to him but then he send me a long email and blamed
> > me that I wasted his 6 hours to do further cleanup and solve bugs and
> > other irrelevant things.
>
> Err, you managed to create _three_ bugs in your trivial cleanup
> patches and that's not irrelevant at all. That's a sign of sloppiness
> and a pretty good reason not to trust any of your patches at all.
>
> > And told me to not send further patches otherwise he will ignore it.
>
> Right, and he is correct about that. This is not the first time and
> you have been asked to be more careful with your patches several times
> in the last months. It's _you_ who is not listening and not caring at
> all.
>
where is the list of bugs, I do not want to hear blah-blah.
> > He is doing mistakes and blaming others and misusing maintainer-ship.
>
> Ingo did clean up _your_ mess and there was no mistake at all. He
> blames _you_ correctly that _your_ trivial patches are buggy.
>
again blah-blah, where is the bug list.
> There is no misuse at all. Ingo is doing what a responsible maintainer
> does: reviewing patches and fixing them up when necessary.
>
Then he should do his work, no need to blame others.
> His decision not to take any more cleanup patches from you is just the
> result of your unwillingness to listen and to react on the requests
> which were made to you from Ingo, myself and others.
>
I even do not want to do further clean-ups, because it is never ending
task and it is totally personnel flavor.
Thanks,
--
JSR
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-02 11:36 [PATCH] vt: add an event interface Alan Cox
2009-07-03 6:45 ` Ingo Molnar
@ 2009-07-21 16:23 ` Lennart Poettering
2009-07-21 16:32 ` Alan Cox
1 sibling, 1 reply; 60+ messages in thread
From: Lennart Poettering @ 2009-07-21 16:23 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel
On Thu, 02.07.09 12:36, Alan Cox (alan@lxorguk.ukuu.org.uk) wrote:
(Sorry for the long delay in responding, I have been travelling)
> Lennart how does this fit your needs - this replaces the existing wait
> active hack with a race free one and adds other events with a proper
> infrastructure for them.
Sounds good to me. Though tbh, in my eyes the "proper" fix for this
whole problem would be something which would enable userspace to
poll() for VT changes. Having blocking ioctl()s still requires most
userspace applications to spawn a thread for doing that since usually
they are not exclusively waiting for VT events, but also for dbus
requests or some other events.
But OTOH I guess 2 threads are still better than the old situation
requiring processes to run 64 threads for listening for VT changes.
Oh, and one more note: instead of padding the struct it would probably
be more future-proof to simply pass the struct size in addition to the
struct to the ioctl().
Lennart
> From: Alan Cox <alan@linux.intel.com>
>
> This is needed and requested in various forms for ConsoleKit, screenblank
> handling and the like so do the job with a single interface. Also build the
> interface so that unlike VT_WAITACTIVE and friends it won't miss events.
>
> Signed-off-by: Alan Cox <alan@linux.intel.com>
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-21 16:23 ` Lennart Poettering
@ 2009-07-21 16:32 ` Alan Cox
2009-07-22 11:14 ` Lennart Poettering
0 siblings, 1 reply; 60+ messages in thread
From: Alan Cox @ 2009-07-21 16:32 UTC (permalink / raw)
To: Lennart Poettering; +Cc: linux-kernel
> Sounds good to me. Though tbh, in my eyes the "proper" fix for this
> whole problem would be something which would enable userspace to
> poll() for VT changes. Having blocking ioctl()s still requires most
The question there is what device do you poll(). It's easy enough to
magic up a separate vtevent device I guess.
> userspace applications to spawn a thread for doing that since usually
> they are not exclusively waiting for VT events, but also for dbus
> requests or some other events.
>
> But OTOH I guess 2 threads are still better than the old situation
> requiring processes to run 64 threads for listening for VT changes.
>
> Oh, and one more note: instead of padding the struct it would probably
> be more future-proof to simply pass the struct size in addition to the
> struct to the ioctl().
Padding is a lot simpler and less likely to cause bugs later
(typecasting, mischecking of sizes etc). For the kernel I favour
simplicity. A vtevent poll/read interface would be even cleaner so I will
think about that a bit further.
Alan
^ permalink raw reply [flat|nested] 60+ messages in thread
* Re: [PATCH] vt: add an event interface
2009-07-21 16:32 ` Alan Cox
@ 2009-07-22 11:14 ` Lennart Poettering
0 siblings, 0 replies; 60+ messages in thread
From: Lennart Poettering @ 2009-07-22 11:14 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel
On Tue, 21.07.09 17:32, Alan Cox (alan@lxorguk.ukuu.org.uk) wrote:
>
> > Sounds good to me. Though tbh, in my eyes the "proper" fix for this
> > whole problem would be something which would enable userspace to
> > poll() for VT changes. Having blocking ioctl()s still requires most
>
> The question there is what device do you poll(). It's easy enough to
> magic up a separate vtevent device I guess.
Hmm, maybe we could just use the usual console devices and use SIGERR
or SIGURG or something like that to signal those events? And then have
an ioctl() to actually read them?
> > But OTOH I guess 2 threads are still better than the old situation
> > requiring processes to run 64 threads for listening for VT changes.
> >
> > Oh, and one more note: instead of padding the struct it would probably
> > be more future-proof to simply pass the struct size in addition to the
> > struct to the ioctl().
>
> Padding is a lot simpler and less likely to cause bugs later
> (typecasting, mischecking of sizes etc). For the kernel I favour
> simplicity. A vtevent poll/read interface would be even cleaner so I will
> think about that a bit further.
But this isn't a kernel-internal iface, but something exposed to
userspace. Userspace interfaces should be designed cleanly and
future-proof. And padding structs is just painful and unflexible,
since you might end up not reserving enough space for your future
extensions, however until those extensions actually happen you always
pass uneeded memory to the kernel.
But uh, then again, everything's better than the current situation. As
long as we get something that doesn't require 64 threads for watching
VT switches I am happy.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
^ permalink raw reply [flat|nested] 60+ messages in thread
end of thread, other threads:[~2009-07-22 11:15 UTC | newest]
Thread overview: 60+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-02 11:36 [PATCH] vt: add an event interface Alan Cox
2009-07-03 6:45 ` Ingo Molnar
2009-07-03 9:08 ` Alan Cox
2009-07-03 9:16 ` Ingo Molnar
2009-07-03 9:44 ` Alan Cox
2009-07-03 9:54 ` Ingo Molnar
2009-07-03 10:06 ` Alan Cox
2009-07-03 10:22 ` Ingo Molnar
2009-07-03 10:44 ` Alan Cox
2009-07-03 13:17 ` Ingo Molnar
2009-07-03 13:37 ` Alan Cox
2009-07-03 14:47 ` Ingo Molnar
2009-07-03 15:02 ` Alan Cox
2009-07-03 15:42 ` Ingo Molnar
2009-07-03 15:48 ` Ingo Molnar
2009-07-03 16:11 ` Alan Cox
2009-07-03 16:24 ` Ingo Molnar
2009-07-03 18:29 ` Alan Cox
2009-07-03 18:41 ` Ingo Molnar
2009-07-03 15:57 ` Ingo Molnar
2009-07-03 15:58 ` Ingo Molnar
2009-07-03 16:26 ` Alan Cox
2009-07-03 16:33 ` Ingo Molnar
2009-07-03 16:42 ` Ingo Molnar
2009-07-03 22:17 ` Jaswinder Singh Rajput
2009-07-04 2:18 ` [GIT PULL -tip][PATCH 0/9] MTRR fix trivial style patches Jaswinder Singh Rajput
2009-07-04 2:20 ` [PATCH 1/9 -tip] x86: mtrr/amd.c fix trivial style problems Jaswinder Singh Rajput
2009-07-04 2:20 ` [PATCH 2/9 -tip] x86: mtrr/centaur.c fix " Jaswinder Singh Rajput
2009-07-04 2:21 ` [PATCH 3/9 -tip] x86: mtrr/cleanup.c fix trivial " Jaswinder Singh Rajput
2009-07-04 2:22 ` [PATCH 4/9 -tip] x86: mtrr/cyrix.c " Jaswinder Singh Rajput
2009-07-04 2:23 ` [PATCH 5/9 -tip] x86: mtrr/generic.c fix " Jaswinder Singh Rajput
2009-07-04 2:23 ` [PATCH 6/9 -tip] x86: mtrr/if.c fix trivial " Jaswinder Singh Rajput
2009-07-04 2:24 ` [PATCH 7/9 -tip] x86: mtrr/mtrr.h " Jaswinder Singh Rajput
2009-07-04 2:24 ` [PATCH 8/9 -tip] x86: mtrr/state.c " Jaswinder Singh Rajput
2009-07-04 2:26 ` [PATCH 9/9 -tip] x86: mtrr/main.c fix " Jaswinder Singh Rajput
2009-07-05 18:21 ` [GIT PULL -tip][PATCH 0/9] MTRR fix trivial style patches Ingo Molnar
2009-07-05 22:09 ` Jaswinder Singh Rajput
2009-07-04 10:06 ` [tip:x86/cleanups] x86: Clean up mtrr/amd.c: tip-bot for Jaswinder Singh Rajput
2009-07-04 10:06 ` [tip:x86/cleanups] x86: Clean up mtrr/centaur.c tip-bot for Jaswinder Singh Rajput
2009-07-04 10:07 ` [tip:x86/cleanups] x86: Clean up mtrr/cleanup.c tip-bot for Jaswinder Singh Rajput
2009-07-04 21:12 ` Yinghai Lu
2009-07-05 0:27 ` Ingo Molnar
2009-07-05 6:02 ` Jaswinder Singh Rajput
2009-07-05 11:59 ` Pekka Enberg
2009-07-05 13:19 ` Jaswinder Singh Rajput
2009-07-05 20:11 ` Thomas Gleixner
2009-07-05 22:16 ` Jaswinder Singh Rajput
2009-07-05 18:04 ` Ingo Molnar
2009-07-04 10:07 ` [tip:x86/cleanups] x86: Clean up mtrr/cyrix.c tip-bot for Jaswinder Singh Rajput
2009-07-04 10:07 ` [tip:x86/cleanups] x86: Clean up mtrr/generic.c tip-bot for Jaswinder Singh Rajput
2009-07-04 10:07 ` [tip:x86/cleanups] x86: Clean up mtrr/if.c tip-bot for Jaswinder Singh Rajput
2009-07-04 10:07 ` [tip:x86/cleanups] x86: Clean up mtrr/mtrr.h tip-bot for Jaswinder Singh Rajput
2009-07-04 10:08 ` [tip:x86/cleanups] x86: Clean up mtrr/state.c tip-bot for Jaswinder Singh Rajput
2009-07-04 10:08 ` [tip:x86/cleanups] x86: Clean up mtrr/main.c tip-bot for Jaswinder Singh Rajput
2009-07-05 7:57 ` [tip:x86/cleanups] x86: Further clean up of mtrr/generic.c tip-bot for Ingo Molnar
2009-07-03 16:10 ` [PATCH] vt: add an event interface Ingo Molnar
2009-07-03 18:24 ` Alan Cox
2009-07-21 16:23 ` Lennart Poettering
2009-07-21 16:32 ` Alan Cox
2009-07-22 11:14 ` Lennart Poettering
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox