From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933918Ab3GWVbn (ORCPT ); Tue, 23 Jul 2013 17:31:43 -0400 Received: from mail-bk0-f44.google.com ([209.85.214.44]:58195 "EHLO mail-bk0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933739Ab3GWVbk (ORCPT ); Tue, 23 Jul 2013 17:31:40 -0400 From: Tomasz Figa To: Alan Stern Cc: Tomasz Figa , Greg KH , Kishon Vijay Abraham I , Laurent Pinchart , broonie@kernel.org, Sylwester Nawrocki , Sascha Hauer , kyungmin.park@samsung.com, balbi@ti.com, jg1.han@samsung.com, s.nawrocki@samsung.com, kgene.kim@samsung.com, grant.likely@linaro.org, tony@atomide.com, arnd@arndb.de, swarren@nvidia.com, devicetree@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-omap@vger.kernel.org, linux-usb@vger.kernel.org, linux-media@vger.kernel.org, linux-fbdev@vger.kernel.org, akpm@linux-foundation.org, balajitk@ti.com, george.cherian@ti.com, nsekhar@ti.com, olof@lixom.net, Stephen Warren , b.zolnierkie@samsung.com, Daniel Lezcano Subject: Re: [PATCH 01/15] drivers: phy: add generic PHY framework Date: Tue, 23 Jul 2013 23:31:31 +0200 Message-ID: <5977067.8rykRgjgre@flatron> User-Agent: KMail/4.10.5 (Linux/3.10.1-gentoo; KDE/4.10.5; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit 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 Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: > 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? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. > > 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. There is no platform data when booting with DT. > 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. Sure. It's good to have different options discussed as well. Best regards, Tomasz From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomasz Figa Date: Tue, 23 Jul 2013 21:31:31 +0000 Subject: Re: [PATCH 01/15] drivers: phy: add generic PHY framework Message-Id: <5977067.8rykRgjgre@flatron> List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-arm-kernel@lists.infradead.org On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: > 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? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. > > 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. There is no platform data when booting with DT. > 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. Sure. It's good to have different options discussed as well. Best regards, Tomasz From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomasz Figa Subject: Re: [PATCH 01/15] drivers: phy: add generic PHY framework Date: Tue, 23 Jul 2013 23:31:31 +0200 Message-ID: <5977067.8rykRgjgre@flatron> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Return-path: In-Reply-To: Sender: linux-doc-owner@vger.kernel.org To: Alan Stern Cc: Tomasz Figa , Greg KH , Kishon Vijay Abraham I , Laurent Pinchart , broonie@kernel.org, Sylwester Nawrocki , Sascha Hauer , kyungmin.park@samsung.com, balbi@ti.com, jg1.han@samsung.com, s.nawrocki@samsung.com, kgene.kim@samsung.com, grant.likely@linaro.org, tony@atomide.com, arnd@arndb.de, swarren@nvidia.com, devicetree@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-omap@vger.kernel.org, linux-usb@vger.kernel.org, linux-media@vger.kernel.org, linux-fbdev@vger.kernel.org, akpm@linux-foundation.org, balajitk@ti.com, george.cherian@ti.com, nsekhar@ti.com, olof@lixom.net, Stephen Warren , b.zol List-Id: linux-omap@vger.kernel.org On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: > 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? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. > > 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. There is no platform data when booting with DT. > 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. Sure. It's good to have different options discussed as well. Best regards, Tomasz From mboxrd@z Thu Jan 1 00:00:00 1970 From: tomasz.figa@gmail.com (Tomasz Figa) Date: Tue, 23 Jul 2013 23:31:31 +0200 Subject: [PATCH 01/15] drivers: phy: add generic PHY framework In-Reply-To: References: Message-ID: <5977067.8rykRgjgre@flatron> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: > 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? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. > > 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. There is no platform data when booting with DT. > 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. Sure. It's good to have different options discussed as well. Best regards, Tomasz