All of lore.kernel.org
 help / color / mirror / Atom feed
From: thomas.petazzoni@free-electrons.com (Thomas Petazzoni)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC v1 01/16] lib: devres: don't enclose pcim_*() functions in CONFIG_HAS_IOPORT
Date: Tue, 11 Dec 2012 17:30:13 +0100	[thread overview]
Message-ID: <20121211173013.0ceea196@skate> (raw)
In-Reply-To: <201212111615.03262.arnd@arndb.de>

Dear Arnd Bergmann,

On Tue, 11 Dec 2012 16:15:02 +0000, Arnd Bergmann wrote:

> What you describe here are probable two bugs, and we should fix both:
> 
> * ARCH_VEXPRESS should not select NO_IOPORT. It's generally wrong
>   to select this in combination with ARCH_MULTIPLATFORM, when some
>   of the other platforms you may enable actually have IOPORT mapping
>   support.

Indeed, but I guess the "select NO_IOPORT" on vexpress is here for a
reason, no?

That said, unless I don't understand what IOPORTs are, I don't think my
platform has any of them, so why should I "select HAVE_IOPORT" ?

> * We should not unconditionally select ARCH_VEXPRESS from ARCH_MULTIPLATFORM.
>   There is no reason why we would enable that platform for building
>   a kernel that runs on only one other platform.

This one is already being worked on by Fabio Estevam, see [PATCH v2]
ARM: Kconfig: Do not force selection of ARCH_VEXPRESS by ARCH_MULTI_V7.

> > I'm not sure which devm_pci_iomap() you're referring to since my patch
> > makes only the pcim_iomap_table(), pcim_iomap(), pcim_iounmap(),
> > pcim_iomap_regions(), pcim_iomap_regions_request_all() and
> > pcim_iounmap_regions() available under CONFIG_PCI instead of CONFIG_PCI
> > && CONFIG_HAS_IOPORT.
> 
> Sorry, I meant pcim_iomap.
> 
> > So maybe you were referring to pcim_iomap(). I haven't checked in
> > details, but I guess it builds because ioport_map() is implemented in
> > arch/arm/mm/iomap.c.
> 
> Right. If an ioport_map function is provided for a given platform,
> we should also set HAVE_IOPORT and vice versa. This is probably
> fallout of the io.h conversion for multiplatform.

arch/arm/mm/iomap.c is unconditionally compiled in all ARM kernels. And
in this file, ioport_map() and ioport_unmap() are implement as soon as
__io is defined. And basically, in arch/arm/include/asm/io.h, __io is
defined for all platforms, except maybe on some platforms having their
own mach/io.h file, but those are quite limited in number (ebsa110, rpc,
at91, s3c24xx, pxa, omap1, footbridge and ixp4xx). So if __io is
defined, says on VEXPRESS, why does it "select NO_IOPORT" ? Essentially
all ARM platforms should select HAVE_IOPORT, except the few ones that
don't define __io. Correct?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org,
	Jason Cooper <jason@lakedaemon.net>, Andrew Lunn <andrew@lunn.ch>,
	Gregory Clement <gregory.clement@free-electrons.com>,
	Lior Amsalem <alior@marvell.com>,
	Yehuda Yitschak <yehuday@marvell.com>,
	Tawfik Bayouk <tawfik@marvell.com>,
	Stephen Warren <swarren@wwwdotorg.org>,
	Thierry Reding <thierry.reding@avionic-design.de>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	linux-kernel@vger.kernel.org,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	"Eran Ben-Avi" <benavi@marvell.com>,
	Nadav Haklai <nadavh@marvell.com>,
	Maen Suleiman <maen@marvell.com>,
	Shadi Ammouri <shadi@marvell.com>,
	Yinghai Lu <yinghai@kernel.org>
Subject: Re: [RFC v1 01/16] lib: devres: don't enclose pcim_*() functions in CONFIG_HAS_IOPORT
Date: Tue, 11 Dec 2012 17:30:13 +0100	[thread overview]
Message-ID: <20121211173013.0ceea196@skate> (raw)
In-Reply-To: <201212111615.03262.arnd@arndb.de>

Dear Arnd Bergmann,

On Tue, 11 Dec 2012 16:15:02 +0000, Arnd Bergmann wrote:

> What you describe here are probable two bugs, and we should fix both:
> 
> * ARCH_VEXPRESS should not select NO_IOPORT. It's generally wrong
>   to select this in combination with ARCH_MULTIPLATFORM, when some
>   of the other platforms you may enable actually have IOPORT mapping
>   support.

Indeed, but I guess the "select NO_IOPORT" on vexpress is here for a
reason, no?

That said, unless I don't understand what IOPORTs are, I don't think my
platform has any of them, so why should I "select HAVE_IOPORT" ?

> * We should not unconditionally select ARCH_VEXPRESS from ARCH_MULTIPLATFORM.
>   There is no reason why we would enable that platform for building
>   a kernel that runs on only one other platform.

This one is already being worked on by Fabio Estevam, see [PATCH v2]
ARM: Kconfig: Do not force selection of ARCH_VEXPRESS by ARCH_MULTI_V7.

