linux-kernel - Re: [PATCH] drivers/staging/pi433: Change data type of bit

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 21 Oct 2022 09:15:53 +1300
From:   Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@...il.com>
To:     Gautam Menghani <gautammenghani201@...il.com>
Cc:     gregkh@...uxfoundation.org, linux-staging@...ts.linux.dev,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drivers/staging/pi433: Change data type of bit_rate to
 be u32

On Thu, Oct 20, 2022 at 11:48:15PM +0530, Gautam Menghani wrote:
> A TODO asks to convert the bit_rate variable to be a u32 so that bit 
> rates up to 300kbps can be supported as per the spec.
> 
Thanks for sending this patch. Comments added in-line.

> diff --git a/drivers/staging/pi433/pi433_if.h b/drivers/staging/pi433/pi433_if.h
> index 25ee0b77a32c..c958dcfa9f96 100644
> --- a/drivers/staging/pi433/pi433_if.h
> +++ b/drivers/staging/pi433/pi433_if.h
> @@ -51,7 +51,7 @@ enum option_on_off {
>  #define PI433_TX_CFG_IOCTL_NR	0
>  struct pi433_tx_cfg {
>  	__u32			frequency;
> -	__u16			bit_rate;
> +	__u32			bit_rate;
>  	__u32			dev_frequency;
>  	enum modulation		modulation;
>  	enum mod_shaping	mod_shaping;
> @@ -99,7 +99,7 @@ struct pi433_tx_cfg {
>  #define PI433_RX_CFG_IOCTL_NR	1
>  struct pi433_rx_cfg {
>  	__u32			frequency;
> -	__u16			bit_rate;
> +	__u32			bit_rate;
>  	__u32			dev_frequency;
>  
>  	enum modulation		modulation;

Cutting a long story short, you won't be able to change bit_rate's type before 
addressing the fact that both pi433_tx_cfg ans pi433_rx_cfg are part of the UAPI.

Usually there are 2 approaches that most people go for when talking about
changes in drivers:

1) Add changes in a backwards compatible way, so whether users are using the
        bitrate member as u32 or u64, it would simply work. But that leads to
        sometimes hard-to-read code.... but this is still a card up your sleeve.

        One suggestion given by Dan Carpenter was to leave the IOCTL impl alone
        and start a sysfs implementation. That way you could have a u64 bit_rate
        synthetic file.

        https://lore.kernel.org/all/20220119053410.GW1978@kadam/

2) Change the tools that make use of this driver at the same time as you change
        the UAPI. This can be tricky. There is a thread I started in the
        kernelnewbies mailing list on the subject which I think might be relevant
        for you to read.

        https://lore.kernel.org/all/YjHvLFSV06w%2FORgV@kroah.com/

Happy coding :-)

Paulo A.