[PATCH 02/12] drbd: convert to bioset_init()/mempool_init()

Signed-off-by: Kent Overstreet --- drivers/block/drbd/drbd_bitmap.c | 4 +- drivers/block/drbd/drbd_int.h | 10 ++--- drivers/block/drbd/drbd_main.c | 71 +++--- drivers/block/drbd/drbd_receiver.c | 6 +-- drivers/block/drbd/drbd_req.c | 4 +-

[PATCH 10/12] btrfs: convert to bioset_init()/mempool_init()

Signed-off-by: Kent Overstreet --- fs/btrfs/extent_io.c | 25 +++-- 1 file changed, 11 insertions(+), 14 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index e99b329002..56d32bb462 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -26,7

[PATCH 00/13] convert block layer to bioset_init()/mempool_init()

Jens - this series does the rest of the conversions that Christoph wanted, and drops bioset_create(). Only lightly tested, but the changes are pretty mechanical. Based on your for-next tree. It's also in the for-jens branch at https://evilpiepirate.org/git/bcachefs.git Kent Overstreet (12):

[PATCH 00/13] convert block layer to bioset_init()/mempool_init()

Jens - this series does the rest of the conversions that Christoph wanted, and drops bioset_create(). Only lightly tested, but the changes are pretty mechanical. Based on your for-next tree. It's also in the for-jens branch at https://evilpiepirate.org/git/bcachefs.git Kent Overstreet (12):

Re: [PATCH v3 1/2] soc: imx: gpcv2: Do not pass static memory as platform data

On Sat, May 19, 2018 at 11:26 PM, Shawn Guo wrote: > On Sat, May 19, 2018 at 03:35:55PM -0700, Andrey Smirnov wrote: >> On Tue, Apr 10, 2018 at 11:32 AM, Andrey Smirnov >> wrote: >> > Platform device core assumes the ownership of dev.platform_data

Re: [PATCH v3 1/2] soc: imx: gpcv2: Do not pass static memory as platform data

On Sat, May 19, 2018 at 11:26 PM, Shawn Guo wrote: > On Sat, May 19, 2018 at 03:35:55PM -0700, Andrey Smirnov wrote: >> On Tue, Apr 10, 2018 at 11:32 AM, Andrey Smirnov >> wrote: >> > Platform device core assumes the ownership of dev.platform_data as >> > well as that it is dynamically allocated

Re: [PATCH v2] net: qcom/emac: Allocate buffers from local node

From: Hemanth Puranik Date: Fri, 18 May 2018 08:59:29 +0530 > Currently we use non-NUMA aware allocation for TPD and RRD buffers, > this patch modifies to use NUMA friendly allocation. > > Signed-off-by: Hemanth Puranik > --- > Change since v1:

Re: [PATCH v2] net: qcom/emac: Allocate buffers from local node

From: Hemanth Puranik Date: Fri, 18 May 2018 08:59:29 +0530 > Currently we use non-NUMA aware allocation for TPD and RRD buffers, > this patch modifies to use NUMA friendly allocation. > > Signed-off-by: Hemanth Puranik > --- > Change since v1: > - Addressed comments related to ordering

Re: [PATCH 00/10] Misc block layer patches for bcachefs

On Sun, 2018-05-20 at 18:17 -0400, Kent Overstreet wrote: > On Fri, May 18, 2018 at 03:12:27PM +, Bart Van Assche wrote: > > On Fri, 2018-05-18 at 05:06 -0400, Kent Overstreet wrote: > > > On Thu, May 17, 2018 at 08:54:57PM +, Bart Van Assche wrote: > > > > With Jens' latest for-next

Re: [PATCH 00/10] Misc block layer patches for bcachefs

On Sun, 2018-05-20 at 18:17 -0400, Kent Overstreet wrote: > On Fri, May 18, 2018 at 03:12:27PM +, Bart Van Assche wrote: > > On Fri, 2018-05-18 at 05:06 -0400, Kent Overstreet wrote: > > > On Thu, May 17, 2018 at 08:54:57PM +, Bart Van Assche wrote: > > > > With Jens' latest for-next

Re: [PATCH 00/10] Misc block layer patches for bcachefs

On Fri, May 18, 2018 at 03:12:27PM +, Bart Van Assche wrote: > On Fri, 2018-05-18 at 05:06 -0400, Kent Overstreet wrote: > > On Thu, May 17, 2018 at 08:54:57PM +, Bart Van Assche wrote: > > > With Jens' latest for-next branch I hit the kernel warning shown below. > > > Can > > > you have

Re: [PATCH 00/10] Misc block layer patches for bcachefs

