From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from ushosting.nmnhosting.com ([167.160.173.127]) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hFzL2-0006SA-DY for ath10k@lists.infradead.org; Mon, 15 Apr 2019 10:59:49 +0000 From: "Alastair D'Silva" References: <20190410031720.11067-1-alastair@au1.ibm.com> <20190410031720.11067-2-alastair@au1.ibm.com> <20190412134802.kprel2c2iqijd4ai@pathway.suse.cz> <092f01d4f186$8e9e7cd0$abdb7670$@d-silva.org> <20190415090232.3ualhrt5ssrb2ixq@pathway.suse.cz> <0dad01d4f376$113df2b0$33b9d810$@d-silva.org> <6912ef2d83d34c9299d5a5ad120c276f@AcuMS.aculab.com> In-Reply-To: <6912ef2d83d34c9299d5a5ad120c276f@AcuMS.aculab.com> Subject: RE: [PATCH 1/4] lib/hexdump.c: Allow 64 bytes per line Date: Mon, 15 Apr 2019 20:59:36 +1000 Message-ID: <0dc901d4f37a$52733a70$f759af50$@d-silva.org> MIME-Version: 1.0 Content-Language: en-au List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "ath10k" Errors-To: ath10k-bounces+kvalo=adurom.com@lists.infradead.org To: 'David Laight' , 'Petr Mladek' Cc: linux-fbdev@vger.kernel.org, 'Stanislaw Gruszka' , 'David Airlie' , 'Joonas Lahtinen' , dri-devel@lists.freedesktop.org, devel@driverdev.osuosl.org, linux-scsi@vger.kernel.org, 'Jassi Brar' , ath10k@lists.infradead.org, intel-gfx@lists.freedesktop.org, 'Jose Abreu' , 'Tom Lendacky' , "'James E.J. Bottomley'" , 'Jani Nikula' , linux-fsdevel@vger.kernel.org, 'Steven Rostedt' , 'Rodrigo Vivi' , 'Benson Leung' , 'Kalle Valo' , 'Karsten Keil' , "'Martin K. Petersen'" , 'Greg Kroah-Hartman' , linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, 'Sergey Senozhatsky' , 'Daniel Vetter' , netdev@vger.kernel.org, 'Enric Balletbo i Serra' , 'Andrew Morton' , "'David S. Miller'" , 'Alexander Viro' > From: Alastair D'Silva > > Sent: 15 April 2019 11:29 > ... > > I do, and I believe the choice of the output length should be in the > > hands of the caller. > > > > On further thought, it would make more sense to remove the hardcoded > > list of sizes and just enforce a power of 2. The function shouldn't > > dictate what the caller can and can't do beyond the technical limits of it's > implementation. > > Why powers of two? > You may want the length to match sizeof (struct foo). > You might even want the address increment to be larger that the number of > lines dumped. Good point, the base requirement is that it should be a multiple of groupsize. -- Alastair D'Silva mob: 0423 762 819 skype: alastair_dsilva msn: alastair@d-silva.org blog: http://alastair.d-silva.org Twitter: @EvilDeece _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k