From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753658Ab3HQB3g (ORCPT ); Fri, 16 Aug 2013 21:29:36 -0400 Received: from netrider.rowland.org ([192.131.102.5]:46792 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1752019Ab3HQB3f (ORCPT ); Fri, 16 Aug 2013 21:29:35 -0400 Date: Fri, 16 Aug 2013 21:29:34 -0400 (EDT) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Mark Brown cc: Greg Kroah-Hartman , Rob Herring , Pawel Moll , Mark Rutland , Stephen Warren , Ian Campbell , Felipe Balbi , Grant Likely , , , Subject: Re: Non-enumerable devices on USB and other enumerable buses In-Reply-To: <20130816224654.GV30073@sirena.org.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 16 Aug 2013, Mark Brown wrote: > > Besides, you need to get the platform information to the driver in any > > case, no matter how you decide to solve the chicken-and-egg problem. > > It shouldn't be a factor in deciding which solution to use. > > It's not that this is hard, it's that I don't see how if you already > have some concept of the device in the kernel data structures (which you > must have in order to be able to provide platform data when it's needed) > anything is gained by not using that when dealing with bootstrapping > issues. I agree. In fact, there's no choice but to use this device concept during startup. Otherwise there's no way to get the platform data to the driver when it is needed, because there's no way to tell which device the data applies to. The question is how elaborate the concept needs to be and how it gets used. Aong those lines, I would like to point out that the device concept embodied in the kernel's data structures can be pretty thin. For example, it might be little more than a port number or bus address. > Anyway, I think it's time to try to implement something rather than talk > about it. Hopefully this discussion has given you some ideas for alternative approachs, or at least helped to solidify your ideas. Alan Stern From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from netrider.rowland.org ([192.131.102.5]:52723 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751586Ab3HQB3f (ORCPT ); Fri, 16 Aug 2013 21:29:35 -0400 Date: Fri, 16 Aug 2013 21:29:34 -0400 (EDT) From: Alan Stern Subject: Re: Non-enumerable devices on USB and other enumerable buses In-Reply-To: <20130816224654.GV30073@sirena.org.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: devicetree-owner@vger.kernel.org To: Mark Brown Cc: Greg Kroah-Hartman , Rob Herring , Pawel Moll , Mark Rutland , Stephen Warren , Ian Campbell , Felipe Balbi , Grant Likely , devicetree@vger.kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org List-ID: On Fri, 16 Aug 2013, Mark Brown wrote: > > Besides, you need to get the platform information to the driver in any > > case, no matter how you decide to solve the chicken-and-egg problem. > > It shouldn't be a factor in deciding which solution to use. > > It's not that this is hard, it's that I don't see how if you already > have some concept of the device in the kernel data structures (which you > must have in order to be able to provide platform data when it's needed) > anything is gained by not using that when dealing with bootstrapping > issues. I agree. In fact, there's no choice but to use this device concept during startup. Otherwise there's no way to get the platform data to the driver when it is needed, because there's no way to tell which device the data applies to. The question is how elaborate the concept needs to be and how it gets used. Aong those lines, I would like to point out that the device concept embodied in the kernel's data structures can be pretty thin. For example, it might be little more than a port number or bus address. > Anyway, I think it's time to try to implement something rather than talk > about it. Hopefully this discussion has given you some ideas for alternative approachs, or at least helped to solidify your ideas. Alan Stern