[From nobody Thu Jun 25 05:54:49 2020 Received: from mail-oi0-x242.google.com ([2607:f8b0:4003:c06::242]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1fqkbR-0000Id-02 for openwrt-devel@lists.openwrt.org; Fri, 17 Aug 2018 19:40:10 +0000 Received: by mail-oi0-x242.google.com with SMTP id s198-v6so15882521oih.11 for <openwrt-devel@lists.openwrt.org>; Fri, 17 Aug 2018 12:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RBA25W6NL1dB9K0b7qC7h06/M3r26qOFsHf9bP4jReM=; b=MR4s/KHeerZ2S3ZttUPezY410p+uQ1FQuwkgJspuiBA6od5uNLKP8ifOsVODZef0fB y9JcFb6vYkSNQelRfncOvDyPyBWZ+3ydN1un3ECjnqMqguWvD+fNV3jpEBXf8D5LXcc6 PyLxdBSIuOaF+BoJUkf20aZwyDUf7E9uNgL5/7zemvey0fZcYBK7MkGKLDMD41OFAPQv 0uhXXIzAiFH+tBX16eGcLL9miM9/KKm5Y0kKs9fXGR/iBJfsZJBWmv9D77MyGnE+VGuK J353pnXGhKQ8HvRIgHPDgDAksSgsEpaVjwInjWtJ4B+nYmqEvnv/LCXAg+PKmjgCDnr8 WZPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RBA25W6NL1dB9K0b7qC7h06/M3r26qOFsHf9bP4jReM=; b=HuhH0v0tDkPLCuhbEoYAxkCj8GcJqipLkrJ7w6ykYgYy1oFb7W1ETeqvR21kWzFRG0 aHaP2j3mMhQhbQs5KO9KPEQAjdsRQxjEUiKPRrW2gV690r+3fLhgl0o7vj7MEYxXHjvp MrhHnu7V8HXq1UXRD8gVg3KWQ0haI+Rikhp78RqaNqmjRTBc28yzgU4zZDmA9LaDnYZY DPHJFJEZcssNO2L0e8otxMScKaNFX73aWDm5ee23whPMG+g2SLA/19QR72esWjaN2q+J VXCql/rGFPmofP9xYXEIO/tcpPa23UM7RqOSX7+Za3/JNxVGPskjuuSGo/e1gzR7fyt7 uLaA== X-Gm-Message-State: AOUpUlEk4U2QruPBDnxAYdzMI7O3hPZgldQjCeqrfzNaOFXHW9ji3llK pDvJds7KMAJ7FL2CCfbwu6jX7VU4TBiwp3nZO7A= X-Google-Smtp-Source: AA+uWPxUFKH5yeVt5BW9r0eySajhga3AG5jA7WyyjeyQqiOwJl++KMO9FQX73ur8Etja9AXAw9Ayjg5KNBBbO61mRQ4= X-Received: by 2002:aca:31c6:: with SMTP id x189-v6mr3598255oix.213.1534534797673; Fri, 17 Aug 2018 12:39:57 -0700 (PDT) MIME-Version: 1.0 References: <20180816030522.9634-1-gch981213@gmail.com> <CAOiHx=nJT28y8xDyE3ErfpJHNDq8BMSWV6Vnth6VF32--WbPKQ@mail.gmail.com> In-Reply-To: <CAOiHx=nJT28y8xDyE3ErfpJHNDq8BMSWV6Vnth6VF32--WbPKQ@mail.gmail.com> From: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Date: Fri, 17 Aug 2018 21:39:46 +0200 Message-ID: <CAFBinCBh2wqnUVEsQ8Tm0-YNJvyt_o5pELYYLujhoAw=wN_o-w@mail.gmail.com> Subject: Re: [OpenWrt-Devel] [PATCH] [RFC] ath79: ag71xx: apply interface mode to MII0/1_CNTL on ar71xx/ar913x To: jonas.gorski@gmail.com Cc: gch981213@gmail.com, openwrt-devel@lists.openwrt.org Content-Type: text/plain; charset="UTF-8" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20180817_124009_063811_01E6CA23 X-CRM114-Status: GOOD ( 25.22 ) X-Spam-Score: -0.1 (/) X-Spam-Report: SpamAssassin version 3.4.1 on bombadil.infradead.org summary: Content analysis details: (-0.1 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [2607:f8b0:4003:c06:0:0:0:242 listed in] [list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (martin.blumenstingl[at]googlemail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Hi, On Fri, Aug 17, 2018 at 12:05 PM Jonas Gorski <jonas.gorski@gmail.com> wrote: > > Hi, > > On 16 August 2018 at 05:05, Chuanhong Guo <gch981213@gmail.com> wrote: > > Signed-off-by: Chuanhong Guo <gch981213@gmail.com> > > --- > > RFC: > > Previous discussion about this patch can be found on GitHub PR#1271. > > This patch applies correct interface mode to MII0/1_CNTL register at 0x18070000/ > > 0x18070004. But there is a small difference in values for these two registers: > > | GMAC0 | GMAC1 | > > |----------|---------| > > | 0 GMII | 0 RGMII | > > | 1 MII | 1 RMII | > > | 2 RGMII | | > > | 3 RMII | | > > I currently have 4 ways of dealing with this: > > 1. Use a bool value in dts indicating whether this is the second GMAC. This one > > is pretty dirty and I dropped it. > > 2. Split MII_CNTL into separated dt node and use different compatible for them > > like we did for ETH_CFG (gmac node) on ar933x and later SoCs. After some discussion > > on GitHub it turns out to be unreasonable to treat those in separated nodes. > > 3. Use ar7100-eth0/ar7100-eth1 as compatible string. This is what I've done in > > this patch I sent here. But I think my way of using compatible string here is ugly :( > > A possible cleaner implementation would be introducing ar7100-eth0/ar7100-eth1/ > > ar9130-eth0/ar9130-eth1 to replace ar7100-eth/ar9130-eth. But I doubt whether > > introducing 4 new compatible strings for such a slight difference is worthy. as already stated on the github PR I prefer option #3 > > 4. Somehow write all the possible values for each interface mode in device tree. > > e.g. qca,if-modes = "gmii","mii","rgmii","rmii"; for eth0 and > > qca,if-modes = "rgmii","rmii"; for eth1. this would encode register values in a devicetree property (index of each string is the register value) I believe that upstream devicetree maintainers don't want this anymore the rule of thumb is: devicetree should describe the hardware (not register contents or driver settings) because it should be "universal" (some bootloaders use it, Linux uses it, ...) if two devices are compatible they can use the same compatible string however, if they are different (even just slightly) they should get their own compatible string (see the stmmac bindings upstream for an example: Documentation/devicetree/bindings/net/stmmac.txt contains the original stmmac bindings while Documentation/devicetree/bindings/net/meson-dwmac.txt / Documentation/devicetree/bindings/net/stm32-dwmac.txt define new compatible strings because each vendor has defined it's own extensions to the original stmmac IP block) > > Which one is better? Is there any other possible solutions for this problem? > > I'd prefer 4, or a modified 3: > > do something like > > aliases { > .... > ethernet0 = &eth0; > ethernet1 = &eth1; > }; > > > and then you can find out if you are eth0 or eth1 by calling > > id = of_alias_get_id(node, "ethernet"); > > and maybe warn (and don't configure mii mode) if it returns neither 0 or 1. this is an interesting idea do you have any upstream example where this behavior was reviewed (and ACK'ed) by the upstream devicetree maintainers? (I found some examples relying on that exact behavior, but I'm not sure if the devicetree maintainers know about this code/want this solution to be used in the future) Regards Martin ]