kybaaz/linux-xiaomi-chiron
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

ALSA: control - add generic LED API

Browse source 
This patchset tries to resolve the diversity in the audio LED
 control among the ALSA drivers. A new control layer registration
 is introduced which allows to run additional operations on
 top of the elementary ALSA sound controls.
 
 A new control access group (three bits in the access flags)
 was introduced to carry the LED group information for
 the sound controls. The low-level sound drivers can just
 mark those controls using this access group. This information
 is not exported to the user space, but user space can
 manage the LED sound control associations through sysfs
 (last patch) per Mark's request. It makes things fully
 configurable in the kernel and user space (UCM).
 
 The actual state ('route') evaluation is really easy
 (the minimal value check for all channels / controls / cards).
 If there's more complicated logic for a given hardware,
 the card driver may eventually export a new read-only
 sound control for the LED group and do the logic itself.
 
 The new LED trigger control code is completely separated
 and possibly optional (there's no symbol dependency).
 The full code separation allows eventually to move this
 LED trigger control to the user space in future.
 Actually it replaces the already present functionality
 in the kernel space (HDA drivers) and allows a quick adoption
 for the recent hardware (ASoC codecs including SoundWire).
 
 snd_ctl_led            24576  0
 
 The sound driver implementation is really easy:
 
 1) call snd_ctl_led_request() when control LED layer should be
    automatically activated
    / it calls module_request("snd-ctl-led") on demand /
 2) mark all related kcontrols with
         SNDRV_CTL_ELEM_ACCESS_SPK_LED or
         SNDRV_CTL_ELEM_ACCESS_MIC_LED
 
 Link: https://lore.kernel.org/r/20210317172945.842280-1-perex@perex.cz
 Signed-off-by: Takashi Iwai <tiwai@suse.de>
 -----BEGIN PGP SIGNATURE-----
 
 iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmBjRuQOHHRpd2FpQHN1
 c2UuZGUACgkQLtJE4w1nLE9ZQw/6Ao2X1io4TVnyO/gO8HtwmnZ6TWcrLUlySaep
 H6Suf0RHsOQO9VOaMcUarA3Wnz1vZ44qJ/fkdLTslnIPGSRJDUx15bbb+n2N6pQJ
 gS7Umxy6n73rQyEoDjd3ZorvDGjFSVFpjM+RYjk/Ohq+yziz7nQ/SZuHPPeqm1GU
 C5d9SxyXGdqlJJ6yFCHzbtjSmIey+l1TZ+j3rSSww/CzDKxB2l5J6JZAMUjVdL9b
 J80Mcw0XLdG9iTtEnkUt3TwvLMcMl95UPeQHIkVQlwsRRb3BtHNIwJLPQ/n+Cou7
 Hre3y2miUYHrNICEzMdMlpDzQBqu5wvpXgbgIV0CwAwCXPZBVWE1hVJ9gG0l+r1G
 fy1a75OmEin4V9g8w+wNTWDEgjwAOkWhA67WVjpbvHtd6kEbISzt4JHFksG1rjU2
 vXOIj2VBmQN6zHtxfcZqY8Ge4A7XGo7tAM/3NsUxin+2y7ZXI6sDvv+0esYmqrYr
 9as/tD84L5LTrbUYewaUgEdauQXluQI1egRi7pSeg7hZyLeYYkmszk54Ra3zdlmM
 m7Hr6u+Y/G7yeFdn/WdeG3VzdmxhC2ZFfk3gq0vneBS3WrATbf6nAORp2bwzGSz4
 pUsVLSv+vhpZdSF+IxpUuMnsLkkbUCvFivXLjQ6irSWvp7uts1HWdRowdg7Pe2lC
 FVbFRuA=
 =1uM7
 -----END PGP SIGNATURE-----

Merge tag 'tags/mute-led-rework' into for-next

ALSA: control - add generic LED API

This patchset tries to resolve the diversity in the audio LED
control among the ALSA drivers. A new control layer registration
is introduced which allows to run additional operations on
top of the elementary ALSA sound controls.

A new control access group (three bits in the access flags)
was introduced to carry the LED group information for
the sound controls. The low-level sound drivers can just
mark those controls using this access group. This information
is not exported to the user space, but user space can
manage the LED sound control associations through sysfs
(last patch) per Mark's request. It makes things fully
configurable in the kernel and user space (UCM).

The actual state ('route') evaluation is really easy
(the minimal value check for all channels / controls / cards).
If there's more complicated logic for a given hardware,
the card driver may eventually export a new read-only
sound control for the LED group and do the logic itself.