On Fri, May 18, 2018 at 03:12:27PM +, Bart Van Assche wrote: > On Fri, 2018-05-18 at 05:06 -0400, Kent Overstreet wrote: > > On Thu, May 17, 2018 at 08:54:57PM +, Bart Van Assche wrote: > > > With Jens' latest for-next branch I hit the kernel warning shown below. > > > Can > > > you have

Proposal

-- Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey

Proposal

-- Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey

Re: [PATCH 13/14] net: sched: use unique idr insert function in unlocked actions

On Mon, May 21, 2018 at 12:33 AM, Marcelo Ricardo Leitner wrote: > On Mon, May 21, 2018 at 12:13:06AM +0300, Or Gerlitz wrote: >> On Sun, May 20, 2018 at 1:20 AM, Marcelo Ricardo Leitner >> wrote: >> > On Mon, May 14, 2018 at 05:27:14PM

Re: [PATCH 13/14] net: sched: use unique idr insert function in unlocked actions

On Mon, May 21, 2018 at 12:33 AM, Marcelo Ricardo Leitner wrote: > On Mon, May 21, 2018 at 12:13:06AM +0300, Or Gerlitz wrote: >> On Sun, May 20, 2018 at 1:20 AM, Marcelo Ricardo Leitner >> wrote: >> > On Mon, May 14, 2018 at 05:27:14PM +0300, Vlad Buslov wrote: >> >> Substitute calls to action

Re: [PATCH 13/14] net: sched: use unique idr insert function in unlocked actions

On Mon, May 21, 2018 at 12:13:06AM +0300, Or Gerlitz wrote: > On Sun, May 20, 2018 at 1:20 AM, Marcelo Ricardo Leitner > wrote: > > On Mon, May 14, 2018 at 05:27:14PM +0300, Vlad Buslov wrote: > >> Substitute calls to action insert function with calls to action insert >

Re: [PATCH 13/14] net: sched: use unique idr insert function in unlocked actions

On Mon, May 21, 2018 at 12:13:06AM +0300, Or Gerlitz wrote: > On Sun, May 20, 2018 at 1:20 AM, Marcelo Ricardo Leitner > wrote: > > On Mon, May 14, 2018 at 05:27:14PM +0300, Vlad Buslov wrote: > >> Substitute calls to action insert function with calls to action insert > >> unique function that

Re: [PATCH v6 00/12] KVM: arm/arm64: Allow multiple GICv3 redistributor regions