> > I'm not sure which devm_pci_iomap() you're referring to since my patch
> > makes only the pcim_iomap_table(), pcim_iomap(), pcim_iounmap(),
> > pcim_iomap_regions(), pcim_iomap_regions_request_all() and
> > pcim_iounmap_regions() available under CONFIG_PCI instead of CONFIG_PCI
> > && CONFIG_HAS_IOPORT.
> 
> Sorry, I meant pcim_iomap.
> 
> > So maybe you were referring to pcim_iomap(). I haven't checked in
> > details, but I guess it builds because ioport_map() is implemented in
> > arch/arm/mm/iomap.c.
> 
> Right. If an ioport_map function is provided for a given platform,
> we should also set HAVE_IOPORT and vice versa. This is probably
> fallout of the io.h conversion for multiplatform.

arch/arm/mm/iomap.c is unconditionally compiled in all ARM kernels. And
in this file, ioport_map() and ioport_unmap() are implement as soon as
__io is defined. And basically, in arch/arm/include/asm/io.h, __io is
defined for all platforms, except maybe on some platforms having their
own mach/io.h file, but those are quite limited in number (ebsa110, rpc,
at91, s3c24xx, pxa, omap1, footbridge and ixp4xx). So if __io is
defined, says on VEXPRESS, why does it "select NO_IOPORT" ? Essentially
all ARM platforms should select HAVE_IOPORT, except the few ones that
don't define __io. Correct?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  parent reply	other threads:[~2012-12-11 16:30 UTC|newest]

