linux-kernel - Re: [PATCH] Prevent interrupt loop with DWMAC MMC RX IPC Counter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <511E51A5.5040406@st.com>
Date:	Fri, 15 Feb 2013 16:17:57 +0100
From:	Giuseppe CAVALLARO <peppe.cavallaro@...com>
To:	Christian Ruppert <christian.ruppert@...lis.com>
Cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	Vineet Gupta <Vineet.Gupta1@...opsys.com>
Subject: Re: [PATCH] Prevent interrupt loop with DWMAC MMC RX IPC Counter

On 2/15/2013 3:48 PM, Christian Ruppert wrote:
> Hello Guiseppe,
>
> Thanks for the feedback. I'll send a new patch shortly which
> unconditionally masks the interrupts as you suggest. The mask register
> does not exist in DWMACs without RX IPC counters, however, and I have no
> way of testing if accessing this register nevertheless generates a bus
> error. Do you have hardware to verify if everything works fine even
> without RX IPC counters before integrating the patch?

Tests done on two boards and no issue on my side

peppe

>
> Greetings,
>    Christian
>
> On Fri, Feb 15, 2013 at 02:46:16PM +0100, Giuseppe CAVALLARO wrote:
>> Hello Christian
>>
>> On 2/15/2013 2:15 PM, Christian Ruppert wrote:
>>> If the DesignWare MAC is synthesised with MMC RX IPC Counter, an unmanaged
>>> and unacknowledged interrupt is generated after some time of operation. To
>>> my knowledge there is no way to autodetect this configuration.
>>>
>>> This patch adds a Kconfig option to tell the driver about the counter which
>>> in turn masks the undesired interrupts.
>>>
>>> Signed-off-by: Christian Ruppert <christian.ruppert@...lis.com>
>>> ---
>>>   drivers/net/ethernet/stmicro/stmmac/Kconfig    |    8 ++++++++
>>>   drivers/net/ethernet/stmicro/stmmac/mmc_core.c |    3 +++
>>>   2 files changed, 11 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
>>> index 1164930..60e5130 100644
>>> --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
>>> @@ -71,5 +71,13 @@ config STMMAC_CHAINED
>>>
>>>   endchoice
>>>
>>> +config STMMAC_RX_IPC_CTRS
>>> +	bool "MMC Receive IPC Counters enabled"
>>> +	depends on STMMAC_ETH
>>> +	default n
>>> +	---help---
>>> +	  Select this option in case MMC Receive IPC counters were enabled at
>>> +	  synthesis time of the block. If this option is not set correctly,
>>> +	  system might hang after a certain amount of time.
>>>
>>>   endif
>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/mmc_core.c b/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
>>> index 0c74a70..ae877ee 100644
>>> --- a/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
>>> @@ -149,6 +149,9 @@ void dwmac_mmc_intr_all_mask(void __iomem *ioaddr)
>>>   {
>>>   	writel(MMC_DEFAULT_MASK, ioaddr + MMC_RX_INTR_MASK);
>>>   	writel(MMC_DEFAULT_MASK, ioaddr + MMC_TX_INTR_MASK);
>>> +#ifdef CONFIG_STMMAC_RX_IPC_CTRS
>>> +	writel(MMC_DEFAULT_MASK, ioaddr + MMC_RX_IPC_INTR_MASK);
>>> +#endif
>>
>> your fix makes sense to me; I have never faced this problem because the
>> MMC RX IPC Counter is not synthesised  on the GMAC chip I used.
>>
>> Anyway all mmc interrupts are not managed by defsign so I only ask
>> you to remove the Kconfig option and add the writel in the
>> dwmac_mmc_intr_all_mask.
>>
>> peppe
>>
>>>   }
>>>
>>>   /* This reads the MAC core counters (if actaully supported).
>>>
>>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/