Prev: BUG in drivers/dma/ioat/dma_v2.c:314
Next: [PATCH 3/3] DMAENGINE: add runtime slave config to DMA40
From: Ingo Molnar on 28 Jun 2010 20:20 * Joe Perches <joe(a)perches.com> wrote: > Needed if pr_<level> becomes a bit more space efficient. > > Signed-off-by: Joe Perches <joe(a)perches.com> > --- > arch/x86/kernel/cpu/mtrr/cleanup.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c > index 06130b5..c5f59d0 100644 > --- a/arch/x86/kernel/cpu/mtrr/cleanup.c > +++ b/arch/x86/kernel/cpu/mtrr/cleanup.c > @@ -632,9 +632,9 @@ static void __init mtrr_print_out_one_result(int i) > 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), > + 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); That file and this subsystem needs a lot more cleanups than just this. Would you be willing to do them all, so that we can get over with the churn in a single well-defined patch (or patches)? I dont see much point in piecemail single-comma patches - i'd rather wait for someone else who'd fix this and other details in one go. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Joe Perches on 28 Jun 2010 20:30 On Tue, 2010-06-29 at 02:14 +0200, Ingo Molnar wrote: > That file and this subsystem needs a lot more cleanups than just this. Would > you be willing to do them all, so that we can get over with the churn in a > single well-defined patch (or patches)? > > I dont see much point in piecemail single-comma patches - i'd rather wait for > someone else who'd fix this and other details in one go. I don't see significant style issues in mtrr $ git ls-files arch/x86/kernel/cpu/mtrr/ | \ xargs ./scripts/checkpatch.pl -f What do you think needs improving?git ls-files arch/x86/kernel/cpu/mtrr/ | \ xargs ./scripts/checkpatch.pl -f -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Joe Perches on 29 Jun 2010 15:10 On Tue, 2010-06-29 at 02:14 +0200, Ingo Molnar wrote: > * Joe Perches <joe(a)perches.com> wrote: > > > Needed if pr_<level> becomes a bit more space efficient. > > > > Signed-off-by: Joe Perches <joe(a)perches.com> > > --- > > arch/x86/kernel/cpu/mtrr/cleanup.c | 6 +++--- > > 1 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c > > index 06130b5..c5f59d0 100644 > > --- a/arch/x86/kernel/cpu/mtrr/cleanup.c > > +++ b/arch/x86/kernel/cpu/mtrr/cleanup.c > > @@ -632,9 +632,9 @@ static void __init mtrr_print_out_one_result(int i) > > 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), > > + 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); > > That file and this subsystem needs a lot more cleanups than just this. Would > you be willing to do them all, so that we can get over with the churn in a > single well-defined patch (or patches)? > > I dont see much point in piecemail single-comma patches - i'd rather wait for > someone else who'd fix this and other details in one go. This is the only "," preceeding a pr_<level> printk in the kernel tree. The comma prevents the pr_<level> macro to take the "do { foo } while (0)" form. I don't see significant issues in the code style that need cleanups in arch/x86/kernel/cpu/mtrr. What do you think needs cleaning? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Thomas Gleixner on 14 Jul 2010 18:10 On Wed, 14 Jul 2010, Joe Perches wrote: Sorry, but that's one of the most convoluted changelogs I ever saw. > These are the only "," terminated statements that > precede a pr_<level> in the kernel tree. Errm, why is this related to pr_<level> in any way ? > These must be ";" terminated if the pr_<level> > macros becomes a bit more space efficient using > a "do { foo } while (0)" form. It has absolutely _NOTHING_ to do with any implementation detail of the function/macro which comes after those statements. Terminating a statement with a comma is simply wrong by itself and it needs to be fixed w/o further ado. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Joe Perches on 14 Jul 2010 18:30 On Thu, 2010-07-15 at 00:00 +0200, Thomas Gleixner wrote: > On Wed, 14 Jul 2010, Joe Perches wrote: > that's one of the most convoluted changelogs I ever saw. > > These are the only "," terminated statements that > > precede a pr_<level> in the kernel tree. > Terminating a statement with a comma is simply wrong by itself and it > needs to be fixed w/o further ado. Great. So remove the changelog and just use the subject. I sent a simpler changelog patch last month. http://lkml.org/lkml/2010/6/28/349 Ingo rejected it. He said there were other style problems in the file that needed cleaning. I asked what those style problems were. checkpatch and his "code-quality" script don't show significant issues. No reply from Ingo. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
Pages: 1 Prev: BUG in drivers/dma/ioat/dma_v2.c:314 Next: [PATCH 3/3] DMAENGINE: add runtime slave config to DMA40 |