Re: [PATCH 2/2] net/smsc911x: Move interrupt allocation to open/stop

Hi,

On 09/01/2016 02:45 PM, Andrew Lunn wrote:

On Thu, Sep 01, 2016 at 01:47:44PM -0500, Jeremy Linton wrote:

quoted

Hi Andrew,

	Thanks for taking a look at this!

On 09/01/2016 12:06 PM, Andrew Lunn wrote:

quoted

Hi Jeremy

Please don't add forward references. Move the function earlier in the
file.

Ok, but I thought it was a fairly large move due to further
dependent functions..

There are a few other options, like moving smsc911x_open() rather than
the interrupt handler.

And i would suggest what ever you do, make it a separate patch. A
patch which says: No functional changes, just move functions around as
needed by later patches, is going to be quick and easy to review.

Yes I put it in another patch, I was busy blasting it out rather than checking my email...

quoted

quoted

quoted

+	netif_carrier_off(dev);

What has this change got to do with interrupt handling?

	This is a whoops, it should be in the previous patch..

Or a patch of its own? You also needs to be careful with ordering
against the phy_connect.

quoted

quoted

quoted

@@ -2479,38 +2491,18 @@ static int smsc911x_drv_probe(struct platform_device *pdev)

	if (retval < 0)
		goto out_disable_resources;

-	/* configure irq polarity and type before connecting isr */
-	if (pdata->config.irq_polarity == SMSC911X_IRQ_POLARITY_ACTIVE_HIGH)
-		intcfg |= INT_CFG_IRQ_POL_;
-
-	if (pdata->config.irq_type == SMSC911X_IRQ_TYPE_PUSH_PULL)
-		intcfg |= INT_CFG_IRQ_TYPE_;
-
-	smsc911x_reg_write(pdata, INT_CFG, intcfg);

I see these removes, but where are the adds?

	The functionality is duplicated in open, when the IRQ handler is tested.

Ah, it is obfusticated by SMC_SET_IRQ_CFG().

If you say it is duplicated, how about a separate patch removing it,
with a clear pointer to where the duplicate is.

? Well, I didn't do that part, but I'm confused by your SMC_SET_IRQ_CFG(). AFAIK, that is smc911x not smsc911x. The code in question is in smsc911x_open() following "Set interrupt deassertion to 100uS". It looks a little different but its reprogramming the INT_CFG preceding the interrupt being enabled.

Really, if I were feeling brave (because this driver is used in so many strange pieces of hardware) I would rewrite a large portion of the interrupt management in this driver. I started looking at it last month, while looking for the mdio polling issue, because I wanted to get the link state changes directly. While at it I noticed the WOL functionality could use some attention, etc, one problem after another.