All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: William Breathitt Gray <vilhelm.gray@gmail.com>
Cc: linux-arch@vger.kernel.org, yamada.masahiro@socionext.com,
	linus.walleij@linaro.org, linux@rasmusvillemoes.dk,
	linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
	bgolaszewski@baylibre.com, akpm@linux-foundation.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v10 10/10] thermal: intel: intel_soc_dts_iosf: Utilize for_each_set_clump8 macro
Date: Sun, 24 Mar 2019 15:52:47 +0200	[thread overview]
Message-ID: <20190324135247.GG9224@smile.fi.intel.com> (raw)
In-Reply-To: <20190324033747.GA7697@icarus>

On Sun, Mar 24, 2019 at 12:38:29PM +0900, William Breathitt Gray wrote:
> On Fri, Mar 22, 2019 at 09:02:43PM +0200, Andy Shevchenko wrote:
> > On Thu, Mar 14, 2019 at 09:32:57PM +0900, William Breathitt Gray wrote:
> > > Utilize for_each_set_clump8 macro, and the bitmap_set_value8 and
> > > bitmap_get_value8 functions, where appropriate. In addition, remove the
> > > now unnecessary temp_mask and temp_shift members of the
> > > intel_soc_dts_sensor_entry structure.
> > 
> > One comment below, otherwise
> > Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Thanks!
> 
> Thank you for testing out the patch. I'll fix the bug your pointed out
> and add the Tested-by line.
> 
> I have a couple minor comments below.

> > >  	u32 store_ptps;

> > > -	out = (store_ptps & ~(0xFF << (thres_index * 8)));
> > > -	out |= (temp_out & 0xFF) << (thres_index * 8);
> > > +	update_ptps = store_ptps;
> > > +	bitmap_set_value8(&update_ptps, 32, temp_out & 0xFF, thres_index * 8);
> 
> I chose to hardcode a bitmap width of 32 here because that is the width
> of the store_ptps variables, but I don't think we necessarily use all 32
> bits here. Would the actual width of store_ptps be the number of
> writable trip count bits (writable_trip_count * 8)?

I think 32 is okay, but sizeof(store_ptps) would be better. It's easy to read
since no need to check what is the actual size inside this variable is used.


Same for below.


-- 
With Best Regards,
Andy Shevchenko

WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: William Breathitt Gray <vilhelm.gray@gmail.com>
Cc: linux-arch@vger.kernel.org, yamada.masahiro@socionext.com,
	linus.walleij@linaro.org, linux@rasmusvillemoes.dk,
	linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
	bgolaszewski@baylibre.com, akpm@linux-foundation.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v10 10/10] thermal: intel: intel_soc_dts_iosf: Utilize for_each_set_clump8 macro
Date: Sun, 24 Mar 2019 15:52:47 +0200	[thread overview]
Message-ID: <20190324135247.GG9224@smile.fi.intel.com> (raw)
In-Reply-To: <20190324033747.GA7697@icarus>

On Sun, Mar 24, 2019 at 12:38:29PM +0900, William Breathitt Gray wrote:
> On Fri, Mar 22, 2019 at 09:02:43PM +0200, Andy Shevchenko wrote:
> > On Thu, Mar 14, 2019 at 09:32:57PM +0900, William Breathitt Gray wrote:
> > > Utilize for_each_set_clump8 macro, and the bitmap_set_value8 and
> > > bitmap_get_value8 functions, where appropriate. In addition, remove the
> > > now unnecessary temp_mask and temp_shift members of the
> > > intel_soc_dts_sensor_entry structure.
> > 
> > One comment below, otherwise
> > Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Thanks!
> 
> Thank you for testing out the patch. I'll fix the bug your pointed out
> and add the Tested-by line.
> 
> I have a couple minor comments below.

> > >  	u32 store_ptps;

> > > -	out = (store_ptps & ~(0xFF << (thres_index * 8)));
> > > -	out |= (temp_out & 0xFF) << (thres_index * 8);
> > > +	update_ptps = store_ptps;
> > > +	bitmap_set_value8(&update_ptps, 32, temp_out & 0xFF, thres_index * 8);
> 
> I chose to hardcode a bitmap width of 32 here because that is the width
> of the store_ptps variables, but I don't think we necessarily use all 32
> bits here. Would the actual width of store_ptps be the number of
> writable trip count bits (writable_trip_count * 8)?

I think 32 is okay, but sizeof(store_ptps) would be better. It's easy to read
since no need to check what is the actual size inside this variable is used.


Same for below.


-- 
With Best Regards,
Andy Shevchenko



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: William Breathitt Gray <vilhelm.gray@gmail.com>
Cc: linus.walleij@linaro.org, akpm@linux-foundation.org,
	linux-gpio@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux@rasmusvillemoes.dk,
	yamada.masahiro@socionext.com, bgolaszewski@baylibre.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v10 10/10] thermal: intel: intel_soc_dts_iosf: Utilize for_each_set_clump8 macro
Date: Sun, 24 Mar 2019 15:52:47 +0200	[thread overview]
Message-ID: <20190324135247.GG9224@smile.fi.intel.com> (raw)
In-Reply-To: <20190324033747.GA7697@icarus>

