[PATCH 1/2] ARM: stm32: Don't select DMA unconditionally on STM32MP157C

The patch that enabled these had no useful changelog that explains why it is done, and it causes a build warning: WARNING: unmet direct dependencies detected for STM32_DMA Depends on [n]: DMADEVICES [=n] && (ARCH_STM32 [=y] || COMPILE_TEST [=y]) Selected by [y]: - MACH_STM32MP157 [=y] &&

[PATCH 1/2] ARM: stm32: Don't select DMA unconditionally on STM32MP157C

The patch that enabled these had no useful changelog that explains why it is done, and it causes a build warning: WARNING: unmet direct dependencies detected for STM32_DMA Depends on [n]: DMADEVICES [=n] && (ARCH_STM32 [=y] || COMPILE_TEST [=y]) Selected by [y]: - MACH_STM32MP157 [=y] &&

[PATCH 1/2] ARM: stm32: Don't select DMA unconditionally on STM32MP157C

The patch that enabled these had no useful changelog that explains why it is done, and it causes a build warning: WARNING: unmet direct dependencies detected for STM32_DMA Depends on [n]: DMADEVICES [=n] && (ARCH_STM32 [=y] || COMPILE_TEST [=y]) Selected by [y]: - MACH_STM32MP157 [=y] &&

[PATCH 1/2] ARM: stm32: Don't select DMA unconditionally on STM32MP157C

The patch that enabled these had no useful changelog that explains why it is done, and it causes a build warning: WARNING: unmet direct dependencies detected for STM32_DMA Depends on [n]: DMADEVICES [=n] && (ARCH_STM32 [=y] || COMPILE_TEST [=y]) Selected by [y]: - MACH_STM32MP157 [=y] &&

[PATCH] qcom: cmd-db: enforce CONFIG_OF_RESERVED_MEM dependency

Without CONFIG_OF_RESERVED_MEM, gcc sees that the global cmd_db_header variable is never initialized, and through code optimization concludes that a lot of other code cannot possibly work after that: drivers/soc/qcom/cmd-db.c: In function 'cmd_db_read_addr': drivers/soc/qcom/cmd-db.c:197:21:

[PATCH] qcom: cmd-db: enforce CONFIG_OF_RESERVED_MEM dependency

Without CONFIG_OF_RESERVED_MEM, gcc sees that the global cmd_db_header variable is never initialized, and through code optimization concludes that a lot of other code cannot possibly work after that: drivers/soc/qcom/cmd-db.c: In function 'cmd_db_read_addr': drivers/soc/qcom/cmd-db.c:197:21:

[PATCH] usb/gadget: aspeed-vhub: add USB_LIBCOMPOSITE dependency

Without that option, we run into a link failure: drivers/usb/gadget/udc/aspeed-vhub/hub.o: In function `ast_vhub_std_hub_request': hub.c:(.text+0x5b0): undefined reference to `usb_gadget_get_string' Fixes: 7ecca2a4080c ("usb/gadget: Add driver for Aspeed SoC virtual hub") Signed-off-by: Arnd

[PATCH] usb/gadget: aspeed-vhub: add USB_LIBCOMPOSITE dependency

Without that option, we run into a link failure: drivers/usb/gadget/udc/aspeed-vhub/hub.o: In function `ast_vhub_std_hub_request': hub.c:(.text+0x5b0): undefined reference to `usb_gadget_get_string' Fixes: 7ecca2a4080c ("usb/gadget: Add driver for Aspeed SoC virtual hub") Signed-off-by: Arnd

Re: [PATCH] drm: check_pixel_format() should return true if no modifiers are passed for a supported pixel format

On Fri, May 25, 2018 at 04:48:59PM +0100, Brian Starkey wrote: > Hi Ayan, > > On Fri, May 25, 2018 at 04:35:41PM +0100, Ayan Kumar Halder wrote: > >If a plane supports a pixel format and the framebuffer does not pass any > >modifiers, then drm_plane_check_pixel_format() should always return true

Re: [PATCH] drm: check_pixel_format() should return true if no modifiers are passed for a supported pixel format

On Fri, May 25, 2018 at 04:48:59PM +0100, Brian Starkey wrote: > Hi Ayan, > > On Fri, May 25, 2018 at 04:35:41PM +0100, Ayan Kumar Halder wrote: > >If a plane supports a pixel format and the framebuffer does not pass any > >modifiers, then drm_plane_check_pixel_format() should always return true

Re: [GIT PULL] PHY: for 4.18

On Tue, May 22, 2018 at 06:08:18AM +0530, Kishon Vijay Abraham I wrote: > Hi Greg, > > Please find the pull request for 4.18 merge window below. It adds a couple of > new USB PHY drivers, adds support for couple of newer PHYs in existing > drivers and few cleanups. Please find the complete set of

Re: [GIT PULL] PHY: for 4.18

