Re: [RFC PATCH 0/3] net: dsa: Complete and fix the dsa unbinding

[Neil Armstrong]

On 09/30/2015 07:43 PM, Florian Fainelli wrote:
> On 30/09/15 01:21, Neil Armstrong wrote:
>> In order to cleanly unbind the dsa core, either as a module removal,
>> or a platform device unbind, switch the allocation the their devm_
>> counterparts and complete the destroy functions.
>>
>> The last patch is an experimental way to exit the probe when no
>> switch is found in the discover process.
>>
>> The patches are based on the current net-next.
> 
> I looked at the patches and they bring DSA in a better direction. For
> future submissions, could you CC people who recently worked on DSA, like
> Andrew Lunn, Guenter Roeck, Vivien Didelot and myself? We can typically
> give your patches a try fairly quickly.
> 
> In case you are seriously considering making DSA a loadable module,
> there were an earlier attempt here:
> 
> http://comments.gmane.org/gmane.linux.network/345803
> 
> Thanks!
> 
>>
>> Neil Armstrong (3):
>>   net: dsa: Use devm_ prefixed allocations
>>   net: dsa: complete dsa_switch_destroy calls
>>   net: dsa: exit probe if no switch were found
>>
>>  net/dsa/dsa.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++++-------
>>  1 file changed, 60 insertions(+), 7 deletions(-)
>>
> 
> 

At least, the following patch could be added with no pain to complete my code :
[PATCH net-next 5/8] net: dsa: allow switch drivers to cleanup their resource (http://permalink.gmane.org/gmane.linux.network/345805)

Then, the following patch could be re-proposed :
[PATCH net-next 7/8] net: dsa: bcm_sf2: cleanup resources in remove callback

I should probably also take this part also :
+	dst->master_netdev->dsa_ptr = NULL;
+	/* If we used a tagging format that doesn't have an ethertype
+	 * field, make sure that all packets from this point get sent
+	 * without the tag and go through the regular receive path.
+	 */
+	wmb();
+

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