All of lore.kernel.org
 help / color / mirror / Atom feed
* [GIT PULL] DMA-mapping updates for v3.11
@ 2013-07-02  8:35 Marek Szyprowski
  2013-07-03  0:09 ` Stephen Rothwell
  0 siblings, 1 reply; 6+ messages in thread
From: Marek Szyprowski @ 2013-07-02  8:35 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel, Marek Szyprowski

Hi Linus,

I would like to ask You for pulling some fixes for ARM dma-mapping subsystem
for v3.11.


The following changes since commit 8bb495e3f02401ee6f76d1b1d77f3ac9f079e376:

  Linux 3.10 (2013-06-30 15:13:29 -0700)

are available in the git repository at:

  git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git for-v3.11

for you to fetch changes up to 1e3d09b223f349a5f6cc14d62b4df66c0798d762:

  ARM: dma: Drop __GFP_COMP for iommu dma memory allocations (2013-07-02 10:30:59 +0200)

----------------------------------------------------------------

This pull request contains an important bugfixes and update for IOMMU
integration support for ARM architecture.

Thanks!

Best regards
Marek Szyprowski
Samsung Poland R&D Center

Patch summary:

Richard Zhao (1):
      ARM: dma: Drop __GFP_COMP for iommu dma memory allocations

Will Deacon (2):
      ARM: dma-mapping: convert DMA direction into IOMMU protection attributes
      ARM: dma-mapping: NULLify dev->archdata.mapping pointer on detach

YoungJun Cho (1):
      ARM: dma-mapping: Get pages if the cpu_addr is out of atomic_pool

 arch/arm/mm/dma-mapping.c |   40 ++++++++++++++++++++++++++++++++--------
 1 file changed, 32 insertions(+), 8 deletions(-)

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [GIT PULL] DMA-mapping updates for v3.11
  2013-07-02  8:35 [GIT PULL] DMA-mapping updates for v3.11 Marek Szyprowski
@ 2013-07-03  0:09 ` Stephen Rothwell
  2013-07-03  7:58   ` Marek Szyprowski
  0 siblings, 1 reply; 6+ messages in thread
From: Stephen Rothwell @ 2013-07-03  0:09 UTC (permalink / raw)
  To: Marek Szyprowski; +Cc: Linus Torvalds, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 809 bytes --]

Hi Marek,

On Tue, 02 Jul 2013 10:35:08 +0200 Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>
> I would like to ask You for pulling some fixes for ARM dma-mapping subsystem
> for v3.11.
> 
> 
> The following changes since commit 8bb495e3f02401ee6f76d1b1d77f3ac9f079e376:
> 
>   Linux 3.10 (2013-06-30 15:13:29 -0700)
> 
> are available in the git repository at:
> 
>   git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git for-v3.11
> 
> for you to fetch changes up to 1e3d09b223f349a5f6cc14d62b4df66c0798d762:
> 
>   ARM: dma: Drop __GFP_COMP for iommu dma memory allocations (2013-07-02 10:30:59 +0200)

This was rebased yesterday onto v3.10 for some reason (one commit was
dropped in the rebase).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [GIT PULL] DMA-mapping updates for v3.11
  2013-07-03  0:09 ` Stephen Rothwell
@ 2013-07-03  7:58   ` Marek Szyprowski
  2013-07-03 21:02     ` Linus Torvalds
  0 siblings, 1 reply; 6+ messages in thread
From: Marek Szyprowski @ 2013-07-03  7:58 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: Linus Torvalds, linux-kernel

Hi Stephen,

