[PATCH] thermal: sun8i: Use bitmap API instead of open code

Maxime Ripard maxime at cerno.tech
Wed Oct 28 09:51:13 EDT 2020


Hi Frank,

On Mon, Oct 19, 2020 at 07:58:36PM +0800, Frank Lee wrote:
> From: Yangtao Li <frank at allwinnertech.com>
> 
> Thw bitmap_* API is the standard way to access data in the bitfield.
> 
> Signed-off-by: Yangtao Li <frank at allwinnertech.com>
> ---
>  drivers/thermal/sun8i_thermal.c | 35 +++++++++++++++++----------------
>  1 file changed, 18 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/thermal/sun8i_thermal.c b/drivers/thermal/sun8i_thermal.c
> index f8b13071a6f4..f2e4a4f18101 100644
> --- a/drivers/thermal/sun8i_thermal.c
> +++ b/drivers/thermal/sun8i_thermal.c
> @@ -8,6 +8,7 @@
>   * Based on the work of Josef Gajdusek <atx at atx.name>
>   */
>  
> +#include <linux/bitmap.h>
>  #include <linux/clk.h>
>  #include <linux/device.h>
>  #include <linux/interrupt.h>
> @@ -74,7 +75,7 @@ struct ths_thermal_chip {
>  	int		(*calibrate)(struct ths_device *tmdev,
>  				     u16 *caldata, int callen);
>  	int		(*init)(struct ths_device *tmdev);
> -	int             (*irq_ack)(struct ths_device *tmdev);
> +	void		(*irq_ack)(struct ths_device *tmdev);
>  	int		(*calc_temp)(struct ths_device *tmdev,
>  				     int id, int reg);
>  };
> @@ -82,6 +83,7 @@ struct ths_thermal_chip {
>  struct ths_device {
>  	const struct ths_thermal_chip		*chip;
>  	struct device				*dev;
> +	DECLARE_BITMAP(irq_bitmap, MAX_SENSOR_NUM);
>  	struct regmap				*regmap;
>  	struct reset_control			*reset;
>  	struct clk				*bus_clk;
> @@ -146,9 +148,11 @@ static const struct regmap_config config = {
>  	.max_register = 0xfc,
>  };
>  
> -static int sun8i_h3_irq_ack(struct ths_device *tmdev)
> +static void sun8i_h3_irq_ack(struct ths_device *tmdev)
>  {
> -	int i, state, ret = 0;
> +	int i, state;
> +
> +	bitmap_zero(tmdev->irq_bitmap, tmdev->chip->sensor_num);
>  
>  	regmap_read(tmdev->regmap, SUN8I_THS_IS, &state);
>  
> @@ -156,16 +160,16 @@ static int sun8i_h3_irq_ack(struct ths_device *tmdev)
>  		if (state & SUN8I_THS_DATA_IRQ_STS(i)) {
>  			regmap_write(tmdev->regmap, SUN8I_THS_IS,
>  				     SUN8I_THS_DATA_IRQ_STS(i));
> -			ret |= BIT(i);
> +			bitmap_set(tmdev->irq_bitmap, i, 1);
>  		}
>  	}
> -
> -	return ret;
>  }
>  
> -static int sun50i_h6_irq_ack(struct ths_device *tmdev)
> +static void sun50i_h6_irq_ack(struct ths_device *tmdev)
>  {
> -	int i, state, ret = 0;
> +	int i, state;
> +
> +	bitmap_zero(tmdev->irq_bitmap, tmdev->chip->sensor_num);
>  
>  	regmap_read(tmdev->regmap, SUN50I_H6_THS_DIS, &state);
>  
> @@ -173,24 +177,21 @@ static int sun50i_h6_irq_ack(struct ths_device *tmdev)
>  		if (state & SUN50I_H6_THS_DATA_IRQ_STS(i)) {
>  			regmap_write(tmdev->regmap, SUN50I_H6_THS_DIS,
>  				     SUN50I_H6_THS_DATA_IRQ_STS(i));
> -			ret |= BIT(i);
> +			bitmap_set(tmdev->irq_bitmap, i, 1);
>  		}
>  	}
> -
> -	return ret;

The bitfield of the acked interrupts is mostly something internal to the
handler, so I'm not really convinced about sharing that through the
global structure.

With that being said...

>  }
>  
>  static irqreturn_t sun8i_irq_thread(int irq, void *data)
>  {
>  	struct ths_device *tmdev = data;
> -	int i, state;
> +	int i;
>  
> -	state = tmdev->chip->irq_ack(tmdev);
> +	tmdev->chip->irq_ack(tmdev);
>  
> -	for (i = 0; i < tmdev->chip->sensor_num; i++) {
> -		if (state & BIT(i))
> -			thermal_zone_device_update(tmdev->sensor[i].tzd,
> -						   THERMAL_EVENT_UNSPECIFIED);
> +	for_each_set_bit(i, tmdev->irq_bitmap, tmdev->chip->sensor_num) {
> +		thermal_zone_device_update(tmdev->sensor[i].tzd,
> +					   THERMAL_EVENT_UNSPECIFIED);

.. for_each_set_bit is definitely cleaner and more readable.

Since it can operate on any unsigned long pointer, maybe we can just
make irq_ack return an unsigned long, and iterate over it here?

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20201028/0f3f64a2/attachment-0001.sig>


More information about the linux-arm-kernel mailing list