All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: netdev@vger.kernel.org
Cc: nobuhiro.iwamatsu.yj@renesas.com, linux-sh@vger.kernel.org
Subject: Re: [PATCH 2/2] sh_eth: workaround for spurious ECI interrupt
Date: Mon, 01 Apr 2013 13:53:26 +0000	[thread overview]
Message-ID: <51599156.7000802@cogentembedded.com> (raw)
In-Reply-To: <201303312354.20695.sergei.shtylyov@cogentembedded.com>

Hello.

On 31-03-2013 23:54, Sergei Shtylyov wrote:

> At least on Renesas R8A7778, EESR.ECI interrupt seems to fire regardless of its
> mask in EESIPR register. I can 100% reproduce it with the following scenario:
> target is booted with 'ip=on' option, and so IP-Config opens SoC Ether device
> but doesn't get a proper reply and then succeeds with on-board SMC chip; then
> I login and try to bring up the SoC Ether device with 'ifconfig', and I get
> an ECI interrupt once request_irq() is called by sh_eth_open() (while interrupt
> mask in EESIPR register is all 0), if that interrupt is accompanied by a pending
> EESR.FRC (frame receive completion) interrupt, I get kernel oops in sh_eth_rx()
> because sh_eth_ring_init() hasn't been called yet!

> The solution I worked out is the following: in sh_eth_interrupt(), mask the
> interrupt status from EESR register with the interrupt mask from EESIPR register
> in order not to handle the disabled interrupts -- but forcing EESIPR.M_ECI bit
> in this mask set because we always need to fully handle EESR.ECI interrupt in
> sh_eth_error() in order to quench it (as it doesn't get cleared by just writing
> 1 to the this bit as all the other interrupts).

> While at it, remove unneeded initializer for 'intr_status' variable and give it
> *unsigned long* type, matching the type of sh_eth_read()'s result; fix comment.

> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Reviewed-by: Max Filippov <max.filippov@cogentembedded.com>

    Though maybe writing 0 to ECSIPR (feLic interrupt mask) register in 
sh_eth_close() could have prevented the spurious interrupts too, masking all 
its primary sources -- I should have tried it beforehand. Still can try though...

WBR, Sergei


WARNING: multiple messages have this Message-ID (diff)
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: netdev@vger.kernel.org
Cc: nobuhiro.iwamatsu.yj@renesas.com, linux-sh@vger.kernel.org
Subject: Re: [PATCH 2/2] sh_eth: workaround for spurious ECI interrupt
Date: Mon, 01 Apr 2013 17:53:26 +0400	[thread overview]
Message-ID: <51599156.7000802@cogentembedded.com> (raw)
In-Reply-To: <201303312354.20695.sergei.shtylyov@cogentembedded.com>

Hello.

On 31-03-2013 23:54, Sergei Shtylyov wrote:

> At least on Renesas R8A7778, EESR.ECI interrupt seems to fire regardless of its
> mask in EESIPR register. I can 100% reproduce it with the following scenario:
> target is booted with 'ip=on' option, and so IP-Config opens SoC Ether device
> but doesn't get a proper reply and then succeeds with on-board SMC chip; then
> I login and try to bring up the SoC Ether device with 'ifconfig', and I get
> an ECI interrupt once request_irq() is called by sh_eth_open() (while interrupt
> mask in EESIPR register is all 0), if that interrupt is accompanied by a pending
> EESR.FRC (frame receive completion) interrupt, I get kernel oops in sh_eth_rx()
> because sh_eth_ring_init() hasn't been called yet!

> The solution I worked out is the following: in sh_eth_interrupt(), mask the
> interrupt status from EESR register with the interrupt mask from EESIPR register
> in order not to handle the disabled interrupts -- but forcing EESIPR.M_ECI bit
> in this mask set because we always need to fully handle EESR.ECI interrupt in
> sh_eth_error() in order to quench it (as it doesn't get cleared by just writing
> 1 to the this bit as all the other interrupts).

> While at it, remove unneeded initializer for 'intr_status' variable and give it
> *unsigned long* type, matching the type of sh_eth_read()'s result; fix comment.

> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Reviewed-by: Max Filippov <max.filippov@cogentembedded.com>

    Though maybe writing 0 to ECSIPR (feLic interrupt mask) register in 
sh_eth_close() could have prevented the spurious interrupts too, masking all 
its primary sources -- I should have tried it beforehand. Still can try though...

WBR, Sergei


  parent reply	other threads:[~2013-04-01 13:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-31 19:54 [PATCH 2/2] sh_eth: workaround for spurious ECI interrupt Sergei Shtylyov
2013-03-31 19:54 ` Sergei Shtylyov
2013-03-31 23:44 ` David Miller
2013-03-31 23:44   ` David Miller
2013-04-01 13:53 ` Sergei Shtylyov [this message]
2013-04-01 13:53   ` Sergei Shtylyov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51599156.7000802@cogentembedded.com \
    --to=sergei.shtylyov@cogentembedded.com \
    --cc=linux-sh@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nobuhiro.iwamatsu.yj@renesas.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.