Re: [PATCH v3 14/14] tracing/selftest: Add test to test hist trigger between kernel event and trace_marker

On Wed, 16 May 2018 11:00:26 -0400 Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > Add a test that tests a trigger that is initiated by a kernel event > (sched_waking) and compared to a write to the trace_marker. > > Signed-off-by: Steven

Re: [PATCH v3 14/14] tracing/selftest: Add test to test hist trigger between kernel event and trace_marker

On Wed, 16 May 2018 11:00:26 -0400 Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > Add a test that tests a trigger that is initiated by a kernel event > (sched_waking) and compared to a write to the trace_marker. > > Signed-off-by: Steven Rostedt (VMware) > --- >

Re: [PATCH 3/6] block: Create scsi_sense.h for SCSI and ATAPI

On 5/22/18 5:49 PM, Kees Cook wrote: > On Tue, May 22, 2018 at 4:42 PM, Jens Axboe wrote: >> On May 22, 2018, at 5:31 PM, Kees Cook wrote: >>> On Tue, May 22, 2018 at 12:16 PM, Jens Axboe wrote: > On 5/22/18 1:13 PM, Christoph

Re: [PATCH 3/6] block: Create scsi_sense.h for SCSI and ATAPI

On 5/22/18 5:49 PM, Kees Cook wrote: > On Tue, May 22, 2018 at 4:42 PM, Jens Axboe wrote: >> On May 22, 2018, at 5:31 PM, Kees Cook wrote: >>> On Tue, May 22, 2018 at 12:16 PM, Jens Axboe wrote: > On 5/22/18 1:13 PM, Christoph Hellwig wrote: >> On Tue, May 22, 2018 at 01:09:41PM

Re: [PATCH v3 13/14] tracing/selftest: Add selftests to test trace_marker histogram triggers

On Wed, 16 May 2018 11:00:25 -0400 Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > Add a couple of tests that test the trace_marker histogram triggers. > One does a straight histogram test, the other will create a synthetic event > and test

Re: [PATCH v3 13/14] tracing/selftest: Add selftests to test trace_marker histogram triggers

On Wed, 16 May 2018 11:00:25 -0400 Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > Add a couple of tests that test the trace_marker histogram triggers. > One does a straight histogram test, the other will create a synthetic event > and test the latency between two different writes

[PATCH] sched,tracing: Correct trace_sched_pi_setprio() for deboosting

This mostly a revert of commit b91473ff6e97 ("sched,tracing: Update trace_sched_pi_setprio()") except for the XXX comments. Since that commit I see during a deboost a task this: |futex sched_pi_setprio: comm=futex_requeue_p pid=2234 oldprio=98 newprio=98 |futex sched_switch:

[PATCH] sched,tracing: Correct trace_sched_pi_setprio() for deboosting

This mostly a revert of commit b91473ff6e97 ("sched,tracing: Update trace_sched_pi_setprio()") except for the XXX comments. Since that commit I see during a deboost a task this: |futex sched_pi_setprio: comm=futex_requeue_p pid=2234 oldprio=98 newprio=98 |futex sched_switch:

Re: [PATCH v2 4/7] Bluetooth: Add new quirk for non-persistent setup settings

