From: Borislav Petkov <bp@alien8.de>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: ALSA Development Mailing List <alsa-devel@alsa-project.org>,
the arch/x86 maintainers <x86@kernel.org>,
Linux-sh list <linux-sh@vger.kernel.org>,
linux-iio@vger.kernel.org,
"open list:REMOTE PROCESSOR \(REMOTEPROC\) SUBSYSTEM"
<linux-remoteproc@vger.kernel.org>,
linux-hyperv@vger.kernel.org,
"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
netdev <netdev@vger.kernel.org>,
Ayush Sawal <ayush.sawal@chelsio.com>,
sparclinux <sparclinux@vger.kernel.org>,
linux-clk <linux-clk@vger.kernel.org>,
linux-leds <linux-leds@vger.kernel.org>,
linux-s390 <linux-s390@vger.kernel.org>,
scsi <linux-scsi@vger.kernel.org>,
Rohit Maheshwari <rohitm@chelsio.com>,
linux-staging@lists.linux.dev,
Geert Uytterhoeven <geert@linux-m68k.org>,
openipmi-developer@lists.sourceforge.net,
bcm-kernel-feedback-list <bcm-kernel-feedback-list@broadcom.com>,
"open list:TENSILICA XTENSA PORT \(xtensa\)"
<linux-xtensa@linux-xtensa.org>, Arnd Bergmann <arnd@arndb.de>,
Linux PM list <linux-pm@vger.kernel.org>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
Vinay Kumar Yadav <vinay.yadav@chelsio.com>,
linux-um <linux-um@lists.infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
rcu@vger.kernel.org,
Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
xen-devel@lists.xenproject.org,
linux-tegra <linux-tegra@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
intel-gvt-dev@lists.freedesktop.org,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-edac@vger.kernel.org,
Parisc List <linux-parisc@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
USB list <linux-usb@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
alpha <linux-alpha@vger.kernel.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [Intel-gfx] [PATCH v0 42/42] notifier: Return an error when callback is already registered
Date: Mon, 8 Nov 2021 22:18:47 +0100 [thread overview]
Message-ID: <YYmUN69Y7z9xITas@zn.tnic> (raw)
In-Reply-To: <20211108205926.GA1678880@rowland.harvard.edu>
On Mon, Nov 08, 2021 at 03:59:26PM -0500, Alan Stern wrote:
> Is there really any reason for returning an error code? For example, is
> it anticipated that at some point in the future these registration calls
> might fail?
>
> Currently, the only reason for failing...
Right, I believe with not making it return void we're leaving the door
open for some, *hypothetical* future return values if we decide we need
to return them too, at some point.
Yes, I can't think of another fact to state besides that the callback
was already registered or return success but who knows what we wanna do
in the future...
And so if we change them all to void now, I think it'll be a lot more
churn to switch back to returning a non-void value and having the
callers who choose to handle that value, do so again.
So, long story short, keeping the retval - albeit not very useful right
now - is probably easier.
I hope I'm making some sense here.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@alien8.de>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
LKML <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Arnd Bergmann <arnd@arndb.de>,
Ayush Sawal <ayush.sawal@chelsio.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Rohit Maheshwari <rohitm@chelsio.com>,
Steven Rostedt <rostedt@goodmis.org>,
Vinay Kumar Yadav <vinay.yadav@chelsio.com>,
ALSA Development Mailing List <alsa-devel@alsa-project.org>,
bcm-kernel-feedback-list <bcm-kernel-feedback-list@broadcom.com>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
intel-gvt-dev@lists.freedesktop.org,
alpha <linux-alpha@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-clk <linux-clk@vger.kernel.org>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
linux-edac@vger.kernel.org,
Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
linux-hyperv@vger.kernel.org, linux-iio@vger.kernel.org,
linux-leds <linux-leds@vger.kernel.org>,
"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
Parisc List <linux-parisc@vger.kernel.org>,
Linux PM list <linux-pm@vger.kernel.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
"open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM"
<linux-remoteproc@vger.kernel.org>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
linux-s390 <linux-s390@vger.kernel.org>,
scsi <linux-scsi@vger.kernel.org>,
Linux-sh list <linux-sh@vger.kernel.org>,
linux-staging@lists.linux.dev,
linux-tegra <linux-tegra@vger.kernel.org>,
linux-um <linux-um@lists.infradead.org>,
USB list <linux-usb@vger.kernel.org>,
"open list:TENSILICA XTENSA PORT (xtensa)"
<linux-xtensa@linux-xtensa.org>, netdev <netdev@vger.kernel.org>,
openipmi-developer@lists.sourceforge.net, rcu@vger.kernel.org,
sparclinux <sparclinux@vger.kernel.org>,
the arch/x86 maintainers <x86@kernel.org>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v0 42/42] notifier: Return an error when callback is already registered
Date: Mon, 8 Nov 2021 22:18:47 +0100 [thread overview]
Message-ID: <YYmUN69Y7z9xITas@zn.tnic> (raw)
In-Reply-To: <20211108205926.GA1678880@rowland.harvard.edu>
On Mon, Nov 08, 2021 at 03:59:26PM -0500, Alan Stern wrote:
> Is there really any reason for returning an error code? For example, is
> it anticipated that at some point in the future these registration calls
> might fail?
>
> Currently, the only reason for failing...
Right, I believe with not making it return void we're leaving the door
open for some, *hypothetical* future return values if we decide we need
to return them too, at some point.
Yes, I can't think of another fact to state besides that the callback
was already registered or return success but who knows what we wanna do
in the future...
And so if we change them all to void now, I think it'll be a lot more
churn to switch back to returning a non-void value and having the
callers who choose to handle that value, do so again.
So, long story short, keeping the retval - albeit not very useful right
now - is probably easier.
I hope I'm making some sense here.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@alien8.de>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: ALSA Development Mailing List <alsa-devel@alsa-project.org>,
the arch/x86 maintainers <x86@kernel.org>,
Linux-sh list <linux-sh@vger.kernel.org>,
linux-iio@vger.kernel.org,
"open list:REMOTE PROCESSOR \(REMOTEPROC\) SUBSYSTEM"
<linux-remoteproc@vger.kernel.org>,
linux-hyperv@vger.kernel.org,
"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
netdev <netdev@vger.kernel.org>,
Ayush Sawal <ayush.sawal@chelsio.com>,
sparclinux <sparclinux@vger.kernel.org>,
linux-clk <linux-clk@vger.kernel.org>,
linux-leds <linux-leds@vger.kernel.org>,
linux-s390 <linux-s390@vger.kernel.org>,
scsi <linux-scsi@vger.kernel.org>,
Rohit Maheshwari <rohitm@chelsio.com>,
linux-staging@lists.linux.dev,
Geert Uytterhoeven <geert@linux-m68k.org>,
openipmi-developer@lists.sourceforge.net,
bcm-kernel-feedback-list <bcm-kernel-feedback-list@broadcom.com>,
"open list:TENSILICA XTENSA PORT \(xtensa\)"
<linux-xtensa@linux-xtensa.org>, Arnd Bergmann <arnd@arndb.de>,
Linux PM list <linux-pm@vger.kernel.org>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
Vinay Kumar Yadav <vinay.yadav@chelsio.com>,
linux-um <linux-um@lists.infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
rcu@vger.kernel.org,
Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
xen-devel@lists.xenproject.org,
linux-tegra <linux-tegra@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
intel-gvt-dev@lists.freedesktop.org,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-edac@vger.kernel.org,
Parisc List <linux-parisc@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
USB list <linux-usb@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
alpha <linux-alpha@vger.kernel.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH v0 42/42] notifier: Return an error when callback is already registered
Date: Mon, 8 Nov 2021 22:18:47 +0100 [thread overview]
Message-ID: <YYmUN69Y7z9xITas@zn.tnic> (raw)
In-Reply-To: <20211108205926.GA1678880@rowland.harvard.edu>
On Mon, Nov 08, 2021 at 03:59:26PM -0500, Alan Stern wrote:
> Is there really any reason for returning an error code? For example, is
> it anticipated that at some point in the future these registration calls
> might fail?
>
> Currently, the only reason for failing...
Right, I believe with not making it return void we're leaving the door
open for some, *hypothetical* future return values if we decide we need
to return them too, at some point.
Yes, I can't think of another fact to state besides that the callback
was already registered or return success but who knows what we wanna do
in the future...
And so if we change them all to void now, I think it'll be a lot more
churn to switch back to returning a non-void value and having the
callers who choose to handle that value, do so again.
So, long story short, keeping the retval - albeit not very useful right
now - is probably easier.
I hope I'm making some sense here.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@alien8.de>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
LKML <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Arnd Bergmann <arnd@arndb.de>,
Ayush Sawal <ayush.sawal@chelsio.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Rohit Maheshwari <rohitm@chelsio.com>,
Steven Rostedt <rostedt@goodmis.org>,
Vinay Kumar Yadav <vinay.yadav@chelsio.com>,
ALSA Development Mailing List <alsa-devel@alsa-project.org>,
bcm-kernel-feedback-list <bcm-kernel-feedback-list@broadcom.com>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
intel-gvt-dev@lists.freedesktop.org,
alpha <linux-alpha@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-clk <linux-clk@vger.kernel.org>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
linux-edac@vger.kernel.org,
Linux Fbdev development list <linux-fbdev@vger.kernel.org>,
linux-hyperv@vger.kernel.org, linux-iio@vger.kernel.org,
linux-leds <linux-leds@vger.kernel.org>,
"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
Parisc List <linux-parisc@vger.kernel.org>,
Linux PM list <linux-pm@vger.kernel.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
"open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM"
<linux-remoteproc@vger.kernel.org>,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
linux-s390 <linux-s390@vger.kernel.org>,
scsi <linux-scsi@vger.kernel.org>,
Linux-sh list <linux-sh@vger.kernel.org>,
linux-staging@lists.linux.dev,
linux-tegra <linux-tegra@vger.kernel.org>,
linux-um <linux-um@lists.infradead.org>,
USB list <linux-usb@vger.kernel.org>,
"open list:TENSILICA XTENSA PORT (xtensa)"
<linux-xtensa@linux-xtensa.org>, netdev <netdev@vger.kernel.org>,
openipmi-developer@lists.sourceforge.net, rcu@vger.kernel.org,
sparclinux <sparclinux@vger.kernel.org>,
the arch/x86 maintainers <x86@kernel.org>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v0 42/42] notifier: Return an error when callback is already registered
Date: Mon, 8 Nov 2021 22:18:47 +0100 [thread overview]
Message-ID: <YYmUN69Y7z9xITas@zn.tnic> (raw)
In-Reply-To: <20211108205926.GA1678880@rowland.harvard.edu>
On Mon, Nov 08, 2021 at 03:59:26PM -0500, Alan Stern wrote:
> Is there really any reason for returning an error code? For example, is
> it anticipated that at some point in the future these registration calls
> might fail?
>
> Currently, the only reason for failing...
Right, I believe with not making it return void we're leaving the door
open for some, *hypothetical* future return values if we decide we need
to return them too, at some point.
Yes, I can't think of another fact to state besides that the callback
was already registered or return success but who knows what we wanna do
in the future...
And so if we change them all to void now, I think it'll be a lot more
churn to switch back to returning a non-void value and having the
callers who choose to handle that value, do so again.
So, long story short, keeping the retval - albeit not very useful right
now - is probably easier.
I hope I'm making some sense here.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@alien8.de>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: ALSA Development Mailing List <alsa-devel@alsa-project.org>,
the arch/x86 maintainers <x86@kernel.org>,
Linux-sh list <linux-sh@vger.kernel.org>,
linux-iio@vger.kernel.org,
"open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM"
<linux-remoteproc@vger.kernel.org>,
linux-hyperv@vger.kernel.org,
"open list:BROADCOM NVRAM DRIVER" <linux-mips@vger.kernel.org>,
netdev <netdev@vger.kernel.org>,
Ayush Sawal <ayush.sawal@chelsio.com>,
sparclinux <sparclinux@vger.kernel.org>,
linux-clk <linux-clk@vger.kernel.org>,
linux-leds <linux-leds@vger.kernel.org>,
linux-s390 <linux-s390@vger.kernel.org>,
scsi <linux-scsi@vger.kernel.org>,
Rohit Maheshwari <rohitm@chelsio.com>,
linux-staging@lists.linux.dev,
Geert Uytterhoeven <geert@linux-m68k.org>,
openipmi-developer@lists.sourceforge.net,
bcm-kernel-feedback-list <bcm-kernel-feedback-list@broadcom.com>,
open list:TENSILICA XTENSA PORT (
Subject: Re: [PATCH v0 42/42] notifier: Return an error when callback is already registered
Date: Mon, 8 Nov 2021 22:18:47 +0100 [thread overview]
Message-ID: <YYmUN69Y7z9xITas@zn.tnic> (raw)
In-Reply-To: <20211108205926.GA1678880@rowland.harvard.edu>
On Mon, Nov 08, 2021 at 03:59:26PM -0500, Alan Stern wrote:
> Is there really any reason for returning an error code? For example, is
> it anticipated that at some point in the future these registration calls
> might fail?
>
> Currently, the only reason for failing...
Right, I believe with not making it return void we're leaving the door
open for some, *hypothetical* future return values if we decide we need
to return them too, at some point.
Yes, I can't think of another fact to state besides that the callback
was already registered or return success but who knows what we wanna do
in the future...
And so if we change them all to void now, I think it'll be a lot more
churn to switch back to returning a non-void value and having the
callers who choose to handle that value, do so again.
So, long story short, keeping the retval - albeit not very useful right
now - is probably easier.
I hope I'm making some sense here.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2021-11-08 21:18 UTC|newest]
Thread overview: 151+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-08 10:11 [PATCH v0 00/42] notifiers: Return an error when callback is already registered Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 01/42] x86: Check notifier registration return value Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 02/42] xen/x86: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 03/42] impi: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 04/42] clk: renesas: " Borislav Petkov
2021-11-08 14:12 ` Geert Uytterhoeven
2021-11-08 10:11 ` [PATCH v0 05/42] dca: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 06/42] firmware: " Borislav Petkov
2021-11-08 10:11 ` Borislav Petkov
2021-11-12 18:43 ` Cristian Marussi
2021-11-12 18:43 ` Cristian Marussi
2021-11-08 10:11 ` [PATCH v0 07/42] drm/i915: " Borislav Petkov
2021-11-08 10:11 ` [Intel-gfx] " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 08/42] Drivers: hv: vmbus: " Borislav Petkov
2021-11-08 11:16 ` Wei Liu
2021-11-08 11:39 ` Borislav Petkov
2021-11-08 11:45 ` Wei Liu
2021-11-08 12:08 ` Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 09/42] iio: proximity: cros_ec: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 10/42] leds: trigger: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 11/42] misc: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 12/42] ethernet: chelsio: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 13/42] power: reset: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 14/42] remoteproc: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 15/42] scsi: target: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 16/42] USB: " Borislav Petkov
2021-11-08 14:05 ` Alan Stern
2021-11-08 14:09 ` Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 17/42] drivers: video: " Borislav Petkov
2021-11-08 11:16 ` Wei Liu
2021-11-08 10:11 ` [PATCH v0 18/42] drivers/xen: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 19/42] kernel/hung_task: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 20/42] rcu: " Borislav Petkov
2021-11-08 16:53 ` Paul E. McKenney
2021-11-08 10:11 ` [PATCH v0 21/42] tracing: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 22/42] net: fib_notifier: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 23/42] ASoC: soc-jack: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 24/42] staging: olpc_dcon: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 25/42] arch/um: " Borislav Petkov
2021-11-08 10:11 ` Borislav Petkov
2021-11-08 10:23 ` Johannes Berg
2021-11-08 10:23 ` Johannes Berg
2021-11-08 10:48 ` Borislav Petkov
2021-11-08 10:48 ` Borislav Petkov
2021-11-08 10:56 ` Johannes Berg
2021-11-08 10:56 ` Johannes Berg
2021-11-08 10:11 ` [PATCH v0 26/42] alpha: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 27/42] bus: brcmstb_gisb: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 28/42] soc: bcm: brcmstb: pm: pm-arm: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 29/42] arm64: " Borislav Petkov
2021-11-08 10:11 ` Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 30/42] soc/tegra: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 31/42] parisc: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 32/42] macintosh/adb: " Borislav Petkov
2021-11-08 10:11 ` Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 33/42] mips: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 34/42] powerpc: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 35/42] sh: " Borislav Petkov
2021-11-08 13:31 ` Geert Uytterhoeven
2021-11-08 13:49 ` Borislav Petkov
2021-11-08 14:03 ` Geert Uytterhoeven
2021-11-08 14:48 ` Sergey Shtylyov
2021-11-08 10:11 ` [PATCH v0 36/42] s390: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 37/42] sparc: " Borislav Petkov
2021-11-08 19:59 ` David Miller
2021-11-08 10:11 ` [PATCH v0 38/42] xtensa: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 39/42] crypto: ccree - check " Borislav Petkov
2021-11-12 18:32 ` Cristian Marussi
2021-11-12 18:48 ` Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 40/42] EDAC/altera: Check " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 41/42] power: supply: ab8500: " Borislav Petkov
2021-11-08 10:11 ` [PATCH v0 42/42] notifier: Return an error when callback is already registered Borislav Petkov
2021-11-08 10:11 ` Borislav Petkov
2021-11-08 10:11 ` Borislav Petkov
2021-11-08 10:11 ` Borislav Petkov
2021-11-08 10:11 ` [Intel-gfx] " Borislav Petkov
2021-11-08 10:11 ` Borislav Petkov
2021-11-08 14:07 ` Geert Uytterhoeven
2021-11-08 14:07 ` Geert Uytterhoeven
2021-11-08 14:07 ` Geert Uytterhoeven
2021-11-08 14:07 ` [Intel-gfx] " Geert Uytterhoeven
2021-11-08 14:07 ` Geert Uytterhoeven
2021-11-08 14:21 ` Borislav Petkov
2021-11-08 14:21 ` Borislav Petkov
2021-11-08 14:21 ` Borislav Petkov
2021-11-08 14:21 ` [Intel-gfx] " Borislav Petkov
2021-11-08 14:21 ` Borislav Petkov
2021-11-08 15:25 ` Geert Uytterhoeven
2021-11-08 15:25 ` Geert Uytterhoeven
2021-11-08 15:25 ` Geert Uytterhoeven
2021-11-08 15:25 ` Geert Uytterhoeven
2021-11-08 15:25 ` [Intel-gfx] " Geert Uytterhoeven
2021-11-08 15:58 ` Borislav Petkov
2021-11-08 15:58 ` Borislav Petkov
2021-11-08 15:58 ` Borislav Petkov
2021-11-08 15:58 ` [Intel-gfx] " Borislav Petkov
2021-11-08 15:58 ` Borislav Petkov
2021-11-08 16:12 ` Geert Uytterhoeven
2021-11-08 16:12 ` Geert Uytterhoeven
2021-11-08 16:12 ` Geert Uytterhoeven
2021-11-08 16:12 ` [Intel-gfx] " Geert Uytterhoeven
2021-11-08 16:12 ` Geert Uytterhoeven
2021-11-08 16:21 ` Borislav Petkov
2021-11-08 16:21 ` Borislav Petkov
2021-11-08 16:21 ` Borislav Petkov
2021-11-08 16:21 ` Borislav Petkov
2021-11-08 16:21 ` [Intel-gfx] " Borislav Petkov
2021-11-08 20:59 ` Alan Stern
2021-11-08 20:59 ` Alan Stern
2021-11-08 20:59 ` Alan Stern
2021-11-08 20:59 ` Alan Stern
2021-11-08 20:59 ` [Intel-gfx] " Alan Stern
2021-11-08 20:59 ` Alan Stern
2021-11-08 21:18 ` Borislav Petkov [this message]
2021-11-08 21:18 ` Borislav Petkov
2021-11-08 21:18 ` Borislav Petkov
2021-11-08 21:18 ` Borislav Petkov
2021-11-08 21:18 ` Borislav Petkov
2021-11-08 10:19 ` [PATCH v0 00/42] notifiers: " Borislav Petkov
2021-11-08 10:19 ` Borislav Petkov
2021-11-08 10:19 ` Borislav Petkov
2021-11-08 10:19 ` Borislav Petkov
2021-11-08 10:19 ` Borislav Petkov
2021-11-08 10:19 ` [Intel-gfx] " Borislav Petkov
2021-11-08 14:17 ` Alan Stern
2021-11-08 14:17 ` Alan Stern
2021-11-08 14:17 ` Alan Stern
2021-11-08 14:17 ` Alan Stern
2021-11-08 14:17 ` [Intel-gfx] " Alan Stern
2021-11-08 14:17 ` Alan Stern
2021-11-08 14:24 ` Borislav Petkov
2021-11-08 14:24 ` Borislav Petkov
2021-11-08 14:24 ` Borislav Petkov
2021-11-08 14:24 ` Borislav Petkov
2021-11-08 14:24 ` [Intel-gfx] " Borislav Petkov
2021-11-08 14:24 ` Borislav Petkov
2021-11-08 14:35 ` Borislav Petkov
2021-11-08 14:35 ` Borislav Petkov
2021-11-08 14:35 ` Borislav Petkov
2021-11-08 14:35 ` [Intel-gfx] " Borislav Petkov
2021-11-08 14:35 ` Borislav Petkov
2021-11-08 16:23 ` Steven Rostedt
2021-11-08 16:23 ` Steven Rostedt
2021-11-08 16:23 ` Steven Rostedt
2021-11-08 16:23 ` [Intel-gfx] " Steven Rostedt
2021-11-08 16:23 ` Steven Rostedt
2021-11-08 16:29 ` Borislav Petkov
2021-11-08 16:29 ` Borislav Petkov
2021-11-08 16:29 ` Borislav Petkov
2021-11-08 16:29 ` [Intel-gfx] " Borislav Petkov
2021-11-08 16:29 ` Borislav Petkov
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=YYmUN69Y7z9xITas@zn.tnic \
--to=bp@alien8.de \
--cc=alsa-devel@alsa-project.org \
--cc=arnd@arndb.de \
--cc=ayush.sawal@chelsio.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-gvt-dev@lists.freedesktop.org \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=linux-tegra@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux-xtensa@linux-xtensa.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=netdev@vger.kernel.org \
--cc=openipmi-developer@lists.sourceforge.net \
--cc=rcu@vger.kernel.org \
--cc=rohitm@chelsio.com \
--cc=rostedt@goodmis.org \
--cc=sparclinux@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
--cc=tglx@linutronix.de \
--cc=vinay.yadav@chelsio.com \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.