Searched +hist:5 +hist:bae4199 (Results 1 - 2 of 2) sorted by relevance

/linux-master/drivers/input/misc/
H A DKconfigdiff f1d2809d Mon Mar 22 17:43:58 MDT 2021 Jeff LaBundy <jeff@labundy.com> Input: Add support for Azoteq IQS626A

This patch adds support for the Azoteq IQS626A capacitive touch
controller.

Signed-off-by: Jeff LaBundy <jeff@labundy.com>
Link: https://lore.kernel.org/r/20210301234928.4298-5-jeff@labundy.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
diff 5d96738d Tue Oct 29 18:04:02 MDT 2019 Dmitry Torokhov <dmitry.torokhov@gmail.com> Input: cobalt_btns - switch to using polled mode of input devices

We have added polled mode to the normal input devices with the intent of
retiring input_polled_dev. This converts cobalt_btns driver to use
the polling mode of standard input devices and removes dependency on
INPUT_POLLDEV.

Link: https://lore.kernel.org/r/20191017204217.106453-13-dmitry.torokhov@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
diff c3941593 Sat Jul 27 02:25:38 MDT 2019 Maximilian Luz <luzmaximilian@gmail.com> Input: soc_button_array - add support for newer surface devices

Power and volume button support for 5th and 6th generation Microsoft
Surface devices via soc_button_array.

Note that these devices use the same MSHW0040 device as on the Surface
Pro 4, however the implementation is different (GPIOs vs. ACPI
notifications). Thus some checking is required to ensure we only load
this driver on the correct devices.

Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
diff 0f681d09 Wed Feb 06 10:49:41 MST 2019 Brian Masney <masneyb@onstation.org> Input: add new vibrator driver for various MSM SOCs

This patch adds a new vibrator driver that supports various Qualcomm
MSM SOCs. Driver was tested on a LG Nexus 5 (hammerhead) phone.

Signed-off-by: Brian Masney <masneyb@onstation.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
diff 5fb94e9c Tue May 08 12:14:57 MDT 2018 Mauro Carvalho Chehab <mchehab+samsung@kernel.org> docs: Fix some broken references

As we move stuff around, some doc references are broken. Fix some of
them via this script:
./scripts/documentation-file-ref-check --fix

Manually checked if the produced result is valid, removing a few
false-positives.

Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Coly Li <colyli@suse.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Jonathan Corbet <corbet@lwn.net>
diff 5a35b85c Mon Jul 24 16:57:12 MDT 2017 Joseph Chen <chenjh@rock-chips.com> Input: add power key driver for Rockchip RK805 PMIC

This driver provides a input driver for the power key on the Rockchip RK805
PMIC.

Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
diff 5b6c26a9 Mon Dec 29 12:20:54 MST 2014 Carlo Caione <carlo@caione.org> Input: add driver for AXP20x Power Enable Key

This change adds support for the Power Enable Key found on MFD AXP202
and AXP209. Besides the basic support for the button, the driver adds
two entries in sysfs to configure the time delay for power on/off.

Signed-off-by: Carlo Caione <carlo@caione.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
[wens@csie.org: made axp20x_pek_remove() static; removed driver owner
field; fixed path for sysfs entries]
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
diff 5fafed3e Sat Dec 27 21:37:37 MST 2014 Felipe Balbi <balbi@ti.com> Input: add tps65218 power button driver

With this driver, we can report KEY_POWER on AM437x SK. This patch has been
tested with said board.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
diff 5b2e303f Fri Oct 29 13:08:28 MDT 2010 David Härdeman <david@hardeman.nu> [media] rc-core: convert winbond-cir

Move winbond-cir from drivers/input/misc/ into drivers/media/rc/
and convert it to use rc-core.

Signed-off-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
diff 5bae4199 Wed Apr 23 02:50:32 MDT 2008 Stas Sergeev <stsp@aknet.ru> pcsp - Don't build pcspkr when snd-pcsp is enabled

- Update CREDITS with the pc-speaker driver authors.
- Prevent pcspkr from being built together with snd-pcsp.
Both pcspkr and snd-pcsp use the same platform driver name "pcspkr".

