From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932446AbcAHPGd (ORCPT ); Fri, 8 Jan 2016 10:06:33 -0500 Received: from pandora.arm.linux.org.uk ([78.32.30.218]:49097 "EHLO pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932404AbcAHPGa (ORCPT ); Fri, 8 Jan 2016 10:06:30 -0500 Date: Fri, 8 Jan 2016 15:06:18 +0000 From: Russell King - ARM Linux To: Masahiro Yamada Cc: linux-arm-kernel , Arnd Bergmann , Linux Kernel Mailing List Subject: Re: range operation of outer cache when start >= end? Message-ID: <20160108150618.GL19062@n2100.arm.linux.org.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 08, 2016 at 11:54:30AM +0900, Masahiro Yamada wrote: > I know I am nitpicking. Forgive me if I am asking a silly question. > > > How should the outer-cache handle such an insane case like start >= end? Passing start >= end isn't defined, code should not pass start >= end. > Assumed answers are: > > [1] Do not care about that. It should never happen. If it does, fix > the caller. This applies. What situation are you seeing start >= end? What you will get with the existing code is potentially some cache cleaning and a sync, but nothing apart from that. __l2c210_op_pa_range() becomes a no-op of start >= end. However, that behaviour is not guaranteed. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.