Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753459Ab2JCDy3 (ORCPT ); Tue, 2 Oct 2012 23:54:29 -0400 Received: from eu1sys200aog107.obsmtp.com ([207.126.144.123]:41340 "EHLO eu1sys200aog107.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753165Ab2JCDy1 convert rfc822-to-8bit (ORCPT ); Tue, 2 Oct 2012 23:54:27 -0400 From: Arun MURTHY To: Greg KH Cc: "linux-kernel@vger.kernel.org" , "netdev@vger.kernel.org" , "linux-doc@vger.kernel.org" , "alan@lxorguk.ukuu.org.uk" Date: Wed, 3 Oct 2012 05:54:08 +0200 Subject: RE: [PATCHv4 1/4] modem_shm: Add Modem Access Framework Thread-Topic: [PATCHv4 1/4] modem_shm: Add Modem Access Framework Thread-Index: Ac2f7cagcFaxm/qgS36PdIbDqd2BkABK66vA Message-ID: References: <1348819504-1303-1-git-send-email-arun.murthy@stericsson.com> <1348819504-1303-2-git-send-email-arun.murthy@stericsson.com> <20120928160045.GD2625@kroah.com> <20121001155940.GA1957@kroah.com> In-Reply-To: <20121001155940.GA1957@kroah.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3578 Lines: 82 > On Mon, Oct 01, 2012 at 07:30:38AM +0200, Arun MURTHY wrote: > > > On Fri, Sep 28, 2012 at 01:35:01PM +0530, Arun Murthy wrote: > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > +#include > > > > + > > > > +static struct class *modem_class; > > > > > > What's wrong with a bus_type instead? > > > > Can I know the advantage of using bus_type over class? > > You have devices living on a bus, and it's much more descriptive than a class > (which we are going to eventually get rid of one of these days...). > > Might I ask why you choose a class over a bus_type? Basically my requirement is to create a central entity for accessing and releasing modem from APE. Since this is done by different clients the central entity should be able to handle the request and play safely, since this has more affect in system suspend and deep sleep. Using class helps me in achieving this and also create an entry to user space which can be used in the later parts. Moreover this not something like a bus or so, so I didn't use bus instead went with a simple class approach. > > > > > +int modem_release(struct modem_desc *mdesc) { > > > > + if (!mdesc->release) > > > > + return -EFAULT; > > > > + > > > > + if (modem_is_requested(mdesc)) { > > > > + atomic_dec(&mdesc->mclients->cnt); > > > > + if (atomic_read(&mdesc->use_cnt) == 1) { > > > > + mdesc->release(mdesc); > > > > + atomic_dec(&mdesc->use_cnt); > > > > + } > > > > > > Eeek, why aren't you using the built-in reference counting that the > > > struct device provided to you, and instead are rolling your own? > > > This happens in many places, why? > > > > My usage of counters over here is for each modem there are many clients. > > Each of the clients will have a ref to modem_desc. Each of them use > > this for requesting and releasing the modem. One counter for tracking > > the request and release for each client which is done by variable 'cnt' in > struct clients. > > The counter use_cnt is used for tracking the modem request/release > > irrespective of the clients and counter cli_cnt is used for > > restricting the modem_get to the no of clients defined in no_clients. > > > > So totally 3 counter one for restricting the usage of modem_get by > > clients, second for restricting modem request/release at top level, > > and 3rd for restricting modem release/request for per client per modem > basis. > > > > Can you let me know if the same can be achieved by using built-in ref > > counting? > > Yes, because you don't need all of those different levels, just stick with one > and you should be fine. :) > No, checks at all these levels are required, I have briefed out the need also. This will have effect on system power management, i.e suspend and deep sleep. We restrict that the drivers should request modem only once and release only once, but we cannot rely on the clients hence a check for the same has to be done in the MAF. Also the no of clients should be defined and hence a check for the same is done in MAF. Apart from all these the requests coming from all the clients is to be accumulated and based on that modem release or access should be performed, hence so. Thanks and Regards, Arun R Murthy ------------------- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/