Re: [PATCH v7 1/6] fieldbus_dev: add Fieldbus Device subsystem.

On Thu 2019-01-24 13:07:58, Sven Van Asbroeck wrote: > On Tue, Jan 22, 2019 at 1:52 PM Greg KH wrote: > > > > SPDX "GPL-2.0+" please. > > > > > would be if this code was derived from v2-only code that can't be > > > relicensed anymore. > > > > Are you _sure_ you want v2+? I ask as I am forced to

Re: [PATCH] netfilter: xt_IDLETIMER: fix sysfs callback function type

On Wed, Feb 27, 2019 at 10:19:10AM -0800, Sami Tolvanen wrote: > Use struct device_attribute instead of struct idletimer_tg_attr, and > the correct callback function type to avoid indirect call mismatches > with Control Flow Integrity checking. Applied, thanks.

Re: [PATCH v2 03/13] mm: Add generic p?d_large() macros

On 01/03/2019 12:30, Kirill A. Shutemov wrote: > On Fri, Mar 01, 2019 at 01:53:01PM +0200, Mike Rapoport wrote: >> Him Kirill, >> >> On Fri, Feb 22, 2019 at 12:06:18AM +0300, Kirill A. Shutemov wrote: >>> On Thu, Feb 21, 2019 at 05:16:46PM +, Steven Price wrote: >> Note that in terms of the

Re: [PATCH] dt-bindings: irqchip: renesas-irqc: Document r8a774c0 support

On 01/03/2019 11:49, Fabrizio Castro wrote: > Hello Marc, > > I am sorry to bother you. > Do you think you can take this patch? It already missed the boat for the merge window, as I sent the pull request last week. Please resend it after -rc1, and I'll pick it up. Thanks, M. > > Thank

Re: [PATCH] arm64: dts: ls1088a: add one more thermal zone node

On Mon, Feb 25, 2019 at 11:00:49AM +0800, Yuantian Tang wrote: > Ls1088a has 2 thermal sensors. This patch adds the second node > to dts to enable it. Can you elaborate on these 2 thermal sensors/zones, ccu and plt? Shawn > > Signed-off-by: Yuantian Tang > --- > arch/arm64/boot/dts/freescale/

[PATCH] efi: Downgrade "EFI_MEMMAP is not enabled" message

Since 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when mapping the FB"), efifb_probe() checks its memory range via efi_mem_desc_lookup(), and this leads to a spurious error message "EFI_MEMMAP is not enabled" at every boot on KVM. This is quite annoying since the error message ap

[PATCH v2 0/4] add MaxBotix I2CXL ultrasonic iio driver

This patch series adds support for I2CXL-MaxSonar ultrasonic distance sensors of family mb12x2 using the i2c interface of vendor MaxBotix Implemented and tested functionality: - reading the distance via in_distance_raw - buffered mode with trigger - make use of status gpio to announce completi

[PATCH v2 1/4] dt-bindings: Add vendor prefix for MaxBotix

Add MaxBotix, which is a vendor of ultrasonic rangers in different varieties and interfaces. Signed-off-by: Andreas Klinger --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Docum

[PATCH v2 3/4] mb12x2.c: add distance iio sensor with i2c

Add I2CXL-MaxSonar ultrasonic distance sensors of type family mb12x2 using an i2c interface Implemented functionality: - reading the distance via in_distance_raw - buffered mode with trigger - make use of status gpio to announce completion of ranging Add mb12x2 driver to Kconfig and Makefile Sig

[PATCH v2 2/4] dt-bindings: maxbotix,i2cxl: Add MaxBotix i2c ultrasonic rangers

Add doc for dt binding maxbotix,i2cxl. This binding is for MaxBotix I2CXL-MaxSonar ultrasonic rangers which share a common i2c interface. Signed-off-by: Andreas Klinger --- .../bindings/iio/proximity/maxbotix,i2cxl.txt | 21 + 1 file changed, 21 insertions(+) create mo

[PATCH v2 4/4] MAINTAINERS: add maintainer for maxbotix ultrasonic driver

add a maintainer for the newly created ultrasonic driver family of maxbotix Signed-off-by: Andreas Klinger --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9919840d54cd..0807d9239e1a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9226,6 +

Re: [PATCH net 0/2] Use C45 Helpers when possible

On Fri, Mar 01, 2019 at 11:54:22AM +0100, Jose Abreu wrote: > For -net. Please review! Hi Jose Patches for net should have fixes: tags, making it clear what they fix, and how far back the patches should be ported. Thanks Andrew

RE: [PATCH] dt-bindings: irqchip: renesas-irqc: Document r8a774c0 support

Hello Marc > From: devicetree-ow...@vger.kernel.org On > Behalf Of Marc Zyngier > Sent: 01 March 2019 13:39 > Subject: Re: [PATCH] dt-bindings: irqchip: renesas-irqc: Document r8a774c0 > support > > On 01/03/2019 11:49, Fabrizio Castro wrote: > > Hello Marc, > > > > I am sorry to bother you. >