Signed-off-by: Stas Sergeev <stsp@aknet.ru>
diff 5bae4199 Wed Apr 23 02:50:32 MDT 2008 Stas Sergeev <stsp@aknet.ru> pcsp - Don't build pcspkr when snd-pcsp is enabled

- Update CREDITS with the pc-speaker driver authors.
- Prevent pcspkr from being built together with snd-pcsp.
Both pcspkr and snd-pcsp use the same platform driver name "pcspkr".

Signed-off-by: Stas Sergeev <stsp@aknet.ru>
/linux-master/
H A DCREDITSdiff b59d8485 Tue Jan 09 09:45:12 MST 2024 Jakub Kicinski <kuba@kernel.org> MAINTAINERS: eth: mt7530: move Landen Chao to CREDITS

mt7530 is a pretty active driver and last we have heard
from Landen Chao on the list was March. There were total
of 4 message from them in the last 2.5 years.
I think it's time to move to CREDITS.

Subsystem MEDIATEK SWITCH DRIVER
Changes 94 / 169 (55%)
Last activity: 2023-10-11
Arınç ÜNAL <arinc.unal@arinc9.com>:
Author e94b590abfff 2023-08-19 00:00:00 12
Tags e94b590abfff 2023-08-19 00:00:00 16
Daniel Golle <daniel@makrotopia.org>:
Author 91daa4f62ce8 2023-04-19 00:00:00 17
Tags ac49b992578d 2023-10-11 00:00:00 20
Landen Chao <Landen.Chao@mediatek.com>:
DENG Qingfang <dqfext@gmail.com>:
Author 342afce10d6f 2021-10-18 00:00:00 24
Tags 342afce10d6f 2021-10-18 00:00:00 25
Sean Wang <sean.wang@mediatek.com>:
Tags c288575f7810 2020-09-14 00:00:00 5
Top reviewers:
[46]: f.fainelli@gmail.com
[29]: andrew@lunn.ch
[19]: olteanv@gmail.com
INACTIVE MAINTAINER Landen Chao <Landen.Chao@mediatek.com>

Acked-by: Arınç ÜNAL <arinc.unal@arinc9.com>
Link: https://lore.kernel.org/r/20240109164517.3063131-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
diff da14d1fe Tue Jan 09 09:45:11 MST 2024 Jakub Kicinski <kuba@kernel.org> MAINTAINERS: eth: mtk: move John to CREDITS

John is still active in other bits of the kernel but not much
on the MediaTek ethernet switch side. Our scripts report:

Subsystem MEDIATEK ETHERNET DRIVER
Changes 81 / 384 (21%)
Last activity: 2023-12-21
Felix Fietkau <nbd@nbd.name>:
Author c6d96df9fa2c 2023-05-02 00:00:00 42
Tags c6d96df9fa2c 2023-05-02 00:00:00 48
John Crispin <john@phrozen.org>:
Sean Wang <sean.wang@mediatek.com>:
Author 880c2d4b2fdf 2019-06-03 00:00:00 5
Tags a5d75538295b 2020-04-07 00:00:00 7
Mark Lee <Mark-MC.Lee@mediatek.com>:
Author 8d66a8183d0c 2019-11-14 00:00:00 4
Tags 8d66a8183d0c 2019-11-14 00:00:00 4
Lorenzo Bianconi <lorenzo@kernel.org>:
Author 7cb8cd4daacf 2023-12-21 00:00:00 98
Tags 7cb8cd4daacf 2023-12-21 00:00:00 112
Top reviewers:
[18]: horms@kernel.org
[15]: leonro@nvidia.com
[8]: rmk+kernel@armlinux.org.uk
INACTIVE MAINTAINER John Crispin <john@phrozen.org>

Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: John Crispin <john@phrozen.org>
Link: https://lore.kernel.org/r/20240109164517.3063131-2-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
diff 5c28913e Mon Dec 18 06:28:31 MST 2023 Bagas Sanjaya <bagasdotme@gmail.com> MAINTAINERS: remove Ohad Ben-Cohen from hwspinlock subsystem

