> This is not the correct way to submit patches for inclusion in the
> stable kernel tree. Please read:
>
> for how to do this properly.
My bad. I am sending the patch to the mainline kernel with a Cc: tag for stable
and hoping the patch will be automatically merged to the st
On Fri, Mar 23, 2018 at 04:41:02PM +, Sridhar Pitchai wrote:
> Please read the link I sent you in relation to email formatting.
>
> Then add your description above in a way that anyone not 100% familiar
> with hyperv can understand it - that's what the commit log is for.
>
Please read the link I sent you in relation to email formatting.
Then add your description above in a way that anyone not 100% familiar
with hyperv can understand it - that's what the commit log is for.
You are sending this patch to stable kernels, patch above has been in
> Previously, when using the bond driver, unique and persistent VF NIC name
> was required, so we used serial number as PCI domain which is included as
> part of the VF NIC name. Transparent SRIOV mode puts VF NIC based on MAC
> match as a slave of synthetic NIC, so VF NIC’s name i
[I composed most of this before seeing Lorenzo's response, so sorry
about the duplication. Maybe seeing things stated a different way
will help :)]
On Tue, Mar 20, 2018 at 11:00:36PM +, Sridhar Pitchai wrote:
> Hi Lorenzo,
>Transparent SRIOV is exposing the NIC directly to the kernel via
On Tue, Mar 20, 2018 at 11:00:36PM +, Sridhar Pitchai wrote:
> Hi Lorenzo,
>Transparent SRIOV is exposing the NIC directly to the kernel via
>para-virtual device, unlike creating a netdev and associating it
>with the bond driver. Further descriptions here,
>
> https://git.kernel
Hi Lorenzo,
Transparent SRIOV is exposing the NIC directly to the kernel via
para-virtual device, unlike creating a netdev and associating it with the bond
driver. Further descriptions here,
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=0c195567a8f6e82ea5535
On Tue, Mar 20, 2018 at 05:56:15PM +, Sridhar Pitchai wrote:
> Hi Lorenzo,
> Are we good with the explanation? Can I send the patch with the
> updated commit comments?
Almost.
[...]
> Since we have the transparent SRIOV mode now, the short VF device name
> is no longer needed.
Can
r.kernel.org;
linux-ker...@vger.kernel.org
Subject: Re: [PATCH v3]PCI: hv: fix PCI-BUS domainID corruption
On Thu, Mar 15, 2018 at 12:03:07AM +, Sridhar Pitchai wrote:
Whenever PCI bus is added, HyperV guarantees the BUS id is unique. Even
"Whenever a PCI bus is
OSG) ;
de...@linuxdriverproject.org; linux-...@vger.kernel.org;
linux-ker...@vger.kernel.org
Subject: Re: [PATCH v3]PCI: hv: fix PCI-BUS domainID corruption
On Thu, Mar 15, 2018 at 12:03:07AM +, Sridhar Pitchai wrote:
Whenever PCI bus is added, HyperV guarantees the BUS id is unique. Even
"
Helgaas ; Jake Oshins ;
Haiyang Zhang ; Stephen Hemminger
; Dexuan Cui ; KY Srinivasan
; Michael Kelley (EOSG) ;
de...@linuxdriverproject.org; linux-...@vger.kernel.org;
linux-ker...@vger.kernel.org
Subject: Re: [PATCH v3]PCI: hv: fix PCI-BUS domainID corruption
On Thu, Mar 15, 2018 at 12:03:07AM
On Thu, Mar 15, 2018 at 12:03:07AM +, Sridhar Pitchai wrote:
> Whenever PCI bus is added, HyperV guarantees the BUS id is unique. Even
"Whenever a PCI bus is added"
> with that when a first device is added to the bus, it overrides bus domain
> ID with the device serial number. Sometime this c
12 matches
Mail list logo
