All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Pat Gefre <pfg@sgi.com>
Cc: tony.luck@intel.com, linux-kernel@vger.kernel.org,
	linux-ia64@vger.kernel.org
Subject: Re: [PATCH] 2.6 SGI Altix I/O code reorganization
Date: Tue, 5 Oct 2004 16:48:42 +0100	[thread overview]
Message-ID: <20041005164842.A19754@infradead.org> (raw)
In-Reply-To: <200410042157.i94Lv7UC104750@fsgi900.americas.sgi.com>; from pfg@sgi.com on Mon, Oct 04, 2004 at 04:57:06PM -0500

On Mon, Oct 04, 2004 at 04:57:06PM -0500, Pat Gefre wrote:
> 
> We have redone the I/O layer in the Altix code.
> 
> We've broken the patch set down to 2 patches. One to remove the files,
> the other to add in the new code. Most of the changes from the last
> posting are in response to review comments.

This looks pretty nice already, but a few small but important issues
need sorting out.

 - The interface between pci_dma.c and the lowlevel code is still wrong -
   and because of the additional 32bit direct translation in this code drop
   it got even worse because you might be calling into a function just to
   error out again.
   Please implement my suggestions from month ago, it's not a lot of work.
 - various sall baclls take bus_number and devfs but no pci domain, while
   the normal SAL calls do, I think you should make the kernel code aware
   of pci domains so the prom can introduce them seamlessly
 - is doing SAL calls from irq context really safe?  Also why do you need
   different SAL calls for shub vs ice error?  The prom should be easily
   able to find out what hub a given nasid corresponds to.
 - the patch reformats various unrelated or only slightly related files.
   Please don't do that - in general the new style is better than the old
   one, but it doesn't belong in this patchA
 - there's a SNDRV_SHUB_GET_IOCTL_VERSION ioctl define added but never
   used.  In fact it looks like all SNDRV_SHUB_ values are unused now?



WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: Pat Gefre <pfg@sgi.com>
Cc: tony.luck@intel.com, linux-kernel@vger.kernel.org,
	linux-ia64@vger.kernel.org
Subject: Re: [PATCH] 2.6 SGI Altix I/O code reorganization
Date: Tue, 05 Oct 2004 15:48:42 +0000	[thread overview]
Message-ID: <20041005164842.A19754@infradead.org> (raw)
In-Reply-To: <200410042157.i94Lv7UC104750@fsgi900.americas.sgi.com>; from pfg@sgi.com on Mon, Oct 04, 2004 at 04:57:06PM -0500

On Mon, Oct 04, 2004 at 04:57:06PM -0500, Pat Gefre wrote:
> 
> We have redone the I/O layer in the Altix code.
> 
> We've broken the patch set down to 2 patches. One to remove the files,
> the other to add in the new code. Most of the changes from the last
> posting are in response to review comments.

