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 S1753400AbdEQLwO (ORCPT <rfc822;w@1wt.eu>);
        Wed, 17 May 2017 07:52:14 -0400
Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:44594 "EHLO
        atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752896AbdEQLwM (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 17 May 2017 07:52:12 -0400
Date: Wed, 17 May 2017 13:52:09 +0200
From: Pavel Machek <pavel@ucw.cz>
To: Mason <slash.tmp@free.fr>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>,
        Richard Weinberger <richard@nod.at>,
        David Woodhouse <dwmw2@infradead.org>,
        Brian Norris <computersforpeace@gmail.com>,
        Marek Vasut <marek.vasut@gmail.com>,
        Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>,
        linux-mtd <linux-mtd@lists.infradead.org>,
        LKML <linux-kernel@vger.kernel.org>, mark.marshall@omicronenergy.com,
        b44839@freescale.com, prabhakar@freescale.com
Subject: Re: [PATCH] nand_base: optimize checking of erased buffers
Message-ID: <20170517115209.GA32246@amd>
References: <20170419121332.GA26979@amd>
 <20170419231804.5a04ed69@bbrezillon>
 <20170419221507.GA24914@amd>
 <20170420002748.5c76c9b9@bbrezillon>
 <20170420114057.GA4705@amd>
 <20170421105107.GA7259@amd>
 <421c46b9-288f-42e9-5b2f-d93af1e8a418@free.fr>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
        protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua"
Content-Disposition: inline
In-Reply-To: <421c46b9-288f-42e9-5b2f-d93af1e8a418@free.fr>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


--SUOF0GtieIMvvwua
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


> This is not true for my platform, as the ecc pointer is
> chip->oob_poi + 10
>=20
> I suppose it's not a problem if the platform can handle
> unaligned loads, otherwise it spells trouble.
>=20
>=20
> > +		unsigned long d =3D *((unsigned long *)bitmap);
> > +		if (d =3D=3D ~0UL)
> > +			continue;
> > +		weight =3D hweight_long(d);
> >  		bitflips +=3D BITS_PER_LONG - weight;
> >  		if (unlikely(bitflips > bitflips_threshold))
> >  			return -EBADMSG;
> >=20
>=20
> The optimization makes sense in itself, but given that it's on an
> error path (?) I'm not sure it will bring any tangible benefits?

Well, if it is critical enough to do magic it does, it is also
important enough not to do expensive bit-counting needlessly...=20

--=20
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo=
g.html

--SUOF0GtieIMvvwua
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlkcOWkACgkQMOfwapXb+vJwIACeK3i/PBV99Fw19DYMc7KuCTCh
3Y8AniSKSNKrCfxYiz4ltoJtnx5uH3P7
=zYT5
-----END PGP SIGNATURE-----

--SUOF0GtieIMvvwua--