Commit 62c46d55688894 ("MAINTAINERS: Removing Ohad from remoteproc/rpmsg
maintenance") removes his MAINTAINERS entry in regards to remoteproc
subsystem due to his inactivity (the last commit with his Signed-off-by is
99c429cb4e628e ("remoteproc/wkup_m3: Use MODULE_DEVICE_TABLE to export
alias") which is authored in 2015 and his last LKML message prior to
62c46d55688894 was [1]).

Remove also his MAINTAINERS entry for hwspinlock subsystem as there is no
point of Cc'ing maintainers who never respond in a long time.

[1]: https://lore.kernel.org/r/CAK=Wgbbcyi36ef1-PV8VS=M6nFoQnFGUDWy6V7OCnkt0dDrtfg@mail.gmail.com/

Link: https://lkml.kernel.org/r/20231218132830.5104-2-bagasdotme@gmail.com
Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
Acked-by: Ohad Ben Cohen <ohad@wizery.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: Bjorn Andersson <andersson@kernel.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
diff 054c4610 Wed Jan 13 18:49:12 MST 2021 Jakub Kicinski <kuba@kernel.org> MAINTAINERS: dccp: move Gerrit Renker to CREDITS

As far as I can tell we haven't heard from Gerrit for roughly
5 years now. DCCP patch would really benefit from some review.
Gerrit was the last maintainer so mark this entry as orphaned.

Subsystem DCCP PROTOCOL
Changes 38 / 166 (22%)
(No activity)
Top reviewers:
[6]: kstewart@linuxfoundation.org
[6]: allison@lohutok.net
[5]: edumazet@google.com
INACTIVE MAINTAINER Gerrit Renker <gerrit@erg.abdn.ac.uk>

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
diff 054c4610 Wed Jan 13 18:49:12 MST 2021 Jakub Kicinski <kuba@kernel.org> MAINTAINERS: dccp: move Gerrit Renker to CREDITS

As far as I can tell we haven't heard from Gerrit for roughly
5 years now. DCCP patch would really benefit from some review.
Gerrit was the last maintainer so mark this entry as orphaned.

Subsystem DCCP PROTOCOL
Changes 38 / 166 (22%)
(No activity)
Top reviewers:
[6]: kstewart@linuxfoundation.org
[6]: allison@lohutok.net
[5]: edumazet@google.com
INACTIVE MAINTAINER Gerrit Renker <gerrit@erg.abdn.ac.uk>

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
diff 0e4ed0b6 Wed Jan 13 18:49:10 MST 2021 Jakub Kicinski <kuba@kernel.org> MAINTAINERS: tls: move Aviad to CREDITS

Aviad wrote parts of the initial TLS implementation
but hasn't been contributing to TLS since.

Subsystem NETWORKING [TLS]
Changes 123 / 308 (39%)
Last activity: 2020-12-01
Boris Pismenny <borisp@nvidia.com>:
Tags 138559b9f99d 2020-11-17 00:00:00 1
Aviad Yehezkel <aviadye@nvidia.com>:
John Fastabend <john.fastabend@gmail.com>:
Author e91de6afa81c 2020-06-01 00:00:00 22
Tags e91de6afa81c 2020-06-01 00:00:00 29
Daniel Borkmann <daniel@iogearbox.net>:
Author c16ee04c9b30 2018-10-20 00:00:00 7
Committer b8e202d1d1d0 2020-02-21 00:00:00 19
Tags b8e202d1d1d0 2020-02-21 00:00:00 28
Jakub Kicinski <kuba@kernel.org>:
Author 5c39f26e67c9 2020-11-27 00:00:00 89
Committer d31c08007523 2020-12-01 00:00:00 15
Tags d31c08007523 2020-12-01 00:00:00 117
Top reviewers:
[50]: dirk.vandermerwe@netronome.com
[26]: simon.horman@netronome.com
[14]: john.hurley@netronome.com
INACTIVE MAINTAINER Aviad Yehezkel <aviadye@nvidia.com>

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
diff 5e62d124 Wed Jan 13 18:49:08 MST 2021 Jakub Kicinski <kuba@kernel.org> MAINTAINERS: vrf: move Shrijeet to CREDITS

Shrijeet has moved on from VRF-related work.

Subsystem VRF
Changes 30 / 120 (25%)
Last activity: 2020-12-09
David Ahern <dsahern@kernel.org>:
Author 1b6687e31a2d 2020-07-23 00:00:00 1
Tags 9125abe7b9cb 2020-12-09 00:00:00 4
Shrijeet Mukherjee <shrijeet@gmail.com>:
Top reviewers:
[13]: dsahern@gmail.com
[4]: dsa@cumulusnetworks.com
INACTIVE MAINTAINER Shrijeet Mukherjee <shrijeet@gmail.com>

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
diff fddb5d43 Sat Jan 18 05:07:59 MST 2020 Aleksa Sarai <cyphar@cyphar.com> open: introduce openat2(2) syscall

/* Background. */
For a very long time, extending openat(2) with new features has been
incredibly frustrating. This stems from the fact that openat(2) is
possibly the most famous counter-example to the mantra "don't silently
accept garbage from userspace" -- it doesn't check whether unknown flags
are present[1].

This means that (generally) the addition of new flags to openat(2) has
been fraught with backwards-compatibility issues (O_TMPFILE has to be
defined as __O_TMPFILE|O_DIRECTORY|[O_RDWR or O_WRONLY] to ensure old
kernels gave errors, since it's insecure to silently ignore the
flag[2]). All new security-related flags therefore have a tough road to
being added to openat(2).

Userspace also has a hard time figuring out whether a particular flag is
supported on a particular kernel. While it is now possible with
contemporary kernels (thanks to [3]), older kernels will expose unknown
flag bits through fcntl(F_GETFL). Giving a clear -EINVAL during
openat(2) time matches modern syscall designs and is far more
fool-proof.

In addition, the newly-added path resolution restriction LOOKUP flags
(which we would like to expose to user-space) don't feel related to the
pre-existing O_* flag set -- they affect all components of path lookup.
We'd therefore like to add a new flag argument.

Adding a new syscall allows us to finally fix the flag-ignoring problem,
and we can make it extensible enough so that we will hopefully never
need an openat3(2).

/* Syscall Prototype. */
/*
* open_how is an extensible structure (similar in interface to
* clone3(2) or sched_setattr(2)). The size parameter must be set to
* sizeof(struct open_how), to allow for future extensions. All future
* extensions will be appended to open_how, with their zero value
* acting as a no-op default.
*/
struct open_how { /* ... */ };

int openat2(int dfd, const char *pathname,
struct open_how *how, size_t size);

/* Description. */
The initial version of 'struct open_how' contains the following fields:

flags
Used to specify openat(2)-style flags. However, any unknown flag
bits or otherwise incorrect flag combinations (like O_PATH|O_RDWR)
will result in -EINVAL. In addition, this field is 64-bits wide to
allow for more O_ flags than currently permitted with openat(2).

mode
The file mode for O_CREAT or O_TMPFILE.

Must be set to zero if flags does not contain O_CREAT or O_TMPFILE.

resolve
Restrict path resolution (in contrast to O_* flags they affect all
path components). The current set of flags are as follows (at the
moment, all of the RESOLVE_ flags are implemented as just passing
the corresponding LOOKUP_ flag).

RESOLVE_NO_XDEV => LOOKUP_NO_XDEV
RESOLVE_NO_SYMLINKS => LOOKUP_NO_SYMLINKS
RESOLVE_NO_MAGICLINKS => LOOKUP_NO_MAGICLINKS
RESOLVE_BENEATH => LOOKUP_BENEATH
RESOLVE_IN_ROOT => LOOKUP_IN_ROOT

open_how does not contain an embedded size field, because it is of
little benefit (userspace can figure out the kernel open_how size at
runtime fairly easily without it). It also only contains u64s (even
though ->mode arguably should be a u16) to avoid having padding fields
which are never used in the future.

Note that as a result of the new how->flags handling, O_PATH|O_TMPFILE
is no longer permitted for openat(2). As far as I can tell, this has
always been a bug and appears to not be used by userspace (and I've not
seen any problems on my machines by disallowing it). If it turns out
this breaks something, we can special-case it and only permit it for
openat(2) but not openat2(2).

After input from Florian Weimer, the new open_how and flag definitions
are inside a separate header from uapi/linux/fcntl.h, to avoid problems
that glibc has with importing that header.

/* Testing. */
In a follow-up patch there are over 200 selftests which ensure that this
syscall has the correct semantics and will correctly handle several
attack scenarios.

In addition, I've written a userspace library[4] which provides
convenient wrappers around openat2(RESOLVE_IN_ROOT) (this is necessary
because no other syscalls support RESOLVE_IN_ROOT, and thus lots of care
must be taken when using RESOLVE_IN_ROOT'd file descriptors with other
syscalls). During the development of this patch, I've run numerous
verification tests using libpathrs (showing that the API is reasonably
usable by userspace).

/* Future Work. */
Additional RESOLVE_ flags have been suggested during the review period.
These can be easily implemented separately (such as blocking auto-mount
during resolution).

Furthermore, there are some other proposed changes to the openat(2)
interface (the most obvious example is magic-link hardening[5]) which
would be a good opportunity to add a way for userspace to restrict how
O_PATH file descriptors can be re-opened.

Another possible avenue of future work would be some kind of
CHECK_FIELDS[6] flag which causes the kernel to indicate to userspace
which openat2(2) flags and fields are supported by the current kernel
(to avoid userspace having to go through several guesses to figure it
out).

[1]: https://lwn.net/Articles/588444/
[2]: https://lore.kernel.org/lkml/CA+55aFyyxJL1LyXZeBsf2ypriraj5ut1XkNDsunRBqgVjZU_6Q@mail.gmail.com
[3]: commit 629e014bb834 ("fs: completely ignore unknown open flags")
[4]: https://sourceware.org/bugzilla/show_bug.cgi?id=17523
[5]: https://lore.kernel.org/lkml/20190930183316.10190-2-cyphar@cyphar.com/
[6]: https://youtu.be/ggD-eb3yPVs

Suggested-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
diff fddb5d43 Sat Jan 18 05:07:59 MST 2020 Aleksa Sarai <cyphar@cyphar.com> open: introduce openat2(2) syscall

/* Background. */
For a very long time, extending openat(2) with new features has been
incredibly frustrating. This stems from the fact that openat(2) is
possibly the most famous counter-example to the mantra "don't silently
accept garbage from userspace" -- it doesn't check whether unknown flags
are present[1].

This means that (generally) the addition of new flags to openat(2) has
been fraught with backwards-compatibility issues (O_TMPFILE has to be
defined as __O_TMPFILE|O_DIRECTORY|[O_RDWR or O_WRONLY] to ensure old
kernels gave errors, since it's insecure to silently ignore the
flag[2]). All new security-related flags therefore have a tough road to
being added to openat(2).

Userspace also has a hard time figuring out whether a particular flag is
supported on a particular kernel. While it is now possible with
contemporary kernels (thanks to [3]), older kernels will expose unknown
flag bits through fcntl(F_GETFL). Giving a clear -EINVAL during
openat(2) time matches modern syscall designs and is far more
fool-proof.

In addition, the newly-added path resolution restriction LOOKUP flags
(which we would like to expose to user-space) don't feel related to the
pre-existing O_* flag set -- they affect all components of path lookup.
We'd therefore like to add a new flag argument.

Adding a new syscall allows us to finally fix the flag-ignoring problem,
and we can make it extensible enough so that we will hopefully never
need an openat3(2).

/* Syscall Prototype. */
/*
* open_how is an extensible structure (similar in interface to
* clone3(2) or sched_setattr(2)). The size parameter must be set to
* sizeof(struct open_how), to allow for future extensions. All future
* extensions will be appended to open_how, with their zero value
* acting as a no-op default.
*/
struct open_how { /* ... */ };

int openat2(int dfd, const char *pathname,
struct open_how *how, size_t size);

/* Description. */
The initial version of 'struct open_how' contains the following fields:

flags
Used to specify openat(2)-style flags. However, any unknown flag
bits or otherwise incorrect flag combinations (like O_PATH|O_RDWR)
will result in -EINVAL. In addition, this field is 64-bits wide to
allow for more O_ flags than currently permitted with openat(2).

mode
The file mode for O_CREAT or O_TMPFILE.

Must be set to zero if flags does not contain O_CREAT or O_TMPFILE.

resolve
Restrict path resolution (in contrast to O_* flags they affect all
path components). The current set of flags are as follows (at the
moment, all of the RESOLVE_ flags are implemented as just passing
the corresponding LOOKUP_ flag).

RESOLVE_NO_XDEV => LOOKUP_NO_XDEV
RESOLVE_NO_SYMLINKS => LOOKUP_NO_SYMLINKS
RESOLVE_NO_MAGICLINKS => LOOKUP_NO_MAGICLINKS
RESOLVE_BENEATH => LOOKUP_BENEATH
RESOLVE_IN_ROOT => LOOKUP_IN_ROOT

open_how does not contain an embedded size field, because it is of
little benefit (userspace can figure out the kernel open_how size at
runtime fairly easily without it). It also only contains u64s (even
though ->mode arguably should be a u16) to avoid having padding fields
which are never used in the future.

Note that as a result of the new how->flags handling, O_PATH|O_TMPFILE
is no longer permitted for openat(2). As far as I can tell, this has
always been a bug and appears to not be used by userspace (and I've not
seen any problems on my machines by disallowing it). If it turns out
this breaks something, we can special-case it and only permit it for
openat(2) but not openat2(2).

After input from Florian Weimer, the new open_how and flag definitions
are inside a separate header from uapi/linux/fcntl.h, to avoid problems
that glibc has with importing that header.

/* Testing. */
In a follow-up patch there are over 200 selftests which ensure that this
syscall has the correct semantics and will correctly handle several
attack scenarios.

In addition, I've written a userspace library[4] which provides
convenient wrappers around openat2(RESOLVE_IN_ROOT) (this is necessary
because no other syscalls support RESOLVE_IN_ROOT, and thus lots of care
must be taken when using RESOLVE_IN_ROOT'd file descriptors with other
syscalls). During the development of this patch, I've run numerous
verification tests using libpathrs (showing that the API is reasonably
usable by userspace).

/* Future Work. */
Additional RESOLVE_ flags have been suggested during the review period.
These can be easily implemented separately (such as blocking auto-mount
during resolution).

Furthermore, there are some other proposed changes to the openat(2)
interface (the most obvious example is magic-link hardening[5]) which
would be a good opportunity to add a way for userspace to restrict how
O_PATH file descriptors can be re-opened.

Another possible avenue of future work would be some kind of
CHECK_FIELDS[6] flag which causes the kernel to indicate to userspace
which openat2(2) flags and fields are supported by the current kernel
(to avoid userspace having to go through several guesses to figure it
out).

[1]: https://lwn.net/Articles/588444/
[2]: https://lore.kernel.org/lkml/CA+55aFyyxJL1LyXZeBsf2ypriraj5ut1XkNDsunRBqgVjZU_6Q@mail.gmail.com
[3]: commit 629e014bb834 ("fs: completely ignore unknown open flags")
[4]: https://sourceware.org/bugzilla/show_bug.cgi?id=17523
[5]: https://lore.kernel.org/lkml/20190930183316.10190-2-cyphar@cyphar.com/
[6]: https://youtu.be/ggD-eb3yPVs

Suggested-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
diff 5e48e55f Thu Oct 10 06:30:46 MDT 2019 Geert Uytterhoeven <geert+renesas@glider.be> MAINTAINERS: Remove Simon as Renesas SoC Co-Maintainer

At the end of the v5.3 upstream kernel development cycle, Simon stepped
down from his role as Renesas SoC maintainer.

Remove his maintainership, git repository, and branch from the
MAINTAINERS file, and add an entry to the CREDITS file to honor his
work.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Completed in 408 milliseconds