[PATCH 1/6] PM / devfreq: Free devfreq upon set_freq_table error

When set_freq_table() fails we must still free the previously allocated devfreq context, so jump to the correct label for this. Also when this happens devfreq will always be non-NULL, so drop the unnecessary conditional. Also destroy the devfreq mutex as we're cleaning up the devfreq object.

[PATCH 1/6] PM / devfreq: Free devfreq upon set_freq_table error

When set_freq_table() fails we must still free the previously allocated devfreq context, so jump to the correct label for this. Also when this happens devfreq will always be non-NULL, so drop the unnecessary conditional. Also destroy the devfreq mutex as we're cleaning up the devfreq object.

[PATCH 5/6] PM / devfreq: Use put_device() on device_register error

After calling device_register() the dev must be released using put_device() rather than just freeing the carrying object. The release function of the devfreq device will be called in this case, but as we're yet to add the devfreq instance to the devfreq_list the release function would print a

[PATCH 4/6] PM / devfreq: Remove unnecessary locking

The devfreq lock is used to prevent concurrent access to the devfreq object, but as all operations leading up to the registration of the devfreq device are local to devfreq_add_device() there's no reason to hold the lock. Signed-off-by: Bjorn Andersson ---

[PATCH 2/6] PM / devfreq: Use the device release function for cleanup

Removing the devfreq from the devfreq_list before calling unregister causes the device's release function to not find the devfreq and as such bails from the release function, resulting in the following log entries if an invalid governor is specified. ufshcd-qcom 624000.ufshc: devfreq_add_device:

[PATCH 0/6] Misc devfreq_add_device() fixes

The first 5 patches corrects error handling, reoder things and stop holding the devfreq mutex in devfreq_add_device(). The last patch validates that a client doesn't attempt to provide a freq_table, as the implementation relies on the freq_table being an internal representation of the associated

[PATCH 4/6] PM / devfreq: Remove unnecessary locking

The devfreq lock is used to prevent concurrent access to the devfreq object, but as all operations leading up to the registration of the devfreq device are local to devfreq_add_device() there's no reason to hold the lock. Signed-off-by: Bjorn Andersson --- drivers/devfreq/devfreq.c | 8

[PATCH 2/6] PM / devfreq: Use the device release function for cleanup

Removing the devfreq from the devfreq_list before calling unregister causes the device's release function to not find the devfreq and as such bails from the release function, resulting in the following log entries if an invalid governor is specified. ufshcd-qcom 624000.ufshc: devfreq_add_device:

[PATCH 0/6] Misc devfreq_add_device() fixes

The first 5 patches corrects error handling, reoder things and stop holding the devfreq mutex in devfreq_add_device(). The last patch validates that a client doesn't attempt to provide a freq_table, as the implementation relies on the freq_table being an internal representation of the associated

[PATCH 5/6] PM / devfreq: Use put_device() on device_register error

After calling device_register() the dev must be released using put_device() rather than just freeing the carrying object. The release function of the devfreq device will be called in this case, but as we're yet to add the devfreq instance to the devfreq_list the release function would print a

Re: media: rcar-vin: add group allocator functions

Hi Colin, Thanks for reporting this. I wonder why smatch and sparse did not catch this, the fault can't be mine for writing such a obviously bad thing right :-) I have a patch to address this, just need to test it before posting. On 2018-04-24 14:14:02 +0100, Colin Ian King wrote: > Hi there,

Re: media: rcar-vin: add group allocator functions

Hi Colin, Thanks for reporting this. I wonder why smatch and sparse did not catch this, the fault can't be mine for writing such a obviously bad thing right :-) I have a patch to address this, just need to test it before posting. On 2018-04-24 14:14:02 +0100, Colin Ian King wrote: > Hi there,

[PATCH 6/6] PM / devfreq: Reject client provided freq_table

The devfreq profile's freq_table is an internal resource used to keep track of all levels described in the associated opp table, in order to support levels being enabled and disabled in runtime by e.g. devfreq_cooling. As it is required by the implementation that the device has an associated opp

[PATCH 6/6] PM / devfreq: Reject client provided freq_table

The devfreq profile's freq_table is an internal resource used to keep track of all levels described in the associated opp table, in order to support levels being enabled and disabled in runtime by e.g. devfreq_cooling. As it is required by the implementation that the device has an associated opp

Re: [PATCH] sched/fair: Rearrange select_task_rq_fair() to optimize it

On 04/24/2018 08:47 AM, Joel Fernandes wrote: On Tue, Apr 24, 2018 at 8:46 AM, Joel Fernandes wrote: On Tue, Apr 24, 2018 at 5:35 AM, Peter Zijlstra wrote: On Tue, Apr 24, 2018 at 12:19:07PM +0100, Valentin Schneider wrote: On 24/04/18 11:43,

