From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752090AbdAMPji (ORCPT ); Fri, 13 Jan 2017 10:39:38 -0500 Received: from mail1.windriver.com ([147.11.146.13]:56929 "EHLO mail1.windriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751444AbdAMPjh (ORCPT ); Fri, 13 Jan 2017 10:39:37 -0500 Date: Fri, 13 Jan 2017 10:39:25 -0500 From: Paul Gortmaker To: Stefano Babic CC: , Martyn Welch Subject: Re: VME: devices not removed after commit 050c3d52cc7 Message-ID: <20170113153925.GU11537@windriver.com> References: <54f7a6d6-f04d-b13a-04bf-b7e4405d2619@denx.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <54f7a6d6-f04d-b13a-04bf-b7e4405d2619@denx.de> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [Adding Martyn to Cc] [VME: devices not removed after commit 050c3d52cc7] On 13/01/2017 (Fri 11:03) Stefano Babic wrote: > Hi, > > I have updated a custom VME device driver (mainly based on vme_user.c) > to 4.9 (previously it was for 3.14-). > > I see that VME device drivers cannot be loaded and unloaded due to this > commit: > > commit 050c3d52cc7810d9d17b8cd231708609af6876ae > Author: Paul Gortmaker > Date: Sun Jul 3 14:05:56 2016 -0400 > > vme: make core vme support explicitly non-modular I've gone back and looked at this, and vme_user.c and I'm not yet 100% convinced this is the right conclusion. But perhaps, and I've put Martyn on the Cc, in the hopes that he can clarify as well, if needed. > > > In fact, this drops the remove function, that scans all devices attached > to the bus and call their remove function. So I guess my confusion here is between removal of a VME device, vs. the removal of a complete VME bus. The above commit you reference was based on the premise that removal of a VME bus is not supported. Which is not to say that a VME device removal is not supported. > > That means that "remove" entry points in VME device driver (let see in > drivers/staging/vme/devices/vme_user.c) are now dead code and the > required cleanup code is not called at all (devices and class are not > removed). Reloading the same driver cause errors due to the missing > cleanup by unloading. This does not let build VME device drivers as > module, as it is supposed to be done. Again, I don't think this analysis is 100% right, but I can't be sure because your driver is out of tree and I don't know what it does precisely. Looking at vme_user.c example, it has its own .remove function that should be executed at module unload, and that would do all the cleanup (see vme_user_remove). > > Paul, what do you mind ? For sure, we can restore the .remove and vme_bus_remove portions of that commit if it is a real regression against a correct use of the infrastructure, but I'm still not clear how you'd be triggering the vme_bus_remove unless the vme device driver was going up into its parent's bus struct directly. Maybe Martyn can spot where I've misunderstood the bus vs. device separation here. Paul. -- > > Best regards, > Stefano Babic > > > -- > ===================================================================== > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de > =====================================================================