| Message ID | 1539356258-12374-1-git-send-email-yamada.masahiro@socionext.com |
|---|---|
| Headers | show |
| Series | mmc: uniphier-sd: two bug-fixes | expand |
> In further testing in uniphier-sd.c, > I found my stupid mistakes. I don't have the uniphier HW but I still had a look at these patches. You never know if there is something interesting for SDHI in there :) > Can you squash this series into > 3fd784f745dd > "mmc: uniphier-sd: add UniPhier SD/eMMC controller driver" > if you have a chance to do rebase? Please don't rebase! We actually develop on top of mmc/next and rebasing creates a lot of pain because we lose the base for that work.
On Fri, Oct 12, 2018 at 11:57:38PM +0900, Masahiro Yamada wrote: > host->chan_rx is NULL when UNIPHIER_SD_CAP_BROKEN_DMA_RX quirk flag > is set. In this case, it should not set up DMA. > > Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
On Mon, Oct 15, 2018 at 7:33 AM Wolfram Sang <wsa@the-dreams.de> wrote: > > > > In further testing in uniphier-sd.c, > > I found my stupid mistakes. > > I don't have the uniphier HW but I still had a look at these patches. > You never know if there is something interesting for SDHI in there :) > > > Can you squash this series into > > 3fd784f745dd > > "mmc: uniphier-sd: add UniPhier SD/eMMC controller driver" > > if you have a chance to do rebase? > > Please don't rebase! Some sub-systems rebase, and some do not. It is up to the sub-system maintainer. I am not asking to rebase just for my two fixes. I see linux-mmc regularly rebase anyway. I'd prefer cleaner git history if Ulf just happens to do one more rebase in this cycle. > We actually develop on top of mmc/next and rebasing > creates a lot of pain because we lose the base for that work. I know what you are saying, but this is how we develop in linux-next. You need to use "git rebase --onto". -- Best Regards Masahiro Yamada
> Some sub-systems rebase, and some do not. > It is up to the sub-system maintainer. We used to have a very strict rule to not rebase anything which ends up in linux-next. Dunno what happened to this rule but I liked it. > I know what you are saying, but this is how we develop in linux-next. I wonder about that... > You need to use "git rebase --onto". And what about lists with commit IDs tracking patches on their way upstream? Yes, there is git-patch-id, yet I think it is easier to admit that incremental changes happen anyway. I know Ulf view differs...
On 15 October 2018 at 09:33, Wolfram Sang <wsa@the-dreams.de> wrote: > >> Some sub-systems rebase, and some do not. >> It is up to the sub-system maintainer. > > We used to have a very strict rule to not rebase anything which ends up > in linux-next. Dunno what happened to this rule but I liked it. > >> I know what you are saying, but this is how we develop in linux-next. > > I wonder about that... > >> You need to use "git rebase --onto". > > And what about lists with commit IDs tracking patches on their way > upstream? Yes, there is git-patch-id, yet I think it is easier to admit > that incremental changes happen anyway. I know Ulf view differs... > For this particular case I can avoid the re-base, as you prefer. However, in general can't commit to not rebase, as it depends on case by case basis. Kind regards Uffe