On Tue, May 22, 2018 at 06:08:18AM +0530, Kishon Vijay Abraham I wrote: > Hi Greg, > > Please find the pull request for 4.18 merge window below. It adds a couple of > new USB PHY drivers, adds support for couple of newer PHYs in existing > drivers and few cleanups. Please find the complete set of

Re: [PATCH 08/11] coresight: Add generic TMC sg table framework

On 23/05/18 21:25, Mathieu Poirier wrote: On Fri, May 18, 2018 at 05:39:24PM +0100, Suzuki K Poulose wrote: This patch introduces a generic sg table data structure and associated operations. An SG table can be used to map a set of Data pages where the trace data could be stored by the TMC ETR.

Re: [PATCH 08/11] coresight: Add generic TMC sg table framework

On 23/05/18 21:25, Mathieu Poirier wrote: On Fri, May 18, 2018 at 05:39:24PM +0100, Suzuki K Poulose wrote: This patch introduces a generic sg table data structure and associated operations. An SG table can be used to map a set of Data pages where the trace data could be stored by the TMC ETR.

[PATCH] usb: dwc3: qcom: mark PM functions as __maybe_unused

The #ifdef guards around these are wrong, resulting in warnings in certain configurations: drivers/usb/dwc3/dwc3-qcom.c:244:12: error: 'dwc3_qcom_resume' defined but not used [-Werror=unused-function] static int dwc3_qcom_resume(struct dwc3_qcom *qcom) ^~~~

[PATCH] usb: dwc3: qcom: mark PM functions as __maybe_unused

The #ifdef guards around these are wrong, resulting in warnings in certain configurations: drivers/usb/dwc3/dwc3-qcom.c:244:12: error: 'dwc3_qcom_resume' defined but not used [-Werror=unused-function] static int dwc3_qcom_resume(struct dwc3_qcom *qcom) ^~~~

Re: [PATCH] KVM: x86: VMX: fix building without CONFIG_HYPERV

Arnd Bergmann writes: > The global ms_hyperv variable is part of the hyperv support, so > we get a link error from accessing it in kernels that have this > turned off: > > arch/x86/kvm/vmx.o: In function `alloc_loaded_vmcs': > vmx.c:(.text+0x1654a): undefined reference to

Re: [PATCH] KVM: x86: VMX: fix building without CONFIG_HYPERV

Arnd Bergmann writes: > The global ms_hyperv variable is part of the hyperv support, so > we get a link error from accessing it in kernels that have this > turned off: > > arch/x86/kvm/vmx.o: In function `alloc_loaded_vmcs': > vmx.c:(.text+0x1654a): undefined reference to `ms_hyperv' >

[PATCH] pwm: stm32: enforce dependency on CONFIG_MFD_STM32_TIMERS

When compile-testing the pwm driver without also enabling the stm32_timers MFD, we run into a link error: drivers/pwm/pwm-stm32.o: In function `stm32_pwm_raw_capture.isra.6': pwm-stm32.c:(.text+0xcb0): undefined reference to `stm32_timers_dma_burst_read' We don't need the '|| COMPILE_TEST' here,

[PATCH] pwm: stm32: enforce dependency on CONFIG_MFD_STM32_TIMERS

When compile-testing the pwm driver without also enabling the stm32_timers MFD, we run into a link error: drivers/pwm/pwm-stm32.o: In function `stm32_pwm_raw_capture.isra.6': pwm-stm32.c:(.text+0xcb0): undefined reference to `stm32_timers_dma_burst_read' We don't need the '|| COMPILE_TEST' here,

[GIT PULL] arm64: fixes for -rc7

Hi Linus, Here are a few arm64 fixes for -rc7. The two main fixes are for the asm constraints in our LSE atomics and for our pmd/pud setters when changing permissions for kernel mappings. Summary in the tag. Please pull, Will --->8 The following changes since commit

[GIT PULL] arm64: fixes for -rc7

Hi Linus, Here are a few arm64 fixes for -rc7. The two main fixes are for the asm constraints in our LSE atomics and for our pmd/pud setters when changing permissions for kernel mappings. Summary in the tag. Please pull, Will --->8 The following changes since commit

[PATCH 2/2] ASoC: omap: fix compile-test building

The newly introduced driver causes a harmless Kconfig warning when compile-testing random configurations: WARNING: unmet direct dependencies detected for SND_SDMA_SOC Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && DMA_OMAP [=n] Selected by [y]: - SND_OMAP_SOC [=y] &&

[PATCH 2/2] ASoC: omap: fix compile-test building

The newly introduced driver causes a harmless Kconfig warning when compile-testing random configurations: WARNING: unmet direct dependencies detected for SND_SDMA_SOC Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && DMA_OMAP [=n] Selected by [y]: - SND_OMAP_SOC [=y] &&