Hi Marc, On 05/20/2018 03:43 PM, Marc Zyngier wrote: > Hi Eric, > > On Mon, 30 Apr 2018 13:48:26 +0200 > Eric Auger wrote: > >> At the moment the KVM VGICv3 only supports a single redistributor >> region (whose base address is set through the GICv3 kvm device >>

Re: [PATCH v6 00/12] KVM: arm/arm64: Allow multiple GICv3 redistributor regions

Hi Marc, On 05/20/2018 03:43 PM, Marc Zyngier wrote: > Hi Eric, > > On Mon, 30 Apr 2018 13:48:26 +0200 > Eric Auger wrote: > >> At the moment the KVM VGICv3 only supports a single redistributor >> region (whose base address is set through the GICv3 kvm device >>

[PATCH v7 01/13] KVM: arm/arm64: Set dist->spis to NULL after kfree

in case kvm_vgic_map_resources() fails, typically if the vgic distributor is not defined, __kvm_vgic_destroy will be called several times. Indeed kvm_vgic_map_resources() is called on first vcpu run. As a result dist->spis is freeed more than once and on the second time it causes a "kernel BUG at

[PATCH v7 03/13] KVM: arm/arm64: Replace the single rdist region by a list

At the moment KVM supports a single rdist region. We want to support several separate rdist regions so let's introduce a list of them. This patch currently only cares about a single entry in this list as the functionality to register several redist regions is not yet there. So this only translates

[PATCH v7 05/13] KVM: arm/arm64: Revisit Redistributor TYPER last bit computation

The TYPER of an redistributor reflects whether the rdist is the last one of the redistributor region. Let's compare the TYPER GPA against the address of the last occupied slot within the redistributor region. Signed-off-by: Eric Auger Reviewed-by: Christoffer Dall

[PATCH v7 05/13] KVM: arm/arm64: Revisit Redistributor TYPER last bit computation

The TYPER of an redistributor reflects whether the rdist is the last one of the redistributor region. Let's compare the TYPER GPA against the address of the last occupied slot within the redistributor region. Signed-off-by: Eric Auger Reviewed-by: Christoffer Dall --- v3 -> v4: - added

[PATCH v7 01/13] KVM: arm/arm64: Set dist->spis to NULL after kfree

in case kvm_vgic_map_resources() fails, typically if the vgic distributor is not defined, __kvm_vgic_destroy will be called several times. Indeed kvm_vgic_map_resources() is called on first vcpu run. As a result dist->spis is freeed more than once and on the second time it causes a "kernel BUG at

[PATCH v7 03/13] KVM: arm/arm64: Replace the single rdist region by a list

At the moment KVM supports a single rdist region. We want to support several separate rdist regions so let's introduce a list of them. This patch currently only cares about a single entry in this list as the functionality to register several redist regions is not yet there. So this only translates

[PATCH v7 08/13] KVM: arm/arm64: Remove kvm_vgic_vcpu_early_init

kvm_vgic_vcpu_early_init gets called after kvm_vgic_cpu_init which is confusing. The call path is as follows: kvm_vm_ioctl_create_vcpu |_ kvm_arch_cpu_create |_ kvm_vcpu_init |_ kvm_vgic_vcpu_init |_ kvm_arch_vcpu_postcreate |_ kvm_vgic_vcpu_early_init Static initialization currently

[PATCH v7 08/13] KVM: arm/arm64: Remove kvm_vgic_vcpu_early_init

kvm_vgic_vcpu_early_init gets called after kvm_vgic_cpu_init which is confusing. The call path is as follows: kvm_vm_ioctl_create_vcpu |_ kvm_arch_cpu_create |_ kvm_vcpu_init |_ kvm_vgic_vcpu_init |_ kvm_arch_vcpu_postcreate |_ kvm_vgic_vcpu_early_init Static initialization currently

[PATCH v7 04/13] KVM: arm/arm64: Helper to locate free rdist index

We introduce vgic_v3_rdist_free_slot to help identifying where we can place a new 2x64KB redistributor. Signed-off-by: Eric Auger Reviewed-by: Christoffer Dall --- v3 -> v4: - add details to vgic_v3_rdist_free_slot kernel doc comment - Added

[PATCH v7 04/13] KVM: arm/arm64: Helper to locate free rdist index

We introduce vgic_v3_rdist_free_slot to help identifying where we can place a new 2x64KB redistributor. Signed-off-by: Eric Auger Reviewed-by: Christoffer Dall --- v3 -> v4: - add details to vgic_v3_rdist_free_slot kernel doc comment - Added Christoffer's R-b ---

[PATCH v7 09/13] KVM: arm/arm64: Check vcpu redist base before registering an iodev

As we are going to register several redist regions, vgic_register_all_redist_iodevs() may be called several times. We need to register a redist_iodev for a given vcpu only once. So let's check if the base address has already been set. Initialize this latter in kvm_vgic_vcpu_init(). Signed-off-by:

[PATCH v7 09/13] KVM: arm/arm64: Check vcpu redist base before registering an iodev

As we are going to register several redist regions, vgic_register_all_redist_iodevs() may be called several times. We need to register a redist_iodev for a given vcpu only once. So let's check if the base address has already been set. Initialize this latter in kvm_vgic_vcpu_init(). Signed-off-by:

[PATCH v7 11/13] KVM: arm/arm64: Add KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION

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 Acked-by: Christoffer Dall --- v3 -> v4: -

[PATCH v7 12/13] KVM: arm/arm64: Implement KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION

Now all the internals are ready to handle multiple redistributor regions, let's allow the userspace to register them. Signed-off-by: Eric Auger Reviewed-by: Christoffer Dall --- v5 -> v6: - added Christoffer's R-b v4 -> v5: - s/uint_t/u - fix

[PATCH v7 07/13] KVM: arm/arm64: Helper to register a new redistributor region

We introduce a new helper that creates and inserts a new redistributor region into the rdist region list. This helper both handles the case where the redistributor region size is known at registration time and the legacy case where it is not (eventually depending on the number of online vcpus).

[PATCH v7 12/13] KVM: arm/arm64: Implement KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION

Now all the internals are ready to handle multiple redistributor regions, let's allow the userspace to register them. Signed-off-by: Eric Auger Reviewed-by: Christoffer Dall --- v5 -> v6: - added Christoffer's R-b v4 -> v5: - s/uint_t/u - fix KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION read - fix

[PATCH v7 07/13] KVM: arm/arm64: Helper to register a new redistributor region

We introduce a new helper that creates and inserts a new redistributor region into the rdist region list. This helper both handles the case where the redistributor region size is known at registration time and the legacy case where it is not (eventually depending on the number of online vcpus).

[PATCH v7 11/13] KVM: arm/arm64: Add KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION

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 Acked-by: Christoffer Dall --- v3 -> v4: - keep previous indentation for existing attributes -

[PATCH v7 10/13] KVM: arm/arm64: Check all vcpu redistributors are set on map_resources

On vcpu first run, we eventually know the actual number of vcpus. This is a synchronization point to check all redistributors were assigned. On kvm_vgic_map_resources() we check both dist and redist were set, eventually check potential base address inconsistencies. Signed-off-by: Eric Auger

[PATCH v7 13/13] KVM: arm/arm64: Bump VGIC_V3_MAX_CPUS to 512

Let's raise the number of supported vcpus along with vgic v3 now that HW is looming with more physical CPUs. Signed-off-by: Eric Auger Acked-by: Christoffer Dall --- v4 -> v5: - addded Christoffer's A-b --- include/kvm/arm_vgic.h | 2 +- 1

[PATCH v7 10/13] KVM: arm/arm64: Check all vcpu redistributors are set on map_resources

On vcpu first run, we eventually know the actual number of vcpus. This is a synchronization point to check all redistributors were assigned. On kvm_vgic_map_resources() we check both dist and redist were set, eventually check potential base address inconsistencies. Signed-off-by: Eric Auger

[PATCH v7 13/13] KVM: arm/arm64: Bump VGIC_V3_MAX_CPUS to 512

Let's raise the number of supported vcpus along with vgic v3 now that HW is looming with more physical CPUs. Signed-off-by: Eric Auger Acked-by: Christoffer Dall --- v4 -> v5: - addded Christoffer's A-b --- include/kvm/arm_vgic.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH v7 06/13] KVM: arm/arm64: Adapt vgic_v3_check_base to multiple rdist regions

vgic_v3_check_base() currently only handles the case of a unique legacy redistributor region whose size is not explicitly set but inferred, instead, from the number of online vcpus. We adapt it to handle the case of multiple redistributor regions with explicitly defined size. We rely on two new

[PATCH v7 06/13] KVM: arm/arm64: Adapt vgic_v3_check_base to multiple rdist regions

vgic_v3_check_base() currently only handles the case of a unique legacy redistributor region whose size is not explicitly set but inferred, instead, from the number of online vcpus. We adapt it to handle the case of multiple redistributor regions with explicitly defined size. We rely on two new

[PATCH v7 00/13] KVM: arm/arm64: Allow multiple GICv3 redistributor regions

At the moment the KVM VGICv3 only supports a single redistributor region (whose base address is set through the GICv3 kvm device KVM_DEV_ARM_VGIC_GRP_ADDR/KVM_VGIC_V3_ADDR_TYPE_REDIST). There, all the redistributors are laid out contiguously. The size of this single redistributor region is not set

[PATCH v7 02/13] KVM: arm/arm64: Document KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION

We introduce a new KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION attribute in KVM_DEV_ARM_VGIC_GRP_ADDR group. It allows userspace to provide the base address and size of a redistributor region Compared to KVM_VGIC_V3_ADDR_TYPE_REDIST, this new attribute allows to declare several separate redistributor

[PATCH v7 00/13] KVM: arm/arm64: Allow multiple GICv3 redistributor regions

At the moment the KVM VGICv3 only supports a single redistributor region (whose base address is set through the GICv3 kvm device KVM_DEV_ARM_VGIC_GRP_ADDR/KVM_VGIC_V3_ADDR_TYPE_REDIST). There, all the redistributors are laid out contiguously. The size of this single redistributor region is not set

[PATCH v7 02/13] KVM: arm/arm64: Document KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION

We introduce a new KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION attribute in KVM_DEV_ARM_VGIC_GRP_ADDR group. It allows userspace to provide the base address and size of a redistributor region Compared to KVM_VGIC_V3_ADDR_TYPE_REDIST, this new attribute allows to declare several separate redistributor

Re: [PATCH 13/14] net: sched: use unique idr insert function in unlocked actions

On Sun, May 20, 2018 at 1:20 AM, Marcelo Ricardo Leitner wrote: > On Mon, May 14, 2018 at 05:27:14PM +0300, Vlad Buslov wrote: >> Substitute calls to action insert function with calls to action insert >> unique function that warns if insertion overwrites index in idr. >

Re: [PATCH 13/14] net: sched: use unique idr insert function in unlocked actions

On Sun, May 20, 2018 at 1:20 AM, Marcelo Ricardo Leitner wrote: > On Mon, May 14, 2018 at 05:27:14PM +0300, Vlad Buslov wrote: >> Substitute calls to action insert function with calls to action insert >> unique function that warns if insertion overwrites index in idr. > > I know this patch may be

Re: PROBLEM: mce: [Hardware Error] from dmesg -l emerg

On Sun, May 20, 2018 at 05:27:32PM +0530, Jeffrin Thalakkottoor wrote: > output for "dmesg | mcelog --ascii" command related Ok, but please do not top-post. ... > Hardware event. This is not a software error. > CPU 0 BANK 0 TSC dead > STATUS 0 MCGSTATUS 0 > line timer enabled > smpboot: CPU0:

Re: PROBLEM: mce: [Hardware Error] from dmesg -l emerg

On Sun, May 20, 2018 at 05:27:32PM +0530, Jeffrin Thalakkottoor wrote: > output for "dmesg | mcelog --ascii" command related Ok, but please do not top-post. ... > Hardware event. This is not a software error. > CPU 0 BANK 0 TSC dead > STATUS 0 MCGSTATUS 0 > line timer enabled > smpboot: CPU0:

[PATCH 1/2] rtc: brcmstb-waketimer: switch to rtc_register_device

Switch to devm_rtc_allocate_device/rtc_register_device. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-brcmstb-waketimer.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/rtc/rtc-brcmstb-waketimer.c

[PATCH 2/2] rtc: brcmstb-waketimer: add range

Let the core handle the range. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-brcmstb-waketimer.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/rtc/rtc-brcmstb-waketimer.c b/drivers/rtc/rtc-brcmstb-waketimer.c index

[PATCH 1/2] rtc: brcmstb-waketimer: switch to rtc_register_device

Switch to devm_rtc_allocate_device/rtc_register_device. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-brcmstb-waketimer.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/rtc/rtc-brcmstb-waketimer.c b/drivers/rtc/rtc-brcmstb-waketimer.c index

[PATCH 2/2] rtc: brcmstb-waketimer: add range

Let the core handle the range. Signed-off-by: Alexandre Belloni --- drivers/rtc/rtc-brcmstb-waketimer.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/rtc/rtc-brcmstb-waketimer.c b/drivers/rtc/rtc-brcmstb-waketimer.c index ba49d9bcff12..f4010a75f2be 100644

Re: [PATCH 2/6] Input: ams_delta_serio: use GPIO lookup table

Hi Janusz, On Fri, May 18, 2018 at 11:09:50PM +0200, Janusz Krzysztofik wrote: > Now as the Amstrad Delta board provides GPIO lookup tables, switch from > GPIO numbers to GPIO descriptors and use the table to locate required > GPIO pins. > > Declare static variables for storing GPIO descriptors

Re: [PATCH 2/6] Input: ams_delta_serio: use GPIO lookup table

Hi Janusz, On Fri, May 18, 2018 at 11:09:50PM +0200, Janusz Krzysztofik wrote: > Now as the Amstrad Delta board provides GPIO lookup tables, switch from > GPIO numbers to GPIO descriptors and use the table to locate required > GPIO pins. > > Declare static variables for storing GPIO descriptors

Re: [alsa-devel] [PATCH 5/6] mtd: rawnand: ams-delta: use GPIO lookup table

On Sun, May 20, 2018 at 09:27:05PM +0200, Ladislav Michl wrote: > On Sat, May 19, 2018 at 11:55:51PM +0200, Janusz Krzysztofik wrote: > > On Saturday, May 19, 2018 8:00:38 PM CEST Andy Shevchenko wrote: > > > On Sat, May 19, 2018 at 2:15 AM, Janusz Krzysztofik > > wrote: > >

Re: [alsa-devel] [PATCH 5/6] mtd: rawnand: ams-delta: use GPIO lookup table

On Sun, May 20, 2018 at 09:27:05PM +0200, Ladislav Michl wrote: > On Sat, May 19, 2018 at 11:55:51PM +0200, Janusz Krzysztofik wrote: > > On Saturday, May 19, 2018 8:00:38 PM CEST Andy Shevchenko wrote: > > > On Sat, May 19, 2018 at 2:15 AM, Janusz Krzysztofik > > wrote: > > > > On Friday, May

Re: cryptomgr_test / drbg_ctr: BUG: sleeping function called from invalid context

Am Freitag, 18. Mai 2018, 10:36:04 CEST schrieb Geert Uytterhoeven: Hi Geert, > > I tried following the code path, but couldn't find where it went wrong. > > mutex_lock(>drbg_mutex) is called from drbg_instantiate(), which is > inlined by the compiler into drbg_kcapi_seed(). > > Do you have a

Re: cryptomgr_test / drbg_ctr: BUG: sleeping function called from invalid context

Am Freitag, 18. Mai 2018, 10:36:04 CEST schrieb Geert Uytterhoeven: Hi Geert, > > I tried following the code path, but couldn't find where it went wrong. > > mutex_lock(>drbg_mutex) is called from drbg_instantiate(), which is > inlined by the compiler into drbg_kcapi_seed(). > > Do you have a

Re: [PATCH] mtd: mtdoops: optionally dump boottime

Hi Stefan, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on mtd/master] [also build test WARNING on v4.17-rc5 next-20180517] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] mtd: mtdoops: optionally dump boottime

