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=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 C80BBC43381 for ; Fri, 22 Mar 2019 10:58:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9F3A521900 for ; Fri, 22 Mar 2019 10:58:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728112AbfCVK6k (ORCPT ); Fri, 22 Mar 2019 06:58:40 -0400 Received: from mail.thorsis.com ([92.198.35.195]:56902 "EHLO mail.thorsis.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726667AbfCVK6k (ORCPT ); Fri, 22 Mar 2019 06:58:40 -0400 X-Greylist: delayed 517 seconds by postgrey-1.27 at vger.kernel.org; Fri, 22 Mar 2019 06:58:39 EDT Received: from localhost (localhost [127.0.0.1]) by mail.thorsis.com (Postfix) with ESMTP id 262B23E54 for ; Fri, 22 Mar 2019 11:50:18 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mail.thorsis.com Received: from mail.thorsis.com ([127.0.0.1]) by localhost (mail.thorsis.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qk54zO5NNKeG for ; Fri, 22 Mar 2019 11:50:14 +0100 (CET) Received: by mail.thorsis.com (Postfix, from userid 109) id 6A59BEF9; Fri, 22 Mar 2019 11:50:14 +0100 (CET) From: Alexander Dahl To: Nicolas Ferre Cc: netdev@vger.kernel.org, Harini Katakam , u-boot@lists.denx.de, Bo Shen , Rafal Ozieblo , Claudiu Beznea Subject: macb: MID register on SAMA5D2 series? Date: Fri, 22 Mar 2019 11:49:54 +0100 Message-ID: <1836694.YYIscaEoiJ@ada> Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hei hei, while bringing up support for a new SAMA5D27 based board I noticed something strange in the macb driver in both U-Boot and Linux. There's a function in both to determine if or not the IP block in the SoC is the gigabit variant, commonly refered to as GEM. The function in U-Boot: static int macb_is_gem(struct macb_device *macb) { return MACB_BFEXT(IDNUM, macb_readl(macb, MID)) >= 0x2; } And in Linux: static bool hw_is_gem(void __iomem *addr, bool native_io) { u32 id; if (native_io) id = __raw_readl(addr + MACB_MID); else id = readl_relaxed(addr + MACB_MID); return MACB_BFEXT(IDNUM, id) >= 0x2; } In both cases a register MID is read, in both cases that has an offset of 0x00fc. #define MACB_MID 0x00fc I studied the register layouts in the datasheets for AT91SAM9G20, SAMA5D2 series, SAMA5D3 series, and SAMA5D4 series. In all but SAMA5D2, offset 0x00fc is marked as reserved for both EMAC and GMAC variants. SAMA5D2 however has a register GMAC_EFTSH (GMAC PTP Event Frame Transmitted Seconds High Register) at this offset. Because the check for SAMA5D2 is broken in U-Boot since v2017.09-111-g245cbc583d (I will send a patch for that today), I got some weird behaviour with our new SAMA5D27 based board. While the SAMA5D27-SOM1-EK worked fine in U-Boot, our board did not, but reported Gigabit Speed on the ethernet link, which is neither supported by SAMA5D2 nor by the ethernet PHY (LAN8720A). I suppose the register content at that offset on that SoC, just does not give that MID? That would be in line with the SAMA5D2 datasheet, and the detection on those SoCs currently works or does not only by chance in U-Boot? However that register offset was introduced in both U-Boot and Linux long time ago, back in 2011 or 2012, so maybe that IP block looks somewhat different on non Atmel/Microchip SoCs? Is there some secret meaning to that register offset, not documented in all those Atmel/Microchip datasheets? Or is that check just wrong on those platforms and nobody noticed yet? I would care to send patches, but I would like to get an idea first on what is supposed to be in that register. At least I'd like to get the behaviour for SAMA5D27 fixed, and would be happy for advice on that. If someone else wants to step in, I would happily test it. ;-) Sorry if I put anyone on Cc, who is not involved in that macb drivers anymore. The get-maintainer scripts on both Linux and U-Boot don't return a maintainer, so I got some people from the last commits on each. O:-) Curious greetings Alex