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/.
WARNING: multiple messages have this Message-ID (diff)
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: Sat, 4 Sep 2004 00:40:24 +0100 [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: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-04 20:14 Altix I/O code reorganization Pat Gefre
2004-08-04 20:14 ` Pat Gefre
2004-08-05 0:31 ` Grant Grundler
2004-08-05 0:31 ` Grant Grundler
2004-08-05 18:16 ` Greg KH
2004-08-05 18:16 ` Greg KH
2004-08-05 20:51 ` Pat Gefre
2004-08-05 20:51 ` Pat Gefre
2004-08-05 21:08 ` Greg KH
2004-08-05 21:08 ` Greg KH
2004-08-05 21:32 ` Jesse Barnes
2004-08-05 21:32 ` Jesse Barnes
2004-08-05 21:36 ` Greg KH
2004-08-05 21:36 ` Greg KH
2004-08-06 13:18 ` Christoph Hellwig
2004-08-06 13:18 ` Christoph Hellwig
2004-08-06 16:19 ` Jesse Barnes
2004-08-06 16:19 ` Jesse Barnes
2004-08-07 10:58 ` Christoph Hellwig
2004-08-07 10:58 ` Christoph Hellwig
2004-08-11 23:24 ` Patrick Gefre
2004-08-11 23:24 ` Patrick Gefre
2004-08-12 9:15 ` Christoph Hellwig
2004-08-12 9:15 ` Christoph Hellwig
2004-08-12 14:47 ` Jesse Barnes
2004-08-12 14:47 ` Jesse Barnes
2004-08-12 15:21 ` Christoph Hellwig
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:10 ` Patrick Gefre
2004-08-27 15:14 ` Patrick Gefre
2004-08-27 15:14 ` Patrick Gefre
2004-08-27 15:21 ` Christoph Hellwig
2004-08-27 15:21 ` Christoph Hellwig
2004-08-27 15:35 ` Patrick Gefre
2004-08-27 15:35 ` Patrick Gefre
2004-08-27 15:44 ` Christoph Hellwig
2004-08-27 15:44 ` Christoph Hellwig
2004-09-03 23:12 ` Latest Altix I/O code rewrite Patrick Gefre
2004-08-27 15:23 ` Latest Altix I/O code reorganization code Pat Gefre
2004-08-27 15:23 ` Pat Gefre
2004-08-27 15:36 ` Christoph Hellwig
2004-08-27 15:36 ` Christoph Hellwig
2004-08-27 15:45 ` Christoph Hellwig
2004-08-27 15:45 ` Christoph Hellwig
2004-08-27 16:32 ` Patrick Gefre
2004-08-27 16:32 ` Patrick Gefre
2004-08-27 15:54 ` Christoph Hellwig
2004-08-27 15:54 ` Christoph Hellwig
2004-08-27 16:06 ` Patrick Gefre
2004-08-27 16:06 ` Patrick Gefre
2004-08-27 16:21 ` Christoph Hellwig
2004-08-27 16:21 ` Christoph Hellwig
2004-09-03 23:40 ` Christoph Hellwig [this message]
2004-09-03 23:40 ` Christoph Hellwig
2004-09-07 22:10 ` Patrick Gefre
2004-09-07 22:10 ` Patrick Gefre
2004-09-07 22:16 ` Christoph Hellwig
2004-09-07 22:16 ` Christoph Hellwig
2004-08-27 17:15 ` Christoph Hellwig
2004-08-27 17:15 ` Christoph Hellwig
2004-08-29 6:39 ` Keith Owens
2004-08-29 6:39 ` Keith Owens
2004-08-29 7:16 ` Sam Ravnborg
2004-08-29 7:16 ` Sam Ravnborg
2004-08-29 7:22 ` Keith Owens
2004-08-29 7:22 ` Keith Owens
2004-08-06 13:51 ` Altix I/O code reorganization Keith Owens
2004-08-06 13:51 ` Keith Owens
2004-08-06 13:55 ` Christoph Hellwig
2004-08-06 13:55 ` Christoph Hellwig
2004-08-06 15:47 ` Russ Anderson
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 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.