Hi Stefan, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on mtd/master] [also build test WARNING on v4.17-rc5 next-20180517] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[GIT PULL] parisc section mismatch fixes for 4.17-rc6

Hi Linus, please pull three small section mismatch fixes for the parisc architecture from: git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.17-5 Three small section mismatch fixes, one of them was found by 0-day test infrastructure. Thanks, Helge

[GIT PULL] parisc section mismatch fixes for 4.17-rc6

Hi Linus, please pull three small section mismatch fixes for the parisc architecture from: git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.17-5 Three small section mismatch fixes, one of them was found by 0-day test infrastructure. Thanks, Helge

Re: [alsa-devel] [PATCH 5/6] mtd: rawnand: ams-delta: use GPIO lookup table

On Sat, May 19, 2018 at 11:55:51PM +0200, Janusz Krzysztofik wrote: > On Saturday, May 19, 2018 8:00:38 PM CEST Andy Shevchenko wrote: > > On Sat, May 19, 2018 at 2:15 AM, Janusz Krzysztofik > wrote: > > > On Friday, May 18, 2018 11:21:14 PM CEST Andy Shevchenko wrote: > >

Re: [alsa-devel] [PATCH 5/6] mtd: rawnand: ams-delta: use GPIO lookup table

On Sat, May 19, 2018 at 11:55:51PM +0200, Janusz Krzysztofik wrote: > On Saturday, May 19, 2018 8:00:38 PM CEST Andy Shevchenko wrote: > > On Sat, May 19, 2018 at 2:15 AM, Janusz Krzysztofik > wrote: > > > On Friday, May 18, 2018 11:21:14 PM CEST Andy Shevchenko wrote: > > >> On Sat, May 19,

