From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935467AbbI2Say (ORCPT ); Tue, 29 Sep 2015 14:30:54 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:54543 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935392AbbI2Sag (ORCPT ); Tue, 29 Sep 2015 14:30:36 -0400 Date: Tue, 29 Sep 2015 19:30:24 +0100 From: Mark Brown To: Rasmus Villemoes Cc: Greg Kroah-Hartman , linux-kernel@vger.kernel.org Message-ID: <20150929183024.GC30445@sirena.org.uk> References: <1443479342-31621-1-git-send-email-linux@rasmusvillemoes.dk> <1443479342-31621-2-git-send-email-linux@rasmusvillemoes.dk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ew/Z8sD4tCE3f25D" Content-Disposition: inline In-Reply-To: <1443479342-31621-2-git-send-email-linux@rasmusvillemoes.dk> X-Cookie: NOBODY EXPECTS THE SPANISH INQUISITION! User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: 94.175.94.161 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH 2/2] regmap: debugfs: improve regmap_reg_ranges_read_file() X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --ew/Z8sD4tCE3f25D Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Sep 29, 2015 at 12:29:02AM +0200, Rasmus Villemoes wrote: This patch is an example of why SubmittingPatches recommends splitting things up into one change per patch, it would be much easier to read and review as a series (especially given that there's very few collisions). > * A page is a bit much for two integers and a bit of punctuation. 64 > bytes should suffice. Right, the reason PAGE_SIZE was chosen is that it's a natural unit for the allocator and is clearly absurdly large for the data. For 64 bytes I have to think for a moment if it's suitably large. Please leave it at PAGE_SIZE, it's not like this hangs around for any length of time. > * Calling strlen() on entry no less than three times is silly, > especially when snprintf() has returned that value (which was just > thrown away). I think we were expecting the compiler would figure out that strlen() is a pure function and do the right thing here (though I do see it's missing an annotation). > * Transferring entry to the output buffer using snprintf is silly, > when we know the length. Use memcpy instead. Right, that's a legacy of a previous version transferring the maximum amount of data possible (which got abandoned due to complexity). However with the changes to use the return value of snprinf() it seems like the best thing to do here is to go back to this and just fill up as much of the buffer as we can by using snprintf() to do the transfer. That said I think memcpy() is going to be the best way of getting to that since one of the issues there (which currently doesn't work) is slicing things off the front and memcpy() handles that nicely. --ew/Z8sD4tCE3f25D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWCtjAAAoJECTWi3JdVIfQCf4H/RFD1CExdm4WGEP2/LWhSfdl m6BIv2BktLdszvXKF52LcvQWL6yfIj41RsJnI45VjysCpgvAWQ071rb7gm1NDQz+ Hepw/mBecrXfWeDcHaWSf/FmXKH3wDoUPz1SwZFw3ZE6hYoVjbDRDZnJNgLJVj/4 TCks+zYbo97zhm3BHTrLswH60f3kIJe3gJ1isdHWuniHGuyGaWdj1tzp3djr2oyn p1Bdp95ZaHvekl6DbVgUB38ZEkJFtdEoPagKWBxvC88i+PZtqCpnxudnuB3CvGtO 0ybzcI5/iyXbpF740GqhOhrgTpQu5HVhAG9HQrlx9myPy7fw0ANCrRF2dLDuGGg= =gI1a -----END PGP SIGNATURE----- --ew/Z8sD4tCE3f25D--