On Thu, 2015-07-09 at 03:40 +0200, Luis R. Rodriguez wrote:
> On Tue, Jul 07, 2015 at 05:10:58PM -0600, Toshi Kani wrote:
> > On Tue, 2015-07-07 at 18:07 +0200, Luis R. Rodriguez wrote:
> > > On Tue, Jul 07, 2015 at 11:13:30AM +0100, Russell King - ARM
> > > Linux
> > > wrote:
> > :
> > > > On
On Mon, Jun 22, 2015 at 04:24:27AM -0400, Dan Williams wrote:
> diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h
> index d8f8622fa044..4789b1cec313 100644
> --- a/include/asm-generic/iomap.h
> +++ b/include/asm-generic/iomap.h
> @@ -62,14 +62,6 @@ extern void __iomem
On Mon, Jun 22, 2015 at 04:24:27AM -0400, Dan Williams wrote:
diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h
index d8f8622fa044..4789b1cec313 100644
--- a/include/asm-generic/iomap.h
+++ b/include/asm-generic/iomap.h
@@ -62,14 +62,6 @@ extern void __iomem
On Thu, 2015-07-09 at 03:40 +0200, Luis R. Rodriguez wrote:
On Tue, Jul 07, 2015 at 05:10:58PM -0600, Toshi Kani wrote:
On Tue, 2015-07-07 at 18:07 +0200, Luis R. Rodriguez wrote:
On Tue, Jul 07, 2015 at 11:13:30AM +0100, Russell King - ARM
Linux
wrote:
:
On ARM, we
On Tue, Jul 07, 2015 at 05:10:58PM -0600, Toshi Kani wrote:
> On Tue, 2015-07-07 at 18:07 +0200, Luis R. Rodriguez wrote:
> > On Tue, Jul 07, 2015 at 11:13:30AM +0100, Russell King - ARM Linux
> > wrote:
> :
> > > On ARM, we (probably) have a lot of cases where ioremap() is used
> > > multiple
On Tue, Jul 07, 2015 at 05:10:58PM -0600, Toshi Kani wrote:
On Tue, 2015-07-07 at 18:07 +0200, Luis R. Rodriguez wrote:
On Tue, Jul 07, 2015 at 11:13:30AM +0100, Russell King - ARM Linux
wrote:
:
On ARM, we (probably) have a lot of cases where ioremap() is used
multiple
times
On Tue, 2015-07-07 at 18:07 +0200, Luis R. Rodriguez wrote:
> On Tue, Jul 07, 2015 at 11:13:30AM +0100, Russell King - ARM Linux
> wrote:
:
> > On ARM, we (probably) have a lot of cases where ioremap() is used
> > multiple
> > times for the same physical address space, so we shouldn't rule out
On Tue, Jul 07, 2015 at 11:13:30AM +0100, Russell King - ARM Linux wrote:
> On Tue, Jul 07, 2015 at 11:50:12AM +0200, Luis R. Rodriguez wrote:
> > mcgrof@ergon ~/linux-next (git::kill-mtrr)$ git grep ioremap_nocache
> > drivers/| wc -l
> > 359
>
> Yes, it's because we have:
> (a) LDD telling
On Tue, Jul 7, 2015 at 12:13 PM, Russell King - ARM Linux
wrote:
> Another issue is... the use of memcpy()/memset() directly on memory
> returned from ioremap*(). The pmem driver does this. This fails sparse
> checks. However, years ago, x86 invented the memcpy_fromio()/memcpy_toio()
>
On Tue, Jul 07, 2015 at 11:50:12AM +0200, Luis R. Rodriguez wrote:
> mcgrof@ergon ~/linux-next (git::kill-mtrr)$ git grep ioremap_nocache
> drivers/| wc -l
> 359
Yes, it's because we have:
(a) LDD telling people they should be using ioremap_nocache() for mapping
devices.
(b) We have
On Wed, Jul 01, 2015 at 09:28:28AM +0200, Christoph Hellwig wrote:
> On Wed, Jul 01, 2015 at 09:19:29AM +0200, Geert Uytterhoeven wrote:
> > >> So it would be the responsibility of the caller to fall back from
> > >> ioremap(..., CACHED) to ioremap(..., UNCACHED)?
> > >> I.e. all drivers using it
On Tue, Jul 07, 2015 at 11:13:30AM +0100, Russell King - ARM Linux wrote:
On Tue, Jul 07, 2015 at 11:50:12AM +0200, Luis R. Rodriguez wrote:
mcgrof@ergon ~/linux-next (git::kill-mtrr)$ git grep ioremap_nocache
drivers/| wc -l
359
Yes, it's because we have:
(a) LDD telling people they
On Tue, 2015-07-07 at 18:07 +0200, Luis R. Rodriguez wrote:
On Tue, Jul 07, 2015 at 11:13:30AM +0100, Russell King - ARM Linux
wrote:
:
On ARM, we (probably) have a lot of cases where ioremap() is used
multiple
times for the same physical address space, so we shouldn't rule out
On Tue, Jul 7, 2015 at 12:13 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
Another issue is... the use of memcpy()/memset() directly on memory
returned from ioremap*(). The pmem driver does this. This fails sparse
checks. However, years ago, x86 invented the
On Wed, Jul 01, 2015 at 09:28:28AM +0200, Christoph Hellwig wrote:
On Wed, Jul 01, 2015 at 09:19:29AM +0200, Geert Uytterhoeven wrote:
So it would be the responsibility of the caller to fall back from
ioremap(..., CACHED) to ioremap(..., UNCACHED)?
I.e. all drivers using it should be
On Tue, Jul 07, 2015 at 11:50:12AM +0200, Luis R. Rodriguez wrote:
mcgrof@ergon ~/linux-next (git::kill-mtrr)$ git grep ioremap_nocache
drivers/| wc -l
359
Yes, it's because we have:
(a) LDD telling people they should be using ioremap_nocache() for mapping
devices.
(b) We have
On Wed, Jul 1, 2015 at 1:09 AM, Russell King - ARM Linux
wrote:
> On Wed, Jul 01, 2015 at 08:55:57AM +0200, Geert Uytterhoeven wrote:
>> On Wed, Jul 1, 2015 at 8:23 AM, Christoph Hellwig wrote:
>> >> One useful feature of the ifdef mess as implemented in the patch is
>> >> that you could test
On Wed, Jul 01, 2015 at 08:55:57AM +0200, Geert Uytterhoeven wrote:
> On Wed, Jul 1, 2015 at 8:23 AM, Christoph Hellwig wrote:
> >> One useful feature of the ifdef mess as implemented in the patch is
> >> that you could test for whether ioremap_cache() is actually
> >> implemented or falls back
On Wed, Jul 01, 2015 at 09:19:29AM +0200, Geert Uytterhoeven wrote:
> >> So it would be the responsibility of the caller to fall back from
> >> ioremap(..., CACHED) to ioremap(..., UNCACHED)?
> >> I.e. all drivers using it should be changed...
> >
> > All of the zero users we currently have will
On Wed, Jul 1, 2015 at 8:59 AM, Christoph Hellwig wrote:
> On Wed, Jul 01, 2015 at 08:55:57AM +0200, Geert Uytterhoeven wrote:
>> >
>> > I think doing this at runtime might be a better idea. E.g. a
>> > ioremap_flags with the CACHED argument will return -EOPNOTSUP unless
>> > actually
On Wed, Jul 01, 2015 at 08:55:57AM +0200, Geert Uytterhoeven wrote:
> >
> > I think doing this at runtime might be a better idea. E.g. a
> > ioremap_flags with the CACHED argument will return -EOPNOTSUP unless
> > actually implemented. On various architectures different CPUs or
> > boards will
On Wed, Jul 1, 2015 at 8:23 AM, Christoph Hellwig wrote:
>> One useful feature of the ifdef mess as implemented in the patch is
>> that you could test for whether ioremap_cache() is actually
>> implemented or falls back to default ioremap(). I think for
>> completeness archs should publish an
On Tue, Jun 30, 2015 at 03:57:16PM -0700, Dan Williams wrote:
> > void __iomem *ioremap_flags(resource_size_t offset, unsigned long size,
> > unsigned long prot_val, unsigned flags);
>
> Doesn't 'flags' imply a specific 'prot_val'?
Looks like the values are arch specific.
On Wed, Jul 1, 2015 at 1:09 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Wed, Jul 01, 2015 at 08:55:57AM +0200, Geert Uytterhoeven wrote:
On Wed, Jul 1, 2015 at 8:23 AM, Christoph Hellwig h...@lst.de wrote:
One useful feature of the ifdef mess as implemented in the patch is
On Tue, Jun 30, 2015 at 03:57:16PM -0700, Dan Williams wrote:
void __iomem *ioremap_flags(resource_size_t offset, unsigned long size,
unsigned long prot_val, unsigned flags);
Doesn't 'flags' imply a specific 'prot_val'?
Looks like the values are arch specific. So
On Wed, Jul 01, 2015 at 08:55:57AM +0200, Geert Uytterhoeven wrote:
I think doing this at runtime might be a better idea. E.g. a
ioremap_flags with the CACHED argument will return -EOPNOTSUP unless
actually implemented. On various architectures different CPUs or
boards will have
On Wed, Jul 1, 2015 at 8:59 AM, Christoph Hellwig h...@lst.de wrote:
On Wed, Jul 01, 2015 at 08:55:57AM +0200, Geert Uytterhoeven wrote:
I think doing this at runtime might be a better idea. E.g. a
ioremap_flags with the CACHED argument will return -EOPNOTSUP unless
actually implemented.
On Wed, Jul 01, 2015 at 09:19:29AM +0200, Geert Uytterhoeven wrote:
So it would be the responsibility of the caller to fall back from
ioremap(..., CACHED) to ioremap(..., UNCACHED)?
I.e. all drivers using it should be changed...
All of the zero users we currently have will need to be
On Wed, Jul 01, 2015 at 08:55:57AM +0200, Geert Uytterhoeven wrote:
On Wed, Jul 1, 2015 at 8:23 AM, Christoph Hellwig h...@lst.de wrote:
One useful feature of the ifdef mess as implemented in the patch is
that you could test for whether ioremap_cache() is actually
implemented or falls back
On Wed, Jul 1, 2015 at 8:23 AM, Christoph Hellwig h...@lst.de wrote:
One useful feature of the ifdef mess as implemented in the patch is
that you could test for whether ioremap_cache() is actually
implemented or falls back to default ioremap(). I think for
completeness archs should publish an
On Mon, Jun 22, 2015 at 9:10 AM, Christoph Hellwig wrote:
> On Mon, Jun 22, 2015 at 04:24:27AM -0400, Dan Williams wrote:
>> Some archs define the first parameter to ioremap() as unsigned long,
>> while the balance define it as resource_size_t. Unify on
>> resource_size_t to enable passing
On Mon, Jun 22, 2015 at 9:10 AM, Christoph Hellwig h...@lst.de wrote:
On Mon, Jun 22, 2015 at 04:24:27AM -0400, Dan Williams wrote:
Some archs define the first parameter to ioremap() as unsigned long,
while the balance define it as resource_size_t. Unify on
resource_size_t to enable passing
On Tue, Jun 23, 2015 at 08:04:47AM -0700, Dan Williams wrote:
> Thanks, definitely a long shot at this point, but this is what one
> gets for fixing rather than working around broken base infrastructure.
> It would be unfortunate if we went another cycle with pmem having both
> poor performance
On Tue, Jun 23, 2015 at 08:04:47AM -0700, Dan Williams wrote:
Thanks, definitely a long shot at this point, but this is what one
gets for fixing rather than working around broken base infrastructure.
It would be unfortunate if we went another cycle with pmem having both
poor performance and
On Tue, Jun 23, 2015 at 3:07 AM, Christoph Hellwig wrote:
> On Mon, Jun 22, 2015 at 10:12:40AM -0700, Dan Williams wrote:
>> Is that an acked-by for this cycle with a request to go deeper for 4.3?
>
> I wouldn't really expect something this wide reaching to be picked up
> for this cycle, but if
On Mon, Jun 22, 2015 at 10:12:40AM -0700, Dan Williams wrote:
> Is that an acked-by for this cycle with a request to go deeper for 4.3?
I wouldn't really expect something this wide reaching to be picked up
for this cycle, but if you manage to get it in:
Acked-by: Christoph Hellwig
--
To
On Tue, Jun 23, 2015 at 3:07 AM, Christoph Hellwig h...@lst.de wrote:
On Mon, Jun 22, 2015 at 10:12:40AM -0700, Dan Williams wrote:
Is that an acked-by for this cycle with a request to go deeper for 4.3?
I wouldn't really expect something this wide reaching to be picked up
for this cycle, but
On Mon, Jun 22, 2015 at 10:12:40AM -0700, Dan Williams wrote:
Is that an acked-by for this cycle with a request to go deeper for 4.3?
I wouldn't really expect something this wide reaching to be picked up
for this cycle, but if you manage to get it in:
Acked-by: Christoph Hellwig h...@lst.de
--
On Mon, Jun 22, 2015 at 9:10 AM, Christoph Hellwig wrote:
> On Mon, Jun 22, 2015 at 04:24:27AM -0400, Dan Williams wrote:
>> Some archs define the first parameter to ioremap() as unsigned long,
>> while the balance define it as resource_size_t. Unify on
>> resource_size_t to enable passing
On Mon, Jun 22, 2015 at 04:24:27AM -0400, Dan Williams wrote:
> Some archs define the first parameter to ioremap() as unsigned long,
> while the balance define it as resource_size_t. Unify on
> resource_size_t to enable passing ioremap function pointers. Also, some
> archs use function-like
Some archs define the first parameter to ioremap() as unsigned long,
while the balance define it as resource_size_t. Unify on
resource_size_t to enable passing ioremap function pointers. Also, some
archs use function-like macros for defining ioremap aliases, but
asm-generic/io.h expects
On Mon, Jun 22, 2015 at 04:24:27AM -0400, Dan Williams wrote:
Some archs define the first parameter to ioremap() as unsigned long,
while the balance define it as resource_size_t. Unify on
resource_size_t to enable passing ioremap function pointers. Also, some
archs use function-like macros
On Mon, Jun 22, 2015 at 9:10 AM, Christoph Hellwig h...@lst.de wrote:
On Mon, Jun 22, 2015 at 04:24:27AM -0400, Dan Williams wrote:
Some archs define the first parameter to ioremap() as unsigned long,
while the balance define it as resource_size_t. Unify on
resource_size_t to enable passing
Some archs define the first parameter to ioremap() as unsigned long,
while the balance define it as resource_size_t. Unify on
resource_size_t to enable passing ioremap function pointers. Also, some
archs use function-like macros for defining ioremap aliases, but
asm-generic/io.h expects
44 matches
Mail list logo
