Hi Rick, On Wed, Mar 4, 2020 at 11:11 PM Sean Anderson <sean...@gmail.com> wrote: > > On 3/4/20 2:47 AM, Rick Chen wrote: > > Hi Sean > > > > This patch series become larger and larger from v1 with 11 patches to > > v5 with 33 patches. > > I didn't intend for it to balloon so large. My original goal for this > revision was just to get the SPI and MMC slots working. However, I > discovered that I would need to implement a pinmux slot and GPIOs for > the MMC slot to work (since I think that is the primary motivating > factor for using U-Boot on this board, as opposed to the native > bootloader). > > > You shall just fix the suggestions from the previous version in the > > next version. > > I will try to do that :) > > > Additional extra features and subsystem drivers that you want to > > support, you shall send them individually instead of mixing them > > together. > > In the past, I have been told to keep this sort of thing in one series > (e.g. by Bin Meng). I'm really not sure what things I should split off > and which I should keep together. >
If separate patches are sent via different tree, we only get a complete new RISC-V board support after all trees are merged. Also there might be inter-dependencies between patches. My practice is to wait for sub-domain maintainers to give Ack or RB tags, then pull all series via one tree. > > > > If you can separate them into different series(spi, gpio,led , > > pinctrl, watchdog, those drivers were not present in v1) and they will > > not block the reviewing schedule each other. > > Hm, ok. Perhaps split those off into series which depend on this one? > > > Narrow down the dependency, it can help to speed up the patch work. > > And I am happy to help pulling the RISC-V relative patchs via riscv > > tree ASAP. > > Ok, I will try and get another version out which fixes the feedback I > have gotten on those patches. Regards, Bin
