mbox series

[v3,0/2] net: phy: call phy_disable_interrupts() in phy_init_hw()

Message ID 20200624112516.7fcd6677@xhacker.debian
Headers show
Series net: phy: call phy_disable_interrupts() in phy_init_hw() | expand

Message

Jisheng Zhang June 24, 2020, 3:25 a.m. UTC 
We face an issue with rtl8211f, a pin is shared between INTB and PMEB,
and the PHY Register Accessible Interrupt is enabled by default, so
the INTB/PMEB pin is always active in polling mode case.

As Heiner pointed out "I was thinking about calling
phy_disable_interrupts() in phy_init_hw(), to have a defined init
state as we don't know in which state the PHY is if the PHY driver is
loaded. We shouldn't assume that it's the chip power-on defaults, BIOS
or boot loader could have changed this. Or in case of dual-boot
systems the other OS could leave the PHY in whatever state."

patch1 makes phy_disable_interrupts() non-static so that it could be used
in phy_init_hw() to have a defined init state.

patch2 calls phy_disable_interrupts() in phy_init_hw() to have a
defined init state.

Since v2:
  - Don't export phy_disable_interrupts() but just make it non-static

Since v1:
  - EXPORT the correct symbol

Jisheng Zhang (2):
  net: phy: make phy_disable_interrupts() non-static
  net: phy: call phy_disable_interrupts() in phy_init_hw()

 drivers/net/phy/phy.c        | 2 +-
 drivers/net/phy/phy_device.c | 7 +++++--
 include/linux/phy.h          | 1 +
 3 files changed, 7 insertions(+), 3 deletions(-)

Comments

David Miller June 24, 2020, 9:43 p.m. UTC | #1 
From: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Date: Wed, 24 Jun 2020 11:25:16 +0800

> We face an issue with rtl8211f, a pin is shared between INTB and PMEB,
> and the PHY Register Accessible Interrupt is enabled by default, so
> the INTB/PMEB pin is always active in polling mode case.
> 
> As Heiner pointed out "I was thinking about calling
> phy_disable_interrupts() in phy_init_hw(), to have a defined init
> state as we don't know in which state the PHY is if the PHY driver is
> loaded. We shouldn't assume that it's the chip power-on defaults, BIOS
> or boot loader could have changed this. Or in case of dual-boot
> systems the other OS could leave the PHY in whatever state."
> 
> patch1 makes phy_disable_interrupts() non-static so that it could be used
> in phy_init_hw() to have a defined init state.
> 
> patch2 calls phy_disable_interrupts() in phy_init_hw() to have a
> defined init state.
> 
> Since v2:
>   - Don't export phy_disable_interrupts() but just make it non-static
> 
> Since v1:
>   - EXPORT the correct symbol

Series applied, thank you.
Florian Fainelli June 24, 2020, 10:10 p.m. UTC | #2 
On 6/24/20 2:43 PM, David Miller wrote:
> From: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
> Date: Wed, 24 Jun 2020 11:25:16 +0800
> 
>> We face an issue with rtl8211f, a pin is shared between INTB and PMEB,
>> and the PHY Register Accessible Interrupt is enabled by default, so
>> the INTB/PMEB pin is always active in polling mode case.
>>
>> As Heiner pointed out "I was thinking about calling
>> phy_disable_interrupts() in phy_init_hw(), to have a defined init
>> state as we don't know in which state the PHY is if the PHY driver is
>> loaded. We shouldn't assume that it's the chip power-on defaults, BIOS
>> or boot loader could have changed this. Or in case of dual-boot
>> systems the other OS could leave the PHY in whatever state."
>>
>> patch1 makes phy_disable_interrupts() non-static so that it could be used
>> in phy_init_hw() to have a defined init state.
>>
>> patch2 calls phy_disable_interrupts() in phy_init_hw() to have a
>> defined init state.
>>
>> Since v2:
>>   - Don't export phy_disable_interrupts() but just make it non-static
>>
>> Since v1:
>>   - EXPORT the correct symbol
> 
> Series applied, thank you.

Did you mean that you applied v4? It does not look like you pushed your
local changes to net-next yet, so I cannot tell for sure.
David Miller June 24, 2020, 11:34 p.m. UTC | #3 
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Wed, 24 Jun 2020 15:10:51 -0700

> Did you mean that you applied v4? It does not look like you pushed your
> local changes to net-next yet, so I cannot tell for sure.

I ended up applying v4, yes.
Florian Fainelli June 25, 2020, 3:07 a.m. UTC | #4 
On 6/24/2020 4:34 PM, David Miller wrote:
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Wed, 24 Jun 2020 15:10:51 -0700
> 
>> Did you mean that you applied v4? It does not look like you pushed your
>> local changes to net-next yet, so I cannot tell for sure.
> 
> I ended up applying v4, yes.
> 

OK, just making sure :) thanks!