From: Hari Nagalla <[email protected]>
Disable the over voltage interrupt at initialization to meet typical
application requirement.
Signed-off-by: Hari Nagalla <[email protected]>
Signed-off-by: Geet Modi <[email protected]>
Signed-off-by: Vikram Sharma <[email protected]>
---
drivers/net/phy/dp83tc811.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/phy/dp83tc811.c b/drivers/net/phy/dp83tc811.c
index 7ea32fb77190..452a39d96bd8 100644
--- a/drivers/net/phy/dp83tc811.c
+++ b/drivers/net/phy/dp83tc811.c
@@ -226,7 +226,6 @@ static int dp83811_config_intr(struct phy_device *phydev)
DP83811_POLARITY_INT_EN |
DP83811_SLEEP_MODE_INT_EN |
DP83811_OVERTEMP_INT_EN |
- DP83811_OVERVOLTAGE_INT_EN |
DP83811_UNDERVOLTAGE_INT_EN);
err = phy_write(phydev, MII_DP83811_INT_STAT2, misr_status);
--
2.17.1
On Thu, Sep 02, 2021 at 02:09:44PM -0500, [email protected] wrote:
> From: Hari Nagalla <[email protected]>
>
> Disable the over voltage interrupt at initialization to meet typical
> application requirement.
Are you saying it is typical to supply too high a voltage?
Andrew
Hi Andrew,
This feature is not used by our mainstream customers as they have additional mechanism to monitor the supply at System level.
Hence want to keep it disable by default.
Regards,
Geet
On 9/2/21, 4:23 PM, "Andrew Lunn" <[email protected]> wrote:
On Thu, Sep 02, 2021 at 02:09:44PM -0500, [email protected] wrote:
> From: Hari Nagalla <[email protected]>
>
> Disable the over voltage interrupt at initialization to meet typical
> application requirement.
Are you saying it is typical to supply too high a voltage?
Andrew
On Mon, Sep 06, 2021 at 08:51:53PM +0000, Modi, Geet wrote:
> Hi Andrew,
>
> This feature is not used by our mainstream customers as they have additional mechanism to monitor the supply at System level.
>
> Hence want to keep it disable by default.
So we are slowly getting closer to a usable commit message. One that
actually makes sense.
Now, this is not really your driver, it is the Linux kernel
driver. Could somebody be using this feature? Not one of your
mainstream customer, but a Linux kernel user?
Lets look at the driver, what interrupts actually get enabled?
misr_status |= (DP83811_RX_ERR_HF_INT_EN |
DP83811_MS_TRAINING_INT_EN |
DP83811_ANEG_COMPLETE_INT_EN |
DP83811_ESD_EVENT_INT_EN |
DP83811_WOL_INT_EN |
DP83811_LINK_STAT_INT_EN |
DP83811_ENERGY_DET_INT_EN |
DP83811_LINK_QUAL_INT_EN);
misr_status |= (DP83811_JABBER_DET_INT_EN |
DP83811_POLARITY_INT_EN |
DP83811_SLEEP_MODE_INT_EN |
DP83811_OVERTEMP_INT_EN |
DP83811_OVERVOLTAGE_INT_EN |
DP83811_UNDERVOLTAGE_INT_EN);
Some of these i have no idea what they even do. Why would i be
interested in RX_ERR_HF_INT_EN or MS_TRAINING_INT_EN?
ESD_EVENT_INT_EN? Do we need to wake up the phy driver and update the
status because these interrupts have fired?
ANEG_COMPLETE_INT_EN, ANEG_COMPLETE_INT_EN, LINK_STAT_INT_EN make
sense.
LINK_QUAL_INT_EN and POLARITY_INT_EN could in theory make sense, but
the driver is missing the code to report quality and MDIX/MDX.
If the driver ever gets HWMON support, OVERTEMP_INT_EN,
OVERVOLTAGE_INT_EN and UNDERVOLTAGE_INT_EN could be interesting. But
there is no HWMON support.
So it looks like there are lots of interrupts which could be removed
because nothing happens when they fire. But then i wonder, why did you
pick just one? Does it cause some sort of problem for one of your
mainstream customers? What sort of problem? Does it affect all other
Linux users, not just your customer?
So please expand your commit message to try to answer some of these
questions.
Thanks
Andrew