Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1034305AbcJ1STv (ORCPT ); Fri, 28 Oct 2016 14:19:51 -0400 Received: from muru.com ([72.249.23.125]:46379 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1034178AbcJ1STS (ORCPT ); Fri, 28 Oct 2016 14:19:18 -0400 Date: Fri, 28 Oct 2016 11:19:14 -0700 From: Tony Lindgren To: Jeroen Hofstee Cc: netdev@vger.kernel.org, Mugunthan V N , Grygorii Strashko , "open list:TI ETHERNET SWITCH DRIVER (CPSW)" , open list Subject: Re: [PATCH v2] net: cpsw: fix obtaining mac address for am3517 Message-ID: <20161028181914.mskebckucukzhxhz@atomide.com> References: <1477668756-2651-1-git-send-email-jhofstee@victronenergy.com> <20161028155213.2t3nwwe3lqaynaer@atomide.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.2-neo (2016-07-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1437 Lines: 32 * Jeroen Hofstee [161028 11:19]: > Hello Tony, > > On 28-10-16 17:52, Tony Lindgren wrote: > > * Jeroen Hofstee [161028 08:33]: > > > Commit b6745f6e4e63 ("drivers: net: cpsw: davinci_emac: move reading mac > > > id to common file") did not only move the code for an am3517, it also > > > added the slave parameter, resulting in an invalid (all zero) mac address > > > being returned for an am3517, since it only has a single emac and the slave > > > parameter is pointing to the second. So simply always read the first and > > > valid mac-address for a ti,am3517-emac. > > And others davinci_emac.c users can have more than one. So is the > > reason the slave parameter points to the second instance because > > of the location in the hardware? > > Sort of, the slave parameter gets determined by the fact if there is one > or two register range(s) associated with the davinci_emac. In davinci_emac.c > > res_ctrl = platform_get_resource(pdev, IORESOURCE_MEM, 1); > ... > rc = davinci_emac_try_get_mac(pdev, res_ctrl ? 0 : 1, > priv->mac_addr); > > So it there are two ranges, the slave param becomes 0. It there is only one, > it > will be 1. Since the am3517 only has a single regs entry it ends up with > slave 1, > while there is only a single davinci_emac. OK thanks for clarifying it: Acked-by: Tony Lindgren