public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Christoph Hellwig <hch@infradead.org>,
	Patrick Gefre <pfg@sgi.com>,
	linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Latest Altix I/O code reorganization code
Date: Fri, 03 Sep 2004 23:40:24 +0000	[thread overview]
Message-ID: <20040904004024.A10459@infradead.org> (raw)
In-Reply-To: <20040827172131.A473@infradead.org>; from hch@infradead.org on Fri, Aug 27, 2004 at 05:21:31PM +0100

Crosscheck of your new code vs the review:

> io_init.c:
> 
>  - sal_get_hubdev_info
> 	umm, you're getting a kernel pointer by a SAL
>  	call.  I wonders how this is supposed to work when the kernel
> 	changes it's VA layout.  (Dito for a bunch of other functions)

Still not explanation

>  - sn_io_init
> 	what's going on here?

gone

> iomv.c:
> 
>  - okay, could use some reformatting to fit 80 chars

ok

> pci_dma.c:
> 
>  - still using all those indirections althoug there's only a single backend

this comment is fixed, but the one later sent in private (stupid choice
of interface beteen upper pci dma code and pcibr code ignored)

> pci_extension.c:
> 
>  - dito.  Why does this single function need a separate file?

Not addressed.  In general your file organization is mess still.

Just do arch/ia64/sn/pci/ for all pci code and move the rest to
arch/ia64/sn/kernel.  That how most arches work.

> pcibr_ate.c:
> 
>  - doesn't look to bad, but should probably merged into pcibr_dma.c.  And
>    the trivial < 10 line function opencoded in their only callers.

Not addressed or commented on yet.

> pcibr_provider.c
> 
>  actual code code looks okay, but:
> 
>   - sal_pcibr_slot_enable/sal_pcibr_slot_disabl are completely unused

you still have typedefs for these around

>   - the pci_provider abstraction is right now completely useless, please
>     add such abstractions only when you need them (and if you'll ever need
>     that a few hints:  stop that casting of methods silliness but use
>     container_of, use C99 initializers, stop the typedef abuse)

ok

>   - request_irq return value needs checking

ok

> 
> pcibr_reg.c:
> 
>  - all this casting is rather horrible.  At least keep a pointer to each
>    of struct tiocp and pic_s (and kill the _s postifx) in syruct pcibus_info.
>    the volatiles looks bogus, if you need it you're missing memorry barries.

the type pointer isn't done.  Any specific reason?

> xtalk_providers.c:
> 
>  - bogus indirection again.  if you actually do have different lowlevel
>    implementations they should be hidden inside the prom.  While at it I think
>    the two calls could just move to arch/ia64/sn/kernel/irq.c

ok

More items:

 - sal_pcibr_rrb_alloc should be merged into its only caller
 - io_init.c still has KDB ifdefs
 - sn_pci_set_vchan should absolutely _not_ be placed in qla1280.c,
   and while you're at it there extern for snia_pcibr_rrb_alloc should
   move to a header
 - kill HUBREG_CAST instead of touching it
 - please don't put your ASSERT into asm/ headers.  In general you
   should use BUG_ON
 - why do you add a pfn_t typedef that's not used anywhere
 - the patch adds include/asm-ia64/sn/xtalk/xtalk_provider.h but there's
   no more xtalk providers

Your headers are still a complete mess.  There's no point exposing tons
of defails about the pci interface in include/asm - just keep and
pci_extensions.h there for non-standard PCI APIs, and the rest should
stay private inisde arch/ia64/sn/pci/.

  reply	other threads:[~2004-09-03 23:40 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-04 20:14 Altix I/O code reorganization Pat Gefre
2004-08-05  0:31 ` Grant Grundler
2004-08-05 18:16 ` Greg KH
2004-08-05 20:51 ` Pat Gefre
2004-08-05 21:08   ` Greg KH
2004-08-05 21:32     ` Jesse Barnes
2004-08-05 21:36       ` Greg KH
2004-08-06 13:18 ` Christoph Hellwig
2004-08-06 16:19   ` Jesse Barnes
2004-08-07 10:58     ` Christoph Hellwig
2004-08-11 23:24   ` Patrick Gefre
2004-08-12  9:15     ` Christoph Hellwig
2004-08-12 14:47       ` Jesse Barnes
2004-08-12 15:21         ` Christoph Hellwig
2004-08-27 15:10     ` Latest Altix I/O code reorganization code Patrick Gefre
2004-08-27 15:14       ` Patrick Gefre
2004-08-27 15:21         ` Christoph Hellwig
2004-08-27 15:35           ` Patrick Gefre
2004-08-27 15:44             ` Christoph Hellwig
2004-08-27 15:23       ` Pat Gefre
2004-08-27 15:36       ` Christoph Hellwig
2004-08-27 15:45       ` Christoph Hellwig
2004-08-27 16:32         ` Patrick Gefre
2004-08-27 15:54       ` Christoph Hellwig
2004-08-27 16:06         ` Patrick Gefre
2004-08-27 16:21         ` Christoph Hellwig
2004-09-03 23:40           ` Christoph Hellwig [this message]
2004-09-07 22:10             ` Patrick Gefre
2004-09-07 22:16               ` Christoph Hellwig
2004-08-27 17:15       ` Christoph Hellwig
2004-08-29  6:39       ` Keith Owens
2004-08-29  7:16         ` Sam Ravnborg
2004-08-29  7:22       ` Keith Owens
2004-08-06 13:51 ` Altix I/O code reorganization Keith Owens
2004-08-06 13:55   ` Christoph Hellwig
2004-08-06 15:47 ` Russ Anderson

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=20040904004024.A10459@infradead.org \
    --to=hch@infradead.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pfg@sgi.com \
    /path/to/YOUR_REPLY

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

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