Use SZ_4K from size.h instead of hardcoding constant.

Signed-off-by: Raag Jadav <raag.jadav@intel.com>
---
 drivers/pwm/pwm-dwc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-dwc.c b/drivers/pwm/pwm-dwc.c
index b6c16139ce4a..86b72db58741 100644
--- a/drivers/pwm/pwm-dwc.c
+++ b/drivers/pwm/pwm-dwc.c
@@ -22,13 +22,14 @@
 #include <linux/pci.h>
 #include <linux/pm_runtime.h>
 #include <linux/pwm.h>
+#include <linux/sizes.h>
 
 #include "pwm-dwc.h"
 
 /* Elkhart Lake */
 static const struct dwc_pwm_info ehl_pwm_info = {
 	.nr = 2,
-	.size = 0x1000,
+	.size = SZ_4K,
 };
 
 static int dwc_pwm_init_one(struct device *dev, struct dwc_pwm_drvdata *ddata, unsigned int idx)
-- 
2.43.0

Hello,

On Mon, Jan 05, 2026 at 02:47:37PM +0530, Raag Jadav wrote:
> Use SZ_4K from size.h instead of hardcoding constant.
> 
> Signed-off-by: Raag Jadav <raag.jadav@intel.com>
> ---
>  drivers/pwm/pwm-dwc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pwm/pwm-dwc.c b/drivers/pwm/pwm-dwc.c
> index b6c16139ce4a..86b72db58741 100644
> --- a/drivers/pwm/pwm-dwc.c
> +++ b/drivers/pwm/pwm-dwc.c
> @@ -22,13 +22,14 @@
>  #include <linux/pci.h>
>  #include <linux/pm_runtime.h>
>  #include <linux/pwm.h>
> +#include <linux/sizes.h>
>  
>  #include "pwm-dwc.h"
>  
>  /* Elkhart Lake */
>  static const struct dwc_pwm_info ehl_pwm_info = {
>  	.nr = 2,
> -	.size = 0x1000,
> +	.size = SZ_4K,
>  };

I don't feel strong if this is an improvement or not. I applied it now
with s,size.h,linux/sizes.h, in the commit log.

Best regards
Uwe

On Mon, Jan 05, 2026 at 02:47:37PM +0530, Raag Jadav wrote:
> Use SZ_4K from size.h instead of hardcoding constant.

Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

OTOH, not sure if it's just an unneeded churn. What was the motivation to
create this patch?

-- 
With Best Regards,
Andy Shevchenko

On Mon, Jan 05, 2026 at 06:41:48PM +0200, Andy Shevchenko wrote:
> On Mon, Jan 05, 2026 at 02:47:37PM +0530, Raag Jadav wrote:
> > Use SZ_4K from size.h instead of hardcoding constant.
> 
> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Thank you.

> OTOH, not sure if it's just an unneeded churn. What was the motivation to
> create this patch?

Your hard work[1] continues to motivate me :)

[1] https://lore.kernel.org/r/20250825163545.39303-3-andriy.shevchenko@linux.intel.com

Raag

On Mon, Jan 05, 2026 at 05:51:34PM +0100, Raag Jadav wrote:
> On Mon, Jan 05, 2026 at 06:41:48PM +0200, Andy Shevchenko wrote:
> > On Mon, Jan 05, 2026 at 02:47:37PM +0530, Raag Jadav wrote:
> > > Use SZ_4K from size.h instead of hardcoding constant.
> > 
> > Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> 
> Thank you.
> 
> > OTOH, not sure if it's just an unneeded churn. What was the motivation to
> > create this patch?

> Your hard work[1] continues to motivate me :)

Ha-ha, but that one has a principal difference, i.e. there was _a custom macro_
*already*, which was replaced with a generic one. From the code perspective
it's not a churn as it kills the unneeded custom macro. Here the situation is
different, i.e. the explicit number 0x1000 is changed to SZ_4K. Just a line to
change, the added header inclusion and no other changes, so as a standalone one
it sounds to me like a churn.

> [1] https://lore.kernel.org/r/20250825163545.39303-3-andriy.shevchenko@linux.intel.com

-- 
With Best Regards,
Andy Shevchenko

On Mon, Jan 05, 2026 at 08:07:07PM +0200, Andy Shevchenko wrote:
> On Mon, Jan 05, 2026 at 05:51:34PM +0100, Raag Jadav wrote:
> > On Mon, Jan 05, 2026 at 06:41:48PM +0200, Andy Shevchenko wrote:
> > > On Mon, Jan 05, 2026 at 02:47:37PM +0530, Raag Jadav wrote:
> > > > Use SZ_4K from size.h instead of hardcoding constant.
> > > 
> > > Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > 
> > Thank you.
> > 
> > > OTOH, not sure if it's just an unneeded churn. What was the motivation to
> > > create this patch?
> 
> > Your hard work[1] continues to motivate me :)
> 
> Ha-ha, but that one has a principal difference, i.e. there was _a custom macro_
> *already*, which was replaced with a generic one. From the code perspective
> it's not a churn as it kills the unneeded custom macro. Here the situation is
> different, i.e. the explicit number 0x1000 is changed to SZ_4K. Just a line to
> change, the added header inclusion and no other changes, so as a standalone one
> it sounds to me like a churn.

Fair, but converting to standard macro is noteworthy IMHO.
I'll leave the final call to you all.

Raag

> > [1] https://lore.kernel.org/r/20250825163545.39303-3-andriy.shevchenko@linux.intel.com