On 7/3/2013 2:09 AM, Stephen Rothwell wrote:
> Hi Marek,
>
> On Tue, 02 Jul 2013 10:35:08 +0200 Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> >
> > I would like to ask You for pulling some fixes for ARM dma-mapping subsystem
> > for v3.11.
> >
> >
> > The following changes since commit 8bb495e3f02401ee6f76d1b1d77f3ac9f079e376:
> >
> >   Linux 3.10 (2013-06-30 15:13:29 -0700)
> >
> > are available in the git repository at:
> >
> >   git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git for-v3.11
> >
> > for you to fetch changes up to 1e3d09b223f349a5f6cc14d62b4df66c0798d762:
> >
> >   ARM: dma: Drop __GFP_COMP for iommu dma memory allocations (2013-07-02 10:30:59 +0200)
>
> This was rebased yesterday onto v3.10 for some reason (one commit was
> dropped in the rebase).

Right, I dropped one commit, which I found in other 'for_next' kernel 
tree (the
one from Russell King) before sending the pull request. What's wrong 
with this
approach?

Best regards
-- 
Marek Szyprowski
Samsung R&D Institute Poland



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [GIT PULL] DMA-mapping updates for v3.11
  2013-07-03  7:58   ` Marek Szyprowski
@ 2013-07-03 21:02     ` Linus Torvalds
  2013-07-04  6:09       ` Marek Szyprowski
  0 siblings, 1 reply; 6+ messages in thread
From: Linus Torvalds @ 2013-07-03 21:02 UTC (permalink / raw)
  To: Marek Szyprowski; +Cc: Stephen Rothwell, Linux Kernel Mailing List

On Wed, Jul 3, 2013 at 12:58 AM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
>
> Right, I dropped one commit, which I found in other 'for_next' kernel tree
> (the one from Russell King) before sending the pull request. What's wrong with
> this approach?

What did dropping the commit fix? Anything?

DO NOT REBASE UNLESS YOU HAVE SERIOUSLY PRESSING REASONS!

Why does this keep on coming up EVERY SINGLE RELEASE? Does nobody read my rants?

A duplicate commit not a "seriously pressing reason". It may be reason
for some introspection ("why did I and Russell end up applying the
same patch and stepping on each others toes?") but it is not in itself
at all a reason for rebasing.

Reasons for rebasing include:

 - "I am a complete moron, and I have terminally messed up my history
with merges from random places to the point where it is completely
unpullable"

 - "There are commits that are so horribly broken in the history that
I can't even revert them, because seeing them mentioned one more time
will make me go blind"

and the best one:

 - "I never made my patches public in the first place, and I'll clean
my ugly series up before posting them publicly for the first time".

but that last one shouldn't happen just before sending it to me, it
should happen a few weeks before sending to me so that linux-next has
time to digest the beauty of the rebased series.

The fact is, rebasing is a perfectly fine operation, but it's a fine
operation that causes lots of problems if those commits have ever been
public before. It means that linux-next cannot easily be compared to
what I pull (which is why Stephen complains), but it also results in
other developers not being able to trust your tree, and in the commits
randomly changing and the testing base thus not being reliable any
more (which is why I complain).

                   Linus

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [GIT PULL] DMA-mapping updates for v3.11
  2013-07-03 21:02     ` Linus Torvalds
