All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: gregkh@linuxfoundation.org, realwakka@gmail.com,
	linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/3] staging: pi433: validate max bit_rate based on modulation used
Date: Wed, 19 Jan 2022 08:34:22 +1300	[thread overview]
Message-ID: <20220118193422.GA3155@mail.google.com> (raw)
In-Reply-To: <20220118135902.GH1951@kadam>

On Tue, Jan 18, 2022 at 04:59:02PM +0300, Dan Carpenter wrote:
> At the same time, this is a GCC warning so it will break the build.
> 
> Instead of applying this patch, I wish you would just make a note of it
> in the drivers/staging/pi433/TODO file.  
> 
>     "Change (struct pi433_tx_cfg)->bit_rate to be a u32 so that we can
>      support bit rates up to 300kbps per the spec."

thanks for taking the time to review this patchset.

It makes sense to me. So essentially for this version of the patchset I
would only validate OOK max bit rate as it fits within the u16 boundary
of the current implementation, right?

Something akin to this:

// check input value
if (bit_rate < 1200 || (mod == OOK && bit_rate > 32768)) {
	dev_dbg(&spi->dev, "setBitRate: illegal input param");
	return -EINVAL;
}

> 
> But you're right that it's complicated to fix this because it's part of
> the UAPI.  I think that the UAPI for pi433 is kind of garbage.  No one
> like custom ioctls.  It would be better to use sysfs.  
> ...
> So my idea is that instead of modifying the custom ioctl then we can
> just add a new sysfs file to set the bit_rate and all the other stuff.
> Eventually we will delete the ioctl after all the users have updated to
> the new userspace.
> 

Using sysfs or even possibly configfs was one of the things I had in
mind too. 

I started a similar discussion on how to change/remove ioctl:
https://lore.kernel.org/kernelnewbies/YeVoAlv0ubKrmckV@kroah.com/T/#t

The tldr;:

If there is a userspace tool that interfaces with char
device and we can change it at the same time as the kernel code then we 
can have a bit more flexibility on how to send/retrieve values to/from 
the driver. If not then we would be required to keep the original ioctl
compatibility even if we move to a different approach due to the
impossibility of knowing whether or not someone is relying on that. :(

Everything leads me to believe that there isn't such userspace tool /
lib so I emailed the original author just to be 100% sure that this is
the case.

thanks,

Paulo Almeida

  reply	other threads:[~2022-01-18 19:34 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-16  0:17 [PATCH 0/3] staging: pi433: validate min/max bit rate settings Paulo Miguel Almeida
2022-01-16  0:21 ` [PATCH 1/3] staging: pi433: fix validation for min bit rate supported by the device Paulo Miguel Almeida
2022-01-16  0:22 ` [PATCH 2/3] staging: pi433: change order in which driver config the rf69 chip Paulo Miguel Almeida
2022-01-16  0:23 ` [PATCH 3/3] staging: pi433: validate max bit_rate based on modulation used Paulo Miguel Almeida
2022-01-16 14:06   ` kernel test robot
2022-01-16 14:06     ` kernel test robot
2022-01-17  5:58     ` [PATCH v2 0/3] staging: pi433: validate min/max bit rate settings Paulo Miguel Almeida
2022-01-17  6:00       ` [PATCH v2 1/3] staging: pi433: fix validation for min bit rate supported by the device Paulo Miguel Almeida
2022-01-17  6:01       ` [PATCH v2 2/3] staging: pi433: change order in which driver config the rf69 chip Paulo Miguel Almeida
2022-01-17  6:02       ` [PATCH v2 3/3] staging: pi433: validate max bit_rate based on modulation used Paulo Miguel Almeida
2022-01-18 13:59         ` Dan Carpenter
2022-01-18 19:34           ` Paulo Miguel Almeida [this message]
2022-01-18 23:03             ` [PATCH v3 0/3] staging: pi433: validate min/max bit rate settings Paulo Miguel Almeida
2022-01-18 23:04               ` [PATCH v3 1/3] staging: pi433: fix validation for min bit rate supported by the device Paulo Miguel Almeida
2022-01-18 23:05               ` [PATCH v3 2/3] staging: pi433: change order in which driver config the rf69 chip Paulo Miguel Almeida
2022-01-18 23:05               ` [PATCH v3 3/3] staging: pi433: validate max bit_rate based on modulation used Paulo Miguel Almeida
2022-01-19  6:04               ` [PATCH v3 0/3] staging: pi433: validate min/max bit rate settings Dan Carpenter
2022-01-23  7:43                 ` Paulo Miguel Almeida
2022-01-24  8:53                   ` Dan Carpenter
2022-01-19  5:34             ` [PATCH v2 3/3] staging: pi433: validate max bit_rate based on modulation used Dan Carpenter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220118193422.GA3155@mail.google.com \
    --to=paulo.miguel.almeida.rodenas@gmail.com \
    --cc=dan.carpenter@oracle.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=realwakka@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.