On Wednesday, March 06, 2013 5:26 PM, Thomas Petazzoni wrote:
>
> Dear Jingoo Han,
>
> On Wed, 06 Mar 2013 06:28:08 + (GMT), Jingoo Han wrote:
>
> > Sorry, I did not know that you submitted the patch.
>
> No problem, I'm happy to have one less patch to carry in my PCIe patch
> set :)
Dear Jingoo Han,
On Wed, 06 Mar 2013 06:28:08 + (GMT), Jingoo Han wrote:
> Sorry, I did not know that you submitted the patch.
No problem, I'm happy to have one less patch to carry in my PCIe patch
set :)
> Like you, I am developing PCIe Host driver.
Just curious, do you already have some
Dear Jingoo Han,
On Wed, 06 Mar 2013 06:28:08 + (GMT), Jingoo Han wrote:
Sorry, I did not know that you submitted the patch.
No problem, I'm happy to have one less patch to carry in my PCIe patch
set :)
Like you, I am developing PCIe Host driver.
Just curious, do you already have some
On Wednesday, March 06, 2013 5:26 PM, Thomas Petazzoni wrote:
Dear Jingoo Han,
On Wed, 06 Mar 2013 06:28:08 + (GMT), Jingoo Han wrote:
Sorry, I did not know that you submitted the patch.
No problem, I'm happy to have one less patch to carry in my PCIe patch
set :)
Thank you :)
On Tuesday, March 05, 2013 5:30 AM, Arnd Bergmann wrote:
>
> On Monday 04 March 2013, Thomas Petazzoni wrote:
> > FWIW, a patch that is doing what I was initially proposing has been
> > merged for 3.9, and it doesn't contain the
> > IS_ENABLED(CONFIG_HAS_IOPORT) test you were proposing (and which
On Tuesday, March 05, 2013 5:30 AM, Arnd Bergmann wrote:
On Monday 04 March 2013, Thomas Petazzoni wrote:
FWIW, a patch that is doing what I was initially proposing has been
merged for 3.9, and it doesn't contain the
IS_ENABLED(CONFIG_HAS_IOPORT) test you were proposing (and which I
On Monday 04 March 2013, Thomas Petazzoni wrote:
> FWIW, a patch that is doing what I was initially proposing has been
> merged for 3.9, and it doesn't contain the
> IS_ENABLED(CONFIG_HAS_IOPORT) test you were proposing (and which I
> think was correct). See:
>
> commit
Dear Arnd Bergmann,
On Tue, 12 Feb 2013 22:36:37 +, Arnd Bergmann wrote:
> > I have the feeling that the problem is more complex than that. My
> > understanding is that the pcim_iomap_regions() function used by
> > drivers/ata/libata-sff.c can perfectly be used to map memory BARs, and
> >
Dear Arnd Bergmann,
On Tue, 12 Feb 2013 22:36:37 +, Arnd Bergmann wrote:
I have the feeling that the problem is more complex than that. My
understanding is that the pcim_iomap_regions() function used by
drivers/ata/libata-sff.c can perfectly be used to map memory BARs, and
not
On Monday 04 March 2013, Thomas Petazzoni wrote:
FWIW, a patch that is doing what I was initially proposing has been
merged for 3.9, and it doesn't contain the
IS_ENABLED(CONFIG_HAS_IOPORT) test you were proposing (and which I
think was correct). See:
commit
On Tuesday 12 February 2013, Thomas Petazzoni wrote:
> > Any driver that requires a
> > linear mapping of I/O ports to __iomem pointers must depend
> > CONFIG_HAS_IOPORT with the current definition of that symbol (as
> > mentioned before, we should really rename that to
> > CONFIG_HAS_IOPORT_MAP).
Dear Arnd Bergmann,
On Tue, 12 Feb 2013 18:00:48 +, Arnd Bergmann wrote:
> On Tuesday 12 February 2013, Thomas Petazzoni wrote:
> > The pcim_*() functions are used by the libata-sff subsystem, and
> > this subsystem is used for many SATA drivers on ARM platforms that
> > do not necessarily
On Tuesday 12 February 2013, Thomas Petazzoni wrote:
> The pcim_*() functions are used by the libata-sff subsystem, and this
> subsystem is used for many SATA drivers on ARM platforms that do not
> necessarily have I/O ports.
>
> Signed-off-by: Thomas Petazzoni
> Cc: Paul Gortmaker
> Cc: Jesse
The pcim_*() functions are used by the libata-sff subsystem, and this
subsystem is used for many SATA drivers on ARM platforms that do not
necessarily have I/O ports.
Signed-off-by: Thomas Petazzoni
Cc: Paul Gortmaker
Cc: Jesse Barnes
Cc: Yinghai Lu
Cc: linux-kernel@vger.kernel.org
---
The pcim_*() functions are used by the libata-sff subsystem, and this
subsystem is used for many SATA drivers on ARM platforms that do not
necessarily have I/O ports.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Paul Gortmaker paul.gortma...@windriver.com
Cc: Jesse
On Tuesday 12 February 2013, Thomas Petazzoni wrote:
The pcim_*() functions are used by the libata-sff subsystem, and this
subsystem is used for many SATA drivers on ARM platforms that do not
necessarily have I/O ports.
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc:
Dear Arnd Bergmann,
On Tue, 12 Feb 2013 18:00:48 +, Arnd Bergmann wrote:
On Tuesday 12 February 2013, Thomas Petazzoni wrote:
The pcim_*() functions are used by the libata-sff subsystem, and
this subsystem is used for many SATA drivers on ARM platforms that
do not necessarily have I/O
On Tuesday 12 February 2013, Thomas Petazzoni wrote:
Any driver that requires a
linear mapping of I/O ports to __iomem pointers must depend
CONFIG_HAS_IOPORT with the current definition of that symbol (as
mentioned before, we should really rename that to
CONFIG_HAS_IOPORT_MAP). Having
18 matches
Mail list logo
