On 03/12/2018 03:10 PM, Andrew Lunn wrote:
>> The problem here is that our routine to change the mtu does a full reset on
>> the driver meaning that in the process we go from effectively "open" to
>> "closed" to "open" again.
>>
>> Consider the scenario where we change the mtu by running "ifdown
>
> The problem here is that our routine to change the mtu does a full reset on
> the driver meaning that in the process we go from effectively "open" to
> "closed" to "open" again.
>
> Consider the scenario where we change the mtu by running "ifdown ",
> editing the ifcfg file with the new mtu, and
On 03/12/2018 02:33 PM, Andrew Lunn wrote:
> On Mon, Mar 12, 2018 at 02:19:52PM -0500, John Allen wrote:
>> If the driver is already in the "open" state, don't attempt the procedure
>> for opening the driver.
>>
>> Signed-off-by: John Allen
>> ---
>> v2: Unlock reset_lock mutex before returning.
>
On Mon, Mar 12, 2018 at 02:19:52PM -0500, John Allen wrote:
> If the driver is already in the "open" state, don't attempt the procedure
> for opening the driver.
>
> Signed-off-by: John Allen
> ---
> v2: Unlock reset_lock mutex before returning.
>
> diff --git a/drivers/net/ethernet/ibm/ibmvnic.
If the driver is already in the "open" state, don't attempt the procedure
for opening the driver.
Signed-off-by: John Allen
---
v2: Unlock reset_lock mutex before returning.
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c
b/drivers/net/ethernet/ibm/ibmvnic.c
index 7be4b06..9a5e8ac 100644
--- a/