From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 249158287E for ; Sat, 24 Jan 2026 01:04:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.13 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769216665; cv=none; b=Q1kWy0u4PHihlMfKTkMH9DM2JKMi0UOBzIa26QfeWMf3belB9c+P1avR2Fg6NWpommoIVE3MfTXnxNfwqxyV9teBDfF53AAKL+/6H2dePwL+TkOml5YtiHvm9DifK7TM93g8UrG+GuYs6tboLGbVNW/oiROJXd4xEGbID81m3Bg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769216665; c=relaxed/simple; bh=x49FFcIOTPr7nuBwVlrsQmqOzImuT0D19ZrJMQvhV4g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=BxnjqdU9Ds7Fcqw2m6ZBWd9RKeC3lFuQ2lT0qAP1n/DsLFzWS2lHOTcki0x7paZrjJbTmeQvqnzSxMCfVDfRo1wJmohbsjZz8v1yscSm40UPC+TmX5/+YSsGXl+CYKfW3LrZJW4K3+M85DRtDPnFhTmlvMN1O+h6TqQKVTOBiZ8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=l05n4sUf; arc=none smtp.client-ip=198.175.65.13 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="l05n4sUf" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1769216665; x=1800752665; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=x49FFcIOTPr7nuBwVlrsQmqOzImuT0D19ZrJMQvhV4g=; b=l05n4sUffr4lJWDWFGRWXRqnSYYCDWJZtzZuO8le0M5OpoEhTMWKSZiY gHfNkTe6K1XsDwX+tzrB8mgalK5aZBxleIno3Nz0gtNixu90MpjNa/iHp 97SpB/5a4u77nE/9lgjvEY/lBo7DmtOBaxJCDfEDxJwYK6Ep9mkUFPfg7 FyCCNqJt7giIazPH+pkaP72mpnFLPDzdgig4a7nbLh7sNGfvBV6DevXgd fRwCmf7m/roG4jqPkqigGKEhiKIHnrSUbKgshsqRrC3qXrixpETyfBl3h DEFuVHUMv8f5Ud7npN0vwocCDJwCpZ+zzTMXjBAd9A4puAAnQVzIRrie2 g==; X-CSE-ConnectionGUID: 1ScWPnUjRnipOx7DTnjk5g== X-CSE-MsgGUID: WijctaPPQDKxWOOV+Z5PRg== X-IronPort-AV: E=McAfee;i="6800,10657,11680"; a="81585954" X-IronPort-AV: E=Sophos;i="6.21,249,1763452800"; d="scan'208";a="81585954" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jan 2026 17:04:24 -0800 X-CSE-ConnectionGUID: QRQM8/FmTJqxoTpLXJ95fQ== X-CSE-MsgGUID: tVb6C3UTT6mNXHI9XUvDvQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,249,1763452800"; d="scan'208";a="206971869" Received: from abityuts-desk.ger.corp.intel.com (HELO localhost) ([10.245.244.207]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Jan 2026 17:04:22 -0800 Date: Sat, 24 Jan 2026 03:04:19 +0200 From: Andy Shevchenko To: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Cc: Miquel Raynal , Richard Weinberger , Vignesh Raghavendra Subject: Re: [PATCH v1 1/1] mtd: cfi_cmdset_0001: Factor out do_write_buffer_locked() to reduce stack frame Message-ID: References: <20260124005203.3167280-1-andriy.shevchenko@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260124005203.3167280-1-andriy.shevchenko@linux.intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo On Sat, Jan 24, 2026 at 01:52:03AM +0100, Andy Shevchenko wrote: > Compiler is not happy about used stack frame: > > drivers/mtd/chips/cfi_cmdset_0001.c: In function 'do_write_buffer': > drivers/mtd/chips/cfi_cmdset_0001.c:1887:1: error: the frame size of 1296 bytes is larger than 1280 bytes [-Werror=frame-larger-than=] > > Fix this by factoring out do_write_buffer_locked(). ... > XIP_INVAL_CACHED_RANGE(map, initial_adr, initial_len); > ENABLE_VPP(map); It seems more logical to leave these two in the original call. ... > +static int __xipram do_write_buffer(struct map_info *map, struct flchip *chip, > + unsigned long adr, const struct kvec **pvec, > + unsigned long *pvec_seek, int len) > +{ > + struct cfi_private *cfi = map->fldrv_priv; > + unsigned long cmd_adr; > + int ret, wbufsize; > + > + wbufsize = cfi_interleave(cfi) << cfi->cfiq->MaxBufWriteSize; > + adr += chip->start; > + cmd_adr = adr & ~(wbufsize - 1); > + > + /* Sharp LH28F640BF chips need the first address for the > + * Page Buffer Program command. See Table 5 of > + * LH28F320BF, LH28F640BF, LH28F128BF Series (Appendix FUM00701) */ > + if (is_LH28F640BF(cfi)) > + cmd_adr = adr; > + > + mutex_lock(&chip->mutex); > + ret = get_chip(map, chip, cmd_adr, FL_WRITING); > + if (ret) { > + mutex_unlock(&chip->mutex); > + return ret; > + } > + > + ret = do_write_buffer_locked(map, chip, cmd_adr, adr, pvec, pvec_seek, len); > + DISABLE_VPP(map); Otherwise this will seem dangling here. > put_chip(map, chip, cmd_adr); > mutex_unlock(&chip->mutex); > return ret; ... Another approach is to leave goto as is in the _locked() and move DISABLE_VPP() there. Tell me what do you prefer? -- With Best Regards, Andy Shevchenko