linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: "Yaşar Arabacı" <yasar11732@gmail.com>
Cc: gregkh@linuxfoundation.org,
	paulo.miguel.almeida.rodenas@gmail.com,
	alexandre.belloni@bootlin.com, realwakka@gmail.com,
	u.kleine-koenig@pengutronix.de, linux-staging@lists.linux.dev,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Staging: pi433: Don't use ioctl for per-client configuration
Date: Mon, 16 May 2022 10:33:29 +0300	[thread overview]
Message-ID: <20220516073329.GJ4009@kadam> (raw)
In-Reply-To: <20220515104711.94567-1-yasar11732@gmail.com>

On Sun, May 15, 2022 at 01:47:11PM +0300, Yaşar Arabacı wrote:
> Currently this driver uses ioctl for reading/writing per-device and
> per-client configuration. Per-client configuration can be handled by
> usespace and sent to driver with each write() call. Doing so does not
> introduce extra overhead because we copy tx config to fifo for each
> transmit anyway. This way, we don't have to introduce new ioctl's.
> 
> This has not been tested as I don't have access to hardware.
> 
> Signed-off-by: Yaşar Arabacı <yasar11732@gmail.com>

This commit is confusing and does a number of unrelated things.  It's
not explained well what the motivation is for the patch.

If I remember this correctly, the current API is broken.  It used a
too small type or something?  People wanted fix it by making
incompatible changes which would have broken user space.  I had said
that the right thing would be to not using ioctls at all but instead use
sysfs.

So I kind of remember that there was a motivation to get rid of the
ioctl, but I don't remember what it was and it's not explained here.

I had imagined adding the sysfs configuration along side the ioctl to
start with and then deleting the ioctl when userspace was updated.  If
you're saying that we don't need any configuration at all then that's
great but that has to come from someone who has tested the code.

What is this part of the commit for?

> --- a/drivers/staging/pi433/pi433_if.h
> +++ b/drivers/staging/pi433/pi433_if.h
> @@ -75,6 +75,8 @@ struct pi433_tx_cfg {
>  
>  	__u8			sync_pattern[8];
>  	__u8			address_byte;
> +	__u32			payload_size;
> +	__u8			payload[];
>  };

regards,
dan carpenter


  parent reply	other threads:[~2022-05-16  7:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-15 10:47 [PATCH] Staging: pi433: Don't use ioctl for per-client configuration Yaşar Arabacı
2022-05-15 10:54 ` Greg KH
2022-05-15 10:55 ` Greg KH
2022-05-16  7:33 ` Dan Carpenter [this message]
2022-05-16 17:23   ` Yaşar Arabacı
2022-05-16 11:23 ` kernel test robot
2022-05-16 15:30 ` kernel test robot

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=20220516073329.GJ4009@kadam \
    --to=dan.carpenter@oracle.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=paulo.miguel.almeida.rodenas@gmail.com \
    --cc=realwakka@gmail.com \
    --cc=u.kleine-koenig@pengutronix.de \
    --cc=yasar11732@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).