public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Greg KH <greg@kroah.com>
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>, Len Brown <len.brown@intel.com>,
	Deepak Saxena <dsaxena@plexity.net>
Subject: Re: [PATCH] Add device addition/removal notifier
Date: Fri, 20 Oct 2006 17:35:06 +1000	[thread overview]
Message-ID: <1161329707.10524.184.camel@localhost.localdomain> (raw)
In-Reply-To: <20061020061618.GA9432@kroah.com>


> Ick, I'd like to say that this is a pretty bad thing to do.  If you need
> that, then just statically link the bus into your code, or make your
> code a module and it will depend on the usb core.  I don't know...
> 
> Remember, we didn't add a type identifier to the struct device for a
> reason, comparing the string of the bus type is not a good idea (for
> USB, it will get you in trouble, because two different types of devices
> can be on that bus, who's to say other busses will not also have that
> issue?)
> 
> I think you need to re-evaluate exactly what you are needing to do
> here...

BTW. You basic saying that one should not test the bus type of a generic
struct device* makes it basically impossible to implement dma_map_* on
platforms that have various bus types with different DMA operations :)

Note that what I'm working on at the moment might make all of that
easier anyway, by having (on powerpc only for now but some of that could
be made generic once I'm finished) dma_ops having off the struct device
(or rather an extension of it).

Oh, also, right now, I re-use the firmware_data pointer there to point
to my struct device_ext, but I'd like to be better typed and avoid too
many pointer dereferences. I'm thus thinking instead of defining an
asm-*/device.h where archs can define their own struct device_ext and
have that flat in struct device (default being an empty struct). We
could even get rid of firmware_data on archs that don't use it by
putting it there :) (Among others).

Ben.



  parent reply	other threads:[~2006-10-20  7:35 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-20  1:55 [PATCH] Add device addition/removal notifier Benjamin Herrenschmidt
2006-10-20  3:26 ` Greg KH
2006-10-20  4:29   ` Benjamin Herrenschmidt
2006-10-20  4:44     ` Greg KH
2006-10-20  5:42       ` Benjamin Herrenschmidt
2006-10-20  6:16         ` Greg KH
2006-10-20  7:19           ` Benjamin Herrenschmidt
2006-10-20  7:35           ` Benjamin Herrenschmidt [this message]
2006-10-20 10:08           ` Paul Mackerras
2006-10-23  4:47           ` [PATCH] Call platform_notify_remove later Benjamin Herrenschmidt
  -- strict thread matches above, loose matches on Subject: below --
2006-10-19  7:56 [PATCH] Add device addition/removal notifier Benjamin Herrenschmidt
2006-10-19 15:55 ` Randy Dunlap
2006-10-20  1:53   ` Benjamin Herrenschmidt

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=1161329707.10524.184.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=akpm@osdl.org \
    --cc=dsaxena@plexity.net \
    --cc=greg@kroah.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    /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