Re: [PATCH] sched/fair: Rearrange select_task_rq_fair() to optimize it

On 04/24/2018 08:47 AM, Joel Fernandes wrote: On Tue, Apr 24, 2018 at 8:46 AM, Joel Fernandes wrote: On Tue, Apr 24, 2018 at 5:35 AM, Peter Zijlstra wrote: On Tue, Apr 24, 2018 at 12:19:07PM +0100, Valentin Schneider wrote: On 24/04/18 11:43, Peter Zijlstra wrote: On Tue, Apr 24, 2018 at

[PATCH 3/6] PM / devfreq: Reorder devfreq_add_device()

The devfreq lock is used to ensure that the devfreq object is fully initialized before e.g. the sysfs interface is accessing it. Moving all these operations before the device_register() call ensures the same thing without a lock; as it's yet to be shared outside the current context. This allows

[PATCH 3/6] PM / devfreq: Reorder devfreq_add_device()

The devfreq lock is used to ensure that the devfreq object is fully initialized before e.g. the sysfs interface is accessing it. Moving all these operations before the device_register() call ensures the same thing without a lock; as it's yet to be shared outside the current context. This allows

[patch v3 for-4.17] mm, oom: fix concurrent munlock and oom reaper unmap

Since exit_mmap() is done without the protection of mm->mmap_sem, it is possible for the oom reaper to concurrently operate on an mm until MMF_OOM_SKIP is set. This allows munlock_vma_pages_all() to concurrently run while the oom reaper is operating on a vma. Since munlock_vma_pages_range()

[patch v3 for-4.17] mm, oom: fix concurrent munlock and oom reaper unmap

Since exit_mmap() is done without the protection of mm->mmap_sem, it is possible for the oom reaper to concurrently operate on an mm until MMF_OOM_SKIP is set. This allows munlock_vma_pages_all() to concurrently run while the oom reaper is operating on a vma. Since munlock_vma_pages_range()

Re: [Intel-gfx] [PATCH v7 02/10] drm/i915: Move DP modeset retry work into intel_dp

On Wed, 2018-04-11 at 18:54 -0400, Lyude Paul wrote: > While having the modeset_retry_work in intel_connector makes sense with > SST, this paradigm doesn't make a whole ton of sense when it comes to > MST since we have to deal with multiple connectors. In most cases, it's > more useful to just

Re: [Intel-gfx] [PATCH v7 02/10] drm/i915: Move DP modeset retry work into intel_dp

On Wed, 2018-04-11 at 18:54 -0400, Lyude Paul wrote: > While having the modeset_retry_work in intel_connector makes sense with > SST, this paradigm doesn't make a whole ton of sense when it comes to > MST since we have to deal with multiple connectors. In most cases, it's > more useful to just

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap

On Wed, 25 Apr 2018, Tetsuo Handa wrote: > > One of the reasons that I extracted __oom_reap_task_mm() out of the new > > oom_reap_task_mm() is to avoid the checks that would be unnecessary when > > called from exit_mmap(). In this case, we can ignore the > >

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap

On Wed, 25 Apr 2018, Tetsuo Handa wrote: > > One of the reasons that I extracted __oom_reap_task_mm() out of the new > > oom_reap_task_mm() is to avoid the checks that would be unnecessary when > > called from exit_mmap(). In this case, we can ignore the > >

Re: [uml-devel] [REVIEW][PATCH 19/22] signal/um: Use force_sig_fault in relay_signal.

Martin Pärtel writes: > And once more in plain text.. > > On 25 April 2018 at 01:00, Martin Pärtel wrote: >> >> Hi all, >> >> This was ages ago, but from what I remember... >> >>> >>> Having a second look I really don't understand what

Re: [uml-devel] [REVIEW][PATCH 19/22] signal/um: Use force_sig_fault in relay_signal.

Martin Pärtel writes: > And once more in plain text.. > > On 25 April 2018 at 01:00, Martin Pärtel wrote: >> >> Hi all, >> >> This was ages ago, but from what I remember... >> >>> >>> Having a second look I really don't understand what relay_signal is >>> trying to do. >>> >>> The function

Re: [PATCH 0/2] selftests: tracing: Update inter-event testcases

On Tue, 2018-04-24 at 15:22 -0400, Steven Rostedt wrote: > On Thu, 5 Apr 2018 18:28:11 +0900 > Masami Hiramatsu wrote: > > > Hi, > > > > I've fixed a testcase for inter-event extended error > > and added a testcase for multiple actions on trigger, > > which is based on