Re: Tasks RCU vs Preempt RCU

On Sun, May 20, 2018 at 11:28:43AM -0400, Steven Rostedt wrote: > > [ Steve interrupts his time off ] Hope you're enjoying your vacation :) > On Sat, 19 May 2018 17:49:38 -0700 > "Paul E. McKenney" wrote: > > > I suggested to Steven that the rcu_read_lock() and

Re: Tasks RCU vs Preempt RCU

On Sun, May 20, 2018 at 11:28:43AM -0400, Steven Rostedt wrote: > > [ Steve interrupts his time off ] Hope you're enjoying your vacation :) > On Sat, 19 May 2018 17:49:38 -0700 > "Paul E. McKenney" wrote: > > > I suggested to Steven that the rcu_read_lock() and rcu_read_unlock() might > > be

Re: [GIT PULL] Btrfs fixes for 4.17-rc6

On Sun, May 20, 2018 at 8:21 AM David Sterba wrote: > They IMHO qualify for a late rc, though I did not expect that many. Especially with the tree-log.c changes being fairly big, I took a look, and I have to say that I appreciate (a) the warning in the pull request and (b) the

Re: [GIT PULL] Btrfs fixes for 4.17-rc6

On Sun, May 20, 2018 at 8:21 AM David Sterba wrote: > They IMHO qualify for a late rc, though I did not expect that many. Especially with the tree-log.c changes being fairly big, I took a look, and I have to say that I appreciate (a) the warning in the pull request and (b) the extensive log

