Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1262080pxb; Fri, 20 Nov 2020 05:29:45 -0800 (PST) X-Google-Smtp-Source: ABdhPJxBO5ULyUvHxmGolo4+0SXxEmE6QSGj7K6wdVRjgTxVpPBew1yM+ci5swVobecb+LIfl967 X-Received: by 2002:a17:906:22c7:: with SMTP id q7mr33965492eja.291.1605878984738; Fri, 20 Nov 2020 05:29:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605878984; cv=none; d=google.com; s=arc-20160816; b=gCJhKnqBMobXB65CDmUlmO+TpzvOGhEeKqZ5oysvkcfG/Mt7waLNRurBFFW60cXsWt ez3PNY7u5+Vt6ZTuvDvHALFcnnvJPOgRwQ6k2afGeuCCVD/nYPhVIW7tXusPku7CUpGV 58sZODOvtm/eANvx4txeEUGhFxGmTKrG7ZYWR7tI2OZVNacZIZ0dgyFZa6Pn5jsQTzW3 PqqkNXIMgtHg0QoSJDepZaHthnAM6K01dxRP2QCAaZ38a3k1ae/+yMSOw1A32nDErZYe ypQpWsZafZ1uCkRH/cpiVWGy/MjlYKIHa8bN8jn71OpLupkZo7lQmFc/7k7O/k39YHiU eTEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=YYnnILdivVIAMpbM42MzVlen1tOt1WOPM8sM7JPwtmU=; b=oPXCf5/XmirnhZ0FWi32ddCs2Ac1SK1jXfho7SsNdhm5Pp/nE2waDGJM8nh1jxo27M BvV5N+dWbRHyW+0XsfmAgZbqxJFuF/BwG3EkYqgZ5Jidd86Hww59Lnca8nDnssSLn8JB 8idm7ZDdrEyfbaN/BISz5ctWP7/0cI1MxtnNWLgf6l7Z85inMi/iK0PvRwBw5MCkVBaC VFFeyxsendkp8Cjz4zwbn5YbDQhwDtBIIhI3FoIAQM6AzeCaLZOcZghzfLzZL3lGRBlR EOr/J0Fp0im/UNHz7dnwoVvqJeGLmDRk2/7ZzK+JX5uL2c+2XkN6er8FhP5IcO1ESLEt UCTw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=NcwbmeHr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id jz23si1708674ejb.221.2020.11.20.05.29.20; Fri, 20 Nov 2020 05:29:44 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=NcwbmeHr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727120AbgKTN0x (ORCPT + 99 others); Fri, 20 Nov 2020 08:26:53 -0500 Received: from mail.kernel.org ([198.145.29.99]:46542 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726719AbgKTN0x (ORCPT ); Fri, 20 Nov 2020 08:26:53 -0500 Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com [209.85.210.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 03E1E2236F; Fri, 20 Nov 2020 13:26:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605878812; bh=+RFM63VBDWH7JjmXp5qfMg6s8bW4Hxl04yTQdjzQX1Q=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=NcwbmeHrDlmpvdoSJgqy4B5TDidwyTlm7Y65tjq3ZxcTxygP0cuTMkuZf9jIAMHGn VDktvbmxrqsxq+a97VO4tbwM+1A82rtlLtk5PzpEf41Kt0a50aHolJivCO57J/89+Q 1G6hFWfh7mU6DB7oWcVcB2L/zQTHywxnTp6whhpI= Received: by mail-ot1-f52.google.com with SMTP id l36so8687244ota.4; Fri, 20 Nov 2020 05:26:51 -0800 (PST) X-Gm-Message-State: AOAM533GR1tECVkwzZBm7mTvkHFk+gqRvWGizV39lb/P+bWOVUvJWKZm NphEReH4LFthNeD21np6b6bkKjYwSaGAfQN9qEQ= X-Received: by 2002:a05:6830:22d2:: with SMTP id q18mr12449744otc.305.1605878811162; Fri, 20 Nov 2020 05:26:51 -0800 (PST) MIME-Version: 1.0 References: <20201109134128.GA5596@shinobu> <20201109164529.GA28710@syed.domain.name> <20201109171140.GA14045@shinobu> <20201109172220.GI4077@smile.fi.intel.com> <20201109173107.GA14643@shinobu> <20201110123538.GA3193@shinobu> <20201110174316.GA12192@shinobu> <20201110220004.GA25801@syed> In-Reply-To: From: Arnd Bergmann Date: Fri, 20 Nov 2020 14:26:35 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v12 4/4] gpio: xilinx: Utilize generic bitmap_get_value and _set_value To: Syed Nayyar Waris Cc: William Breathitt Gray , Michal Simek , Andy Shevchenko , Linus Walleij , Andrew Morton , "open list:GPIO SUBSYSTEM" , "linux-kernel@vger.kernel.org" , Bartosz Golaszewski , Linux ARM Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 13, 2020 at 5:52 PM Syed Nayyar Waris wrote: > On Wed, Nov 11, 2020 at 3:30 AM Syed Nayyar Waris wrote: > > On Tue, Nov 10, 2020 at 12:43:16PM -0500, William Breathitt Gray wrote: > > > On Tue, Nov 10, 2020 at 10:52:42PM +0530, Syed Nayyar Waris wrote: > > > > On Tue, Nov 10, 2020 at 6:05 PM William Breathitt Gray > > > > wrote: > > > > > > > > > > On Tue, Nov 10, 2020 at 11:02:43AM +0100, Michal Simek wrote: > > > > > > > > > > > > > > > > > > On 09. 11. 20 18:31, William Breathitt Gray wrote: > > > > > > > On Mon, Nov 09, 2020 at 07:22:20PM +0200, Andy Shevchenko wrote: > > > > > > >> On Mon, Nov 09, 2020 at 12:11:40PM -0500, William Breathitt Gray wrote: > > > > > > >>> On Mon, Nov 09, 2020 at 10:15:29PM +0530, Syed Nayyar Waris wrote: > > > > > > >>>> On Mon, Nov 09, 2020 at 03:41:53PM +0100, Arnd Bergmann wrote: > > > > > > >> > > > > > > >> ... > > > > > > >> > > > > > > >>>> static inline void bitmap_set_value(unsigned long *map, > > > > > > >>>> - unsigned long value, > > > > > > >>>> + unsigned long value, const size_t length, > > > > > > >>>> unsigned long start, unsigned long nbits) > > > > > > >>>> { > > > > > > >>>> const size_t index = BIT_WORD(start); > > > > > > >>>> @@ -15,6 +15,10 @@ static inline void bitmap_set_value(unsigned long *map, > > > > > > >>>> } else { > > > > > > >>>> map[index + 0] &= ~BITMAP_FIRST_WORD_MASK(start); > > > > > > >>>> map[index + 0] |= value << offset; > > > > > > >>>> + > > > > > > >>>> + if (index + 1 >= length) > > > > > > >>>> + __builtin_unreachable(); > > > > > > >>>> + > > > > > > >>>> map[index + 1] &= ~BITMAP_LAST_WORD_MASK(start + nbits); > > > > > > >>>> map[index + 1] |= value >> space; > > > > > > >>>> } > > > > > > >>> > > > > > > >>> Hi Syed, > > > > > > >>> > > > > > > >>> Let's rename 'length' to 'nbits' as Arnd suggested, and rename 'nbits' > > > > > > >>> to value_width. > > > > > > >> > > > > > > >> length here is in longs. I guess this is the point of entire patch. > > > > > > > > > > > > > > Ah yes, this should become 'const unsigned long nbits' and represent the > > > > > > > length of the bitmap in bits and not longs. > > > > > > > > Hi William, Andy and All, > > > > > > > > Thank You for reviewing. I was looking into the review comments and I > > > > have a question on the above. > > > > > > > > Actually, in bitmap_set_value(), the intended comparison is to be made > > > > between 'index + 1' and 'length' (which is now renamed as 'nbits'). > > > > That is, the comparison would look-like as follows: > > > > if (index + 1 >= nbits) > > > > > > > > The 'index' is getting populated with BIT_WORD(start). > > > > The 'index' variable in above is the actual index of the bitmap array, > > > > while in previous mail it is suggested to use 'nbits' which represent > > > > the length of the bitmap in bits and not longs. > > > > > > > > Isn't it comparing two different things? index of array (not the > > > > bit-wise-length) on left hand side and nbits (bit-wise-length) on > > > > right hand side? > > > > > > > > Have I misunderstood something? If yes, request to clarify. > > > > > > > > Or do I have to first divide 'nbits' by BITS_PER_LONG and then compare > > > > it with 'index + 1'? Something like this? > > > > > > > > Regards > > > > Syed Nayyar Waris > > > > > > The array elements of the bitmap memory region are abstracted away for > > > the covenience of the users of the bitmap_* functions; the driver > > > authors are able to treat their bitmaps as just a set of contiguous bits > > > and not worry about where the division between array elements happen. > > > > > > So to match the interface of the other bitmap_* functions, you should > > > take in nbits and figure out the actual array length by dividing by > > > BITS_PER_LONG inside bitmap_set_value(). Then you can use your > > > conditional check (index + 1 >= length) like you have been doing so far. > > > > > > William Breathitt Gray > > > > Hi Arnd, > > > > Sharing a new version of bitmap_set_value(). Let me know if it looks > > good and whether it suppresses the compiler warning. > > > > The below patch is created against the v12 version of bitmap_set_value(). > > > > -static inline void bitmap_set_value(unsigned long *map, > > - unsigned long value, > > - unsigned long start, unsigned long nbits) > > +static inline void bitmap_set_value(unsigned long *map, unsigned long nbits, > > + unsigned long value, unsigned long value_width, > > + unsigned long start) > > { > > - const size_t index = BIT_WORD(start); > > + const unsigned long index = BIT_WORD(start); > > + const unsigned long length = BIT_WORD(nbits); > > const unsigned long offset = start % BITS_PER_LONG; > > const unsigned long ceiling = round_up(start + 1, BITS_PER_LONG); > > const unsigned long space = ceiling - start; > > > > - value &= GENMASK(nbits - 1, 0); > > + value &= GENMASK(value_width - 1, 0); > > > > - if (space >= nbits) { > > - map[index] &= ~(GENMASK(nbits - 1, 0) << offset); > > + if (space >= value_width) { > > + map[index] &= ~(GENMASK(value_width - 1, 0) << offset); > > map[index] |= value << offset; > > } else { > > map[index + 0] &= ~BITMAP_FIRST_WORD_MASK(start); > > map[index + 0] |= value << offset; > > - map[index + 1] &= ~BITMAP_LAST_WORD_MASK(start + nbits); > > + > > + if (index + 1 >= length) > > + __builtin_unreachable(); > > + > > + map[index + 1] &= ~BITMAP_LAST_WORD_MASK(start + value_width); > > map[index + 1] |= value >> space; > > } > > } > > > > > > Hi Arnd, > > What do you think of the above solution ( new version of > bitmap_set_value() )? Does it look good? Sorry for the late reply and thanks for continuing to look at solutions. I don't really like the idea of having the __builtin_unreachable() in there, since that would lead to even worse undefined behavior (jumping to a random instruction) than the previous one (writing to a random location) when invalid data gets passed. Isn't passing the length of the bitmap sufficient to suppress the warning (sorry I did not try myself)? If not, maybe this could be a "BUG_ON(index + 1 >= length)" instead of the __builtin_unreachable(). That way it would at least crash in a well-defined way. Arnd