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/.
next prev parent 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