The new LED trigger control code is completely separated
and possibly optional (there's no symbol dependency).
The full code separation allows eventually to move this
LED trigger control to the user space in future.
Actually it replaces the already present functionality
in the kernel space (HDA drivers) and allows a quick adoption
for the recent hardware (ASoC codecs including SoundWire).

snd_ctl_led            24576  0

The sound driver implementation is really easy:

1) call snd_ctl_led_request() when control LED layer should be
   automatically activated
   / it calls module_request("snd-ctl-led") on demand /
2) mark all related kcontrols with
        SNDRV_CTL_ELEM_ACCESS_SPK_LED or
        SNDRV_CTL_ELEM_ACCESS_MIC_LED

Link: https://lore.kernel.org/r/20210317172945.842280-1-perex@perex.cz
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit is contained in:
Takashi Iwai 2021-03-30 17:42:40 +02:00
commit 5b1ed7df01
1390 changed files with 12867 additions and 7336 deletions
Download patch file Download diff file Expand all files Collapse all files

17
include/uapi/linux/bpf.h
View file

@ -3850,8 +3850,7 @@ union bpf_attr {
*
* long bpf_check_mtu(void *ctx, u32 ifindex, u32 *mtu_len, s32 len_diff, u64 flags)
* Description
* Check ctx packet size against exceeding MTU of net device (based
* Check packet size against exceeding MTU of net device (based
* on *ifindex*). This helper will likely be used in combination
* with helpers that adjust/change the packet size.
*
@ -3868,6 +3867,14 @@ union bpf_attr {
* against the current net device. This is practical if this isn't
* used prior to redirect.
*
* On input *mtu_len* must be a valid pointer, else verifier will
* reject BPF program. If the value *mtu_len* is initialized to
* zero then the ctx packet size is use. When value *mtu_len* is
* provided as input this specify the L3 length that the MTU check
* is done against. Remember XDP and TC length operate at L2, but
* this value is L3 as this correlate to MTU and IP-header tot_len
* values which are L3 (similar behavior as bpf_fib_lookup).
*
* The Linux kernel route table can configure MTUs on a more
* specific per route level, which is not provided by this helper.
* For route level MTU checks use the **bpf_fib_lookup**\ ()
@ -3892,11 +3899,9 @@ union bpf_attr {
*
* On return *mtu_len* pointer contains the MTU value of the net
* device. Remember the net device configured MTU is the L3 size,
* which is returned here and XDP and TX length operate at L2.
* which is returned here and XDP and TC length operate at L2.
* Helper take this into account for you, but remember when using
* MTU value in your BPF-code. On input *mtu_len* must be a valid
* pointer and be initialized (to zero), else verifier will reject
* BPF program.
* MTU value in your BPF-code.
*
* Return
* * 0 on success, and populate MTU value in *mtu_len* pointer.

3
include/uapi/linux/fuse.h
View file

@ -903,7 +903,8 @@ struct fuse_notify_retrieve_in {
};
/* Device ioctls: */
#define FUSE_DEV_IOC_CLONE _IOR(229, 0, uint32_t)
#define FUSE_DEV_IOC_MAGIC 229
#define FUSE_DEV_IOC_CLONE _IOR(FUSE_DEV_IOC_MAGIC, 0, uint32_t)
struct fuse_lseek_in {
uint64_t fh;

1
include/uapi/linux/l2tp.h
View file

@ -145,6 +145,7 @@ enum {
L2TP_ATTR_RX_ERRORS, /* u64 */
L2TP_ATTR_STATS_PAD,
L2TP_ATTR_RX_COOKIE_DISCARDS, /* u64 */
L2TP_ATTR_RX_INVALID, /* u64 */
__L2TP_ATTR_STATS_MAX,
};

2
include/uapi/linux/netfilter/nfnetlink_cthelper.h
View file

@ -5,7 +5,7 @@
#define NFCT_HELPER_STATUS_DISABLED 0
#define NFCT_HELPER_STATUS_ENABLED 1
enum nfnl_acct_msg_types {
enum nfnl_cthelper_msg_types {
NFNL_MSG_CTHELPER_NEW,
NFNL_MSG_CTHELPER_GET,
NFNL_MSG_CTHELPER_DEL,

5
include/uapi/linux/psample.h
View file

@ -3,7 +3,6 @@
#define __UAPI_PSAMPLE_H
enum {
/* sampled packet metadata */
PSAMPLE_ATTR_IIFINDEX,
PSAMPLE_ATTR_OIFINDEX,
PSAMPLE_ATTR_ORIGSIZE,
@ -11,10 +10,8 @@ enum {
PSAMPLE_ATTR_GROUP_SEQ,
PSAMPLE_ATTR_SAMPLE_RATE,
PSAMPLE_ATTR_DATA,
PSAMPLE_ATTR_TUNNEL,
/* commands attributes */
PSAMPLE_ATTR_GROUP_REFCOUNT,
PSAMPLE_ATTR_TUNNEL,
__PSAMPLE_ATTR_MAX
};