On 03-09-2024 20:02, Mathieu Poirier wrote:
On Tue, 3 Sept 2024 at 04:15, Beleswar Prasad Padhi wrote:
Hi Mathieu,
On 20-08-2024 16:20, Beleswar Padhi wrote:
From: Udit Kumar
Few times, core1 was scheduled to boot first before core0, which leads
to error:
'k3_r5_rproc_start: can not star
On Tue, 3 Sept 2024 at 04:15, Beleswar Prasad Padhi wrote:
>
> Hi Mathieu,
>
> On 20-08-2024 16:20, Beleswar Padhi wrote:
> > From: Udit Kumar
> >
> > Few times, core1 was scheduled to boot first before core0, which leads
> > to error:
> >
> > 'k3_r5_rproc_start: can not start core 1 before core
Hi Mathieu,
On 20-08-2024 16:20, Beleswar Padhi wrote:
From: Udit Kumar
Few times, core1 was scheduled to boot first before core0, which leads
to error:
'k3_r5_rproc_start: can not start core 1 before core 0'.
This was happening due to some scheduling between prepare and start
callback. The
From: Udit Kumar
Few times, core1 was scheduled to boot first before core0, which leads
to error:
'k3_r5_rproc_start: can not start core 1 before core 0'.
This was happening due to some scheduling between prepare and start
callback. The probe function waits for event, which is getting
triggered
On Fri, Aug 09, 2024 at 11:31:32AM +0530, Beleswar Padhi wrote:
> From: Udit Kumar
>
> Few times, core1 was scheduled to boot first before core0, which leads
> to error:
>
> 'k3_r5_rproc_start: can not start core 1 before core 0'.
>
> This was happening due to some scheduling between prepare an
Sometime, it would be useful to disable the configure change
notification from the driver. So this patch allows this by introducing
a variable config_change_driver_disabled and only allow the configure
change notification callback to be triggered when it is allowed by
both the virtio core and the
From: Udit Kumar
Few times, core1 was scheduled to boot first before core0, which leads
to error:
'k3_r5_rproc_start: can not start core 1 before core 0'.
This was happening due to some scheduling between prepare and start
callback. The probe function waits for event, which is getting
triggered
Sometime, it would be useful to disable the configure change
notification from the driver. So this patch allows this by introducing
a variable config_change_driver_disabled and only allow the configure
change notification callback to be triggered when it is allowed by
both the virtio core and the
Sometime, it would be useful to disable the configure change
notification from the driver. So this patch allows this by introducing
a variable config_change_driver_disabled and only allow the configure
change notification callback to be triggered when it is allowed by
both the virtio core and the
On Tue, 9 Jul 2024 16:02:13 +0800, Jason Wang wrote:
> Sometime, it would be useful to disable the configure change
> notification from the driver. So this patch allows this by introducing
> a variable config_change_driver_disabled and only allow the configure
> change notification
On Tue, 9 Jul 2024 16:02:13 +0800, Jason Wang wrote:
> Sometime, it would be useful to disable the configure change
> notification from the driver. So this patch allows this by introducing
> a variable config_change_driver_disabled and only allow the configure
> change notification
Sometime, it would be useful to disable the configure change
notification from the driver. So this patch allows this by introducing
a variable config_change_driver_disabled and only allow the configure
change notification callback to be triggered when it is allowed by
both the virtio core and the
ivers/regulator/irq_helpers.c b/drivers/regulator/irq_helpers.c
new file mode 100644
index ..f57abb96e74c
--- /dev/null
+++ b/drivers/regulator/irq_helpers.c
@@ -0,0 +1,394 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2021 ROHM Semiconductors
+// regulator IRQ based even
Extend regulator notification support
This series extends the regulator notification and error flag support.
Initial discussion on the topic can be found here:
https://lore.kernel.org/lkml/6046836e22b8252983f08d5621c35ececb97820d.ca...@fi.rohmeurope.com/
This series is built on top of the
I am bringing this notice to your attention in respect of the death of
a deceased client of mine that has the same surname with you and his
fund valued at $19.9M to be paid to you.contact me at
cephasagb...@gmail.com for more details.
Yours Sincerely,
Cephas Agbeh,
Attorney At Law.
or/irq_helpers.c
new file mode 100644
index ..f57abb96e74c
--- /dev/null
+++ b/drivers/regulator/irq_helpers.c
@@ -0,0 +1,394 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2021 ROHM Semiconductors
+// regulator IRQ based event notification helpers
+//
+// Logic has been p
Extend regulator notification support
This series extends the regulator notification and error flag support.
Initial discussion on the topic can be found here:
https://lore.kernel.org/lkml/6046836e22b8252983f08d5621c35ececb97820d.ca...@fi.rohmeurope.com/
This series is built on top of the
This patch also fixes the bug I reported here:
https://lore.kernel.org/lkml/20210413160151.3301-1-rodr...@kinvolk.io/T/
--
Rodrigo Campos
---
Kinvolk GmbH | Adalbertstr.6a, 10999 Berlin | tel: +491755589364
Geschäftsführer/Directors: Alban Crequy, Chris Kühl, Iago López Galeiras
Registergericht
On Mon, Apr 12, 2021 at 03:24:16PM +0300, Matti Vaittinen wrote:
> Maybe this 'hardware protection, in-kernel, emergency HW saving
> shutdown' - logic, should be pulled out of thermal_core.c (or at least
> exported) for (other parts like) the regulators to use?
That sounds sensible.
signature.a
On Fri, 2021-04-09 at 10:08 +0300, Matti Vaittinen wrote:
> On Thu, 2021-04-08 at 20:20 -0700, Kees Cook wrote:
> > On Wed, Apr 07, 2021 at 03:50:15PM +0300, Andy Shevchenko wrote:
> > > On Wed, Apr 7, 2021 at 12:49 PM Vaittinen, Matti
> > > wrote:
> > > > On Wed, 2021-04-07 at 12:10 +0300, Andy
the PCIe device driver how PCIe
device driver can get the notification of the function level reset(FLR)?
On Thu, 2021-04-08 at 20:20 -0700, Kees Cook wrote:
> On Wed, Apr 07, 2021 at 03:50:15PM +0300, Andy Shevchenko wrote:
> > On Wed, Apr 7, 2021 at 12:49 PM Vaittinen, Matti
> > wrote:
> > > On Wed, 2021-04-07 at 12:10 +0300, Andy Shevchenko wrote:
> > > > On Wed, Apr 7, 2021 at 8:02 AM Matti Vaitt
On Wed, Apr 07, 2021 at 03:50:15PM +0300, Andy Shevchenko wrote:
> On Wed, Apr 7, 2021 at 12:49 PM Vaittinen, Matti
> wrote:
> > On Wed, 2021-04-07 at 12:10 +0300, Andy Shevchenko wrote:
> > > On Wed, Apr 7, 2021 at 8:02 AM Matti Vaittinen
> > > wrote:
> > > > On Wed, 2021-04-07 at 01:44 +0300, A
On Thu, 2021-04-08 at 12:58 +0300, Andy Shevchenko wrote:
> On Thu, Apr 8, 2021 at 11:21 AM Matti Vaittinen
> wrote:
> > Hello Andy,
> >
> > On Wed, 2021-04-07 at 16:21 +0300, Andy Shevchenko wrote:
> > > On Wed, Apr 7, 2021 at 1:04 PM Matti Vaittinen
> > > wrote:
> > > > Provide helper functio
On Thu, Apr 8, 2021 at 11:21 AM Matti Vaittinen
wrote:
>
> Hello Andy,
>
> On Wed, 2021-04-07 at 16:21 +0300, Andy Shevchenko wrote:
> > On Wed, Apr 7, 2021 at 1:04 PM Matti Vaittinen
> > wrote:
> > > Provide helper function for IC's implementing regulator
> > > notifications
> > > when an IRQ fi
er instead of plain pointer.
>
This I replied to earlier - I did change the parameter documentation a
bit to explain this:
"@rdev: Array of pointers to regulators associated with this IRQ"
> > +#include
> > +#include
> > +#include
>
> + Blank line? I would sep
Hello Andy, All.
On Wed, 2021-04-07 at 16:21 +0300, Andy Shevchenko wrote:
> On Wed, Apr 7, 2021 at 1:04 PM Matti Vaittinen
> wrote:
> > Provide helper function for IC's implementing regulator
> > notifications
> > when an IRQ fires. The helper also works for IRQs which can not be
> > acked.
> >
ptr = regulator_irq_helper(dev, d, irq, irq_flags, common_errs,
> + per_rdev_errs, rdev, rdev_amount);
> + if (IS_ERR(ptr))
> + return ptr;
> + ret = devm_add_action_or_reset(dev, regulator_irq_helper_drop, ptr);
> +
On Wed, Apr 7, 2021 at 12:49 PM Vaittinen, Matti
wrote:
> On Wed, 2021-04-07 at 12:10 +0300, Andy Shevchenko wrote:
> > On Wed, Apr 7, 2021 at 8:02 AM Matti Vaittinen
> > wrote:
> > > On Wed, 2021-04-07 at 01:44 +0300, Andy Shevchenko wrote:
> > > > On Tuesday, April 6, 2021, Matti Vaittinen <
>
/drivers/regulator/irq_helpers.c
new file mode 100644
index ..374ff0f3c6d3
--- /dev/null
+++ b/drivers/regulator/irq_helpers.c
@@ -0,0 +1,396 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2021 ROHM Semiconductors
+// regulator IRQ based event notification helpers
+//
Extend regulator notification support
This series extends the regulator notification and error flag support. Initial
discussion on the topic can be found here:
https://lore.kernel.org/lkml/6046836e22b8252983f08d5621c35ececb97820d.ca...@fi.rohmeurope.com/
This series is built on top of the
Hello Andy,
On Wed, 2021-04-07 at 12:10 +0300, Andy Shevchenko wrote:
> On Wed, Apr 7, 2021 at 8:02 AM Matti Vaittinen
> wrote:
> > On Wed, 2021-04-07 at 01:44 +0300, Andy Shevchenko wrote:
> > > On Tuesday, April 6, 2021, Matti Vaittinen <
> > > matti.vaitti...@fi.rohmeurope.com> wrote:
>
> ...
On Wed, Apr 7, 2021 at 8:02 AM Matti Vaittinen
wrote:
>
> Morning Andy,
>
> Thanks for the review! By the way, is it me or did your mail-client
> spill this out using HTML?
It's Gmail from my mobile phone, sorry for that. We have to blame
Google that they don't think through.
> On Wed, 2021-04-0
Morning Andy,
Thanks for the review! By the way, is it me or did your mail-client
spill this out using HTML?
On Wed, 2021-04-07 at 01:44 +0300, Andy Shevchenko wrote:
> On Tuesday, April 6, 2021, Matti Vaittinen <
> matti.vaitti...@fi.rohmeurope.com> wrote:
> > +static void die_loudly(const char
-base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Matti-Vaittinen/Extend-regulator-notification-support/20210406-151758
base:e49d033bddf5b565044e2abe4241353959bc9120
config: x86_64-randconfig-a014-20210406 (attached
,0 +1,432 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2021 ROHM Semiconductors
+// regulator IRQ based event notification helpers
+//
+// Logic has been partially adapted from qcom-labibb driver.
+//
+// Author: Matti Vaittinen
+
+#include
+#include
+#include
+#include
+#i
Extend regulator notification support
This series extends the regulator notification and error flag support. Initial
discussion on the topic can be found here:
https://lore.kernel.org/lkml/6046836e22b8252983f08d5621c35ececb97820d.ca...@fi.rohmeurope.com/
This series is built on top of the
On Tue, 2021-04-06 at 18:27 +0800, kernel test robot wrote:
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
>
> All errors (new ones prefixed by >>):
>
>In file included from include/linux/kernel.h:16,
> from arch/x86/inc
-base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Matti-Vaittinen/Extend-regulator-notification-support/20210406-151758
base:e49d033bddf5b565044e2abe4241353959bc9120
config: i386-randconfig-m021-20210406 (attached as .config
-Identifier: GPL-2.0
+//
+// Copyright (C) 2021 ROHM Semiconductors
+// regulator IRQ based event notification helpers
+//
+// Logic has been partially adapted from qcom-labibb driver.
+//
+// Author: Matti Vaittinen
+
+#include
+#include
+#include
+#include
+#include
+#include
+#incl
Extend regulator notification support
This series extends the regulator notification and error flag support. Initial
discussion on the topic can be found here:
https://lore.kernel.org/lkml/6046836e22b8252983f08d5621c35ececb97820d.ca...@fi.rohmeurope.com/
This series is built on top of the
On Fri, 2021-04-02 at 18:11 +0100, Mark Brown wrote:
> On Thu, Mar 11, 2021 at 12:22:36PM +0200, Matti Vaittinen wrote:
> > + if (d->fatal_cnt && h->retry_cnt > d->fatal_cnt) {
> > + if (d->die)
> > + ret = d->die(rid);
> > + else
> > + BU
On Thu, Mar 11, 2021 at 12:21:01PM +0200, Matti Vaittinen wrote:
> Extend regulator notification support
>
> This is an RFC series for getting feedback on extending the regulator
> notification and error flag support. Initial discussion on the topic can
> be found here:
This l
On Thu, Mar 11, 2021 at 12:22:36PM +0200, Matti Vaittinen wrote:
> @@ -0,0 +1,423 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2021 ROHM Semiconductors
Please make the entire comment a C++ one so things look more consistent.
> +static void regulator_notifier_isr_work(struc
Hi,
I think that you can squash this patch to patch4.
On 3/23/21 8:34 PM, Andrew-sh.Cheng wrote:
> From: "Andrew-sh.Cheng"
>
> SVS will change the voltage of opp item.
What it the full name of SVS?
> CCI devfreq need to react to change frequency.
>
> Signed-off-by: Andrew-sh.Cheng
> ---
>
://lore.kernel.org/lkml/202012011322.26DCBC64F2@keescook/
>
> Rodrigo Campos (1):
> seccomp: Support atomic "addfd + send reply"
>
> Sargun Dhillon (4):
> seccomp: Refactor notification handler to prepare for new semantics
> seccomp: Add wait_killable semantic to seccomp
On 11.03.21 06:32, Matti Vaittinen wrote:
...This is what happens when you suddenly pause work for over a week
because it starts to rain in the kitchen >.<;
Uups :(
I once had raining in the living room. (fortunately, just a rented
appartment, so let the owner do everything). At first I tried
t's been
running for more than 10ms during GC. During certain syscalls, it's
non-trivial to write them in a reetrant manner in userspace (mount).
This has a couple semantic changes, and relaxes a check on seccomp_data, and
changes the semantics with ordering of how addfd and notific
This refactors the user notification code to have a do / while loop around
the completion condition. This has a small change in semantic, in that
previously we ignored addfd calls upon wakeup if the notification had been
responded to, but instead with the new change we check for an outstanding
t's been
running for more than 10ms during GC. During certain syscalls, it's
non-trivial to write them in a reetrant manner in userspace (mount).
This has a couple semantic changes, and relaxes a check on seccomp_data, and
changes the semantics with ordering of how addfd and notific
Expose to the SCMI drivers a new alternative devres managed notifications
API based on protocol handles.
All drivers still keep using the old API, no functional change.
Signed-off-by: Cristian Marussi
---
v6 --> v7
- constify src_id parameter
- renamed non-static function to fit scmi__ naming pa
gt; This is only useful if you have devices that support PTM, but it
> is safe to enable even if you don't.
>
> -config PCIE_BW
> - bool "PCI Express Bandwidth Change Notification"
> - depends on PCIEPORTBUS
> - help
> - This
From: Greg Kroah-Hartman
From: Bjorn Helgaas
[ Upstream commit b4c7d2076b4e767dd2e075a2b3a9e57753fc67f5 ]
The PCIe Bandwidth Change Notification feature logs messages when the link
bandwidth changes. Some users have reported that these messages occur
often enough to significantly reduce NVMe
From: Greg Kroah-Hartman
From: Bjorn Helgaas
[ Upstream commit b4c7d2076b4e767dd2e075a2b3a9e57753fc67f5 ]
The PCIe Bandwidth Change Notification feature logs messages when the link
bandwidth changes. Some users have reported that these messages occur
often enough to significantly reduce NVMe
From: Greg Kroah-Hartman
From: Keith Busch
[ Upstream commit 387c72cdd7fb6bef650fb078d0f6ae9682abf631 ]
Overwriting the frozen detected status with the result of the link reset
loses the NEED_RESET result that drivers are depending on for error
handling to report the .slot_reset() callback. Re
while waiting for their QAOB
completion.
But it missed to adjust the check in qeth_tx_complete_buf(). So if
qeth_tx_complete_pending_bufs() is called during teardown to drain
the parked TX buffers, we no longer raise a notification for af_iucv.
Instead of updating the checked state, just move this
waiting for their QAOB
completion.
But it missed to adjust the check in qeth_tx_complete_buf(). So if
qeth_tx_complete_pending_bufs() is called during teardown to drain
the parked TX buffers, we no longer raise a notification for af_iucv.
Instead of updating the checked state, just move this code
e impression that this is an authenticated event. The
function 'wg_socket_set_peer_endpoint' where I hook in the notification
is called from:
- set_peer (changes from netlink, authenticated)
- wg_packet_consume_data_done (which should be authenticated?)
- wg_socket_set_peer_endpoint_
rs in cache for the duration of IRQ disabling.
Signed-off-by: Matti Vaittinen
---
v3:
- Fixed access to dangling pointer (sorry!)
v2:
- devm and non devm variants of IRQ notification helpers
- unconditionally call map_event in IRQ handling and require it to be
populated
drivers/regu
Extend regulator notification support
This is an RFC series for getting feedback on extending the regulator
notification and error flag support. Initial discussion on the topic can
be found here:
https://lore.kernel.org/lkml/6046836e22b8252983f08d5621c35ececb97820d.ca...@fi.rohmeurope.com/
This
Hello Peeps,
On Wed, 2021-03-10 at 15:07 +0200, Matti Vaittinen wrote:
> Extend regulator notification support
>
> This is an RFC series for getting feedback on extending the regulator
> notification and error flag support.
I am sorry. It seems I've sent bad version of the se
new file mode 100644
index ..29b7a7541f69
--- /dev/null
+++ b/drivers/regulator/irq_helpers.c
@@ -0,0 +1,428 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021 ROHM Semiconductors
+ * regulator IRQ based event notification helpers
+ *
+ * Logic has been partially adapted from
Extend regulator notification support
This is an RFC series for getting feedback on extending the regulator
notification and error flag support.
This series is built on top of the
The BD9576MUF support patch series v9
which is not yet in-tree
Here:
https://lore.kernel.org/lkml/cover.1615219345
ul
> > > wait_for_sync() API. And it doesn't need to be exposed to userspace at
> > > all.
> > >
> > > [1] https://lwn.net/Articles/789024/
> >
> > This sounds like an interesting idea. Actually, what I probably want is a
> > notifi
On Tue, Mar 09, 2021 at 09:32:47AM +1100, Dave Chinner wrote:
> On Mon, Mar 08, 2021 at 11:28:41AM +, David Howells wrote:
> > Possibly it's sufficient to just clear the excess page space before
> > writing, but that doesn't necessarily stop a writable mmap from
> > scribbling on
s a discussion about fsyncing a range of files on LSFMM [1].
> > In the last comment on the article dchinner argues why we already have that
> > API (and now also with io_uring(), but AFAIK, we do not have a useful
> > wait_for_sync() API. And it doesn't need to be exposed
useful
> wait_for_sync() API. And it doesn't need to be exposed to userspace at all.
>
> [1] https://lwn.net/Articles/789024/
This sounds like an interesting idea. Actually, what I probably want is a
notification to say that a particular object has been completely sync'd to
dis
Hey Linus,
Thanks for the patch and sorry for the delay in reviewing it. Seeing
the basic scaffolding for getting netlink notifiers working with
WireGuard is enlightening; it looks surprisingly straightforward.
There are three classes of things that are interesting to receive
notifications for:
From: Keith Busch
[ Upstream commit 387c72cdd7fb6bef650fb078d0f6ae9682abf631 ]
Overwriting the frozen detected status with the result of the link reset
loses the NEED_RESET result that drivers are depending on for error
handling to report the .slot_reset() callback. Retain this status so
that su
From: Bjorn Helgaas
[ Upstream commit b4c7d2076b4e767dd2e075a2b3a9e57753fc67f5 ]
The PCIe Bandwidth Change Notification feature logs messages when the link
bandwidth changes. Some users have reported that these messages occur
often enough to significantly reduce NVMe performance. GPUs also
From: Bjorn Helgaas
[ Upstream commit b4c7d2076b4e767dd2e075a2b3a9e57753fc67f5 ]
The PCIe Bandwidth Change Notification feature logs messages when the link
bandwidth changes. Some users have reported that these messages occur
often enough to significantly reduce NVMe performance. GPUs also
active;
+};
+
enum ioasid_state {
IOASID_STATE_IDLE,
IOASID_STATE_ACTIVE,
@@ -415,6 +436,38 @@ void ioasid_detach_data(ioasid_t ioasid)
}
EXPORT_SYMBOL_GPL(ioasid_detach_data);
+/**
+ * ioasid_notify - Send notification on a given IOASID for status change.
+ *
+ * @data: The
This refactors the user notification code to have a do / while loop around
the completion condition. This has a small change in semantic, in that
previously we ignored addfd calls upon wakeup if the notification had been
responded to, but instead with the new change we check for an outstanding
On Thu, 2021-02-11 at 14:35 +0200, Matti Vaittinen wrote:
> Provide helper function for IC's implementing regulator notifications
> when an IRQ fires. The helper also works for IRQs which can not be
> acked.
> Helper can be set to disable the IRQ at handler and then re-enabling
> it
> on delayed w
From: Srikanth Thokala
Add support to notify XLink layer upon PCIe link UP/DOWN events
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Reviewed-by: Mark Gross
Signed-off-by: Mark Gross
Signed-off-by: Srikanth Thokala
---
drivers/misc/xlink-pcie/common/core.h | 3 ++
drivers/misc/xlink-pcie/
On Fri, Feb 12, 2021 at 09:33:44AM +, Vaittinen, Matti wrote:
> There seems to be few drivers which need delayed wq and which implement
> .remove() just to call the cancel_delayed_work_sync().
> I think this might help cleaning up those(?) Or am I completely off
> here?
I can see it being us
On Thu, 2021-02-11 at 14:35 +0200, Matti Vaittinen wrote:
> Provide helper function for IC's implementing regulator notifications
> when an IRQ fires. The helper also works for IRQs which can not be
> acked.
> Helper can be set to disable the IRQ at handler and then re-enabling
> it
> on delayed wo
/Documentation/watch_queue.rst
index 426038e10276..75adb1874a0f 100644
--- a/Documentation/watch_queue.rst
+++ b/Documentation/watch_queue.rst
@@ -215,7 +215,7 @@ the following function should be used::
The notification should be preformatted and a pointer to the header (``n``)
should be passed in
e the config so the driver could override it after
diff --git a/drivers/regulator/irq_helpers.c b/drivers/regulator/irq_helpers.c
new file mode 100644
index ..57121554de8e
--- /dev/null
+++ b/drivers/regulator/irq_helpers.c
@@ -0,0 +1,396 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyrigh
Extend regulator notification support
This is an RFC series for getting feedback on extending the regulator
notification and error flag support. Initial discussion on the topic can
be found here:
https://lore.kernel.org/lkml/6046836e22b8252983f08d5621c35ececb97820d.ca...@fi.rohmeurope.com/
This
e are checked as below.
* A request (KVM_REQ_ASYNC_PF) is raised if the worker is the
first one enqueued to the completion queue. With the request,
the completion queue is checked and the worker is dequeued.
A PPI is sent to guest as the page-ready notification and
the guest s
primary goal of the feature (Asynchronous Page
Fault).
This supports delivery of page-not-present notification through SDEI
event when the requested page isn't present. When the notification is
received on the guest's vCPU, something else (another process) can be
scheduled. The design is highli
From: Srikanth Thokala
Add support to notify XLink layer upon PCIe link UP/DOWN events
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Reviewed-by: Mark Gross
Signed-off-by: Mark Gross
Signed-off-by: Srikanth Thokala
---
drivers/misc/xlink-pcie/common/core.h | 3 ++
drivers/misc/xlink-pcie/
When a device error occurs, the mediated device need to be notified in
order to notify the guest of device error. Add support to notify the
specific mdev when an error is wq specific and broadcast errors to all mdev
when it's a generic device error.
Signed-off-by: Dave Jiang
---
drivers/dma/idxd
Expose to the SCMI drivers a new alternative devres managed notifications
API based on protocol handles.
All drivers still keep using the old API, no functional change.
Signed-off-by: Cristian Marussi
---
drivers/firmware/arm_scmi/notify.c | 123 +
include/linux/scmi
From: Bjorn Helgaas
The PCIe Bandwidth Change Notification feature logs messages when the link
bandwidth changes. Some users have reported that these messages occur
often enough to significantly reduce NVMe performance. GPUs also seem to
generate these messages.
We don't know why the
be better as a kernel
parameter? People encountering this seem quite competent in passing kernel
arguments, so having a "pcie_bw_notification=off" would solve their
problems.
I don't want people to have to discover a parameter to solve issues.
If there's a parameter, notificatio
d of making it a config option, wouldn't it be better as a kernel
> > > parameter? People encountering this seem quite competent in passing kernel
> > > arguments, so having a "pcie_bw_notification=off" would solve their
> > > problems.
> >
> >
l
arguments, so having a "pcie_bw_notification=off" would solve their
problems.
I don't want people to have to discover a parameter to solve issues.
If there's a parameter, notification should default to off, and people
who want notification should supply a parameter to enable it.
From: Srikanth Thokala
Add support to notify XLink layer upon PCIe link UP/DOWN events
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Reviewed-by: Mark Gross
Signed-off-by: Srikanth Thokala
---
drivers/misc/xlink-pcie/common/core.h | 3 ++
drivers/misc/xlink-pcie/common/interface.c | 17 +++
From: Srikanth Thokala
Add support to notify XLink layer upon PCIe link UP/DOWN events
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Reviewed-by: Mark Gross
Signed-off-by: Mark Gross
Signed-off-by: Srikanth Thokala
---
drivers/misc/xlink-pcie/common/core.h | 3 ++
drivers/misc/xlink-pcie/
> >
> Instead of making it a config option, wouldn't it be better as a kernel
> parameter? People encountering this seem quite competent in passing kernel
> arguments, so having a "pcie_bw_notification=off" would solve their
> problems.
I don't want people to have to d
On Thu, Jan 28, 2021 at 6:39 PM Bjorn Helgaas wrote:
>
> [+cc Atanas -- thank you very much for the bug report!]
>
> On Sat, Feb 22, 2020 at 10:58:40AM -0600, Bjorn Helgaas wrote:
> > On Wed, Jan 15, 2020 at 04:10:08PM -0600, Bjorn Helgaas wrote:
> > > I think we have a problem with link bandwidth
On 1/28/21 5:51 PM, Sinan Kaya wrote:
On 1/28/2021 6:39 PM, Bjorn Helgaas wrote:
AFAICT, this thread petered out with no resolution.
If the bandwidth change notifications are important to somebody,
please speak up, preferably with a patch that makes the notifications
disabled by default and add
On 1/28/2021 6:39 PM, Bjorn Helgaas wrote:
> AFAICT, this thread petered out with no resolution.
>
> If the bandwidth change notifications are important to somebody,
> please speak up, preferably with a patch that makes the notifications
> disabled by default and adds a parameter to enable them (o
[+cc Atanas -- thank you very much for the bug report!]
On Sat, Feb 22, 2020 at 10:58:40AM -0600, Bjorn Helgaas wrote:
> On Wed, Jan 15, 2020 at 04:10:08PM -0600, Bjorn Helgaas wrote:
> > I think we have a problem with link bandwidth change notifications
> > (see
> > https://git.kernel.org/pub/sc
Hi Jason,
have you had a chance to look at it yet?
Cheers
Linus
Am 16.01.21 um 00:40 schrieb Jason A. Donenfeld:
> Hey Linus,
>
> My email server has been firewalled from vger.kernel.org until today,
> so I didn't see the original until this v2 was sent today. My
> apologies. I'll review this fi
From: Srikanth Thokala
Add support to notify XLink layer upon PCIe link UP/DOWN events
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Reviewed-by: Mark Gross
Signed-off-by: Srikanth Thokala
---
drivers/misc/xlink-pcie/common/core.h | 3 ++
drivers/misc/xlink-pcie/common/interface.c | 17 +++
Hi Jason,
No worries, thanks!
Linus
> Hey Linus,
>
> My email server has been firewalled from vger.kernel.org until today,
> so I didn't see the original until this v2 was sent today. My
> apologies. I'll review this first thing on Monday.
>
> Jason
>
Hey Linus,
My email server has been firewalled from vger.kernel.org until today,
so I didn't see the original until this v2 was sent today. My
apologies. I'll review this first thing on Monday.
Jason
1 - 100 of 1032 matches
Mail list logo
