From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1756435AbbE2Pig (ORCPT <rfc822;w@1wt.eu>);
	Fri, 29 May 2015 11:38:36 -0400
Received: from metis.ext.pengutronix.de ([92.198.50.35]:52197 "EHLO
	metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1756036AbbE2Pi3 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 29 May 2015 11:38:29 -0400
Message-ID: <1432913902.3046.9.camel@pengutronix.de>
Subject: Re: [PATCH v3 1/9] misc: sram: fix enabled clock leak on error path
From: Philipp Zabel <p.zabel@pengutronix.de>
To: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Cc: Heiko =?ISO-8859-1?Q?St=FCbner?= <heiko@sntech.de>,
        Arnd Bergmann <arnd@arndb.de>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-kernel@vger.kernel.org
Date: Fri, 29 May 2015 17:38:22 +0200
In-Reply-To: <55684E01.70502@mentor.com>
References: <1431976122-4228-1-git-send-email-vladimir_zapolskiy@mentor.com>
				 <1431976122-4228-2-git-send-email-vladimir_zapolskiy@mentor.com>
			 <1432032089.15181.22.camel@pengutronix.de> <555B368E.4080102@mentor.com>
		 <1432121401.4466.60.camel@pengutronix.de> <556230A9.8030307@mentor.com>
	 <1432630462.3743.15.camel@pengutronix.de> <55684E01.70502@mentor.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.12.9-1+b1 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 2001:67c:670:100:96de:80ff:fec2:9969
X-SA-Exim-Mail-From: p.zabel@pengutronix.de
X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false
X-PTX-Original-Recipient: linux-kernel@vger.kernel.org
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Vladimir,

Am Freitag, den 29.05.2015, 14:31 +0300 schrieb Vladimir Zapolskiy:
[...]
> > res->start is of type phys_addr_t (well, resource_size_t) already.
> > block->start/size and cur_start/size are just offsets added to it.
> 
> I agree.
> 
> > I wonder if it wouldn't be more appropriate to use resource_size_t for
> > the sram_reserve .start field.
> 
> Assuming that the sram_reserve .start field represents only the difference
> of two res->start and this difference fits into u32 storage, it should be
> safe to keep it as is.
> 
> In my opinion integer overflow case should not be considered or handled
> by the driver, so probably the best option would be just to drop
> phys_addr_t commit, since it attempts to solve a nonexistent problem.
> 
> Please let me know your opinion, if it is fine with you, I'll remove
> "use phys_addr_t instead of u32 for physical address" commit and resend
> the series.

Yes, that's fine with me.

regards
Philipp