Re: [PATCH 09/14] net: sched: don't release reference on action overwrite

On Sat 19 May 2018 at 21:52, Marcelo Ricardo Leitner wrote: > On Mon, May 14, 2018 at 05:27:10PM +0300, Vlad Buslov wrote: >> Return from action init function with reference to action taken, >> even when overwriting existing action. > > Isn't this patch necessary

Re: [PATCH 09/14] net: sched: don't release reference on action overwrite

On Sat 19 May 2018 at 21:52, Marcelo Ricardo Leitner wrote: > On Mon, May 14, 2018 at 05:27:10PM +0300, Vlad Buslov wrote: >> Return from action init function with reference to action taken, >> even when overwriting existing action. > > Isn't this patch necessary before patch 7, to not break

RE: [tip:x86/hyperv] x86/Hyper-V/hv_apic: Include asm/apic.h

> -Original Message- > From: tip tree robot > Sent: Saturday, May 19, 2018 7:46 AM > To: linux-tip-comm...@vger.kernel.org > Cc: h...@zytor.com; Michael Kelley (EOSG) > ; KY Srinivasan ; > t...@linutronix.de;

RE: [tip:x86/hyperv] x86/Hyper-V/hv_apic: Build the Hyper-V APIC conditionally

> -Original Message- > From: tip tree robot > Sent: Saturday, May 19, 2018 12:40 PM > To: linux-tip-comm...@vger.kernel.org > Cc: l...@intel.com; h...@zytor.com; mi...@kernel.org; Michael Kelley > (EOSG) ; t...@linutronix.de; KY >

