Address brooks' comments.

In D45237#1032029, @dev_submerge.ch wrote:

The current check is never false and If nvlist_unpack(), we might panic later down the road.

Commit message should probably be "... if nvlist_unpack() fails, ..."?

Address brooks' comment.

In D45236#1031986, @brooks wrote:

You need to decide the type of data based on the command passed before you examine it so you'll need a case statement before the tests. I'd also tend not to assign the arg/arg32 until you've decided the type. Additionally, data will be NULL for at least SNDSTIOC_REFRESH_DEVS and SNDSTIOC_FLUSH_USER_DEVS,

Also it seems like this fallback mechanism is needed by a few other ioctls, so I think it's better to fix all of them in a single patch.

In D45150#1029983, @dev_submerge.ch wrote:

In D45150#1029901, @christos wrote:

@dev_submerge.ch Can you test that this and D45151 fix the problem? I cannot reproduce it right now.

The mixer does see devices now that come after the unavailable ones. But it shows no device description for it.

We're missing a piece of the puzzle, as mixer_oss_mixerinfo() still skips unavailable devices. Which means SNDCTL_MIXERINFO returns an error instead of a device with enabled == 0, thus breaking the ossinfo utility from audio/oss, and probably other software using the same approach.

@dev_submerge.ch Can you test that this and D45151 fix the problem? I cannot reproduce it right now.

In D45144#1029831, @dev_submerge.ch wrote:

This is ok as is, but it has the same problem as SNDCTL_MIXERINFO: We should consider returning "blank" oss_card_info structs for unavailable devices / device indices, instead of an error. Current implementation breaks audio/oss and probably kodi when devices are unavailable, since they stop iterating the SNDCTL_CARDINFO indices if there's an error. There is no enabled in oss_card_info to signal that a device is unavailable, but the info is mostly descriptive. We could return "unavailable" or something like that in the strings, which would hopefully be picked up by the application and shown to the user.

In D45135#1029509, @dev_submerge.ch wrote:

Maybe unrelated to this particular piece of code, but I did some tests with two USB sound cards. When I remove the first one (pcm0), the mixer application reveals some flaws:

<flo@current:~> mixer -a
mixer: /dev/mixer0: no such mixer

<flo@current:~> mixer
pcm1:mixer: (play/rec) (default)
    vol       = 0.75:0.75     pbk
    pcm       = 0.75:0.75     pbk

Note that while the mixer default pcm is correct (pcm1), there's no sound card identifier like when I have both plugged in:

<flo@current:~> mixer -a
pcm0:mixer: <Roland EDIROL UA-25EX> on uaudio0 (play/rec)
    vol       = 0.75:0.75     pbk
    pcm       = 0.75:0.75     pbk
pcm1:mixer: <RME Babyface (23607206)> on uaudio1 (play/rec) (default)
    vol       = 0.75:0.75     pbk
    pcm       = 0.75:0.75     pbk

<flo@current:~> mixer
pcm1:mixer: <RME Babyface (23607206)> on uaudio1 (play/rec) (default)
    vol       = 0.75:0.75     pbk
    pcm       = 0.75:0.75     pbk

Possibly related bug report.

I do not really have the hardware to test the driver, but the code looks good to me at a first glance.

In D45135#1029486, @emaste wrote:

Regarding the race, it maybe be very hard to hit it

I just mean that I think the race doesn't even matter because the issue is identical if you remove the device any time prior to the mixer_oss_mixerinfo call?

In D45135#1029480, @emaste wrote:

This seems sensible; I'd expect mixer 1 to refer to /dev/mixer1 not whatever the second mixer happens to be. I don't think a race condition like you describe is even required, right? Removing the device providing /dev/mixer0 means the system will always be in this state?

s/real_device/legacy_device/

Update commit message and filler size according to most recent soundcard.h
version.

In D45100#1028617, @christos wrote:

In D45100#1028614, @emaste wrote:

I couldn't find a useful reference for a name elsewhere so I think it's fine, although I might go with LENOVO_IDEAPAD3_SUBVENDOR

I chose I3 instead of IDEAPAD3 so as to follow the convention used for LENOVO_I330_SUBVENDOR, which is used for Ideapad 330.

I propose to make a follow-up patch to change both to IDEAPAD*.

In D45100#1028614, @emaste wrote:

I couldn't find a useful reference for a name elsewhere so I think it's fine, although I might go with LENOVO_IDEAPAD3_SUBVENDOR

Since the user told me his exact laptop model is:
Lenovo Ideapad 3 17IAU7
CPU: 12th Gen Intel(R) Core(TM) i3-1215U