Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934320Ab3GWVOZ (ORCPT ); Tue, 23 Jul 2013 17:14:25 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:56978 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1758001Ab3GWVOV (ORCPT ); Tue, 23 Jul 2013 17:14:21 -0400 Date: Tue, 23 Jul 2013 17:14:20 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Tomasz Figa cc: Tomasz Figa , Greg KH , Kishon Vijay Abraham I , Laurent Pinchart , , Sylwester Nawrocki , Sascha Hauer , , , , , , , , , , , , , , , , , , , , , , , , Stephen Warren , , Daniel Lezcano Subject: Re: [PATCH 01/15] drivers: phy: add generic PHY framework In-Reply-To: <1388978.Qc6sFy33oS@flatron> 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 Content-Length: 2222 Lines: 55 On Tue, 23 Jul 2013, Tomasz Figa wrote: > > If you want to keep the phy struct completely separate from the board > > file, there's an easy way to do it. Let's say the board file knows > > about N different PHYs in the system. Then you define an array of N > > pointers to phys: > > > > struct phy *(phy_address[N]); > > > > In the platform data for both PHY j and its controller, store > > &phy_address[j]. The PHY provider passes this cookie to phy_create: > > > > cookie = pdev->dev.platform_data; > > ret = phy_create(phy, cookie); > > > > and phy_create simply stores: *cookie = phy. The PHY consumer does > > much the same the same thing: > > > > cookie = pdev->dev.platform_data; > > phy = phy_get(cookie); > > > > phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise. > > OK, this can work. Again, just technically, because it's rather ugly. There's no reason the phy_address things have to be arrays. A separate individual pointer for each PHY would work just as well. > Where would you want to have those phy_address arrays stored? There are no > board files when booting with DT. Not even saying that you don't need to > use any hacky schemes like this when you have DT that nicely specifies > relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? > Anyway, board file should not be considered as a method to exchange data > between drivers. It should be used only to pass data from it to drivers, > not the other way. Ideally all data in a board file should be marked as > const and __init and dropped after system initialization. The phy_address things don't have to be defined or allocated in the board file; they could be set up along with the platform data. In any case, this was simply meant to be a suggestion to show that it is relatively easy to do what you need without using name or ID strings. Alan Stern -- 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/