RE: [tip:x86/hyperv] x86/Hyper-V/hv_apic: Include asm/apic.h

> -Original Message- > From: tip tree robot > Sent: Saturday, May 19, 2018 7:46 AM > To: linux-tip-comm...@vger.kernel.org > Cc: h...@zytor.com; Michael Kelley (EOSG) > ; KY Srinivasan ; > t...@linutronix.de; mi...@kernel.org; l...@intel.com > Subject: [tip:x86/hyperv]

RE: [tip:x86/hyperv] x86/Hyper-V/hv_apic: Build the Hyper-V APIC conditionally

> -Original Message- > From: tip tree robot > Sent: Saturday, May 19, 2018 12:40 PM > To: linux-tip-comm...@vger.kernel.org > Cc: l...@intel.com; h...@zytor.com; mi...@kernel.org; Michael Kelley > (EOSG) ; t...@linutronix.de; KY > Srinivasan > Subject: [tip:x86/hyperv]

Re: [PATCH 10/32] aio: implement IOCB_CMD_POLL

On Sun, May 20, 2018 at 08:33:39AM +0100, Al Viro wrote: > > ... get buggered on attempt to dereference a pointer fetched from freed and > > reused object. > > FWIW, how painful would it be to pull the following trick: > * insert into wait queue under ->ctx_lock > * have wakeup do

Re: [PATCH 10/32] aio: implement IOCB_CMD_POLL

On Sun, May 20, 2018 at 08:33:39AM +0100, Al Viro wrote: > > ... get buggered on attempt to dereference a pointer fetched from freed and > > reused object. > > FWIW, how painful would it be to pull the following trick: > * insert into wait queue under ->ctx_lock > * have wakeup do

Re: [PATCH 5/6] mtd: rawnand: ams-delta: use GPIO lookup table

Hello, On Sun, 20 May 2018 19:17:04 +0300, Andy Shevchenko wrote: > >> Though, I completely dislike "rdy" name of GPIO. Where is it documented? > > > > No documentation files for Amstrad Delta nor for its NAND driver > > specifically > > exist under Documentation/.

Re: [PATCH 5/6] mtd: rawnand: ams-delta: use GPIO lookup table

Hello, On Sun, 20 May 2018 19:17:04 +0300, Andy Shevchenko wrote: > >> Though, I completely dislike "rdy" name of GPIO. Where is it documented? > > > > No documentation files for Amstrad Delta nor for its NAND driver > > specifically > > exist under Documentation/. However, there exist some

[PATCH 1/2] drm/fourcc: add a 10bits fully packed variant of NV12

This pixel format is a fully packed and 10bits variant of NV12. A luma pixel would take 10bits in memory, without any filled bits between pixels in a stride. The color gamut follows the BT.2020 standard. Signed-off-by: Randy Li --- drivers/gpu/drm/drm_fourcc.c | 1 +

[PATCH 2/2] drm/rockchip: Support 10 bits yuv format in vop

The rockchip use fully packed pixel format variants for YUV 10bits. This patch only make the VOP accept this pixel format, but it doesn't add the converting data path for the color gamuts that the target display are supported. Signed-off-by: Randy Li ---

[PATCH 0/2] Add support for a YUV 10bits pixel format

This pixel format is current used in the rockchip platform. I think any model higher than rk322x would support this pixel format. Xilinx may support it but I am not sure. More than a year ago, I post the patch Add pixel formats for 10/16 bits YUV video to the mail list, it has been update to

[PATCH 1/2] drm/fourcc: add a 10bits fully packed variant of NV12

This pixel format is a fully packed and 10bits variant of NV12. A luma pixel would take 10bits in memory, without any filled bits between pixels in a stride. The color gamut follows the BT.2020 standard. Signed-off-by: Randy Li --- drivers/gpu/drm/drm_fourcc.c | 1 +

[PATCH 2/2] drm/rockchip: Support 10 bits yuv format in vop

