On Wed, Jul 29, 2026 at 11:58 PM Yao Zi <[email protected]> wrote: > > On Wed, Jul 29, 2026 at 10:05:14PM +0800, Eric Chung wrote: > > On Tue, Jul 28, 2026 at 5:11 PM Yao Zi <[email protected]> wrote: > > > > > > On Tue, Jul 28, 2026 at 09:04:52AM +0800, Eric Chung wrote: > > > > On Tue, Jul 28, 2026 at 1:08 AM Yao Zi <[email protected]> wrote: > > > > > > > > > > On Mon, Jul 27, 2026 at 09:08:52PM +0800, Eric Chung wrote: > > > > > > Hi Yao, > > > > > > > > > > > > I'm not familiar with the policy for syncing DTS files from the > > > > > > Linux upstream. > > > > > > Could you clarify how this script works? > > > > > > > > > > > > Does it sync all DTS files from Linux upstream at once, or is it > > > > > > possible to sync > > > > > > only the Spacemit DTS file? > > > > > > > > > > update-subtree.sh cherry-picks a commit from the upstream, or > > > > > merge an upstream tag into the subtree. Cherry-picking SD-related > > > > > commits from Linux upstream suits for your case. > > > > > > > > > > > If I choose to sync only the Spacemit DTS file and include it in my > > > > > > patch set, > > > > > > would that cause conflicts later when others try to sync all DTS > > > > > > files? > > > > > > > > > > Tom synchronizes the dts subtree with Linux upstream irregularly, > > > > > there > > > > > should be no conflict or relatively small ones if you cherry-pick the > > > > > changes, while adding downstream nodes in *-u-boot.dtsi might suffer > > > > > from duplication, too, during synchronization. > > > > > > > > > > > > > The process is a bit complex. Since my main issue is that the DTS > > > > files are out of > > > > date, would it be simpler if I just copy the relevant Spacemit DTS > > > > files directly > > > > from the Linux upstream into the dts/upstream folder? > > > > > > The answer is simply no. > > > > > > > OK. I'll keep using my own overlay DTS file. > > I tried upstream DTS file. It only gave me more bugs. I could switch to > > upstream DTS file when Tom syncs it. > > So first of all, please note switching to upstream devicetree doesn't > mean you must remove all the dts overlays, you could keep small pieces > like these adding bootph-pre-ram properties, which are > bootloader-specific and might not get upstreamed in a short period. > > And I noticed there have been quite a lot code in the overlays, like the > PMIC code, thus changes to overlays might be huge when cherry-picking, > if it's the case, this patch is then acceptable, but please mention it > in the commit message. > Yes, it's one of the reasons. Too many related commits exist. I prefer to keep the process simple. When someone syncs the whole DTS, the process is much easier and avoids commit conflicts.
> But, if switching to the devicetree with cherry-picked patches for MMC > leads to bugs, there are likely ABI compatibility issues in your driver, > which would persist even after the synchronization with upstream v7.2 > tag. Please fix them. From the very start, it's agreed compatibility > with Linux devicetree ABI is important[1]. There are several commits on DTS. Cherry-picking only a few commits is not ideal. I'm using upstream DTS. I just keep minimal changes in the overlay DTS file. The cd-gpios property isn't even consistent between bananapi f3 and musepi pro board. The sequence of mmc nodes is also inconsistent. SD node is declared first, and the eMMC node is declared second. However, there is an alias that reverses this order. In order to make it work, I have to enable CONFIG_DM_SEQ_ALIAS. As I said they could be fixed. And I failed to cherry-pick only a few commits. So I don't want to import commit conflicts when I synchronizing DTS files. I prefer it could be handled by maintainers. When it's done, I can continue to submit new patches for fixes. It should be fixed in Linux. But that doesn't mean I must fix the error in Linux first. Then I submit this patch set after 6 months, waiting for the fix to merge in Linux. > > So here's my NAK for this series, including v7 of it. > > Thanks, > Yao Zi > > [1]: https://lore.kernel.org/all/20260429-glare-anybody-16c98d01184e@spud/ > > > > > > > Best Regards > > > > > > Eric > > > > > > Regards, > > > Yao Zi > > > > > > > > By the way, please avoid top-posting if possible. > > > > > > > > > > Thanks, > > > > > Yao Zi > > > > > > > > > > > On Mon, Jul 27, 2026 at 7:52 PM Yao Zi <[email protected]> wrote: > > > > > > > > > > > > > > On Mon, Jul 27, 2026 at 02:59:08PM +0800, Eric Chung wrote: > > > > > > > > Add the SDH0 controller node and its pinctrl groups to the > > > > > > > > u-boot > > > > > > > > overlay. The upstream DTS only contains the eMMC node; the SD > > > > > > > > card > > > > > > > > controller (sdhci@d4280000) and its MMC1 pinctrl configuration > > > > > > > > are > > > > > > > > missing. Place the new node inside the storage-bus via > > > > > > > > path-based > > > > > > > > merge so it inherits the dma-ranges from the parent bus. > > > > > > > > > > > > > > > > Signed-off-by: Eric Chung <[email protected]> > > > > > > > > > > > > > > Please cherry-pick upstream devicetree changes from Linux > > > > > > > upstream with > > > > > > > tools/update-subtree.sh instead of adding our own copies. Changes > > > > > > > for > > > > > > > k1-bananapi-f3 and k1-muse-pi-pro have both landed in Linux v7.2. > > > > > > > > > > > > > > Best regards, > > > > > > > Yao Zi > > > > > > > > > > > > > > > --- > > > > > > > > v5: > > > > > > > > - Append power source field on eMMC/SD pinctrl. > > > > > > > > v3: > > > > > > > > - Fix SD pinctrl as uhs. > > > > > > > > v2: > > > > > > > > - Use vmmc-supply as vqmmc-supply on SD node. > > > > > > > > - Add alias of mmc0 and mmc1. > > > > > > > > --- > > > > > > > > arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi | 91 > > > > > > > > ++++++++++++++++++++++++++++++- > > > > > > > > arch/riscv/dts/k1-musepi-pro-u-boot.dtsi | 86 > > > > > > > > ++++++++++++++++++++++++++++- > > > > > > > > 2 files changed, 173 insertions(+), 4 deletions(-)