[git pull] m68k updates for 5.1

Hi Linus, The following changes since commit bfeffd155283772bbe78c6a05dec7c0128ee500c: Linux 5.0-rc1 (2019-01-06 17:08:20 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git tags/m68k-for-v5.1-tag1 for you to fetch chan

Re: [PATCH net 2/2] net: phy: Use C45 Helpers in PHY_FORCING state

On Fri, Mar 01, 2019 at 11:54:24AM +0100, Jose Abreu wrote: > +static inline int phy_update_link(struct phy_device *phydev) > +{ > + if (!phydev->drv) > + return -EIO; > + > + if (phydev->drv->read_status) > + return phydev->drv->read_status(phydev); > + else if

Re: [PATCH] perf/core: Mark expected switch fall-through

Em Thu, Feb 28, 2019 at 03:31:31PM -0600, Gustavo A. R. Silva escreveu: > Hi all, > > Friendly ping: > > Who can ack or review this, please? I'm applying it, thanks. - Arnaldo > Thanks > -- > Gustavo > > On 2/12/19 2:54 PM, Gustavo A. R. Silva wrote: > > In preparation to enabling -Wimplicit

Re: [PATCH] efi: Downgrade "EFI_MEMMAP is not enabled" message

On Fri, 1 Mar 2019 at 14:40, Takashi Iwai wrote: > > Since 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes > when mapping the FB"), efifb_probe() checks its memory range via > efi_mem_desc_lookup(), and this leads to a spurious error message > "EFI_MEMMAP is not enabled" at every boo

Re: [PATCH v4 4/4] hugetlb: allow to free gigantic pages regardless of the configuration

On 03/01/2019 02:33 PM, Vlastimil Babka wrote: On 3/1/19 2:21 PM, Alexandre Ghiti wrote: I collected mistakes here: domain name expired and no mailing list added :) Really sorry about that, I missed the whole discussion (if any). Could someone forward it to me (if any) ? Thanks ! Bounced you Da

Re: [GIT PULL] tee subsys fixes for v5.0

On Thu, Feb 28, 2019 at 1:32 PM Jens Wiklander wrote: > > Hello arm-soc maintainers, > > Please pull this last minute fix for the OP-TEE driver. Pulled into arm/fixes, thanks! Arnd

Re: [PATCH] efi: Downgrade "EFI_MEMMAP is not enabled" message

On Fri, 01 Mar 2019 14:53:39 +0100, Ard Biesheuvel wrote: > > On Fri, 1 Mar 2019 at 14:40, Takashi Iwai wrote: > > > > Since 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes > > when mapping the FB"), efifb_probe() checks its memory range via > > efi_mem_desc_lookup(), and this leads

Re: [GIT PULL] tee subsys for v5.1

On Thu, Feb 28, 2019 at 2:12 PM Jens Wiklander wrote: > > Hello arm-soc maintainers, > > Please pull these small TEE subsystem updates. The license for two .h > files in OP-TEE driver is clarified with a dual license. The kernel > space tee client interface is complemented with cancellation suppor

Re: [PATCH] efi: Downgrade "EFI_MEMMAP is not enabled" message

On Fri, 1 Mar 2019 at 15:01, Takashi Iwai wrote: > > On Fri, 01 Mar 2019 14:53:39 +0100, > Ard Biesheuvel wrote: > > > > On Fri, 1 Mar 2019 at 14:40, Takashi Iwai wrote: > > > > > > Since 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes > > > when mapping the FB"), efifb_probe() chec

[PATCH] crypto: s5p-sss - fix AES support for Exynos5433

Commit 0918f18c7179 ("crypto: s5p - add AES support for Exynos5433") introduced bug in dereferencing clk_names[1] on platforms different from Exynos5433. On Exynos board XU3 call trace is: "Unable to handle kernel paging request at virtual address 4000" (strcmp) from [] (of_property_match_stri

Re: [PATCH] ARM: pxa: remove CONFIG_SND_PXA2XX_AC97 in pxa_defconfig

On Wed, Feb 27, 2019 at 11:01 PM Robert Jarzmik wrote: > > Arnd Bergmann writes: > > > The CONFIG_SND_PXA2XX_AC97 driver is for the old AC97 bus implementation, > > and conflicts with all the new-style AC97 drivers after the conversion, > > so the drivers we want all get turned off. > > > > Not d

[PATCH 04/20] ARM/io: Remove useless definition of mmiowb()

ARM includes asm-generic/io.h, which provides a dummy definition of mmiowb() if one isn't already provided by the architecture. Remove the useless definition. Signed-off-by: Will Deacon --- arch/arm/include/asm/io.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/include/asm/io.h

[PATCH 02/20] arch: Use asm-generic header for asm/mmiowb.h

Hook up asm-generic/mmiowb.h to Kbuild for all architectures so that we can subsequently include asm/mmiowb.h from core code. Cc: Masahiro Yamada Cc: Arnd Bergmann Signed-off-by: Will Deacon --- arch/alpha/include/asm/Kbuild | 1 + arch/arc/include/asm/Kbuild| 1 + arch/arm/includ

[PATCH 00/20] Remove Mysterious Macro Intended to Obscure Weird Behaviours (mmiowb())

Hi everybody, This is a non-RFC posting of the RFC previously posted here: https://lwn.net/ml/linux-kernel/20190222185026.10973-1-will.dea...@arm.com/ There have been some significant changes since then, including: * Reduced mmiowb_spin_{lock,unlock}() overhead * Support for the arch code

[PATCH 03/20] mmiowb: Hook up mmiowb helpers to spinlocks and generic I/O accessors

Removing explicit calls to mmiowb() from driver code means that we must now call into the generic mmiowb_spin_{lock,unlock}() functions from the core spinlock code. In order to elide barriers following critical sections without any I/O writes, we also hook into the asm-generic I/O routines. Signed

[PATCH 10/20] mips/mmiowb: Add unconditional mmiowb() to arch_spin_unlock()

The mmiowb() macro is horribly difficult to use and drivers will continue to work most of the time if they omit a call when it is required. Rather than rely on driver authors getting this right, push mmiowb() into arch_spin_unlock() for mips. If this is deemed to be a performance issue, a subseque

[PATCH 01/20] asm-generic/mmiowb: Add generic implementation of mmiowb() tracking

In preparation for removing all explicit mmiowb() calls from driver code, implement a tracking system in asm-generic based loosely on the PowerPC implementation. This allows architectures with a non-empty mmiowb() definition to have the barrier automatically inserted in spin_unlock() following a cr

[PATCH 07/20] nds32/io: Remove useless definition of mmiowb()

mmiowb() only makes sense for SMP platforms, so we can remove it entirely for nds32. Signed-off-by: Will Deacon --- arch/nds32/include/asm/io.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/nds32/include/asm/io.h b/arch/nds32/include/asm/io.h index 71cd226d6863..5ef8ae5ba833 100644 -

[PATCH 09/20] sh/mmiowb: Add unconditional mmiowb() to arch_spin_unlock()

The mmiowb() macro is horribly difficult to use and drivers will continue to work most of the time if they omit a call when it is required. Rather than rely on driver authors getting this right, push mmiowb() into arch_spin_unlock() for sh. If this is deemed to be a performance issue, a subsequent

[PATCH 05/20] arm64/io: Remove useless definition of mmiowb()

arm64 includes asm-generic/io.h, which provides a dummy definition of mmiowb() if one isn't already provided by the architecture. Remove the useless definition. Signed-off-by: Will Deacon --- arch/arm64/include/asm/io.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm64/include/asm

[PATCH 06/20] x86/io: Remove useless definition of mmiowb()

x86 maps mmiowb() to barrier(), but this is superfluous because a compiler barrier is already implied by spin_unlock(). Since x86 also includes asm-generic/io.h in its asm/io.h file, we can remove the definition entirely and pick up the dummy definition from core code. Signed-off-by: Will Deacon

[PATCH 11/20] ia64/mmiowb: Add unconditional mmiowb() to arch_spin_unlock()

The mmiowb() macro is horribly difficult to use and drivers will continue to work most of the time if they omit a call when it is required. Rather than rely on driver authors getting this right, push mmiowb() into arch_spin_unlock() for ia64. If this is deemed to be a performance issue, a subseque

[PATCH 16/20] drivers: Remove explicit invocations of mmiowb()

mmiowb() is now implied by spin_unlock() on architectures that require it, so there is no reason to call it from driver code. This patch was generated using coccinelle: @mmiowb@ @@ - mmiowb(); and invoked as: $ for d in drivers include/linux/qed sound; do \ spatch --inclu

[PATCH 17/20] scsi/qla1280: Remove stale comment about mmiowb()

All mmiowb() invocations have been removed, so there's no need to keep banging on about it. Signed-off-by: Will Deacon --- drivers/scsi/qla1280.c | 10 -- 1 file changed, 10 deletions(-) diff --git a/drivers/scsi/qla1280.c b/drivers/scsi/qla1280.c index 93acbc5094f0..327eff67a1ee 100644

[PATCH 19/20] net/ethernet/silan/sc92031: Remove stale comment about mmiowb()

mmiowb() is no more. It has ceased to be. It is an ex-barrier. So remove all references to it from comments. Signed-off-by: Will Deacon --- drivers/net/ethernet/silan/sc92031.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/ethernet/silan/sc92031.c b/drivers/net/ethernet/silan/s

[PATCH 20/20] arch: Remove dummy mmiowb() definitions from arch code

Now that no driver code is using mmiowb() directly, we can remove the dummy definitions remaining in architectures that don't make use of asm-generic/io.h, as well as the definition in asm-generic/io,h itself. Signed-off-by: Will Deacon --- arch/alpha/include/asm/io.h | 2 -- arch/hexagon/

[PATCH 13/20] riscv/mmiowb: Hook up mmwiob() implementation to asm-generic code

In a bid to kill off explicit mmiowb() usage in driver code, hook up the asm-generic mmiowb() tracking code for riscv, so that an mmiowb() is automatically issued from spin_unlock() if an I/O write was performed in the critical section. Signed-off-by: Will Deacon --- arch/riscv/Kconfig

[PATCH 18/20] i40iw: Redefine i40iw_mmiowb() to do nothing

mmiowb() is now implicit in spin_unlock(), so there's no reason to call it from driver code. Redefine i40iw_mmiowb() to do nothing instead. Signed-off-by: Will Deacon --- drivers/infiniband/hw/i40iw/i40iw_osdep.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/infinib

[PATCH 15/20] drivers: Remove useless trailing comments from mmiowb() invocations

In preparation for using coccinelle to remove all mmiowb() instances from drivers, remove all trailing comments since they won't be picked up by spatch later on and will end up being preserved in the code. Signed-off-by: Will Deacon --- drivers/infiniband/hw/hfi1/chip.c| 2 +- dr

[PATCH 14/20] Documentation: Kill all references to mmiowb()

The guarantees provided by mmiowb() are now provided implicitly by spin_unlock(), so we can remove all references to this most confusing of barriers from our Documentation. Good riddance. Signed-off-by: Will Deacon --- Documentation/driver-api/device-io.rst | 45 -- Documentation/

[PATCH 08/20] m68k/io: Remove useless definition of mmiowb()

m68k includes asm-generic/io.h, which provides a dummy definition of mmiowb() if one isn't already provided by the architecture. Remove the useless definition. Acked-by: Geert Uytterhoeven Reviewed-by: Geert Uytterhoeven Signed-off-by: Will Deacon --- arch/m68k/include/asm/io_mm.h | 2 -- 1 f

[PATCH 12/20] powerpc/mmiowb: Hook up mmwiob() implementation to asm-generic code

In a bid to kill off explicit mmiowb() usage in driver code, hook up the asm-generic mmiowb() tracking code but provide a definition of arch_mmiowb_state() so that the tracking data can remain in the paca as it does at present This replaces the existing (flawed) implementation. Signed-off-by: Wil

Re: [GIT PULL] updates to soc/fsl drivers for v5.1 take4

On Wed, Feb 27, 2019 at 9:52 PM Li Yang wrote: > > Hi arm-soc maintainers, > > Since we are having a -rc8 for v5.0, please help to merge a few additional > patches for the upcoming merge window. Thanks Pulled into arm/drivers, thanks! Arnd

Re: [PATCH v2] Documentation/locking/lockdep: Drop last two chars of sample states

On Fri, Mar 01, 2019 at 10:40:52AM +0100, Geert Uytterhoeven wrote: > Since the removal of FS_RECLAIM annotations, lockdep states contain four > characters, not six. > > Fixes: e5684bbfc3f03480 ("Documentation/locking/lockdep: Update info about > states") > Fixes: d92a8cfcb37ecd13 ("locking/lockd

Re: [PATCH] efi: Downgrade "EFI_MEMMAP is not enabled" message

On Fri, 01 Mar 2019 15:02:23 +0100, Ard Biesheuvel wrote: > > On Fri, 1 Mar 2019 at 15:01, Takashi Iwai wrote: > > > > On Fri, 01 Mar 2019 14:53:39 +0100, > > Ard Biesheuvel wrote: > > > > > > On Fri, 1 Mar 2019 at 14:40, Takashi Iwai wrote: > > > > > > > > Since 38ac0287b7f4 ("fbdev/efifb: Hono

Re: [PATCH v2] perf util: Refactor time range parsing code

Em Fri, Mar 01, 2019 at 06:13:06PM +0800, Jin Yao escreveu: > Jiri points out that we don't need any time checking and time string > parsing if the --time option is not set. That makes sense. > > This patch refactors the time range parsing code, move the duplicated > code from perf report and perf

Re: [PATCH net-next v2 2/3] net: phy: marvell10g: add the suspend/resume callbacks for the 88x2210

On Fri, Mar 01, 2019 at 12:00:46PM +0100, Antoine Tenart wrote: > When the 88x2110 PHY support was added, the suspend and resume callbacks > were forgotten. This patch adds them to the 88x2110 PHY callback > definition. > > Signed-off-by: Antoine Tenart Reviewed-by: Andrew Lunn Andrew

Re: [PATCH v6 1/3] PCI: altera: Add Stratix 10 PCIe support

On Fri, Mar 01, 2019 at 08:50:48AM +0800, Ley Foon Tan wrote: > On Thu, 2019-02-28 at 10:56 +, Lorenzo Pieralisi wrote: > > On Thu, Feb 28, 2019 at 06:52:50PM +0800, Ley Foon Tan wrote: > > > > [...] > > > > > > > > +static int s10_tlp_read_packet(struct altera_pcie *pcie, u32 > > > *value)

Re: [PATCH net-next v2 1/3] net: phy: marvell10g: implement suspend/resume callbacks

On Fri, Mar 01, 2019 at 12:00:45PM +0100, Antoine Tenart wrote: > This patch adds the suspend/resume callbacks for Marvell 10G PHYs. The > three PCS (base-t, base-r and 1000base-x) are set in low power (the PCS > are powered down) when the PHY isn't used. > > Signed-off-by: Antoine Tenart Review

Re: [PATCH net-next v2 3/3] net: phy: marvell10g: set the PHY in low power by default

On Fri, Mar 01, 2019 at 12:00:47PM +0100, Antoine Tenart wrote: > When the Marvell 10G PHYs are set out of reset, the LPOWER bit is set > depending on an hardware configuration choice. We also do not know what > is the PHY state at boot time. Hence, set the PHY in low power by > default when this d

Re: [PATCH] crypto: s5p-sss - fix AES support for Exynos5433

On Fri, 1 Mar 2019 at 15:03, Kamil Konieczny wrote: > > Commit 0918f18c7179 ("crypto: s5p - add AES support for Exynos5433") > introduced bug in dereferencing clk_names[1] on platforms different from > Exynos5433. On Exynos board XU3 call trace is: > > "Unable to handle kernel paging request at vi

[PATCH] regulator: palmas: Constify palmas_smps_ramp_delay array

The palmas_smps_ramp_delay array should never modify, make it const. Signed-off-by: Axel Lin --- drivers/regulator/palmas-regulator.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/regulator/palmas-regulator.c b/drivers/regulator/palmas-regulator.c index c2cc392a27d

[PATCH v2] powerpc/mm: fix "section_base" set but not used

The commit 24b6d4164348 ("mm: pass the vmem_altmap to vmemmap_free") removed a line in vmemmap_free(), altmap = to_vmem_altmap((unsigned long) section_base); but left a variable no longer used. arch/powerpc/mm/init_64.c: In function 'vmemmap_free': arch/powerpc/mm/init_64.c:277:16: error: variab

[PATCH] regulator: mc13xxx: Constify regulator_ops variables

These regulator_ops variables should never change, make them const. Signed-off-by: Axel Lin --- drivers/regulator/mc13783-regulator.c | 4 ++-- drivers/regulator/mc13892-regulator.c | 8 drivers/regulator/mc13xxx-regulator-core.c | 4 ++-- drivers/regulator/mc13xxx.h

Re: [PATCH] drm/virtio: Allow userspace to mmap() framebuffer

On Fri, 2019-03-01 at 06:51 +0100, Gerd Hoffmann wrote: > On Thu, Feb 28, 2019 at 10:47:41AM -0600, Joshua Watt wrote: > > Reports the size of the virtgpu framebuffer to userspace and > > installs > > the deferred I/O handlers so that userspace can mmap() and write to > > it. > > Fixed already, as

Re: [PATCH v7 1/6] fieldbus_dev: add Fieldbus Device subsystem.

On Fri, Mar 01, 2019 at 02:34:56PM +0100, Pavel Machek wrote: > > > > > > > > >> + > > > >> +MODULE_AUTHOR("Sven Van Asbroeck "); > > > >> +MODULE_AUTHOR("Jonathan Stiles "); > > > >> +MODULE_DESCRIPTION("Fieldbus Device Driver Core"); > > > >> +MODULE_LICENSE("GPL v2"); > > > > > > Sven, as thi

Re: [PATCH] net: mvpp2: avoid bouncing buffers

Hi Christoph, I saw you sent this patch as part of another series back in August, but it seems it was never applied and I can't find it even in -next. We made some tests and this patch is helping a lot the PPv2 engine driver in improving its performances. Do you plan on re-sending it, or reworkin

Re: [PATCH] cxgb4: fix undefined behavior in mem.c

On Thu, 2019-02-28 at 16:57 -0700, Shaobo He wrote: > Good catch. But if we agree on that memory management functions are those > specified by the C standard, would it be OK to ignore so-called use after > free > or double free bugs for the kernel as C standard does not apply to kfree? No, most

[PATCH] usb: core: make default autosuspend delay configurable

Make the default autosuspend delay configurable at build time. This is useful for systems that require a non-standard value as it avoids relying on the command line being properly set. Signed-off-by: Mans Rullgard --- drivers/usb/core/Kconfig | 8 drivers/usb/core/usb.c | 4 ++-- 2 fi

[PATCH] Coding style fixes on vme_user.c trivial

drivers/staging/devices: Coding style fixes found at file vme_user.c. Signed-off-by: Oryan Perlmutter --- drivers/staging/vme/devices/vme_user.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/vme/devices/vme_user.c b/drivers/staging/vme/devices/vme_user.c in

Re: [PATCH v3 bus+gpio 3/5] bus: moxtet: Add sysfs documentation

On Fri, Mar 1, 2019 at 4:59 AM Marek Behún wrote: > Add sysfs ABI documentation for the attribute files module_id, > module_name, input_value and output_value of Moxtet devices. > > Signed-off-by: Marek Behún (...) > +++ b/Documentation/ABI/testing/sysfs-bus-moxtet-devices > @@ -0,0 +1,25 @@ >

Re: [PATCH] regulator: lp87565: Convert to use regulator_set/get_current_limit_regmap

kbuild test robot 於 2019年3月1日 週五 下午7:32寫道： > > Hi Axel, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on regulator/for-next] > [also build test ERROR on next-20190228] > [cannot apply to v5.0-rc8] > [if your patch is applied to the wrong git tree, please drop us

Re: [PATCH v4 00/10] Add basic support for Socionext Milbeaut M10V SoC

On Wed, Feb 27, 2019 at 5:51 AM Sugaya Taichi wrote: > > Hi, > > Here is the series of patches the initial support for SC2000(M10V) of > Milbeaut SoCs. "M10V" is the internal name of SC2000, so commonly used in > source code. > > SC2000 is a SoC of the Milbeaut series. equipped with a DSP optimize

Re: [PATCH v3 bus+gpio 5/5] dt-bindings: gpio: Document GPIOs via Moxtet bus

On Fri, Mar 1, 2019 at 4:59 AM Marek Behún wrote: > This patch adds documentation of the device tree bindings for GPIOs > on the devices connected via Moxtet bus. > > Signed-off-by: Marek Behún > Cc: Rob Herring > Cc: devicet...@vger.kernel.org Reviewed-by: Linus Walleij > + co

Re: [PATCH] ARM: sun8i: h3: bluetooth for Banana Pi M2 Zero board

Hi, Thanks for your patch On Thu, Feb 28, 2019 at 10:28:40PM +0100, Andreas Kemnade wrote: > The Banana Pi M2 Zero board has an AP6212 BT+Wifi combo chip > with broadcom internals attached to UART1 and some gpios. > This addition is in line with similar boards > > Signed-off-by: Andreas Kemnade

Re: [PATCH 6/8] i915,uaccess: Fix redundant CLAC

On Fri, Mar 01, 2019 at 01:57:18PM +0100, Peter Zijlstra wrote: > On Fri, Mar 01, 2019 at 01:27:45PM +0100, Peter Zijlstra wrote: > > arch/x86/lib/usercopy_64.o: warning: objtool: .altinstr_replacement+0x30: > > redundant UACCESS disable > > > The usercopy one is difficult, that's copy_user_handl

[PATCH v2] memcg: fix a bad line

The commit 230671533d64 ("mm: memory.low hierarchical behavior") missed an asterisk in one of the comments. mm/memcontrol.c:5774: warning: bad line:| 0, otherwise. Acked-by: Souptick Joarder Signed-off-by: Qian Cai --- v2: improve the commit message. mm/memcontrol.c | 2 +- 1

Re: [PATCH 2/3] mm: separate memory allocation and actual work in alloc_vmap_area()

On 2/25/19 9:30 PM, Roman Gushchin wrote: > alloc_vmap_area() is allocating memory for the vmap_area, and > performing the actual lookup of the vm area and vmap_area > initialization. > > This prevents us from using a pre-allocated memory for the map_area > structure, which can be used in some cas

Re: [PATCH] soc: sunxi: Fix missing dependency on REGMAP_MMIO

On Thu, Feb 28, 2019 at 08:20:44PM -0600, Samuel Holland wrote: > When enabling ARCH_SUNXI from allnoconfig, SUNXI_SRAM is enabled, but > not REGMAP_MMIO, so the kernel fails to link with an undefined reference > to __devm_regmap_init_mmio_clk. Select REGMAP_MMIO, as suggested in > drivers/base/reg

Re: [PATCH v2 0/2] x86/mm/KASLR: Change the granularity of randomization to PUD size in 5-level

Hi Kirill, I updated patch per your comments. While I kept the 'paddr' variable and the '0' initilization stuffs. My thought is there are two kinds of mapping in the handling, so keeping these names from old codes can make it more understandable. What do you think? Kind Physical add

Re: [PATCH 1/8] kasan,x86: Frob kasan_report() in an exception

On Thu, Feb 28, 2019 at 04:22:04PM +0100, Dmitry Vyukov wrote: > On Thu, Feb 28, 2019 at 4:05 PM Peter Zijlstra wrote: > > > > Because __asan_{load,store}{N,1,2,4,8,16}_noabort() get called from > > UACCESS context, and kasan_report() is most definitely _NOT_ safe to > > be called from there, move

Re: [PATCH] fbdev: omap2: fix warnings in dss core

On 02/13/2019 09:47 AM, Anders Roxell wrote: > Commit 60d2fa0dad06 ("fbdev: omap2: no need to check return value of > debugfs_create functions") changed the declaration of the return value > of function dss_debugfs_create_file() and the following two warnings > appeared: > > drivers/video/fbdev/

Re: [PATCH v2 00/10] Allwinner sunxi message box support

Hi On Thu, Feb 28, 2019 at 11:29:37PM -0600, Samuel Holland wrote: > This series adds support for the "hardware message box" in sun8i, sun9i, > and sun50i SoCs, used for communication with the ARISC management > processor (the platform's equivalent of the ARM SCP). The end goal is to > use the arm

Re: [PATCH -next] fbdev: omap2: omapfb: trivial code cleanup

Hi, On 03/01/2019 02:53 AM, Yue Haibing wrote: > From: YueHaibing > > After commit 60d2fa0dad06 ("fbdev: omap2: no need to check > return value of debugfs_create functions"), there are corner > code need to be cleaned. > > Signed-off-by: YueHaibing Thanks but I've already applied earlier pa

[RFC] sched/fair: hard lockup in sched_cfs_period_timer

Hi, I have a reproducible case of this: [ 217.264946] NMI watchdog: Watchdog detected hard LOCKUP on cpu 24 [ 217.264948] Modules linked in: sunrpc iTCO_wdt gpio_ich iTCO_vendor_support intel_powerclamp coretemp kvm_intel kvm ipmi_ssif irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_in

Re: [PATCH v5 2/2] i2c: designware: Add support for an interface clock

On 2/28/19 3:52 PM, Gareth Williams wrote: From: Phil Edworthy The Synopsys I2C Controller has an interface clock, but most SoCs hide this away. However, on some SoCs you need to explicitly enable the interface clock in order to access the registers. Therefore, add support for an optional inter

Re: [PATCH v2] net: cpsw: fix obtaining mac address for am3517

Tony Lindgren writes: > * Jeroen Hofstee [161028 11:19]: >> Hello Tony, >> >> On 28-10-16 17:52, Tony Lindgren wrote: >> > * Jeroen Hofstee [161028 08:33]: >> > > Commit b6745f6e4e63 ("drivers: net: cpsw: davinci_emac: move reading mac >> > > id to common file") did not only move the code for

[PATCH] pstore: automatically dump and clean dmesg entries

From: Torsten Duwe Dump a previous oops or panic, which has made it to pstore, to the new syslog after reboot, optionally deleting it. This can happen automatically, without user land interaction. Signed-off-by: Torsten Duwe CC: Thomas Renninger --- fs/pstore/inode.c| 6 +++--- fs/pstor

Re: [PATCH v3 3/8] KVM:CPUID: Add CPUID support for Guest CET

On Thu, Feb 28, 2019 at 04:28:32PM +0800, Yang Weijiang wrote: > On Thu, Feb 28, 2019 at 07:59:40AM -0800, Sean Christopherson wrote: > > On Mon, Feb 25, 2019 at 09:27:11PM +0800, Yang Weijiang wrote: > > > Guest CET SHSTK and IBT capability are reported via > > > CPUID.(EAX=7, ECX=0):ECX[bit 7] an

Re: [PATCH 2/2] seccomp.2: document userspace notification

On Thu, Feb 28, 2019 at 01:52:19PM +0100, Michael Kerrisk (man-pages) wrote: > > +a notification will be sent to this fd. See "Userspace Notification" below > > for > > s/fd/file descriptor/ throughout please. Will do. > > +more details. > > I think the description here could be better worded

Re: [PATCH 2/2] seccomp.2: document userspace notification

On Thu, Feb 28, 2019 at 02:25:55PM +0100, Michael Kerrisk (man-pages) wrote: > > 7. The monitoring process can use the information in the > >'struct seccomp_notif' to make a determination about the > >system call being made by the target process. This > >structure includes a 'data' fiel

[PATCH net] net: sit: fix memory leak in sit_init_net()

If register_netdev() is failed to register sitn->fb_tunnel_dev, it will go to err_reg_dev and forget to free netdev(sitn->fb_tunnel_dev). BUG: memory leak unreferenced object 0x888378daad00 (size 512): comm "syz-executor.1", pid 4006, jiffies 4295121142 (age 16.115s) hex dump (first 32 byt

Re: [PATCH] drm/vkms: Solve bug on kms_crc_cursor tests

Em qui, 28 de fev de 2019 às 11:03, Ville Syrjälä escreveu: > > On Thu, Feb 28, 2019 at 11:11:07AM +0100, Daniel Vetter wrote: > > On Mon, Feb 25, 2019 at 11:26:06AM -0300, Shayenne Moura wrote: > > > vkms_crc_work_handle needs the value of the actual frame to > > > schedule the workqueue that cal

pull-request: wireless-drivers-next 2019-03-01

Hi Dave, as Linus gave us one more week here are few more patches to net-next for 5.1. Please let me know if there are any problems. Kalle The following changes since commit bd16693f359bbab8776541c06a6df32f3996638e: net: fix double-free in bpf_lwt_xmit_reroute (2019-02-24 22:24:50 -0800) are

Re: [PATCH] efi: Downgrade "EFI_MEMMAP is not enabled" message

On Fri, 1 Mar 2019 at 15:14, Takashi Iwai wrote: > > On Fri, 01 Mar 2019 15:02:23 +0100, > Ard Biesheuvel wrote: > > > > On Fri, 1 Mar 2019 at 15:01, Takashi Iwai wrote: > > > > > > On Fri, 01 Mar 2019 14:53:39 +0100, > > > Ard Biesheuvel wrote: > > > > > > > > On Fri, 1 Mar 2019 at 14:40, Takash

Re: [PATCH 2/2] arm64: allwinner: a64: Add Oceanic A64-5inMFD initial support

On Wed, Feb 27, 2019 at 09:49:23PM +0530, Jagan Teki wrote: > On Wed, Feb 27, 2019 at 9:03 PM Maxime Ripard > wrote: > > > > Hi, > > > > On Tue, Feb 26, 2019 at 11:32:40AM +0530, Jagan Teki wrote: > > > Oceanic A64-5inMFD is a 5 inch Multi function display baseboard > > > designed to mount SoPine

Re: [PATCH v3 6/8] KVM:VMX: Load Guest CET via VMCS when CET is enabled in Guest

On Thu, Feb 28, 2019 at 04:38:44PM +0800, Yang Weijiang wrote: > On Thu, Feb 28, 2019 at 08:17:15AM -0800, Sean Christopherson wrote: > > On Mon, Feb 25, 2019 at 09:27:14PM +0800, Yang Weijiang wrote: > > > "Load Guest CET state" bit controls whether guest CET states > > > will be loaded at Guest e

Re: [PATCH] pstore: automatically dump and clean dmesg entries

On Friday, March 1, 2019 3:53:25 PM CET Thomas Renninger wrote: > From: Torsten Duwe > > Dump a previous oops or panic, which has made it to pstore, > to the new syslog after reboot, optionally deleting it. > This can happen automatically, without user land interaction. > > Signed-off-by: Torste

[PATCH 5/4] soc/fsl/qe: qe.c: fold qe_get_num_of_snums into qe_snums_init

The comment "No QE ever has fewer than 28 SNUMs" is false; e.g. the MPC8309 has 14. The code path returning -EINVAL is also a recipe for instant disaster, since the caller (qe_snums_init) uncritically assigns the return value to the unsigned qe_num_of_snum, and would thus proceed to attempt to copy

[PATCH v2] scsi: smartpqi_init: Reporting 'logical unit failure'

When the HARDWARE_ERROR/0x3e/0x1 case is triggered, the logical volume is offlined. When reading the kernel log, the reason why the device got offlined isn't reported to the user. This situation makes difficult for admins to estimate the root cause of the issue they analize. Reading this part o

Re: [PATCH 0/3] drm/sun4i: DE2/DE3 improvements

On Thu, Feb 28, 2019 at 09:03:26PM +0100, Jernej Skrabec wrote: > DE2 and DE3 VI channels support coarse scaling to overcome VI scaler > limitations. That is especially useful for downscaling big planes, for > example 4K to 1080p. > > Following patches were tested on H3 and A64 with 4K video playb

Re: [PATCH] scsi: smartpqi_init: Reporting 'logical unit failure'

[...] > Be careful printing errors per-IO; you could get thousands of them if things > go bad. > The block layer print_req_error() uses printk_ratelimited(KERN_ERR) for that > reason, > and the SCSI layer scsi_io_completion_action() maintains a ratelimit on its > own. > > The dev_err_ratelimited

[GIT PULL] dtype handling cleanup for v5.1-rc1

Hello Linus, could you please pull from git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git dtype_for_v5.1-rc1 to get a reworked version of the dtype cleanup patches based on your feedback to the previous version of these. Again the series includes only the generic code and ext2

Re: [PATCH] can: ti_hecc: fix close when napi poll is active

Jeroen Hofstee writes: > When closing this CAN interface while napi poll is active, for example with: > `ip link set can0 down` several interfaces freeze. This seemed to be caused > by napi_disable called from ti_hecc_close expecting the scheduled probe to > either return quota or call napi_compl

Re: [PATCH 3/3] mm: show number of vmalloc pages in /proc/meminfo

On 2/25/19 9:30 PM, Roman Gushchin wrote: > Vmalloc() is getting more and more used these days (kernel stacks, > bpf and percpu allocator are new top users), and the total % > of memory consumed by vmalloc() can be pretty significant > and changes dynamically. > > /proc/meminfo is the best place t

Re: [PATCH 1/8] kasan,x86: Frob kasan_report() in an exception

On Fri, Mar 1, 2019 at 3:46 PM Peter Zijlstra wrote: > > On Thu, Feb 28, 2019 at 04:22:04PM +0100, Dmitry Vyukov wrote: > > On Thu, Feb 28, 2019 at 4:05 PM Peter Zijlstra wrote: > > > > > > Because __asan_{load,store}{N,1,2,4,8,16}_noabort() get called from > > > UACCESS context, and kasan_report

Re: [PATCH net-next v2 3/3] net: phy: marvell10g: set the PHY in low power by default

Hi Andrew, On Fri, Mar 01, 2019 at 03:19:53PM +0100, Andrew Lunn wrote: > On Fri, Mar 01, 2019 at 12:00:47PM +0100, Antoine Tenart wrote: > > When the Marvell 10G PHYs are set out of reset, the LPOWER bit is set > > depending on an hardware configuration choice. We also do not know what > > is the

<    1   2   3   4   5   6   7   8   >