The rockchip use fully packed pixel format variants for YUV 10bits. This patch only make the VOP accept this pixel format, but it doesn't add the converting data path for the color gamuts that the target display are supported. Signed-off-by: Randy Li ---

[PATCH 0/2] Add support for a YUV 10bits pixel format

This pixel format is current used in the rockchip platform. I think any model higher than rk322x would support this pixel format. Xilinx may support it but I am not sure. More than a year ago, I post the patch Add pixel formats for 10/16 bits YUV video to the mail list, it has been update to

[PATCH v1 0/7] add external interrupt support to MT7622 pinctrl

From: Sean Wang The series is to add external interrupt support to MT7622 pinctrl. Before we can freely do that in pinctrl-mt7622.c with patch 3, a refactor work has to be done with patch 2 to split EINT-related code from a specific driver and then allows pintrl-mt7622.c

[PATCH v1 0/7] add external interrupt support to MT7622 pinctrl

From: Sean Wang The series is to add external interrupt support to MT7622 pinctrl. Before we can freely do that in pinctrl-mt7622.c with patch 3, a refactor work has to be done with patch 2 to split EINT-related code from a specific driver and then allows pintrl-mt7622.c to reuse it. patch 1,

[PATCH v1 7/7] arm64: dts: mt7622: add EINT support to pinctrl

From: Sean Wang Add EINT support to pinctrl and set those GPIO keys as interrupt-driven keys. Signed-off-by: Sean Wang --- arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 2 +- arch/arm64/boot/dts/mediatek/mt7622.dtsi | 8 +++- 2 files

[PATCH v1 1/7] dt-bindings: pinctrl: add external interrupt support to MT7622 pinctrl

From: Sean Wang Extend the capability of MT7622 pinctrl with adding EINT so that each GPIO can be used to notify CPU when a signal state is changing on the line as an external interrupt. Signed-off-by: Sean Wang ---

[PATCH v1 7/7] arm64: dts: mt7622: add EINT support to pinctrl

From: Sean Wang Add EINT support to pinctrl and set those GPIO keys as interrupt-driven keys. Signed-off-by: Sean Wang --- arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 2 +- arch/arm64/boot/dts/mediatek/mt7622.dtsi | 8 +++- 2 files changed, 8 insertions(+), 2 deletions(-) diff

[PATCH v1 1/7] dt-bindings: pinctrl: add external interrupt support to MT7622 pinctrl

From: Sean Wang Extend the capability of MT7622 pinctrl with adding EINT so that each GPIO can be used to notify CPU when a signal state is changing on the line as an external interrupt. Signed-off-by: Sean Wang --- Documentation/devicetree/bindings/pinctrl/pinctrl-mt7622.txt | 10 ++

[PATCH v1 3/7] pinctrl: mediatek: add EINT support to MT7622 SoC

From: Sean Wang Add EINT support to MT7622 SoC and the support is made as just an option to MT7622 pinctrl. Signed-off-by: Sean Wang --- drivers/pinctrl/mediatek/Kconfig | 2 +- drivers/pinctrl/mediatek/pinctrl-mt7622.c | 143

[PATCH v1 3/7] pinctrl: mediatek: add EINT support to MT7622 SoC

From: Sean Wang Add EINT support to MT7622 SoC and the support is made as just an option to MT7622 pinctrl. Signed-off-by: Sean Wang --- drivers/pinctrl/mediatek/Kconfig | 2 +- drivers/pinctrl/mediatek/pinctrl-mt7622.c | 143 ++ 2 files changed, 144

[PATCH v1 6/7] MAINTAINERS: update entry for PIN CONTROLLER - MEDIATEK

From: Sean Wang Add new files for the entry Signed-off-by: Sean Wang --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9051a9c..7f3cced 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11193,6

[PATCH v1 6/7] MAINTAINERS: update entry for PIN CONTROLLER - MEDIATEK

From: Sean Wang Add new files for the entry Signed-off-by: Sean Wang --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9051a9c..7f3cced 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11193,6 +11193,7 @@ L:

[PATCH v1 4/7] pinctrl: mediatek: use generic EINT register maps for each SoC

From: Sean Wang So far, EINT on each SoC all used exactly identical register map and thus it's better that we apply generic register map already supported in EINT library and stop copy-n-pasting the same data block and filling into its platform data. Signed-off-by: Sean

[PATCH v1 4/7] pinctrl: mediatek: use generic EINT register maps for each SoC

From: Sean Wang So far, EINT on each SoC all used exactly identical register map and thus it's better that we apply generic register map already supported in EINT library and stop copy-n-pasting the same data block and filling into its platform data. Signed-off-by: Sean Wang ---

<    1   2   3   4   5   6   7   >