[PATCH 4/4] staging: speakup: Alignment should match open parenthesis

Fix checkpatch issues: "CHECK: Alignment should match open parenthesis". Signed-off-by: Arushi Singhal --- drivers/staging/speakup/kobjects.c | 16 drivers/staging/speakup/main.c | 2 +- drivers/staging/speakup/selection.c

[PATCH 4/4] staging: speakup: Alignment should match open parenthesis

Fix checkpatch issues: "CHECK: Alignment should match open parenthesis". Signed-off-by: Arushi Singhal --- drivers/staging/speakup/kobjects.c | 16 drivers/staging/speakup/main.c | 2 +- drivers/staging/speakup/selection.c | 2 +-

[PATCH 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

Currently, sg_cpu's flags are set to the value defined by the last call of the cpufreq_update_util()/cpufreq_update_this_cpu(); for RT/DL classes this corresponds to the SCHED_CPUFREQ_{RT/DL} flags always being set. When multiple CPU shares the same frequency domain it might happen that a CPU

[PATCH 1/6] cpufreq: schedutil: reset sg_cpus's flags at IDLE enter

Currently, sg_cpu's flags are set to the value defined by the last call of the cpufreq_update_util()/cpufreq_update_this_cpu(); for RT/DL classes this corresponds to the SCHED_CPUFREQ_{RT/DL} flags always being set. When multiple CPU shares the same frequency domain it might happen that a CPU

[PATCH 2/2] xfs: back off from kmem_zalloc_greedy if the task is killed

From: Michal Hocko It doesn't really make much sense to retry vmalloc request if the current task is killed. We should rather bail out as soon as possible and let it RIP as soon as possible. The current implementation of vmalloc will fail anyway. Suggested-by: Brian Foster

[PATCH 2/2] xfs: back off from kmem_zalloc_greedy if the task is killed

From: Michal Hocko It doesn't really make much sense to retry vmalloc request if the current task is killed. We should rather bail out as soon as possible and let it RIP as soon as possible. The current implementation of vmalloc will fail anyway. Suggested-by: Brian Foster Signed-off-by:

[PATCH 0/6] cpufreq: schedutil: fixes for flags updates

The current version of schedutil has some issues related to the management of update flags used by systems with frequency domains spawning multiple CPUs. Each time a CPU utilisation update is issued by the scheduler a set of flags are configured to define (mainly) which class is asking for a

[PATCH 0/6] cpufreq: schedutil: fixes for flags updates

The current version of schedutil has some issues related to the management of update flags used by systems with frequency domains spawning multiple CPUs. Each time a CPU utilisation update is issued by the scheduler a set of flags are configured to define (mainly) which class is asking for a

[PATCH 2/6] cpufreq: schedutil: ignore the sugov kthread for frequencies selections

In system where multiple CPUs shares the same frequency domain a small workload on a CPU can still be subject frequency spikes, generated by the activation of the sugov's kthread. Since the sugov kthread is a special RT task, which goal is just that to activate a frequency transition, it does not

[PATCH 2/6] cpufreq: schedutil: ignore the sugov kthread for frequencies selections

In system where multiple CPUs shares the same frequency domain a small workload on a CPU can still be subject frequency spikes, generated by the activation of the sugov's kthread. Since the sugov kthread is a special RT task, which goal is just that to activate a frequency transition, it does not

[PATCH 07/11] drm/meson: Add support for HDMI encoder and DW-HDMI bridge + PHY

The Amlogic Meson GXBB/GXL/GXM SoCs embeds a Synopsys DesignWare HDMI TX Controller with a custom Bridge + PHY around the Controller. This driver makes uses of all the custom PHY plat data callbacks and enables the compatible HDMI modes to be configured as a drm_encoder instance. Signed-off-by:

[PATCH 07/11] drm/meson: Add support for HDMI encoder and DW-HDMI bridge + PHY

The Amlogic Meson GXBB/GXL/GXM SoCs embeds a Synopsys DesignWare HDMI TX Controller with a custom Bridge + PHY around the Controller. This driver makes uses of all the custom PHY plat data callbacks and enables the compatible HDMI modes to be configured as a drm_encoder instance. Signed-off-by:

[RFC PATCH v2 32/32] x86: kvm: Pin the guest memory when SEV is active

The SEV memory encryption engine uses a tweak such that two identical plaintexts at different location will have a different ciphertexts. So swapping or moving ciphertexts of two pages will not result in plaintexts being swapped. Relocating (or migrating) a physical backing pages for SEV guest

[RFC PATCH v2 32/32] x86: kvm: Pin the guest memory when SEV is active

The SEV memory encryption engine uses a tweak such that two identical plaintexts at different location will have a different ciphertexts. So swapping or moving ciphertexts of two pages will not result in plaintexts being swapped. Relocating (or migrating) a physical backing pages for SEV guest

[RFC PATCH v2 31/32] kvm: svm: Add support for SEV LAUNCH_MEASURE command

The command is used to retrieve the measurement of memory encrypted through the LAUNCH_UPDATE_DATA command. This measurement can be used for attestation purposes. Signed-off-by: Brijesh Singh --- arch/x86/kvm/svm.c | 52

[RFC PATCH v2 31/32] kvm: svm: Add support for SEV LAUNCH_MEASURE command

The command is used to retrieve the measurement of memory encrypted through the LAUNCH_UPDATE_DATA command. This measurement can be used for attestation purposes. Signed-off-by: Brijesh Singh --- arch/x86/kvm/svm.c | 52 1 file changed, 52

Re: [linux-sunxi] Re: [PATCH 2/4] clk: sunxi-ng: Add sun7i-a20 CCU driver

On Thu, Mar 2, 2017 at 10:21 PM, Maxime Ripard wrote: > Hi Priit, > > On Wed, Mar 01, 2017 at 11:38:14PM +0200, Priit Laes wrote: >> > > +/* PLL2 - Audio clock */ >> > > +static struct ccu_nm pll_audio_base_clk = { >> > > > > > > + .enable = BIT(31), >> >

Re: [linux-sunxi] Re: [PATCH 2/4] clk: sunxi-ng: Add sun7i-a20 CCU driver

On Thu, Mar 2, 2017 at 10:21 PM, Maxime Ripard wrote: > Hi Priit, > > On Wed, Mar 01, 2017 at 11:38:14PM +0200, Priit Laes wrote: >> > > +/* PLL2 - Audio clock */ >> > > +static struct ccu_nm pll_audio_base_clk = { >> > > > > > > + .enable = BIT(31), >> > > > > > > + .n =

Re: [PATCHv2 1/2] mfd: cpcap: implement irq sense helper

* Sebastian Reichel [170301 16:24]: > CPCAP can sense if IRQ is currently set or not. This > functionality is required for a few subdevices, such > as the power button and usb phy modules. > > Signed-off-by: Sebastian Reichel > --- > Changes since PATCHv1: > -

Re: [PATCHv2 1/2] mfd: cpcap: implement irq sense helper

* Sebastian Reichel [170301 16:24]: > CPCAP can sense if IRQ is currently set or not. This > functionality is required for a few subdevices, such > as the power button and usb phy modules. > > Signed-off-by: Sebastian Reichel > --- > Changes since PATCHv1: > - Newly introduced patch Works for

Re: [PATCH v17 2/3] usb: USB Type-C connector class

Hi Heikki, Good to see things are happening with Type-C! On 2017-02-21 15:24, Heikki Krogerus wrote: ... +When connected, the partner will be presented also as its own device under +/sys/class/typec/. The parent of the partner device will always be the port it +is attached to. The partner

Re: [PATCH v17 2/3] usb: USB Type-C connector class

Hi Heikki, Good to see things are happening with Type-C! On 2017-02-21 15:24, Heikki Krogerus wrote: ... +When connected, the partner will be presented also as its own device under +/sys/class/typec/. The parent of the partner device will always be the port it +is attached to. The partner

[RFC PATCH v2 27/32] kvm: svm: Add support for SEV LAUNCH_FINISH command

The command is used for finializing the SEV guest launch process. Signed-off-by: Brijesh Singh --- arch/x86/kvm/svm.c | 36 1 file changed, 36 insertions(+) diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index 62c2b22..c108064

[RFC PATCH v2 27/32] kvm: svm: Add support for SEV LAUNCH_FINISH command

The command is used for finializing the SEV guest launch process. Signed-off-by: Brijesh Singh --- arch/x86/kvm/svm.c | 36 1 file changed, 36 insertions(+) diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index 62c2b22..c108064 100644 ---

[RFC PATCH v2 08/32] x86: Use PAGE_KERNEL protection for ioremap of memory page

From: Tom Lendacky In order for memory pages to be properly mapped when SEV is active, we need to use the PAGE_KERNEL protection attribute as the base protection. This will insure that memory mapping of, e.g. ACPI tables, receives the proper mapping attributes.

[RFC PATCH v2 08/32] x86: Use PAGE_KERNEL protection for ioremap of memory page

From: Tom Lendacky In order for memory pages to be properly mapped when SEV is active, we need to use the PAGE_KERNEL protection attribute as the base protection. This will insure that memory mapping of, e.g. ACPI tables, receives the proper mapping attributes. Signed-off-by: Tom Lendacky ---

[RFC PATCH v2 25/32] kvm: svm: Add support for SEV LAUNCH_START command

The command is used to bootstrap SEV guest from unencrypted boot images. The command creates a new VM encryption key (VEK) using the guest owner's public DH certificates, and session data. The VEK will be used to encrypt the guest memory. Signed-off-by: Brijesh Singh ---

[RFC PATCH v2 25/32] kvm: svm: Add support for SEV LAUNCH_START command

The command is used to bootstrap SEV guest from unencrypted boot images. The command creates a new VM encryption key (VEK) using the guest owner's public DH certificates, and session data. The VEK will be used to encrypt the guest memory. Signed-off-by: Brijesh Singh --- arch/x86/kvm/svm.c |

[RFC PATCH v2 20/32] crypto: ccp: Add Platform Security Processor (PSP) interface support

AMD Platform Security Processor (PSP) is a dedicated processor that provides the support for encrypting the guest memory in a Secure Encrypted Virtualiztion (SEV) mode, along with software-based Tursted Executation Environment (TEE) to enable the third-party tursted applications. Signed-off-by:

[RFC PATCH v2 20/32] crypto: ccp: Add Platform Security Processor (PSP) interface support

AMD Platform Security Processor (PSP) is a dedicated processor that provides the support for encrypting the guest memory in a Secure Encrypted Virtualiztion (SEV) mode, along with software-based Tursted Executation Environment (TEE) to enable the third-party tursted applications. Signed-off-by:

[RFC PATCH v2 21/32] crypto: ccp: Add Secure Encrypted Virtualization (SEV) interface support

The Secure Encrypted Virtualization (SEV) interface allows the memory contents of a virtual machine (VM) to be transparently encrypted with a key unique to the guest. The interface provides: - /dev/sev device and ioctl (SEV_ISSUE_CMD) to execute the platform provisioning commands from the

[RFC PATCH v2 21/32] crypto: ccp: Add Secure Encrypted Virtualization (SEV) interface support

The Secure Encrypted Virtualization (SEV) interface allows the memory contents of a virtual machine (VM) to be transparently encrypted with a key unique to the guest. The interface provides: - /dev/sev device and ioctl (SEV_ISSUE_CMD) to execute the platform provisioning commands from the

[RFC PATCH v2 29/32] kvm: svm: Add support for SEV DEBUG_DECRYPT command

The command is used to decrypt guest memory region for debug purposes. Signed-off-by: Brijesh Singh --- arch/x86/kvm/svm.c | 76 1 file changed, 76 insertions(+) diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c

[RFC PATCH v2 29/32] kvm: svm: Add support for SEV DEBUG_DECRYPT command

The command is used to decrypt guest memory region for debug purposes. Signed-off-by: Brijesh Singh --- arch/x86/kvm/svm.c | 76 1 file changed, 76 insertions(+) diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index 977aa22..ce8819a

[RFC PATCH v2 05/32] x86: Use encrypted access of BOOT related data with SEV

From: Tom Lendacky When Secure Encrypted Virtualization (SEV) is active, BOOT data (such as EFI related data, setup data) is encrypted and needs to be accessed as such when mapped. Update the architecture override in early_memremap to keep the encryption attribute when

[RFC PATCH v2 05/32] x86: Use encrypted access of BOOT related data with SEV

From: Tom Lendacky When Secure Encrypted Virtualization (SEV) is active, BOOT data (such as EFI related data, setup data) is encrypted and needs to be accessed as such when mapped. Update the architecture override in early_memremap to keep the encryption attribute when mapping this data.

[PATCH v2 2/2] drivers: pwm: pwm-atmel: enable PWM on sama5d2

sama5d2 can use the same atmel_pwm_data as sama5d3. Signed-off-by: Claudiu Beznea --- Documentation/devicetree/bindings/pwm/atmel-pwm.txt | 1 + drivers/pwm/pwm-atmel.c | 3 +++ 2 files changed, 4 insertions(+) diff --git

[PATCH v2 2/2] drivers: pwm: pwm-atmel: enable PWM on sama5d2

sama5d2 can use the same atmel_pwm_data as sama5d3. Signed-off-by: Claudiu Beznea --- Documentation/devicetree/bindings/pwm/atmel-pwm.txt | 1 + drivers/pwm/pwm-atmel.c | 3 +++ 2 files changed, 4 insertions(+) diff --git

[PATCH v2 1/2] drm: bridge: dw-hdmi: Take input format from plat_data

Some display pipelines can only provide non-RBG input pixels to the HDMI TX Controller, this patch takes the pixel format from the plat_data if provided. Signed-off-by: Neil Armstrong --- drivers/gpu/drm/bridge/dw-hdmi.c | 59

[PATCH v2 1/2] drm: bridge: dw-hdmi: Take input format from plat_data

Some display pipelines can only provide non-RBG input pixels to the HDMI TX Controller, this patch takes the pixel format from the plat_data if provided. Signed-off-by: Neil Armstrong --- drivers/gpu/drm/bridge/dw-hdmi.c | 59

[RFC PATCH v2 30/32] kvm: svm: Add support for SEV DEBUG_ENCRYPT command

The command copies a plain text into guest memory and encrypts it using the VM encryption key. The command will be used for debug purposes (e.g setting breakpoint through gdbserver) Signed-off-by: Brijesh Singh --- arch/x86/kvm/svm.c | 87

[RFC PATCH v2 30/32] kvm: svm: Add support for SEV DEBUG_ENCRYPT command

The command copies a plain text into guest memory and encrypts it using the VM encryption key. The command will be used for debug purposes (e.g setting breakpoint through gdbserver) Signed-off-by: Brijesh Singh --- arch/x86/kvm/svm.c | 87

Re: [PATCH v6 1/4] clk: sunxi-ng: add Allwinner H5 CCU support for H3 CCU driver

On Thu, Mar 02, 2017 at 04:13:39AM +0800, Icenowy Zheng wrote: > Allwinner H5 is a SoC that features a design which keeps the peripheral > compatible with H3, so that it have also a CCU like the one on H3 -- > only one bus gate/reset is added, and the mmc sample/output phases are > removed because

Re: [PATCH v6 1/4] clk: sunxi-ng: add Allwinner H5 CCU support for H3 CCU driver

On Thu, Mar 02, 2017 at 04:13:39AM +0800, Icenowy Zheng wrote: > Allwinner H5 is a SoC that features a design which keeps the peripheral > compatible with H3, so that it have also a CCU like the one on H3 -- > only one bus gate/reset is added, and the mmc sample/output phases are > removed because

Re: [RFC] blkio_delay_total is calculated mistakenly

Ping? Can anyone please add some comments for this change? Thank you. Best, Weiwei Jia On Tue, Feb 14, 2017 at 8:27 PM, Weiwei Jia wrote: > Hi, > > When I read Linux Kernel source codes about how "blkio_delay_total" > (delay waiting for synchronous block I/O to complete

Re: [RFC] blkio_delay_total is calculated mistakenly

Ping? Can anyone please add some comments for this change? Thank you. Best, Weiwei Jia On Tue, Feb 14, 2017 at 8:27 PM, Weiwei Jia wrote: > Hi, > > When I read Linux Kernel source codes about how "blkio_delay_total" > (delay waiting for synchronous block I/O to complete for one task) is >

[RFC PATCH v2 02/32] x86: Secure Encrypted Virtualization (SEV) support

From: Tom Lendacky Provide support for Secure Encyrpted Virtualization (SEV). This initial support defines a flag that is used by the kernel to determine if it is running with SEV active. Signed-off-by: Tom Lendacky ---

[PATCH] thp: fix another corner case of munlock() vs. THPs

The following test case triggers BUG() in munlock_vma_pages_range(): int main(int argc, char *argv[]) { int fd; system("mount -t tmpfs -o huge=always none /mnt"); fd = open("/mnt/test", O_CREAT | O_RDWR);

[RFC PATCH v2 02/32] x86: Secure Encrypted Virtualization (SEV) support

From: Tom Lendacky Provide support for Secure Encyrpted Virtualization (SEV). This initial support defines a flag that is used by the kernel to determine if it is running with SEV active. Signed-off-by: Tom Lendacky --- arch/x86/include/asm/mem_encrypt.h | 14 +-

[PATCH] thp: fix another corner case of munlock() vs. THPs

The following test case triggers BUG() in munlock_vma_pages_range(): int main(int argc, char *argv[]) { int fd; system("mount -t tmpfs -o huge=always none /mnt"); fd = open("/mnt/test", O_CREAT | O_RDWR);

[PATCH v2 0/2] switch to atomic PWM

Changes since v1: - update only duty factor without disabling the PWM channel - if PWM channel is enabled, period, as signal polarity, is updated by disabling + enabling the PWM channel - atmel_pwm_config_prepare() function has been removed and added instead two functions, one to compute the

[PATCH v2 0/2] switch to atomic PWM

Changes since v1: - update only duty factor without disabling the PWM channel - if PWM channel is enabled, period, as signal polarity, is updated by disabling + enabling the PWM channel - atmel_pwm_config_prepare() function has been removed and added instead two functions, one to compute the

[PATCH v2 2/2] drm: bridge: Move HPD handling to PHY operations

The HDMI TX controller support HPD and RXSENSE signaling from the PHY via it's STAT0 PHY interface, but some vendor PHYs can manage these signals independently from the controller, thus these STAT0 handling should be moved to PHY specific operations and become optional. The existing STAT0 HPD and

[PATCH v2 2/2] drm: bridge: Move HPD handling to PHY operations

The HDMI TX controller support HPD and RXSENSE signaling from the PHY via it's STAT0 PHY interface, but some vendor PHYs can manage these signals independently from the controller, thus these STAT0 handling should be moved to PHY specific operations and become optional. The existing STAT0 HPD and

[RFC PATCH v2 07/32] x86/efi: Access EFI data as encrypted when SEV is active

From: Tom Lendacky EFI data is encrypted when the kernel is run under SEV. Update the page table references to be sure the EFI memory areas are accessed encrypted. Signed-off-by: Tom Lendacky Signed-off-by: Brijesh Singh

[RFC PATCH v2 07/32] x86/efi: Access EFI data as encrypted when SEV is active

From: Tom Lendacky EFI data is encrypted when the kernel is run under SEV. Update the page table references to be sure the EFI memory areas are accessed encrypted. Signed-off-by: Tom Lendacky Signed-off-by: Brijesh Singh --- arch/x86/platform/efi/efi_64.c | 15 ++- 1 file

[PATCH v2 0/2] drm: bridge: dw-hdmi: Add support for Custom PHYs

The Amlogic GX SoCs implements a Synopsys DesignWare HDMI TX Controller in combination with a very custom PHY. Thanks to Laurent Pinchart's changes, the HW report the following : Detected HDMI TX controller v2.01a with HDCP (Vendor PHY) The following differs from common PHY integration as

[PATCH v2 0/2] drm: bridge: dw-hdmi: Add support for Custom PHYs

The Amlogic GX SoCs implements a Synopsys DesignWare HDMI TX Controller in combination with a very custom PHY. Thanks to Laurent Pinchart's changes, the HW report the following : Detected HDMI TX controller v2.01a with HDCP (Vendor PHY) The following differs from common PHY integration as

[RFC PATCH v2 06/32] x86/pci: Use memremap when walking setup data

From: Tom Lendacky The use of ioremap will force the setup data to be mapped decrypted even though setup data is encrypted. Switch to using memremap which will be able to perform the proper mapping. Signed-off-by: Tom Lendacky ---

Re: mm allocation failure and hang when running xfstests generic/269 on xfs

On Thu, Mar 02, 2017 at 04:14:11PM +0100, Michal Hocko wrote: > On Thu 02-03-17 09:51:31, Brian Foster wrote: > > On Thu, Mar 02, 2017 at 03:34:41PM +0100, Michal Hocko wrote: > > > On Thu 02-03-17 09:23:15, Brian Foster wrote: > > > > On Thu, Mar 02, 2017 at 02:50:01PM +0100, Michal Hocko wrote:

[RFC PATCH v2 06/32] x86/pci: Use memremap when walking setup data

From: Tom Lendacky The use of ioremap will force the setup data to be mapped decrypted even though setup data is encrypted. Switch to using memremap which will be able to perform the proper mapping. Signed-off-by: Tom Lendacky --- arch/x86/pci/common.c |4 ++-- 1 file changed, 2

Re: mm allocation failure and hang when running xfstests generic/269 on xfs

On Thu, Mar 02, 2017 at 04:14:11PM +0100, Michal Hocko wrote: > On Thu 02-03-17 09:51:31, Brian Foster wrote: > > On Thu, Mar 02, 2017 at 03:34:41PM +0100, Michal Hocko wrote: > > > On Thu 02-03-17 09:23:15, Brian Foster wrote: > > > > On Thu, Mar 02, 2017 at 02:50:01PM +0100, Michal Hocko wrote:

[RFC PATCH v2 09/32] x86: Change early_ioremap to early_memremap for BOOT data

From: Tom Lendacky In order to map BOOT data with the proper encryption bit, the early_ioremap() function calls are changed to early_memremap() calls. This allows the proper access for both SME and SEV. Signed-off-by: Tom Lendacky ---

[RFC PATCH v2 09/32] x86: Change early_ioremap to early_memremap for BOOT data

From: Tom Lendacky In order to map BOOT data with the proper encryption bit, the early_ioremap() function calls are changed to early_memremap() calls. This allows the proper access for both SME and SEV. Signed-off-by: Tom Lendacky --- arch/x86/kernel/acpi/boot.c |4 ++--

Re: [PATCH] uapi: fix asm/signal.h userspace compilation errors

On Wed, Mar 1, 2017 at 11:20 AM, Arnd Bergmann wrote: > On Sun, Feb 26, 2017 at 2:01 AM, Dmitry V. Levin wrote: >> Include (guarded by #ifndef __KERNEL__) to fix asm/signal.h >> userspace compilation errors like this: >> >> /usr/include/asm/signal.h:126:2:

Re: [PATCH] uapi: fix asm/signal.h userspace compilation errors

On Wed, Mar 1, 2017 at 11:20 AM, Arnd Bergmann wrote: > On Sun, Feb 26, 2017 at 2:01 AM, Dmitry V. Levin wrote: >> Include (guarded by #ifndef __KERNEL__) to fix asm/signal.h >> userspace compilation errors like this: >> >> /usr/include/asm/signal.h:126:2: error: unknown type name 'size_t' >>

Re: [PATCH v1] irqdomain: add empty irq_domain_check_msi_remap

On 02/03/17 15:11, Mian Yousaf Kaukab wrote: > Fix following build error for s390: > drivers/vfio/vfio_iommu_type1.c: In function 'vfio_iommu_type1_attach_group': > drivers/vfio/vfio_iommu_type1.c:1290:25: error: implicit declaration of > function 'irq_domain_check_msi_remap' > > Signed-off-by:

Re: [PATCH] staging: speakup: replace simple_strtoul with kstrtou8

Marcin Ciupak, on jeu. 02 mars 2017 15:28:23 +0100, wrote: > - int val; > + int ret; > > - val = simple_strtoul(skip_spaces(start), , 10); > + ret = kstrtou8(skip_spaces(start), 10, dest); This is not the same, you need to have start properly move, since it's used below: >

Re: [PATCH v1] irqdomain: add empty irq_domain_check_msi_remap

On 02/03/17 15:11, Mian Yousaf Kaukab wrote: > Fix following build error for s390: > drivers/vfio/vfio_iommu_type1.c: In function 'vfio_iommu_type1_attach_group': > drivers/vfio/vfio_iommu_type1.c:1290:25: error: implicit declaration of > function 'irq_domain_check_msi_remap' > > Signed-off-by:

Re: [PATCH] staging: speakup: replace simple_strtoul with kstrtou8

Marcin Ciupak, on jeu. 02 mars 2017 15:28:23 +0100, wrote: > - int val; > + int ret; > > - val = simple_strtoul(skip_spaces(start), , 10); > + ret = kstrtou8(skip_spaces(start), 10, dest); This is not the same, you need to have start properly move, since it's used below: >

Re: [PATCHv2 01/14] treewide: Move set_memory_* functions away from cacheflush.h

On Wed, Mar 01, 2017 at 04:14:53PM -0800, Laura Abbott wrote: > diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild > index a12f1af..e419965 100644 > --- a/arch/arm64/include/asm/Kbuild > +++ b/arch/arm64/include/asm/Kbuild > @@ -27,6 +27,7 @@ generic-y += preempt.h >

Re: [PATCHv2 01/14] treewide: Move set_memory_* functions away from cacheflush.h

On Wed, Mar 01, 2017 at 04:14:53PM -0800, Laura Abbott wrote: > diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild > index a12f1af..e419965 100644 > --- a/arch/arm64/include/asm/Kbuild > +++ b/arch/arm64/include/asm/Kbuild > @@ -27,6 +27,7 @@ generic-y += preempt.h >

Re: [PATCHv2 14/14] treewide: Decouple cacheflush.h and set_memory.h

On Wed, Mar 01, 2017 at 04:15:06PM -0800, Laura Abbott wrote: > > Now that all call sites, completely decouple cacheflush.h and > set_memory.h > > Signed-off-by: Laura Abbott > --- > arch/arm/include/asm/cacheflush.h | 1 - > arch/arm64/include/asm/cacheflush.h | 1 - >

Re: [PATCHv2 14/14] treewide: Decouple cacheflush.h and set_memory.h

On Wed, Mar 01, 2017 at 04:15:06PM -0800, Laura Abbott wrote: > > Now that all call sites, completely decouple cacheflush.h and > set_memory.h > > Signed-off-by: Laura Abbott > --- > arch/arm/include/asm/cacheflush.h | 1 - > arch/arm64/include/asm/cacheflush.h | 1 - >

[PATCH] [v2] scsi: qedi: fix build error without DEBUG_FS

Without CONFIG_DEBUG_FS, we run into a link error: drivers/scsi/qedi/qedi_iscsi.o: In function `qedi_ep_poll': qedi_iscsi.c:(.text.qedi_ep_poll+0x134): undefined reference to `do_not_recover' drivers/scsi/qedi/qedi_iscsi.o: In function `qedi_ep_disconnect':

[PATCH] [v2] scsi: qedi: fix build error without DEBUG_FS

Without CONFIG_DEBUG_FS, we run into a link error: drivers/scsi/qedi/qedi_iscsi.o: In function `qedi_ep_poll': qedi_iscsi.c:(.text.qedi_ep_poll+0x134): undefined reference to `do_not_recover' drivers/scsi/qedi/qedi_iscsi.o: In function `qedi_ep_disconnect':

[RFC PATCH v2 10/32] x86: DMA support for SEV memory encryption

From: Tom Lendacky DMA access to memory mapped as encrypted while SEV is active can not be encrypted during device write or decrypted during device read. In order for DMA to properly work when SEV is active, the swiotlb bounce buffers must be used. Signed-off-by: Tom

[RFC PATCH v2 10/32] x86: DMA support for SEV memory encryption

From: Tom Lendacky DMA access to memory mapped as encrypted while SEV is active can not be encrypted during device write or decrypted during device read. In order for DMA to properly work when SEV is active, the swiotlb bounce buffers must be used. Signed-off-by: Tom Lendacky ---

Re: [PATCH 2/3] clk: sunxi-ng: add support for PRCM CCUs

On Wed, Mar 01, 2017 at 08:22:13PM +0800, Icenowy Zheng wrote: > > I'm a bit worried by that to be honest. You claim to support the A31, > > yet jugdging by the current state of that code you never actually > > tested it on that SoC. > > > > What makes you say that the PRCM clocks are the same

Re: [PATCH v2] dt-bindings: net: generalize moxart-mac to support all faraday based ftmac IP

On Thu, Feb 23, 2017 at 10:53:47AM +0800, Greentime Hu wrote: > Andestech and moxa use the same faraday mac IP, so we use faraday,ftmac.txt to > describe it. > > Signed-off-by: Greentime Hu > --- > Changes in v2: > - Wrap the commit messages and remove the hunk that are

Re: [PATCH 2/3] clk: sunxi-ng: add support for PRCM CCUs

On Wed, Mar 01, 2017 at 08:22:13PM +0800, Icenowy Zheng wrote: > > I'm a bit worried by that to be honest. You claim to support the A31, > > yet jugdging by the current state of that code you never actually > > tested it on that SoC. > > > > What makes you say that the PRCM clocks are the same

Re: [PATCH v2] dt-bindings: net: generalize moxart-mac to support all faraday based ftmac IP

On Thu, Feb 23, 2017 at 10:53:47AM +0800, Greentime Hu wrote: > Andestech and moxa use the same faraday mac IP, so we use faraday,ftmac.txt to > describe it. > > Signed-off-by: Greentime Hu > --- > Changes in v2: > - Wrap the commit messages and remove the hunk that are already applied. > --- >

[PATCH 0/4] thp: fix few MADV_DONTNEED races

For MADV_DONTNEED to work properly with huge pages, it's critical to not clear pmd intermittently unless you hold down_write(mmap_sem). Otherwise MADV_DONTNEED can miss the THP which can lead to userspace breakage. See example of such race in commit message of patch 2/4. All these races are

[PATCH 0/4] thp: fix few MADV_DONTNEED races

For MADV_DONTNEED to work properly with huge pages, it's critical to not clear pmd intermittently unless you hold down_write(mmap_sem). Otherwise MADV_DONTNEED can miss the THP which can lead to userspace breakage. See example of such race in commit message of patch 2/4. All these races are

Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support

On 02/03/2017 15:29, Boris Brezillon wrote: > On Thu, 2 Mar 2017 19:24:43 +0530 > Vignesh R wrote: > >> > Not really, I am debugging another issue with UBIFS on DRA74 EVM (ARM > cortex-a15) wherein pages allocated by vmalloc are in highmem region > that are

Re: [RFC PATCH 2/2] mtd: devices: m25p80: Enable spi-nor bounce buffer support

On 02/03/2017 15:29, Boris Brezillon wrote: > On Thu, 2 Mar 2017 19:24:43 +0530 > Vignesh R wrote: > >> > Not really, I am debugging another issue with UBIFS on DRA74 EVM (ARM > cortex-a15) wherein pages allocated by vmalloc are in highmem region > that are not addressable

[PATCH] rmap: fix NULL-pointer dereference on THP munlocking

The following test case triggers NULL-pointer derefernce in try_to_unmap_one(): #include #include #include #include int main(int argc, char *argv[]) { int fd; system("mount -t tmpfs -o huge=always none /mnt");

[PATCH] rmap: fix NULL-pointer dereference on THP munlocking

The following test case triggers NULL-pointer derefernce in try_to_unmap_one(): #include #include #include #include int main(int argc, char *argv[]) { int fd; system("mount -t tmpfs -o huge=always none /mnt");

Re: [PATCH 4/7] net: stmmac: Parse FIFO sizes from feature registers

Hi Thierry, Às 5:24 PM de 2/23/2017, Thierry Reding escreveu: > From: Thierry Reding > > New version of this core encode the FIFO sizes in one of the feature > registers. Use these sizes as default, but still allow device tree to > override them for backwards compatibility.

Re: [PATCH 4/7] net: stmmac: Parse FIFO sizes from feature registers

Hi Thierry, Às 5:24 PM de 2/23/2017, Thierry Reding escreveu: > From: Thierry Reding > > New version of this core encode the FIFO sizes in one of the feature > registers. Use these sizes as default, but still allow device tree to > override them for backwards compatibility. > > Signed-off-by:

Re: [PATCH v2 2/3] printk: rename selected_console -> preferred_console

On Thu, 2 Mar 2017 16:11:33 +0300 Aleksey Makarov wrote: > The variable selected_console is set in __add_preferred_console() > to point to the last console parameter that was added to the > console_cmdline array. > > Rename it to preferred_console so that the name

Re: [PATCH v2 2/3] printk: rename selected_console -> preferred_console

On Thu, 2 Mar 2017 16:11:33 +0300 Aleksey Makarov wrote: > The variable selected_console is set in __add_preferred_console() > to point to the last console parameter that was added to the > console_cmdline array. > > Rename it to preferred_console so that the name reflects the usage. As I

Re: [PATCH] omap3isp: wait for regulators to come up

Hi Pavel, Thank you for the patch. On Thursday 02 Mar 2017 13:45:32 Pavel Machek wrote: > If regulator returns -EPROBE_DEFER, we need to return it too, so that > omap3isp will be re-probed when regulator is ready. > > Signed-off-by: Pavel Machek > > diff --git

Re: [PATCH] omap3isp: wait for regulators to come up

Hi Pavel, Thank you for the patch. On Thursday 02 Mar 2017 13:45:32 Pavel Machek wrote: > If regulator returns -EPROBE_DEFER, we need to return it too, so that > omap3isp will be re-probed when regulator is ready. > > Signed-off-by: Pavel Machek > > diff --git

Re: [Outreachy kernel] [PATCH] staging: nvec: cleanup USLEEP_RANGE checkpatch checks

On Thu, 2 Mar 2017, SIMRAN SINGHAL wrote: > > > On Thursday, March 2, 2017 at 8:06:40 PM UTC+5:30, Julia Lawall wrote: > > > On Thu, 2 Mar 2017, simran singhal wrote: > > > Resolve strict checkpatch USLEEP_RANGE checks by converting > delays and > > sleeps as described

Re: [Outreachy kernel] [PATCH] staging: nvec: cleanup USLEEP_RANGE checkpatch checks

On Thu, 2 Mar 2017, SIMRAN SINGHAL wrote: > > > On Thursday, March 2, 2017 at 8:06:40 PM UTC+5:30, Julia Lawall wrote: > > > On Thu, 2 Mar 2017, simran singhal wrote: > > > Resolve strict checkpatch USLEEP_RANGE checks by converting > delays and > > sleeps as described

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Thu 02-03-17 14:53:48, Igor Mammedov wrote: [...] > When trying to support memory unplug on guest side in RHEL7, > experience shows otherwise. Simplistic udev rule which onlines > added block doesn't work in case one wants to online it as movable. > > Hotplugged blocks in current kernel should

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Thu 02-03-17 14:53:48, Igor Mammedov wrote: [...] > When trying to support memory unplug on guest side in RHEL7, > experience shows otherwise. Simplistic udev rule which onlines > added block doesn't work in case one wants to online it as movable. > > Hotplugged blocks in current kernel should

Re: [PATCH] scsi: qedi: fix build error without DEBUG_FS

On 03/02/2017 01:10 PM, Arnd Bergmann wrote: > Without CONFIG_DEBUG_FS, we run into a link error: > > drivers/scsi/qedi/qedi_iscsi.o: In function `qedi_ep_poll': > qedi_iscsi.c:(.text.qedi_ep_poll+0x134): undefined reference to > `do_not_recover' > drivers/scsi/qedi/qedi_iscsi.o: In function

Re: [PATCH] scsi: qedi: fix build error without DEBUG_FS

On 03/02/2017 01:10 PM, Arnd Bergmann wrote: > Without CONFIG_DEBUG_FS, we run into a link error: > > drivers/scsi/qedi/qedi_iscsi.o: In function `qedi_ep_poll': > qedi_iscsi.c:(.text.qedi_ep_poll+0x134): undefined reference to > `do_not_recover' > drivers/scsi/qedi/qedi_iscsi.o: In function

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