[0/2] mmc: uniphier-sd: two bug-fixes

Message

Masahiro Yamada Oct. 12, 2018, 2:57 p.m. UTC

In further testing in uniphier-sd.c,
I found my stupid mistakes.

Ulf,

Can you squash this series into
3fd784f745dd
"mmc: uniphier-sd: add UniPhier SD/eMMC controller driver"
if you have a chance to do rebase?

Of course, it is OK to apply this series
on top of your next branch if it is too late.



Masahiro Yamada (2):
  mmc: uniphier-sd: fix DMA disabling
  mmc: uniphier-sd: avoid using broken DMA RX channel

 drivers/mmc/host/uniphier-sd.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

Comments

Wolfram Sang Oct. 14, 2018, 10:33 p.m. UTC | #1

> 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.

Masahiro Yamada Oct. 15, 2018, 3:12 a.m. UTC | #2

On Mon, Oct 15, 2018 at 7:33 AM Wolfram Sang <[e-mail]> 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

Wolfram Sang Oct. 15, 2018, 7:33 a.m. UTC | #3

> 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...

Ulf Hansson Oct. 15, 2018, 12:51 p.m. UTC | #4

On 15 October 2018 at 09:33, Wolfram Sang <[e-mail]> 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