Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 21 Oct 2022 09:15:53 +1300
From:   Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com>
To:     Gautam Menghani <gautammenghani201@gmail.com>
Cc:     gregkh@linuxfoundation.org, linux-staging@lists.linux.dev,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drivers/staging/pi433: Change data type of bit_rate to
 be u32
Message-ID: <Y1GseU1Z+CCHJs9I@mail.google.com>
References: <20221020181815.31245-1-gautammenghani201@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20221020181815.31245-1-gautammenghani201@gmail.com>
Precedence: bulk

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.