[GIT PULL] use generic pci_iomap on all architectures

[GIT PULL] use generic pci_iomap on all architectures

[Michael S. Tsirkin]

Linus, please pull the following changes for 3.3, thanks a lot!

These changes have been on linux-next for a while now.
They touch a lot of arches and have interdependencies, so merging
separately seems to make sense, I think.

The following changes since commit 805a6af8dba5dfdd35ec35dc52ec0122400b2610:

  Linux 3.2 (2012-01-04 15:55:44 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git for-linus

for you to fetch changes up to 193a667fba76b3df482cbf865228e26ee246e889:

  alpha: drop pci_iomap/pci_iounmap from pci-noop.c (2011-12-04 16:00:19 +0200)

----------------------------------------------------------------
lib: use generic pci_iomap on all architectures

Many architectures don't want to pull in iomap.c,
so they ended up duplicating pci_iomap from that file.
That function isn't trivial, and we are going to modify it
https://lkml.org/lkml/2011/11/14/183
so the duplication hurts.

This reduces the scope of the problem significantly,
by moving pci_iomap to a separate file and
referencing that from all architectures.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

----------------------------------------------------------------
Michael S. Tsirkin (16):
      lib: move GENERIC_IOMAP to lib/Kconfig
      lib: add GENERIC_PCI_IOMAP
      alpha: switch to GENERIC_PCI_IOMAP
      arm: switch to GENERIC_PCI_IOMAP
      microblaze: switch to GENERIC_PCI_IOMAP
      mips: switch to GENERIC_PCI_IOMAP
      parisc: switch to GENERIC_PCI_IOMAP
      powerpc: switch to GENERIC_PCI_IOMAP
      sh: switch to GENERIC_PCI_IOMAP
      sparc: switch to GENERIC_PCI_IOMAP
      tile: don't panic on iomap
      tile: switch to GENERIC_PCI_IOMAP
      frv: switch to GENERIC_PCI_IOMAP
      mn10300: add missing __iomap markers
      mn10300: switch to GENERIC_PCI_IOMAP
      alpha: drop pci_iomap/pci_iounmap from pci-noop.c

 arch/alpha/Kconfig                    |    5 +---
 arch/alpha/kernel/pci-noop.c          |   12 --------
 arch/alpha/kernel/pci.c               |   26 +-----------------
 arch/arm/Kconfig                      |    1 +
 arch/arm/include/asm/io.h             |    2 +-
 arch/arm/mm/iomap.c                   |   21 --------------
 arch/cris/Kconfig                     |    5 +---
 arch/frv/Kconfig                      |    1 +
 arch/frv/include/asm/io.h             |    2 +-
 arch/frv/mb93090-mb00/Makefile        |    2 +-
 arch/frv/mb93090-mb00/pci-iomap.c     |   29 --------------------
 arch/hexagon/Kconfig                  |    4 +--
 arch/ia64/Kconfig                     |    5 +---
 arch/m68k/Kconfig                     |    4 +--
 arch/microblaze/Kconfig               |    1 +
 arch/microblaze/pci/iomap.c           |   19 -------------
 arch/mips/Kconfig                     |    1 +
 arch/mips/lib/iomap-pci.c             |   26 ------------------
 arch/mn10300/Kconfig                  |    1 +
 arch/mn10300/include/asm/io.h         |   17 +++++------
 arch/mn10300/unit-asb2305/Makefile    |    2 +-
 arch/mn10300/unit-asb2305/pci-iomap.c |   31 ---------------------
 arch/openrisc/Kconfig                 |    3 --
 arch/parisc/Kconfig                   |    1 +
 arch/parisc/lib/iomap.c               |   23 ---------------
 arch/powerpc/Kconfig                  |    1 +
 arch/powerpc/kernel/iomap.c           |   19 -------------
 arch/powerpc/platforms/Kconfig        |    3 --
 arch/score/Kconfig                    |    4 +--
 arch/sh/Kconfig                       |    4 +--
 arch/sh/drivers/pci/pci.c             |   23 ---------------
 arch/sparc/Kconfig                    |    1 +
 arch/sparc/include/asm/io_32.h        |    2 +-
 arch/sparc/include/asm/io_64.h        |    2 +-
 arch/sparc/lib/iomap.c                |   23 ---------------
 arch/tile/Kconfig                     |    1 +
 arch/tile/include/asm/io.h            |    3 +-
 arch/tile/include/asm/pci.h           |    2 +-
 arch/tile/kernel/pci.c                |   21 --------------
 arch/unicore32/Kconfig                |    4 +--
 arch/x86/Kconfig                      |    4 +--
 include/asm-generic/io.h              |    4 +-
 include/asm-generic/iomap.h           |    9 ++----
 include/asm-generic/pci_iomap.h       |   25 +++++++++++++++++
 lib/Kconfig                           |    7 +++++
 lib/Makefile                          |    1 +
 lib/iomap.c                           |   38 +------------------------
 lib/pci_iomap.c                       |   48 +++++++++++++++++++++++++++++++++
 48 files changed, 124 insertions(+), 369 deletions(-)
 delete mode 100644 arch/frv/mb93090-mb00/pci-iomap.c
 delete mode 100644 arch/mn10300/unit-asb2305/pci-iomap.c
 create mode 100644 include/asm-generic/pci_iomap.h
 create mode 100644 lib/pci_iomap.c

Re: [GIT PULL] use generic pci_iomap on all architectures

[Stephen Rothwell]

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

Hi Michael,

[I am not *just* picking on you - others do this as well ...]

On Thu, 5 Jan 2012 16:58:36 +0200 "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> Linus, please pull the following changes for 3.3, thanks a lot!
> 
> These changes have been on linux-next for a while now.
> They touch a lot of arches and have interdependencies, so merging
> separately seems to make sense, I think.
> 
> The following changes since commit 805a6af8dba5dfdd35ec35dc52ec0122400b2610:
> 
>   Linux 3.2 (2012-01-04 15:55:44 -0800)

So why have you rebased this?  All this stuff in in linux-next based on
v3.2-rc3 since December 5 (and that version will be in linux-next today
as well unless you update your linux-next branch in the next sort while).

Is there something in v3.2 that interacts with this series of patches?
If so, then you had better delay your pull request and do more testing.
If not, then *don't rebase*.

(and if you do rebase, please make sure that what goes into linux-next is
the *same commits* (not just the same patches) as what Linus is merging)

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: [GIT PULL] use generic pci_iomap on all architectures

[Stephen Rothwell]

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

Hi Michael,

On Fri, 6 Jan 2012 08:31:41 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> [I am not *just* picking on you - others do this as well ...]
> 
> On Thu, 5 Jan 2012 16:58:36 +0200 "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >
> > Linus, please pull the following changes for 3.3, thanks a lot!
> > 
> > These changes have been on linux-next for a while now.
> > They touch a lot of arches and have interdependencies, so merging
> > separately seems to make sense, I think.
> > 
> > The following changes since commit 805a6af8dba5dfdd35ec35dc52ec0122400b2610:
> > 
> >   Linux 3.2 (2012-01-04 15:55:44 -0800)
> 
> So why have you rebased this?  All this stuff in in linux-next based on
> v3.2-rc3 since December 5 (and that version will be in linux-next today
> as well unless you update your linux-next branch in the next sort while).

OK, seems I was mistaken (and mislead by the above.  Your for-linus tag
just tags what is already in linux-next and based on v3.2-rc3 ...

Sorry about that.

So why does you pull request refer to "commit
805a6af8dba5dfdd35ec35dc52ec0122400b2610", I wonder?  Is that just what
"git request-pull" produced?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: [GIT PULL] use generic pci_iomap on all architectures

[Stephen Rothwell]

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

On Fri, 6 Jan 2012 08:39:16 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> So why does you pull request refer to "commit
> 805a6af8dba5dfdd35ec35dc52ec0122400b2610", I wonder?  Is that just what
> "git request-pull" produced?

I see, "git request-pull" just puts in whatever you specify on the
command line rather than the merge-base ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

Re: [GIT PULL] use generic pci_iomap on all architectures

[Geert Uytterhoeven]

On Thu, Jan 5, 2012 at 22:47, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Fri, 6 Jan 2012 08:39:16 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> So why does you pull request refer to "commit
>> 805a6af8dba5dfdd35ec35dc52ec0122400b2610", I wonder?  Is that just what
>> "git request-pull" produced?
>
> I see, "git request-pull" just puts in whatever you specify on the
> command line rather than the merge-base ...

Yep, I noticed the samething, for

|git request-pull v3.2
ra.kernel.org:/pub/scm/linux/kernel/git/geert/linux-m68k.git for-linus

while for-linus is based on v3.2-rc5, not v3.2.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [GIT PULL] use generic pci_iomap on all architectures

[Linus Torvalds]

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

On Thu, Jan 5, 2012 at 1:47 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Fri, 6 Jan 2012 08:39:16 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> So why does you pull request refer to "commit
>> 805a6af8dba5dfdd35ec35dc52ec0122400b2610", I wonder?  Is that just what
>> "git request-pull" produced?
>
> I see, "git request-pull" just puts in whatever you specify on the
> command line rather than the merge-base ...

.. and that is a fairly silly misfeature, since it makes the "since
commit xyz" largely meaningless.

I suspect we really should make "git request-pull" show the merge
base(s) as the "since commit", because that way the output of git
request-pull is "stable", and doesn't depend on what particular random
state you've synced up to since.

Junio, I think the patch would be as simple as the attached - totally
untested - one-liner? Comments?

                            Linus

[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 486 bytes --]

 git-request-pull.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/git-request-pull.sh b/git-request-pull.sh
index d7ba1178ae75..64960d65a1c2 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -96,7 +96,7 @@ git show -s --format='The following changes since commit %H:
   %s (%ci)
 
 are available in the git repository at:
-' $baserev &&
+' $merge_base &&
 echo "  $url${ref+ $ref}" &&
 git show -s --format='
 for you to fetch changes up to %H:

Re: [GIT PULL] use generic pci_iomap on all architectures

[Linus Torvalds]

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

On Thu, Jan 5, 2012 at 1:47 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Fri, 6 Jan 2012 08:39:16 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> So why does you pull request refer to "commit
>> 805a6af8dba5dfdd35ec35dc52ec0122400b2610", I wonder?  Is that just what
>> "git request-pull" produced?
>
> I see, "git request-pull" just puts in whatever you specify on the
> command line rather than the merge-base ...

.. and that is a fairly silly misfeature, since it makes the "since
commit xyz" largely meaningless.

I suspect we really should make "git request-pull" show the merge
base(s) as the "since commit", because that way the output of git
request-pull is "stable", and doesn't depend on what particular random
state you've synced up to since.

Junio, I think the patch would be as simple as the attached - totally
untested - one-liner? Comments?

                            Linus

[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 486 bytes --]

 git-request-pull.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/git-request-pull.sh b/git-request-pull.sh
index d7ba1178ae75..64960d65a1c2 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -96,7 +96,7 @@ git show -s --format='The following changes since commit %H:
   %s (%ci)
 
 are available in the git repository at:
-' $baserev &&
+' $merge_base &&
 echo "  $url${ref+ $ref}" &&
 git show -s --format='
 for you to fetch changes up to %H:

Re: [GIT PULL] use generic pci_iomap on all architectures

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Thu, Jan 5, 2012 at 1:47 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> On Fri, 6 Jan 2012 08:39:16 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>> So why does you pull request refer to "commit
>>> 805a6af8dba5dfdd35ec35dc52ec0122400b2610", I wonder?  Is that just what
>>> "git request-pull" produced?
>>
>> I see, "git request-pull" just puts in whatever you specify on the
>> command line rather than the merge-base ...
>
> .. and that is a fairly silly misfeature, since it makes the "since
> commit xyz" largely meaningless.
>
> I suspect we really should make "git request-pull" show the merge
> base(s) as the "since commit", because that way the output of git
> request-pull is "stable", and doesn't depend on what particular random
> state you've synced up to since.
>
> Junio, I think the patch would be as simple as the attached - totally
> untested - one-liner? Comments?

I think it makes sense.

We use whatever garbage the user gave us (e.g. "origin/linus" which may
have been updated since the topic forked and be made irrelevant) only to
figure out where the history forked, and once we find that out we
consistently use the fork-point which has some meaning.

The parameter to "git shortlog" that appears later should also be updated
to match this, by the way, even though that should not affect the outcome
in any way.

I am however not sure what would happen when there are more than one merge
bases. I guess those who throw pull requests are not supposed to be doing
merges in reverse direction, so it should not matter ;-)

 git-request-pull.sh |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/git-request-pull.sh b/git-request-pull.sh
index d7ba117..38b68bb 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -96,7 +96,7 @@ git show -s --format='The following changes since commit %H:
   %s (%ci)
 
 are available in the git repository at:
-' $baserev &&
+' $merge_base &&
 echo "  $url${ref+ $ref}" &&
 git show -s --format='
 for you to fetch changes up to %H:
@@ -124,7 +124,7 @@ then
 	echo "----------------------------------------------------------------"
 fi &&
 
-git shortlog ^$baserev $headrev &&
+git shortlog $merge_base..$headrev &&
 git diff -M --stat --summary $patch $merge_base..$headrev || status=1
 
 if test -z "$ref"

Re: [GIT PULL] use generic pci_iomap on all architectures

[Linus Torvalds]

On Tue, Jan 10, 2012 at 6:38 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> The parameter to "git shortlog" that appears later should also be updated
> to match this, by the way, even though that should not affect the outcome
> in any way.

No, don't do that part.

Why?

Remember: there can be *multiple* merge bases. The expression

    git shortlog ^$baserev $headrev

always works, but changing "baserev" to "merge_base" will suddenly
break for the multiple merge-bases case.

> I am however not sure what would happen when there are more than one merge
> bases. I guess those who throw pull requests are not supposed to be doing
> merges in reverse direction, so it should not matter ;-)

The other cases don't really care. For them, "show one merge-base" is
fine, and they are "end-point" operations (like "diff") that really
cannot handle a set of commits anyway.

But for "git shortlog", switching to using the merge base would
actually start showing commits that shouldn't be shown. It's
fundamentally a set operator, and does the right thing in the presense
of multiple merge-bases (which "diff" and "since commit XYZ" are
clearly not set operators, although arguably you could try to show all
merge bases for the "since" case).

                       Linus