From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Walle Date: Sun, 03 Nov 2019 16:22:48 +0100 Subject: [U-Boot] Pull request: u-boot-net.git master In-Reply-To: <20191102150520.GN11173@bill-the-cat> References: <20190508224849.GW25571@bill-the-cat> <20190508225455.GX25571@bill-the-cat> <20190515145844.GC22232@bill-the-cat> <594fdfe224bb5ecbaf92200121266d40@walle.cc> <20191102141209.GM11173@bill-the-cat> <20191102150520.GN11173@bill-the-cat> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Am 2019-11-02 16:05, schrieb Tom Rini: [snip] > But again, I've given up. I say that the ABI meant that the wrong > value > was supposed to work since that's what happened and a new version of > the > binding needed to be used where the right value must be used. Others > disagree. I'm not holding U-Boot up on the new changes over this, I > just haven't put together the PR. It's on my short list now. I want to rebase my cleanup and device tree support for the Atheros PHY onto the patches by Vladimir. Although I do have some problems/questions now: - will the whole series [1] be pulled altogether? - there is a kconfig option to control the EEE option. Wouldn't it be better to put that into a device tree property option too? - there were some cleanups I'd do another way, for example the clock enumeration uses "BIT(0) | BIT(1)" instead of 3. I'd use a mask and the correct enumeration and FIELD_PREP(). So should I base my patch on Vladimirs patch? Should Vladimir post a new patch? To be frank, I'd rather pull Vladimirs patches and change (or drop them if they are superseeded mine), if everyone is ok with that. I'd propose the following: - I rebase my patches onto Vladimirs patches - change some of Vladimirs patches - privately, mail the patch series to Vladimir, then he can review them, add SOB or other tags - If he is ok with the changes, I'll post another "atheros PHY cleanup and device tree support" series with patches from Vladimir and myself. I don't really want to hijack any patches, but patching the patch seems to be not really good. Does anybody know if the "disable smartEEE" should go into the linux phy driver too? As far as I understand it, linux configures the complete phy itself, (eg. it might even do a hardware reset). -- -michael [1] https://patchwork.ozlabs.org/cover/1031360/