> 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
Whenever PCI bus is added, HyperV guarantees the BUS id is unique. Even
with that when a first device is added to the bus, it overrides bus domain
ID with the device serial number. Sometime this can result in BUS ID not
being unique. In this case, when PCI_BUS and a device to bus is added, the
firs
13 matches
Mail list logo
