linux-kernel - Re: [PATCH] xen: Use 'unsigned int' instead of 'unsigned'

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 2 Mar 2020 10:11:00 +0100
From:   Jan Beulich <jbeulich@...e.com>
To:     Yan Yankovskyi <yyankovskyi@...il.com>
Cc:     Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Juergen Gross <jgross@...e.com>,
        Stefano Stabellini <sstabellini@...nel.org>,
        xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] xen: Use 'unsigned int' instead of 'unsigned'

On 29.02.2020 23:30, Yan Yankovskyi wrote:
> Resolve the following warning, reported by checkpatch.pl:
> WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
> 
> No functional change.

IMO a change like this would ideally go a little further and try
to use the actually designated types when adjusting them anyway,
e.g. ...

> --- a/drivers/xen/events/events_2l.c
> +++ b/drivers/xen/events/events_2l.c
> @@ -42,48 +42,48 @@
>  
>  static DEFINE_PER_CPU(xen_ulong_t [EVTCHN_MASK_SIZE], cpu_evtchn_mask);
>  
> -static unsigned evtchn_2l_max_channels(void)
> +static unsigned int evtchn_2l_max_channels(void)
>  {
>  	return EVTCHN_2L_NR_CHANNELS;
>  }
>  
> -static void evtchn_2l_bind_to_cpu(struct irq_info *info, unsigned cpu)
> +static void evtchn_2l_bind_to_cpu(struct irq_info *info, unsigned int cpu)
>  {
>  	clear_bit(info->evtchn, BM(per_cpu(cpu_evtchn_mask, info->cpu)));
>  	set_bit(info->evtchn, BM(per_cpu(cpu_evtchn_mask, cpu)));
>  }
>  
> -static void evtchn_2l_clear_pending(unsigned port)
> +static void evtchn_2l_clear_pending(unsigned int port)

... evtchn_port_t here and elsewhere.

Jan