On Sun, Mar 24, 2019 at 12:38:29PM +0900, William Breathitt Gray wrote:
> On Fri, Mar 22, 2019 at 09:02:43PM +0200, Andy Shevchenko wrote:
> > On Thu, Mar 14, 2019 at 09:32:57PM +0900, William Breathitt Gray wrote:
> > > Utilize for_each_set_clump8 macro, and the bitmap_set_value8 and
> > > bitmap_get_value8 functions, where appropriate. In addition, remove the
> > > now unnecessary temp_mask and temp_shift members of the
> > > intel_soc_dts_sensor_entry structure.
> > 
> > One comment below, otherwise
> > Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Thanks!
> 
> Thank you for testing out the patch. I'll fix the bug your pointed out
> and add the Tested-by line.
> 
> I have a couple minor comments below.

> > >  	u32 store_ptps;

> > > -	out = (store_ptps & ~(0xFF << (thres_index * 8)));
> > > -	out |= (temp_out & 0xFF) << (thres_index * 8);
> > > +	update_ptps = store_ptps;
> > > +	bitmap_set_value8(&update_ptps, 32, temp_out & 0xFF, thres_index * 8);
> 
> I chose to hardcode a bitmap width of 32 here because that is the width
> of the store_ptps variables, but I don't think we necessarily use all 32
> bits here. Would the actual width of store_ptps be the number of
> writable trip count bits (writable_trip_count * 8)?

I think 32 is okay, but sizeof(store_ptps) would be better. It's easy to read
since no need to check what is the actual size inside this variable is used.


Same for below.


-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2019-03-24 13:52 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-14 12:29 [PATCH v10 00/10] Introduce the for_each_set_clump8 macro William Breathitt Gray
2019-03-14 12:29 ` William Breathitt Gray
2019-03-14 12:30 ` [PATCH v10 01/10] bitops: " William Breathitt Gray
2019-03-14 12:30   ` William Breathitt Gray
2019-03-22 18:22   ` Andy Shevchenko
2019-03-22 18:22     ` Andy Shevchenko
2019-03-14 12:30 ` [PATCH v10 02/10] lib/test_bitmap.c: Add for_each_set_clump8 test cases William Breathitt Gray
2019-03-14 12:30   ` William Breathitt Gray
2019-03-14 12:30 ` [PATCH v10 03/10] gpio: 104-dio-48e: Utilize for_each_set_clump8 macro William Breathitt Gray
2019-03-14 12:30   ` William Breathitt Gray
2019-03-14 12:30 ` [PATCH v10 04/10] gpio: 104-idi-48: " William Breathitt Gray
2019-03-14 12:30   ` William Breathitt Gray
2019-03-14 12:31 ` [PATCH v10 05/10] gpio: gpio-mm: " William Breathitt Gray
2019-03-14 12:31   ` William Breathitt Gray
2019-03-14 12:31 ` [PATCH v10 06/10] gpio: ws16c48: " William Breathitt Gray
2019-03-14 12:31   ` William Breathitt Gray
2019-03-14 12:31 ` [PATCH v10 07/10] gpio: pci-idio-16: " William Breathitt Gray
2019-03-14 12:31   ` William Breathitt Gray
2019-03-14 12:32 ` [PATCH v10 08/10] gpio: pcie-idio-24: " William Breathitt Gray
2019-03-14 12:32   ` William Breathitt Gray
2019-03-14 12:32 ` [PATCH v10 09/10] gpio: uniphier: " William Breathitt Gray
2019-03-14 12:32   ` William Breathitt Gray
2019-03-14 12:53   ` William Breathitt Gray
2019-03-14 12:53     ` William Breathitt Gray
2019-03-14 12:32 ` [PATCH v10 10/10] thermal: intel: intel_soc_dts_iosf: " William Breathitt Gray
2019-03-14 12:32   ` William Breathitt Gray
2019-03-14 14:26   ` Andy Shevchenko
2019-03-14 14:26     ` Andy Shevchenko
2019-03-14 14:39     ` William Breathitt Gray
2019-03-14 14:39       ` William Breathitt Gray
2019-03-22 19:02   ` Andy Shevchenko
2019-03-22 19:02     ` Andy Shevchenko
2019-03-24  3:38     ` William Breathitt Gray
2019-03-24  3:38       ` William Breathitt Gray
2019-03-24 13:52       ` Andy Shevchenko [this message]
2019-03-24 13:52         ` Andy Shevchenko
2019-03-24 13:52         ` Andy Shevchenko
2019-03-22 19:12 ` [PATCH v10 00/10] Introduce the " Andy Shevchenko
2019-03-22 19:12   ` Andy Shevchenko
2019-03-24  4:08   ` William Breathitt Gray
2019-03-24  4:08     ` William Breathitt Gray
2019-03-24  4:08     ` William Breathitt Gray
2019-03-24  8:53     ` Geert Uytterhoeven
2019-03-24  8:53       ` Geert Uytterhoeven
2019-03-24 12:08     ` Andy Shevchenko
2019-03-24 12:08       ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190324135247.GG9224@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=bgolaszewski@baylibre.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=vilhelm.gray@gmail.com \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.