[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090206154231.GN18368@elte.hu>
Date: Fri, 6 Feb 2009 16:42:31 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Tvrtko Ursulin <tvrtko.ursulin@...hos.com>
Cc: Ed Swierk <eswierk@...stanetworks.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>,
"hpa@...or.com" <hpa@...or.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"lenb@...nel.org" <lenb@...nel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"jbarnes@...tuousgeek.org" <jbarnes@...tuousgeek.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
Subject: Re: [PATCH] Detect mmconfig on nVidia MCP55
* Tvrtko Ursulin <tvrtko.ursulin@...hos.com> wrote:
> On Thursday 05 February 2009 18:00:19 Ingo Molnar wrote:
> > * Tvrtko Ursulin <tvrtko.ursulin@...hos.com> wrote:
> > > On Wednesday 04 February 2009 17:04:40 Ingo Molnar wrote:
> > > > 2) Please use vertical spaces when initializing structure fields.
> > > > Instead of the messy looking (and over-long-line generating) construct
> > > > of:
> > > >
> > > > pci_mmcfg_config[0].address = (extcfg & 0x00007fff) << 25;
> > > > pci_mmcfg_config[0].pci_segment = 0;
> > > > pci_mmcfg_config[0].start_bus_number = 0;
> > > > pci_mmcfg_config[0].end_bus_number = (1 << (8 - ((extcfg >> 28)
> > > > & 3))) - 1; pci_mmcfg_config_num = 1;
> > > >
> > > > You will get something like:
> > > >
> > > > config->address = (extcfg & 0x00007fff) << 25;
> > > > config->pci_segment = 0;
> > > > config->start_bus_number = 0;
> > > > config->end_bus_number = (1 << (8 - ((extcfg >> 28) &
> > > > 3)));
> > > >
> > > > pci_mmcfg_config = config;
> > > > pci_mmcfg_config_num = 1;
> > > >
> > > > Which makes it more structured, more reviewable - and more pleasant
> > > > to look at as well.
> >
> > It is arch/x86/ and scheduler / etc. policy for new code - and we follow
> > that principle when we clean up code as well.
>
> You also didn't say anything about variable declarations I asked about?
> And I can add structure definition to that question as well.
Firstly, when posting on lkml please use proper line length breaks. Your
email was almost unreadable in my mailer, so i had to stop reading it.
Also, i'm surprised you see the need to try to influence things here - i
dont see a single upstream contribution from you in the past ~4 years of git
log so how can you have any knowledge and experience about such details?
Both of those issues pretty materially weaken your standing to be taken
seriously when it comes to fine details of Linux kernel coding style.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists