On 2020/12/16 10:43, Palmer Dabbelt wrote: > On Sun, 13 Dec 2020 00:06:22 PST (-0800), Damien Le Moal wrote: >> On Sat, 2020-12-12 at 22:04 -0800, Stephen Boyd wrote: >>> Quoting Damien Le Moal (2020-12-10 06:02:51) >>>> >>>> Finally the last two patches updates the k210 nommu defconfig to include >>>> the newly implemented drivers and provide a new default configuration >>>> file enabling SD card support. >>>> >>>> A lot of the work on the device tree and on the K210 drivers come from >>>> the work by Sean Anderson for the U-Boot project support of the K210 >>>> SoC. Sean also helped with debugging many aspects of this series. >>>> >>>> A tree with all patches applied is available here: >>>> https://github.com/damien-lemoal/linux, k210-sysctl-v20 branch. >>>> A demonstration of this series used on a SiPeed MAIX Dock >>>> board together with an I2C servo controller can be seen here: >>>> https://damien-lemoal.github.io/linux-robot-arm/#example >>>> >>>> This tree was used to build userspace busybox environment image that is >>>> then copied onto an SD card formatted with ext2: >>>> https://github.com/damien-lemoal/buildroot >>>> Of note is that running this userspace environment requires a revert of >>>> commit 2217b982624680d19a80ebb4600d05c8586c4f96 introduced during the >>>> 5.9 development cycle. Without this revert, execution of the init >>>> process fails. A problem with the riscv port of elf2flt is suspected but >>>> not confirmed. I am now starting to investigate this problem. >>>> >>>> Reviews and comments are as always much welcome. >>> >>> What's the merge plan for this series? I'd like to apply the clk patches >>> but they're combined with the sysctl driver so I guess I can't? >> >> Not sure. Palmer ? What is your plan for this series ? Can you queue the >> riscv/DT pieces for 5.11 ? >> >> I will post a v9 to address Rob's comment on the sysctl and fpioa drivers >> binding doc, not other with v8 changes beside that. > > I guess I got hung up on that bultin DT thing, but I've sort of decided I don't > really care that much (though I guess I didn't decide enough to reply to the > email...). I don't think it's 5.11 material: we were told to be stricter this > time around because of the timing, and I'm trying to sort out a boot issue > that's manifesting post 5.10+for-next merge so I probably won't have time to > take more stuff. > > Also: I'm kind of trying to avoid the whole thing where I take patches that > have a bunch of versions sent either right before or during the merge window, > as it just makes things too hard to keep track of. OK. 5.12 it is then. Please queue these in a branch as soon as possible once the merge window is done. Or do you prefer that I resend everything rebased on 5.11-rc first ? That said, I think patches 1-3 should go in 5.11. 1 & 2 are trivial and patch 3 fixes a nasty bug that exists with the current k210 support. -- Damien Le Moal Western Digital Research
