On Oct 13, 2011, at 10:37 AM, David Laight wrote:
>
>> Kumar Gala wrote:
>>> + phys_addr_t addr;
>
> Please add a comment here saying:
>
> 1) That 'addr' can be a virtual or physical address
>>> The code and everything else makes that clear
>>
>> I'm sorr
> Kumar Gala wrote:
> >>> >> + phys_addr_t addr;
> >> >
> >> > Please add a comment here saying:
> >> >
> >> > 1) That 'addr' can be a virtual or physical address
> > The code and everything else makes that clear
>
> I'm sorry, but I have to strongly disagree here. It is *NO
David Laight wrote:
> Since there is a discriminating field, could a union be used?
> At a guess the type of the address is constrained between
> produces and consumer??
I don't think we need to complicate the code by changing that variable into a
union. I just a want a short comment added to the
On Oct 13, 2011, at 9:37 AM, Tabi Timur-B04825 wrote:
> On Wed, Oct 12, 2011 at 3:57 PM, Kumar Gala wrote:
>> From: Kai Jiang
>>
>> To support >32-bit physical addresses for UIO_MEM_PHYS type we need to
>> extend the width of 'addr' in struct uio_mem. Numerous platforms like
>> embedded PPC,
Kumar Gala wrote:
>>> >> + phys_addr_t addr;
>> >
>> > Please add a comment here saying:
>> >
>> > 1) That 'addr' can be a virtual or physical address
> The code and everything else makes that clear
I'm sorry, but I have to strongly disagree here. It is *NOT* clear that a
vari
On Wed, Oct 12, 2011 at 3:57 PM, Kumar Gala wrote:
> From: Kai Jiang
>
> To support >32-bit physical addresses for UIO_MEM_PHYS type we need to
> extend the width of 'addr' in struct uio_mem. Numerous platforms like
> embedded PPC, ARM, and X86 have support for systems with larger physical
> add
