[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20150921.150827.116958889622345434.davem@redhat.com>
Date: Mon, 21 Sep 2015 15:08:27 -0700 (PDT)
From: David Miller <davem@...hat.com>
To: linux@....linux.org.uk
Cc: f.fainelli@...il.com, devicetree@...r.kernel.org,
frowand.list@...il.com, grant.likely@...aro.org,
isubramanian@....com, kchudgar@....com,
linux-arm-kernel@...ts.infradead.org,
linuxppc-dev@...ts.ozlabs.org, leoli@...escale.com,
michal.simek@...inx.com, netdev@...r.kernel.org, rric@...nel.org,
robh+dt@...nel.org, soren.brinkmann@...inx.com,
sgoutham@...ium.com, thomas.petazzoni@...e-electrons.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/7] phy: fix of_mdio_find_bus() device refcount leak
From: Russell King - ARM Linux <linux@....linux.org.uk>
Date: Mon, 21 Sep 2015 20:32:07 +0100
> In the case of the mdio mux code, I'm dropping the reference when
> either (a) we've encountered an error during initialisation and
> we're cleaning up, or (b) when the mdio mux code is being torn down
> after the mdiomux bus has been unregistered and freed. In both
> cases, we're done with the mdio bus that was returned from
> of_mdio_find_bus().
>
> In case (a), the devres code will release the kmalloc'd memory when
> mdio_mux_gpio_probe() or mdio_mux_mmioreg_probe() propagates the error
> out of their probe() function.
>
> I'm not sure why you think anything is wrong here - maybe it's the odd
> code structure to the success path at the bottom of mdio_mux_init()?
Ok I may have misread your change. I'll restudy it when you respin
the series with the commit message fixed and the DSA change added.
Thanks.
--
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/
Powered by blists - more mailing lists