[PATCH 1/2] ASoC: omap: sdma-pcm: add module license

Kbuild warns that we should have a MODULE_LICENSE() tag in the new module: WARNING: modpost: missing MODULE_LICENSE() in sound/soc/omap/snd-soc-sdma.o This adds both the license and author field corresponding to the information at the top of the file. Fixes: dde637f2daf1 ("ASoC: omap: Introduce

[PATCH 1/2] ASoC: omap: sdma-pcm: add module license

Kbuild warns that we should have a MODULE_LICENSE() tag in the new module: WARNING: modpost: missing MODULE_LICENSE() in sound/soc/omap/snd-soc-sdma.o This adds both the license and author field corresponding to the information at the top of the file. Fixes: dde637f2daf1 ("ASoC: omap: Introduce

Re: [PATCH] remoteproc: Add APSS based Qualcomm ADSP PIL driver for SDM845

On Thu, May 24, 2018 at 12:18 AM, Rohit Kumar wrote: > Thanks Bjorn for reviewing. > > > On 5/23/2018 11:56 AM, Bjorn Andersson wrote: >> >> On Sun 13 May 00:01 PDT 2018, Rohit kumar wrote: >> >> [..] >>> >>> +static inline void update_bits(void *reg, u32 mask_val, u32

Re: [PATCH] remoteproc: Add APSS based Qualcomm ADSP PIL driver for SDM845

On Thu, May 24, 2018 at 12:18 AM, Rohit Kumar wrote: > Thanks Bjorn for reviewing. > > > On 5/23/2018 11:56 AM, Bjorn Andersson wrote: >> >> On Sun 13 May 00:01 PDT 2018, Rohit kumar wrote: >> >> [..] >>> >>> +static inline void update_bits(void *reg, u32 mask_val, u32 set_val, u32 >>> shift)

Re: [RFC PATCH 4/5] mm: rename and change semantics of nr_indirectly_reclaimable_bytes

On Thu, 24 May 2018, Vlastimil Babka wrote: > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h > index 32699b2dc52a..4343948f33e5 100644 > --- a/include/linux/mmzone.h > +++ b/include/linux/mmzone.h > @@ -180,7 +180,7 @@ enum node_stat_item { > NR_VMSCAN_IMMEDIATE,/*

Re: [RFC PATCH 4/5] mm: rename and change semantics of nr_indirectly_reclaimable_bytes

On Thu, 24 May 2018, Vlastimil Babka wrote: > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h > index 32699b2dc52a..4343948f33e5 100644 > --- a/include/linux/mmzone.h > +++ b/include/linux/mmzone.h > @@ -180,7 +180,7 @@ enum node_stat_item { > NR_VMSCAN_IMMEDIATE,/*

Re: [Very Urgent] I need a foreign partner.

Hello I urgently need a partner to retain and invest 14 six zero USD figures currently in America, I'm willing to give 35 percent of the total as compensation to you for your assistance. Sincerely, Richard.

Re: [Very Urgent] I need a foreign partner.

Hello I urgently need a partner to retain and invest 14 six zero USD figures currently in America, I'm willing to give 35 percent of the total as compensation to you for your assistance. Sincerely, Richard.

[PATCH 1/4 v2] PM / suspend: Prevent might sleep splats

From: Thomas Gleixner timekeeping suspend/resume calls read_persistent_clock() which takes rtc_lock. That results in might sleep warnings because at that point we run with interrupts disabled. We cannot convert rtc_lock to a raw spinlock as that would trigger other might

[PATCH v7 1/3] acpi: apei: Rename GHES_SEV_PANIC to GHES_SEV_FATAL

'GHES_SEV_PANIC' implies that the kernel must panic. That was true many years ago when fatal errors could not be handled and recovered. However, this is no longer the case with PCIe AER and DPC errors. The latter class of errors are contained at the hardware level. 'GHES_SEV_PANIC' is confusing

[PATCH 1/4 v2] PM / suspend: Prevent might sleep splats

From: Thomas Gleixner timekeeping suspend/resume calls read_persistent_clock() which takes rtc_lock. That results in might sleep warnings because at that point we run with interrupts disabled. We cannot convert rtc_lock to a raw spinlock as that would trigger other might sleep warnings. As a

[PATCH v7 1/3] acpi: apei: Rename GHES_SEV_PANIC to GHES_SEV_FATAL

'GHES_SEV_PANIC' implies that the kernel must panic. That was true many years ago when fatal errors could not be handled and recovered. However, this is no longer the case with PCIe AER and DPC errors. The latter class of errors are contained at the hardware level. 'GHES_SEV_PANIC' is confusing

Re: [PATCH] drm: check_pixel_format() should return true if no modifiers are passed for a supported pixel format

On Fri, May 25, 2018 at 04:35:41PM +0100, Ayan Kumar Halder wrote: > If a plane supports a pixel format and the framebuffer does not pass any > modifiers, then drm_plane_check_pixel_format() should always return true > for the given format regardless of whether the plane supports any > modifiers

Re: [PATCH] drm: check_pixel_format() should return true if no modifiers are passed for a supported pixel format

On Fri, May 25, 2018 at 04:35:41PM +0100, Ayan Kumar Halder wrote: > If a plane supports a pixel format and the framebuffer does not pass any > modifiers, then drm_plane_check_pixel_format() should always return true > for the given format regardless of whether the plane supports any > modifiers

Re: [PATCH v5 02/10] sched/rt: add rt_rq utilization tracking

On 25-May 15:12, Vincent Guittot wrote: > schedutil governor relies on cfs_rq's util_avg to choose the OPP when cfs ^ only otherwise, while RT tasks are

[PATCH v7 3/3] acpi: apei: Do not panic() on PCIe errors reported through GHES

As previously noted, the policy to panic on any "Fatal" GHES error is not suitable for several classes of errors. The most notable is error containment. The correct policy is to achieve identical behavior to native error handling -- i.e. when not reported through GHES. This, in special cases, may

Re: [PATCH v5 02/10] sched/rt: add rt_rq utilization tracking

On 25-May 15:12, Vincent Guittot wrote: > schedutil governor relies on cfs_rq's util_avg to choose the OPP when cfs ^ only otherwise, while RT tasks are

[PATCH v7 3/3] acpi: apei: Do not panic() on PCIe errors reported through GHES

As previously noted, the policy to panic on any "Fatal" GHES error is not suitable for several classes of errors. The most notable is error containment. The correct policy is to achieve identical behavior to native error handling -- i.e. when not reported through GHES. This, in special cases, may

Re: [RFT v2 1/4] perf cs-etm: Generate sample for missed packets

Hi Arnaldo, Rob, On Fri, May 25, 2018 at 12:27:13PM -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, May 25, 2018 at 03:03:47PM +0100, Robert Walker escreveu: > > Hi Leo, > > > > Following the discussions from your reply to this with a simplified patch, > > this version of the patch works better

Re: [RFT v2 1/4] perf cs-etm: Generate sample for missed packets

Hi Arnaldo, Rob, On Fri, May 25, 2018 at 12:27:13PM -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, May 25, 2018 at 03:03:47PM +0100, Robert Walker escreveu: > > Hi Leo, > > > > Following the discussions from your reply to this with a simplified patch, > > this version of the patch works better

[PATCH v7 2/3] acpi: apei: Rename ghes_severity() to ghes_cper_severity()

ghes_severity() is a misnomer in this case, as it implies the severity of the entire GHES structure. Instead, it maps one CPER value to one GHES_SEV* value. ghes_cper_severity() is clearer. Signed-off-by: Alexandru Gagniuc --- drivers/acpi/apei/ghes.c | 17

[PATCH v7 2/3] acpi: apei: Rename ghes_severity() to ghes_cper_severity()

ghes_severity() is a misnomer in this case, as it implies the severity of the entire GHES structure. Instead, it maps one CPER value to one GHES_SEV* value. ghes_cper_severity() is clearer. Signed-off-by: Alexandru Gagniuc --- drivers/acpi/apei/ghes.c | 17 - 1 file changed, 8

[PATCH v7 0/3] acpi: apei: Drop panic() on fatal errors policy

FFS (firmware-first) handling through APEI seems to have developed a policy to panic() on any fatal errors. This policy is completely independent of the non-FFS case. It is also inconsistent with how the native error handlers, a number of which will recover the system from fatal errors. The

[PATCH v7 0/3] acpi: apei: Drop panic() on fatal errors policy

FFS (firmware-first) handling through APEI seems to have developed a policy to panic() on any fatal errors. This policy is completely independent of the non-FFS case. It is also inconsistent with how the native error handlers, a number of which will recover the system from fatal errors. The

Re: [PATCH] staging: typec: rt1711h: fix tcpci dependency

On Fri, May 25, 2018 at 05:38:25PM +0200, Arnd Bergmann wrote: > Using 'select' instead of the normal 'depends on' causes > a build issue with CONFIG_I2C=m: > > WARNING: unmet direct dependencies detected for TYPEC_TCPCI > Depends on [m]: STAGING [=y] && TYPEC_TCPM [=y] && I2C [=m] > Selected

Re: [PATCH] staging: typec: rt1711h: fix tcpci dependency

On Fri, May 25, 2018 at 05:38:25PM +0200, Arnd Bergmann wrote: > Using 'select' instead of the normal 'depends on' causes > a build issue with CONFIG_I2C=m: > > WARNING: unmet direct dependencies detected for TYPEC_TCPCI > Depends on [m]: STAGING [=y] && TYPEC_TCPM [=y] && I2C [=m] > Selected

[PATCH 7/8] drm/bridge: fix dependency for lvds-encoder

The DRM panel bridge code is built into the kms helpers module, so we get a link error when trying to use it from a built-in driver while the kms helper is a loadable module: drivers/gpu/drm/bridge/lvds-encoder.o: In function `lvds_encoder_probe': lvds-encoder.c:(.text+0x124): undefined reference

[PATCH 7/8] drm/bridge: fix dependency for lvds-encoder

The DRM panel bridge code is built into the kms helpers module, so we get a link error when trying to use it from a built-in driver while the kms helper is a loadable module: drivers/gpu/drm/bridge/lvds-encoder.o: In function `lvds_encoder_probe': lvds-encoder.c:(.text+0x124): undefined reference

[PATCH 6/8] drm/exynos: fix scaler_task_done return type

Modern gcc versions warn about returning a ternary operator with an 'int' type in a function returning type 'bool': drivers/gpu/drm/exynos/exynos_drm_scaler.c: In function 'scaler_task_done': drivers/gpu/drm/exynos/exynos_drm_scaler.c:402:47: error: ?: using integer constants in boolean context

[PATCH 6/8] drm/exynos: fix scaler_task_done return type

Modern gcc versions warn about returning a ternary operator with an 'int' type in a function returning type 'bool': drivers/gpu/drm/exynos/exynos_drm_scaler.c: In function 'scaler_task_done': drivers/gpu/drm/exynos/exynos_drm_scaler.c:402:47: error: ?: using integer constants in boolean context

[PATCH 8/8] drm/bridge: cdns: mark PM functions as __maybe_unused

These two functions are unused in some configurations, and using __maybe_unused is the easiest way to shut up the harmless warnings: drivers/gpu/drm/bridge/cdns-dsi.c:1353:12: error: 'cdns_dsi_suspend' defined but not used [-Werror=unused-function] static int cdns_dsi_suspend(struct device

[PATCH 8/8] drm/bridge: cdns: mark PM functions as __maybe_unused

These two functions are unused in some configurations, and using __maybe_unused is the easiest way to shut up the harmless warnings: drivers/gpu/drm/bridge/cdns-dsi.c:1353:12: error: 'cdns_dsi_suspend' defined but not used [-Werror=unused-function] static int cdns_dsi_suspend(struct device

Re: [RFC PATCH 1/5] mm, slab/slub: introduce kmalloc-reclaimable caches

On Thu, 24 May 2018, Vlastimil Babka wrote: > diff --git a/include/linux/slab.h b/include/linux/slab.h > index 9ebe659bd4a5..5bff0571b360 100644 > --- a/include/linux/slab.h > +++ b/include/linux/slab.h > @@ -296,11 +296,16 @@ static inline void __check_heap_object(const void *ptr, > unsigned

Re: [RFC PATCH 1/5] mm, slab/slub: introduce kmalloc-reclaimable caches

On Thu, 24 May 2018, Vlastimil Babka wrote: > diff --git a/include/linux/slab.h b/include/linux/slab.h > index 9ebe659bd4a5..5bff0571b360 100644 > --- a/include/linux/slab.h > +++ b/include/linux/slab.h > @@ -296,11 +296,16 @@ static inline void __check_heap_object(const void *ptr, > unsigned

[PATCH 5/8] drm/v3d: add CONFIG_MMU dependency

Without CONFIG_MMU, we get a link error: drivers/gpu/drm/v3d/v3d_bo.o: In function `v3d_gem_fault': v3d_bo.c:(.text+0x3ca): undefined reference to `vm_insert_mixed' The other drivers with this problem already depend on CONFIG_MMU, so let's do the same thing here. Fixes: 57692c94dcbe ("drm/v3d:

[PATCH 5/8] drm/v3d: add CONFIG_MMU dependency

Without CONFIG_MMU, we get a link error: drivers/gpu/drm/v3d/v3d_bo.o: In function `v3d_gem_fault': v3d_bo.c:(.text+0x3ca): undefined reference to `vm_insert_mixed' The other drivers with this problem already depend on CONFIG_MMU, so let's do the same thing here. Fixes: 57692c94dcbe ("drm/v3d:

[PATCH 4/8] drm/rcar-du: fix merge conflict for state->alpha

The "alpha" struct member was removed in one commit but another user added in another, leading to a build failure: drivers/gpu/drm/rcar-du/rcar_du_vsp.c: In function 'rcar_du_vsp_plane_atomic_duplicate_state': drivers/gpu/drm/rcar-du/rcar_du_vsp.c:325:6: error: 'struct rcar_du_vsp_plane_state'

[PATCH 4/8] drm/rcar-du: fix merge conflict for state->alpha

The "alpha" struct member was removed in one commit but another user added in another, leading to a build failure: drivers/gpu/drm/rcar-du/rcar_du_vsp.c: In function 'rcar_du_vsp_plane_atomic_duplicate_state': drivers/gpu/drm/rcar-du/rcar_du_vsp.c:325:6: error: 'struct rcar_du_vsp_plane_state'

[PATCH 3/8] drm/xen-front: fix 32-bit build warning

In 32-bit kernel builds, we cannot cast between a pointer and a 64-bit type: In file included from drivers/gpu/drm/xen/xen_drm_front_cfg.c:18: drivers/gpu/drm/xen/xen_drm_front.h: In function 'xen_drm_front_fb_to_cookie': drivers/gpu/drm/xen/xen_drm_front.h:129:9: error: cast from pointer to

[PATCH 3/8] drm/xen-front: fix 32-bit build warning

In 32-bit kernel builds, we cannot cast between a pointer and a 64-bit type: In file included from drivers/gpu/drm/xen/xen_drm_front_cfg.c:18: drivers/gpu/drm/xen/xen_drm_front.h: In function 'xen_drm_front_fb_to_cookie': drivers/gpu/drm/xen/xen_drm_front.h:129:9: error: cast from pointer to

Fw: fix green/blue pio-led on bpi-r2

Resend to Mailinglist because of previous blocked cause of html-format Gesendet: Freitag, 25. Mai 2018 um 17:47 Uhr Von: "Frank Wunderlich" An: "Matthias Brugger" , "Rob Herring" , "Mark Rutland" , "Russell King"

Fw: fix green/blue pio-led on bpi-r2

Resend to Mailinglist because of previous blocked cause of html-format Gesendet: Freitag, 25. Mai 2018 um 17:47 Uhr Von: "Frank Wunderlich" An: "Matthias Brugger" , "Rob Herring" , "Mark Rutland" , "Russell King" Cc: linux-arm-ker...@lists.infradead.org, linux-media...@lists.infradead.org,

[PATCH 2/8] drm/amdgpu: fix 32-bit build warning

Casting a pointer to a 64-bit type causes a warning on 32-bit targets: drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c:473:24: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] lower_32_bits((uint64_t)wptr)); ^

[PATCH 2/8] drm/amdgpu: fix 32-bit build warning

Casting a pointer to a 64-bit type causes a warning on 32-bit targets: drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c:473:24: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] lower_32_bits((uint64_t)wptr)); ^

[PATCH 1/8] drm/sun4i: mark PM functions as __maybe_unused

Disabling CONFIG_PM produces a compile time warning when these functions are not referenced: drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:1072:12: error: 'sun6i_dsi_runtime_suspend' defined but not used [-Werror=unused-function] static int sun6i_dsi_runtime_suspend(struct device *dev)

[PATCH 1/8] drm/sun4i: mark PM functions as __maybe_unused

Disabling CONFIG_PM produces a compile time warning when these functions are not referenced: drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:1072:12: error: 'sun6i_dsi_runtime_suspend' defined but not used [-Werror=unused-function] static int sun6i_dsi_runtime_suspend(struct device *dev)

Re: [PATCH] drm: check_pixel_format() should return true if no modifiers are passed for a supported pixel format

Hi Ayan, On Fri, May 25, 2018 at 04:35:41PM +0100, Ayan Kumar Halder wrote: If a plane supports a pixel format and the framebuffer does not pass any modifiers, then drm_plane_check_pixel_format() should always return true for the given format regardless of whether the plane supports any

Re: [PATCH] drm: check_pixel_format() should return true if no modifiers are passed for a supported pixel format

Hi Ayan, On Fri, May 25, 2018 at 04:35:41PM +0100, Ayan Kumar Halder wrote: If a plane supports a pixel format and the framebuffer does not pass any modifiers, then drm_plane_check_pixel_format() should always return true for the given format regardless of whether the plane supports any

Re: [PATCHv4 1/2] ARM: imx53: add secure-reg-access support for PMU

Hi Shawn, On Tue, Feb 27, 2018 at 11:17:12AM +0100, Sebastian Reichel wrote: > Hi, > > On Tue, Feb 27, 2018 at 09:10:34AM +0800, Shawn Guo wrote: > > On Mon, Feb 26, 2018 at 02:47:41PM +0100, Sebastian Reichel wrote: > > > On Sat, Feb 24, 2018 at 03:45:44PM +0800, Shawn Guo wrote: > > > > On

Re: [PATCHv4 1/2] ARM: imx53: add secure-reg-access support for PMU

Hi Shawn, On Tue, Feb 27, 2018 at 11:17:12AM +0100, Sebastian Reichel wrote: > Hi, > > On Tue, Feb 27, 2018 at 09:10:34AM +0800, Shawn Guo wrote: > > On Mon, Feb 26, 2018 at 02:47:41PM +0100, Sebastian Reichel wrote: > > > On Sat, Feb 24, 2018 at 03:45:44PM +0800, Shawn Guo wrote: > > > > On

Re: [PATCH v3 1/7] security: rename security_kernel_read_file() hook

On Thu, 24 May 2018, Eric W. Biederman wrote: > Below is where I suggest you start on sorting out these security hooks. > - Adding a security_kernel_arg to catch when you want to allow/deny the > use of an argument to a syscall. What security_kernel_file_read and >

Re: [PATCH v3 1/7] security: rename security_kernel_read_file() hook

On Thu, 24 May 2018, Eric W. Biederman wrote: > Below is where I suggest you start on sorting out these security hooks. > - Adding a security_kernel_arg to catch when you want to allow/deny the > use of an argument to a syscall. What security_kernel_file_read and >

Re: [PATCH 1/7] fs: allow per-device dax status checking for filesystems

On Thu, May 24, 2018 at 10:02:18PM -0700, Darrick J. Wong wrote: > On Thu, May 24, 2018 at 08:55:12PM -0600, Ross Zwisler wrote: > > From: "Darrick J. Wong" > > > > Remove __bdev_dax_supported and change to bdev_dax_supported that takes a > > bdev parameter. This

Re: [PATCH 1/7] fs: allow per-device dax status checking for filesystems

On Thu, May 24, 2018 at 10:02:18PM -0700, Darrick J. Wong wrote: > On Thu, May 24, 2018 at 08:55:12PM -0600, Ross Zwisler wrote: > > From: "Darrick J. Wong" > > > > Remove __bdev_dax_supported and change to bdev_dax_supported that takes a > > bdev parameter. This enables multi-device

[PATCH] staging: typec: rt1711h: fix tcpci dependency

Using 'select' instead of the normal 'depends on' causes a build issue with CONFIG_I2C=m: WARNING: unmet direct dependencies detected for TYPEC_TCPCI Depends on [m]: STAGING [=y] && TYPEC_TCPM [=y] && I2C [=m] Selected by [y]: - TYPEC_RT1711H [=y] && STAGING [=y] && TYPEC_TCPM [=y] Fixes:

[PATCH] staging: typec: rt1711h: fix tcpci dependency

Using 'select' instead of the normal 'depends on' causes a build issue with CONFIG_I2C=m: WARNING: unmet direct dependencies detected for TYPEC_TCPCI Depends on [m]: STAGING [=y] && TYPEC_TCPM [=y] && I2C [=m] Selected by [y]: - TYPEC_RT1711H [=y] && STAGING [=y] && TYPEC_TCPM [=y] Fixes:

Re: [PATCH -V2 -mm 0/4] mm, huge page: Copy target sub-page last when copy huge page

On Thu, 24 May 2018, Huang, Ying wrote: > If the cache contention is heavy when copying the huge page, and we > copy the huge page from the begin to the end, it is possible that the > begin of huge page is evicted from the cache after we finishing > copying the end of the huge page. And it is

Re: [PATCH -V2 -mm 0/4] mm, huge page: Copy target sub-page last when copy huge page

On Thu, 24 May 2018, Huang, Ying wrote: > If the cache contention is heavy when copying the huge page, and we > copy the huge page from the begin to the end, it is possible that the > begin of huge page is evicted from the cache after we finishing > copying the end of the huge page. And it is

[PATCH] KVM: x86: VMX: fix building without CONFIG_HYPERV

The global ms_hyperv variable is part of the hyperv support, so we get a link error from accessing it in kernels that have this turned off: arch/x86/kvm/vmx.o: In function `alloc_loaded_vmcs': vmx.c:(.text+0x1654a): undefined reference to `ms_hyperv' vmx.c:(.text+0x1657a): undefined reference to

[PATCH] staging: fsl-dpaa2/rtc: fix PTP dependency

We can't select PTP_1588_CLOCK when posix timers are completely disabled: WARNING: unmet direct dependencies detected for PTP_1588_CLOCK Depends on [n]: NET [=y] && POSIX_TIMERS [=n] Selected by [y]: - FSL_DPAA2_PTP_CLOCK [=y] && STAGING [=y] && FSL_DPAA2_ETH [=y] This adds the necessary

[PATCH] KVM: x86: VMX: fix building without CONFIG_HYPERV

The global ms_hyperv variable is part of the hyperv support, so we get a link error from accessing it in kernels that have this turned off: arch/x86/kvm/vmx.o: In function `alloc_loaded_vmcs': vmx.c:(.text+0x1654a): undefined reference to `ms_hyperv' vmx.c:(.text+0x1657a): undefined reference to

[PATCH] staging: fsl-dpaa2/rtc: fix PTP dependency

We can't select PTP_1588_CLOCK when posix timers are completely disabled: WARNING: unmet direct dependencies detected for PTP_1588_CLOCK Depends on [n]: NET [=y] && POSIX_TIMERS [=n] Selected by [y]: - FSL_DPAA2_PTP_CLOCK [=y] && STAGING [=y] && FSL_DPAA2_ETH [=y] This adds the necessary

[PATCH] drm: check_pixel_format() should return true if no modifiers are passed for a supported pixel format

If a plane supports a pixel format and the framebuffer does not pass any modifiers, then drm_plane_check_pixel_format() should always return true for the given format regardless of whether the plane supports any modifiers or not. Signed-off-by: Ayan Kumar Halder ---

[PATCH] drm: check_pixel_format() should return true if no modifiers are passed for a supported pixel format

If a plane supports a pixel format and the framebuffer does not pass any modifiers, then drm_plane_check_pixel_format() should always return true for the given format regardless of whether the plane supports any modifiers or not. Signed-off-by: Ayan Kumar Halder --- drivers/gpu/drm/drm_plane.c

[PATCH 3/8] xen/grant-table: Allow allocating buffers suitable for DMA

From: Oleksandr Andrushchenko Extend grant table module API to allow allocating buffers that can be used for DMA operations and mapping foreign grant references on top of those. The resulting buffer is similar to the one allocated by the balloon driver in terms

[PATCH 3/8] xen/grant-table: Allow allocating buffers suitable for DMA

From: Oleksandr Andrushchenko Extend grant table module API to allow allocating buffers that can be used for DMA operations and mapping foreign grant references on top of those. The resulting buffer is similar to the one allocated by the balloon driver in terms that proper memory reservation is

[PATCH 1/8] xen/grant-table: Make set/clear page private code shared

From: Oleksandr Andrushchenko Make set/clear page private code shared and accessible to other kernel modules which can re-use these instead of open-coding. Signed-off-by: Oleksandr Andrushchenko --- drivers/xen/grant-table.c

[PATCH 1/8] xen/grant-table: Make set/clear page private code shared

From: Oleksandr Andrushchenko Make set/clear page private code shared and accessible to other kernel modules which can re-use these instead of open-coding. Signed-off-by: Oleksandr Andrushchenko --- drivers/xen/grant-table.c | 54 +--

[PATCH] iio: adc: sun4i-gpadc: select REGMAP_IRQ

We can't call regmap_irq_get_virq() unless the regmap-irq support is enabled: drivers/iio/adc/sun4i-gpadc-iio.o: In function `sun4i_irq_init': sun4i-gpadc-iio.c:(.text+0x59c): undefined reference to `regmap_irq_get_virq' I came across this in a randconfig build now, but I guess this is a much

[PATCH] iio: adc: sun4i-gpadc: select REGMAP_IRQ

We can't call regmap_irq_get_virq() unless the regmap-irq support is enabled: drivers/iio/adc/sun4i-gpadc-iio.o: In function `sun4i_irq_init': sun4i-gpadc-iio.c:(.text+0x59c): undefined reference to `regmap_irq_get_virq' I came across this in a randconfig build now, but I guess this is a much

[PATCH 4/8] xen/gntdev: Allow mappings for DMA buffers

From: Oleksandr Andrushchenko Allow mappings for DMA backed buffers if grant table module supports such: this extends grant device to not only map buffers made of balloon pages, but also from buffers allocated with dma_alloc_xxx. Signed-off-by: Oleksandr

[PATCH 4/8] xen/gntdev: Allow mappings for DMA buffers

From: Oleksandr Andrushchenko Allow mappings for DMA backed buffers if grant table module supports such: this extends grant device to not only map buffers made of balloon pages, but also from buffers allocated with dma_alloc_xxx. Signed-off-by: Oleksandr Andrushchenko ---

[PATCH 2/8] xen/balloon: Move common memory reservation routines to a module

From: Oleksandr Andrushchenko Memory {increase|decrease}_reservation and VA mappings update/reset code used in balloon driver can be made common, so other drivers can also re-use the same functionality without open-coding. Create a dedicated module for the

[PATCH 2/8] xen/balloon: Move common memory reservation routines to a module

From: Oleksandr Andrushchenko Memory {increase|decrease}_reservation and VA mappings update/reset code used in balloon driver can be made common, so other drivers can also re-use the same functionality without open-coding. Create a dedicated module for the shared code and export corresponding

[PATCH 6/8] xen/gntdev: Implement dma-buf export functionality

From: Oleksandr Andrushchenko 1. Create a dma-buf from grant references provided by the foreign domain. By default dma-buf is backed by system memory pages, but by providing GNTDEV_DMA_FLAG_XXX flags it can also be created as a DMA

[PATCH 6/8] xen/gntdev: Implement dma-buf export functionality

From: Oleksandr Andrushchenko 1. Create a dma-buf from grant references provided by the foreign domain. By default dma-buf is backed by system memory pages, but by providing GNTDEV_DMA_FLAG_XXX flags it can also be created as a DMA write-combine/coherent buffer, e.g. allocated with

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