Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965631AbbHKQA5 (ORCPT ); Tue, 11 Aug 2015 12:00:57 -0400 Received: from smtp21.mail.ru ([94.100.179.250]:60996 "EHLO smtp21.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965208AbbHKQAa (ORCPT ); Tue, 11 Aug 2015 12:00:30 -0400 Subject: Re: [PATCH 0/2] of: fsl/fman: reuse the fixed node parsing code To: Florian Fainelli , madalin.bucur@freescale.com, netdev@vger.kernel.org, grant.likely@linaro.org, robh+dt@kernel.org References: <1438785745-15517-1-git-send-email-madalin.bucur@freescale.com> <55C63D3B.5020005@gmail.com> Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Igal.Liberman@freescale.com, Stas Sergeev From: Stas Sergeev Message-ID: <55CA1C14.3000202@list.ru> Date: Tue, 11 Aug 2015 19:00:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55C63D3B.5020005@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mras: Ok Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2237 Lines: 46 08.08.2015 20:32, Florian Fainelli пишет: > CC'ing Stas, Hi. > Le 08/05/15 07:42, Madalin Bucur a écrit : >> The FMan MAC configuration code needs the speed and duplex information >> for fixed-link interfaces that is parsed now by the of function >> of_phy_register_fixed_link(). This parses the fixed-link parameters but >> does not expose to the caller neither the phy_device pointer nor the >> status struct where it loads the fixed-link params. I have only barely touched that code, but IMO both things are by design. There are some API deficiencies, and so, many drivers still use of_phy_find_device() to circumvent the encapsulation and get the phy_device pointer, but this is unlikely a good thing to do. I even proposed some API extensions, but there was no interest. >> By extracting the >> fixed-link parsing code from of_phy_register_fixed_link() into a >> separate function the parsed values are made available without changing >> the existing API. This change also removes a small redundancy in the >> previous code calling fixed_phy_register(). Today, the fixed_link is not always fixed. See for example this patch (already mainlined): https://lkml.org/lkml/2015/7/20/711 of_phy_is_fixed_link() returns 'true' if you have managed="in-band-status", and so the SGMII in-band status can update fixed-link params. So my question is: why do you even need to know whether the link is fixed or not? IIRC you can check the phy_device pointer in the adjust_link callback of of_phy_connect() to get the current link status values. Why is this not enough for your task? Maybe the patch description should be updated to include why the current technique is bad, what is actually fixed by the change. I think using the fixed-link DT values directly is not something to be done. The encapsulation is there for a reason, so maybe instead we can see what API additions do we need to avoid the current limitations that force people to use of_phy_find_device() and other work-arounds. -- 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/