@ 2013-07-04  6:09       ` Marek Szyprowski
  0 siblings, 0 replies; 6+ messages in thread
From: Marek Szyprowski @ 2013-07-04  6:09 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Stephen Rothwell, Linux Kernel Mailing List

Hello,

On 7/3/2013 11:02 PM, Linus Torvalds wrote:
> On Wed, Jul 3, 2013 at 12:58 AM, Marek Szyprowski
> <m.szyprowski@samsung.com> wrote:
> >
> > Right, I dropped one commit, which I found in other 'for_next' kernel tree
> > (the one from Russell King) before sending the pull request. What's wrong with
> > this approach?
>
> What did dropping the commit fix? Anything?
>
> DO NOT REBASE UNLESS YOU HAVE SERIOUSLY PRESSING REASONS!
>
> Why does this keep on coming up EVERY SINGLE RELEASE? Does nobody read my rants?
>
> A duplicate commit not a "seriously pressing reason". It may be reason
> for some introspection ("why did I and Russell end up applying the
> same patch and stepping on each others toes?") but it is not in itself
> at all a reason for rebasing.
>
> Reasons for rebasing include:
>
>   - "I am a complete moron, and I have terminally messed up my history
> with merges from random places to the point where it is completely
> unpullable"
>
>   - "There are commits that are so horribly broken in the history that
> I can't even revert them, because seeing them mentioned one more time
> will make me go blind"
>
> and the best one:
>
>   - "I never made my patches public in the first place, and I'll clean
> my ugly series up before posting them publicly for the first time".
>
> but that last one shouldn't happen just before sending it to me, it
> should happen a few weeks before sending to me so that linux-next has
> time to digest the beauty of the rebased series.
>
> The fact is, rebasing is a perfectly fine operation, but it's a fine
> operation that causes lots of problems if those commits have ever been
> public before. It means that linux-next cannot easily be compared to
> what I pull (which is why Stephen complains), but it also results in
> other developers not being able to trust your tree, and in the commits
> randomly changing and the testing base thus not being reliable any
> more (which is why I complain).

Ok, right. MY FAULT. I'm really sorry. I will never do it again.

Now, I want to repair what I broke. Do you want me to restore my tree to
the point before the rebase and send pull request again? The current tree
already appeared at next-20130703, so I wonder what would cause less harm
to others.

Best regards
-- 
Marek Szyprowski
Samsung R&D Institute Poland



^ permalink raw reply	[flat|nested] 6+ messages in thread

* [GIT PULL] DMA-mapping updates for v3.11
@ 2013-07-05 15:31 Marek Szyprowski
  0 siblings, 0 replies; 6+ messages in thread
From: Marek Szyprowski @ 2013-07-05 15:31 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-kernel, Marek Szyprowski

Hi Linus,

I'm really sorry for the rebased tree last time. I restored the tree
that was in linux next for a long time till 2nd July. I would like to
ask You for pulling fixes for ARM dma-mapping subsystem for v3.11.


The following changes since commit 9e895ace5d82df8929b16f58e9f515f6d54ab82d:

  Linux 3.10-rc7 (2013-06-22 09:47:31 -1000)

are available in the git repository at:

  git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git for-v3.11

for you to fetch changes up to 5b91a98c61abe914e6a80d7dc15e435c47ea0004:

  ARM: dma: Drop __GFP_COMP for iommu dma memory allocations (2013-06-28 15:14:29 +0200)

----------------------------------------------------------------
Ming Lei (1):
      ARM: DMA-mapping: mark all !DMA_TO_DEVICE pages in unmapping as clean

Richard Zhao (1):
      ARM: dma: Drop __GFP_COMP for iommu dma memory allocations

Will Deacon (2):
      ARM: dma-mapping: convert DMA direction into IOMMU protection attributes
      ARM: dma-mapping: NULLify dev->archdata.mapping pointer on detach

YoungJun Cho (1):
      ARM: dma-mapping: Get pages if the cpu_addr is out of atomic_pool

 arch/arm/mm/dma-mapping.c |   60 ++++++++++++++++++++++++++++++++++++---------
 1 file changed, 49 insertions(+), 11 deletions(-)

----------------------------------------------------------------

This pull request contains an important bugfixes and update for IOMMU
integration support for ARM architecture.

Thanks!

Best regards
Marek Szyprowski
Samsung Poland R&D Center

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2013-07-05 15:32 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-02  8:35 [GIT PULL] DMA-mapping updates for v3.11 Marek Szyprowski
2013-07-03  0:09 ` Stephen Rothwell
2013-07-03  7:58   ` Marek Szyprowski
2013-07-03 21:02     ` Linus Torvalds
2013-07-04  6:09       ` Marek Szyprowski
2013-07-05 15:31 Marek Szyprowski

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.