All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: Roland Dreier <rdreier@cisco.com>
Cc: Mark Maule <maule@sgi.com>,
	Jun'ichi Nomura <j-nomura@ce.jp.nec.com>,
	Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org,
	shaohua.li@intel.com
Subject: Re: [PATCH] (-mm) drivers/pci/msi: explicit declaration of msi_register
Date: Thu, 16 Mar 2006 23:47:05 +0000	[thread overview]
Message-ID: <20060316234705.GA24527@suse.de> (raw)
In-Reply-To: <adalkvaneq5.fsf@cisco.com>

On Thu, Mar 16, 2006 at 03:37:22PM -0800, Roland Dreier wrote:
>     Greg> As msi.c today is pretty platform-specific as is, I don't
>     Greg> have a problem with moving the ia64 stuff also into that
>     Greg> directory.  Especially as it will help solve issues like
>     Greg> this a lot better.
> 
> I think we really want to make drivers/pci/msi.c less
> platform-specific.  Both powerpc and sparc64 are starting to pay
> attention to MSI, so we should really be trying to move things in the
> direction of a clean separation of generic MSI handling and
> Intel-specific bits.

Oh I completely agree.  It's just that the efforts so far to do this has
caused a big #include mess that we are currently in.  And I don't think
that putting pci core structures in the include/linux/ directory is the
correct solution.  If others can come up with cleaner splits of the
code, I incourage it.

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@suse.de>
To: Roland Dreier <rdreier@cisco.com>
Cc: Mark Maule <maule@sgi.com>,
	"Jun'ichi Nomura" <j-nomura@ce.jp.nec.com>,
	Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org,
	shaohua.li@intel.com
Subject: Re: [PATCH] (-mm) drivers/pci/msi: explicit declaration of msi_register
Date: Thu, 16 Mar 2006 15:47:05 -0800	[thread overview]
Message-ID: <20060316234705.GA24527@suse.de> (raw)
In-Reply-To: <adalkvaneq5.fsf@cisco.com>

On Thu, Mar 16, 2006 at 03:37:22PM -0800, Roland Dreier wrote:
>     Greg> As msi.c today is pretty platform-specific as is, I don't
>     Greg> have a problem with moving the ia64 stuff also into that
>     Greg> directory.  Especially as it will help solve issues like
>     Greg> this a lot better.
> 
> I think we really want to make drivers/pci/msi.c less
> platform-specific.  Both powerpc and sparc64 are starting to pay
> attention to MSI, so we should really be trying to move things in the
> direction of a clean separation of generic MSI handling and
> Intel-specific bits.

Oh I completely agree.  It's just that the efforts so far to do this has
caused a big #include mess that we are currently in.  And I don't think
that putting pci core structures in the include/linux/ directory is the
correct solution.  If others can come up with cleaner splits of the
code, I incourage it.

thanks,

greg k-h

  parent reply	other threads:[~2006-03-16 23:47 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-14 21:01 [PATCH] (-mm) drivers/pci/msi: explicit declaration of msi_register Jun'ichi Nomura
2006-03-14 21:01 ` Jun'ichi Nomura
2006-03-14 21:45 ` [PATCH] (-mm) drivers/pci/msi: explicit declaration of Andrew Morton
2006-03-14 21:45   ` [PATCH] (-mm) drivers/pci/msi: explicit declaration of msi_register Andrew Morton
2006-03-14 21:59   ` Greg KH
2006-03-14 21:59     ` Greg KH
2006-03-14 22:25     ` Matthew Wilcox
2006-03-14 22:25       ` Matthew Wilcox
2006-03-15  0:51   ` Jun'ichi Nomura
2006-03-15  0:51     ` Jun'ichi Nomura
2006-03-15 23:55     ` Greg KH
2006-03-15 23:55       ` Greg KH
2006-03-16 15:19       ` Jun'ichi Nomura
2006-03-16 15:19         ` Jun'ichi Nomura
2006-03-16 18:19         ` Mark Maule
2006-03-16 18:19           ` Mark Maule
2006-03-16 19:32           ` Jun'ichi Nomura
2006-03-16 19:32             ` Jun'ichi Nomura
2006-03-16 19:41             ` Mark Maule
2006-03-16 19:41               ` Mark Maule
2006-03-16 23:28               ` Greg KH
2006-03-16 23:28                 ` Greg KH
2006-03-16 23:37                 ` Roland Dreier
2006-03-16 23:37                   ` Roland Dreier
2006-03-16 23:45                   ` Grant Grundler
2006-03-16 23:45                     ` Grant Grundler
2006-03-16 23:47                   ` Greg KH [this message]
2006-03-16 23:47                     ` Greg KH
2006-03-16 23:41           ` Grant Grundler
2006-03-16 23:41             ` Grant Grundler
2006-03-16 23:49             ` Greg KH
2006-03-16 23:49               ` Greg KH
2006-03-17  0:41               ` Grant Grundler
2006-03-17  0:41                 ` Grant Grundler
2006-03-17  1:18                 ` Mark Maule
2006-03-17  1:18                   ` Mark Maule
2006-03-16 15:29       ` Jun'ichi Nomura
2006-03-16 15:29         ` Jun'ichi Nomura
2006-03-14 21:57 ` Adrian Bunk
2006-03-14 21:57   ` Adrian Bunk
2006-03-14 23:55   ` Jun'ichi Nomura
2006-03-14 23:55     ` Jun'ichi Nomura
2006-03-15  0:09     ` Mark Maule
2006-03-15  0:09       ` Mark Maule
2006-03-15  1:04       ` Jun'ichi Nomura
2006-03-15  1:04         ` Jun'ichi Nomura

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=20060316234705.GA24527@suse.de \
    --to=gregkh@suse.de \
    --cc=akpm@osdl.org \
    --cc=j-nomura@ce.jp.nec.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maule@sgi.com \
    --cc=rdreier@cisco.com \
    --cc=shaohua.li@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.