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@xxxxxxxxx/
Happy coding :-)
Paulo A.