Re: [PATCH 0/2] selftests: tracing: Update inter-event testcases

On Tue, 2018-04-24 at 15:22 -0400, Steven Rostedt wrote: > On Thu, 5 Apr 2018 18:28:11 +0900 > Masami Hiramatsu wrote: > > > Hi, > > > > I've fixed a testcase for inter-event extended error > > and added a testcase for multiple actions on trigger, > > which is based on what Tom shown in his

Re: [pci PATCH v8 0/4] Add support for unmanaged SR-IOV

On Tue, Apr 24, 2018 at 2:51 PM, Bjorn Helgaas wrote: > On Sat, Apr 21, 2018 at 05:22:27PM -0700, Alexander Duyck wrote: >> On Sat, Apr 21, 2018 at 1:34 PM, Bjorn Helgaas wrote: > >> > For example, I'm not sure what you mean by "devices where the PF is >>

Re: [pci PATCH v8 0/4] Add support for unmanaged SR-IOV

On Tue, Apr 24, 2018 at 2:51 PM, Bjorn Helgaas wrote: > On Sat, Apr 21, 2018 at 05:22:27PM -0700, Alexander Duyck wrote: >> On Sat, Apr 21, 2018 at 1:34 PM, Bjorn Helgaas wrote: > >> > For example, I'm not sure what you mean by "devices where the PF is >> > not capable of managing VF resources."

Re: [PATCH net-next 2/2 v2] netns: isolate seqnums to use per-netns locks

On Tue, Apr 24, 2018 at 04:52:20PM -0500, Eric W. Biederman wrote: > Christian Brauner writes: > > > Now that it's possible to have a different set of uevents in different > > network namespaces, per-network namespace uevent sequence numbers are > > introduced. This

Re: [PATCH net-next 2/2 v2] netns: isolate seqnums to use per-netns locks

On Tue, Apr 24, 2018 at 04:52:20PM -0500, Eric W. Biederman wrote: > Christian Brauner writes: > > > Now that it's possible to have a different set of uevents in different > > network namespaces, per-network namespace uevent sequence numbers are > > introduced. This increases performance as

[PATCH] selftests: net: add in_netns.sh TEST_GEN_PROGS_EXTENDED

Script in_netns.sh is a utility function and not its own test so it shouldn't be part of the TEST_PROGS. The in_netns.sh get used by run_afpackettests. To install in_netns.sh without being added to the main run_kselftest.sh script use the TEST_GEN_PROGS_EXTENDED variable. Fixes: 5ff9c1a3dd92

[PATCH] selftests: net: add in_netns.sh TEST_GEN_PROGS_EXTENDED

Script in_netns.sh is a utility function and not its own test so it shouldn't be part of the TEST_PROGS. The in_netns.sh get used by run_afpackettests. To install in_netns.sh without being added to the main run_kselftest.sh script use the TEST_GEN_PROGS_EXTENDED variable. Fixes: 5ff9c1a3dd92

Re: vmalloc with GFP_NOFS

Am Dienstag, 24. April 2018, 21:28:03 CEST schrieb Michal Hocko: > > Also only for debugging. > > Getting rid of vmalloc with GFP_NOFS in UBIFS is no big problem. > > I can prepare a patch. > > Cool! > > Anyway, if UBIFS has some reclaim recursion critical sections in general > it would be

Re: vmalloc with GFP_NOFS

Am Dienstag, 24. April 2018, 21:28:03 CEST schrieb Michal Hocko: > > Also only for debugging. > > Getting rid of vmalloc with GFP_NOFS in UBIFS is no big problem. > > I can prepare a patch. > > Cool! > > Anyway, if UBIFS has some reclaim recursion critical sections in general > it would be