This looks pretty nice already, but a few small but important issues
need sorting out.

 - The interface between pci_dma.c and the lowlevel code is still wrong -
   and because of the additional 32bit direct translation in this code drop
   it got even worse because you might be calling into a function just to
   error out again.
   Please implement my suggestions from month ago, it's not a lot of work.
 - various sall baclls take bus_number and devfs but no pci domain, while
   the normal SAL calls do, I think you should make the kernel code aware
   of pci domains so the prom can introduce them seamlessly
 - is doing SAL calls from irq context really safe?  Also why do you need
   different SAL calls for shub vs ice error?  The prom should be easily
   able to find out what hub a given nasid corresponds to.
 - the patch reformats various unrelated or only slightly related files.
   Please don't do that - in general the new style is better than the old
   one, but it doesn't belong in this patchA
 - there's a SNDRV_SHUB_GET_IOCTL_VERSION ioctl define added but never
   used.  In fact it looks like all SNDRV_SHUB_ values are unused now?



  reply	other threads:[~2004-10-05 15:50 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-04 21:57 [PATCH] 2.6 SGI Altix I/O code reorganization Pat Gefre
2004-10-04 21:57 ` Pat Gefre
2004-10-05 15:48 ` Christoph Hellwig [this message]
2004-10-05 15:48   ` Christoph Hellwig
2004-10-05 18:26   ` Patrick Gefre
2004-10-05 18:26     ` Patrick Gefre
2004-10-05 23:30   ` Patrick Gefre
2004-10-05 23:30     ` Patrick Gefre
2004-10-05 15:50 ` Christoph Hellwig
2004-10-05 15:50   ` Christoph Hellwig
2004-10-05  5:13 Luck, Tony
2004-10-05  5:13 ` Luck, Tony
2004-10-05 15:43 ` Jesse Barnes
2004-10-05 15:43   ` Jesse Barnes
2004-10-05 16:22   ` Grant Grundler
2004-10-05 16:22     ` Grant Grundler
2004-10-05 17:45     ` Matthew Wilcox
2004-10-05 17:45       ` Matthew Wilcox
2004-10-05 19:00       ` Colin Ngam
2004-10-05 19:00         ` Colin Ngam
2004-10-05 19:10       ` Grant Grundler
2004-10-05 19:10         ` Grant Grundler
2004-10-05 19:15         ` Matthew Wilcox
2004-10-05 19:15           ` Matthew Wilcox
2004-10-05 18:20 ` Patrick Gefre
2004-10-05 18:20   ` Patrick Gefre
2004-10-05 18:34   ` Jesse Barnes
2004-10-05 18:34     ` Jesse Barnes
2004-10-05 19:16 Luck, Tony
2004-10-05 19:16 ` Luck, Tony
2004-10-05 19:35 ` Patrick Gefre
2004-10-05 19:35   ` Patrick Gefre
2004-10-05 20:34 Luck, Tony
2004-10-05 20:34 ` Luck, Tony
2004-10-06 15:32 ` Patrick Gefre
2004-10-06 15:32   ` Patrick Gefre
2004-10-06 18:57   ` Grant Grundler
2004-10-06 18:57     ` Grant Grundler
2004-10-06 19:09     ` Colin Ngam
2004-10-06 19:09       ` Colin Ngam
2004-10-06 19:54       ` Grant Grundler
2004-10-06 19:54         ` Grant Grundler
2004-10-06 19:54         ` Colin Ngam
2004-10-06 19:54           ` Colin Ngam
2004-10-06 20:10         ` Patrick Gefre
2004-10-06 20:10           ` Patrick Gefre
2004-10-06 20:44           ` Jesse Barnes
2004-10-06 20:44             ` Jesse Barnes
2004-10-07 15:02             ` Patrick Gefre
2004-10-07 15:02               ` Patrick Gefre
2004-10-07 16:52               ` Jesse Barnes
2004-10-07 16:52                 ` Jesse Barnes
2004-10-06 20:27         ` Jesse Barnes
2004-10-06 20:27           ` Jesse Barnes
2004-10-06 20:21           ` Colin Ngam
2004-10-06 20:21             ` Colin Ngam
2004-10-06 20:33           ` Matthew Wilcox
2004-10-06 20:33             ` Matthew Wilcox
2004-10-06 20:48           ` Grant Grundler
2004-10-06 20:48             ` Grant Grundler
2004-10-06 21:05             ` Matthew Wilcox
2004-10-06 21:05               ` Matthew Wilcox
2004-10-06 20:55               ` Colin Ngam
2004-10-06 20:55                 ` Colin Ngam
2004-10-08 15:16                 ` Colin Ngam
2004-10-08 15:16                   ` Colin Ngam
2004-10-08 16:37                   ` Jesse Barnes
2004-10-08 16:37                     ` Jesse Barnes
2004-10-09 22:20                   ` Grant Grundler
2004-10-09 22:20                     ` Grant Grundler
     [not found]                     ` <4169A508.84FB19C7@sgi.com>
2004-10-11 14:03                       ` Patrick Gefre
2004-10-11 14:03                         ` Patrick Gefre
2004-10-08 22:37                 ` Colin Ngam
2004-10-08 22:37                   ` Colin Ngam
2004-10-07 17:06 Luck, Tony
2004-10-07 17:06 ` Luck, Tony
2004-10-07 17:22 ` Jesse Barnes
2004-10-07 17:22   ` Jesse Barnes
2004-10-07 18:59 ` Jes Sorensen
2004-10-07 18:59   ` Jes Sorensen
2004-10-11 20:49 Luck, Tony
2004-10-11 20:49 ` Luck, Tony

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=20041005164842.A19754@infradead.org \
    --to=hch@infradead.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pfg@sgi.com \
    --cc=tony.luck@intel.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.