Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754904AbYHWBCq (ORCPT ); Fri, 22 Aug 2008 21:02:46 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751977AbYHWBCh (ORCPT ); Fri, 22 Aug 2008 21:02:37 -0400 Received: from yx-out-2324.google.com ([74.125.44.29]:23067 "EHLO yx-out-2324.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751887AbYHWBCh (ORCPT ); Fri, 22 Aug 2008 21:02:37 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=HySRdNTVIS2YyXTkszY6goHXtP5vHcBqXFmW221ZGAdMGhpUee44R+F5gOx0GyR9sh YxCooscZPs9oVqyWKMC05Q2NzAuAUevb/rZcojJ6k+nhANew4yx/6DRPKsHCnJW7fwl5 QOImPHrg3t/ynDCAS83PZxQE4JsRXbIAEJDek= Message-ID: Date: Fri, 22 Aug 2008 21:02:35 -0400 From: "Eric Miao" To: "Jon Smirl" Subject: Re: Fundamental Design Flaw of the Device Driver Model? Cc: LKML In-Reply-To: <9e4733910808220733o7a8904do9dec947dde7d09c0@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9e4733910808220733o7a8904do9dec947dde7d09c0@mail.gmail.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1416 Lines: 29 On Fri, Aug 22, 2008 at 10:33 AM, Jon Smirl wrote: > On 8/22/08, Eric Miao wrote: > ====================================================== >> This, however, creates many questions you have to face with: >> >> 1. on what bus shall these sub-devices be? >> ** this is the reason I choose to use "platform_device", at least they >> can reside on the platform_bus_type, thus platform_driver can be used >> for this sub-device > > Another option is making your own bus. If I understand your hardware > it effectively has an internal bus. > That's another option around, but it didn't solve my fundamental question of, (e.g. an PCI card with multiple network interfaces and other functionality): Why should I have to create an intermediate device provided that a "struct net_device" already contains a "struct device"? And that device-driver binding, parameter passing (platform_data), bus and other functionalities of this "struct net_device" is not used while that's used solely by that intermediate device (platform_device maybe)? They should have perfectly been combined into a single virtual device. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/