On 06/25/2014 07:54 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2014-06-25 at 00:33 +1000, Alexey Kardashevskiy wrote:
>>
>> I do not understand why @val is considered LE here and need to be
>> converted
>> to CPU. Really. I truly believe it should be cpu_to_le32().
>
> No. Both are slightly wrong
On Wed, 2014-06-25 at 00:33 +1000, Alexey Kardashevskiy wrote:
>
> I do not understand why @val is considered LE here and need to be
> converted
> to CPU. Really. I truly believe it should be cpu_to_le32().
No. Both are slightly wrong semantically but le32_to_cpu() is less
wrong :-)
iowrite32 su
On Tue, 2014-06-24 at 12:41 +0200, Alexander Graf wrote:
> Is there actually any difference in generated code with this patch
> applied and without? I would hope that iowrite..() is inlined and
> cancels out the cpu_to_le..() calls that are also inlined?
No, the former uses byteswapping asm, the
On 06/25/2014 12:43 AM, Alex Williamson wrote:
> On Wed, 2014-06-25 at 00:33 +1000, Alexey Kardashevskiy wrote:
>> On 06/25/2014 12:21 AM, Alex Williamson wrote:
>>> On Tue, 2014-06-24 at 15:22 +0200, Alexander Graf wrote:
On 24.06.14 15:01, Alexey Kardashevskiy wrote:
> On 06/24/2014 10:5
On Wed, 2014-06-25 at 00:33 +1000, Alexey Kardashevskiy wrote:
> On 06/25/2014 12:21 AM, Alex Williamson wrote:
> > On Tue, 2014-06-24 at 15:22 +0200, Alexander Graf wrote:
> >> On 24.06.14 15:01, Alexey Kardashevskiy wrote:
> >>> On 06/24/2014 10:52 PM, Alexander Graf wrote:
> On 24.06.14 14:
From: Alexey Kardashevskiy
...
> >> So IMHO we should either create new, generic iowrite helpers that don't
> >> do any endian swapping at all or do iowrite32(cpu_to_le32(val)) calls.
> >
> > I'm one of those people for whom iowrite32(le32_to_cpu(val)) makes sense
>
>
> I do not understand why @v
On 06/25/2014 12:21 AM, Alex Williamson wrote:
> On Tue, 2014-06-24 at 15:22 +0200, Alexander Graf wrote:
>> On 24.06.14 15:01, Alexey Kardashevskiy wrote:
>>> On 06/24/2014 10:52 PM, Alexander Graf wrote:
On 24.06.14 14:50, Alexey Kardashevskiy wrote:
> On 06/24/2014 08:41 PM, Alexander G
On Tue, 2014-06-24 at 15:22 +0200, Alexander Graf wrote:
> On 24.06.14 15:01, Alexey Kardashevskiy wrote:
> > On 06/24/2014 10:52 PM, Alexander Graf wrote:
> >> On 24.06.14 14:50, Alexey Kardashevskiy wrote:
> >>> On 06/24/2014 08:41 PM, Alexander Graf wrote:
> On 24.06.14 12:11, Alexey Kardas
On 24.06.14 15:01, Alexey Kardashevskiy wrote:
On 06/24/2014 10:52 PM, Alexander Graf wrote:
On 24.06.14 14:50, Alexey Kardashevskiy wrote:
On 06/24/2014 08:41 PM, Alexander Graf wrote:
On 24.06.14 12:11, Alexey Kardashevskiy wrote:
On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote:
On T
On 06/24/2014 10:52 PM, Alexander Graf wrote:
>
> On 24.06.14 14:50, Alexey Kardashevskiy wrote:
>> On 06/24/2014 08:41 PM, Alexander Graf wrote:
>>> On 24.06.14 12:11, Alexey Kardashevskiy wrote:
On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2014-06-19 at 21:21 -0600, A
On 24.06.14 14:50, Alexey Kardashevskiy wrote:
On 06/24/2014 08:41 PM, Alexander Graf wrote:
On 24.06.14 12:11, Alexey Kardashevskiy wrote:
On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-19 at 21:21 -0600, Alex Williamson wrote:
Working on big endian being an accident
On 06/24/2014 08:41 PM, Alexander Graf wrote:
>
> On 24.06.14 12:11, Alexey Kardashevskiy wrote:
>> On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote:
>>> On Thu, 2014-06-19 at 21:21 -0600, Alex Williamson wrote:
>>>
Working on big endian being an accident may be a matter of perspective
>>
On 24.06.14 12:11, Alexey Kardashevskiy wrote:
On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote:
On Thu, 2014-06-19 at 21:21 -0600, Alex Williamson wrote:
Working on big endian being an accident may be a matter of perspective
:-)
The comment remains that this patch doesn't actually f
On 06/21/2014 09:12 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2014-06-19 at 21:21 -0600, Alex Williamson wrote:
>
>> Working on big endian being an accident may be a matter of perspective
>
> :-)
>
>> The comment remains that this patch doesn't actually fix anything except
>> the overhead on
On Sat, 2014-06-21 at 00:14 +1000, Alexey Kardashevskiy wrote:
> We can still use __raw_writel&co, would that be ok?
No unless you understand precisely what kind of memory barriers each
platform require for these.
Cheers,
Ben.
___
Linuxppc-dev mailin
On Thu, 2014-06-19 at 21:21 -0600, Alex Williamson wrote:
> Working on big endian being an accident may be a matter of perspective
:-)
> The comment remains that this patch doesn't actually fix anything except
> the overhead on big endian systems doing redundant byte swapping and
> maybe the ph
On 06/20/2014 01:21 PM, Alex Williamson wrote:
> On Thu, 2014-06-19 at 13:48 +1000, Alexey Kardashevskiy wrote:
>> On 06/19/2014 11:50 AM, Alexey Kardashevskiy wrote:
>>> On 06/19/2014 10:50 AM, Alexey Kardashevskiy wrote:
On 06/19/2014 04:35 AM, Alex Williamson wrote:
> On Wed, 2014-06-18
On Thu, 2014-06-19 at 13:48 +1000, Alexey Kardashevskiy wrote:
> On 06/19/2014 11:50 AM, Alexey Kardashevskiy wrote:
> > On 06/19/2014 10:50 AM, Alexey Kardashevskiy wrote:
> >> On 06/19/2014 04:35 AM, Alex Williamson wrote:
> >>> On Wed, 2014-06-18 at 21:36 +1000, Alexey Kardashevskiy wrote:
> >>>
2014 9:18 AM
>> To: Alex Williamson
>> Cc: k...@vger.kernel.org; Nikunj A Dadhania; linux-ker...@vger.kernel.org;
>> Alexander Graf; linuxppc-dev@lists.ozlabs.org
>> Subject: Re: [PATCH] vfio: Fix endianness handling for emulated BARs
>>
>> On 06/19/2014
A Dadhania; linux-ker...@vger.kernel.org;
> Alexander Graf; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] vfio: Fix endianness handling for emulated BARs
>
> On 06/19/2014 11:50 AM, Alexey Kardashevskiy wrote:
> > On 06/19/2014 10:50 AM, Alexey Kardashevskiy wrote:
> >> On 06/1
On 06/19/2014 11:50 AM, Alexey Kardashevskiy wrote:
> On 06/19/2014 10:50 AM, Alexey Kardashevskiy wrote:
>> On 06/19/2014 04:35 AM, Alex Williamson wrote:
>>> On Wed, 2014-06-18 at 21:36 +1000, Alexey Kardashevskiy wrote:
VFIO exposes BARs to user space as a byte stream so userspace can
On 06/19/2014 10:50 AM, Alexey Kardashevskiy wrote:
> On 06/19/2014 04:35 AM, Alex Williamson wrote:
>> On Wed, 2014-06-18 at 21:36 +1000, Alexey Kardashevskiy wrote:
>>> VFIO exposes BARs to user space as a byte stream so userspace can
>>> read it using pread()/pwrite(). Since this is a byte strea
On 06/19/2014 10:50 AM, Alexey Kardashevskiy wrote:
> On 06/19/2014 04:35 AM, Alex Williamson wrote:
>> On Wed, 2014-06-18 at 21:36 +1000, Alexey Kardashevskiy wrote:
>>> VFIO exposes BARs to user space as a byte stream so userspace can
>>> read it using pread()/pwrite(). Since this is a byte strea
On 06/19/2014 04:35 AM, Alex Williamson wrote:
> On Wed, 2014-06-18 at 21:36 +1000, Alexey Kardashevskiy wrote:
>> VFIO exposes BARs to user space as a byte stream so userspace can
>> read it using pread()/pwrite(). Since this is a byte stream, VFIO should
>> not do byte swapping and simply return
On Wed, 2014-06-18 at 21:36 +1000, Alexey Kardashevskiy wrote:
> VFIO exposes BARs to user space as a byte stream so userspace can
> read it using pread()/pwrite(). Since this is a byte stream, VFIO should
> not do byte swapping and simply return values as it gets them from
> PCI device.
>
> Inste
25 matches
Mail list logo
