From: Yuval Mintz
Date: Tue, 10 May 2016 18:15:08 +
>> > I'm not entirely convinced this is true; If we'll not enforce the
>> > alignment of this 64-bit field, it's possible there will be
>> > differences between 32-bit and 64-bit machines versions of this struct.
>>
> > > I'm not entirely convinced this is true; If we'll not enforce the
> > > alignment of this 64-bit field, it's possible there will be
> > > differences between 32-bit and 64-bit machines versions of this struct.
> > > You have to recall that this is going to be copied via DMA between
> > > PF
> > I'm not entirely convinced this is true; If we'll not enforce the
> > alignment of this 64-bit field, it's possible there will be
> > differences between 32-bit and 64-bit machines versions of this struct.
> > You have to recall that this is going to be copied via DMA between PF
> > and VF, so
From: Alexander Duyck
Date: Tue, 10 May 2016 11:02:09 -0700
> On Tue, May 10, 2016 at 10:16 AM, Yuval Mintz wrote:
>> > From: Yuval Mintz
>>> Date: Mon, 9 May 2016 16:19:10 +0300
>>>
>>> > + /* bitmap indicating
From: Yuval Mintz
Date: Tue, 10 May 2016 17:16:16 +
> I'm not entirely convinced this is true; If we'll not enforce the alignment
> of this 64-bit field, it's possible there will be differences between 32-bit
> and 64-bit machines versions of this struct.
> You have
On Tue, May 10, 2016 at 10:16 AM, Yuval Mintz wrote:
> > From: Yuval Mintz
>> Date: Mon, 9 May 2016 16:19:10 +0300
>>
>> > + /* bitmap indicating which fields hold valid values */
>> > + aligned_u64 valid_bitmap;
>>
>> There is absolutely no
> From: Yuval Mintz
> Date: Mon, 9 May 2016 16:19:10 +0300
>
> > + /* bitmap indicating which fields hold valid values */
> > + aligned_u64 valid_bitmap;
>
> There is absolutely no reason to use aligned_u64 here. That type is for
> handling
> a specific issue in
From: Yuval Mintz
Date: Mon, 9 May 2016 16:19:10 +0300
> + /* bitmap indicating which fields hold valid values */
> + aligned_u64 valid_bitmap;
There is absolutely no reason to use aligned_u64 here. That type is for
handling a specific issue in user facing APIs,
Add support for a new Kconfig option for qed* driver which would allow
[eventually] the support in VFs.
This patch adds the necessary logic in the PF to learn about the possible
VFs it will have to support [Based on PCI configuration space and HW],
and prepare a database with an entry per-VF as