* [PATCH 0/2] mmc: uniphier-sd: two bug-fixes
@ 2018-10-12 14:57 ` Masahiro Yamada
0 siblings, 0 replies; 23+ messages in thread
From: Masahiro Yamada @ 2018-10-12 14:57 UTC (permalink / raw)
To: linux-arm-kernel
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(-)
--
2.7.4
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 0/2] mmc: uniphier-sd: two bug-fixes
@ 2018-10-12 14:57 ` Masahiro Yamada
0 siblings, 0 replies; 23+ messages in thread
From: Masahiro Yamada @ 2018-10-12 14:57 UTC (permalink / raw)
To: linux-mmc, Ulf Hansson
Cc: Wolfram Sang, linux-kernel, linux-arm-kernel, Masahiro Yamada
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(-)
--
2.7.4
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 1/2] mmc: uniphier-sd: fix DMA disabling
2018-10-12 14:57 ` Masahiro Yamada
@ 2018-10-12 14:57 ` Masahiro Yamada
-1 siblings, 0 replies; 23+ messages in thread
From: Masahiro Yamada @ 2018-10-12 14:57 UTC (permalink / raw)
To: linux-mmc, Ulf Hansson
Cc: Wolfram Sang, Masahiro Yamada, linux-arm-kernel, linux-kernel
Once DMA is enabled, it is not possible to disable it because
uniphier_sd_dma_endisable() always sets the DMA_ENABLE_DMASDRW bit
regardless of the argument 'enable'. It should disable DMA when
'enable' is false.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/mmc/host/uniphier-sd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/uniphier-sd.c b/drivers/mmc/host/uniphier-sd.c
index 10e7b30..10d49aa 100644
--- a/drivers/mmc/host/uniphier-sd.c
+++ b/drivers/mmc/host/uniphier-sd.c
@@ -78,7 +78,7 @@ static void *uniphier_sd_priv(struct tmio_mmc_host *host)
static void uniphier_sd_dma_endisable(struct tmio_mmc_host *host, int enable)
{
- sd_ctrl_write16(host, CTL_DMA_ENABLE, DMA_ENABLE_DMASDRW);
+ sd_ctrl_write16(host, CTL_DMA_ENABLE, enable ? DMA_ENABLE_DMASDRW : 0);
}
/* external DMA engine */
--
2.7.4
^ permalink raw reply related [flat|nested] 23+ messages in thread* [PATCH 1/2] mmc: uniphier-sd: fix DMA disabling
@ 2018-10-12 14:57 ` Masahiro Yamada
0 siblings, 0 replies; 23+ messages in thread
From: Masahiro Yamada @ 2018-10-12 14:57 UTC (permalink / raw)
To: linux-arm-kernel
Once DMA is enabled, it is not possible to disable it because
uniphier_sd_dma_endisable() always sets the DMA_ENABLE_DMASDRW bit
regardless of the argument 'enable'. It should disable DMA when
'enable' is false.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/mmc/host/uniphier-sd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/uniphier-sd.c b/drivers/mmc/host/uniphier-sd.c
index 10e7b30..10d49aa 100644
--- a/drivers/mmc/host/uniphier-sd.c
+++ b/drivers/mmc/host/uniphier-sd.c
@@ -78,7 +78,7 @@ static void *uniphier_sd_priv(struct tmio_mmc_host *host)
static void uniphier_sd_dma_endisable(struct tmio_mmc_host *host, int enable)
{
- sd_ctrl_write16(host, CTL_DMA_ENABLE, DMA_ENABLE_DMASDRW);
+ sd_ctrl_write16(host, CTL_DMA_ENABLE, enable ? DMA_ENABLE_DMASDRW : 0);
}
/* external DMA engine */
--
2.7.4
^ permalink raw reply related [flat|nested] 23+ messages in thread* Re: [PATCH 1/2] mmc: uniphier-sd: fix DMA disabling
2018-10-12 14:57 ` Masahiro Yamada
@ 2018-10-14 22:33 ` Wolfram Sang
-1 siblings, 0 replies; 23+ messages in thread
From: Wolfram Sang @ 2018-10-14 22:33 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mmc, Ulf Hansson, Wolfram Sang, linux-arm-kernel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 423 bytes --]
On Fri, Oct 12, 2018 at 11:57:37PM +0900, Masahiro Yamada wrote:
> Once DMA is enabled, it is not possible to disable it because
> uniphier_sd_dma_endisable() always sets the DMA_ENABLE_DMASDRW bit
> regardless of the argument 'enable'. It should disable DMA when
> 'enable' is false.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 1/2] mmc: uniphier-sd: fix DMA disabling
2018-10-12 14:57 ` Masahiro Yamada
@ 2018-10-15 13:15 ` Ulf Hansson
-1 siblings, 0 replies; 23+ messages in thread
From: Ulf Hansson @ 2018-10-15 13:15 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mmc, Wolfram Sang, Linux ARM, Linux Kernel Mailing List
On 12 October 2018 at 16:57, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> Once DMA is enabled, it is not possible to disable it because
> uniphier_sd_dma_endisable() always sets the DMA_ENABLE_DMASDRW bit
> regardless of the argument 'enable'. It should disable DMA when
> 'enable' is false.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Applied for next, thanks!
Kind regards
Uffe
> ---
>
> drivers/mmc/host/uniphier-sd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/uniphier-sd.c b/drivers/mmc/host/uniphier-sd.c
> index 10e7b30..10d49aa 100644
> --- a/drivers/mmc/host/uniphier-sd.c
> +++ b/drivers/mmc/host/uniphier-sd.c
> @@ -78,7 +78,7 @@ static void *uniphier_sd_priv(struct tmio_mmc_host *host)
>
> static void uniphier_sd_dma_endisable(struct tmio_mmc_host *host, int enable)
> {
> - sd_ctrl_write16(host, CTL_DMA_ENABLE, DMA_ENABLE_DMASDRW);
> + sd_ctrl_write16(host, CTL_DMA_ENABLE, enable ? DMA_ENABLE_DMASDRW : 0);
> }
>
> /* external DMA engine */
> --
> 2.7.4
>
^ permalink raw reply [flat|nested] 23+ messages in thread* [PATCH 1/2] mmc: uniphier-sd: fix DMA disabling
@ 2018-10-15 13:15 ` Ulf Hansson
0 siblings, 0 replies; 23+ messages in thread
From: Ulf Hansson @ 2018-10-15 13:15 UTC (permalink / raw)
To: linux-arm-kernel
On 12 October 2018 at 16:57, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> Once DMA is enabled, it is not possible to disable it because
> uniphier_sd_dma_endisable() always sets the DMA_ENABLE_DMASDRW bit
> regardless of the argument 'enable'. It should disable DMA when
> 'enable' is false.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Applied for next, thanks!
Kind regards
Uffe
> ---
>
> drivers/mmc/host/uniphier-sd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/uniphier-sd.c b/drivers/mmc/host/uniphier-sd.c
> index 10e7b30..10d49aa 100644
> --- a/drivers/mmc/host/uniphier-sd.c
> +++ b/drivers/mmc/host/uniphier-sd.c
> @@ -78,7 +78,7 @@ static void *uniphier_sd_priv(struct tmio_mmc_host *host)
>
> static void uniphier_sd_dma_endisable(struct tmio_mmc_host *host, int enable)
> {
> - sd_ctrl_write16(host, CTL_DMA_ENABLE, DMA_ENABLE_DMASDRW);
> + sd_ctrl_write16(host, CTL_DMA_ENABLE, enable ? DMA_ENABLE_DMASDRW : 0);
> }
>
> /* external DMA engine */
> --
> 2.7.4
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 2/2] mmc: uniphier-sd: avoid using broken DMA RX channel
2018-10-12 14:57 ` Masahiro Yamada
@ 2018-10-12 14:57 ` Masahiro Yamada
-1 siblings, 0 replies; 23+ messages in thread
From: Masahiro Yamada @ 2018-10-12 14:57 UTC (permalink / raw)
To: linux-mmc, Ulf Hansson
Cc: Wolfram Sang, Masahiro Yamada, linux-arm-kernel, linux-kernel
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>
---
drivers/mmc/host/uniphier-sd.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mmc/host/uniphier-sd.c b/drivers/mmc/host/uniphier-sd.c
index 10d49aa..1ee9fd0 100644
--- a/drivers/mmc/host/uniphier-sd.c
+++ b/drivers/mmc/host/uniphier-sd.c
@@ -251,6 +251,9 @@ static void uniphier_sd_internal_dma_start(struct tmio_mmc_host *host,
u32 dma_mode;
int sg_len;
+ if ((data->flags & MMC_DATA_READ) && !host->chan_rx)
+ goto force_pio;
+
if (WARN_ON(host->sg_len != 1))
goto force_pio;
--
2.7.4
^ permalink raw reply related [flat|nested] 23+ messages in thread
* [PATCH 2/2] mmc: uniphier-sd: avoid using broken DMA RX channel
@ 2018-10-12 14:57 ` Masahiro Yamada
0 siblings, 0 replies; 23+ messages in thread
From: Masahiro Yamada @ 2018-10-12 14:57 UTC (permalink / raw)
To: linux-arm-kernel
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>
---
drivers/mmc/host/uniphier-sd.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mmc/host/uniphier-sd.c b/drivers/mmc/host/uniphier-sd.c
index 10d49aa..1ee9fd0 100644
--- a/drivers/mmc/host/uniphier-sd.c
+++ b/drivers/mmc/host/uniphier-sd.c
@@ -251,6 +251,9 @@ static void uniphier_sd_internal_dma_start(struct tmio_mmc_host *host,
u32 dma_mode;
int sg_len;
+ if ((data->flags & MMC_DATA_READ) && !host->chan_rx)
+ goto force_pio;
+
if (WARN_ON(host->sg_len != 1))
goto force_pio;
--
2.7.4
^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH 2/2] mmc: uniphier-sd: avoid using broken DMA RX channel
2018-10-12 14:57 ` Masahiro Yamada
@ 2018-10-14 22:35 ` Wolfram Sang
-1 siblings, 0 replies; 23+ messages in thread
From: Wolfram Sang @ 2018-10-14 22:35 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mmc, Ulf Hansson, Wolfram Sang, linux-arm-kernel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 321 bytes --]
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>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 2/2] mmc: uniphier-sd: avoid using broken DMA RX channel
2018-10-12 14:57 ` Masahiro Yamada
@ 2018-10-15 13:15 ` Ulf Hansson
-1 siblings, 0 replies; 23+ messages in thread
From: Ulf Hansson @ 2018-10-15 13:15 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mmc, Wolfram Sang, Linux ARM, Linux Kernel Mailing List
On 12 October 2018 at 16:57, Masahiro Yamada
<yamada.masahiro@socionext.com> 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>
Applied for next, thanks!
Kind regards
Uffe
> ---
>
> drivers/mmc/host/uniphier-sd.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/mmc/host/uniphier-sd.c b/drivers/mmc/host/uniphier-sd.c
> index 10d49aa..1ee9fd0 100644
> --- a/drivers/mmc/host/uniphier-sd.c
> +++ b/drivers/mmc/host/uniphier-sd.c
> @@ -251,6 +251,9 @@ static void uniphier_sd_internal_dma_start(struct tmio_mmc_host *host,
> u32 dma_mode;
> int sg_len;
>
> + if ((data->flags & MMC_DATA_READ) && !host->chan_rx)
> + goto force_pio;
> +
> if (WARN_ON(host->sg_len != 1))
> goto force_pio;
>
> --
> 2.7.4
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 2/2] mmc: uniphier-sd: avoid using broken DMA RX channel
@ 2018-10-15 13:15 ` Ulf Hansson
0 siblings, 0 replies; 23+ messages in thread
From: Ulf Hansson @ 2018-10-15 13:15 UTC (permalink / raw)
To: linux-arm-kernel
On 12 October 2018 at 16:57, Masahiro Yamada
<yamada.masahiro@socionext.com> 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>
Applied for next, thanks!
Kind regards
Uffe
> ---
>
> drivers/mmc/host/uniphier-sd.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/mmc/host/uniphier-sd.c b/drivers/mmc/host/uniphier-sd.c
> index 10d49aa..1ee9fd0 100644
> --- a/drivers/mmc/host/uniphier-sd.c
> +++ b/drivers/mmc/host/uniphier-sd.c
> @@ -251,6 +251,9 @@ static void uniphier_sd_internal_dma_start(struct tmio_mmc_host *host,
> u32 dma_mode;
> int sg_len;
>
> + if ((data->flags & MMC_DATA_READ) && !host->chan_rx)
> + goto force_pio;
> +
> if (WARN_ON(host->sg_len != 1))
> goto force_pio;
>
> --
> 2.7.4
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/2] mmc: uniphier-sd: two bug-fixes
2018-10-12 14:57 ` Masahiro Yamada
@ 2018-10-14 22:33 ` Wolfram Sang
-1 siblings, 0 replies; 23+ messages in thread
From: Wolfram Sang @ 2018-10-14 22:33 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mmc, Ulf Hansson, Wolfram Sang, linux-arm-kernel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 496 bytes --]
> 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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 0/2] mmc: uniphier-sd: two bug-fixes
@ 2018-10-14 22:33 ` Wolfram Sang
0 siblings, 0 replies; 23+ messages in thread
From: Wolfram Sang @ 2018-10-14 22:33 UTC (permalink / raw)
To: linux-arm-kernel
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20181015/8c912046/attachment.sig>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/2] mmc: uniphier-sd: two bug-fixes
2018-10-14 22:33 ` Wolfram Sang
@ 2018-10-15 3:12 ` Masahiro Yamada
-1 siblings, 0 replies; 23+ messages in thread
From: Masahiro Yamada @ 2018-10-15 3:12 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-mmc, Ulf Hansson, Wolfram Sang, linux-arm-kernel,
Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 0/2] mmc: uniphier-sd: two bug-fixes
@ 2018-10-15 3:12 ` Masahiro Yamada
0 siblings, 0 replies; 23+ messages in thread
From: Masahiro Yamada @ 2018-10-15 3:12 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/2] mmc: uniphier-sd: two bug-fixes
2018-10-15 3:12 ` Masahiro Yamada
@ 2018-10-15 7:33 ` Wolfram Sang
-1 siblings, 0 replies; 23+ messages in thread
From: Wolfram Sang @ 2018-10-15 7:33 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mmc, Ulf Hansson, Wolfram Sang, linux-arm-kernel,
Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 568 bytes --]
> 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...
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 0/2] mmc: uniphier-sd: two bug-fixes
@ 2018-10-15 7:33 ` Wolfram Sang
0 siblings, 0 replies; 23+ messages in thread
From: Wolfram Sang @ 2018-10-15 7:33 UTC (permalink / raw)
To: linux-arm-kernel
> 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...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20181015/36f0b364/attachment.sig>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH 0/2] mmc: uniphier-sd: two bug-fixes
2018-10-15 7:33 ` Wolfram Sang
@ 2018-10-15 12:51 ` Ulf Hansson
-1 siblings, 0 replies; 23+ messages in thread
From: Ulf Hansson @ 2018-10-15 12:51 UTC (permalink / raw)
To: Wolfram Sang
Cc: Masahiro Yamada, linux-mmc, Wolfram Sang, linux-arm-kernel,
Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH 0/2] mmc: uniphier-sd: two bug-fixes
@ 2018-10-15 12:51 ` Ulf Hansson
0 siblings, 0 replies; 23+ messages in thread
From: Ulf Hansson @ 2018-10-15 12:51 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 23+ messages in thread