Re: [PATCH v5 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V

On 4/24/18 12:44 PM, Palmer Dabbelt wrote: On Tue, 24 Apr 2018 12:27:26 PDT (-0700), atish.pa...@wdc.com wrote: On 4/24/18 11:07 AM, Atish Patra wrote: On 4/19/18 4:28 PM, Alan Kao wrote: This implements the baseline PMU for RISC-V platforms. To ease future PMU portings, a guide is also

Re: [PATCH v5 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V

On 4/24/18 12:44 PM, Palmer Dabbelt wrote: On Tue, 24 Apr 2018 12:27:26 PDT (-0700), atish.pa...@wdc.com wrote: On 4/24/18 11:07 AM, Atish Patra wrote: On 4/19/18 4:28 PM, Alan Kao wrote: This implements the baseline PMU for RISC-V platforms. To ease future PMU portings, a guide is also

Re: [PATCH 3/3] scsi: ufs: Use freq table with devfreq

On Tue 24 Apr 15:08 PDT 2018, Subhash Jadavani wrote: > On 2018-04-23 17:20, Bjorn Andersson wrote: > > devfreq requires that the client operates on actual frequencies, not > > only 0 and UMAX_INT and as such UFS brok with the introduction of > > f1d981eaecf8 ("PM / devfreq: Use the available

Re: [PATCH 3/3] scsi: ufs: Use freq table with devfreq

On Tue 24 Apr 15:08 PDT 2018, Subhash Jadavani wrote: > On 2018-04-23 17:20, Bjorn Andersson wrote: > > devfreq requires that the client operates on actual frequencies, not > > only 0 and UMAX_INT and as such UFS brok with the introduction of > > f1d981eaecf8 ("PM / devfreq: Use the available

Re: CLOCK_MONOTONIC, BOOTTIME, suspend and screensaver regression

On Tuesday, April 24, 2018 2:07:00 PM CEST Pavel Machek wrote: > > --CE+1k2dSO48ffgeK > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > Hi! > > In 4.17-rc1 I have weird problems with network manager... and I also > have

Re: CLOCK_MONOTONIC, BOOTTIME, suspend and screensaver regression

On Tuesday, April 24, 2018 2:07:00 PM CEST Pavel Machek wrote: > > --CE+1k2dSO48ffgeK > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > Hi! > > In 4.17-rc1 I have weird problems with network manager... and I also > have

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

Andrey Grodzovsky writes: > On 04/24/2018 05:21 PM, Eric W. Biederman wrote: >> Andrey Grodzovsky writes: >> >>> On 04/24/2018 03:44 PM, Daniel Vetter wrote: On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote: > Adding

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

Andrey Grodzovsky writes: > On 04/24/2018 05:21 PM, Eric W. Biederman wrote: >> Andrey Grodzovsky writes: >> >>> On 04/24/2018 03:44 PM, Daniel Vetter wrote: On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote: > Adding the dri-devel list, since this is driver independent

Re: [PATCH 3/3] scsi: ufs: Use freq table with devfreq

On 2018-04-23 17:20, Bjorn Andersson wrote: devfreq requires that the client operates on actual frequencies, not only 0 and UMAX_INT and as such UFS brok with the introduction of f1d981eaecf8 ("PM / devfreq: Use the available min/max frequency"). This patch registers the frequencies of the

Re: [PATCH 3/3] scsi: ufs: Use freq table with devfreq

On 2018-04-23 17:20, Bjorn Andersson wrote: devfreq requires that the client operates on actual frequencies, not only 0 and UMAX_INT and as such UFS brok with the introduction of f1d981eaecf8 ("PM / devfreq: Use the available min/max frequency"). This patch registers the frequencies of the

Re: [uml-devel] [REVIEW][PATCH 19/22] signal/um: Use force_sig_fault in relay_signal.

And once more in plain text.. On 25 April 2018 at 01:00, Martin Pärtel wrote: > > Hi all, > > This was ages ago, but from what I remember... > >> >> Having a second look I really don't understand what relay_signal is >> trying to do. >> >> The function relay_signal does

Re: [uml-devel] [REVIEW][PATCH 19/22] signal/um: Use force_sig_fault in relay_signal.

And once more in plain text.. On 25 April 2018 at 01:00, Martin Pärtel wrote: > > Hi all, > > This was ages ago, but from what I remember... > >> >> Having a second look I really don't understand what relay_signal is >> trying to do. >> >> The function relay_signal does not pass siginfo through

Re: [PATCH 2/2] power: pf1550_charger: add pf1550 charger driver

Hi Abel, Some comments below, hope will be helpful for you. 2018-04-17 16:20 GMT+02:00 Abel Vesa : > From: Robin Gong > > Add basic pf1550 charger driver. > > Signed-off-by: Robin Gong > Signed-off-by: Abel Vesa >

Re: [PATCH 2/2] power: pf1550_charger: add pf1550 charger driver

Hi Abel, Some comments below, hope will be helpful for you. 2018-04-17 16:20 GMT+02:00 Abel Vesa : > From: Robin Gong > > Add basic pf1550 charger driver. > > Signed-off-by: Robin Gong > Signed-off-by: Abel Vesa > --- > drivers/power/supply/Kconfig | 6 + >

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap

David Rientjes wrote: > On Tue, 24 Apr 2018, Tetsuo Handa wrote: > > > > > We can call __oom_reap_task_mm() from exit_mmap() (or __mmput()) before > > > > exit_mmap() holds mmap_sem for write. Then, at least memory which could > > > > have been reclaimed if exit_mmap() did not hold mmap_sem for

Re: [patch v2] mm, oom: fix concurrent munlock and oom reaper unmap

David Rientjes wrote: > On Tue, 24 Apr 2018, Tetsuo Handa wrote: > > > > > We can call __oom_reap_task_mm() from exit_mmap() (or __mmput()) before > > > > exit_mmap() holds mmap_sem for write. Then, at least memory which could > > > > have been reclaimed if exit_mmap() did not hold mmap_sem for

Re: [PATCH net-next 1/2 v2] netns: restrict uevents

We already do this in practice in userspace. It doesn't make much sense to perform this delivery. So we might as well make this optimization. Christian Brauner writes: > commit 07e98962fa77 ("kobject: Send hotplug events in all network namespaces") > > enabled

Re: [PATCH net-next 1/2 v2] netns: restrict uevents

We already do this in practice in userspace. It doesn't make much sense to perform this delivery. So we might as well make this optimization. Christian Brauner writes: > commit 07e98962fa77 ("kobject: Send hotplug events in all network namespaces") > > enabled sending hotplug events into all

Re: [PATCH v2] selftests: bpf: update .gitignore with missing file

On 04/24/2018 12:53 AM, Anders Roxell wrote: > Fixes: c0fa1b6c3efc ("bpf: btf: Add BTF tests") > Signed-off-by: Anders Roxell > --- > Rebased against bpf-next. Applied to bpf-next, thanks Anders!

Re: [PATCH v2] selftests: bpf: update .gitignore with missing file

On 04/24/2018 12:53 AM, Anders Roxell wrote: > Fixes: c0fa1b6c3efc ("bpf: btf: Add BTF tests") > Signed-off-by: Anders Roxell > --- > Rebased against bpf-next. Applied to bpf-next, thanks Anders!

Re: [PATCH net-next 2/2 v2] netns: isolate seqnums to use per-netns locks

Christian Brauner writes: > Now that it's possible to have a different set of uevents in different > network namespaces, per-network namespace uevent sequence numbers are > introduced. This increases performance as locking is now restricted to the > network

Re: [PATCH net-next 2/2 v2] netns: isolate seqnums to use per-netns locks

Christian Brauner writes: > Now that it's possible to have a different set of uevents in different > network namespaces, per-network namespace uevent sequence numbers are > introduced. This increases performance as locking is now restricted to the > network namespace affected by the uevent

Re: [pci PATCH v8 0/4] Add support for unmanaged SR-IOV

On Sat, Apr 21, 2018 at 05:22:27PM -0700, Alexander Duyck wrote: > On Sat, Apr 21, 2018 at 1:34 PM, Bjorn Helgaas wrote: > > For example, I'm not sure what you mean by "devices where the PF is > > not capable of managing VF resources." > > > > It *sounds* like you're saying

Re: [pci PATCH v8 0/4] Add support for unmanaged SR-IOV

On Sat, Apr 21, 2018 at 05:22:27PM -0700, Alexander Duyck wrote: > On Sat, Apr 21, 2018 at 1:34 PM, Bjorn Helgaas wrote: > > For example, I'm not sure what you mean by "devices where the PF is > > not capable of managing VF resources." > > > > It *sounds* like you're saying the hardware works

Re: [PATCH 1/3] sched: remove select_idle_core() for scalability

On 04/24/2018 05:46 AM, Peter Zijlstra wrote: On Mon, Apr 23, 2018 at 05:41:14PM -0700, subhra mazumdar wrote: select_idle_core() can potentially search all cpus to find the fully idle core even if there is one such core. Removing this is necessary to achieve scalability in the fast path. So

Re: [PATCH 1/3] sched: remove select_idle_core() for scalability

On 04/24/2018 05:46 AM, Peter Zijlstra wrote: On Mon, Apr 23, 2018 at 05:41:14PM -0700, subhra mazumdar wrote: select_idle_core() can potentially search all cpus to find the fully idle core even if there is one such core. Removing this is necessary to achieve scalability in the fast path. So

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On Tue, Apr 24, 2018 at 05:02:40PM -0400, Andrey Grodzovsky wrote: > > > On 04/24/2018 03:44 PM, Daniel Vetter wrote: > > On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote: > > > Adding the dri-devel list, since this is driver independent code. > > > > > > > > > On 2018-04-24 05:30

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On Tue, Apr 24, 2018 at 05:02:40PM -0400, Andrey Grodzovsky wrote: > > > On 04/24/2018 03:44 PM, Daniel Vetter wrote: > > On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote: > > > Adding the dri-devel list, since this is driver independent code. > > > > > > > > > On 2018-04-24 05:30

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On 04/24/2018 05:21 PM, Eric W. Biederman wrote: Andrey Grodzovsky writes: On 04/24/2018 03:44 PM, Daniel Vetter wrote: On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote: Adding the dri-devel list, since this is driver independent code. On

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On 04/24/2018 05:21 PM, Eric W. Biederman wrote: Andrey Grodzovsky writes: On 04/24/2018 03:44 PM, Daniel Vetter wrote: On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote: Adding the dri-devel list, since this is driver independent code. On 2018-04-24 05:30 PM, Andrey

Confidential Request!!

-- Dear Friend, My name is Mr. Williams Abbas, Executive Director and Head of Personal Banking ( Investment & Development). I am a private investor who wants to invest his financial estate in long-term business venture especially in public and private securities (including real estate, energy,

Confidential Request!!

-- Dear Friend, My name is Mr. Williams Abbas, Executive Director and Head of Personal Banking ( Investment & Development). I am a private investor who wants to invest his financial estate in long-term business venture especially in public and private securities (including real estate, energy,

Re: [PATCH] do not call trace_printk on non-debug build

I have seen case when LLVM appends postfix to most function names, causing func such as tracing_mark_write becomes tracing_mark_write.XXX which messed all post-processing. Also I think this is a typo? https://lkml.org/lkml/2018/4/24/1176 On Tue, Apr 24, 2018 at 1:48 PM Steven Rostedt

Re: [PATCH] do not call trace_printk on non-debug build

I have seen case when LLVM appends postfix to most function names, causing func such as tracing_mark_write becomes tracing_mark_write.XXX which messed all post-processing. Also I think this is a typo? https://lkml.org/lkml/2018/4/24/1176 On Tue, Apr 24, 2018 at 1:48 PM Steven Rostedt wrote: > On

Re: [PATCH 2/7] aio: remove an outdated BUG_ON and comment in aio_complete

On Sun, Apr 15, 2018 at 05:01:03PM +0200, Christoph Hellwig wrote: > These days we don't treat sync iocbs special in the aio completion code as > they never use it. Remove the old comment and BUG_ON given that the > current definition of is_sync_kiocb makes it impossible to hit. > >

Re: [PATCH 2/7] aio: remove an outdated BUG_ON and comment in aio_complete

On Sun, Apr 15, 2018 at 05:01:03PM +0200, Christoph Hellwig wrote: > These days we don't treat sync iocbs special in the aio completion code as > they never use it. Remove the old comment and BUG_ON given that the > current definition of is_sync_kiocb makes it impossible to hit. > >

[PATCH] kernel.h: fix a typo in comment

From: Wei Wang Signed-off-by: Wei Wang --- include/linux/kernel.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/kernel.h b/include/linux/kernel.h index 6a1eb0b0aad96..e37e40ff14bba 100644 --- a/include/linux/kernel.h +++

[PATCH] kernel.h: fix a typo in comment

From: Wei Wang Signed-off-by: Wei Wang --- include/linux/kernel.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/kernel.h b/include/linux/kernel.h index 6a1eb0b0aad96..e37e40ff14bba 100644 --- a/include/linux/kernel.h +++ b/include/linux/kernel.h @@ -664,7

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

Andrey Grodzovsky writes: > On 04/24/2018 03:44 PM, Daniel Vetter wrote: >> On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote: >>> Adding the dri-devel list, since this is driver independent code. >>> >>> >>> On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote:

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

Andrey Grodzovsky writes: > On 04/24/2018 03:44 PM, Daniel Vetter wrote: >> On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote: >>> Adding the dri-devel list, since this is driver independent code. >>> >>> >>> On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote: Avoid calling

[PATCH] [v2] x86: ipc: fix x32 version of shmid64_ds and msqid64_ds

A bugfix broke the x32 shmid64_ds and msqid64_ds data structure layout (as seen from user space) a few years ago: Originally, __BITS_PER_LONG was defined as 64 on x32, so we did not have padding after the 64-bit __kernel_time_t fields, After __BITS_PER_LONG got changed to 32, applications would

[PATCH] [v2] x86: ipc: fix x32 version of shmid64_ds and msqid64_ds

A bugfix broke the x32 shmid64_ds and msqid64_ds data structure layout (as seen from user space) a few years ago: Originally, __BITS_PER_LONG was defined as 64 on x32, so we did not have padding after the 64-bit __kernel_time_t fields, After __BITS_PER_LONG got changed to 32, applications would

Re: Regression 4.17-rc1: SSD doesn properly resume causing system hang (NULL pointer dereference)

On Tue, 2018-04-24 at 23:04 +0200, Paul Menzel wrote: > I applied your change, and rebuilt the Linux kernel. Unfortunately, it > looks like, it didn’t make a difference. In that case I don't know what is causing the failure. Can you run a bisect to determine which commit introduced this

Re: Regression 4.17-rc1: SSD doesn properly resume causing system hang (NULL pointer dereference)

On Tue, 2018-04-24 at 23:04 +0200, Paul Menzel wrote: > I applied your change, and rebuilt the Linux kernel. Unfortunately, it > looks like, it didn’t make a difference. In that case I don't know what is causing the failure. Can you run a bisect to determine which commit introduced this

Re: [RFC][PATCH 0/1] serdev: Support HS-UART serdev slaves over tty

Hi, On 24-04-18 19:18, Johan Hovold wrote: [ Adding some more people on CC. ] On Tue, Apr 24, 2018 at 04:29:53PM +0800, Shrirang Bagul wrote: On systems using Intel Atom (Baytrail-I) SoC's, slave devices connected on HSUART1/2 ports are described by the ACPI BIOS as virtual hardware using

Re: [RFC][PATCH 0/1] serdev: Support HS-UART serdev slaves over tty

Hi, On 24-04-18 19:18, Johan Hovold wrote: [ Adding some more people on CC. ] On Tue, Apr 24, 2018 at 04:29:53PM +0800, Shrirang Bagul wrote: On systems using Intel Atom (Baytrail-I) SoC's, slave devices connected on HSUART1/2 ports are described by the ACPI BIOS as virtual hardware using

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

On 04/23/18 22:29, Jan Kiszka wrote: > On 2018-04-24 00:38, Frank Rowand wrote: >> Hi Jan, >> >> + Alan Tull for fpga perspective >> >> On 04/22/18 03:30, Jan Kiszka wrote: >>> On 2018-04-11 07:42, Jan Kiszka wrote: On 2018-04-05 23:12, Rob Herring wrote: > On Thu, Apr 5, 2018 at 2:28 PM,

Re: [PATCH v7 2/5] of: change overlay apply input data from unflattened to FDT

On 04/23/18 22:29, Jan Kiszka wrote: > On 2018-04-24 00:38, Frank Rowand wrote: >> Hi Jan, >> >> + Alan Tull for fpga perspective >> >> On 04/22/18 03:30, Jan Kiszka wrote: >>> On 2018-04-11 07:42, Jan Kiszka wrote: On 2018-04-05 23:12, Rob Herring wrote: > On Thu, Apr 5, 2018 at 2:28 PM,

Re: [alsa-devel] [PATCH v4 3/3] ALSA: hda: Disabled unused audio controller for Dell platforms with Switchable Graphics

On Mon, Apr 23, 2018 at 04:18:35PM +0800, Kai Heng Feng wrote: > >On Apr 23, 2018, at 4:08 PM, Pali Rohár wrote: > >On Monday 23 April 2018 16:04:55 Kai Heng Feng wrote: > >>>On Apr 20, 2018, at 8:10 PM, Takashi Iwai wrote: > >>>On Fri, 20 Apr 2018 11:44:32

Re: [alsa-devel] [PATCH v4 3/3] ALSA: hda: Disabled unused audio controller for Dell platforms with Switchable Graphics

On Mon, Apr 23, 2018 at 04:18:35PM +0800, Kai Heng Feng wrote: > >On Apr 23, 2018, at 4:08 PM, Pali Rohár wrote: > >On Monday 23 April 2018 16:04:55 Kai Heng Feng wrote: > >>>On Apr 20, 2018, at 8:10 PM, Takashi Iwai wrote: > >>>On Fri, 20 Apr 2018 11:44:32 +0200, Kai-Heng Feng wrote: > Now

Re: [RFC 00/10] ARM: Remove support for Exynos5440

On Tue, Apr 24, 2018 at 10:56 PM, Krzysztof Kozlowski wrote: > On Tue, Apr 24, 2018 at 10:50:58PM +0200, Arnd Bergmann wrote: >> On Tue, Apr 24, 2018 at 10:32 PM, Krzysztof Kozlowski >> wrote: > The only dependency is through Kconfig symbol (SOC_EXYNOS5440).

Re: [RFC 00/10] ARM: Remove support for Exynos5440

On Tue, Apr 24, 2018 at 10:56 PM, Krzysztof Kozlowski wrote: > On Tue, Apr 24, 2018 at 10:50:58PM +0200, Arnd Bergmann wrote: >> On Tue, Apr 24, 2018 at 10:32 PM, Krzysztof Kozlowski >> wrote: > The only dependency is through Kconfig symbol (SOC_EXYNOS5440). After > applying 10/10, which

Re: [PATCH v2 3/7] powerpc: use task_pid_nr() for TID allocation

Andrew Donnellan [andrew.donnel...@au1.ibm.com] wrote: > [+ Sukadev, Christophe] > > On 18/04/18 11:08, Alastair D'Silva wrote: > > From: Alastair D'Silva > > > > The current implementation of TID allocation, using a global IDR, may > > result in an errant process starving

Re: [PATCH v2 3/7] powerpc: use task_pid_nr() for TID allocation

Andrew Donnellan [andrew.donnel...@au1.ibm.com] wrote: > [+ Sukadev, Christophe] > > On 18/04/18 11:08, Alastair D'Silva wrote: > > From: Alastair D'Silva > > > > The current implementation of TID allocation, using a global IDR, may > > result in an errant process starving the system of

Re: [PATCH v3 02/12] KVM: arm/arm64: Document KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION

On Tue, Apr 24, 2018 at 05:50:37PM +0100, Peter Maydell wrote: > On 24 April 2018 at 17:46, Christoffer Dall wrote: > > On Fri, Apr 13, 2018 at 10:20:48AM +0200, Eric Auger wrote: > >> --- a/Documentation/virtual/kvm/devices/arm-vgic-v3.txt > >> +++

Re: [PATCH v3 02/12] KVM: arm/arm64: Document KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION

On Tue, Apr 24, 2018 at 05:50:37PM +0100, Peter Maydell wrote: > On 24 April 2018 at 17:46, Christoffer Dall wrote: > > On Fri, Apr 13, 2018 at 10:20:48AM +0200, Eric Auger wrote: > >> --- a/Documentation/virtual/kvm/devices/arm-vgic-v3.txt > >> +++

[PATCH] firmware: dmi: Add access to the SKU ID string

This is used in some systems from user space for determining the identity of the device. Expose this as a file so that that user-space tools don't need to read from /sys/firmware/dmi/tables/DMI Signed-off-by: Simon Glass --- drivers/firmware/dmi-id.c | 2 ++

[PATCH] firmware: dmi: Add access to the SKU ID string

This is used in some systems from user space for determining the identity of the device. Expose this as a file so that that user-space tools don't need to read from /sys/firmware/dmi/tables/DMI Signed-off-by: Simon Glass --- drivers/firmware/dmi-id.c | 2 ++ drivers/firmware/dmi_scan.c

Re: [PATCH v2 2/2] regulator: add QCOM RPMh regulator driver

On 04/24/2018 10:45 AM, Mark Brown wrote: >>> You'd need to ask Mark if he's OK with it, but a option #3 is to add a >>> patch to your series fix the regulator framework to try setting the >>> voltage if _regulator_get_voltage() fails. Presumably in >>> machine_constraints_voltage() you'd now do

Re: [PATCH v2 2/2] regulator: add QCOM RPMh regulator driver

On 04/24/2018 10:45 AM, Mark Brown wrote: >>> You'd need to ask Mark if he's OK with it, but a option #3 is to add a >>> patch to your series fix the regulator framework to try setting the >>> voltage if _regulator_get_voltage() fails. Presumably in >>> machine_constraints_voltage() you'd now do

Re: [PATCH 2/3] scsi: ufs: Extract devfreq registration

On 2018-04-23 17:20, Bjorn Andersson wrote: Failing to register with devfreq leaves hba->devfreq assigned, which causes the error path to dereference the ERR_PTR(). Rather than bolting on more conditionals, move the call of devm_devfreq_add_device() into it's own function and only update

Re: [PATCH 2/3] scsi: ufs: Extract devfreq registration

On 2018-04-23 17:20, Bjorn Andersson wrote: Failing to register with devfreq leaves hba->devfreq assigned, which causes the error path to dereference the ERR_PTR(). Rather than bolting on more conditionals, move the call of devm_devfreq_add_device() into it's own function and only update

Re: [PATCH v3 10/12] KVM: arm/arm64: Add KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION

On Fri, Apr 13, 2018 at 10:20:56AM +0200, Eric Auger wrote: > This new attribute allows the userspace to set the base address > of a reditributor region, relaxing the constraint of having all > consecutive redistibutor frames contiguous. > > Signed-off-by: Eric Auger > ---

Re: [PATCH v3 09/12] KVM: arm/arm64: Check all vcpu redistributors are set on map_resources

On Fri, Apr 13, 2018 at 10:20:55AM +0200, Eric Auger wrote: > On vcpu first run, we eventually know the actual number of vcpus. > This is a synchronization point to check all redistributors regions > were assigned. Isn't it the other way around? We want to check that all redistributors (one for

<    1   2   3   4   5   6   7   8   9   10   >