From: Stuart Yoder <stuart.yoder@nxp.com>
To: Dan Carpenter <dan.carpenter@oracle.com>,
        Shiva Kerdel <shiva@exdev.nl>
CC: "devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        Nipun Gupta <nipun.gupta@nxp.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "treding@nvidia.com" <treding@nvidia.com>,
        Laurentiu Tudor <laurentiu.tudor@nxp.com>
Subject: RE: [PATCH 1/2] Staging: fsl-mc: include: mc: Kernel type 's16'
 preferred over 'int16_t'
Thread-Topic: [PATCH 1/2] Staging: fsl-mc: include: mc: Kernel type 's16'
 preferred over 'int16_t'
Thread-Index: AQHSPAvfdnmnRhb0FUi9htvgspyz2aDTo/IAgAA0wlA=
Date: Fri, 11 Nov 2016 14:52:31 +0000
Message-ID: <VI1PR0401MB26383A9D15287D79B790BAD38DBB0@VI1PR0401MB2638.eurprd04.prod.outlook.com>
References: <20161111110740.1926-1-shiva@exdev.nl>
 <20161111112326.GG28701@mwanda>
In-Reply-To: <20161111112326.GG28701@mwanda>
Accept-Language: en-US
Content-Language: en-US
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2016 14:52:31.1490
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB1855
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id uABGQoBB031335
Content-Length: 2819
Lines: 74


> -----Original Message-----
> From: Dan Carpenter [mailto:dan.carpenter@oracle.com]
> Sent: Friday, November 11, 2016 5:23 AM
> To: Shiva Kerdel <shiva@exdev.nl>
> Cc: Stuart Yoder <stuart.yoder@nxp.com>; devel@driverdev.osuosl.org; German.Rivera@freescale.com;
> gregkh@linuxfoundation.org; Nipun Gupta <nipun.gupta@nxp.com>; linux-kernel@vger.kernel.org; German
> Rivera <german.rivera@nxp.com>; treding@nvidia.com; itai.katz@nxp.com
> Subject: Re: [PATCH 1/2] Staging: fsl-mc: include: mc: Kernel type 's16' preferred over 'int16_t'
> 
> On Fri, Nov 11, 2016 at 12:07:39PM +0100, Shiva Kerdel wrote:
> > Follow the kernel type preferrences of using 's16' over 'int16_t'.
> >
> > Signed-off-by: Shiva Kerdel <shiva@exdev.nl>
> > Acked-by: Stuart Yoder <stuart.yoder@nxp.com>
> > ---
> > Changes for v2:
> >     - corrected an error in the log message, wrote 's32' instead of 's16'.
> > Changes for v3:
> >     - added the missing annotates.
> > Changes for v4:
> >     - corrected patch subject to version 4.
> >
> >  drivers/staging/fsl-mc/include/mc-bus.h | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/staging/fsl-mc/include/mc-bus.h b/drivers/staging/fsl-mc/include/mc-bus.h
> > index e915574..c7cad87 100644
> > --- a/drivers/staging/fsl-mc/include/mc-bus.h
> > +++ b/drivers/staging/fsl-mc/include/mc-bus.h
> > @@ -42,8 +42,8 @@ struct msi_domain_info;
> >   */
> >  struct fsl_mc_resource_pool {
> >  	enum fsl_mc_pool_type type;
> > -	int16_t max_count;
> > -	int16_t free_count;
> > +	s16 max_count;
> 
> My understanding is that this has to be signed because the design of
> this driver is that we keep adding devices until the the counter
> overflows.  After that there are a couple tests for
> "if (WARN_ON(res_pool->max_count < 0)) " which prevent the driver from
> working again.
>
> This all seems pretty horrible.

Can you elaborate?

The resource pools managed by this driver are populated by hardware objects
discovered when the fsl-mc bus probes a DPRC/container.

The number of potential objects discovered of a given type is in the hundreds,
so a signed 16-bit number is order of magnitudes larger than anything we will
ever encounter.

Would you feel better about this if max_count was an int?

The max_count reflects the total number of objects discovered.  If that is
exceeded we display a warning, because something is horribly wrong.  Nothing
stops working, the allocator simply refuses to add anything else to the
free list.

The only reason max_count is there at all is as an internal check against
bugs and resource leaks.  If the driver is being removed and a resource
pool is being freed, max_count must be zero...i.e. all objects should have
been removed.  If not, there is a leak somewhere.  So, it's a sanity check.

Thanks,
Stuart