On Do, 2018-12-13 at 15:16 +0300, Dan Carpenter wrote:
> On Wed, Dec 12, 2018 at 01:15:26PM +0100, Christian Gromm wrote:
> >
> > @@ -571,6 +600,40 @@ static int audio_probe_channel(struct
> > most_interface *iface, int channel_id,
> > return -EINVAL;
> > }
> >
> > + ret = split_arg_list(arg_list, &card_name, &ch_num,
> > &sample_res,
> > + &create);
> > + if (ret < 0)
> > + return ret;
> > +
> > + list_for_each_entry(adpt, &adpt_list, list) {
> > + if (adpt->iface == iface && adpt->registered)
> > + return -ENOSPC;
> > + if (!adpt->registered) {
> > + adpt->pcm_dev_idx++;
> > + goto skip_adpt_alloc;
> We haven't ensured the adpt->iface == iface.
>
> >
> > + }
> > + }
> Probably you want to say:
>
> list_for_each_entry(adpt, &adpt_list, list) {
> if (adpt->iface != iface)
> continue;
> if (adpt->registered)
> return -ENOSPC;
> adpt->pcm_dev_idx++;
> goto skip_adpt_alloc;
> }
>
I do.
> But here again, I think I might prefer if allocating a new "adpt"
> were
> and explicit command from user space as opposed to just a side effect
> of
> registering a new iface.
>
Sounds reasonable. But, problem here is that we want the
process of how channels are linked to be independent from the
component that is being used. That's when things start to
become complicated.
In other words, I don't want the sound module to be configured
in a different way than the cdev module, networking module or the
v4l2 module is. The goal was to have only sysfs files that
are generic (->default attrs of most_core mod) and apply to all
components.
The latest change of the sound module creates the need of
signaling that the user is done with the config of the ALSA card.
The quickest way to achieve this, was to expand the "module
parameter" field (which we already have) with the "create" flag
that is passed to the module when a channel is being probed as a
trigger.
Because no other module needs such a trigger, creating a dedicated
sysfs file for this purpose seemed kind of weird, especially when
the sound module isn't loaded at all.
Maybe the sound module should create its own file, but since it
has no struct device embedded, I'm not sure how to achieve that :/
thanks,
Chris
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
