From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 27C58C282C2 for ; Sun, 10 Feb 2019 11:45:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A7B5321773 for ; Sun, 10 Feb 2019 11:45:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=aruba.it header.i=@aruba.it header.b="cacvXQOm" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726157AbfBJLpn (ORCPT ); Sun, 10 Feb 2019 06:45:43 -0500 Received: from smtpcmd0756.aruba.it ([62.149.156.56]:58448 "EHLO smtpcmd0756.aruba.it" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726002AbfBJLpn (ORCPT ); Sun, 10 Feb 2019 06:45:43 -0500 Received: from [192.168.1.39] ([93.146.66.165]) by smtpcmd07.ad.aruba.it with bizsmtp id azlc1z00L3Zw7e501zlcQc; Sun, 10 Feb 2019 12:45:40 +0100 Subject: Re: Possible bug into DSA2 code. To: Andrew Lunn Cc: Florian Fainelli , Vivien Didelot , "David S. Miller" , netdev@vger.kernel.org References: <528f797d-445b-a314-d8ef-db15a3b6a8ce@enneenne.com> <20190209193409.GI30856@lunn.ch> From: Rodolfo Giometti Message-ID: <084b3973-88b9-8c71-50d5-9d773999ad04@enneenne.com> Date: Sun, 10 Feb 2019 12:45:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190209193409.GI30856@lunn.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aruba.it; s=a1; t=1549799140; bh=uLmbO2pxkldO/N5mtiQj4JfOoD2GwvJM60Vi/B7ea68=; h=Subject:To:From:Date:MIME-Version:Content-Type; b=cacvXQOmafQrHwpvAe53xGXfGF1ja+1zF3g/dOSjjmEQtJgxymd73karlBHUSZWuk Xw36zWSDCt2p2XMJ3OGM6I9n0JPNabHYHZSYHkYVh/Uic30bNo0/88E+xeCophZrR+ uwHcUcAmITdonEwWqT44Tu8uwRqH3Yv+hjllZFMPxHDtNjwb7T9mu6sjoWHBNRmJaS 3WXwtTdSnYUP16oRoUc20fyWGY/2pM0psoLKS3IoNggPiDSMNDzMNQI7HDQdYnJPlV VyVGWixas6+MPsvKtYwnrd2k75s1+8IGwn5gmzhopfJKj5frIG3pkTlHZCXW9Lb2WK je1PxyFAKALgQ== Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 09/02/2019 20:34, Andrew Lunn wrote: >> So we I see two possible solutions: >> >> 1) having both ds->slave_mii_bus and ds->ops->phy_read already defined is an >> error, then it must be signaled to the calling code, or > > I don't think we can do that. mv88e6xxx optionally instantiates the > MDIO busses, depending on what is in device tree. If there is no mdio > property, we need the DSA core to create an MDIO bus. OK, but using the following check to know if DSA did such allocation is not correct because DSA drivers can allocate it by their own: static void dsa_switch_teardown(struct dsa_switch *ds) { if (ds->slave_mii_bus && ds->ops->phy_read) mdiobus_unregister(ds->slave_mii_bus); Maybe can we add a flag to register ds->slave_mii_bus allocation by DSA? > Looking at the driver, ds->slave_mii_bus is assigned in > mv88e6xxx_setup(). > > We have talked about adding a teardown() to the ops structure. This > seems like another argument we should do it. The mv88e6xxx_teardown() > can set ds->slave_mii_bus back to NULL, undoing what it did in the > setup code. This seems reasonable to me, but in this case you have to call teardown() operation before calling mdiobus_unregister() into dsa_switch_teardown() or we still have the problem... Ciao, Rodolfo -- GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@linux.it Embedded Systems phone: +39 349 2432127 UNIX programming skype: rodolfo.giometti