netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <Tristram.Ha@microchip.com>
To: <Razvan.Stefanescu@microchip.com>, <andrew@lunn.ch>
Cc: <Woojung.Huh@microchip.com>, <UNGLinuxDriver@microchip.com>,
	<vivien.didelot@gmail.com>, <f.fainelli@gmail.com>,
	<davem@davemloft.net>, <netdev@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 3/4] net: dsa: microchip: fix interrupt mask
Date: Tue, 27 Aug 2019 20:56:54 +0000	[thread overview]
Message-ID: <MN2PR11MB36781D752F1D07245B35FBAAECA00@MN2PR11MB3678.namprd11.prod.outlook.com> (raw)
In-Reply-To: <f54e1c98-e2db-2c63-4bd9-d1576f94937b@microchip.com>

> On 27/08/2019 15:51, Andrew Lunn wrote:
> >
> > On Tue, Aug 27, 2019 at 12:31:09PM +0300, Razvan Stefanescu wrote:
> >> Global Interrupt Mask Register comprises of Lookup Engine (LUE)
> Interrupt
> >> Mask (bit 31) and GPIO Pin Output Trigger and Timestamp Unit Interrupt
> >> Mask (bit 29).
> >>
> >> This corrects LUE bit.
> >
> > Hi Razvan
> >
> > Is this a fix? Something that should be back ported to old kernels?
> 
> Hello,
> 
> During testing I did not observed any issues with the old value. So I am
> not sure how the switch is affected by the incorrect setting.
> 
> Maybe maintainers will be able to make a better assessment if this needs
> back-porting. And I will be happy to do it if it is necessary.
> 

I do not think the change has any effect as the interrupt handling is not implemented in the driver, unless I am mistaken and do not know about the new code.

Currently those 3 interrupts do not do anything that are required in normal operation.

The first one LUE_INT notifies the driver when there are learn/write fails in the MAC table.  This condition rarely happens unless the switch is going through stress test.  When this interrupt happens software cannot do anything to resolve the issue.  It may become a denial of service if the MAC table keeps triggering learn fail.

The second one is used by PTP code, which is not implemented.

The third one is triggered when register access space does not exist.  It is useful during development so driver knows it is accessing the wrong register.  It can also become a denial of service if someone keeps accessing wrong registers.  But then that person can do anything with the chip.


  reply	other threads:[~2019-08-27 20:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-27  9:31 [PATCH 0/4] net: dsa: microchip: add KSZ8563 support Razvan Stefanescu
2019-08-27  9:31 ` [PATCH 1/4] dt-bindings: net: dsa: document additional Microchip KSZ8563 switch Razvan Stefanescu
2019-08-27  9:31 ` [PATCH 2/4] net: dsa: microchip: add KSZ8563 compatibility string Razvan Stefanescu
2019-08-27  9:31 ` [PATCH 3/4] net: dsa: microchip: fix interrupt mask Razvan Stefanescu
2019-08-27 12:51   ` Andrew Lunn
2019-08-27 13:22     ` Razvan.Stefanescu
2019-08-27 20:56       ` Tristram.Ha [this message]
2019-08-27  9:31 ` [PATCH 4/4] net: dsa: microchip: avoid hard-codded port count Razvan Stefanescu
2019-08-27 12:55   ` Andrew Lunn
2019-08-27 21:03   ` Tristram.Ha

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=MN2PR11MB36781D752F1D07245B35FBAAECA00@MN2PR11MB3678.namprd11.prod.outlook.com \
    --to=tristram.ha@microchip.com \
    --cc=Razvan.Stefanescu@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=Woojung.Huh@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=vivien.didelot@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).