From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stas Sergeev Subject: Re: [PATCH 4/6] of: add API for changing parameters of fixed link Date: Fri, 27 Mar 2015 19:39:45 +0300 Message-ID: <551587D1.5070408@list.ru> References: <55155AFC.4050800@list.ru> <55155D35.1070703@list.ru> <5515803F.3020600@list.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Florian Fainelli Cc: netdev , Linux kernel , Stas Sergeev , Grant Likely , Rob Herring , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Thomas Petazzoni , Andrew Lunn List-Id: devicetree@vger.kernel.org 27.03.2015 19:21, Florian Fainelli =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> Do you want mvneta to register a similar callback in of_mdio, instea= d >> of adding an explicit state-updating functions? Something like >> of_phy_fixed_link_set_update_callback()? > You don't need an of_phy_fixed_link_set_update callback, you just nee= d > to provide a fixed_link_update callback in mvneta, that you register, That approach I in fact considered initially, as the simplest one, and even had a patch. But I disliked the fact that then mvneta will exploit the knowledge of the fact that of_phy_register_fixed_link() uses a fixed_phy driver. What if the implementation will later change? Also what makes me uncomfortable is that since of_phy_register_fixed_li= nk() doesn't even return the struct phy_device pointer, mvneta will have to get around that and use for example of_phy_find_device(), or registe= r the callback later, after of_phy_connect(). dsa/slave.c does of_phy_con= nect() initially, together with fixed link registration, so it gets around the problem. But mvneta registers the fixed_link in .probe callback, and does of_phy_connect() in .open callback. This all made me to drop that idea despite the simplicity. >> This will remove a few changes indeed, but perhaps not too much. >> Please confirm if this is exactly what you want, and then I try. > Let me know if this is clearer now, if not, I can certainly cook a > patch which does what I am suggesting. Thanks! I can do that too, because I already did. Let me know if the above concerns are not important, and I'll restore my initial patch. -- To unsubscribe from this list: send the line "unsubscribe devicetree" i= n the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932194AbbC0QkB (ORCPT ); Fri, 27 Mar 2015 12:40:01 -0400 Received: from smtp22.mail.ru ([94.100.181.177]:57853 "EHLO smtp22.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753568AbbC0Qjz (ORCPT ); Fri, 27 Mar 2015 12:39:55 -0400 Message-ID: <551587D1.5070408@list.ru> Date: Fri, 27 Mar 2015 19:39:45 +0300 From: Stas Sergeev User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Florian Fainelli CC: netdev , Linux kernel , Stas Sergeev , Grant Likely , Rob Herring , "devicetree@vger.kernel.org" , Thomas Petazzoni , Andrew Lunn Subject: Re: [PATCH 4/6] of: add API for changing parameters of fixed link References: <55155AFC.4050800@list.ru> <55155D35.1070703@list.ru> <5515803F.3020600@list.ru> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam: Not detected X-Mras: Ok Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 27.03.2015 19:21, Florian Fainelli пишет: >> Do you want mvneta to register a similar callback in of_mdio, instead >> of adding an explicit state-updating functions? Something like >> of_phy_fixed_link_set_update_callback()? > You don't need an of_phy_fixed_link_set_update callback, you just need > to provide a fixed_link_update callback in mvneta, that you register, That approach I in fact considered initially, as the simplest one, and even had a patch. But I disliked the fact that then mvneta will exploit the knowledge of the fact that of_phy_register_fixed_link() uses a fixed_phy driver. What if the implementation will later change? Also what makes me uncomfortable is that since of_phy_register_fixed_link() doesn't even return the struct phy_device pointer, mvneta will have to get around that and use for example of_phy_find_device(), or register the callback later, after of_phy_connect(). dsa/slave.c does of_phy_connect() initially, together with fixed link registration, so it gets around the problem. But mvneta registers the fixed_link in .probe callback, and does of_phy_connect() in .open callback. This all made me to drop that idea despite the simplicity. >> This will remove a few changes indeed, but perhaps not too much. >> Please confirm if this is exactly what you want, and then I try. > Let me know if this is clearer now, if not, I can certainly cook a > patch which does what I am suggesting. Thanks! I can do that too, because I already did. Let me know if the above concerns are not important, and I'll restore my initial patch.