Thread overview: 133+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-07 22:04 [RFC v1] PCIe support for the Armada 370 and Armada XP SoCs Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 01/16] lib: devres: don't enclose pcim_*() functions in CONFIG_HAS_IOPORT Thomas Petazzoni
2012-12-07 22:04   ` Thomas Petazzoni
2012-12-11 10:43   ` Arnd Bergmann
2012-12-11 10:43     ` Arnd Bergmann
2012-12-11 16:03     ` Thomas Petazzoni
2012-12-11 16:03       ` Thomas Petazzoni
2012-12-11 16:15       ` Arnd Bergmann
2012-12-11 16:15         ` Arnd Bergmann
2012-12-11 16:23         ` Russell King - ARM Linux
2012-12-11 16:23           ` Russell King - ARM Linux
2012-12-11 16:38           ` Thomas Petazzoni
2012-12-11 16:38             ` Thomas Petazzoni
2012-12-11 16:50             ` Russell King - ARM Linux
2012-12-11 16:50               ` Russell King - ARM Linux
2012-12-11 17:29             ` Alan Cox
2012-12-11 17:29               ` Alan Cox
2012-12-11 22:20               ` Arnd Bergmann
2012-12-11 22:20                 ` Arnd Bergmann
2012-12-11 22:34           ` Arnd Bergmann
2012-12-11 22:34             ` Arnd Bergmann
2012-12-11 16:30         ` Thomas Petazzoni [this message]
2012-12-11 16:30           ` Thomas Petazzoni
2012-12-11 16:46           ` Russell King - ARM Linux
2012-12-11 16:46             ` Russell King - ARM Linux
2012-12-11 17:32             ` Alan Cox
2012-12-11 17:32               ` Alan Cox
2012-12-11 22:28               ` Arnd Bergmann
2012-12-11 22:28                 ` Arnd Bergmann
2012-12-11 16:55           ` Russell King - ARM Linux
2012-12-11 16:55             ` Russell King - ARM Linux
2012-12-11 16:26     ` Russell King - ARM Linux
2012-12-11 16:26       ` Russell King - ARM Linux
2012-12-11 17:16       ` Alan Cox
2012-12-11 17:16         ` Alan Cox
2012-12-11 17:34         ` Russell King - ARM Linux
2012-12-11 17:34           ` Russell King - ARM Linux
2012-12-11 17:45           ` Alan Cox
2012-12-11 17:45             ` Alan Cox
2012-12-11 17:51             ` Russell King - ARM Linux
2012-12-11 17:51               ` Russell King - ARM Linux
2012-12-07 22:04 ` [RFC v1 02/16] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370 Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 03/16] arm: plat-orion: introduce WIN_CTRL_ENABLE in address mapping code Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 04/16] arm: plat-orion: refactor the orion_disable_wins() function Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 05/16] arm: plat-orion: introduce orion_{alloc, free}_cpu_win() functions Thomas Petazzoni
2012-12-08 11:53   ` [RFC v1 05/16] arm: plat-orion: introduce orion_{alloc,free}_cpu_win() functions Andrew Lunn
2012-12-08 12:15     ` Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 06/16] arm: mvebu: add functions to alloc/free PCIe decoding windows Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 07/16] arm: plat-orion: make common PCIe code usable on mvebu Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 08/16] arm: mvebu: the core PCIe driver Thomas Petazzoni
2012-12-10  8:28   ` Andrew Lunn
2012-12-10  8:45     ` Thomas Petazzoni
2012-12-10 19:08   ` Jason Gunthorpe
2012-12-11 10:56   ` Arnd Bergmann
2012-12-12 15:58     ` Thomas Petazzoni
2012-12-12 21:51       ` Jason Gunthorpe
2012-12-13 14:58         ` Arnd Bergmann
2012-12-13 17:40           ` Jason Gunthorpe
2012-12-13 19:09             ` Thomas Petazzoni
2012-12-14 19:34         ` Rob Herring
2012-12-13 12:19       ` Arnd Bergmann
2012-12-13 17:54         ` Jason Gunthorpe
2012-12-13 19:12           ` Thomas Petazzoni
2012-12-13 21:46             ` Arnd Bergmann
2012-12-13 22:27               ` Jason Gunthorpe
2012-12-07 22:04 ` [RFC v1 09/16] arm: mvebu: PCIe support is now available on mvebu Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 10/16] arm: mvebu: add PCIe Device Tree informations for Armada 370 Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 11/16] arm: mvebu: add PCIe Device Tree informations for Armada XP Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 12/16] arm: mvebu: PCIe Device Tree informations for OpenBlocks AX3-4 Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 13/16] arm: mvebu: PCIe Device Tree informations for Armada XP DB Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 14/16] arm: mvebu: PCIe Device Tree informations for Armada 370 Mirabox Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 15/16] arm: mvebu: PCIe Device Tree informations for Armada 370 DB Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 16/16] arm: mvebu: update defconfig with PCI and USB support Thomas Petazzoni
2012-12-07 23:33 ` [RFC v1] PCIe support for the Armada 370 and Armada XP SoCs Jason Gunthorpe
2012-12-10 17:52   ` Stephen Warren
2012-12-10 18:05     ` Thomas Petazzoni
2012-12-10 18:16       ` Stephen Warren
2012-12-10 18:59         ` Thomas Petazzoni
2012-12-10 19:07           ` Jason Gunthorpe
2012-12-10 20:08           ` Stephen Warren
2012-12-10 18:44     ` Jason Gunthorpe
2012-12-10 19:03       ` Thomas Petazzoni
2012-12-10 19:18         ` Jason Gunthorpe
2012-12-12 16:04           ` Thomas Petazzoni
2012-12-12 20:09             ` Jason Gunthorpe
2012-12-16 13:02               ` Thierry Reding
2012-12-11  7:52     ` Thierry Reding
2012-12-11 21:21       ` Stephen Warren
2012-12-12 20:34         ` Thierry Reding
2012-12-12 22:30           ` Stephen Warren
2012-12-13  7:03             ` Thierry Reding
2012-12-13  8:04               ` Jason Gunthorpe
2012-12-13  8:23                 ` Thierry Reding
2012-12-13 18:12                   ` Stephen Warren
2012-12-13 20:42                     ` Thierry Reding
2012-12-13 20:47                       ` Jason Gunthorpe
2012-12-13 21:16                         ` Thierry Reding
2012-12-14 10:05                         ` Thierry Reding
2012-12-14 15:10                       ` Thierry Reding
2012-12-14 17:27                         ` Jason Gunthorpe
2012-12-16 12:33                           ` Thierry Reding
2012-12-17 18:29                             ` Jason Gunthorpe
2012-12-17 19:41                               ` Thierry Reding
2012-12-18  2:10                                 ` Stephen Warren
2012-12-18  2:51                                   ` Jason Gunthorpe
2012-12-18 17:03                                     ` Stephen Warren
2012-12-20 15:32                                       ` Thierry Reding
2012-12-21 13:38                                         ` Jay Agarwal
2012-12-21 14:03                                           ` Thierry Reding
2012-12-22 14:50                                         ` Thomas Petazzoni
2012-12-28 21:06                                           ` Thierry Reding
2012-12-28 21:16                                             ` Thomas Petazzoni
2012-12-28 23:49                                               ` Stephen Warren
2012-12-29  8:09                                                 ` Thomas Petazzoni
2012-12-31 16:40                                                   ` Stephen Warren
2012-12-29  9:33                                                 ` Thierry Reding
2012-12-31 16:44                                                   ` Stephen Warren
2013-01-02 20:09                                                   ` Jason Gunthorpe
2013-01-03 14:20                                                     ` Thierry Reding
2012-12-28 23:51                                         ` Stephen Warren
2012-12-18  7:32                                   ` Thierry Reding
2013-01-03 14:39 ` Thierry Reding
2013-01-03 14:39   ` Thierry Reding
2013-01-03 15:00   ` Bjorn Helgaas
2013-01-03 15:00     ` Bjorn Helgaas
2013-01-03 15:11     ` Thierry Reding
2013-01-03 15:11       ` Thierry Reding
2013-01-03 15:09   ` Thomas Petazzoni
2013-01-03 15:09     ` Thomas Petazzoni
2013-01-03 15:56   ` Arnd Bergmann
2013-01-03 15:56     ` Arnd Bergmann
2013-01-03 16:01     ` Thierry Reding
2013-01-03 16:01       ` Thierry Reding

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20121211173013.0ceea196@skate \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.