On Wed, 2018-05-23 at 14:31 +0200, Marcel Holtmann wrote: > Hi Sean, > > >> > >> [ ... ] > >> > -if (hci_dev_test_flag(hdev, HCI_SETUP)) { > +if (hci_dev_test_flag(hdev, HCI_SETUP) || > +test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, >quirks)) { >

Re: [PATCH v2 4/7] Bluetooth: Add new quirk for non-persistent setup settings

On Wed, 2018-05-23 at 14:31 +0200, Marcel Holtmann wrote: > Hi Sean, > > >> > >> [ ... ] > >> > -if (hci_dev_test_flag(hdev, HCI_SETUP)) { > +if (hci_dev_test_flag(hdev, HCI_SETUP) || > +test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, >quirks)) { >

Re: [PATCH 07/24] arm64: ilp32: add documentation on the ILP32 ABI for ARM64

On Wed 2018-05-16 11:18:52, Yury Norov wrote: > Based on Andrew Pinski's patch-series. > > Signed-off-by: Yury Norov So Andrew's signoff should be here? > --- > Documentation/arm64/ilp32.txt | 45 +++ > 1 file changed, 45

Re: v4.17-rc1: regressions on N900, N950

On Wed 2018-05-23 00:56:38, Aaro Koskinen wrote: > Hi, > > On Tue, May 22, 2018 at 10:58:26PM +0200, Pavel Machek wrote: > > On Tue 2018-05-22 22:41:39, Aaro Koskinen wrote: > > > My device worked with v4.17-rc1 (haven't found time to test newer > > > kernels), > > > but if you say the probe

Re: [PATCH 07/24] arm64: ilp32: add documentation on the ILP32 ABI for ARM64

On Wed 2018-05-16 11:18:52, Yury Norov wrote: > Based on Andrew Pinski's patch-series. > > Signed-off-by: Yury Norov So Andrew's signoff should be here? > --- > Documentation/arm64/ilp32.txt | 45 +++ > 1 file changed, 45 insertions(+) > create mode 100644

Re: v4.17-rc1: regressions on N900, N950

On Wed 2018-05-23 00:56:38, Aaro Koskinen wrote: > Hi, > > On Tue, May 22, 2018 at 10:58:26PM +0200, Pavel Machek wrote: > > On Tue 2018-05-22 22:41:39, Aaro Koskinen wrote: > > > My device worked with v4.17-rc1 (haven't found time to test newer > > > kernels), > > > but if you say the probe

Re: [PATCH v7 3/3] gpio: pca953x: fix address calculation for pcal6524

On Thu 2018-05-17 06:59:49, H. Nikolaus Schaller wrote: > The register constants are so far defined in a way that they fit > for the pcal9555a when shifted by the number of banks, i.e. are > multiplied by 2 in the accessor function. > > Now, the pcal6524 has 3 banks which means the relative

Re: [PATCH v7 3/3] gpio: pca953x: fix address calculation for pcal6524

On Thu 2018-05-17 06:59:49, H. Nikolaus Schaller wrote: > The register constants are so far defined in a way that they fit > for the pcal9555a when shifted by the number of banks, i.e. are > multiplied by 2 in the accessor function. > > Now, the pcal6524 has 3 banks which means the relative

Re: [PATCH 2/2] mm: do not warn on offline nodes unless the specific node is explicitly requested

On Wed 23-05-18 19:15:51, Anshuman Khandual wrote: > On 05/23/2018 06:25 PM, Michal Hocko wrote: > > when adding memory to a node that is currently offline. > > > > The VM_WARN_ON is just too loud without a good reason. In this > > particular case we are doing > > alloc_pages_node(node,

Re: [PATCH 2/2] mm: do not warn on offline nodes unless the specific node is explicitly requested

On Wed 23-05-18 19:15:51, Anshuman Khandual wrote: > On 05/23/2018 06:25 PM, Michal Hocko wrote: > > when adding memory to a node that is currently offline. > > > > The VM_WARN_ON is just too loud without a good reason. In this > > particular case we are doing > > alloc_pages_node(node,

Re: [PATCH v2 09/16] irqchip/irq-mvebu-sei: add new driver for Marvell SEI

On 22/05/18 10:40, Miquel Raynal wrote: > This is a cascaded interrupt controller in the AP806 GIC that collapses > SEIs (System Error Interrupt) coming from the AP and the CPs (through > the ICU). > > The SEI handles up to 64 interrupts. The first 21 interrupts are wired > and come from the AP.

Re: [PATCH v2 09/16] irqchip/irq-mvebu-sei: add new driver for Marvell SEI

On 22/05/18 10:40, Miquel Raynal wrote: > This is a cascaded interrupt controller in the AP806 GIC that collapses > SEIs (System Error Interrupt) coming from the AP and the CPs (through > the ICU). > > The SEI handles up to 64 interrupts. The first 21 interrupts are wired > and come from the AP.

Re: [PATCH 13/13] atomics/treewide: make test ops optional

On Wed, May 23, 2018 at 3:35 PM, Mark Rutland wrote: > Some of the atomics return the result of a test applied after the atomic > operation, and almost all architectures implement these as trivial > wrappers around the underlying atomic. Specifically: > > * _inc_and_test(v)

Re: [PATCH 13/13] atomics/treewide: make test ops optional

On Wed, May 23, 2018 at 3:35 PM, Mark Rutland wrote: > Some of the atomics return the result of a test applied after the atomic > operation, and almost all architectures implement these as trivial > wrappers around the underlying atomic. Specifically: > > * _inc_and_test(v) is (_inc_return(v) ==

Re: [PATCH] usb: hub: Per-port setting to use old enumeration scheme

On Wed, 23 May 2018, Nicolas Boichat wrote: > The "old" enumeration scheme is considerably faster (it takes > ~294ms instead of ~439ms to get the descriptor). > > It is currently only possible to use the old scheme globally > (/sys/module/usbcore/parameters/old_scheme_first), which is not >

Re: [PATCH] usb: hub: Per-port setting to use old enumeration scheme

On Wed, 23 May 2018, Nicolas Boichat wrote: > The "old" enumeration scheme is considerably faster (it takes > ~294ms instead of ~439ms to get the descriptor). > > It is currently only possible to use the old scheme globally > (/sys/module/usbcore/parameters/old_scheme_first), which is not >

Re: [PATCH 04/13] atomics/treewide: make atomic_fetch_add_unless() optional

On Wed, May 23, 2018 at 3:35 PM, Mark Rutland wrote: > Several architectures these have a near-identical implementation based > on atomic_read() and atomic_cmpxchg() that we can instead define in > , so let's do so, using something close to the existing > x86 implementation

Re: [PATCH 04/13] atomics/treewide: make atomic_fetch_add_unless() optional

On Wed, May 23, 2018 at 3:35 PM, Mark Rutland wrote: > Several architectures these have a near-identical implementation based > on atomic_read() and atomic_cmpxchg() that we can instead define in > , so let's do so, using something close to the existing > x86 implementation with try_cmpxchg(). >

Re: [PATCH 01/13] atomics/treewide: s/__atomic_add_unless/atomic_fetch_add_unless/

On Wed, May 23, 2018 at 3:35 PM, Mark Rutland wrote: > While __atomic_add_unless was originally intended as a building-block > for atomic_add_unless, it's now used in a number of places around the > kernel. It's the only common atomic operation named __atomic*(), rather >

Re: [PATCH 01/13] atomics/treewide: s/__atomic_add_unless/atomic_fetch_add_unless/

On Wed, May 23, 2018 at 3:35 PM, Mark Rutland wrote: > While __atomic_add_unless was originally intended as a building-block > for atomic_add_unless, it's now used in a number of places around the > kernel. It's the only common atomic operation named __atomic*(), rather > than atomic_*(), and for

Re: [PATCH v9 3/4] arm64: Implement page table free interfaces

Hi Chintan, [as a side note: I'm confused on the status of this patch series, as part of it was reposted separately by Toshi. Please can you work together?] On Mon, Apr 30, 2018 at 01:11:33PM +0530, Chintan Pandya wrote: > Implement pud_free_pmd_page() and pmd_free_pte_page(). > >

Re: [PATCH v9 3/4] arm64: Implement page table free interfaces

Hi Chintan, [as a side note: I'm confused on the status of this patch series, as part of it was reposted separately by Toshi. Please can you work together?] On Mon, Apr 30, 2018 at 01:11:33PM +0530, Chintan Pandya wrote: > Implement pud_free_pmd_page() and pmd_free_pte_page(). > >

Re: [PATCH] ppp: remove the PPPIOCDETACH ioctl

On Tue, May 22, 2018 at 08:59:52PM -0700, Eric Biggers wrote: > From: Eric Biggers > > The PPPIOCDETACH ioctl effectively tries to "close" the given ppp file > before f_count has reached 0, which is fundamentally a bad idea. It > does check 'f_count < 2', which excludes

Re: [PATCH] ppp: remove the PPPIOCDETACH ioctl

On Tue, May 22, 2018 at 08:59:52PM -0700, Eric Biggers wrote: > From: Eric Biggers > > The PPPIOCDETACH ioctl effectively tries to "close" the given ppp file > before f_count has reached 0, which is fundamentally a bad idea. It > does check 'f_count < 2', which excludes concurrent operations on

Re: [alsa-devel] [RFC/RFT PATCH] ASoC: topology: Improve backwards compatibility with v4 topology files

On Wed, 23 May 2018 15:42:59 +0200, Pierre-Louis Bossart wrote: > > On 5/23/18 3:24 AM, Mark Brown wrote: > > On Tue, May 22, 2018 at 02:59:35PM -0500, Pierre-Louis Bossart wrote: > > > >> I am also not convinced by the notion that maintaining topology files is > >> only a userspace/distro issue.

Re: [alsa-devel] [RFC/RFT PATCH] ASoC: topology: Improve backwards compatibility with v4 topology files

On Wed, 23 May 2018 15:42:59 +0200, Pierre-Louis Bossart wrote: > > On 5/23/18 3:24 AM, Mark Brown wrote: > > On Tue, May 22, 2018 at 02:59:35PM -0500, Pierre-Louis Bossart wrote: > > > >> I am also not convinced by the notion that maintaining topology files is > >> only a userspace/distro issue.

Re: [RFC/RFT PATCH] ASoC: topology: Improve backwards compatibility with v4 topology files

On Wed, May 23, 2018 at 03:54:54PM +0200, Takashi Iwai wrote: > And I'm wondering whether we should move these definitions to uapi > headers. Yes, we should. signature.asc Description: PGP signature

Re: [RFC/RFT PATCH] ASoC: topology: Improve backwards compatibility with v4 topology files

On Wed, May 23, 2018 at 03:54:54PM +0200, Takashi Iwai wrote: > And I'm wondering whether we should move these definitions to uapi > headers. Yes, we should. signature.asc Description: PGP signature

Re: [PATCH] ARM: DTS: imx53: Add support for imx53 HSC/DDC boards from K+P

Hi Lukasz, On Sat, May 19, 2018 at 9:02 AM, Lukasz Majewski wrote: > After removing imx53-kp-ddc and imx53-kp-common iomux subnodes I do see > following errors in the dmesg (v4.17-rc5): > > imx53-pinctrl 53fa8000.iomuxc: function 'iomuxc' not supported > imx53-pinctrl

Re: [PATCH] ARM: DTS: imx53: Add support for imx53 HSC/DDC boards from K+P

Hi Lukasz, On Sat, May 19, 2018 at 9:02 AM, Lukasz Majewski wrote: > After removing imx53-kp-ddc and imx53-kp-common iomux subnodes I do see > following errors in the dmesg (v4.17-rc5): > > imx53-pinctrl 53fa8000.iomuxc: function 'iomuxc' not supported > imx53-pinctrl 53fa8000.iomuxc: invalid

Re: [PATCH] kernel: sys: fix potential Spectre v1

On Wed, May 23, 2018 at 2:08 AM, Peter Zijlstra wrote: > > Sorry for being late to the party.. > > On Wed, May 23, 2018 at 12:03:57AM -0500, Gustavo A. R. Silva wrote: > >> +#define validate_index_nospec(index, size)\ >> +({

Re: [PATCH] kernel: sys: fix potential Spectre v1

On Wed, May 23, 2018 at 2:08 AM, Peter Zijlstra wrote: > > Sorry for being late to the party.. > > On Wed, May 23, 2018 at 12:03:57AM -0500, Gustavo A. R. Silva wrote: > >> +#define validate_index_nospec(index, size)\ >> +({

Re: [RFC/RFT PATCH] ASoC: topology: Improve backwards compatibility with v4 topology files

On Tue, 22 May 2018 18:58:42 +0200, Guenter Roeck wrote: > > +struct skl_dfw_v4_module_caps { > + u32 set_params:2; > + u32 rsvd:30; > + u32 param_id; > + u32 caps_size; > + u32 caps[HDA_SST_CFG_MAX]; > +}; Missing __packed attribute? And I'm wondering whether we should move

Re: [RFC/RFT PATCH] ASoC: topology: Improve backwards compatibility with v4 topology files

On Tue, 22 May 2018 18:58:42 +0200, Guenter Roeck wrote: > > +struct skl_dfw_v4_module_caps { > + u32 set_params:2; > + u32 rsvd:30; > + u32 param_id; > + u32 caps_size; > + u32 caps[HDA_SST_CFG_MAX]; > +}; Missing __packed attribute? And I'm wondering whether we should move

Re: [PATCH v2] PCI: qcom: add runtime pm support to pcie_port

Hi Srini, On 05/23/2018 01:44 PM, Srinivas Kandagatla wrote: > This patch is required when the pcie controller sits on a bus with > its own power domain and clocks which are controlled via a bus driver > like simple pm bus. As these bus driver have runtime pm enabled, it makes > sense to update

Re: [PATCH v11 0/2] Kryo CPU scaling driver

On 23/05/18 13:38, Ilia Lin wrote: > [v11] > * Addressed comment from Russel about device_node reference > * Addressed comment from Sudeep about the late_initcall > * Transformed init into probe to take care of deferals > > [v10] > * Split the series into domains > * Addressed comments

Re: [PATCH v2] PCI: qcom: add runtime pm support to pcie_port

Hi Srini, On 05/23/2018 01:44 PM, Srinivas Kandagatla wrote: > This patch is required when the pcie controller sits on a bus with > its own power domain and clocks which are controlled via a bus driver > like simple pm bus. As these bus driver have runtime pm enabled, it makes > sense to update

Re: [PATCH v11 0/2] Kryo CPU scaling driver

On 23/05/18 13:38, Ilia Lin wrote: > [v11] > * Addressed comment from Russel about device_node reference > * Addressed comment from Sudeep about the late_initcall > * Transformed init into probe to take care of deferals > > [v10] > * Split the series into domains > * Addressed comments

Re: [PATCH v11 1/8] soc: qcom: Separate kryo l2 accessors from PMU driver

On 23/05/18 13:52, Ilia Lin wrote: > The driver provides kernel level API for other drivers > to access the MSM8996 L2 cache registers. > Separating the L2 access code from the PMU driver and > making it public to allow other drivers use it. > The accesses must be separated with a single

Re: [PATCH v11 1/8] soc: qcom: Separate kryo l2 accessors from PMU driver

On 23/05/18 13:52, Ilia Lin wrote: > The driver provides kernel level API for other drivers > to access the MSM8996 L2 cache registers. > Separating the L2 access code from the PMU driver and > making it public to allow other drivers use it. > The accesses must be separated with a single

[PATCH v3 2/2] MIPS: memset.S: Add comments to fault fixup handlers

It is not immediately obvious what the expected inputs to these fault handlers is and how they calculate the number of unset bytes. Having stared deeply at this in order to fix some corner cases, add some comments to assist those who follow. Signed-off-by: Matt Redfearn

[PATCH v3 2/2] MIPS: memset.S: Add comments to fault fixup handlers

It is not immediately obvious what the expected inputs to these fault handlers is and how they calculate the number of unset bytes. Having stared deeply at this in order to fix some corner cases, add some comments to assist those who follow. Signed-off-by: Matt Redfearn --- Changes in v3: -

Re: [PATCH v1] MIPS: PCI: Use dev_printk() when possible

On Wed, May 23, 2018 at 09:14:48AM +0100, James Hogan wrote: > On Tue, May 22, 2018 at 08:11:42AM -0500, Bjorn Helgaas wrote: > > From: Bjorn Helgaas > > > > Use the pci_info() and pci_err() wrappers for dev_printk() when possible. > > > > Signed-off-by: Bjorn Helgaas

Re: [PATCH v1] MIPS: PCI: Use dev_printk() when possible

On Wed, May 23, 2018 at 09:14:48AM +0100, James Hogan wrote: > On Tue, May 22, 2018 at 08:11:42AM -0500, Bjorn Helgaas wrote: > > From: Bjorn Helgaas > > > > Use the pci_info() and pci_err() wrappers for dev_printk() when possible. > > > > Signed-off-by: Bjorn Helgaas > > --- > >

RE: [PATCH] tpm: separate cmd_ready/go_idle from runtime_pm

> On Tue, May 22, 2018 at 09:27:46AM +, Winkler, Tomas wrote: > > > > > > On Wed, May 16, 2018 at 10:46:00PM +0300, Tomas Winkler wrote: > > > > New wrappers are added tpm_cmd_ready() and tpm_go_idle() > wrappers > > > > to streamline tpm_try_transmit code. TPM_TRANSMIT_UNLOCKED flag > is > >

RE: [PATCH] tpm: separate cmd_ready/go_idle from runtime_pm

> On Tue, May 22, 2018 at 09:27:46AM +, Winkler, Tomas wrote: > > > > > > On Wed, May 16, 2018 at 10:46:00PM +0300, Tomas Winkler wrote: > > > > New wrappers are added tpm_cmd_ready() and tpm_go_idle() > wrappers > > > > to streamline tpm_try_transmit code. TPM_TRANSMIT_UNLOCKED flag > is > >

Re: [PATCH 2/2] mm: do not warn on offline nodes unless the specific node is explicitly requested

On 05/23/2018 06:25 PM, Michal Hocko wrote: > when adding memory to a node that is currently offline. > > The VM_WARN_ON is just too loud without a good reason. In this > particular case we are doing > alloc_pages_node(node, GFP_KERNEL|__GFP_RETRY_MAYFAIL|__GFP_NOWARN, > order) > > so we

Re: [PATCH 2/2] mm: do not warn on offline nodes unless the specific node is explicitly requested

On 05/23/2018 06:25 PM, Michal Hocko wrote: > when adding memory to a node that is currently offline. > > The VM_WARN_ON is just too loud without a good reason. In this > particular case we are doing > alloc_pages_node(node, GFP_KERNEL|__GFP_RETRY_MAYFAIL|__GFP_NOWARN, > order) > > so we

Re: [PATCH -next] slimbus: qcom: fix potential NULL dereference in qcom_slim_prg_slew()

On 22/05/18 12:46, Wei Yongjun wrote: platform_get_resource() may fail and return NULL, so we should better check it's return value to avoid a NULL pointer dereference a bit later in the code. This is detected by Coccinelle semantic patch. @@ expression pdev, res, n, t, e, e1, e2; @@ res =

Re: [PATCH -next] slimbus: qcom: fix potential NULL dereference in qcom_slim_prg_slew()

On 22/05/18 12:46, Wei Yongjun wrote: platform_get_resource() may fail and return NULL, so we should better check it's return value to avoid a NULL pointer dereference a bit later in the code. This is detected by Coccinelle semantic patch. @@ expression pdev, res, n, t, e, e1, e2; @@ res =

Re: [alsa-devel] [RFC/RFT PATCH] ASoC: topology: Improve backwards compatibility with v4 topology files

On 5/23/18 3:24 AM, Mark Brown wrote: On Tue, May 22, 2018 at 02:59:35PM -0500, Pierre-Louis Bossart wrote: I am also not convinced by the notion that maintaining topology files is only a userspace/distro issue. This would mean some distros will have access to the required topology files,

Re: [alsa-devel] [RFC/RFT PATCH] ASoC: topology: Improve backwards compatibility with v4 topology files

On 5/23/18 3:24 AM, Mark Brown wrote: On Tue, May 22, 2018 at 02:59:35PM -0500, Pierre-Louis Bossart wrote: I am also not convinced by the notion that maintaining topology files is only a userspace/distro issue. This would mean some distros will have access to the required topology files,

[PATCH 04/13] atomics/treewide: make atomic_fetch_add_unless() optional

Several architectures these have a near-identical implementation based on atomic_read() and atomic_cmpxchg() that we can instead define in , so let's do so, using something close to the existing x86 implementation with try_cmpxchg(). Where an architecture provides its own

[PATCH 04/13] atomics/treewide: make atomic_fetch_add_unless() optional

Several architectures these have a near-identical implementation based on atomic_read() and atomic_cmpxchg() that we can instead define in , so let's do so, using something close to the existing x86 implementation with try_cmpxchg(). Where an architecture provides its own

[PATCH 00/13] atomics: API cleanups

This series contains a few cleanups of the atomic API, fixing an inconsistency between atomic_* and atomic64_*, and minimizing repetition in arch code. This is nicer for arch code, and the improved regularity will help when generating the atomic headers in future. The bulk of the patches

[PATCH 00/13] atomics: API cleanups

This series contains a few cleanups of the atomic API, fixing an inconsistency between atomic_* and atomic64_*, and minimizing repetition in arch code. This is nicer for arch code, and the improved regularity will help when generating the atomic headers in future. The bulk of the patches

[PATCH 11/13] atomics/riscv: define atomic64_fetch_add_unless()

As a step towards unifying the atomic/atomic64/atomic_long APIs, this patch converts the arch/riscv implementation of atomic64_add_unless() into an implementation of atomic64_fetch_add_unless(). A wrapper in will build atomic_add_unless() atop of this, provided it is given a preprocessor

[PATCH 11/13] atomics/riscv: define atomic64_fetch_add_unless()

As a step towards unifying the atomic/atomic64/atomic_long APIs, this patch converts the arch/riscv implementation of atomic64_add_unless() into an implementation of atomic64_fetch_add_unless(). A wrapper in will build atomic_add_unless() atop of this, provided it is given a preprocessor

[PATCH 07/13] atomics/alpha: define atomic64_fetch_add_unless()

As a step towards unifying the atomic/atomic64/atomic_long APIs, this patch converts the arch/alpha implementation of atomic64_add_unless() into an implementation of atomic64_fetch_add_unless(). A wrapper in will build atomic_add_unless() atop of this, provided it is given a preprocessor

[PATCH 07/13] atomics/alpha: define atomic64_fetch_add_unless()

As a step towards unifying the atomic/atomic64/atomic_long APIs, this patch converts the arch/alpha implementation of atomic64_add_unless() into an implementation of atomic64_fetch_add_unless(). A wrapper in will build atomic_add_unless() atop of this, provided it is given a preprocessor

[PATCH 09/13] atomics/arm: define atomic64_fetch_add_unless()

As a step towards unifying the atomic/atomic64/atomic_long APIs, this patch converts the arch/arm implementation of atomic64_add_unless() into an implementation of atomic64_fetch_add_unless(). A wrapper in will build atomic_add_unless() atop of this, provided it is given a preprocessor

[PATCH v3 1/2] MIPS: memset.S: Fix byte_fixup for MIPSr6

The __clear_user function is defined to return the number of bytes that could not be cleared. From the underlying memset / bzero implementation this means setting register a2 to that number on return. Currently if a page fault is triggered within the MIPSr6 version of setting of initial unaligned

[PATCH 09/13] atomics/arm: define atomic64_fetch_add_unless()

As a step towards unifying the atomic/atomic64/atomic_long APIs, this patch converts the arch/arm implementation of atomic64_add_unless() into an implementation of atomic64_fetch_add_unless(). A wrapper in will build atomic_add_unless() atop of this, provided it is given a preprocessor

[PATCH v3 1/2] MIPS: memset.S: Fix byte_fixup for MIPSr6

The __clear_user function is defined to return the number of bytes that could not be cleared. From the underlying memset / bzero implementation this means setting register a2 to that number on return. Currently if a page fault is triggered within the MIPSr6 version of setting of initial unaligned

[PATCH 12/13] atomics/treewide: make atomic64_fetch_add_unless() optional

Architectures with atomic64_fetch_add_unless provide a preprocessor symbol if they do so, and all other architectures have trivial C implementations of atomic64_add_unless() which are near-identical. Let's unify the trivial definitions of atomic64_fetch_add_unless() in , so that we always have

Re: [PATCH 6/6] Drop flex_arrays

On Tue, 22 May 2018 21:18:21 -0400 Kent Overstreet wrote: > All existing users have been converted to generic radix trees > > Signed-off-by: Kent Overstreet > --- > Documentation/core-api/flexible-arrays.rst | 130 --- >

[PATCH 12/13] atomics/treewide: make atomic64_fetch_add_unless() optional

Architectures with atomic64_fetch_add_unless provide a preprocessor symbol if they do so, and all other architectures have trivial C implementations of atomic64_add_unless() which are near-identical. Let's unify the trivial definitions of atomic64_fetch_add_unless() in , so that we always have

Re: [PATCH 6/6] Drop flex_arrays

On Tue, 22 May 2018 21:18:21 -0400 Kent Overstreet wrote: > All existing users have been converted to generic radix trees > > Signed-off-by: Kent Overstreet > --- > Documentation/core-api/flexible-arrays.rst | 130 --- > Documentation/flexible-arrays.txt | 123 --- >

[PATCH 06/13] atomics/generic: define atomic64_fetch_add_unless()

As a step towards unifying the atomic/atomic64/atomic_long APIs, this patch converts the generic implementation of atomic64_add_unless() into a generic implementation of atomic64_fetch_add_unless(). A wrapper in will build atomic_add_unless() atop of this, provided it is given a preprocessor

[PATCH 06/13] atomics/generic: define atomic64_fetch_add_unless()

As a step towards unifying the atomic/atomic64/atomic_long APIs, this patch converts the generic implementation of atomic64_add_unless() into a generic implementation of atomic64_fetch_add_unless(). A wrapper in will build atomic_add_unless() atop of this, provided it is given a preprocessor

[PATCH 01/13] atomics/treewide: s/__atomic_add_unless/atomic_fetch_add_unless/

While __atomic_add_unless was originally intended as a building-block for atomic_add_unless, it's now used in a number of places around the kernel. It's the only common atomic operation named __atomic*(), rather than atomic_*(), and for consistency it would be better named

[PATCH 01/13] atomics/treewide: s/__atomic_add_unless/atomic_fetch_add_unless/

While __atomic_add_unless was originally intended as a building-block for atomic_add_unless, it's now used in a number of places around the kernel. It's the only common atomic operation named __atomic*(), rather than atomic_*(), and for consistency it would be better named

[PATCH 08/13] atomics/arc: define atomic64_fetch_add_unless()

As a step towards unifying the atomic/atomic64/atomic_long APIs, this patch converts the arch/arc implementation of atomic64_add_unless() into an implementation of atomic64_fetch_add_unless(). A wrapper in will build atomic_add_unless() atop of this, provided it is given a preprocessor

[PATCH 08/13] atomics/arc: define atomic64_fetch_add_unless()

As a step towards unifying the atomic/atomic64/atomic_long APIs, this patch converts the arch/arc implementation of atomic64_add_unless() into an implementation of atomic64_fetch_add_unless(). A wrapper in will build atomic_add_unless() atop of this, provided it is given a preprocessor

Re: [PATCH v2] packet: track ring entry use using a shadow ring to prevent RX ring overrun

On Wed, May 23, 2018 at 7:54 AM, Jon Rosen (jrosen) wrote: >> > For the ring, there is no requirement to allocate exactly the amount >> > specified by the user request. Safer than relying on shared memory >> > and simpler than the extra allocation in this patch would be to

Re: [PATCH v2] packet: track ring entry use using a shadow ring to prevent RX ring overrun

On Wed, May 23, 2018 at 7:54 AM, Jon Rosen (jrosen) wrote: >> > For the ring, there is no requirement to allocate exactly the amount >> > specified by the user request. Safer than relying on shared memory >> > and simpler than the extra allocation in this patch would be to allocate >> > extra

[PATCH 10/13] atomics/powerpc: define atomic64_fetch_add_unless()

As a step towards unifying the atomic/atomic64/atomic_long APIs, this patch converts the arch/powerpc implementation of atomic64_add_unless() into an implementation of atomic64_fetch_add_unless(). A wrapper in will build atomic_add_unless() atop of this, provided it is given a preprocessor

[PATCH 10/13] atomics/powerpc: define atomic64_fetch_add_unless()

As a step towards unifying the atomic/atomic64/atomic_long APIs, this patch converts the arch/powerpc implementation of atomic64_add_unless() into an implementation of atomic64_fetch_add_unless(). A wrapper in will build atomic_add_unless() atop of this, provided it is given a preprocessor

Gruß

Gruß In einer kurzen Einführung bin ich Rechtsanwalt Hengeler Mueller aus Portugal, aber jetzt lebe ich in London, ich habe dir eine E-Mail über deine verstorbene Verwandte geschickt, aber ich habe keine Antwort von dir erhalten, verstorben ist ein Bürger deines Landes mit derselbe Nachname mit

Gruß

Gruß In einer kurzen Einführung bin ich Rechtsanwalt Hengeler Mueller aus Portugal, aber jetzt lebe ich in London, ich habe dir eine E-Mail über deine verstorbene Verwandte geschickt, aber ich habe keine Antwort von dir erhalten, verstorben ist ein Bürger deines Landes mit derselbe Nachname mit

Re: [PATCH v2] PCI: qcom: add runtime pm support to pcie_port

On 23-05-18, 11:44, Srinivas Kandagatla wrote: > This patch is required when the pcie controller sits on a bus with > its own power domain and clocks which are controlled via a bus driver > like simple pm bus. As these bus driver have runtime pm enabled, it makes > sense to update the usage

Re: [PATCH v2] PCI: qcom: add runtime pm support to pcie_port

On 23-05-18, 11:44, Srinivas Kandagatla wrote: > This patch is required when the pcie controller sits on a bus with > its own power domain and clocks which are controlled via a bus driver > like simple pm bus. As these bus driver have runtime pm enabled, it makes > sense to update the usage

[PATCH 13/13] atomics/treewide: make test ops optional

Some of the atomics return the result of a test applied after the atomic operation, and almost all architectures implement these as trivial wrappers around the underlying atomic. Specifically: * _inc_and_test(v) is (_inc_return(v) == 0) * _dec_and_test(v) is (_dec_return(v) == 0) *

[PATCH 13/13] atomics/treewide: make test ops optional

Some of the atomics return the result of a test applied after the atomic operation, and almost all architectures implement these as trivial wrappers around the underlying atomic. Specifically: * _inc_and_test(v) is (_inc_return(v) == 0) * _dec_and_test(v) is (_dec_return(v) == 0) *

[PATCH 05/13] atomics: prepare for atomic64_fetch_add_unless()

Currently architecture must implement atomic_fetch_add_unless(), with common code providing atomic_add_unless(). Architectures must also implement atmic64_add_unless() directly, with no corresponding atomic64_fetch_add_unless(). This divergenece is unfortunate, and means that the APIs for

[PATCH 05/13] atomics: prepare for atomic64_fetch_add_unless()

Currently architecture must implement atomic_fetch_add_unless(), with common code providing atomic_add_unless(). Architectures must also implement atmic64_add_unless() directly, with no corresponding atomic64_fetch_add_unless(). This divergenece is unfortunate, and means that the APIs for

[PATCH 03/13] atomics/treewide: make atomic64_inc_not_zero() optional

We define a trivial fallback for atomic_inc_not_zero(), but don't do the same for atmic64_inc_not_zero(), leading most architectures to define the same boilerplate. Let's add a fallback in , and remove the redundant implementations. Note that atomic64_add_unless() is always defined in , and

[PATCH 03/13] atomics/treewide: make atomic64_inc_not_zero() optional

We define a trivial fallback for atomic_inc_not_zero(), but don't do the same for atmic64_inc_not_zero(), leading most architectures to define the same boilerplate. Let's add a fallback in , and remove the redundant implementations. Note that atomic64_add_unless() is always defined in , and

[PATCH 02/13] atomics/treewide: remove redundant atomic_inc_not_zero() definitions

vWhen atomic_inc_not_zero(v) isn't defined, will define it as falling back to atomic_add_unless((v), 1, 0), so there's no need for arch code to do so. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland Cc: Boqun Feng

[PATCH 02/13] atomics/treewide: remove redundant atomic_inc_not_zero() definitions

vWhen atomic_inc_not_zero(v) isn't defined, will define it as falling back to atomic_add_unless((v), 1, 0), so there's no need for arch code to do so. There should be no functional change as a result of this patch. Signed-off-by: Mark Rutland Cc: Boqun Feng Cc: Peter Zijlstra Cc: Will Deacon

Re: [PATCH v4 0/2] vfio/mdev: Device namespace protection

On Wed, 23 May 2018 14:29:28 +0200 Halil Pasic wrote: > On 05/23/2018 10:56 AM, Cornelia Huck wrote: > > On Tue, 22 May 2018 12:38:29 -0600 > > Alex Williamson wrote: > > > >> On Tue, 22 May 2018 19:17:07 +0200 > >> Halil Pasic

Re: [PATCH v1] dma: imx-sdma: add virt-dma support

On 23-05-18, 12:56, s.ha...@pengutronix.de wrote: > Well, it's somewhat related to virtual dma support, but that's not my > point. My point is that this patch is quite big and thus hard to review. > If we find ways to make it smaller and to split it up in multiple > patches then we should do so,

<    8   9   10   11   12   13   14   15   16   17   >