All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Giuseppe Sacco <giuseppe@eppesuigoccas.homedns.org>,
	linux-mips@linux-mips.org
Subject: Re: [PATCH] enable PCI bridges in MIPS ip32
Date: Thu, 4 Oct 2007 14:03:18 +0100	[thread overview]
Message-ID: <20071004130318.GC28928@linux-mips.org> (raw)
In-Reply-To: <Pine.LNX.4.64N.0710041316000.10573@blysk.ds.pg.gda.pl>

On Thu, Oct 04, 2007 at 01:27:47PM +0100, Maciej W. Rozycki wrote:

> On Thu, 4 Oct 2007, Giuseppe Sacco wrote:
> 
> > I managed to create a patch against current 2.6.23-rc9 git tree
> > for supporting PCI bridges on SGI ip32 machines.
> > This is my first kernel patch, so I am usure about the correct way
> > to send a patch. Please let me know if anything is wrong.
> 
>  I am glad you have succeeded.  A couple of minor notes below.
> 
> > @@ -31,20 +31,21 @@
> >  
> >  #define chkslot(_bus,_devfn)					\
> >  do {							        \
> > -	if ((_bus)->number > 0 || PCI_SLOT (_devfn) < 1	\
> > -	    || PCI_SLOT (_devfn) > 3)			        \
> > +	if ((_bus)->number > 1 ||                               \
> > +		((_bus)->number == 0 && (PCI_SLOT (_devfn) < 1  \
> > +	    	|| PCI_SLOT (_devfn) > 3)))		        \
> >  		return PCIBIOS_DEVICE_NOT_FOUND;		\
> 
>  I think you should allow any bus numbers, not only 0 and 1 -- while 
> possibly unlikely, you may have a tree of bridges on an option card.  The 
> generic code should handle it fine -- you need not care.

I think historically we had something like chkslot() first in the code
for the Galileo/Marvell bridges where it's needed due the brainddead
abuse of device 31 - any access to that will crash the system.  From that
point on chkslot checking spread across the PCI code like the measles in
a kindergarden.

Another stylistic comment is about the return statement in the macro.
That sort of construct should be avoided, it's quite unobvious to the
reader who isn't familiar with the macro definition.

Another thing the historically extremly widespread use of macros in the
Linux kernel.  Macros tend to be harder to read and maintain but
historically gcc was doing a rather bad job at optimizing inline functions
because inlining happend rather late in the compilation process when many
of the optimizations already had been performed.  That is no longer true
for modern gcc so these days functions are prefered.  So adding this all
up:

static inline int chkslot(struct pci_bus *bus, unsigned int devfn)
{
	return bus->number > 1 ||
	       (bus->number == 0 && (PCI_SLOT(devfn) < 1 ||
		PCI_SLOT(devfn) > 3));
}

static inline int mkaddr(struct pci_bus *bus, unsigned int devfn,
	unsigned int reg)
{
	return ((bus->number & 0xff) << 16) |
	       ((devfn & 0xff) << 8) |
	       (reg & 0xfc);
}

static int
mace_pci_read_config(struct pci_bus *bus, unsigned int devfn,
                     int reg, int size, u32 *val)
{
	if (chkslot(bus, devfn)
		return PCIBIOS_DEVICE_NOT_FOUND;

	mace->pci.config_addr = mkaddr(bus, devfn, reg);
[...]

(of course this all goes far beyond Giuseppe's patch - but the whole
ops-mace.c file like so much of the other code in arch/mips/pci isn't
exactly an example to be copied.

Ah, one final formality - when sending a patch please add a
Signed-off-by: line.  See Documentation/SubmittingPatches in the kernel
tree for what this means.

So Giuseppe, I'm happy to apply your patch because it makes sense and
doesn't add new badness.

Cheers,

  Ralf

  parent reply	other threads:[~2007-10-04 13:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-04 10:32 [PATCH] enable PCI bridges in MIPS ip32 Giuseppe Sacco
2007-10-04 12:27 ` Maciej W. Rozycki
2007-10-04 12:50   ` Giuseppe Sacco
2007-10-04 13:03   ` Ralf Baechle [this message]
2007-10-04 14:13     ` Maciej W. Rozycki
2007-10-04 16:55       ` Ralf Baechle
2007-10-05 12:10         ` Maciej W. Rozycki
2007-10-05 12:27       ` Maciej W. Rozycki
2007-10-04 14:33     ` Giuseppe Sacco
2007-10-04 15:03       ` Maciej W. Rozycki
2007-10-04 15:19       ` Ralf Baechle
2007-10-04 15:27         ` Maciej W. Rozycki
2007-10-04 15:32           ` Ralf Baechle
2007-10-05  5:33             ` Giuseppe Sacco
2007-10-05 11:53               ` Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071004130318.GC28928@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=giuseppe@eppesuigoccas.homedns.org \
    --cc=linux-mips@linux-mips.org \
    --cc=macro@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.