On 06/12/2015 12:27 AM, Scott Wood wrote:
> Dropping the upper bits of the size harms the ability to detect error
> scenarios where unmappably large -- but not power-of-two -- regions
> are requested to be mapped.
>
> However, this patch doesn't fix that. It just postpones the loss of
> the up
On Thu, 2015-06-11 at 19:10 +0300, Cristian Stoica wrote:
> On 06/11/2015 06:38 PM, Greg KH wrote:
> > On Thu, Jun 11, 2015 at 05:42:00PM +0300, Cristian Stoica wrote:
> >
> > Why?
> >
>
> This patch matches the input argument "size" of ioremap() with the
> output of request_mem_region() (which
On Thu, Jun 11, 2015 at 07:10:36PM +0300, Cristian Stoica wrote:
> On 06/11/2015 06:38 PM, Greg KH wrote:
> > On Thu, Jun 11, 2015 at 05:42:00PM +0300, Cristian Stoica wrote:
> >
> > Why?
> >
>
> This patch matches the input argument "size" of ioremap() with the output of
> request_mem_region()
On 06/11/2015 06:38 PM, Greg KH wrote:
> On Thu, Jun 11, 2015 at 05:42:00PM +0300, Cristian Stoica wrote:
>
> Why?
>
This patch matches the input argument "size" of ioremap() with the output of
request_mem_region() (which is
resource_size_t).
Since the latter is used as input to the former, the
On Thu, Jun 11, 2015 at 05:42:00PM +0300, Cristian Stoica wrote:
> Hi Greg,
>
> Can you have a look at this patch?
>
> https://patchwork.kernel.org/patch/6413191/
Why?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org
Hi Greg,
Can you have a look at this patch?
https://patchwork.kernel.org/patch/6413191/
Thanks,
Cristian S.
On 05/15/2015 12:44 PM, Cristian Stoica wrote:
> Use resource_size_t to accommodate sizes greater than the size of an
> unsigned long int on platforms that have more than 32 bit
> physic
Use resource_size_t to accommodate sizes greater than the size of an
unsigned long int on platforms that have more than 32 bit
physical addresses
Signed-off-by: Cristian Stoica
Changes in v2:
- update definitions is pgtable_64.c as well - or else we get broken builds on
64
- minor reformatting
