Linux Sound subsystem development
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: "Geoffrey D. Bennett" <g@b4.vu>
Cc: Takashi Iwai <tiwai@suse.de>, Takashi Iwai <tiwai@suse.com>,
	linux-sound@vger.kernel.org
Subject: Re: [PATCH v4 1/2] ALSA: FCP: Add Focusrite Control Protocol driver
Date: Fri, 10 Jan 2025 18:03:02 +0100	[thread overview]
Message-ID: <87tta6txdl.wl-tiwai@suse.de> (raw)
In-Reply-To: <931600fcf8a23173a474f4768ec844cebc096b5b.1736007881.git.g@b4.vu>

On Sat, 04 Jan 2025 18:12:54 +0100,
Geoffrey D. Bennett wrote:
> +/* Get protocol version */
> +#define FCP_IOCTL_PVERSION _IOR('S', 0x60, int)
> +
> +/* Start the protocol */
> +
> +/* Step 0 and step 2 responses are variable length and placed in
> + * resp[] one after the other.
> + */
> +struct fcp_init_v1 {
> +	__u32 version;
> +	__u16 step0_resp_size;
> +	__u16 step2_resp_size;
> +	__u32 init1_opcode;
> +	__u32 init2_opcode;
> +	__u8  resp[];
> +} __attribute__((packed));
> +
> +union fcp_init {
> +	__u32 version;
> +	struct fcp_init_v1 v1;
> +};
> +
> +#define FCP_IOCTL_INIT _IOWR('S', 0x64, union fcp_init)

I don't think this version and union are needed.
If you need a different way of initialization, you can provide simply
a new ioctl, instead of keeping the same ioctl and handles something
conditionally in a complex way.

Also, in which situation should the init ioctl be performed?
And in which situation it shouldn't (must not) be performed?
Currently the driver seems allowing to run it at any time.  e.g. what
happens if the init ioctl is called while you're playing or recording
streams?  The same question is applied to the fcp_cmd, too.

> +static int fcp_hwdep_open(struct snd_hwdep *hw, struct file *file)
> +{
> +	struct usb_mixer_interface *mixer = hw->private_data;
> +	struct fcp_data *private = mixer->private_data;
> +
> +	if (!capable(CAP_SYS_RAWIO))
> +		return -EPERM;

So now you limit the hwdep operation essentially only to root user.
Is it intended, right?  That is, the hwdep should be accessed only at
probe time for configuring the stuff (preferably some service or udev
stuff)?

Maybe it'd be helpful to give some "big picture" to indicate how
things should work.  Also, the more proper documentation should be
provided for the hwdep interface, too.  The kernel doc in comments
should be fine, too.


Last but not least, I don't think we need to split to two patches.
The second patch merely adds the setup hook, and this can be folded
into the main patch.


thanks,

Takashi

  reply	other threads:[~2025-01-10 17:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-04 17:11 [PATCH v4 0/2] ALSA: Add driver for big Scarlett 4th Gen interfaces Geoffrey D. Bennett
2025-01-04 17:12 ` [PATCH v4 1/2] ALSA: FCP: Add Focusrite Control Protocol driver Geoffrey D. Bennett
2025-01-10 17:03   ` Takashi Iwai [this message]
2025-01-04 17:13 ` [PATCH v4 2/2] ALSA: scarlett2: Add device_setup option to use FCP driver Geoffrey D. Bennett

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=87tta6txdl.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=g@b4.vu \
    --cc=linux-sound@vger.kernel.org \
    --cc=tiwai@suse.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