Re: [PATCH] scripts/dtc: consolidate include path options in Makefile
Hi Rob, 2018-07-04 10:59 GMT+09:00 Masahiro Yamada : > It is tedious to specify extra compiler options for every file. > HOST_EXTRACFLAGS is useful to add options to all files in a > directory. > > -I$(src)/libfdt is needed for all the files in this directory > to include libfdt_env.h etc. from scripts/dtc/libfdt/. > > On the other hand, -I$(src) is used to include check-in headers > from generated C files. Thus, I added it only to dtc-lexer.lex.o > and dtc-parser.tab.o . > > Signed-off-by: Masahiro Yamada I hope this is a good clean-up. May I apply this to my kbuild tree for v4.19 ? > --- > > scripts/dtc/Makefile | 18 -- > 1 file changed, 4 insertions(+), 14 deletions(-) > > diff --git a/scripts/dtc/Makefile b/scripts/dtc/Makefile > index 9cac65b..1c943e0 100644 > --- a/scripts/dtc/Makefile > +++ b/scripts/dtc/Makefile > @@ -9,21 +9,11 @@ dtc-objs := dtc.o flattree.o fstree.o data.o > livetree.o treesource.o \ > dtc-objs += dtc-lexer.lex.o dtc-parser.tab.o > > # Source files need to get at the userspace version of libfdt_env.h to > compile > +HOST_EXTRACFLAGS := -I$(src)/libfdt > > -HOSTCFLAGS_DTC := -I$(src) -I$(src)/libfdt > - > -HOSTCFLAGS_checks.o := $(HOSTCFLAGS_DTC) > -HOSTCFLAGS_data.o := $(HOSTCFLAGS_DTC) > -HOSTCFLAGS_dtc.o := $(HOSTCFLAGS_DTC) > -HOSTCFLAGS_flattree.o := $(HOSTCFLAGS_DTC) > -HOSTCFLAGS_fstree.o := $(HOSTCFLAGS_DTC) > -HOSTCFLAGS_livetree.o := $(HOSTCFLAGS_DTC) > -HOSTCFLAGS_srcpos.o := $(HOSTCFLAGS_DTC) > -HOSTCFLAGS_treesource.o := $(HOSTCFLAGS_DTC) > -HOSTCFLAGS_util.o := $(HOSTCFLAGS_DTC) > - > -HOSTCFLAGS_dtc-lexer.lex.o := $(HOSTCFLAGS_DTC) > -HOSTCFLAGS_dtc-parser.tab.o := $(HOSTCFLAGS_DTC) > +# Generated files need one more search path to include headers in source tree > +HOSTCFLAGS_dtc-lexer.lex.o := -I$(src) > +HOSTCFLAGS_dtc-parser.tab.o := -I$(src) > > # dependencies on generated files need to be listed explicitly > $(obj)/dtc-lexer.lex.o: $(obj)/dtc-parser.tab.h > -- > 2.7.4 > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Best Regards Masahiro Yamada
Re: [PATCH v2 1/3] arm64: implement ftrace with regs
On 17 August 2018 at 12:27, Torsten Duwe wrote: > Check for compiler support of -fpatchable-function-entry and use it > to intercept functions immediately on entry, saving the LR in x9. Could you please add a note that this is safe because IPA register allocation is turned off as well by that option? I had to go and find the GCC patches to confirm that this is the case. > Disable ftracing in efi/libstub, because this triggers cross-section > linker errors now (-pg is disabled already for those files). > Add an ftrace_caller which can handle LR in x9, as well as an > ftrace_regs_caller that additionally writes out a set of pt_regs > for inspection. > > Signed-off-by: Torsten Duwe > > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -110,6 +110,7 @@ config ARM64 > select HAVE_DEBUG_KMEMLEAK > select HAVE_DMA_CONTIGUOUS > select HAVE_DYNAMIC_FTRACE > + select HAVE_DYNAMIC_FTRACE_WITH_REGS > select HAVE_EFFICIENT_UNALIGNED_ACCESS > select HAVE_FTRACE_MCOUNT_RECORD > select HAVE_FUNCTION_TRACER > --- a/arch/arm64/Makefile > +++ b/arch/arm64/Makefile > @@ -78,6 +78,15 @@ ifeq ($(CONFIG_ARM64_MODULE_PLTS),y) > KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/arm64/kernel/module.lds > endif > > +ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS > + CC_FLAGS_FTRACE := -fpatchable-function-entry=2 > + KBUILD_CPPFLAGS += -DCC_USING_PATCHABLE_FUNCTION_ENTRY > + ifeq ($(call cc-option,-fpatchable-function-entry=2),) > +$(error Cannot use CONFIG_DYNAMIC_FTRACE_WITH_REGS: \ > + -fpatchable-function-entry not supported by compiler) > + endif > +endif > + > # Default value > head-y := arch/arm64/kernel/head.o > > --- a/arch/arm64/include/asm/ftrace.h > +++ b/arch/arm64/include/asm/ftrace.h > @@ -16,6 +16,13 @@ > #define MCOUNT_ADDR((unsigned long)_mcount) > #define MCOUNT_INSN_SIZE AARCH64_INSN_SIZE > > +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS > +#define ARCH_SUPPORTS_FTRACE_OPS 1 > +#define REC_IP_BRANCH_OFFSET 4 > +#else > +#define REC_IP_BRANCH_OFFSET 0 > +#endif > + > #ifndef __ASSEMBLY__ > #include > > --- a/arch/arm64/kernel/Makefile > +++ b/arch/arm64/kernel/Makefile > @@ -7,9 +7,9 @@ CPPFLAGS_vmlinux.lds:= -DTEXT_OFFSET=$( > AFLAGS_head.o := -DTEXT_OFFSET=$(TEXT_OFFSET) > CFLAGS_armv8_deprecated.o := -I$(src) > > -CFLAGS_REMOVE_ftrace.o = -pg > -CFLAGS_REMOVE_insn.o = -pg > -CFLAGS_REMOVE_return_address.o = -pg > +CFLAGS_REMOVE_ftrace.o = -pg $(CC_FLAGS_FTRACE) > +CFLAGS_REMOVE_insn.o = -pg $(CC_FLAGS_FTRACE) > +CFLAGS_REMOVE_return_address.o = -pg $(CC_FLAGS_FTRACE) > > # Object file lists. > arm64-obj-y:= debug-monitors.o entry.o irq.o fpsimd.o > \ > --- a/drivers/firmware/efi/libstub/Makefile > +++ b/drivers/firmware/efi/libstub/Makefile > @@ -11,7 +11,8 @@ cflags-$(CONFIG_X86) += -m$(BITS) -D__K >-fPIC -fno-strict-aliasing -mno-red-zone \ >-mno-mmx -mno-sse -fshort-wchar > > -cflags-$(CONFIG_ARM64) := $(subst -pg,,$(KBUILD_CFLAGS)) -fpie > +cflags-$(CONFIG_ARM64) := $(filter-out -pg $(CC_FLAGS_FTRACE)\ > + ,$(KBUILD_CFLAGS)) -fpie > cflags-$(CONFIG_ARM) := $(subst -pg,,$(KBUILD_CFLAGS)) \ >-fno-builtin -fpic -mno-single-pic-base > > --- a/arch/arm64/kernel/entry-ftrace.S > +++ b/arch/arm64/kernel/entry-ftrace.S > @@ -13,6 +13,8 @@ > #include > #include > #include > +#include > +#include > > /* > * Gcc with -pg will put the following code in the beginning of each > function: > @@ -123,6 +125,7 @@ skip_ftrace_call: // } > ENDPROC(_mcount) > > #else /* CONFIG_DYNAMIC_FTRACE */ > +#ifndef CC_USING_PATCHABLE_FUNCTION_ENTRY > /* > * _mcount() is used to build the kernel with -pg option, but all the branch > * instructions to _mcount() are replaced to NOP initially at kernel start > up, > @@ -162,6 +165,88 @@ ftrace_graph_call: // ftrace_graph_cal > > mcount_exit > ENDPROC(ftrace_caller) > +#else /* CC_USING_PATCHABLE_FUNCTION_ENTRY */ > +ENTRY(_mcount) > + mov x10, lr > + mov lr, x9 > + ret x10 > +ENDPROC(_mcount) > + > +ENTRY(ftrace_regs_caller) > + stp x29, x9, [sp, #-16]! > + sub sp, sp, #S_FRAME_SIZE > + > + stp x10, x11, [sp, #80] > + stp x12, x13, [sp, #96] > + stp x14, x15, [sp, #112] > + stp x16, x17, [sp, #128] > + stp x18, x19, [sp, #144] > + stp x20, x21, [sp, #160] > + stp x22, x23, [sp, #176] > + stp x24, x25, [sp, #192] > + stp x26, x27, [sp, #208] > + Any reason in particular this stack frame is the wrong way around? We usually keep the frame pointer at the top. > + b ftrace_common > +ENDPROC(ftrace_regs_caller) > + > +ENTRY(ftrace_caller) > + stp x29, x9, [sp, #
Re: [RESEND PATCH v10 1/6] arm: arm64: introduce CONFIG_HAVE_MEMBLOCK_PFN_VALID
On 8/17/2018 10:50 PM, Catalin Marinas Wrote: > On Fri, Jul 06, 2018 at 05:01:10PM +0800, Jia He wrote: >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >> index 42c090c..26d75f4 100644 >> --- a/arch/arm64/Kconfig >> +++ b/arch/arm64/Kconfig >> @@ -778,6 +778,10 @@ config ARCH_SELECT_MEMORY_MODEL >> config HAVE_ARCH_PFN_VALID >> def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM >> >> +config HAVE_MEMBLOCK_PFN_VALID >> +def_bool y >> +depends on HAVE_ARCH_PFN_VALID >> + >> config HW_PERF_EVENTS >> def_bool y >> depends on ARM_PMU >> diff --git a/mm/Kconfig b/mm/Kconfig >> index 94af022..28fcf54 100644 >> --- a/mm/Kconfig >> +++ b/mm/Kconfig >> @@ -137,6 +137,9 @@ config HAVE_MEMBLOCK_NODE_MAP >> config HAVE_MEMBLOCK_PHYS_MAP >> bool >> >> +config HAVE_MEMBLOCK_PFN_VALID >> +bool > > Since you defined HAVE_MEMBLOCK_PFN_VALID here, do we need to define it > in the arch code as well? If kept it in the mm/Kconfig only, you could > just select it in the arch HAVE_ARCH_PFN_VALID entry: > Ok, thanks for the comments It makes it more clean. -- Cheers, Jia > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index d0a53cc6293a..cd230c77e122 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -787,6 +787,7 @@ config ARCH_FLATMEM_ENABLE > > config HAVE_ARCH_PFN_VALID > def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM > + select HAVE_MEMBLOCK_PFN_VALID > > config HW_PERF_EVENTS > def_bool y > > (similarly for arch/arm) >
Re: [RFC PATCH 1/6] Revert "PCI: Fix is_added/is_busmaster race condition"
On Mon, Aug 20, 2018 at 7:40 AM, Benjamin Herrenschmidt wrote: > On Sat, 2018-08-18 at 21:24 -0500, Bjorn Helgaas wrote: >> On Sat, Aug 18, 2018 at 01:24:51PM +1000, Benjamin Herrenschmidt wrote: >> > On Fri, 2018-08-17 at 10:44 -0500, Bjorn Helgaas wrote: >> > > On Fri, Aug 17, 2018 at 02:48:57PM +1000, Benjamin Herrenschmidt wrote: >> > > > This reverts commit 44bda4b7d26e9fffed6d7152d98a2e9edaeb2a76. >> > > >> > > Just to be clear, if I understand correctly, this is a pure revert of >> > > 44bda4b7d26e and as such it reintroduces the problem solved by that >> > > commit. >> > > >> > > If your solution turns out to be better, that's great, but it would be >> > > nice to avoid the bisection hole of reintroducing the problem, then >> > > fixing it again later. >> > >> > There is no way to do that other than merging the revert and the fix >> > into one. That said, the race is sufficiently hard to hit that I >> > wouldn't worry too much about it. >> >> OK, then at least mention that in the changelog. > > Sure will do. This is just RFC at this stage :-) > > As for the race with enable, what's your take on my approach ? The > basic premise is that we need some kind of mutex to make the updates to > enable_cnt and the actual config space changes atomic. While at it we > can fold pci_set_master vs. is_busmaster as well as those are racy too. > > I chose to create a new mutex which we should be able to address other > similar races if we find them. The other solutions that I dismissed > were: > > - Using the device_lock. A explained previously, this is tricky, I > prefer not using this for anything other than locking against > concurrent add/remove. The main issue is that drivers will be sometimes > called in context where that's already held, so we can't take it inside > pci_enable_device() and I'd rather not add new constraints such as > "pci_enable_device() must be only called from probe() unless you also > take the device lock". It would be tricky to audit everybody... > > - Using a global mutex. We could move the bridge lock from AER to core > code for example, and use that. But it doesn't buy us much, and > slightly redecuces parallelism. It also makes it a little bit more > messy to walk up the bridge chain, we'd have to do a > pci_enable_device_unlocked or something, messy. > > So are you ok with the approach ? Do you prefer one of the above > regardless ? Something else ? > > Cheers, > Ben. > > Some concern was raised about race situation so just to be more clear about race condition. Situation is described in Bug 200283 - PCI: Data corruption happening due to a race condition. Issue was discovered by our broadcom QA team. Initially commit was to use one separate lock only for avoiding race condition but after review, approach was slightly changed to move is_added to pci_dev private flags as it was completely internal/private variable of pci core driver. Powerpc legacy arch code was using is_added flag directly which looks bit strange so ../../ type of inclusion of pci.h was required. I know it looks ugly but it is being used in some legacy code still. Anyway, as stated earlier too, problem should be just solved in better way. Regards, hari
[PATCH] mtd/ubi: Make sure to read volume record from LEB 0 or LEB 1
From: fishland
Even though we protect on-flash data by CRC checksums,
we still don't trust the media. If lnum is not 0 or 1,
access exceed array boundary can lead to bad situation.
Signed-off-by: Liu Song
Reviewed-by: Jiang Biao
---
drivers/mtd/ubi/vtbl.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/mtd/ubi/vtbl.c b/drivers/mtd/ubi/vtbl.c
index 94d7a86..64a2937 100644
--- a/drivers/mtd/ubi/vtbl.c
+++ b/drivers/mtd/ubi/vtbl.c
@@ -410,6 +410,10 @@ static struct ubi_vtbl_record *process_lvol(struct
ubi_device *ubi,
/* Read both LEB 0 and LEB 1 into memory */
ubi_rb_for_each_entry(rb, aeb, &av->root, u.rb) {
+ if (aeb->lnum != 0 && aeb->lnum != 1) {
+ ubi_warn(ubi, "volume store in LEB %d", aeb->lnum);
+ continue;
+ }
leb[aeb->lnum] = vzalloc(ubi->vtbl_size);
if (!leb[aeb->lnum]) {
err = -ENOMEM;
--
2.1.0.GIT
[PATCH V3 2/3] dt-bindings: input: Add document bindings for DA7280
from: Roy Im
Add device tree binding information for DA7280 haptic driver.
Example bindings for DA7280 are added.
Signed-off-by: Roy Im
---
v3: Fixed subject format.
v2: No changes
.../devicetree/bindings/input/dlg,da7280.txt | 91
1 file changed, 91 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/dlg,da7280.txt
diff --git a/Documentation/devicetree/bindings/input/dlg,da7280.txt
b/Documentation/devicetree/bindings/input/dlg,da7280.txt
new file mode 100644
index 000..759bcfe
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/dlg,da7280.txt
@@ -0,0 +1,91 @@
+Dialog Semiconductor DA7280 Haptics bindings
+
+Required properties:
+- compatible: Should be "dlg,da7280".
+- reg: Specifies the I2C slave address.
+
+- interrupt-parent : Specifies the phandle of the interrupt controller to
+ which the IRQs from DA7280 are delivered to.
+- interrupts: IRQ line info for DA7280.
+ (See Documentation/devicetree/bindings/interrupt-controller/
+ interrupts.txt for further information relating to interrupt properties)
+- dlg,vib-mode:
+ "LRA-MODE" - Linear Resonance Actuator mode.
+ "ERM-BAR" - Bar type Eccentric Rotating Mass mode.
+ "ERM-COIN" - Coin type Eccentric Rotating Mass mode.
+- dlg,play-mode: choose one in below five modes.
+ "DRO-MODE" - Direct register override mode.
+ "PWM-MODE" - PWM data source mode.
+ In this case, user is able to set duty to 0 ~ 0x(0% ~ 100%)
+ "RTWM-MODE" - Register triggered waveform memory mode.
+ In this case, when enable this mode the pattern assigned
+ to the PS_SEQ_ID will be played as much times as PS_SEQ_LOOP.
+ "ETWM-MODE" - Edge triggered waveform memory mode.
+ In this case, external GPI(N) control are required to enable/disable
+ and it needs to keep device enabled by sending magnitude (X > 0)
+ the pattern assigned to the GPI(N)_SEQUENCE_ID below.
+ For more details, please see the datasheet.
+- dlg,nom-microvolt: Nominal actuator voltage rating.
+- dlg,abs-max-microvolt: Absolute actuator maximum voltage rating.
+- dlg,imax-microamp: Actuator max current rating.
+- dlg,impd-micro-ohms: the impedance of the actuator in micro ohm,
+ as read from its datasheet.
+
+Optional properties:
+- pwms : phandle to the physical PWM(Pulse Width Modulation) device.
+ PWM properties should be named "pwms". And number of cell is different
+ for each pwm device.
+ (See Documentation/devicetree/bindings/pwm/pwm.txt
+ for further information relating to pwm properties)
+- dlg,ps-seq-id: the PS_SEQ_ID(pattern ID in waveform memory inside chip)
+ to play back when RTWM-MODE is enabled.
+- dlg,ps-seq-loop: the PS_SEQ_LOOP, Number of times the pre-stored sequence
+ pointed to by PS_SEQ_ID or GPI(N)_SEQUENCE_ID is repeated.
+- dlg,gpiN-seq-id: the GPI(N)_SEQUENCE_ID, pattern to play
+ when gpi0 is triggered, 'N' must be 0~2.
+- dlg,gpiN-mode: the pattern mode which can select either
+ "Single-pattern" or "Multi-pattern", 'N' must be 0~2.
+- dlg,gpiN-polarity: gpiN polarity which can be chosen among "Rising-edge",
+ "Falling-edge" and "Both-edge", 'N' must be 0~2.
+ Haptic will work by this edge option in case of ETWM-MODE.
+
+- dlg,resonant-freq-hz: use in case of LRA-MODE, default 205Hz.
+ the freq range: 50Hz ~ 300Hz.
+ It will be set to 205Hz if the value is out of range.
+- dlg,bemf-sens-enable: Enable for internal loop computations.
+- dlg,freq-track-enable: Enable for resonant frequency tracking.
+- dlg,acc-enable: Enable for active acceleration.
+- dlg,rapid-stop-enable: Enable for rapid stop.
+- dlg,amp-pid-enable: Enable for the amplitude PID.
+- dlg,mem-array: use in case that memory registers should be updated,
+ Please fill the whole buffers(100 bytes) to avoid any error in driver.
+ For example,
+ dlg,mem-array = <
+ 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0A
+ ...
+ 0x71 0x72 0x73 0x74 0x75 0x76 0x77 0x78 0x79 0x7A
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+ >;
+
+For further information, see device datasheet.
+
+==
+
+Example:
+
+ haptics: da7280-haptics@4A {
+ compatible = "dlg,da7280";
+ reg = <0x4A>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+ dlg,vib-mode = "LRA-MODE";
+ dlg,play-mode = "DRO-MODE";
+ dlg,nom-microvolt = <200>;
+ dlg,abs-max-microvolt = <200>;
+ dlg,imax-microamp = <17>;
+ dlg,resonant-freq-hz = <180>;
+ dlg,impd-micro-ohms = <1050>;
+ dlg,freq-track-enable;
+ dlg,rapid-stop-enable;
+ };
--
end-of-patch for PATCH V3
[PATCH V3 0/3] da7280: haptic driver submission
From: Roy Im This patch adds support for the Dialog DA7280 Haptic driver IC. In this patch set the following is provided: [PATCH V2 1/3] MAINTAINERS file update for DA7280 [PATCH V2 2/3] DA7280 DT Binding [PATCH V2 3/3] DA7280 Driver This patch applies against linux-next and v4.18 Thank you, Roy Im, Dialog Semiconductor Ltd. Roy Im (3): MAINTAINERS: da7280 updates to the Dialog Semiconductor search terms dt-bindings: input: Add document bindings for DA7280 Input: new da7280 haptic driver .../devicetree/bindings/input/dlg,da7280.txt | 91 ++ MAINTAINERS|2 + drivers/input/misc/Kconfig | 12 + drivers/input/misc/Makefile|1 + drivers/input/misc/da7280.c| 1451 drivers/input/misc/da7280.h| 412 ++ 6 files changed, 1969 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/dlg,da7280.txt create mode 100644 drivers/input/misc/da7280.c create mode 100644 drivers/input/misc/da7280.h -- end-of-patch for PATCH V3
[PATCH V3 3/3] Input: new da7280 haptic driver
from: Roy Im
Adds support for the Dialog DA7280 LRA/ERM Haptic Driver with
multiple mode and integrated waveform memory and wideband support.
It communicates via an I2C bus to the device.
Signed-off-by: Roy Im
---
v3: No changes.
v2: Fixed kbuild error/warning
drivers/input/misc/Kconfig | 12 +
drivers/input/misc/Makefile |1 +
drivers/input/misc/da7280.c | 1451 +++
drivers/input/misc/da7280.h | 412
4 files changed, 1876 insertions(+)
create mode 100644 drivers/input/misc/da7280.c
create mode 100644 drivers/input/misc/da7280.h
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index ca59a2b..6e0de69 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -851,4 +851,16 @@ config INPUT_SC27XX_VIBRA
To compile this driver as a module, choose M here. The module will
be called sc27xx_vibra.
+config INPUT_DA7280_HAPTICS
+ tristate "Dialog Semiconductor DA7280 haptics support"
+ depends on (INPUT && I2C && SYSFS) || PWM
+ select INPUT_FF_MEMLESS
+ select REGMAP_I2C
+ help
+ Say Y to enable support for the haptics controller on
+ Dialog DA7280 chip.
+
+ To compile this driver as a module, choose M here: the
+ module will be called da7280-haptic.
+
endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 9d0f9d1..d941348 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_INPUT_CMA3000) += cma3000_d0x.o
obj-$(CONFIG_INPUT_CMA3000_I2C)+= cma3000_d0x_i2c.o
obj-$(CONFIG_INPUT_COBALT_BTNS)+= cobalt_btns.o
obj-$(CONFIG_INPUT_CPCAP_PWRBUTTON)+= cpcap-pwrbutton.o
+obj-$(CONFIG_INPUT_DA7280_HAPTICS) += da7280.o
obj-$(CONFIG_INPUT_DA9052_ONKEY) += da9052_onkey.o
obj-$(CONFIG_INPUT_DA9055_ONKEY) += da9055_onkey.o
obj-$(CONFIG_INPUT_DA9063_ONKEY) += da9063_onkey.o
diff --git a/drivers/input/misc/da7280.c b/drivers/input/misc/da7280.c
new file mode 100644
index 000..f2e1d3a
--- /dev/null
+++ b/drivers/input/misc/da7280.c
@@ -0,0 +1,1451 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DA7280 Haptic device driver
+ *
+ * Copyright (c) 2018 Dialog Semiconductor.
+ * Author: Roy Im
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "da7280.h"
+
+/* uV unit for voltage rate */
+#define DA7280_VOLTAGE_RATE_MAX600
+#define DA7280_VOLTAGE_RATE_STEP 23400
+#define DA7280_NOMMAX_DFT 0x6B
+#define DA7280_ABSMAX_DFT 0x78
+
+#define DA7280_IMPD_MAX0x
+#define DA7280_IMPD_DEFAULT2200
+
+#define DA7280_IMAX_DEFAULT0x0E
+/* uA unit step and limit for IMAX*/
+#define DA7280_IMAX_STEP 7200
+#define DA7280_IMAX_LIMIT 252000
+
+#define DA7280_RESONT_FREQH_DFT0x39
+#define DA7280_RESONT_FREQL_DFT0x32
+#define DA7280_MIN_RESONAT_FREQ_HZ 50
+#define DA7280_MAX_RESONAT_FREQ_HZ 300
+#define DA7280_MIN_PWM_FREQ_KHZ10
+#define DA7280_MAX_PWM_FREQ_KHZ250
+
+#define DA7280_SEQ_ID_MAX 15
+#define DA7280_SEQ_LOOP_MAX15
+#define DA7280_GPI1_SEQ_ID_DEFT0x0
+
+#define DA7280_SNP_MEM_SIZE100
+#define DA7280_SNP_MEM_MAX DA7280_SNP_MEM_99
+
+#define IRQ_NUM3
+
+#define DA7280_SKIP_INIT 0x100
+
+enum da7280_haptic_dev_t {
+ DA7280_LRA = 0,
+ DA7280_ERM_BAR = 1,
+ DA7280_ERM_COIN = 2,
+ DA7280_DEV_MAX,
+};
+
+enum da7280_op_mode {
+ DA7280_INACTIVE = 0,
+ DA7280_DRO_MODE = 1,
+ DA7280_PWM_MODE = 2,
+ DA7280_RTWM_MODE= 3,
+ DA7280_ETWM_MODE= 4,
+ DA7280_OPMODE_MAX,
+};
+
+struct da7280_gpi_ctl {
+ u8 seq_id;
+ u8 mode;
+ u8 polarity;
+};
+
+struct da7280_haptic {
+ struct regmap *regmap;
+ struct input_dev *input_dev;
+ struct device *dev;
+ struct i2c_client *client;
+ struct pwm_device *pwm_dev;
+ boollegacy;
+ int pwm_id;
+ struct work_struct work;
+
+ bool suspend_state;
+ unsigned int magnitude;
+
+ u8 dev_type;
+ u8 op_mode;
+ u16 nommax;
+ u16 absmax;
+ u32 imax;
+ u32 impd;
+ u32 resonant_freq_h;
+ u32 resonant_freq_l;
+ u8 bemf_sense_en;
+ u8 freq_track_en;
+ u8 acc_en;
+ u8 rapid_stop_en;
+ u8 amp_pid_en;
+ u8 ps_seq_id;
+ u8 ps_seq_loop;
+ struct da7280_gpi_ctl gpi_ctl[3];
+ bool mem_update;
+ u8 snp_mem[DA7280_SNP_MEM_SIZE];
+ const struct attribute_group **attr_group;
+};
+
+static bool da7280_volatile_register(struct device *dev, unsigned in
[PATCH V3 1/3] MAINTAINERS: da7280 updates to the Dialog Semiconductor search terms
From: Roy Im This patch adds the da7280 bindings doc and driver to the Dialog Semiconductor support list. Signed-off-by: Roy Im --- v3: No changes. v2: No changes. MAINTAINERS |2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 544cac8..720f9fe 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4221,6 +4221,7 @@ S:Supported F: Documentation/hwmon/da90?? F: Documentation/devicetree/bindings/mfd/da90*.txt F: Documentation/devicetree/bindings/input/da90??-onkey.txt +F: Documentation/devicetree/bindings/input/dlg,da72??.txt F: Documentation/devicetree/bindings/thermal/da90??-thermal.txt F: Documentation/devicetree/bindings/regulator/da92*.txt F: Documentation/devicetree/bindings/watchdog/da90??-wdt.txt @@ -4229,6 +4230,7 @@ F:drivers/gpio/gpio-da90??.c F: drivers/hwmon/da90??-hwmon.c F: drivers/iio/adc/da91??-*.c F: drivers/input/misc/da90??_onkey.c +F: drivers/input/misc/da72??.[ch] F: drivers/input/touchscreen/da9052_tsi.c F: drivers/leds/leds-da90??.c F: drivers/mfd/da903x.c -- end-of-patch for PATCH V3
Re: [PATCH 7/7] Documentation: devicetree: Add Xilinx R5 rproc binding
On Fri, Aug 17, 2018 at 9:31 AM, Moritz Fischer
wrote:
> Hi Wendy,
>
> couple of minor stuff inline.
>
> On Thu, Aug 16, 2018 at 12:06 AM, Wendy Liang wrote:
>> Add device tree binding for Xilinx Cortex-r5 remoteproc.
>>
>> Signed-off-by: Wendy Liang
>> ---
>> .../remoteproc/xlnx,zynqmp-r5-remoteproc.txt | 81
>> ++
>> 1 file changed, 81 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt
>> b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt
>> new file mode 100644
>> index 000..3940019
>> --- /dev/null
>> +++
>> b/Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt
>> @@ -0,0 +1,81 @@
>> +Xilinx ARM Cortex A53-R5 remoteproc driver
>> +==
>> +
>> +ZynqMP family of devices use two Cortex R5 processors to help with various
>> +low power / real time tasks.
>
> The ZynqMP family [..] uses [..]
Will update in next version
>> +
>> +This driver requires specific ZynqMP hardware design.
>
> *a* specific ZynqMP hardware design. What does that mean?
>> +
>> +ZynqMP R5 RemoteProc Device Node:
>> +=
>> +A zynqmp_r5_remoteproc device node is used to represent a R5 IP instance
>> +within ZynqMP SoC.
>> +
>> +Required properties:
>> +
>> + - compatible : Should be "xlnx,zynqmp-r5-remoteproc-1.0"
>> + - reg : Address and length of the register set for the device. It
>> +contains in the same order as described reg-names
>
> ?
>> + - reg-names: Contain the register set names.
>
> Contains
Will update in next version
>
>> + "tcm_a" and "tcm_b" for TCM memories.
>> + If the user uses the remoteproc driver with the RPMsg kernel
>> + driver,"ipi" for the IPI register used to communicate with RPU
>> + is also required.
>> + Otherwise, if user only uses the remoteproc driver to boot RPU
>> + firmware, "ipi" is not required.
>> + - tcm-pnode-id: TCM resources power nodes IDs which are used to request TCM
>> + resources for the remoteproc driver to access.
>> + - rpu-pnode-id : RPU power node id which is used by the remoteproc driver
>> + to start RPU or shut it down.
>> +
>> +Optional properties:
>> +
>> + - core_conf : R5 core configuration (valid string - split0 or split1 or
>> + lock-step), default is lock-step.
>> + - memory-region: memories regions for RPU executable and DMA memory.
>> + - interrupts : Interrupt mapping for remoteproc IPI. It is required if the
>> +user uses the remoteproc driver with the RPMsg kernel
>> driver.
>> + - interrupt-parent : Phandle for the interrupt controller. It is required
>> if
>> + the user uses the remoteproc driver with the RPMsg
>> kernel
>> + kernel driver.
>> +
>> +Example:
>> +
>> + reserved-memory {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> + rproc_0_fw_reserved: rproc@3ed00 {
>> + compatible = "rproc-prog-memory";
>> + no-map;
>> + reg = <0x0 0x3ed0 0x0 0x4>;
>> + };
>> + rproc_0_dma_reserved: rproc@3ed40 {
>> + compatible = "shared-dma-pool";
>> + no-map;
>> + reg = <0x0 0x3ed4 0x0 0x8>;
>> + };
>> + };
>> +
>> + firmware {
>> + zynqmp_firmware: zynqmp-firmware {
>> + compatible = "xlnx,zynqmp-firmware";
>> + method = "smc";
>> + };
>> + };
>> +
>> + zynqmp-r5-remoteproc@0 {
>> + compatible = "xlnx,zynqmp-r5-remoteproc-1.0";
>> + reg = <0x0 0xFFE0 0x0 0x1>,
>> + <0x0 0xFFE2 0x0 0x1>,
>> + <0x0 0xff34 0x0 0x100>;
>> + reg-names = "tcm_a", "tcm_b", "ipi";
>> + dma-ranges;
>> + core_conf = "split0";
>> + memory-region = <&rproc_0_fw_reserved>,
>> + <&rproc_0_dma_reserved>;
>> + tcm-pnode-id = <0xf>, <0x10>;
>> + rpu-pnode-id = <0x7>;
>> + interrupt-parent = <&gic>;
>> + interrupts = <0 29 4>;
>> + } ;
>> --
>> 2.7.4
>>
>
> Cheers,
> Moritz
Re: [PATCH 7/7] Documentation: devicetree: Add Xilinx R5 rproc binding
On Fri, Aug 17, 2018 at 8:09 AM, Rob Herring wrote: > Hi, this email is from Rob's (experimental) review bot. I found a couple > of common problems with your patch. Please see below. > > On Thu, 16 Aug 2018 00:06:30 -0700, Wendy Liang wrote: >> Add device tree binding for Xilinx Cortex-r5 remoteproc. >> >> Signed-off-by: Wendy Liang > > The preferred subject prefix is "dt-bindings: : ...". Will updated in the next release > >> --- >> .../remoteproc/xlnx,zynqmp-r5-remoteproc.txt | 81 >> ++ >> 1 file changed, 81 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/remoteproc/xlnx,zynqmp-r5-remoteproc.txt >>
Re: [PATCH v9 2/4] Uprobes/sdt: Prevent multiple reference counter for same uprobe
On Sun, Aug 19, 2018 at 9:42 PM, Ravi Bangoria
wrote:
> We assume to have only one reference counter for one uprobe.
> Don't allow user to register multiple uprobes having same
> inode+offset but different reference counter.
>
> Signed-off-by: Ravi Bangoria
> Acked-by: Srikar Dronamraju
> Reviewed-by: Oleg Nesterov
Reviewed-by: Song Liu
> ---
> kernel/events/uprobes.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index 35065febcb6c..ecee371a59c7 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -679,6 +679,16 @@ static struct uprobe *insert_uprobe(struct uprobe
> *uprobe)
> return u;
> }
>
> +static void
> +ref_ctr_mismatch_warn(struct uprobe *cur_uprobe, struct uprobe *uprobe)
> +{
> + pr_warn("ref_ctr_offset mismatch. inode: 0x%lx offset: 0x%llx "
> + "ref_ctr_offset(old): 0x%llx ref_ctr_offset(new): 0x%llx\n",
> + uprobe->inode->i_ino, (unsigned long long) uprobe->offset,
> + (unsigned long long) cur_uprobe->ref_ctr_offset,
> + (unsigned long long) uprobe->ref_ctr_offset);
> +}
> +
> static struct uprobe *alloc_uprobe(struct inode *inode, loff_t offset,
>loff_t ref_ctr_offset)
> {
> @@ -698,6 +708,12 @@ static struct uprobe *alloc_uprobe(struct inode *inode,
> loff_t offset,
> cur_uprobe = insert_uprobe(uprobe);
> /* a uprobe exists for this inode:offset combination */
> if (cur_uprobe) {
> + if (cur_uprobe->ref_ctr_offset != uprobe->ref_ctr_offset) {
> + ref_ctr_mismatch_warn(cur_uprobe, uprobe);
> + put_uprobe(cur_uprobe);
> + kfree(uprobe);
> + return ERR_PTR(-EINVAL);
> + }
> kfree(uprobe);
> uprobe = cur_uprobe;
> }
> @@ -1112,6 +1128,9 @@ static int __uprobe_register(struct inode *inode,
> loff_t offset,
> uprobe = alloc_uprobe(inode, offset, ref_ctr_offset);
> if (!uprobe)
> return -ENOMEM;
> + if (IS_ERR(uprobe))
> + return PTR_ERR(uprobe);
> +
> /*
> * We can race with uprobe_unregister()->delete_uprobe().
> * Check uprobe_is_active() and retry if it is false.
> --
> 2.14.4
>
Re: [PATCH v9 1/4] Uprobes: Support SDT markers having reference count (semaphore)
On Sun, Aug 19, 2018 at 9:42 PM, Ravi Bangoria
wrote:
> Userspace Statically Defined Tracepoints[1] are dtrace style markers
> inside userspace applications. Applications like PostgreSQL, MySQL,
> Pthread, Perl, Python, Java, Ruby, Node.js, libvirt, QEMU, glib etc
> have these markers embedded in them. These markers are added by developer
> at important places in the code. Each marker source expands to a single
> nop instruction in the compiled code but there may be additional
> overhead for computing the marker arguments which expands to couple of
> instructions. In case the overhead is more, execution of it can be
> omitted by runtime if() condition when no one is tracing on the marker:
>
> if (reference_counter > 0) {
> Execute marker instructions;
> }
>
> Default value of reference counter is 0. Tracer has to increment the
> reference counter before tracing on a marker and decrement it when
> done with the tracing.
>
> Implement the reference counter logic in core uprobe. User will be
> able to use it from trace_uprobe as well as from kernel module. New
> trace_uprobe definition with reference counter will now be:
>
> :[(ref_ctr_offset)]
>
> where ref_ctr_offset is an optional field. For kernel module, new
> variant of uprobe_register() has been introduced:
>
> uprobe_register_refctr(inode, offset, ref_ctr_offset, consumer)
>
> No new variant for uprobe_unregister() because it's assumed to have
> only one reference counter for one uprobe.
>
> [1] https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation
>
> Note: 'reference counter' is called as 'semaphore' in original Dtrace
> (or Systemtap, bcc and even in ELF) documentation and code. But the
> term 'semaphore' is misleading in this context. This is just a counter
> used to hold number of tracers tracing on a marker. This is not really
> used for any synchronization. So we are calling it a 'reference counter'
> in kernel / perf code.
>
> Signed-off-by: Ravi Bangoria
> Reviewed-by: Masami Hiramatsu
> [Only trace_uprobe.c]
> Reviewed-by: Oleg Nesterov
Reviewed-by: Song Liu
> ---
> include/linux/uprobes.h | 5 +
> kernel/events/uprobes.c | 259
> ++--
> kernel/trace/trace.c| 2 +-
> kernel/trace/trace_uprobe.c | 38 ++-
> 4 files changed, 293 insertions(+), 11 deletions(-)
>
> diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
> index bb9d2084af03..103a48a48872 100644
> --- a/include/linux/uprobes.h
> +++ b/include/linux/uprobes.h
> @@ -123,6 +123,7 @@ extern unsigned long uprobe_get_swbp_addr(struct pt_regs
> *regs);
> extern unsigned long uprobe_get_trap_addr(struct pt_regs *regs);
> extern int uprobe_write_opcode(struct arch_uprobe *auprobe, struct mm_struct
> *mm, unsigned long vaddr, uprobe_opcode_t);
> extern int uprobe_register(struct inode *inode, loff_t offset, struct
> uprobe_consumer *uc);
> +extern int uprobe_register_refctr(struct inode *inode, loff_t offset, loff_t
> ref_ctr_offset, struct uprobe_consumer *uc);
> extern int uprobe_apply(struct inode *inode, loff_t offset, struct
> uprobe_consumer *uc, bool);
> extern void uprobe_unregister(struct inode *inode, loff_t offset, struct
> uprobe_consumer *uc);
> extern int uprobe_mmap(struct vm_area_struct *vma);
> @@ -160,6 +161,10 @@ uprobe_register(struct inode *inode, loff_t offset,
> struct uprobe_consumer *uc)
> {
> return -ENOSYS;
> }
> +static inline int uprobe_register_refctr(struct inode *inode, loff_t offset,
> loff_t ref_ctr_offset, struct uprobe_consumer *uc)
> +{
> + return -ENOSYS;
> +}
> static inline int
> uprobe_apply(struct inode *inode, loff_t offset, struct uprobe_consumer *uc,
> bool add)
> {
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index 919c1ce32beb..35065febcb6c 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -73,6 +73,7 @@ struct uprobe {
> struct uprobe_consumer *consumers;
> struct inode*inode; /* Also hold a ref to inode */
> loff_t offset;
> + loff_t ref_ctr_offset;
> unsigned long flags;
>
> /*
> @@ -88,6 +89,15 @@ struct uprobe {
> struct arch_uprobe arch;
> };
>
> +struct delayed_uprobe {
> + struct list_head list;
> + struct uprobe *uprobe;
> + struct mm_struct *mm;
> +};
> +
> +static DEFINE_MUTEX(delayed_uprobe_lock);
> +static LIST_HEAD(delayed_uprobe_list);
> +
> /*
> * Execute out of line area: anonymous executable mapping installed
> * by the probed task to execute the copy of the original instruction
> @@ -282,6 +292,166 @@ static int verify_opcode(struct page *page, unsigned
> long vaddr, uprobe_opcode_t
> return 1;
> }
>
> +static struct delayed_uprobe *
> +delayed_uprobe_check(struct uprobe *uprobe, struct mm_struct *mm)
> +{
> + struct delayed_uprobe *du;
> +
> + list_for_each_ent
linux-next: Tree for Aug 20
Hi all, Please do not add any v4.20 material to your linux-next included branches until after v4.19-rc1 has been released. Changes since 20180817: The akpm-current tree gained conflicts against the tip tree. Non-merge commits (relative to Linus' tree): 2346 2426 files changed, 93635 insertions(+), 35418 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 286 trees (counting Linus' and 65 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (2ad0d5269970 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging fixes/master (147a89bc71e7 Merge tag 'kconfig-v4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild) Merging kbuild-current/fixes (08b5fa819970 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input) Merging arc-current/for-curr (fce0d0affdc5 ARC: cleanup show_faulting_vma()) Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return for binutils 2.29+) Merging arm64-fixes/for-next/fixes (5ad356eabc47 arm64: mm: check for upper PAGE_SHIFT bits in pfn_valid()) Merging m68k-current/for-linus (71a896687b85 m68k/defconfig: Update defconfigs for v4.18-rc6) Merging powerpc-fixes/fixes (cca19f0b684f powerpc/64s/radix: Fix missing global invalidations when removing copro) Merging sparc/master (c1d61e7fe376 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (e2948e5af8ee ip6_vti: fix creating fallback tunnel device for vti6) Merging bpf/master (f6069b9aa993 bpf: fix redirect to map under tail calls) Merging ipsec/master (25432eba9cd8 openvswitch: meter: Fix setting meter id for new entries) Merging netfilter/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (299b6365a3b7 brcmfmac: fix regression in parsing NVRAM for multiple devices) Merging mac80211/master (484004339d45 mac80211_hwsim: require at least one channel) Merging rdma-fixes/for-rc (addb8a6559f0 RDMA/uverbs: Expand primary and alt AV port checks) Merging sound-current/for-linus (250ea7c5f56e ALSA: ac97: fix unbalanced pm_runtime_enable) Merging sound-asoc-fixes/for-linus (ba095ffc9324 Merge branch 'asoc-4.18' into asoc-linus) Merging regmap-fixes/for-linus (94710cac0ef4 Linux 4.18) Merging regulator-fixes/for-linus (84d77c5ab32d Merge branch 'regulator-4.18' into regulator-linus) Merging spi-fixes/for-linus (8a7c14551b9b Merge branch 'spi-4.18' into spi-linus) Merging pci-current/for-linus (44bda4b7d26e PCI: Fix is_added/is_busmaster race condition) Merging driver-core.current/driver-core-linus (08b5fa819970 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input) Merging tty.current/tty-linus (08b5fa819970 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input) Merging usb.current/usb-linus (08b5fa819970 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input) Merging usb-gadget-fixes/fixes (acb1872577b3 Linux 4.18-rc7) Merging usb-serial-fixes/usb-linus (9d3cce1e8b85 Linux 4.1
Re: [PATCH v8 1/2] kbuild: Allow asm-specific compiler_types.h
Hi Paul,
2018-08-19 3:10 GMT+09:00 Paul Burton :
> We have a need to override the definition of
> barrier_before_unreachable() for MIPS, which means we either need to add
> architecture-specific code into linux/compiler-gcc.h or we need to allow
> the architecture to provide a header that can define the macro before
> the generic definition. The latter seems like the better approach.
>
> A straightforward approach to the per-arch header is to make use of
> asm-generic to provide a default empty header & adjust architectures
> which don't need anything specific to make use of that by adding the
> header to generic-y. Unfortunately this doesn't work so well due to
> commit a95b37e20db9 ("kbuild: get out of
> ") which moved the inclusion of linux/compiler.h to
> cflags using the -include compiler flag.
>
> Because the -include flag is present for all C files we compile, we need
> the architecture-provided header to be present before any C files are
> compiled. If any C files can be compiled prior to the asm-generic header
> wrappers being generated then we hit a build failure due to missing
> header. Such cases do exist - one pointed out by the kbuild test robot
> is the compilation of arch/ia64/kernel/nr-irqs.c, which occurs as part
> of the archprepare target [1].
>
> This leaves us with a few options:
>
> 1) Use generic-y & fix any build failures we find by enforcing
> ordering such that the asm-generic target occurs before any C
> compilation, such that linux/compiler_types.h can always include
> the generated asm-generic wrapper which in turn includes the empty
> asm-generic header. This would rely on us finding all the
> problematic cases - I don't know for sure that the ia64 issue is
> the only one.
>
> 2) Add an actual empty header to each architecture, so that we don't
> need the generated asm-generic wrapper. This seems messy.
>
> 3) Give up & add #ifdef CONFIG_MIPS or similar to
> linux/compiler_types.h. This seems messy too.
>
> 4) Include the arch header only when it's actually needed, removing
> the need for the asm-generic wrapper for all other architectures.
>
> This patch allows us to use approach 4, by including an
> asm/compiler_types.h header using the -include flag in the same way we
> do for linux/compiler_types.h, but only if the header actually exists.
I agree with the approach 4),
but I am of two minds about how to implement it.
I guess the cost of evaluating 'wildcard' for each C file
is unnoticeable level, but I am slightly in favor of
including from
conditionally.
I am not sure about the CONFIG name, but for example, like this.
#ifdef CONFIG_HAVE_ARCH_COMPILER_TYPES
#include
#endif
What do you think?
> [1] https://lists.01.org/pipermail/kbuild-all/2018-August/051175.html
>
> Signed-off-by: Paul Burton
> Cc: Arnd Bergmann
> Cc: James Hogan
> Cc: Masahiro Yamada
> Cc: Ralf Baechle
> Cc: linux-a...@vger.kernel.org
> Cc: linux-kbu...@vger.kernel.org
> Cc: linux-m...@linux-mips.org
>
> ---
> Any thoughts anyone?
>
> This isn't the prettiest it could possibly be but it's a small change &
> clearly shouldn't break anything, which are good qualities for a patch
> fixing build failures that we'd ideally backport as far as 4.16.
>
> Changes in v8:
> - New patch.
>
> scripts/Makefile.lib | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 1bb594fcfe12..4e7b41ef029b 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -151,8 +151,11 @@ __a_flags = $(call flags,_a_flags)
> __cpp_flags = $(call flags,_cpp_flags)
> endif
>
> +c_includes = $(wildcard
> $(srctree)/arch/$(SRCARCH)/include/asm/compiler_types.h)
> +c_includes += $(srctree)/include/linux/compiler_types.h
> +
> c_flags= -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) \
> --include $(srctree)/include/linux/compiler_types.h \
> +$(addprefix -include ,$(c_includes)) \
> $(__c_flags) $(modkern_cflags) \
> $(basename_flags) $(modname_flags)
>
> --
> 2.18.0
>
--
Best Regards
Masahiro Yamada
[PATCH v9 4/4] perf probe: Support SDT markers having reference counter (semaphore)
With this, perf buildid-cache will save SDT markers with reference
counter in probe cache. Perf probe will be able to probe markers
having reference counter. Ex,
# readelf -n /tmp/tick | grep -A1 loop2
Name: loop2
... Semaphore: 0x10020036
# ./perf buildid-cache --add /tmp/tick
# ./perf probe sdt_tick:loop2
# ./perf stat -e sdt_tick:loop2 /tmp/tick
hi: 0
hi: 1
hi: 2
^C
Performance counter stats for '/tmp/tick':
3 sdt_tick:loop2
2.561851452 seconds time elapsed
Signed-off-by: Ravi Bangoria
Acked-by: Masami Hiramatsu
Acked-by: Srikar Dronamraju
---
tools/perf/util/probe-event.c | 39
tools/perf/util/probe-event.h | 1 +
tools/perf/util/probe-file.c | 34 ++--
tools/perf/util/probe-file.h | 1 +
tools/perf/util/symbol-elf.c | 46 ---
tools/perf/util/symbol.h | 7 +++
6 files changed, 106 insertions(+), 22 deletions(-)
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index f119eb628dbb..e86f8be89157 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -1819,6 +1819,12 @@ int parse_probe_trace_command(const char *cmd, struct
probe_trace_event *tev)
tp->offset = strtoul(fmt2_str, NULL, 10);
}
+ if (tev->uprobes) {
+ fmt2_str = strchr(p, '(');
+ if (fmt2_str)
+ tp->ref_ctr_offset = strtoul(fmt2_str + 1, NULL, 0);
+ }
+
tev->nargs = argc - 2;
tev->args = zalloc(sizeof(struct probe_trace_arg) * tev->nargs);
if (tev->args == NULL) {
@@ -2012,6 +2018,22 @@ static int synthesize_probe_trace_arg(struct
probe_trace_arg *arg,
return err;
}
+static int
+synthesize_uprobe_trace_def(struct probe_trace_event *tev, struct strbuf *buf)
+{
+ struct probe_trace_point *tp = &tev->point;
+ int err;
+
+ err = strbuf_addf(buf, "%s:0x%lx", tp->module, tp->address);
+
+ if (err >= 0 && tp->ref_ctr_offset) {
+ if (!uprobe_ref_ctr_is_supported())
+ return -1;
+ err = strbuf_addf(buf, "(0x%lx)", tp->ref_ctr_offset);
+ }
+ return err >= 0 ? 0 : -1;
+}
+
char *synthesize_probe_trace_command(struct probe_trace_event *tev)
{
struct probe_trace_point *tp = &tev->point;
@@ -2041,15 +2063,17 @@ char *synthesize_probe_trace_command(struct
probe_trace_event *tev)
}
/* Use the tp->address for uprobes */
- if (tev->uprobes)
- err = strbuf_addf(&buf, "%s:0x%lx", tp->module, tp->address);
- else if (!strncmp(tp->symbol, "0x", 2))
+ if (tev->uprobes) {
+ err = synthesize_uprobe_trace_def(tev, &buf);
+ } else if (!strncmp(tp->symbol, "0x", 2)) {
/* Absolute address. See try_to_find_absolute_address() */
err = strbuf_addf(&buf, "%s%s0x%lx", tp->module ?: "",
tp->module ? ":" : "", tp->address);
- else
+ } else {
err = strbuf_addf(&buf, "%s%s%s+%lu", tp->module ?: "",
tp->module ? ":" : "", tp->symbol, tp->offset);
+ }
+
if (err)
goto error;
@@ -2633,6 +2657,13 @@ static void warn_uprobe_event_compat(struct
probe_trace_event *tev)
{
int i;
char *buf = synthesize_probe_trace_command(tev);
+ struct probe_trace_point *tp = &tev->point;
+
+ if (tp->ref_ctr_offset && !uprobe_ref_ctr_is_supported()) {
+ pr_warning("A semaphore is associated with %s:%s and "
+ "seems your kernel doesn't support it.\n",
+ tev->group, tev->event);
+ }
/* Old uprobe event doesn't support memory dereference */
if (!tev->uprobes || tev->nargs == 0 || !buf)
diff --git a/tools/perf/util/probe-event.h b/tools/perf/util/probe-event.h
index 45b14f020558..15a98c3a2a2f 100644
--- a/tools/perf/util/probe-event.h
+++ b/tools/perf/util/probe-event.h
@@ -27,6 +27,7 @@ struct probe_trace_point {
char*symbol;/* Base symbol */
char*module;/* Module name */
unsigned long offset; /* Offset from symbol */
+ unsigned long ref_ctr_offset; /* SDT reference counter offset */
unsigned long address;/* Actual address of the trace point */
boolretprobe; /* Return probe flag */
};
diff --git a/tools/perf/util/probe-file.c b/tools/perf/util/probe-file.c
index b76088fadf3d..aac7817d9e14 100644
--- a/tools/perf/util/probe-file.c
+++ b/tools/perf/util/probe-file.c
@@ -696,8 +696,16 @@ int probe_cache__add_entry(struct probe_cache *pcache,
#ifdef HAVE_GELF_GETNOTE_SUPPORT
static unsigned long long sdt_note__get_addr(struct sdt_note *note)
{
- return note->bit32 ?
[PATCH v9 3/4] trace_uprobe/sdt: Prevent multiple reference counter for same uprobe
We assume to have only one reference counter for one uprobe.
Don't allow user to add multiple trace_uprobe entries having
same inode+offset but different reference counter.
Ex,
# echo "p:sdt_tick/loop2 /home/ravi/tick:0x6e4(0x10036)" > uprobe_events
# echo "p:sdt_tick/loop2_1 /home/ravi/tick:0x6e4(0xf)" >> uprobe_events
bash: echo: write error: Invalid argument
# dmesg
trace_kprobe: Reference counter offset mismatch.
There is one exception though:
When user is trying to replace the old entry with the new
one, we allow this if the new entry does not conflict with
any other existing entries.
Signed-off-by: Ravi Bangoria
Acked-by: Srikar Dronamraju
Reviewed-by: Song Liu
Reviewed-by: Oleg Nesterov
---
kernel/trace/trace_uprobe.c | 37 +++--
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
index a7ef6c4ca16e..21d9fffaa096 100644
--- a/kernel/trace/trace_uprobe.c
+++ b/kernel/trace/trace_uprobe.c
@@ -324,6 +324,35 @@ static int unregister_trace_uprobe(struct trace_uprobe *tu)
return 0;
}
+/*
+ * Uprobe with multiple reference counter is not allowed. i.e.
+ * If inode and offset matches, reference counter offset *must*
+ * match as well. Though, there is one exception: If user is
+ * replacing old trace_uprobe with new one(same group/event),
+ * then we allow same uprobe with new reference counter as far
+ * as the new one does not conflict with any other existing
+ * ones.
+ */
+static struct trace_uprobe *find_old_trace_uprobe(struct trace_uprobe *new)
+{
+ struct trace_uprobe *tmp, *old = NULL;
+ struct inode *new_inode = d_real_inode(new->path.dentry);
+
+ old = find_probe_event(trace_event_name(&new->tp.call),
+ new->tp.call.class->system);
+
+ list_for_each_entry(tmp, &uprobe_list, list) {
+ if ((old ? old != tmp : true) &&
+ new_inode == d_real_inode(tmp->path.dentry) &&
+ new->offset == tmp->offset &&
+ new->ref_ctr_offset != tmp->ref_ctr_offset) {
+ pr_warn("Reference counter offset mismatch.");
+ return ERR_PTR(-EINVAL);
+ }
+ }
+ return old;
+}
+
/* Register a trace_uprobe and probe_event */
static int register_trace_uprobe(struct trace_uprobe *tu)
{
@@ -333,8 +362,12 @@ static int register_trace_uprobe(struct trace_uprobe *tu)
mutex_lock(&uprobe_lock);
/* register as an event */
- old_tu = find_probe_event(trace_event_name(&tu->tp.call),
- tu->tp.call.class->system);
+ old_tu = find_old_trace_uprobe(tu);
+ if (IS_ERR(old_tu)) {
+ ret = PTR_ERR(old_tu);
+ goto end;
+ }
+
if (old_tu) {
/* delete old event */
ret = unregister_trace_uprobe(old_tu);
--
2.14.4
[PATCH v9 2/4] Uprobes/sdt: Prevent multiple reference counter for same uprobe
We assume to have only one reference counter for one uprobe.
Don't allow user to register multiple uprobes having same
inode+offset but different reference counter.
Signed-off-by: Ravi Bangoria
Acked-by: Srikar Dronamraju
Reviewed-by: Oleg Nesterov
---
kernel/events/uprobes.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 35065febcb6c..ecee371a59c7 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -679,6 +679,16 @@ static struct uprobe *insert_uprobe(struct uprobe *uprobe)
return u;
}
+static void
+ref_ctr_mismatch_warn(struct uprobe *cur_uprobe, struct uprobe *uprobe)
+{
+ pr_warn("ref_ctr_offset mismatch. inode: 0x%lx offset: 0x%llx "
+ "ref_ctr_offset(old): 0x%llx ref_ctr_offset(new): 0x%llx\n",
+ uprobe->inode->i_ino, (unsigned long long) uprobe->offset,
+ (unsigned long long) cur_uprobe->ref_ctr_offset,
+ (unsigned long long) uprobe->ref_ctr_offset);
+}
+
static struct uprobe *alloc_uprobe(struct inode *inode, loff_t offset,
loff_t ref_ctr_offset)
{
@@ -698,6 +708,12 @@ static struct uprobe *alloc_uprobe(struct inode *inode,
loff_t offset,
cur_uprobe = insert_uprobe(uprobe);
/* a uprobe exists for this inode:offset combination */
if (cur_uprobe) {
+ if (cur_uprobe->ref_ctr_offset != uprobe->ref_ctr_offset) {
+ ref_ctr_mismatch_warn(cur_uprobe, uprobe);
+ put_uprobe(cur_uprobe);
+ kfree(uprobe);
+ return ERR_PTR(-EINVAL);
+ }
kfree(uprobe);
uprobe = cur_uprobe;
}
@@ -1112,6 +1128,9 @@ static int __uprobe_register(struct inode *inode, loff_t
offset,
uprobe = alloc_uprobe(inode, offset, ref_ctr_offset);
if (!uprobe)
return -ENOMEM;
+ if (IS_ERR(uprobe))
+ return PTR_ERR(uprobe);
+
/*
* We can race with uprobe_unregister()->delete_uprobe().
* Check uprobe_is_active() and retry if it is false.
--
2.14.4
[PATCH v9 1/4] Uprobes: Support SDT markers having reference count (semaphore)
Userspace Statically Defined Tracepoints[1] are dtrace style markers
inside userspace applications. Applications like PostgreSQL, MySQL,
Pthread, Perl, Python, Java, Ruby, Node.js, libvirt, QEMU, glib etc
have these markers embedded in them. These markers are added by developer
at important places in the code. Each marker source expands to a single
nop instruction in the compiled code but there may be additional
overhead for computing the marker arguments which expands to couple of
instructions. In case the overhead is more, execution of it can be
omitted by runtime if() condition when no one is tracing on the marker:
if (reference_counter > 0) {
Execute marker instructions;
}
Default value of reference counter is 0. Tracer has to increment the
reference counter before tracing on a marker and decrement it when
done with the tracing.
Implement the reference counter logic in core uprobe. User will be
able to use it from trace_uprobe as well as from kernel module. New
trace_uprobe definition with reference counter will now be:
:[(ref_ctr_offset)]
where ref_ctr_offset is an optional field. For kernel module, new
variant of uprobe_register() has been introduced:
uprobe_register_refctr(inode, offset, ref_ctr_offset, consumer)
No new variant for uprobe_unregister() because it's assumed to have
only one reference counter for one uprobe.
[1] https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation
Note: 'reference counter' is called as 'semaphore' in original Dtrace
(or Systemtap, bcc and even in ELF) documentation and code. But the
term 'semaphore' is misleading in this context. This is just a counter
used to hold number of tracers tracing on a marker. This is not really
used for any synchronization. So we are calling it a 'reference counter'
in kernel / perf code.
Signed-off-by: Ravi Bangoria
Reviewed-by: Masami Hiramatsu
[Only trace_uprobe.c]
Reviewed-by: Oleg Nesterov
---
include/linux/uprobes.h | 5 +
kernel/events/uprobes.c | 259 ++--
kernel/trace/trace.c| 2 +-
kernel/trace/trace_uprobe.c | 38 ++-
4 files changed, 293 insertions(+), 11 deletions(-)
diff --git a/include/linux/uprobes.h b/include/linux/uprobes.h
index bb9d2084af03..103a48a48872 100644
--- a/include/linux/uprobes.h
+++ b/include/linux/uprobes.h
@@ -123,6 +123,7 @@ extern unsigned long uprobe_get_swbp_addr(struct pt_regs
*regs);
extern unsigned long uprobe_get_trap_addr(struct pt_regs *regs);
extern int uprobe_write_opcode(struct arch_uprobe *auprobe, struct mm_struct
*mm, unsigned long vaddr, uprobe_opcode_t);
extern int uprobe_register(struct inode *inode, loff_t offset, struct
uprobe_consumer *uc);
+extern int uprobe_register_refctr(struct inode *inode, loff_t offset, loff_t
ref_ctr_offset, struct uprobe_consumer *uc);
extern int uprobe_apply(struct inode *inode, loff_t offset, struct
uprobe_consumer *uc, bool);
extern void uprobe_unregister(struct inode *inode, loff_t offset, struct
uprobe_consumer *uc);
extern int uprobe_mmap(struct vm_area_struct *vma);
@@ -160,6 +161,10 @@ uprobe_register(struct inode *inode, loff_t offset, struct
uprobe_consumer *uc)
{
return -ENOSYS;
}
+static inline int uprobe_register_refctr(struct inode *inode, loff_t offset,
loff_t ref_ctr_offset, struct uprobe_consumer *uc)
+{
+ return -ENOSYS;
+}
static inline int
uprobe_apply(struct inode *inode, loff_t offset, struct uprobe_consumer *uc,
bool add)
{
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 919c1ce32beb..35065febcb6c 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -73,6 +73,7 @@ struct uprobe {
struct uprobe_consumer *consumers;
struct inode*inode; /* Also hold a ref to inode */
loff_t offset;
+ loff_t ref_ctr_offset;
unsigned long flags;
/*
@@ -88,6 +89,15 @@ struct uprobe {
struct arch_uprobe arch;
};
+struct delayed_uprobe {
+ struct list_head list;
+ struct uprobe *uprobe;
+ struct mm_struct *mm;
+};
+
+static DEFINE_MUTEX(delayed_uprobe_lock);
+static LIST_HEAD(delayed_uprobe_list);
+
/*
* Execute out of line area: anonymous executable mapping installed
* by the probed task to execute the copy of the original instruction
@@ -282,6 +292,166 @@ static int verify_opcode(struct page *page, unsigned long
vaddr, uprobe_opcode_t
return 1;
}
+static struct delayed_uprobe *
+delayed_uprobe_check(struct uprobe *uprobe, struct mm_struct *mm)
+{
+ struct delayed_uprobe *du;
+
+ list_for_each_entry(du, &delayed_uprobe_list, list)
+ if (du->uprobe == uprobe && du->mm == mm)
+ return du;
+ return NULL;
+}
+
+static int delayed_uprobe_add(struct uprobe *uprobe, struct mm_struct *mm)
+{
+ struct delayed_uprobe *du;
+
+ if (delayed_uprobe_check(uprobe, m
[PATCH v9 0/4] Uprobes: Support SDT markers having reference count (semaphore)
v8 -> v9:
- Rebased to rostedt/for-next (Commit bb730b5833b5 to be precise)
- Not including first two patches now. They are already pulled by
Steven.
- Change delayed_uprobe_remove() function as suggested by Oleg
- Dump inode, offset, ref_ctr_offset, mm etc if we fail to update
reference counter.
- Rename delayed_uprobe_install() to delayed_ref_ctr_inc()
- Use 'short d' (delta) in update_ref_ctr() in place of 'bool
is_register'.
v8: https://lkml.org/lkml/2018/8/9/81
Future work:
- Optimize uprobe_mmap()->delayed_ref_ctr_inc() by making
delayed_uprobe_list per mm.
Description:
Userspace Statically Defined Tracepoints[1] are dtrace style markers
inside userspace applications. Applications like PostgreSQL, MySQL,
Pthread, Perl, Python, Java, Ruby, Node.js, libvirt, QEMU, glib etc
have these markers embedded in them. These markers are added by developer
at important places in the code. Each marker source expands to a single
nop instruction in the compiled code but there may be additional
overhead for computing the marker arguments which expands to couple of
instructions. In case the overhead is more, execution of it can be
omitted by runtime if() condition when no one is tracing on the marker:
if (reference_counter > 0) {
Execute marker instructions;
}
Default value of reference counter is 0. Tracer has to increment the
reference counter before tracing on a marker and decrement it when
done with the tracing.
Currently, perf tool has limited supports for SDT markers. I.e. it
can not trace markers surrounded by reference counter. Also, it's
not easy to add reference counter logic in userspace tool like perf,
so basic idea for this patchset is to add reference counter logic in
the a uprobe infrastructure. Ex,[2]
# cat tick.c
...
for (i = 0; i < 100; i++) {
DTRACE_PROBE1(tick, loop1, i);
if (TICK_LOOP2_ENABLED()) {
DTRACE_PROBE1(tick, loop2, i);
}
printf("hi: %d\n", i);
sleep(1);
}
...
Here tick:loop1 is marker without reference counter where as tick:loop2
is surrounded by reference counter condition.
# perf buildid-cache --add /tmp/tick
# perf probe sdt_tick:loop1
# perf probe sdt_tick:loop2
# perf stat -e sdt_tick:loop1,sdt_tick:loop2 -- /tmp/tick
hi: 0
hi: 1
hi: 2
^C
Performance counter stats for '/tmp/tick':
3 sdt_tick:loop1
0 sdt_tick:loop2
2.747086086 seconds time elapsed
Perf failed to record data for tick:loop2. Same experiment with this
patch series:
# ./perf buildid-cache --add /tmp/tick
# ./perf probe sdt_tick:loop2
# ./perf stat -e sdt_tick:loop2 /tmp/tick
hi: 0
hi: 1
hi: 2
^C
Performance counter stats for '/tmp/tick':
3 sdt_tick:loop2
2.561851452 seconds time elapsed
[1] https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation
[2] https://github.com/iovisor/bcc/issues/327#issuecomment-200576506
Ravi Bangoria (4):
Uprobes: Support SDT markers having reference count (semaphore)
Uprobes/sdt: Prevent multiple reference counter for same uprobe
trace_uprobe/sdt: Prevent multiple reference counter for same uprobe
perf probe: Support SDT markers having reference counter (semaphore)
include/linux/uprobes.h | 5 +
kernel/events/uprobes.c | 278 --
kernel/trace/trace.c | 2 +-
kernel/trace/trace_uprobe.c | 75 +++-
tools/perf/util/probe-event.c | 39 +-
tools/perf/util/probe-event.h | 1 +
tools/perf/util/probe-file.c | 34 +-
tools/perf/util/probe-file.h | 1 +
tools/perf/util/symbol-elf.c | 46 +--
tools/perf/util/symbol.h | 7 ++
10 files changed, 453 insertions(+), 35 deletions(-)
--
2.14.4
Re: [PATCH] x86/process: Export start_thread()
On 2018-08-19 19:29, Andy Lutomirski wrote:
On Aug 19, 2018, at 4:08 PM, Rian Hunter wrote:
Commit e634d8fc792c ("x86-64: merge the standard and compat
start_thread() functions") removed exporting for the start_thread()
function in what seems like a typo. Add it back to
arch/x86/kernel/process_64.c for parity with process_32.c and other
arch.
What for? Perhaps 32-bit could remove it instead?
Came across this while writing a binfmt module. Useful for me but
probably no one else on Earth, at least for another ~9 years on average.
Signed-off-by: Rian Hunter
---
arch/x86/kernel/process_64.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/process_64.c
b/arch/x86/kernel/process_64.c
index 476e3ddf8890..a451bc374b9b 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -384,6 +384,7 @@ start_thread(struct pt_regs *regs, unsigned long
new_ip, unsigned long new_sp)
start_thread_common(regs, new_ip, new_sp,
__USER_CS, __USER_DS, 0);
}
+EXPORT_SYMBOL_GPL(start_thread);
#ifdef CONFIG_COMPAT
void compat_start_thread(struct pt_regs *regs, u32 new_ip, u32 new_sp)
--
2.16.3
linux-next: manual merge of the akpm-current tree with the tip tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got conflicts in:
fs/proc/kcore.c
include/linux/kcore.h
between commit:
6855dc41b246 ("x86: Add entry trampolines to kcore")
from the tip tree and commits:
4eb27c275abf ("fs/proc/kcore.c: use __pa_symbol() for KCORE_TEXT list
entries")
ea551910d3f4 ("proc/kcore: clean up ELF header generation")
537412a2958f ("proc/kcore: don't grab lock for kclist_add()")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc fs/proc/kcore.c
index 00282f134336,80464432dfe6..
--- a/fs/proc/kcore.c
+++ b/fs/proc/kcore.c
@@@ -448,53 -291,148 +291,151 @@@ static ssize_
read_kcore(struct file *file, char __user *buffer, size_t buflen, loff_t
*fpos)
{
char *buf = file->private_data;
- ssize_t acc = 0;
- size_t size, tsz;
- size_t elf_buflen;
+ size_t phdrs_offset, notes_offset, data_offset;
+ size_t phdrs_len, notes_len;
+ struct kcore_list *m;
+ size_t tsz;
int nphdr;
unsigned long start;
+ size_t orig_buflen = buflen;
+ int ret = 0;
- read_lock(&kclist_lock);
- size = get_kcore_size(&nphdr, &elf_buflen);
+ down_read(&kclist_lock);
+
+ get_kcore_size(&nphdr, &phdrs_len, ¬es_len, &data_offset);
+ phdrs_offset = sizeof(struct elfhdr);
+ notes_offset = phdrs_offset + phdrs_len;
+
+ /* ELF file header. */
+ if (buflen && *fpos < sizeof(struct elfhdr)) {
+ struct elfhdr ehdr = {
+ .e_ident = {
+ [EI_MAG0] = ELFMAG0,
+ [EI_MAG1] = ELFMAG1,
+ [EI_MAG2] = ELFMAG2,
+ [EI_MAG3] = ELFMAG3,
+ [EI_CLASS] = ELF_CLASS,
+ [EI_DATA] = ELF_DATA,
+ [EI_VERSION] = EV_CURRENT,
+ [EI_OSABI] = ELF_OSABI,
+ },
+ .e_type = ET_CORE,
+ .e_machine = ELF_ARCH,
+ .e_version = EV_CURRENT,
+ .e_phoff = sizeof(struct elfhdr),
+ .e_flags = ELF_CORE_EFLAGS,
+ .e_ehsize = sizeof(struct elfhdr),
+ .e_phentsize = sizeof(struct elf_phdr),
+ .e_phnum = nphdr,
+ };
+
+ tsz = min_t(size_t, buflen, sizeof(struct elfhdr) - *fpos);
+ if (copy_to_user(buffer, (char *)&ehdr + *fpos, tsz)) {
+ ret = -EFAULT;
+ goto out;
+ }
- if (buflen == 0 || *fpos >= size) {
- read_unlock(&kclist_lock);
- return 0;
+ buffer += tsz;
+ buflen -= tsz;
+ *fpos += tsz;
}
- /* trim buflen to not go beyond EOF */
- if (buflen > size - *fpos)
- buflen = size - *fpos;
-
- /* construct an ELF core header if we'll need some of it */
- if (*fpos < elf_buflen) {
- char * elf_buf;
-
- tsz = elf_buflen - *fpos;
- if (buflen < tsz)
- tsz = buflen;
- elf_buf = kzalloc(elf_buflen, GFP_ATOMIC);
- if (!elf_buf) {
- read_unlock(&kclist_lock);
- return -ENOMEM;
+ /* ELF program headers. */
+ if (buflen && *fpos < phdrs_offset + phdrs_len) {
+ struct elf_phdr *phdrs, *phdr;
+
+ phdrs = kzalloc(phdrs_len, GFP_KERNEL);
+ if (!phdrs) {
+ ret = -ENOMEM;
+ goto out;
}
- elf_kcore_store_hdr(elf_buf, nphdr, elf_buflen);
- read_unlock(&kclist_lock);
- if (copy_to_user(buffer, elf_buf + *fpos, tsz)) {
- kfree(elf_buf);
- return -EFAULT;
+
+ phdrs[0].p_type = PT_NOTE;
+ phdrs[0].p_offset = notes_offset;
+ phdrs[0].p_filesz = notes_len;
+
+ phdr = &phdrs[1];
+ list_for_each_entry(m, &kclist_head, list) {
+ phdr->p_type = PT_LOAD;
+ phdr->p_flags = PF_R | PF_W | PF_X;
+ phdr->p_offset = kc_vaddr_to_offset(m->addr) +
data_offset;
- phdr->p_vaddr = (size_t)m->addr;
- if (m->type == KCORE_RAM)
++ if (m-
KASAN: slab-out-of-bounds Read in rdma_listen
Hello, syzbot found the following crash on: HEAD commit:5c60a7389d79 Merge tag 'for-linus-4.19-ofs1' of git://git... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=10bf9aee40 kernel config: https://syzkaller.appspot.com/x/.config?x=4fd89f99c889a184 dashboard link: https://syzkaller.appspot.com/bug?extid=c92378b32760a4eef756 compiler: gcc (GCC) 8.0.1 20180413 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+c92378b32760a4eef...@syzkaller.appspotmail.com == BUG: KASAN: slab-out-of-bounds in __list_add_valid+0x8f/0xb0 lib/list_debug.c:26 Read of size 8 at addr 880188b13098 by task syz-executor6/27383 CPU: 1 PID: 27383 Comm: syz-executor6 Not tainted 4.18.0+ #193 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 print_address_description+0x6c/0x20b mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 __list_add_valid+0x8f/0xb0 lib/list_debug.c:26 __list_add include/linux/list.h:60 [inline] list_add_tail include/linux/list.h:93 [inline] cma_listen_on_all drivers/infiniband/core/cma.c:2328 [inline] rdma_listen+0x6dc/0x990 drivers/infiniband/core/cma.c:3354 ucma_listen+0x1a4/0x260 drivers/infiniband/core/ucma.c:1096 ucma_write+0x336/0x420 drivers/infiniband/core/ucma.c:1680 __vfs_write+0x117/0x9d0 fs/read_write.c:485 vfs_write+0x1f8/0x560 fs/read_write.c:549 ksys_write+0x101/0x260 fs/read_write.c:598 __do_sys_write fs/read_write.c:610 [inline] __se_sys_write fs/read_write.c:607 [inline] __x64_sys_write+0x73/0xb0 fs/read_write.c:607 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457089 Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f211d28dc78 EFLAGS: 0246 ORIG_RAX: 0001 RAX: ffda RBX: 7f211d28e6d4 RCX: 00457089 RDX: 0010 RSI: 2080 RDI: 0004 RBP: 009300a0 R08: R09: R10: R11: 0246 R12: R13: 004d7448 R14: 004ca592 R15: Allocated by task 2291: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490 kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554 getname_flags+0xd0/0x5a0 fs/namei.c:140 getname+0x19/0x20 fs/namei.c:211 do_sys_open+0x3a2/0x760 fs/open.c:1055 __do_sys_open fs/open.c:1079 [inline] __se_sys_open fs/open.c:1074 [inline] __x64_sys_open+0x7e/0xc0 fs/open.c:1074 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 2291: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kmem_cache_free+0x86/0x2d0 mm/slab.c:3756 putname+0xf2/0x130 fs/namei.c:261 do_sys_open+0x569/0x760 fs/open.c:1070 __do_sys_open fs/open.c:1079 [inline] __se_sys_open fs/open.c:1074 [inline] __x64_sys_open+0x7e/0xc0 fs/open.c:1074 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at 880188b12000 which belongs to the cache names_cache of size 4096 The buggy address is located 152 bytes to the right of 4096-byte region [880188b12000, 880188b13000) The buggy address belongs to the page: page:ea000622c480 count:1 mapcount:0 mapping:8801dad85dc0 index:0x0 compound_mapcount: 0 flags: 0x2fffc008100(slab|head) raw: 02fffc008100 ea00074e8708 ea00073cdb08 8801dad85dc0 raw: 880188b12000 00010001 page dumped because: kasan: bad access detected Memory state around the buggy address: 880188b12f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 880188b13000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 880188b13080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ 880188b13100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc 880188b13180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc == --- This bug is generated by a bot. It may contain errors.
[PATCH] UBIFS: Fix typo of output in get_cs_sqnum
"Not a CS node" makes more sense than "Node a CS node".
Signed-off-by: Liu Song
Reviewed-by: Jiang Biao
---
fs/ubifs/recovery.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ubifs/recovery.c b/fs/ubifs/recovery.c
index 3af4472061cc..400163dc7022 100644
--- a/fs/ubifs/recovery.c
+++ b/fs/ubifs/recovery.c
@@ -829,7 +829,7 @@ static int get_cs_sqnum(struct ubifs_info *c, int lnum, int
offs,
goto out_err;
}
if (cs_node->ch.node_type != UBIFS_CS_NODE) {
- ubifs_err(c, "Node a CS node, type is %d",
cs_node->ch.node_type);
+ ubifs_err(c, "Not a CS node, type is %d",
cs_node->ch.node_type);
goto out_err;
}
if (le64_to_cpu(cs_node->cmt_no) != c->cmt_no) {
--
2.17.1
[PATCH] mtd: nand: denali: use SPDX-License-Identifier and fix license mismatch
Use SPDX-License-Identifier instead of the license boilerplates.
This conversion makes it easier for us to scan the license, then
I notice license mismatch problems.
The license blocks in denali* indicate GPL-2.0 "only", while the
MODULE_LICENSE in denali.c and denali_dt.c is GPL-2.0 "or later"
as explained in include/linux/module.h as follows:
"GPL" [GNU Public License v2 or later]
"GPL v2"[GNU Public License v2]
I fixed the MODULE_LICENSE tags, assuming the license blocks are
the authors' intention.
Also, add missing MODULE_DESCRIPTION/AUTHOR to denali.c
While I am touching the license things, I added my credit to denali.c
because this driver was largely re-written by me in 2017.
Signed-off-by: Masahiro Yamada
---
drivers/mtd/nand/raw/denali.c | 17 +++--
drivers/mtd/nand/raw/denali.h | 10 +-
drivers/mtd/nand/raw/denali_dt.c | 12 ++--
drivers/mtd/nand/raw/denali_pci.c | 10 +-
4 files changed, 11 insertions(+), 38 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index ca18612..9f432f0 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -1,15 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* NAND Flash Controller Device Driver
* Copyright © 2009-2010, Intel Corporation and its suppliers.
*
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
- * more details.
+ * Copyright (c) 2017 Socionext Inc.
+ * Reworked by Masahiro Yamada
*/
#include
@@ -25,8 +20,6 @@
#include "denali.h"
-MODULE_LICENSE("GPL");
-
#define DENALI_NAND_NAME"denali-nand"
/* for Indexed Addressing */
@@ -1396,3 +1389,7 @@ void denali_remove(struct denali_nand_info *denali)
denali_disable_irq(denali);
}
EXPORT_SYMBOL(denali_remove);
+
+MODULE_DESCRIPTION("Driver core for Denali NAND controller");
+MODULE_AUTHOR("Intel Corporation and its suppliers");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/mtd/nand/raw/denali.h b/drivers/mtd/nand/raw/denali.h
index 1f8feaf..57a5498 100644
--- a/drivers/mtd/nand/raw/denali.h
+++ b/drivers/mtd/nand/raw/denali.h
@@ -1,15 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 */
/*
* NAND Flash Controller Device Driver
* Copyright (c) 2009 - 2010, Intel Corporation and its suppliers.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
- * more details.
*/
#ifndef __DENALI_H__
diff --git a/drivers/mtd/nand/raw/denali_dt.c b/drivers/mtd/nand/raw/denali_dt.c
index 0faaad0..7c6a8a4 100644
--- a/drivers/mtd/nand/raw/denali_dt.c
+++ b/drivers/mtd/nand/raw/denali_dt.c
@@ -1,16 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* NAND Flash Controller Device Driver for DT
*
* Copyright © 2011, Picochip.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
- * more details.
*/
#include
@@ -202,6 +194,6 @@ static struct platform_driver denali_dt_driver = {
};
module_platform_driver(denali_dt_driver);
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Jamie Iles");
MODULE_DESCRIPTION("DT driver for Denali NAND controller");
diff --git a/drivers/mtd/nand/raw/denali_pci.c
b/drivers/mtd/nand/raw/denali_pci.c
index 7c8efc4..48e9ac5 100644
--- a/drivers/mtd/nand/raw/denali_pci.c
+++ b/drivers/mtd/nand/raw/denali_pci.c
@@ -1,15 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* NAND Flash Controller Device Driver
* Copyright © 2009-2010, Intel Corporation and its suppliers.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABIL
Re: [PATCH] x86/process: Export start_thread()
> On Aug 19, 2018, at 4:08 PM, Rian Hunter wrote:
>
> Commit e634d8fc792c ("x86-64: merge the standard and compat
> start_thread() functions") removed exporting for the start_thread()
> function in what seems like a typo. Add it back to
> arch/x86/kernel/process_64.c for parity with process_32.c and other
> arch.
What for? Perhaps 32-bit could remove it instead?
>
> Signed-off-by: Rian Hunter
> ---
> arch/x86/kernel/process_64.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
> index 476e3ddf8890..a451bc374b9b 100644
> --- a/arch/x86/kernel/process_64.c
> +++ b/arch/x86/kernel/process_64.c
> @@ -384,6 +384,7 @@ start_thread(struct pt_regs *regs, unsigned long new_ip,
> unsigned long new_sp)
>start_thread_common(regs, new_ip, new_sp,
>__USER_CS, __USER_DS, 0);
> }
> +EXPORT_SYMBOL_GPL(start_thread);
>
> #ifdef CONFIG_COMPAT
> void compat_start_thread(struct pt_regs *regs, u32 new_ip, u32 new_sp)
> --
> 2.16.3
>
Re: linux-next: build warnings from Linus' tree
On Mon, Aug 20, 2018 at 03:33:19AM +0200, Adam Borowski wrote: > Valid uses of strncpy() do exist (such as SCSI structs), but those deal with > fixed-width fields. Thus, gcc is right for warning for at least some of > misuse of strncpy() for C strings. The function wasn't designed for them. The problem is that the kernel has a goodly share of fixed-width fields. The ext4 superblock is one of them. strncpy() is the most convenient function to do what is needed. If it's a valid use, then we need to have a way to get gcc to shut up about them. - Ted
RE: [PATCHv4 00/12] sched/fair: Migrate 'misfit' tasks on asymmetric capacity systems
Hi, > -Original Message- > From: Morten Rasmussen > Sent: Wednesday, July 4, 2018 7:18 PM > To: pet...@infradead.org; mi...@redhat.com > Cc: valentin.schnei...@arm.com; dietmar.eggem...@arm.com; > vincent.guit...@linaro.org; Gaku Inami > ; linux-kernel@vger.kernel.org; Morten Rasmussen > > Subject: [PATCHv4 00/12] sched/fair: Migrate 'misfit' tasks on asymmetric > capacity systems [snip] > The patches have been tested on: >1. Arm Juno (r0): 2+4 Cortex A57/A53 >2. Hikey960: 4+4 Cortex A73/A53 > > Test case: > Big cpus are always kept busy. Pin a shorter running sysbench tasks to > big cpus, while creating a longer running set of unpinned sysbench > tasks. I have tested v4 patches on Renesas SoC again. It looks fine. You can add: Tested-by: Gaku Inami The patches have been tested on: 3. Renesas R-Car H3 : 4+4 Cortex A57/A53 Results: Single runs with completion time of each task R-Car H3 (tip) total time: 0.9488s total time: 0.9766s total time: 1.3243s total time: 1.6740s R-Car H3 (misfit) total time: 0.9313s total time: 0.9214s total time: 0.9493s total time: 0.9606s 10 run summary (tracking longest running task for each run) R-Car H3 avg max tip 1.6744 1.6780 misfit 0.9616 1.0290 Also, I confirmed that these patches bring performance improvement to some benchmarks(UnixBench, LMbench). So they have very useful for Renesas SoC. [snip] Regards, Inami
IF U ARE TOCH ON MY MESSAGE PLS REPLY ME,,
Friend, My name is Miss Qadesa AbdulAziz and I am 17 years old girl from Syria. There is serious war crisis here in Syria, and I have lost my parents and my two brothers in this war. I want you to help me and receive ($7.md) which my late father deposited with my name in a bank in London. I want to come to your country and start a new life and invest with you, because am the only survival in my family. I wait to hear from you, Please do not let me die here, I begging you the name of Almighty. please respond here my pirate email qad...@protonmail.com Regards Miss Qadesa AbdulAziz
[PATCH 1/2] nds32: Remove the deprecated ABI implementation
We are not using NDS32 ABI 2 for now, just remove the preprocessor
directives __NDS32_ABI_2.
Signed-off-by: Zong Li
---
arch/nds32/kernel/traps.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/nds32/kernel/traps.c b/arch/nds32/kernel/traps.c
index 7684c8f..f432310 100644
--- a/arch/nds32/kernel/traps.c
+++ b/arch/nds32/kernel/traps.c
@@ -117,13 +117,8 @@ static void __dump(struct task_struct *tsk, unsigned long
*base_reg)
!((unsigned long)base_reg & 0x3) &&
((unsigned long)base_reg >= TASK_SIZE)) {
unsigned long next_fp;
-#if !defined(__NDS32_ABI_2)
- ret_addr = base_reg[0];
- next_fp = base_reg[1];
-#else
ret_addr = base_reg[-1];
next_fp = base_reg[FP_OFFSET];
-#endif
if (__kernel_text_address(ret_addr)) {
ret_addr = ftrace_graph_ret_addr(
--
2.7.4
[PATCH 2/2] nds32: Add macro definition for offset of lp register on stack
Use macro to replace the magic number.
Signed-off-by: Zong Li
---
arch/nds32/include/asm/nds32.h | 1 +
arch/nds32/kernel/stacktrace.c | 2 +-
arch/nds32/kernel/traps.c | 2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/nds32/include/asm/nds32.h b/arch/nds32/include/asm/nds32.h
index 19b1939..68c3815 100644
--- a/arch/nds32/include/asm/nds32.h
+++ b/arch/nds32/include/asm/nds32.h
@@ -17,6 +17,7 @@
#else
#define FP_OFFSET (-2)
#endif
+#define LP_OFFSET (-1)
extern void __init early_trap_init(void);
static inline void GIE_ENABLE(void)
diff --git a/arch/nds32/kernel/stacktrace.c b/arch/nds32/kernel/stacktrace.c
index 36bc870..d974c0c 100644
--- a/arch/nds32/kernel/stacktrace.c
+++ b/arch/nds32/kernel/stacktrace.c
@@ -31,7 +31,7 @@ void save_stack_trace_tsk(struct task_struct *tsk, struct
stack_trace *trace)
&& (fpn >= (unsigned long *)TASK_SIZE)) {
unsigned long lpp, fpp;
- lpp = fpn[-1];
+ lpp = fpn[LP_OFFSET];
fpp = fpn[FP_OFFSET];
if (!__kernel_text_address(lpp))
break;
diff --git a/arch/nds32/kernel/traps.c b/arch/nds32/kernel/traps.c
index f432310..b0b85b7 100644
--- a/arch/nds32/kernel/traps.c
+++ b/arch/nds32/kernel/traps.c
@@ -117,7 +117,7 @@ static void __dump(struct task_struct *tsk, unsigned long
*base_reg)
!((unsigned long)base_reg & 0x3) &&
((unsigned long)base_reg >= TASK_SIZE)) {
unsigned long next_fp;
- ret_addr = base_reg[-1];
+ ret_addr = base_reg[LP_OFFSET];
next_fp = base_reg[FP_OFFSET];
if (__kernel_text_address(ret_addr)) {
--
2.7.4
[PATCH 0/2] Remove the deprecated ABI implementation
This patches remove the implementation of NDS32_ABI_2 and replace the magic number of offset of lp on stack. In stacktrace.c, we dump the stack without considering the old ABI, it should be consistent in traps.c. Zong Li (2): nds32: Remove the deprecated ABI implementation nds32: Add macro definition for offset of lp register on stack arch/nds32/include/asm/nds32.h | 1 + arch/nds32/kernel/stacktrace.c | 2 +- arch/nds32/kernel/traps.c | 7 +-- 3 files changed, 3 insertions(+), 7 deletions(-) -- 2.7.4
Re: [PATCH v2] i2c: Remove '-Wno-deprecated-declarations' compiler warning
On Sun, 2018-08-19 at 09:46 -0700, Linus Torvalds wrote:
> On Sun, Aug 19, 2018 at 6:51 AM Sedat Dilek wrote:
> >
> > This can be dropped with commit 771c035372a036f83353eef46dbb829780330234
> > ("deprecate the '__deprecated' attribute warnings entirely and for good")
> > now in upstream.
>
> Could we please just remove the __deprecated use in i2c entirely?
>
> As fat as I can tell, it's used for one thing, which is the
> "attach_adapter" function pointer member in 'struct i2c_driver'.
>
> And I think there is _one_ remaining driver using it, namely the
> powermac "therm_windtunnel" driver.
>
> Could somebody who knows the i2c probing just a bit convert that *one*
> remaining driver, then remove the "attach_adapter" entirely, and also
> remove this thing?
>
> Alternatively, perhaps the driver should be removed? The last actual
> powermac change to that driver seems to be from August 2009.
> Everything since has been just cleanup unrelated to that driver code
> itself (ie spelling fixes, automated coccinelle scripts etc).
>
> Added a few people either because they're still officially maintainers
> of that file, or because they touched the code ten years ago.
Some people still use those old machines, I'll give a try at fixing the
driver.
Paul: Do you still have one of these machines ?
Cheers
Ben.
Re: [RFC PATCH 1/6] Revert "PCI: Fix is_added/is_busmaster race condition"
On Sat, 2018-08-18 at 21:24 -0500, Bjorn Helgaas wrote: > On Sat, Aug 18, 2018 at 01:24:51PM +1000, Benjamin Herrenschmidt wrote: > > On Fri, 2018-08-17 at 10:44 -0500, Bjorn Helgaas wrote: > > > On Fri, Aug 17, 2018 at 02:48:57PM +1000, Benjamin Herrenschmidt wrote: > > > > This reverts commit 44bda4b7d26e9fffed6d7152d98a2e9edaeb2a76. > > > > > > Just to be clear, if I understand correctly, this is a pure revert of > > > 44bda4b7d26e and as such it reintroduces the problem solved by that > > > commit. > > > > > > If your solution turns out to be better, that's great, but it would be > > > nice to avoid the bisection hole of reintroducing the problem, then > > > fixing it again later. > > > > There is no way to do that other than merging the revert and the fix > > into one. That said, the race is sufficiently hard to hit that I > > wouldn't worry too much about it. > > OK, then at least mention that in the changelog. Sure will do. This is just RFC at this stage :-) As for the race with enable, what's your take on my approach ? The basic premise is that we need some kind of mutex to make the updates to enable_cnt and the actual config space changes atomic. While at it we can fold pci_set_master vs. is_busmaster as well as those are racy too. I chose to create a new mutex which we should be able to address other similar races if we find them. The other solutions that I dismissed were: - Using the device_lock. A explained previously, this is tricky, I prefer not using this for anything other than locking against concurrent add/remove. The main issue is that drivers will be sometimes called in context where that's already held, so we can't take it inside pci_enable_device() and I'd rather not add new constraints such as "pci_enable_device() must be only called from probe() unless you also take the device lock". It would be tricky to audit everybody... - Using a global mutex. We could move the bridge lock from AER to core code for example, and use that. But it doesn't buy us much, and slightly redecuces parallelism. It also makes it a little bit more messy to walk up the bridge chain, we'd have to do a pci_enable_device_unlocked or something, messy. So are you ok with the approach ? Do you prefer one of the above regardless ? Something else ? Cheers, Ben.
tools/include/asm-generic/bitsperlong.h:14:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
Hi Alexei, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 2ad0d52699700a91660a406a4046017a2d7f246a commit: 819dd92b9c0bc7bce9097d8c1f14240f471bb386 bpfilter: switch to CC from HOSTCC date: 3 months ago config: alpha-allyesconfig (attached as .config) compiler: alpha-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 819dd92b9c0bc7bce9097d8c1f14240f471bb386 # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=alpha All errors (new ones prefixed by >>): In file included from tools/include/uapi/asm/bitsperlong.h:17:0, from /usr/alpha-linux-gnu/include/asm-generic/int-l64.h:11, from /usr/alpha-linux-gnu/include/asm/types.h:12, from tools/include/linux/types.h:10, from ./include/uapi/linux/bpf.h:11, from net//bpfilter/main.c:9: >> tools/include/asm-generic/bitsperlong.h:14:2: error: #error Inconsistent >> word size. Check asm/bitsperlong.h #error Inconsistent word size. Check asm/bitsperlong.h ^ vim +14 tools/include/asm-generic/bitsperlong.h bb970707 Arnaldo Carvalho de Melo 2016-07-12 12 2a00f026 Arnaldo Carvalho de Melo 2016-07-13 13 #if BITS_PER_LONG != __BITS_PER_LONG bb970707 Arnaldo Carvalho de Melo 2016-07-12 @14 #error Inconsistent word size. Check asm/bitsperlong.h bb970707 Arnaldo Carvalho de Melo 2016-07-12 15 #endif bb970707 Arnaldo Carvalho de Melo 2016-07-12 16 :: The code at line 14 was first introduced by commit :: bb9707077b4ee5f77bc9939b057ff8a0d410296f tools: Copy the bitsperlong.h files from the kernel :: TO: Arnaldo Carvalho de Melo :: CC: Arnaldo Carvalho de Melo --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: linux-next: build warnings from Linus' tree
On Sun, Aug 19, 2018 at 04:21:57PM -0700, Linus Torvalds wrote:
> On Sun, Aug 19, 2018 at 3:13 PM Stephen Rothwell
> wrote:
> >
> > Today's linux-next build (powerpc ppc64_defconfig) produced these
> > warnings:
> >
> > fs/cifs/cifssmb.c:605:3: warning: 'strncpy' writing 16 bytes into a region
> > of size 1 overflows the destination [-Wstringop-overflow=]
> >strncpy(pSMB->DialectsArray+count, protocols[i].name, 16);
> >
> > Presumably caused by my update to gcc 8.2.0.
>
> Yeah. There are some patches to mark some arrays as non-strings to get
> rid of these, but we'll see. Maybe we'll just disable the new gcc
> warning if it causes more pain than it is worth.
Every single use of strncpy() for a C string is either a bug, inefficiency,
or both. In this particular case the code:
count = 0;
for (i = 0; i < CIFS_NUM_PROT; i++) {
strncpy(pSMB->DialectsArray+count, protocols[i].name, 16);
count += strlen(protocols[i].name) + 1;
/* null at end of source and target buffers anyway */
}
* pointlessly clears 16 bytes in every iteration
* calculates the string's length twice
* there's no protection against buffer overflow anyway
So what is the strncpy() there for, when an unbounded copy would be just as
good? For other cases, there's a bunch of better functions: strlcpy(),
snprintf(), even strlen()+memcpy(), etc.
Valid uses of strncpy() do exist (such as SCSI structs), but those deal with
fixed-width fields. Thus, gcc is right for warning for at least some of
misuse of strncpy() for C strings. The function wasn't designed for them.
(Skipped analysis why strncpy is always a bad choice for C strings.)
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17]
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37]
⠈⠳⣄ • use glitches to walk on water [Mt14:25-26]
Re: [RFC PATCH] pci: Proof of concept at fixing pci_enable_device/bridge races
On Thu, Aug 16, 2018 at 09:38:41AM +1000, Benjamin Herrenschmidt wrote: > On Wed, 2018-08-15 at 15:40 -0700, Guenter Roeck wrote: > > On Thu, Aug 16, 2018 at 07:50:13AM +1000, Benjamin Herrenschmidt wrote: > > > (Resent with lkml on copy) > > > > > > [Note: This isn't meant to be merged, it need splitting at the very > > > least, see below] > > > > > > This is something I cooked up quickly today to test if that would fix > > > my problems with large number of switch and NVME devices on POWER. > > > > > > > Is that a problem that can be reproduced with a qemu setup ? > > With difficulty... mt-tcg might help, but you need a rather large > systems to reproduce it. > > My repro-case is a 2 socket POWER9 system (about 40 cores off the top > of my mind, so 160 threads) with 72 NVME devices underneath a tree of > switches (I don't have the system at hand today to check how many). > > It's possible to observe it I suppose on a smaller system (in theory a > single bridge with 2 devices is enough) but in practice the timing is > extremely hard to hit. > > You need a combination of: > > - The bridges come up disabled (which is the case when Linux does the > resource assignment, such as on POWER but not on x86 unless it's > hotplug) > > - The nvme devices try to enable them simultaneously > > Also the resulting error is a UR, I don't know how well qemu models > that. > Not well enough, apparently. I tried for a while, registering as many nvme drives as the system would take, but I was not able to reproduce the problem with qemu. It was worth a try, though. Guenter
Re: [PATCH v2] ASoC: wm9712: fix replace codec to component
Hi
# I know it is very late response
Acked-by: Kuninori Morimoto
> From: Marcel Ziswiler
>
> Since commit 143b44845d87 ("ASoC: wm9712: replace codec to component")
> "wm9712-codec" got renamed to "wm9712-component", however, this change
> never got propagated down to the actual board/platform drivers. E.g. on
> Colibri T20 this lead to the following spew upon boot with sound/touch
> being broken:
>
> [2.214121] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not
> registered
> [2.222137] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
> ...
> [2.344384] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not
> registered
> [2.351885] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
> ...
> [2.668339] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not
> registered
> [2.675811] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
> ...
> [3.208408] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not
> registered
> [3.216312] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
> ...
> [3.235397] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not
> registered
> [3.248938] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
> ...
> [ 14.970443] ALSA device list:
> [ 14.996628] No soundcards found.
>
> This commit finally fixes this again.
>
> Signed-off-by: Marcel Ziswiler
>
> ---
Best regards
---
Kuninori Morimoto
Re: [PATCH v8 2/2] PCI: pciehp: Mask AER surprise link down error if hotplug is enabled
Hi Sinan,
I love your patch! Yet something to improve:
[auto build test ERROR on pci/next]
[also build test ERROR on next-20180817]
[cannot apply to v4.18]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Sinan-Kaya/PCI-pciehp-Ignore-link-events-when-there-is-a-fatal-error-pending/20180820-074636
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: i386-randconfig-x075-201833 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/pci/hotplug/pciehp_core.c: In function
'pciehp_control_surprise_error':
>> drivers/pci/hotplug/pciehp_core.c:241:14: error: 'struct pci_dev' has no
>> member named 'aer_cap'; did you mean 'ats_cap'?
pos = pdev->aer_cap;
^~~
ats_cap
vim +241 drivers/pci/hotplug/pciehp_core.c
231
232 static int pciehp_control_surprise_error(struct controller *ctrl, bool
enable)
233 {
234 struct pci_dev *pdev = ctrl->pcie->port;
235 u32 reg32;
236 int pos;
237
238 if (!pci_is_pcie(pdev))
239 return -ENODEV;
240
> 241 pos = pdev->aer_cap;
242 if (!pos)
243 return -ENODEV;
244
245 pci_read_config_dword(pdev, pos + PCI_ERR_UNCOR_MASK, ®32);
246 if (enable)
247 reg32 &= ~PCI_ERR_UNC_SURPDN;
248 else
249 reg32 |= PCI_ERR_UNC_SURPDN;
250 pci_write_config_dword(pdev, pos + PCI_ERR_UNCOR_MASK, reg32);
251
252 return 0;
253 }
254
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH V2] arm64: dts: sdm630 SoC and Sony Pioneer (Xperia XA2) support
Hi Craig, Thank you for the patch! Yet something to improve: [auto build test ERROR on agross/for-next] [also build test ERROR on v4.18 next-20180817] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Craig-Tatlor/arm64-dts-sdm630-SoC-and-Sony-Pioneer-Xperia-XA2-support/20180813-040803 base: https://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git for-next config: arm64-allnoconfig (attached as .config) compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=arm64 All errors (new ones prefixed by >>): In file included from arch/arm64/boot/dts/qcom/sdm630-pioneer.dtsi:4:0, from arch/arm64/boot/dts/qcom/sdm630-pioneer.dts:6: >> arch/arm64/boot/dts/qcom/sdm630.dtsi:5:10: fatal error: >> dt-bindings/clock/qcom,gcc-sdm660.h: No such file or directory #include ^ compilation terminated. vim +5 arch/arm64/boot/dts/qcom/sdm630.dtsi 3 4 #include > 5 #include 6 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: linux-next: build warnings from Linus' tree
On Mon, Aug 20, 2018 at 08:13:23AM +1000, Stephen Rothwell wrote:
> fs/ext4/super.c: In function '__save_error_info':
> fs/ext4/super.c:344:2: warning: 'strncpy' specified bound 32 equals
> destination size [-Wstringop-truncation]
> strncpy(es->s_last_error_func, func, sizeof(es->s_last_error_func));
> ^~~
> fs/ext4/super.c:349:3: warning: 'strncpy' specified bound 32 equals
> destination size [-Wstringop-truncation]
>strncpy(es->s_first_error_func, func,
>^
> sizeof(es->s_first_error_func));
> ~~~
All of ext4 superblock char[] fields are not necessarily null
terminated, so this is a false positive. I suppose we could do
something like this:
inline char *
strncpy_I_solemnly_swear_I_know_what_I_am_doing(char *dest,
const char *src, size_t n)
{
#if __GNUC_PREREQ (8, 2)
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wstringop-truncate"
#endif
return strncpy(dest, src, n);
#if __GNUC_PREREQ (8, 2)
#pragma GCC diagnostic pop
#endif
}
(if we really think this warning is worthwhile enough that we don't
just want to globally disable it, of course)
- Ted
P.S. It's really, really too bad there isn't a simpler way to shut up
gcc. You need the #ifdef __GNUC_PREREQ nonsense because otherwise
older versions of gcc that don't understand the particular warning
you're trying to suppress will complain loudly. (Ask me how I
know)
Re: [PATCH] gpio: 74x164: add lines-initial-states property
Hi Linus, On 8/16/18 10:11 AM, Linus Walleij wrote: > This sounds like something that should be generic, and not use > a bitmask, but offsets. It should work even if the number of > GPIOs from the chip is > 32. > > Is the usecase different from hogs? > See Documentation/devicetree/bindings/gpio.txt Thanks for pointing that out. Indeed for my use-case (Asserting single output to be high on driver probe) hogs are are sufficient solution. Best wishes David
cgroup aware oom killer (was Re: [PATCH 0/3] introduce memory.oom.group)
Roman, have you had time to go through this?
On Tue, 7 Aug 2018, David Rientjes wrote:
> On Mon, 6 Aug 2018, Roman Gushchin wrote:
>
> > > In a cgroup-aware oom killer world, yes, we need the ability to specify
> > > that the usage of the entire subtree should be compared as a single
> > > entity with other cgroups. That is necessary for user subtrees but may
> > > not be necessary for top-level cgroups depending on how you structure
> > > your
> > > unified cgroup hierarchy. So it needs to be configurable, as you
> > > suggest,
> > > and you are correct it can be different than oom.group.
> > >
> > > That's not the only thing we need though, as I'm sure you were expecting
> > > me to say :)
> > >
> > > We need the ability to preserve existing behavior, i.e. process based and
> > > not cgroup aware, for subtrees so that our users who have clear
> > > expectations and tune their oom_score_adj accordingly based on how the
> > > oom
> > > killer has always chosen processes for oom kill do not suddenly regress.
> >
> > Isn't the combination of oom.group=0 and oom.evaluate_together=1 describing
> > this case? This basically means that if memcg is selected as target,
> > the process inside will be selected using traditional per-process approach.
> >
>
> No, that would overload the policy and mechanism. We want the ability to
> consider user-controlled subtrees as a single entity for comparison with
> other user subtrees to select which subtree to target. This does not
> imply that users want their entire subtree oom killed.
>
> > > So we need to define the policy for a subtree that is oom, and I suggest
> > > we do that as a characteristic of the cgroup that is oom ("process" vs
> > > "cgroup", and process would be the default to preserve what currently
> > > happens in a user subtree).
> >
> > I'm not entirely convinced here.
> > I do agree, that some sub-tree may have a well tuned oom_score_adj,
> > and it's preferable to keep the current behavior.
> >
> > At the same time I don't like the idea to look at the policy of the OOMing
> > cgroup. Why exceeding of one limit should be handled different to exceeding
> > of another? This seems to be a property of workload, not a limit.
> >
>
> The limit is the property of the mem cgroup, so it's logical that the
> policy when reaching that limit is a property of the same mem cgroup.
> Using the user-controlled subtree example, if we have /david and /roman,
> we can define our own policies on oom, we are not restricted to cgroup
> aware selection on the entire hierarchy. /david/oom.policy can be
> "process" so that I haven't regressed with earlier kernels, and
> /roman/oom.policy can be "cgroup" to target the largest cgroup in your
> subtree.
>
> Something needs to be oom killed when a mem cgroup at any level in the
> hierarchy is reached and reclaim has failed. What to do when that limit
> is reached is a property of that cgroup.
>
> > > Now, as users who rely on process selection are well aware, we have
> > > oom_score_adj to influence the decision of which process to oom kill. If
> > > our oom subtree is cgroup aware, we should have the ability to likewise
> > > influence that decision. For example, we have high priority applications
> > > that run at the top-level that use a lot of memory and strictly oom
> > > killing them in all scenarios because they use a lot of memory isn't
> > > appropriate. We need to be able to adjust the comparison of a cgroup (or
> > > subtree) when compared to other cgroups.
> > >
> > > I've also suggested, but did not implement in my patchset because I was
> > > trying to define the API and find common ground first, that we have a
> > > need
> > > for priority based selection. In other words, define the priority of a
> > > subtree regardless of cgroup usage.
> > >
> > > So with these four things, we have
> > >
> > > - an "oom.policy" tunable to define "cgroup" or "process" for that
> > >subtree (and plans for "priority" in the future),
> > >
> > > - your "oom.evaluate_as_group" tunable to account the usage of the
> > >subtree as the cgroup's own usage for comparison with others,
> > >
> > > - an "oom.adj" to adjust the usage of the cgroup (local or subtree)
> > >to protect important applications and bias against unimportant
> > >applications.
> > >
> > > This adds several tunables, which I didn't like, so I tried to overload
> > > oom.policy and oom.evaluate_as_group. When I referred to separating out
> > > the subtree usage accounting into a separate tunable, that is what I have
> > > referenced above.
> >
> > IMO, merging multiple tunables into one doesn't make it saner.
> > The real question how to make a reasonable interface with fever tunables.
> >
> > The reason behind introducing all these knobs is to provide
> > a generic solution to define OOM handling rules, but then the
> > question raises if the kernel is the best place for it.
> >
Re: [PATCH v8 2/2] PCI: pciehp: Mask AER surprise link down error if hotplug is enabled
On 8/18/2018 2:51 AM, Sinan Kaya wrote: cleanup_slot(ctrl); + pciehp_control_surprise_error(ctrl, true); I think I need to move this one line up but I'd like to see some input here and also ask for some testing. I don't have any hardware to test.
Re: linux-next: build warnings from Linus' tree
On Sun, Aug 19, 2018 at 3:13 PM Stephen Rothwell wrote: > > Today's linux-next build (powerpc ppc64_defconfig) produced these > warnings: > > fs/cifs/cifssmb.c:605:3: warning: 'strncpy' writing 16 bytes into a region of > size 1 overflows the destination [-Wstringop-overflow=] >strncpy(pSMB->DialectsArray+count, protocols[i].name, 16); > > Presumably caused by my update to gcc 8.2.0. Yeah. There are some patches to mark some arrays as non-strings to get rid of these, but we'll see. Maybe we'll just disable the new gcc warning if it causes more pain than it is worth. Linus
[PATCH v8 1/2] PCI: pciehp: Ignore link events when there is a fatal error pending
AER/DPC reset is known as warm-resets. HP link recovery is known as
cold-reset via power-off and power-on command to the PCI slot.
In the middle of a warm-reset operation (AER/DPC), we are:
1. turning off the slow power. Slot power needs to be kept on in order
for recovery to succeed.
2. performing a cold reset causing Fatal Error recovery to fail.
If link goes down due to a DPC event, it should be recovered by DPC
status trigger. Injecting a cold reset in the middle can cause a HW
lockup as it is an undefined behavior.
Similarly, If link goes down due to an AER secondary bus reset issue,
it should be recovered by HW. Injecting a cold reset in the middle of a
secondary bus reset can cause a HW lockup as it is an undefined behavior.
1. HP ISR observes link down interrupt.
2. HP ISR checks that there is a fatal error pending, it doesn't touch
the link.
3. HP ISR waits until link recovery happens.
4. HP ISR calls the read vendor id function.
5. If all fails, try the cold-reset approach.
If fatal error is pending and a fatal error service such as DPC or AER
is running, it is the responsibility of the fatal error service to
recover the link.
Signed-off-by: Sinan Kaya
---
drivers/pci/hotplug/pciehp_ctrl.c | 18
drivers/pci/pci.h | 2 ++
drivers/pci/pcie/err.c| 34 +++
3 files changed, 54 insertions(+)
diff --git a/drivers/pci/hotplug/pciehp_ctrl.c
b/drivers/pci/hotplug/pciehp_ctrl.c
index da7c72372ffc..22354b6850c3 100644
--- a/drivers/pci/hotplug/pciehp_ctrl.c
+++ b/drivers/pci/hotplug/pciehp_ctrl.c
@@ -222,9 +222,27 @@ void pciehp_handle_disable_request(struct slot *slot)
void pciehp_handle_presence_or_link_change(struct slot *slot, u32 events)
{
struct controller *ctrl = slot->ctrl;
+ struct pci_dev *pdev = ctrl->pcie->port;
bool link_active;
u8 present;
+ /* If a fatal error is pending, wait for AER or DPC to handle it. */
+ if (pcie_fatal_error_pending(pdev)) {
+ bool recovered;
+
+ recovered = pcie_wait_fatal_error_clear(pdev);
+
+ /* If the fatal error is gone and the link is up, return */
+ if (recovered && pcie_wait_for_link(pdev, true)) {
+ ctrl_info(ctrl, "Slot(%s): Ignoring Link event due to
successful fatal error recovery\n",
+ slot_name(slot));
+ return;
+ }
+
+ ctrl_info(ctrl, "Slot(%s): Fatal error recovery failed for Link
event, trying hotplug reset\n",
+ slot_name(slot));
+ }
+
/*
* If the slot is on and presence or link has changed, turn it off.
* Even if it's occupied again, we cannot assume the card is the same.
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index c358e7a07f3f..e2d98654630b 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -356,6 +356,8 @@ void pci_enable_acs(struct pci_dev *dev);
/* PCI error reporting and recovery */
void pcie_do_fatal_recovery(struct pci_dev *dev, u32 service);
void pcie_do_nonfatal_recovery(struct pci_dev *dev);
+bool pcie_fatal_error_pending(struct pci_dev *pdev);
+bool pcie_wait_fatal_error_clear(struct pci_dev *pdev);
bool pcie_wait_for_link(struct pci_dev *pdev, bool active);
#ifdef CONFIG_PCIEASPM
diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index f7ce0cb0b0b7..b1b5604cb00b 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include "portdrv.h"
#include "../pci.h"
@@ -386,3 +387,36 @@ void pcie_do_nonfatal_recovery(struct pci_dev *dev)
/* TODO: Should kernel panic here? */
pci_info(dev, "AER: Device recovery failed\n");
}
+
+bool pcie_fatal_error_pending(struct pci_dev *pdev)
+{
+ u16 err_status = 0;
+ int rc;
+
+ if (!pci_is_pcie(pdev))
+ return false;
+
+ rc = pcie_capability_read_word(pdev, PCI_EXP_DEVSTA, &err_status);
+ if (rc)
+ return false;
+
+ return !!(err_status & PCI_EXP_DEVSTA_FED);
+}
+
+bool pcie_wait_fatal_error_clear(struct pci_dev *pdev)
+{
+ int timeout = 1000;
+ bool ret;
+
+ for (;;) {
+ ret = pcie_fatal_error_pending(pdev);
+ if (ret == false)
+ return true;
+ if (timeout <= 0)
+ break;
+ msleep(20);
+ timeout -= 20;
+ }
+
+ return false;
+}
--
2.17.1
[PATCH v8 2/2] PCI: pciehp: Mask AER surprise link down error if hotplug is enabled
PCIe Spec 3.0. 7.10.2. Uncorrectable Error Status Register (Offset 04h)
defines link down errors as an AER error as bit 5 Surprise Down Error
Status.
If hotplug is supported by a particular port, we want hotplug driver
to handle the link down/up conditions via Data Link Layer Active
interrupt rather than the AER error interrupt. Mask the Surprise Down
Error during hotplug driver and re-enable it during remove.
Signed-off-by: Sinan Kaya
---
drivers/pci/hotplug/pciehp_core.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/pci/hotplug/pciehp_core.c
b/drivers/pci/hotplug/pciehp_core.c
index ec48c9433ae5..8322db8f369a 100644
--- a/drivers/pci/hotplug/pciehp_core.c
+++ b/drivers/pci/hotplug/pciehp_core.c
@@ -229,6 +229,29 @@ static void pciehp_check_presence(struct controller *ctrl)
up_read(&ctrl->reset_lock);
}
+static int pciehp_control_surprise_error(struct controller *ctrl, bool enable)
+{
+ struct pci_dev *pdev = ctrl->pcie->port;
+ u32 reg32;
+ int pos;
+
+ if (!pci_is_pcie(pdev))
+ return -ENODEV;
+
+ pos = pdev->aer_cap;
+ if (!pos)
+ return -ENODEV;
+
+ pci_read_config_dword(pdev, pos + PCI_ERR_UNCOR_MASK, ®32);
+ if (enable)
+ reg32 &= ~PCI_ERR_UNC_SURPDN;
+ else
+ reg32 |= PCI_ERR_UNC_SURPDN;
+ pci_write_config_dword(pdev, pos + PCI_ERR_UNCOR_MASK, reg32);
+
+ return 0;
+}
+
static int pciehp_probe(struct pcie_device *dev)
{
int rc;
@@ -280,6 +303,9 @@ static int pciehp_probe(struct pcie_device *dev)
pciehp_check_presence(ctrl);
+ /* We want exclusive control of link down events in hotplug driver */
+ pciehp_control_surprise_error(ctrl, false);
+
return 0;
err_out_shutdown_notification:
@@ -298,6 +324,7 @@ static void pciehp_remove(struct pcie_device *dev)
pci_hp_del(ctrl->slot->hotplug_slot);
pcie_shutdown_notification(ctrl);
cleanup_slot(ctrl);
+ pciehp_control_surprise_error(ctrl, true);
pciehp_release_ctrl(ctrl);
}
--
2.17.1
[PATCH] x86/process: Export start_thread()
Commit e634d8fc792c ("x86-64: merge the standard and compat
start_thread() functions") removed exporting for the start_thread()
function in what seems like a typo. Add it back to
arch/x86/kernel/process_64.c for parity with process_32.c and other
arch.
Signed-off-by: Rian Hunter
---
arch/x86/kernel/process_64.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 476e3ddf8890..a451bc374b9b 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -384,6 +384,7 @@ start_thread(struct pt_regs *regs, unsigned long new_ip,
unsigned long new_sp)
start_thread_common(regs, new_ip, new_sp,
__USER_CS, __USER_DS, 0);
}
+EXPORT_SYMBOL_GPL(start_thread);
#ifdef CONFIG_COMPAT
void compat_start_thread(struct pt_regs *regs, u32 new_ip, u32 new_sp)
--
2.16.3
Re: linux-next: build warnings from Linus' tree
Hi all,
On Mon, 20 Aug 2018 08:16:18 +1000 Stephen Rothwell
wrote:
>
> On Mon, 20 Aug 2018 08:13:23 +1000 Stephen Rothwell
> wrote:
> >
> > Today's linux-next build (powerpc ppc64_defconfig) produced these
> > warnings:
> >
> ...
> >
> > Presumably caused by my update to gcc 8.2.0.
>
> And this from the x86_64 allmodconfig build:
>
> scripts/unifdef.c: In function 'Mpass':
> scripts/unifdef.c:453:28: warning: 'strncpy' output truncated before
> terminating nul copying 4 bytes from a string of the same length
> [-Wstringop-truncation]
> static void Mpass (void) { strncpy(keyword, "if ", 4); Pelif(); }
> ^~~
Note that I only upgraded my (host) powerpc compiler.
--
Cheers,
Stephen Rothwell
pgpeM_4obblHa.pgp
Description: OpenPGP digital signature
Re: linux-next: build warnings from Linus' tree
Hi all,
On Mon, 20 Aug 2018 08:13:23 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next build (powerpc ppc64_defconfig) produced these
> warnings:
>
...
>
> Presumably caused by my update to gcc 8.2.0.
And this from the x86_64 allmodconfig build:
scripts/unifdef.c: In function 'Mpass':
scripts/unifdef.c:453:28: warning: 'strncpy' output truncated before
terminating nul copying 4 bytes from a string of the same length
[-Wstringop-truncation]
static void Mpass (void) { strncpy(keyword, "if ", 4); Pelif(); }
^~~
--
Cheers,
Stephen Rothwell
pgpVPhNgYwUXE.pgp
Description: OpenPGP digital signature
linux-next: build warnings from Linus' tree
Hi Linus,
Today's linux-next build (powerpc ppc64_defconfig) produced these
warnings:
fs/cifs/cifssmb.c: In function 'CIFSSMBNegotiate':
fs/cifs/cifssmb.c:605:3: warning: 'strncpy' writing 16 bytes into a region of
size 1 overflows the destination [-Wstringop-overflow=]
strncpy(pSMB->DialectsArray+count, protocols[i].name, 16);
^
In function 'get_sensor_index_attr',
inlined from 'create_device_attrs' at drivers/hwmon/ibmpowernv.c:293:8,
inlined from 'ibmpowernv_probe' at drivers/hwmon/ibmpowernv.c:699:8:
drivers/hwmon/ibmpowernv.c:256:2: warning: 'strncpy' specified bound 32 equals
destination size [-Wstringop-truncation]
strncpy(attr, dash_pos + 1, MAX_ATTR_LEN);
^
fs/hfsplus/xattr.c: In function 'copy_name':
fs/hfsplus/xattr.c:416:3: warning: 'strncpy' output truncated before
terminating nul copying 4 bytes from a string of the same length
[-Wstringop-truncation]
strncpy(buffer, XATTR_MAC_OSX_PREFIX, XATTR_MAC_OSX_PREFIX_LEN);
^~~
fs/ext4/super.c: In function '__save_error_info':
fs/ext4/super.c:344:2: warning: 'strncpy' specified bound 32 equals destination
size [-Wstringop-truncation]
strncpy(es->s_last_error_func, func, sizeof(es->s_last_error_func));
^~~
fs/ext4/super.c:349:3: warning: 'strncpy' specified bound 32 equals destination
size [-Wstringop-truncation]
strncpy(es->s_first_error_func, func,
^
sizeof(es->s_first_error_func));
~~~
In file included from include/trace/define_trace.h:97,
from include/trace/events/writeback.h:762,
from fs/fs-writeback.c:98:
include/trace/events/writeback.h: In function 'perf_trace_writeback_work_class':
include/trace/events/writeback.h:223:3: warning: 'strncpy' specified bound 32
equals destination size [-Wstringop-truncation]
strncpy(__entry->name,
^~
wb->bdi->dev ? dev_name(wb->bdi->dev) : "(unknown)", 32);
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
{ assign; } \
^~
include/trace/events/writeback.h:222:2: note: in expansion of macro
'TP_fast_assign'
TP_fast_assign(
^~
include/trace/events/writeback.h: In function 'perf_trace_writeback_class':
include/trace/events/writeback.h:277:3: warning: 'strncpy' specified bound 32
equals destination size [-Wstringop-truncation]
strncpy(__entry->name, dev_name(wb->bdi->dev), 32);
^~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
{ assign; } \
^~
include/trace/events/writeback.h:276:2: note: in expansion of macro
'TP_fast_assign'
TP_fast_assign(
^~
include/trace/events/writeback.h: In function
'perf_trace_writeback_bdi_register':
include/trace/events/writeback.h:299:3: warning: 'strncpy' specified bound 32
equals destination size [-Wstringop-truncation]
strncpy(__entry->name, dev_name(bdi->dev), 32);
^~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
{ assign; } \
^~
include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
PARAMS(assign), \
^~
include/trace/events/writeback.h:292:1: note: in expansion of macro
'TRACE_EVENT'
TRACE_EVENT(writeback_bdi_register,
^~~
include/trace/events/writeback.h:298:2: note: in expansion of macro
'TP_fast_assign'
TP_fast_assign(
^~
include/trace/events/writeback.h: In function 'perf_trace_wbc_class':
include/trace/events/writeback.h:324:3: warning: 'strncpy' specified bound 32
equals destination size [-Wstringop-truncation]
strncpy(__entry->name, dev_name(bdi->dev), 32);
^~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
{ assign; } \
^~
include/trace/events/writeback.h:323:2: note: in expansion of macro
'TP_fast_assign'
TP_fast_assign(
^~
include/trace/events/writeback.h: In function 'perf_trace_writeback_queue_io':
include/trace/events/writeback.h:375:3: warning: 'strncpy' specified bound 32
equals destination size [-Wstringop-truncation]
strncpy(__entry->name, dev_name(wb->bdi->dev), 32);
^~
include/trace/perf.h:66:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
{ assign; } \
^~
include/trace/trace_events.h:78:9: note: in expansion of macro 'PARAMS'
PARAMS(assign), \
^~
include/trace/events/writeback.h:360:1: note: in expansion of macro
'TRACE_EVENT'
TRACE_EVENT(writeba
Re: [PATCH v6 1/2] iio: light: Add support for vishay vcnl4035
Hi, On Tue, Aug 07, 2018 at 12:27:03PM +0200, Parthiban Nallathambi wrote: > Add support for VCNL4035, which is capable of Ambient light > sensing (ALS) and proximity function. This patch adds support > only for ALS function > > Signed-off-by: Parthiban Nallathambi > > Changelog since v1: > > 1. Fixed 0-day warning on le16_to_cpu usage > 2. Persistence value is directly mapped to datasheet's value to > avoid confusions of usage from sysfs > > Changelog in v3: > - Usage of lock is not needed, removed mutex locking > - ALS threshold and persistence configuration available > as events and threshold events are notified to userspace > - Usage of devm_ is re-ordered and exit handling updated > - Complexity in timestamp calculation is removed and used > iio_get_time_ns > > Changelog in v4: > - New white light index is introduced for getting data from > white spectrum > - PM enable/disable is called from read_raw accordingly > - Probe exit handling re-ordered > > Changelog in v5: > - White spectrum is mesaured as "_CLEAR" intesity, so removed > white spectrum modifier > - Header re-ordering > - Trigger init and de-init into separate function > - Indentation correct and usage of dev_err in place of pr_err > > Changelog in v6: > - Usage of devm_ for trigger probing and cleanups > - pm_runtime re-order and exit patch corrections > - IIO_INTENSITY to IIO_LIGHT, lux/steps are fixed at IT cycle > lux can be calculated based on IT sensitivity > - _CLEAR to _BOTH although measurement is only WHITE spectrum > for traditional reasons > --- As Jonathan already pointed out, the changelog should go here. A tip is to use notes (see `man git-notes`) to add a changelog and then generate the patches with `git format-patch --notes `. I find it really neat. > drivers/iio/light/Kconfig| 12 + > drivers/iio/light/Makefile | 1 + > drivers/iio/light/vcnl4035.c | 686 > +++ > 3 files changed, 699 insertions(+) > create mode 100644 drivers/iio/light/vcnl4035.c > > diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig > index c7ef8d1862d6..b7069a4c28a2 100644 > --- a/drivers/iio/light/Kconfig > +++ b/drivers/iio/light/Kconfig > @@ -447,6 +447,18 @@ config VCNL4000 >To compile this driver as a module, choose M here: the >module will be called vcnl4000. > > +config VCNL4035 > + tristate "VCNL4035 combined ALS and proximity sensor" > + select REGMAP_I2C > + depends on I2C > + help > + Say Y here if you want to build a driver for the Vishay VCNL4035, > + combined ambient light (ALS) and proximity sensor. Currently only ALS > + function is available. > + > + To compile this driver as a module, choose M here: the > + module will be called vcnl4035. > + > config VEML6070 > tristate "VEML6070 UV A light sensor" > depends on I2C > diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile > index 80943af5d627..dce98511a59b 100644 > --- a/drivers/iio/light/Makefile > +++ b/drivers/iio/light/Makefile > @@ -44,6 +44,7 @@ obj-$(CONFIG_TSL2772) += tsl2772.o > obj-$(CONFIG_TSL4531)+= tsl4531.o > obj-$(CONFIG_US5182D)+= us5182d.o > obj-$(CONFIG_VCNL4000) += vcnl4000.o > +obj-$(CONFIG_VCNL4035) += vcnl4035.o > obj-$(CONFIG_VEML6070) += veml6070.o > obj-$(CONFIG_VL6180) += vl6180.o > obj-$(CONFIG_ZOPT2201) += zopt2201.o > diff --git a/drivers/iio/light/vcnl4035.c b/drivers/iio/light/vcnl4035.c > new file mode 100644 > index ..e9f471d93a15 > --- /dev/null > +++ b/drivers/iio/light/vcnl4035.c > @@ -0,0 +1,686 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * VCNL4035 Ambient Light and Proximity Sensor - 7-bit I2C slave address 0x60 > + * > + * Copyright (c) 2018, DENX Software Engineering GmbH > + * Author: Parthiban Nallathambi > + * > + * > + * TODO: Proximity > + */ > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define VCNL4035_DRV_NAME"vcnl4035" > +#define VCNL4035_IRQ_NAME"vcnl4035_event" > +#define VCNL4035_REGMAP_NAME "vcnl4035_regmap" > + > +/* Device registers */ > +#define VCNL4035_ALS_CONF0x00 > +#define VCNL4035_ALS_THDH0x01 > +#define VCNL4035_ALS_THDL0x02 > +#define VCNL4035_ALS_DATA0x0B > +#define VCNL4035_WHITE_DATA 0x0C > +#define VCNL4035_INT_FLAG0x0D > +#define VCNL4035_DEV_ID 0x0E > + > +/* Register masks */ > +#define VCNL4035_MODE_ALS_MASK BIT(0) > +#define VCNL4035_MODE_ALS_WHITE_CHAN BIT(8) > +#define VCNL4035_MODE_ALS_INT_MASK BIT(1) > +#define VCNL4035_ALS_IT_MASK GENMASK(7, 5) > +#define VCNL4035_ALS_PERS_MASK GENMASK(3, 2) > +#define VCNL4035_INT_ALS_IF_H_MASK BIT(12) > +#define VCNL4035_INT_ALS_IF_L_MASK BIT(13) > + > +/* Default values */ >
Re: Build failures with gcc 4.5 and older
On Tue, Aug 14, 2018 at 10:48 AM, Joe Perches wrote:
> On Tue, 2018-08-14 at 10:09 -0700, Guenter Roeck wrote:
>> Hi,
>>
>> Since commit c1a2f7f0c0645 ("mm: Allocate the mm_cpumask
>> (mm->cpu_bitmap[]) dynamically based on nr_cpu_ids"), building
>> the Linux kernel with gcc version 4.5 and older fails as follows.
>>
>> In file included from ./include/linux/mm.h:17:0,
>> from ./include/linux/pid_namespace.h:7,
>>from ./include/linux/ptrace.h:10,
>>from arch/openrisc/kernel/asm-offsets.c:32:
>> ./include/linux/mm_types.h:497:16: error: flexible array member in otherwise
>> empty struct
>>
>> This is just an example with gcc 4.5.1 for or32. I have seen the problem
>> with gcc 4.4 (for unicore32) as well.
>>
>> Does that mean that gcc 4.5 and older are now officially no longer
>> supported for compiling the kernel ?
>>
>> If so, would it make sense to update include/linux/compiler-gcc.h
>> accordingly ?
>
> And Documentation/process/changes.rst which shows a
> minimum version required of gcc as 3.2, etc...
>
> With cleaning up now unnecessary version tests in
> compiler-gcc.h, something like:
I rejoice at raising the minimum gcc to version 4.6! :)
> ---
> Documentation/process/changes.rst | 2 +-
> include/linux/compiler-gcc.h | 86
> ---
> 2 files changed, 19 insertions(+), 69 deletions(-)
These look good, thanks:
Reviewed-by: Kees Cook
-Kees
>
> diff --git a/Documentation/process/changes.rst
> b/Documentation/process/changes.rst
> index 7a92a06f90de..61f918b10a0c 100644
> --- a/Documentation/process/changes.rst
> +++ b/Documentation/process/changes.rst
> @@ -29,7 +29,7 @@ you probably needn't concern yourself with isdn4k-utils.
> == ===
>
> ProgramMinimal version Command to check the version
> == ===
>
> -GNU C 3.2 gcc --version
> +GNU C 4.6 gcc --version
> GNU make 3.81 make --version
> binutils 2.20 ld -v
> flex 2.5.35 flex --version
> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
> index 573f5a7d42d4..020e4b9eee5c 100644
> --- a/include/linux/compiler-gcc.h
> +++ b/include/linux/compiler-gcc.h
> @@ -10,6 +10,10 @@
> + __GNUC_MINOR__ * 100 \
> + __GNUC_PATCHLEVEL__)
>
> +#if GCC_VERSION < 40600
> +# error Sorry, your compiler is too old - please upgrade it.
> +#endif
> +
> /* Optimization barrier */
>
> /* The "volatile" is due to gcc bugs */
> @@ -58,6 +62,12 @@
> #define OPTIMIZER_HIDE_VAR(var)
> \
> __asm__ ("" : "=r" (var) : "0" (var))
>
> +/*
> + * A trick to suppress uninitialized variable warning without generating any
> + * code
> + */
> +#define uninitialized_var(x) x = x
> +
> #ifdef __CHECKER__
> #define __must_be_array(a) 0
> #else
> @@ -91,7 +101,7 @@
> * A lot of inline functions can cause havoc with function tracing.
> */
> #if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) || \
> -!defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4)
> +!defined(CONFIG_OPTIMIZE_INLINING)
> #define inline \
> inline __attribute__((always_inline, unused)) notrace __gnu_inline
> #else
> @@ -148,47 +158,13 @@
> #define __always_unused__attribute__((unused))
> #define __mode(x) __attribute__((mode(x)))
>
> -/* gcc version specific checks */
> -
> -#if GCC_VERSION < 30200
> -# error Sorry, your compiler is too old - please upgrade it.
> -#endif
> -
> -#if GCC_VERSION < 30300
> -# define __used__attribute__((__unused__))
> -#else
> -# define __used__attribute__((__used__))
> -#endif
> -
> -#ifdef CONFIG_GCOV_KERNEL
> -# if GCC_VERSION < 30400
> -# error "GCOV profiling support for gcc versions below 3.4 not included"
> -# endif /* __GNUC_MINOR__ */
> -#endif /* CONFIG_GCOV_KERNEL */
> -
> -#if GCC_VERSION >= 30400
> #define __must_check __attribute__((warn_unused_result))
> #define __malloc __attribute__((__malloc__))
> -#endif
> -
> -#if GCC_VERSION >= 4
> -
> -/* GCC 4.1.[01] miscompiles __weak */
> -#ifdef __KERNEL__
> -# if GCC_VERSION >= 40100 && GCC_VERSION <= 40101
> -# error Your version of gcc miscompiles the __weak directive
> -# endif
> -#endif
>
> #define __used __attribute__((__used__))
> #define __compiler_offsetof(a, b) \
> __builtin_offsetof(a, b)
>
> -#if GCC_VERSION >= 40100
> -# define __compiletime_object_size(obj) __builtin_object_size(obj, 0)
> -#endif
> -
> -#if GCC_VERSION >= 40300
> /* Mark functions as cold. gcc will assume a
Re: [PATCH] Revert "Permit silencing of __deprecated warnings."
On Fri, 17 Aug 2018 20:45:06 -0600 Jason Gunthorpe wrote: > Jonathan: I'm not sure if you prefer diffs to documentation to be > minimal like this, or if should reflow the paragraph? I guess I've never really thought to develop a strong preference. But, in the end, the docs are meant to be read in their source form, so we want to keep them readable. If a paragraph needs to be refilled due to significant changes, just go ahead and do it... jon
Re: [RFC PATCH] compiler.h: give up __compiletime_assert_fallback()
On Sun, Aug 19, 2018 at 1:36 PM Nick Desaulniers wrote: > > On Sun, Aug 19, 2018 at 1:28 PM Linus Torvalds > wrote: > > > > Well, it turns out that we effectively stopped supporting gcc < 4.6 > > during this merge window for other reasons, so.. > > For the whole kernel (or just a particular arch)? Which commit? Do > we keep track of minimal versions somewhere? It's effectively for the whole kernel right now. See: https://lore.kernel.org/lkml/20180814170904.ga12...@roeck-us.net/ although it might be fixable. Nobody really *wants* to fix it, though, because we've had that initializer issue before too, and various other issues with old gcc versions. So we have long had reasons why we'd _want_ to upgrade to at least gcc-4.6 The "we support gcc-3.2" in Documentation/process/changes.rst is complete fantasy. Linus
Re: [RFC PATCH] compiler.h: give up __compiletime_assert_fallback()
On Sun, Aug 19, 2018 at 1:28 PM Linus Torvalds wrote: > > On Sun, Aug 19, 2018 at 1:25 PM Nick Desaulniers > wrote: > > > > + gbiv who wrote this cool paste (showing alternatives to > > _Static_assert, which is supported by both compilers in -std=gnu89, > > but not until gcc 4.6): https://godbolt.org/g/DuLsxu > > > > I can't help but think that BUILD_BUG_ON_MSG should use > > _Static_assert, then have fallbacks for gcc < 4.6. > > Well, it turns out that we effectively stopped supporting gcc < 4.6 > during this merge window for other reasons, so.. For the whole kernel (or just a particular arch)? Which commit? Do we keep track of minimal versions somewhere? Documentation/process/changes.rst mentions gcc 3.2 (eek), but I assume there's a compiler version check somewhere (if you're using gcc and it's version is less than X, abort. Ditto for clang.) -- Thanks, ~Nick Desaulniers
[PATCH v4 0/2] i2c: npcm7xx: new driver for I2C controller
Nuvoton NPCM7XX I2C Controller NPCM7xx includes 16 I2C controllers. This driver operates the controller. This module also includes a slave mode, which will be submitted later on. --- v4 -> v3: - typo on cover letter. v3 -> v2: - fix dt binding: compatible name: omit "bus" v2 -> v1: - run check patch in strict mode. - use linux crc. - define regs in constant offset without base. - remove debug prints. - no declarations for local functions. v1: initial version Signed-off-by: Tali Perry Reviewed-by: Rob Herring --- Tali Perry (2): dt-bindings: i2c: npcm7xx: add binding for i2c controller i2c: npcm7xx: add i2c controller master mode only .../devicetree/bindings/i2c/i2c-npcm7xx.txt| 29 + drivers/i2c/busses/Kconfig | 11 + drivers/i2c/busses/Makefile|1 + drivers/i2c/busses/i2c-npcm7xx.c | 2017 4 files changed, 2058 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-npcm7xx.txt create mode 100644 drivers/i2c/busses/i2c-npcm7xx.c -- 2.14.1
[PATCH v4 2/2] i2c: npcm7xx: add i2c controller master mode only
Nuvoton NPCM7XX I2C Controller
NPCM7xx includes 16 I2C controllers. This driver operates the controller.
This module also includes a slave mode, which will be submitted later on.
---
v4 -> v3:
- typo on cover letter.
v3 -> v2:
- fix dt binding: compatible name: omit "bus"
v2 -> v1:
- run check patch in strict mode.
- use linux crc.
- define regs in constant offset without base.
- remove debug prints.
- no declarations for local functions.
v1: initial version
Signed-off-by: Tali Perry
Reviewed-by: Rob Herring
---
drivers/i2c/busses/Kconfig | 11 +
drivers/i2c/busses/Makefile |1 +
drivers/i2c/busses/i2c-npcm7xx.c | 2017 ++
3 files changed, 2029 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-npcm7xx.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 4f8df2ec87b1..61862fed71fd 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -742,6 +742,17 @@ config I2C_NOMADIK
I2C interface from ST-Ericsson's Nomadik and Ux500 architectures,
as well as the STA2X11 PCIe I/O HUB.
+config I2C_NPCM7XX
+ tristate "Nuvoton I2C Controller"
+ depends on ARCH_NPCM7XX
+ select CRC8
+ help
+ If you say yes to this option, support will be included for the
+ Nuvoton I2C controller.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-npcm7xx.
+
config I2C_OCORES
tristate "OpenCores I2C Controller"
help
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 5a869144a0c5..80d4ec8908e1 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_I2C_MT65XX) += i2c-mt65xx.o
obj-$(CONFIG_I2C_MV64XXX) += i2c-mv64xxx.o
obj-$(CONFIG_I2C_MXS) += i2c-mxs.o
obj-$(CONFIG_I2C_NOMADIK) += i2c-nomadik.o
+obj-$(CONFIG_I2C_NPCM7XX) += i2c-npcm7xx.o
obj-$(CONFIG_I2C_OCORES) += i2c-ocores.o
obj-$(CONFIG_I2C_OMAP) += i2c-omap.o
obj-$(CONFIG_I2C_PASEMI) += i2c-pasemi.o
diff --git a/drivers/i2c/busses/i2c-npcm7xx.c b/drivers/i2c/busses/i2c-npcm7xx.c
new file mode 100644
index ..4dc766016031
--- /dev/null
+++ b/drivers/i2c/busses/i2c-npcm7xx.c
@@ -0,0 +1,2017 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Nuvoton NPCM7xx SMB Controller driver
+ *
+ * Copyright (C) 2018 Nuvoton Technologies tali.pe...@nuvoton.com
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define I2C_VERSION "0.0.3"
+
+enum smb_mode {
+ SMB_SLAVE = 1,
+ SMB_MASTER
+};
+
+/*
+ * External SMB Interface driver xfer indication values, which indicate status
+ * of the bus.
+ */
+enum smb_state_ind {
+ SMB_NO_STATUS_IND = 0,
+ SMB_SLAVE_RCV_IND = 1,
+ SMB_SLAVE_XMIT_IND = 2,
+ SMB_SLAVE_XMIT_MISSING_DATA_IND = 3,
+ SMB_SLAVE_RESTART_IND = 4,
+ SMB_SLAVE_DONE_IND = 5,
+ SMB_MASTER_DONE_IND = 6,
+ SMB_NO_DATA_IND = 7,
+ SMB_NACK_IND = 8,
+ SMB_BUS_ERR_IND = 9,
+ SMB_WAKE_UP_IND = 10,
+ SMB_MASTER_PEC_ERR_IND = 11,
+ SMB_BLOCK_BYTES_ERR_IND = 12,
+ SMB_SLAVE_PEC_ERR_IND = 13,
+ SMB_SLAVE_RCV_MISSING_DATA_IND = 14,
+};
+
+// SMBus Operation type values
+enum smb_oper {
+ SMB_NO_OPER = 0,
+ SMB_WRITE_OPER = 1,
+ SMB_READ_OPER = 2
+};
+
+// SMBus Bank (FIFO mode)
+enum smb_bank {
+ SMB_BANK_0 = 0,
+ SMB_BANK_1 = 1
+};
+
+// Internal SMB states values (for the SMB module state machine).
+enum smb_state {
+ SMB_DISABLE = 0,
+ SMB_IDLE,
+ SMB_MASTER_START,
+ SMB_SLAVE_MATCH,
+ SMB_OPER_STARTED,
+ SMB_REPEATED_START,
+ SMB_STOP_PENDING
+};
+
+// Module supports setting multiple own slave addresses:
+enum smb_addr {
+ SMB_SLAVE_ADDR1 = 0,
+ SMB_SLAVE_ADDR2,
+ SMB_SLAVE_ADDR3,
+ SMB_SLAVE_ADDR4,
+ SMB_SLAVE_ADDR5,
+ SMB_SLAVE_ADDR6,
+ SMB_SLAVE_ADDR7,
+ SMB_SLAVE_ADDR8,
+ SMB_SLAVE_ADDR9,
+ SMB_SLAVE_ADDR10,
+ SMB_GC_ADDR,
+ SMB_ARP_ADDR
+};
+
+// global regs
+static struct regmap *gcr_regmap;
+static struct regmap *clk_regmap;
+
+#define NPCM_I2CSEGCTL 0xE4
+#define NPCM_SECCNT0x68
+#define NPCM_CNTR25M 0x6C
+#define I2CSEGCTL_VAL 0x0333F000
+
+// Common regs
+#define NPCM_SMBSDA0x000
+#define NPCM_SMBST 0x002
+#define NPCM_SMBCST0x004
+#define NPCM_SMBCTL1 0x006
+#define NPCM_SMBADDR1 0x008
+#define NPCM_SMBCTL2 0x00A
+#define NPCM_SMBADDR2 0x00C
+#define NPCM_SMBCTL3 0x00E
+#define NPCM_SMBCST2 0x018
+#define NPCM_SMBCST3
[PATCH v4 1/2] dt-bindings: i2c: npcm7xx: add binding for i2c controller
Nuvoton NPCM7XX I2C Controller
NPCM7xx includes 16 I2C controllers. This driver operates the controller.
This module also includes a slave mode, which will be submitted later on.
---
v4 -> v3:
- typo on cover letter.
v3 -> v2:
- fix dt binding: compatible name: omit "bus"
v2 -> v1:
- run check patch in strict mode.
- use linux crc.
- define regs in constant offset without base.
- remove debug prints.
- no declarations for local functions.
v1: initial version
Signed-off-by: Tali Perry
Reviewed-by: Rob Herring
---
.../devicetree/bindings/i2c/i2c-npcm7xx.txt| 29 ++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-npcm7xx.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-npcm7xx.txt
b/Documentation/devicetree/bindings/i2c/i2c-npcm7xx.txt
new file mode 100644
index ..0ecae950748b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-npcm7xx.txt
@@ -0,0 +1,29 @@
+Nuvoton NPCM7XX I2C bus
+
+The NPCM750x includes sixteen I2C bus controllers. All Controllers support
+both master and slave mode. Each controller has two 16 byte HW FIFO for TX and
+RX.
+
+Required properties:
+- compatible : must be "nuvoton,npcm750-i2c"
+- reg : Offset and length of the register set for the device.
+- interrupts : Contain the I2C interrupt with flags for falling edge.
+- clocks : phandle of I2C reference clock.
+
+Optional:
+- bus-frequency : Contain the I2C bus frequency,
+ the default I2C bus frequency is 10.
+- pinctrl-0 : must be <&smbX_pins>, X is module number
+ (on NPCM7XX it's 0 to 15)
+- pinctrl-names : should be set to "default"
+Example:
+
+ i2c0: i2c@8 {
+ compatible = "nuvoton,npcm750-i2c";
+ reg = <0x8 0x1000>;
+ clocks = <&clk NPCM7XX_CLK_APB2>;
+ bus-frequency = <10>;
+ interrupts = ;
+ pinctrl-names = "default";
+ pinctrl-0 = <&smb0_pins>;
+ };
--
2.14.1
Re: [RFC PATCH] compiler.h: give up __compiletime_assert_fallback()
On Sun, Aug 19, 2018 at 1:25 PM Nick Desaulniers wrote: > > + gbiv who wrote this cool paste (showing alternatives to > _Static_assert, which is supported by both compilers in -std=gnu89, > but not until gcc 4.6): https://godbolt.org/g/DuLsxu > > I can't help but think that BUILD_BUG_ON_MSG should use > _Static_assert, then have fallbacks for gcc < 4.6. Well, it turns out that we effectively stopped supporting gcc < 4.6 during this merge window for other reasons, so.. Linus
Re: [RFC PATCH] compiler.h: give up __compiletime_assert_fallback()
+ gbiv who wrote this cool paste (showing alternatives to
_Static_assert, which is supported by both compilers in -std=gnu89,
but not until gcc 4.6): https://godbolt.org/g/DuLsxu
I can't help but think that BUILD_BUG_ON_MSG should use
_Static_assert, then have fallbacks for gcc < 4.6.
On Sun, Aug 19, 2018 at 9:14 AM Kees Cook wrote:
>
> On Sat, Aug 18, 2018 at 10:51 PM, Masahiro Yamada
> wrote:
> > __compiletime_assert_fallback() is supposed to stop building earlier
> > by using the negative-array-size method in case the compiler does not
> > support "error" attribute, but has never worked like that.
> >
> > You can try this simple code:
> >
> > #include
> > void foo(void)
> > {
> > BUILD_BUG_ON(1);
> > }
> >
> > GCC (precisely, GCC 4.3 or later) immediately terminates the build,
> > but Clang does not report anything because Clang does not support the
> > "error" attribute now. It will eventually fail in the link stage,
> > but at least __compiletime_assert_fallback() is not working.
> >
> > The root cause is commit 1d6a0d19c855 ("bug.h: prevent double evaluation
> > of `condition' in BUILD_BUG_ON"). Prior to that commit, BUILD_BUG_ON()
> > was checked by the negative-array-size method *and* the link-time trick.
> > Since that commit, the negative-array-size is not effective because
> > '__cond' is no longer constant. As the comment in
> > says, GCC (and Clang as well) only emits the error for obvious cases.
> >
> > When '__cond' is a variable,
> >
> > ((void)sizeof(char[1 - 2 * __cond]))
> >
> > ... is not obvious for the compiler to know the array size is negative.
> >
> > One way to fix this is to stop the variable assignment, i.e. to pass
> > '!(condition)' directly to __compiletime_error_fallback() at the cost
> > of the double evaluation of 'condition'. However, all calls of
> > BUILD_BUG() would be turned into errors even if they are called from
> > dead-code.
> >
> > This commit does not change the current behavior since it just rips
> > off the code that has not been effective for some years.
> >
> > Signed-off-by: Masahiro Yamada
>
> Yeah, Clang would only complain about the VLA (and not error) and then
> later fail at link time. This seems like a reasonable change to me.
Heh, we were just talking about this (-Wvla warnings from this macro).
Was there a previous thread before this patch?
>
> Reviewed-by: Kees Cook
>
> -Kees
>
> > ---
> >
> > include/linux/compiler.h | 17 +
> > 1 file changed, 1 insertion(+), 16 deletions(-)
> >
> > diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> > index 42506e4..c062238f4 100644
> > --- a/include/linux/compiler.h
> > +++ b/include/linux/compiler.h
> > @@ -295,29 +295,14 @@ unsigned long read_word_at_a_time(const void *addr)
> > #endif
> > #ifndef __compiletime_error
> > # define __compiletime_error(message)
> > -/*
> > - * Sparse complains of variable sized arrays due to the temporary variable
> > in
> > - * __compiletime_assert. Unfortunately we can't just expand it out to make
> > - * sparse see a constant array size without breaking compiletime_assert on
> > old
> > - * versions of GCC (e.g. 4.2.4), so hide the array from sparse altogether.
> > - */
> > -# ifndef __CHECKER__
> > -# define __compiletime_error_fallback(condition) \
> > - do { ((void)sizeof(char[1 - 2 * condition])); } while (0)
Note that there are a few definitions of BUILD_BUG_ON that still use
this negative array size trick. Should that pattern be removed from
them as well? See:
* arch/x86/boot/boot.h#L33
* include/linux/build_bug.h#L66
* tools/include/linux/kernel.h#L38
Reviewed-by: Nick Desaulniers
--
Thanks,
~Nick Desaulniers
Re: [PATCH v4 1/3] iio: adc: add support for mcp3911
On Sun, Aug 19, 2018 at 08:29:43PM +0100, Jonathan Cameron wrote: > On Sun, 19 Aug 2018 21:17:51 +0200 > Marcus Folkesson wrote: > > > On Sun, Aug 19, 2018 at 08:02:57PM +0100, Jonathan Cameron wrote: > > > On Wed, 8 Aug 2018 10:09:15 +0200 > > > Marcus Folkesson wrote: > > > > > > > MCP3911 is a dual channel Analog Front End (AFE) containing two > > > > synchronous sampling delta-sigma Analog-to-Digital Converters (ADC). > > > > > > > > Co-Developed-by: Kent Gustavsson > > > checkpatch points out.. > > > Co-developed-by is the 'official' form of the tag. I'll fixup. > > > (first time I've seen one of these ;) > > > > Yep, I also noticed that checkpatch is not Co-developed-by-aware yet. > > I tried to fix it, but Perl is just such a terrible language that I > > considered it impossible. > > The version in mainline seems to be aware, it just wants > Co-developed-by not Co-Developed-by! > > (lower case d) I just noticed that the tag was renamed from Co-Developed-by to Co-developed-by in e474785a12b46230ecf9f3663166b0de1175bcdc. I must have been reading the documentation from an older tree... /Marcus signature.asc Description: PGP signature
Re: [PATCH v4 1/3] iio: adc: add support for mcp3911
On Sun, 19 Aug 2018 21:17:51 +0200 Marcus Folkesson wrote: > On Sun, Aug 19, 2018 at 08:02:57PM +0100, Jonathan Cameron wrote: > > On Wed, 8 Aug 2018 10:09:15 +0200 > > Marcus Folkesson wrote: > > > > > MCP3911 is a dual channel Analog Front End (AFE) containing two > > > synchronous sampling delta-sigma Analog-to-Digital Converters (ADC). > > > > > > Co-Developed-by: Kent Gustavsson > > checkpatch points out.. > > Co-developed-by is the 'official' form of the tag. I'll fixup. > > (first time I've seen one of these ;) > > Yep, I also noticed that checkpatch is not Co-developed-by-aware yet. > I tried to fix it, but Perl is just such a terrible language that I > considered it impossible. The version in mainline seems to be aware, it just wants Co-developed-by not Co-Developed-by! (lower case d) > > > > > > Signed-off-by: Kent Gustavsson > > > Signed-off-by: Marcus Folkesson > > Applied to the togreg branch of iio.git and pushed out as testing for the > > autobuilders to play with it. > > > > A few really trivial comments inline. Also some slightly odd alignment > > I'll fix up that I haven't noted, but not every parameter second line > > lines up with the opening brackets correctly. > > Thank you. > > > > Jonathan > > > > > --- > > > > > > Notes: > > > v4: > > > - remove defined(CONFIG_OF) and of_match_ptr() macro > > > - do not check adc->clki as clock api is NULL-aware > > > - add Kent as co-developer > > > v3: > > > - rename adc_clk to clki > > > - add error handling/cleanup for clock > > > v2: > > > - cleanups and bugfixes (thanks Peter Meerwald-Stadler) > > > - drop hardware gain > > > - use the presence or lack of regulator to indicate if we go > > > for internal or external voltage reference > > > - do not store device node in private struct > > > - drop support to set width in devicetree > > > - use the presence or lack of clock to indicate if we go for > > > internal or external clock > > > > > > drivers/iio/adc/Kconfig | 10 ++ > > > drivers/iio/adc/Makefile | 1 + > > > drivers/iio/adc/mcp3911.c | 361 > > > ++ > > > 3 files changed, 372 insertions(+) > > > create mode 100644 drivers/iio/adc/mcp3911.c > > > > > > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig > > > index 15606f237480..f9a41fa96fcc 100644 > > > --- a/drivers/iio/adc/Kconfig > > > +++ b/drivers/iio/adc/Kconfig > > > @@ -501,6 +501,16 @@ config MCP3422 > > > This driver can also be built as a module. If so, the module will be > > > called mcp3422. > > > > > > +config MCP3911 > > > + tristate "Microchip Technology MCP3911 driver" > > > + depends on SPI > > > + help > > > + Say yes here to build support for Microchip Technology's MCP3911 > > > + analog to digital converter. > > > + > > > + This driver can also be built as a module. If so, the module will be > > > + called mcp3911. > > > + > > > config MEDIATEK_MT6577_AUXADC > > > tristate "MediaTek AUXADC driver" > > > depends on ARCH_MEDIATEK || COMPILE_TEST > > > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile > > > index 28a9423997f3..3cfebfff7d26 100644 > > > --- a/drivers/iio/adc/Makefile > > > +++ b/drivers/iio/adc/Makefile > > > @@ -47,6 +47,7 @@ obj-$(CONFIG_MAX1363) += max1363.o > > > obj-$(CONFIG_MAX9611) += max9611.o > > > obj-$(CONFIG_MCP320X) += mcp320x.o > > > obj-$(CONFIG_MCP3422) += mcp3422.o > > > +obj-$(CONFIG_MCP3911) += mcp3911.o > > > obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o > > > obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o > > > obj-$(CONFIG_MESON_SARADC) += meson_saradc.o > > > diff --git a/drivers/iio/adc/mcp3911.c b/drivers/iio/adc/mcp3911.c > > > new file mode 100644 > > > index ..540c8fbcce89 > > > --- /dev/null > > > +++ b/drivers/iio/adc/mcp3911.c > > > @@ -0,0 +1,361 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > > +/* > > > + * Driver for Microchip MCP3911, Two-channel Analog Front End > > > + * > > > + * Copyright (C) 2018 Marcus Folkesson > > > + * Copyright (C) 2018 Kent Gustavsson > > > + */ > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > + > > > +#define MCP3911_REG_CHANNEL0 0x00 > > > +#define MCP3911_REG_CHANNEL1 0x03 > > > +#define MCP3911_REG_MOD 0x06 > > > +#define MCP3911_REG_PHASE0x07 > > > +#define MCP3911_REG_GAIN 0x09 > > > + > > > +#define MCP3911_REG_STATUSCOM0x0a > > > +#define MCP3911_STATUSCOM_CH1_24WIDTHBIT(4) > > > +#define MCP3911_STATUSCOM_CH0_24WIDTHBIT(3) > > > +#define MCP3911_STATUSCOM_EN_OFFCAL BIT(2) > > > +#define MCP3911_STATUSCOM_EN_GAINCAL BIT(1) > > > + > > > +#define MCP3911_REG_CONFIG 0x0c > > > +#define MCP3911_CONFIG_
[PATCH] MIPS: BCM47XX: Enable USB power on Netgear WNDR3400v3
Setting GPIO 21 high seems to be required to enable power to USB ports
on the WNDR3400v3. As there is already similar code for WNR3500L,
make the existing USB power GPIO code generic and use that.
Signed-off-by: Tuomas Tynkkynen
---
arch/mips/bcm47xx/workarounds.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/mips/bcm47xx/workarounds.c b/arch/mips/bcm47xx/workarounds.c
index 1a8a07e7a563..46eddbec8d9f 100644
--- a/arch/mips/bcm47xx/workarounds.c
+++ b/arch/mips/bcm47xx/workarounds.c
@@ -5,9 +5,8 @@
#include
#include
-static void __init bcm47xx_workarounds_netgear_wnr3500l(void)
+static void __init bcm47xx_workarounds_enable_usb_power(int usb_power)
{
- const int usb_power = 12;
int err;
err = gpio_request_one(usb_power, GPIOF_OUT_INIT_HIGH, "usb_power");
@@ -23,7 +22,10 @@ void __init bcm47xx_workarounds(void)
switch (board) {
case BCM47XX_BOARD_NETGEAR_WNR3500L:
- bcm47xx_workarounds_netgear_wnr3500l();
+ bcm47xx_workarounds_enable_usb_power(12);
+ break;
+ case BCM47XX_BOARD_NETGEAR_WNDR3400_V3:
+ bcm47xx_workarounds_enable_usb_power(21);
break;
default:
/* No workaround(s) needed */
--
2.16.3
Re: [PATCH 3/3] iio: potentiometer: merge calls to of_match_device and of_device_get_match_data
On Sun, 19 Aug 2018 09:02:42 +0200
Peter Rosin wrote:
> On 2018-05-21 11:49, Julia Lawall wrote:
> > Drop call to of_match_device, which is subsumed by the subsequent
> > call to of_device_get_match_data. The code becomes simpler, and a
> > temporary variable can be dropped.
> >
> > The semantic match that makes this change is as follows:
> > (http://coccinelle.lip6.fr/)
> >
> > //
> > @r@
> > local idexpression match;
> > identifier i;
> > expression x, dev, e, e1;
> > @@
> > -match@i = of_match_device(x, dev);
> > -if (match) e = of_device_get_match_data(dev);
> > -else e = e1;
> > +e = of_device_get_match_data(dev);
> > +if (!e) e = e1;
> >
> > @@
> > identifier r.i;
> > @@
> > - const struct of_device_id *i;
> > ... when != i
> > //
> >
> > Signed-off-by: Julia Lawall
>
> Reviewed-by: Peter Rosin
Applied to the togreg branch of iio.git.
Glad you replied to this one Peter, it had definitely dropped through the
cracks.
Jonathan
>
> Cheers,
> Peter
>
> >
> > ---
> > drivers/iio/potentiometer/max5481.c |7 ++-
> > drivers/iio/potentiometer/mcp4018.c |7 ++-
> > drivers/iio/potentiometer/mcp4531.c |7 ++-
> > 3 files changed, 6 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/iio/potentiometer/mcp4018.c
> > b/drivers/iio/potentiometer/mcp4018.c
> > index 320a7c9..c051ee0 100644
> > --- a/drivers/iio/potentiometer/mcp4018.c
> > +++ b/drivers/iio/potentiometer/mcp4018.c
> > @@ -147,7 +147,6 @@ static int mcp4018_probe(struct i2c_client *client)
> > struct device *dev = &client->dev;
> > struct mcp4018_data *data;
> > struct iio_dev *indio_dev;
> > - const struct of_device_id *match;
> >
> > if (!i2c_check_functionality(client->adapter,
> > I2C_FUNC_SMBUS_BYTE)) {
> > @@ -162,10 +161,8 @@ static int mcp4018_probe(struct i2c_client *client)
> > i2c_set_clientdata(client, indio_dev);
> > data->client = client;
> >
> > - match = of_match_device(of_match_ptr(mcp4018_of_match), dev);
> > - if (match)
> > - data->cfg = of_device_get_match_data(dev);
> > - else
> > + data->cfg = of_device_get_match_data(dev);
> > + if (!data->cfg)
> > data->cfg = &mcp4018_cfg[i2c_match_id(mcp4018_id,
> > client)->driver_data];
> >
> > indio_dev->dev.parent = dev;
> > diff --git a/drivers/iio/potentiometer/mcp4531.c
> > b/drivers/iio/potentiometer/mcp4531.c
> > index df894af..d87ca85 100644
> > --- a/drivers/iio/potentiometer/mcp4531.c
> > +++ b/drivers/iio/potentiometer/mcp4531.c
> > @@ -360,7 +360,6 @@ static int mcp4531_probe(struct i2c_client *client)
> > struct device *dev = &client->dev;
> > struct mcp4531_data *data;
> > struct iio_dev *indio_dev;
> > - const struct of_device_id *match;
> >
> > if (!i2c_check_functionality(client->adapter,
> > I2C_FUNC_SMBUS_WORD_DATA)) {
> > @@ -375,10 +374,8 @@ static int mcp4531_probe(struct i2c_client *client)
> > i2c_set_clientdata(client, indio_dev);
> > data->client = client;
> >
> > - match = of_match_device(of_match_ptr(mcp4531_of_match), dev);
> > - if (match)
> > - data->cfg = of_device_get_match_data(dev);
> > - else
> > + data->cfg = of_device_get_match_data(dev);
> > + if (!data->cfg)
> > data->cfg = &mcp4531_cfg[i2c_match_id(mcp4531_id,
> > client)->driver_data];
> >
> > indio_dev->dev.parent = dev;
> > diff --git a/drivers/iio/potentiometer/max5481.c
> > b/drivers/iio/potentiometer/max5481.c
> > index ffe2761..6d2f13f 100644
> > --- a/drivers/iio/potentiometer/max5481.c
> > +++ b/drivers/iio/potentiometer/max5481.c
> > @@ -137,7 +137,6 @@ static int max5481_probe(struct spi_device *spi)
> > struct iio_dev *indio_dev;
> > struct max5481_data *data;
> > const struct spi_device_id *id = spi_get_device_id(spi);
> > - const struct of_device_id *match;
> > int ret;
> >
> > indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*data));
> > @@ -149,10 +148,8 @@ static int max5481_probe(struct spi_device *spi)
> >
> > data->spi = spi;
> >
> > - match = of_match_device(of_match_ptr(max5481_match), &spi->dev);
> > - if (match)
> > - data->cfg = of_device_get_match_data(&spi->dev);
> > - else
> > + data->cfg = of_device_get_match_data(&spi->dev);
> > + if (!data->cfg)
> > data->cfg = &max5481_cfg[id->driver_data];
> >
> > indio_dev->name = id->name;
> >
>
Re: [PATCH v4 1/3] iio: adc: add support for mcp3911
On Sun, Aug 19, 2018 at 08:02:57PM +0100, Jonathan Cameron wrote: > On Wed, 8 Aug 2018 10:09:15 +0200 > Marcus Folkesson wrote: > > > MCP3911 is a dual channel Analog Front End (AFE) containing two > > synchronous sampling delta-sigma Analog-to-Digital Converters (ADC). > > > > Co-Developed-by: Kent Gustavsson > checkpatch points out.. > Co-developed-by is the 'official' form of the tag. I'll fixup. > (first time I've seen one of these ;) Yep, I also noticed that checkpatch is not Co-developed-by-aware yet. I tried to fix it, but Perl is just such a terrible language that I considered it impossible. > > > Signed-off-by: Kent Gustavsson > > Signed-off-by: Marcus Folkesson > Applied to the togreg branch of iio.git and pushed out as testing for the > autobuilders to play with it. > > A few really trivial comments inline. Also some slightly odd alignment > I'll fix up that I haven't noted, but not every parameter second line > lines up with the opening brackets correctly. Thank you. > > Jonathan > > > --- > > > > Notes: > > v4: > > - remove defined(CONFIG_OF) and of_match_ptr() macro > > - do not check adc->clki as clock api is NULL-aware > > - add Kent as co-developer > > v3: > > - rename adc_clk to clki > > - add error handling/cleanup for clock > > v2: > > - cleanups and bugfixes (thanks Peter Meerwald-Stadler) > > - drop hardware gain > > - use the presence or lack of regulator to indicate if we go > > for internal or external voltage reference > > - do not store device node in private struct > > - drop support to set width in devicetree > > - use the presence or lack of clock to indicate if we go for > > internal or external clock > > > > drivers/iio/adc/Kconfig | 10 ++ > > drivers/iio/adc/Makefile | 1 + > > drivers/iio/adc/mcp3911.c | 361 > > ++ > > 3 files changed, 372 insertions(+) > > create mode 100644 drivers/iio/adc/mcp3911.c > > > > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig > > index 15606f237480..f9a41fa96fcc 100644 > > --- a/drivers/iio/adc/Kconfig > > +++ b/drivers/iio/adc/Kconfig > > @@ -501,6 +501,16 @@ config MCP3422 > > This driver can also be built as a module. If so, the module will be > > called mcp3422. > > > > +config MCP3911 > > + tristate "Microchip Technology MCP3911 driver" > > + depends on SPI > > + help > > + Say yes here to build support for Microchip Technology's MCP3911 > > + analog to digital converter. > > + > > + This driver can also be built as a module. If so, the module will be > > + called mcp3911. > > + > > config MEDIATEK_MT6577_AUXADC > > tristate "MediaTek AUXADC driver" > > depends on ARCH_MEDIATEK || COMPILE_TEST > > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile > > index 28a9423997f3..3cfebfff7d26 100644 > > --- a/drivers/iio/adc/Makefile > > +++ b/drivers/iio/adc/Makefile > > @@ -47,6 +47,7 @@ obj-$(CONFIG_MAX1363) += max1363.o > > obj-$(CONFIG_MAX9611) += max9611.o > > obj-$(CONFIG_MCP320X) += mcp320x.o > > obj-$(CONFIG_MCP3422) += mcp3422.o > > +obj-$(CONFIG_MCP3911) += mcp3911.o > > obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o > > obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o > > obj-$(CONFIG_MESON_SARADC) += meson_saradc.o > > diff --git a/drivers/iio/adc/mcp3911.c b/drivers/iio/adc/mcp3911.c > > new file mode 100644 > > index ..540c8fbcce89 > > --- /dev/null > > +++ b/drivers/iio/adc/mcp3911.c > > @@ -0,0 +1,361 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Driver for Microchip MCP3911, Two-channel Analog Front End > > + * > > + * Copyright (C) 2018 Marcus Folkesson > > + * Copyright (C) 2018 Kent Gustavsson > > + */ > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#define MCP3911_REG_CHANNEL0 0x00 > > +#define MCP3911_REG_CHANNEL1 0x03 > > +#define MCP3911_REG_MOD0x06 > > +#define MCP3911_REG_PHASE 0x07 > > +#define MCP3911_REG_GAIN 0x09 > > + > > +#define MCP3911_REG_STATUSCOM 0x0a > > +#define MCP3911_STATUSCOM_CH1_24WIDTH BIT(4) > > +#define MCP3911_STATUSCOM_CH0_24WIDTH BIT(3) > > +#define MCP3911_STATUSCOM_EN_OFFCALBIT(2) > > +#define MCP3911_STATUSCOM_EN_GAINCAL BIT(1) > > + > > +#define MCP3911_REG_CONFIG 0x0c > > +#define MCP3911_CONFIG_CLKEXT BIT(1) > > +#define MCP3911_CONFIG_VREFEXT BIT(2) > > + > > +#define MCP3911_REG_OFFCAL_CH0 0x0e > > +#define MCP3911_REG_GAINCAL_CH00x11 > > +#define MCP3911_REG_OFFCAL_CH1 0x14 > > +#define MCP3911_REG_GAINCAL_CH10x17 > > +#define MCP3911_REG_VREFCAL0x1a > > + > > +#define MCP3911_CHANNEL(x)
Re: [PATCH] iio: chemical: bme680: Add check for val2 in the write_raw function
On Sun, 19 Aug 2018 22:40:14 +0530 Himanshu Jha wrote: > On Sun, Aug 19, 2018 at 05:25:14PM +0100, Jonathan Cameron wrote: > > On Sat, 11 Aug 2018 15:56:36 +0530 > > Himanshu Jha wrote: > > > > > val2 is responsible for the floating part of the number to be > > > written to the device. We don't need the floating part > > > while writing the oversampling ratio for BME680 since the > > > available oversampling ratios are pure natural numbers. > > > > > > So, add a sanity check to make sure val2 is 0. > > > > > > Signed-off-by: Himanshu Jha > > > > As discussed in David's patch series v3, I think this is still relevant > > but now needs an update to cover the new code. > > I already had informed David to reabse his series on top of my patch > and he rebased this patch series. > > So, it should apply cleanly without any further effort. > > If it doesn't, then ping me. Meh, was only some trivial fuzz. I thought things had changed more than that as hadn't noticed you just applied it at the top of write_raw as all the things that can be written in this driver are integers. Anyhow, applied now. Thanks, Jonathan >
Re: [PATCH v4 2/3] dt-bindings: iio: adc: add bindings for mcp3911
On Wed, 8 Aug 2018 10:09:16 +0200
Marcus Folkesson wrote:
> MCP3911 is a dual channel Analog Front End (AFE) containing two
> synchronous sampling delta-sigma Analog-to-Digital Converters (ADC).
>
> Co-Developed-by: Kent Gustavsson
> Signed-off-by: Kent Gustavsson
> Signed-off-by: Marcus Folkesson
> Reviewed-by: Rob Herring
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
thanks,
Jonathan
> ---
>
> Notes:
> v4:
> - remove reference to Documentation/.../interrupts.txt
> - add Kent as co-developer
> v3:
> - add bindings for interrupt
> - prefix device-addr with `microchip`
> - drop `clock-names`
> v2:
> - drop channel width
> - drop `external_vref`
> - replace `external-clock` with proper clock bindings
>
> .../devicetree/bindings/iio/adc/mcp3911.txt| 30
> ++
> 1 file changed, 30 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/mcp3911.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/mcp3911.txt
> b/Documentation/devicetree/bindings/iio/adc/mcp3911.txt
> new file mode 100644
> index ..3071f48fb30b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/mcp3911.txt
> @@ -0,0 +1,30 @@
> +* Microchip MCP3911 Dual channel analog front end (ADC)
> +
> +Required properties:
> + - compatible: Should be "microchip,mcp3911"
> + - reg: SPI chip select number for the device
> +
> +Recommended properties:
> + - spi-max-frequency: Definition as per
> + Documentation/devicetree/bindings/spi/spi-bus.txt.
> + Max frequency for this chip is 20MHz.
> +
> +Optional properties:
> + - clocks: Phandle and clock identifier for sampling clock
> + - interrupt-parent: Phandle to the parent interrupt controller
> + - interrupts: IRQ line for the ADC
> + - microchip,device-addr: Device address when multiple MCP3911 chips are
> present on the
> + same SPI bus. Valid values are 0-3. Defaults to 0.
> + - vref-supply: Phandle to the external reference voltage supply.
> +
> +Example:
> +adc@0 {
> + compatible = "microchip,mcp3911";
> + reg = <0>;
> + interrupt-parent = <&gpio5>;
> + interrupts = <15 IRQ_TYPE_EDGE_RISING>;
> + spi-max-frequency = <2000>;
> + microchip,device-addr = <0>;
> + vref-supply = <&vref_reg>;
> + clocks = <&xtal>;
> +};
Re: [PATCH v4 1/3] iio: adc: add support for mcp3911
On Wed, 8 Aug 2018 10:09:15 +0200
Marcus Folkesson wrote:
> MCP3911 is a dual channel Analog Front End (AFE) containing two
> synchronous sampling delta-sigma Analog-to-Digital Converters (ADC).
>
> Co-Developed-by: Kent Gustavsson
checkpatch points out..
Co-developed-by is the 'official' form of the tag. I'll fixup.
(first time I've seen one of these ;)
> Signed-off-by: Kent Gustavsson
> Signed-off-by: Marcus Folkesson
Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to play with it.
A few really trivial comments inline. Also some slightly odd alignment
I'll fix up that I haven't noted, but not every parameter second line
lines up with the opening brackets correctly.
Jonathan
> ---
>
> Notes:
> v4:
> - remove defined(CONFIG_OF) and of_match_ptr() macro
> - do not check adc->clki as clock api is NULL-aware
> - add Kent as co-developer
> v3:
> - rename adc_clk to clki
> - add error handling/cleanup for clock
> v2:
> - cleanups and bugfixes (thanks Peter Meerwald-Stadler)
> - drop hardware gain
> - use the presence or lack of regulator to indicate if we go for
> internal or external voltage reference
> - do not store device node in private struct
> - drop support to set width in devicetree
> - use the presence or lack of clock to indicate if we go for internal
> or external clock
>
> drivers/iio/adc/Kconfig | 10 ++
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/mcp3911.c | 361
> ++
> 3 files changed, 372 insertions(+)
> create mode 100644 drivers/iio/adc/mcp3911.c
>
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 15606f237480..f9a41fa96fcc 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -501,6 +501,16 @@ config MCP3422
> This driver can also be built as a module. If so, the module will be
> called mcp3422.
>
> +config MCP3911
> + tristate "Microchip Technology MCP3911 driver"
> + depends on SPI
> + help
> + Say yes here to build support for Microchip Technology's MCP3911
> + analog to digital converter.
> +
> + This driver can also be built as a module. If so, the module will be
> + called mcp3911.
> +
> config MEDIATEK_MT6577_AUXADC
> tristate "MediaTek AUXADC driver"
> depends on ARCH_MEDIATEK || COMPILE_TEST
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 28a9423997f3..3cfebfff7d26 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -47,6 +47,7 @@ obj-$(CONFIG_MAX1363) += max1363.o
> obj-$(CONFIG_MAX9611) += max9611.o
> obj-$(CONFIG_MCP320X) += mcp320x.o
> obj-$(CONFIG_MCP3422) += mcp3422.o
> +obj-$(CONFIG_MCP3911) += mcp3911.o
> obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o
> obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
> obj-$(CONFIG_MESON_SARADC) += meson_saradc.o
> diff --git a/drivers/iio/adc/mcp3911.c b/drivers/iio/adc/mcp3911.c
> new file mode 100644
> index ..540c8fbcce89
> --- /dev/null
> +++ b/drivers/iio/adc/mcp3911.c
> @@ -0,0 +1,361 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Driver for Microchip MCP3911, Two-channel Analog Front End
> + *
> + * Copyright (C) 2018 Marcus Folkesson
> + * Copyright (C) 2018 Kent Gustavsson
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define MCP3911_REG_CHANNEL0 0x00
> +#define MCP3911_REG_CHANNEL1 0x03
> +#define MCP3911_REG_MOD 0x06
> +#define MCP3911_REG_PHASE0x07
> +#define MCP3911_REG_GAIN 0x09
> +
> +#define MCP3911_REG_STATUSCOM0x0a
> +#define MCP3911_STATUSCOM_CH1_24WIDTHBIT(4)
> +#define MCP3911_STATUSCOM_CH0_24WIDTHBIT(3)
> +#define MCP3911_STATUSCOM_EN_OFFCAL BIT(2)
> +#define MCP3911_STATUSCOM_EN_GAINCAL BIT(1)
> +
> +#define MCP3911_REG_CONFIG 0x0c
> +#define MCP3911_CONFIG_CLKEXTBIT(1)
> +#define MCP3911_CONFIG_VREFEXT BIT(2)
> +
> +#define MCP3911_REG_OFFCAL_CH0 0x0e
> +#define MCP3911_REG_GAINCAL_CH0 0x11
> +#define MCP3911_REG_OFFCAL_CH1 0x14
> +#define MCP3911_REG_GAINCAL_CH1 0x17
> +#define MCP3911_REG_VREFCAL 0x1a
> +
> +#define MCP3911_CHANNEL(x) (MCP3911_REG_CHANNEL0 + x * 3)
> +#define MCP3911_OFFCAL(x)(MCP3911_REG_OFFCAL_CH0 + x * 6)
> +
> +/* Internal voltage reference in uV */
> +#define MCP3911_INT_VREF_UV 120
> +
> +#define MCP3911_REG_READ(reg, id)reg) << 1) | ((id) << 5) | (1 <<
> 0)) & 0xff)
> +#define MCP3911_REG_WRITE(reg, id) reg) << 1) | ((id) << 5) | (0 <<
> 0)) & 0xff)
> +
> +#define MCP3911_NUM_CHANNELS 2
> +
> +struct mcp3911 {
> + struct spi_device *spi;
> + struct mutex lock;
> + struct regulat
Re: [PATCH 1/3] iio: dac: add support for ltc166x
Hi Jonathan,
Thanks for your comments!
On Sun, Aug 19, 2018 at 05:38:50PM +0100, Jonathan Cameron wrote:
> On Sat, 11 Aug 2018 22:02:24 +0200
> Marcus Folkesson wrote:
>
> > LTC1665/LTC1660 is a 8/10-bit Digital-to-Analog Converter
> > (DAC) with eight individual channels.
> >
> > Signed-off-by: Marcus Folkesson
>
> So first rule we try to stick to that this breaks is never use wild cards
> in drivers. You probably wouldn't believe how often this has gone wrong with
> a manufacturer deciding to use other values that wild card covers...
Hah, I can imagine. I will switch do use ltc1660 all over the place.
>
> Please pick a part and name everything after that. Either one is fine.
>
> A few really minor things inline. Nice little driver.
>
> Thanks,
>
> Jonathan
>
>
> > ---
> > drivers/iio/dac/Kconfig | 10 ++
> > drivers/iio/dac/Makefile | 1 +
> > drivers/iio/dac/ltc166x.c | 244
> > ++
> > 3 files changed, 255 insertions(+)
> > create mode 100644 drivers/iio/dac/ltc166x.c
> >
> > diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
> > index 76db0768e454..04cfa6bb9dc1 100644
> > --- a/drivers/iio/dac/Kconfig
> > +++ b/drivers/iio/dac/Kconfig
> > @@ -120,6 +120,16 @@ config AD5624R_SPI
> > Say yes here to build support for Analog Devices AD5624R, AD5644R and
> > AD5664R converters (DAC). This driver uses the common SPI interface.
> >
> > +config LTC166X
> > + tristate "Linear Technology LTC1660/LTC1665 DAC SPI driver"
> > + depends on SPI
> > + help
> > + Say yes here to build support for Linear Technology
> > + LTC1660 and LTC1665 Digital to Analog Converters.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called ltc166x.
> > +
> > config LTC2632
> > tristate "Linear Technology LTC2632-12/10/8 DAC spi driver"
> > depends on SPI
> > diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
> > index 81e710ed7491..380749c87c26 100644
> > --- a/drivers/iio/dac/Makefile
> > +++ b/drivers/iio/dac/Makefile
> > @@ -26,6 +26,7 @@ obj-$(CONFIG_CIO_DAC) += cio-dac.o
> > obj-$(CONFIG_DPOT_DAC) += dpot-dac.o
> > obj-$(CONFIG_DS4424) += ds4424.o
> > obj-$(CONFIG_LPC18XX_DAC) += lpc18xx_dac.o
> > +obj-$(CONFIG_LTC166X) += ltc166x.o
> > obj-$(CONFIG_LTC2632) += ltc2632.o
> > obj-$(CONFIG_M62332) += m62332.o
> > obj-$(CONFIG_MAX517) += max517.o
> > diff --git a/drivers/iio/dac/ltc166x.c b/drivers/iio/dac/ltc166x.c
> > new file mode 100644
> > index ..0031f2b50f14
> > --- /dev/null
> > +++ b/drivers/iio/dac/ltc166x.c
> > @@ -0,0 +1,244 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Driver for Linear Technology LTC1665/LTC1660, 8 channels DAC
> > + *
> > + * Copyright (C) 2018 Marcus Folkesson
> > + */
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define LTC166X_REG_WAKE 0x0
> > +#define LTC166X_REG_DAC_A 0x1
> > +#define LTC166X_REG_DAC_B 0x2
> > +#define LTC166X_REG_DAC_C 0x3
> > +#define LTC166X_REG_DAC_D 0x4
> > +#define LTC166X_REG_DAC_E 0x5
> > +#define LTC166X_REG_DAC_F 0x6
> > +#define LTC166X_REG_DAC_G 0x7
> > +#define LTC166X_REG_DAC_H 0x8
> > +#define LTC166X_REG_SLEEP 0xe
> > +
> > +#define LTC166X_NUM_CHANNELS 8
> > +
> > +static const struct regmap_config ltc166x_regmap_config = {
> > + .reg_bits = 4,
> > + .val_bits = 12,
> > +};
> > +
> > +enum ltc166x_supported_device_ids {
> > + ID_LTC1660,
> > + ID_LTC1665,
> > +};
> > +
> > +struct ltc166x_priv {
> > + struct spi_device *spi;
> > + struct regmap *regmap;
> > + struct regulator *vref_reg;
> > + unsigned int value[LTC166X_NUM_CHANNELS];
> > + unsigned int vref_mv;
> > +};
> > +
> > +static int ltc166x_read_raw(struct iio_dev *indio_dev,
> > + struct iio_chan_spec const *chan,
> > + int *val,
> > + int *val2,
> > + long mask)
> > +{
> > + struct ltc166x_priv *priv = iio_priv(indio_dev);
> > +
> > + switch (mask) {
> > + case IIO_CHAN_INFO_RAW:
> > + *val = priv->value[chan->channel];
> > + return IIO_VAL_INT;
> > + case IIO_CHAN_INFO_SCALE:
> > + *val = priv->vref_mv;
> > + *val2 = chan->scan_type.realbits;
> > + return IIO_VAL_FRACTIONAL_LOG2;
> > + default:
> > + return -EINVAL;
> > + }
> > +}
> > +
> > +static int ltc166x_write_raw(struct iio_dev *indio_dev,
> > + struct iio_chan_spec const *chan,
> > + int val,
> > + int val2,
> > + long mask)
> > +{
> > + struct ltc166x_priv *priv = iio_priv(indio_dev);
> > +
> > + switch (mask) {
> > + case IIO_CHAN_INFO_RAW:
> > + if (val2 != 0)
> > + return -EINVAL;
> > + if (val > GENMASK(chan->scan_type.realbits-1, 0))
> > + return -EINVAL;
>
> nothing makes val positive.. Also spac
Re: [PATCH v6 1/2] iio: light: Add support for vishay vcnl4035
On Tue, 7 Aug 2018 12:27:03 +0200 Parthiban Nallathambi wrote: > Add support for VCNL4035, which is capable of Ambient light > sensing (ALS) and proximity function. This patch adds support > only for ALS function > > Signed-off-by: Parthiban Nallathambi > Changelog should be below the --- as we don't want it in the final git commit log. > Changelog since v1: > > 1. Fixed 0-day warning on le16_to_cpu usage > 2. Persistence value is directly mapped to datasheet's value to > avoid confusions of usage from sysfs > > Changelog in v3: > - Usage of lock is not needed, removed mutex locking > - ALS threshold and persistence configuration available > as events and threshold events are notified to userspace > - Usage of devm_ is re-ordered and exit handling updated > - Complexity in timestamp calculation is removed and used > iio_get_time_ns > > Changelog in v4: > - New white light index is introduced for getting data from > white spectrum > - PM enable/disable is called from read_raw accordingly > - Probe exit handling re-ordered > > Changelog in v5: > - White spectrum is mesaured as "_CLEAR" intesity, so removed > white spectrum modifier > - Header re-ordering > - Trigger init and de-init into separate function > - Indentation correct and usage of dev_err in place of pr_err > > Changelog in v6: > - Usage of devm_ for trigger probing and cleanups > - pm_runtime re-order and exit patch corrections > - IIO_INTENSITY to IIO_LIGHT, lux/steps are fixed at IT cycle > lux can be calculated based on IT sensitivity > - _CLEAR to _BOTH although measurement is only WHITE spectrum > for traditional reasons My main issue remaining in here is with the ordering in probe and remove. It becomes very messy and unclear once runtime_pm is present. I've note how I think that can be cleaned up though such that the remove is the obvious unwind of the probe. Unless I missing something (more than possible on a Sunday evening after a nice dinner :) you aren't actually stopping the device from auto suspending when running in buffered mode. Jonathan > --- > drivers/iio/light/Kconfig| 12 + > drivers/iio/light/Makefile | 1 + > drivers/iio/light/vcnl4035.c | 686 > +++ > 3 files changed, 699 insertions(+) > create mode 100644 drivers/iio/light/vcnl4035.c > > diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig > index c7ef8d1862d6..b7069a4c28a2 100644 > --- a/drivers/iio/light/Kconfig > +++ b/drivers/iio/light/Kconfig > @@ -447,6 +447,18 @@ config VCNL4000 >To compile this driver as a module, choose M here: the >module will be called vcnl4000. > > +config VCNL4035 > + tristate "VCNL4035 combined ALS and proximity sensor" > + select REGMAP_I2C > + depends on I2C > + help > + Say Y here if you want to build a driver for the Vishay VCNL4035, > + combined ambient light (ALS) and proximity sensor. Currently only ALS > + function is available. > + > + To compile this driver as a module, choose M here: the > + module will be called vcnl4035. > + > config VEML6070 > tristate "VEML6070 UV A light sensor" > depends on I2C > diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile > index 80943af5d627..dce98511a59b 100644 > --- a/drivers/iio/light/Makefile > +++ b/drivers/iio/light/Makefile > @@ -44,6 +44,7 @@ obj-$(CONFIG_TSL2772) += tsl2772.o > obj-$(CONFIG_TSL4531)+= tsl4531.o > obj-$(CONFIG_US5182D)+= us5182d.o > obj-$(CONFIG_VCNL4000) += vcnl4000.o > +obj-$(CONFIG_VCNL4035) += vcnl4035.o > obj-$(CONFIG_VEML6070) += veml6070.o > obj-$(CONFIG_VL6180) += vl6180.o > obj-$(CONFIG_ZOPT2201) += zopt2201.o > diff --git a/drivers/iio/light/vcnl4035.c b/drivers/iio/light/vcnl4035.c > new file mode 100644 > index ..e9f471d93a15 > --- /dev/null > +++ b/drivers/iio/light/vcnl4035.c > @@ -0,0 +1,686 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * VCNL4035 Ambient Light and Proximity Sensor - 7-bit I2C slave address 0x60 > + * > + * Copyright (c) 2018, DENX Software Engineering GmbH > + * Author: Parthiban Nallathambi > + * Nitpick. One blank line is plenty here. > + * > + * TODO: Proximity > + */ > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define VCNL4035_DRV_NAME"vcnl4035" > +#define VCNL4035_IRQ_NAME"vcnl4035_event" > +#define VCNL4035_REGMAP_NAME "vcnl4035_regmap" > + > +/* Device registers */ > +#define VCNL4035_ALS_CONF0x00 > +#define VCNL4035_ALS_THDH0x01 > +#define VCNL4035_ALS_THDL0x02 > +#define VCNL4035_ALS_DATA0x0B > +#define VCNL4035_WHITE_DATA 0x0C > +#define VCNL4035_INT_FLAG0x0D > +#define VCNL4035_DEV_ID 0x0E > + > +/* Register masks */ > +#define VCNL4035_MODE_ALS_MASK B
[PATCH] security/capabilities: remove check for -EINVAL
bprm_caps_from_vfs_caps() does not return -EINVAL anymore so remove the rc == -EINVAL check. Signed-off-by: Christian Brauner --- security/commoncap.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/security/commoncap.c b/security/commoncap.c index f4c33abd9959..6012f0cd8157 100644 --- a/security/commoncap.c +++ b/security/commoncap.c @@ -684,9 +684,6 @@ static int get_file_caps(struct linux_binprm *bprm, bool *effective, bool *has_f } rc = bprm_caps_from_vfs_caps(&vcaps, bprm, effective, has_fcap); - if (rc == -EINVAL) - printk(KERN_NOTICE "%s: cap_from_disk returned %d for %s\n", - __func__, rc, bprm->filename); out: if (rc) -- 2.17.1
Re: [PATCH] i2c: Remove '-Wno-deprecated-declarations' compiler warning
Hi Sedat,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on wsa/i2c/for-next]
[also build test WARNING on v4.18 next-20180817]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Sedat-Dilek/i2c-Remove-Wno-deprecated-declarations-compiler-warning/20180819-55
base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
i2c/for-next
config: i386-randconfig-x016-201833 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers//i2c/i2c-core-base.c: In function 'i2c_do_add_adapter':
drivers//i2c/i2c-core-base.c:1128:2: warning: 'attach_adapter' is deprecated
[-Wdeprecated-declarations]
if (driver->attach_adapter) {
^~
In file included from drivers//i2c/i2c-core-base.c:31:0:
include/linux/i2c.h:274:8: note: declared here
int (*attach_adapter)(struct i2c_adapter *) __deprecated;
^~
drivers//i2c/i2c-core-base.c:1128:2: warning: 'attach_adapter' is deprecated
[-Wdeprecated-declarations]
if (driver->attach_adapter) {
^~
In file included from drivers//i2c/i2c-core-base.c:31:0:
include/linux/i2c.h:274:8: note: declared here
int (*attach_adapter)(struct i2c_adapter *) __deprecated;
^~
In file included from include/linux/ioport.h:13:0,
from include/linux/acpi.h:25,
from drivers//i2c/i2c-core-base.c:24:
>> include/linux/compiler.h:61:17: warning: 'attach_adapter' is deprecated
>> [-Wdeprecated-declarations]
static struct ftrace_branch_data \
^
include/linux/compiler.h:56:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
^~
>> drivers//i2c/i2c-core-base.c:1128:2: note: in expansion of macro 'if'
if (driver->attach_adapter) {
^~
In file included from drivers//i2c/i2c-core-base.c:31:0:
include/linux/i2c.h:274:8: note: declared here
int (*attach_adapter)(struct i2c_adapter *) __deprecated;
^~
drivers//i2c/i2c-core-base.c:1134:3: warning: 'attach_adapter' is deprecated
[-Wdeprecated-declarations]
driver->attach_adapter(adap);
^~
In file included from drivers//i2c/i2c-core-base.c:31:0:
include/linux/i2c.h:274:8: note: declared here
int (*attach_adapter)(struct i2c_adapter *) __deprecated;
^~
Cyclomatic Complexity 5 include/linux/compiler.h:__read_once_size
Cyclomatic Complexity 5 include/linux/compiler.h:__write_once_size
Cyclomatic Complexity 1 include/linux/kasan-checks.h:kasan_check_read
Cyclomatic Complexity 1 include/linux/kasan-checks.h:kasan_check_write
Cyclomatic Complexity 1 include/linux/ioport.h:resource_type
Cyclomatic Complexity 3 arch/x86/include/asm/bitops.h:clear_bit
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:variable_test_bit
Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls
Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u32
Cyclomatic Complexity 1 include/linux/list.h:INIT_LIST_HEAD
Cyclomatic Complexity 1 include/linux/list.h:__list_add_valid
Cyclomatic Complexity 1 include/linux/list.h:__list_del_entry_valid
Cyclomatic Complexity 2 include/linux/list.h:__list_add
Cyclomatic Complexity 1 include/linux/list.h:list_add_tail
Cyclomatic Complexity 1 include/linux/list.h:__list_del
Cyclomatic Complexity 2 include/linux/list.h:__list_del_entry
Cyclomatic Complexity 1 include/linux/list.h:list_del
Cyclomatic Complexity 1 include/linux/list.h:hlist_empty
Cyclomatic Complexity 1 include/asm-generic/getorder.h:__get_order
Cyclomatic Complexity 1 include/linux/cpumask.h:cpumask_check
Cyclomatic Complexity 1 include/linux/cpumask.h:cpumask_test_cpu
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_read
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_inc
Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_dec
Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_read
Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_inc
Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_dec
Cyclomatic Complexity 1 include/linux/jump_label.h:static_key_count
Cyclomatic Complexity 2 include/linux/jump_label.h:static_key_false
Cyclomatic Complexity 1 arch/x86/include/asm/paravirt.h:arch_local_save_flags
Cyclomatic Complexity 1
arch/x86/include/asm/irqflags.h:arch_irqs_disabled_flags
Cyclomatic Complexity 1 arch/x86/include/asm/preempt.h:preempt_count
Cycl
Re: [PATCH v6 1/2] iio: light: Add support for vishay vcnl4035
On Sat, 11 Aug 2018 23:25:41 +0800 kbuild test robot wrote: > Hi Parthiban, > > Thank you for the patch! Yet something to improve: The issue here is I think that you should be simply calling hweight8 rather than directly calling the fallback software version. I 'might' fix that up if it is the only issue known to remain. Thanks, Jonathan > > [auto build test ERROR on iio/togreg] > [also build test ERROR on v4.18-rc8 next-20180810] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Parthiban-Nallathambi/iio-light-Add-support-for-vishay-vcnl4035/20180810-012903 > base: https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg > config: ia64-allmodconfig (attached as .config) > compiler: ia64-linux-gcc (GCC) 8.1.0 > reproduce: > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > GCC_VERSION=8.1.0 make.cross ARCH=ia64 > > All errors (new ones prefixed by >>): > >ERROR: "ia64_delay_loop" [drivers/spi/spi-thunderx.ko] undefined! >ERROR: "__sw_hweight8" [drivers/net/wireless/mediatek/mt76/mt76.ko] > undefined! >ERROR: "ia64_delay_loop" [drivers/net/phy/mdio-cavium.ko] undefined! > >> ERROR: "__sw_hweight8" [drivers/iio/light/vcnl4035.ko] undefined! > > --- > 0-DAY kernel test infrastructureOpen Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCH] iio: max44000: remove unused variable max44000_alstim_shift
On Thu, 9 Aug 2018 14:53:38 +0100
Colin King wrote:
> From: Colin Ian King
>
> Variable max44000_alstim_shift is defined but is never used hence it is
> redundant and can be removed. This variable has been like this since
> the driver was added back in 2016.
>
> Cleans up clang warning:
> warning: 'max44000_alstim_shift' defined but not used
> [-Wunused-const-variable=]
>
> Signed-off-by: Colin Ian King
Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/light/max44000.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/iio/light/max44000.c b/drivers/iio/light/max44000.c
> index bcdb0eb9e537..b9b0bd341be8 100644
> --- a/drivers/iio/light/max44000.c
> +++ b/drivers/iio/light/max44000.c
> @@ -99,7 +99,6 @@ static const int max44000_alspga_shift[] = {0, 2, 4, 7};
> * Handling this internally is also required for buffer support because the
> * channel's scan_type can't be modified dynamically.
> */
> -static const int max44000_alstim_shift[] = {0, 2, 4, 6};
> #define MAX44000_ALSTIM_SHIFT(alstim) (2 * (alstim))
>
> /* Available integration times with pretty manual alignment: */
Re: [PATCH v6 4/6] iio:adxl372: Add FIFO and interrupts support
On Sun, 19 Aug 2018 18:12:18 +0100
Jonathan Cameron wrote:
> On Fri, 10 Aug 2018 11:46:21 +0300
> Stefan Popa wrote:
>
> > This patch adds support for the adxl372 FIFO. In order to accomplish this,
> > triggered buffers were used.
> >
> > The number of FIFO samples which trigger the watermark interrupt can be
> > configured by using the buffer watermark. The FIFO format is determined by
> > configuring the scan elements for each axis. The FIFO data is pushed to the
> > IIO device's buffer.
> >
> > Signed-off-by: Stefan Popa
>
> one minor item I'd missed previously. I'll fix it whilst applying.
I was wrong on this, so no need to make that change.
>
> Applied to the togreg branch of iio.git and pushed out as testing
> to see what we've all missed that the autobuilders might find.
Dropped for now because of issues in the other email I just sent.
I'll hold the rest of the series until those are sorted.
Jonathan
>
> Thanks,
>
> Jonathan
>
> > ---
> > drivers/iio/accel/adxl372.c | 357
> > +++-
> > 1 file changed, 356 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
> > index db9ecd2..1e2519a 100644
> > --- a/drivers/iio/accel/adxl372.c
> > +++ b/drivers/iio/accel/adxl372.c
> > @@ -6,12 +6,19 @@
> > */
> >
> > #include
> > +#include
> > +#include
> > #include
> > #include
> > #include
> >
> > #include
> > #include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> >
> > /* ADXL372 registers definition */
> > #define ADXL372_DEVID 0x00
> > @@ -123,6 +130,9 @@
> > #define ADXL372_INT1_MAP_LOW_MSK BIT(7)
> > #define ADXL372_INT1_MAP_LOW_MODE(x) (((x) & 0x1) << 7)
> >
> > +/* The ADXL372 includes a deep, 512 sample FIFO buffer */
> > +#define ADXL372_FIFO_SIZE 512
> > +
> > /*
> > * At +/- 200g with 12-bit resolution, scale is computed as:
> > * (200 + 200) * 9.81 / (2^12 - 1) = 0.958241
> > @@ -170,6 +180,43 @@ static const unsigned int adxl372_th_reg_high_addr[3]
> > = {
> > [ADXL372_INACTIVITY] = ADXL372_X_THRESH_INACT_H,
> > };
> >
> > +enum adxl372_fifo_format {
> > + ADXL372_XYZ_FIFO,
> > + ADXL372_X_FIFO,
> > + ADXL372_Y_FIFO,
> > + ADXL372_XY_FIFO,
> > + ADXL372_Z_FIFO,
> > + ADXL372_XZ_FIFO,
> > + ADXL372_YZ_FIFO,
> > + ADXL372_XYZ_PEAK_FIFO,
> > +};
> > +
> > +enum adxl372_fifo_mode {
> > + ADXL372_FIFO_BYPASSED,
> > + ADXL372_FIFO_STREAMED,
> > + ADXL372_FIFO_TRIGGERED,
> > + ADXL372_FIFO_OLD_SAVED
> > +};
> > +
> > +static const int adxl372_samp_freq_tbl[5] = {
> > + 400, 800, 1600, 3200, 6400,
> > +};
> > +
> > +struct adxl372_axis_lookup {
> > + unsigned int bits;
> > + enum adxl372_fifo_format fifo_format;
> > +};
> > +
> > +static const struct adxl372_axis_lookup adxl372_axis_lookup_table[] = {
> > + { BIT(0), ADXL372_X_FIFO },
> > + { BIT(1), ADXL372_Y_FIFO },
> > + { BIT(2), ADXL372_Z_FIFO },
> > + { BIT(0) | BIT(1), ADXL372_XY_FIFO },
> > + { BIT(0) | BIT(2), ADXL372_XZ_FIFO },
> > + { BIT(1) | BIT(2), ADXL372_YZ_FIFO },
> > + { BIT(0) | BIT(1) | BIT(2), ADXL372_XYZ_FIFO },
> > +};
> > +
> > #define ADXL372_ACCEL_CHANNEL(index, reg, axis) { \
> > .type = IIO_ACCEL, \
> > .address = reg, \
> > @@ -177,6 +224,13 @@ static const unsigned int adxl372_th_reg_high_addr[3]
> > = {
> > .channel2 = IIO_MOD_##axis, \
> > .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> > .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
> > + .scan_index = index,\
> > + .scan_type = { \
> > + .sign = 's',\
> > + .realbits = 12, \
> > + .storagebits = 16, \
> > + .shift = 4, \
> > + }, \
> > }
> >
> > static const struct iio_chan_spec adxl372_channels[] = {
> > @@ -188,12 +242,29 @@ static const struct iio_chan_spec adxl372_channels[]
> > = {
> > struct adxl372_state {
> > struct spi_device *spi;
> > struct regmap *regmap;
> > + struct iio_trigger *dready_trig;
> > + enum adxl372_fifo_mode fifo_mode;
> > + enum adxl372_fifo_formatfifo_format;
> > enum adxl372_op_modeop_mode;
> > enum adxl372_act_proc_mode act_proc_mode;
> > enum adxl372_odrodr;
> > enum adxl372_bandwidth bw;
> > u32 act_time_ms;
> > u32
[PATCH] staging: rtl8188eu: Removed unneeded variable
This patch removed unneeded variable named ret because this variable is
used only to return 0.
Signed-off-by: Bhaskar Singh
---
drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
index bee3c3a7a7a9..4801345a2b57 100644
--- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
@@ -1370,7 +1370,7 @@ static int rtw_wx_get_essid(struct net_device *dev,
struct iw_request_info *a,
union iwreq_data *wrqu, char *extra)
{
- u32 len, ret = 0;
+ u32 len;
struct adapter *padapter = (struct adapter *)rtw_netdev_priv(dev);
struct mlme_priv *pmlmepriv = &(padapter->mlmepriv);
struct wlan_bssid_ex *pcur_bss = &pmlmepriv->cur_network.network;
@@ -1388,7 +1388,7 @@ static int rtw_wx_get_essid(struct net_device *dev,
wrqu->essid.length = len;
wrqu->essid.flags = 1;
- return ret;
+ return 0;
}
static int rtw_wx_set_rate(struct net_device *dev,
--
2.16.4
Re: [PATCH v6 4/6] iio:adxl372: Add FIFO and interrupts support
On Fri, 10 Aug 2018 11:46:21 +0300
Stefan Popa wrote:
> This patch adds support for the adxl372 FIFO. In order to accomplish this,
> triggered buffers were used.
>
> The number of FIFO samples which trigger the watermark interrupt can be
> configured by using the buffer watermark. The FIFO format is determined by
> configuring the scan elements for each axis. The FIFO data is pushed to the
> IIO device's buffer.
>
> Signed-off-by: Stefan Popa
Hi Stefan, I'm afraid I missed a few things on previous versions of this.
If we are going to expose a general purpose trigger or allow a driver
to use a general purpose trigger (this currently does both as neither validate
function is provided to limit it's usage), then the trigger 'must' correspond
to one interrupt per reading. It's absolutely fine to have a device specific
trigger where that isn't true though normally we would only bother exposing it
as a trigger if there as an alternative.
A classic case would be that we have a fifo and use it if the trigger is the
devices only trigger, but in the event of a different trigger being selected
we are happy to use it with the fifo length set to 1 (or it just turned off).
That allows the use of say a sysfs of hrtimer trigger with us getting the
expected
1 sample set per trigger, and the use of the fifo for this device alone.
To do that you have make sure you have a validate_device callback provided
for the trigger so it rejects other devices.
We can just forgo alternative triggers and have the buffer driven directly.
I don't really like that option though as it leads to abi changes if we ever
want to add alternatives in future though we can sort of get around that using
default triggers.
So the simple solution for now is to provide validate_trigger and
validate_device
callbacks to fix it to use them only when they are the same device.
We can do clever stuff later if needed to enable other triggers.
Jonathan
> ---
> drivers/iio/accel/adxl372.c | 357
> +++-
> 1 file changed, 356 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
> index db9ecd2..1e2519a 100644
> --- a/drivers/iio/accel/adxl372.c
> +++ b/drivers/iio/accel/adxl372.c
> @@ -6,12 +6,19 @@
> */
>
> #include
> +#include
> +#include
> #include
> #include
> #include
>
> #include
> #include
> +#include
> +#include
Why events?
> +#include
> +#include
> +#include
>
> /* ADXL372 registers definition */
> #define ADXL372_DEVID0x00
> @@ -123,6 +130,9 @@
> #define ADXL372_INT1_MAP_LOW_MSK BIT(7)
> #define ADXL372_INT1_MAP_LOW_MODE(x) (((x) & 0x1) << 7)
>
> +/* The ADXL372 includes a deep, 512 sample FIFO buffer */
> +#define ADXL372_FIFO_SIZE512
> +
> /*
> * At +/- 200g with 12-bit resolution, scale is computed as:
> * (200 + 200) * 9.81 / (2^12 - 1) = 0.958241
> @@ -170,6 +180,43 @@ static const unsigned int adxl372_th_reg_high_addr[3] = {
> [ADXL372_INACTIVITY] = ADXL372_X_THRESH_INACT_H,
> };
>
> +enum adxl372_fifo_format {
> + ADXL372_XYZ_FIFO,
> + ADXL372_X_FIFO,
> + ADXL372_Y_FIFO,
> + ADXL372_XY_FIFO,
> + ADXL372_Z_FIFO,
> + ADXL372_XZ_FIFO,
> + ADXL372_YZ_FIFO,
> + ADXL372_XYZ_PEAK_FIFO,
> +};
> +
> +enum adxl372_fifo_mode {
> + ADXL372_FIFO_BYPASSED,
> + ADXL372_FIFO_STREAMED,
> + ADXL372_FIFO_TRIGGERED,
> + ADXL372_FIFO_OLD_SAVED
> +};
> +
> +static const int adxl372_samp_freq_tbl[5] = {
> + 400, 800, 1600, 3200, 6400,
> +};
> +
> +struct adxl372_axis_lookup {
> + unsigned int bits;
> + enum adxl372_fifo_format fifo_format;
> +};
> +
> +static const struct adxl372_axis_lookup adxl372_axis_lookup_table[] = {
> + { BIT(0), ADXL372_X_FIFO },
> + { BIT(1), ADXL372_Y_FIFO },
> + { BIT(2), ADXL372_Z_FIFO },
> + { BIT(0) | BIT(1), ADXL372_XY_FIFO },
> + { BIT(0) | BIT(2), ADXL372_XZ_FIFO },
> + { BIT(1) | BIT(2), ADXL372_YZ_FIFO },
> + { BIT(0) | BIT(1) | BIT(2), ADXL372_XYZ_FIFO },
> +};
> +
> #define ADXL372_ACCEL_CHANNEL(index, reg, axis) {\
> .type = IIO_ACCEL, \
> .address = reg, \
> @@ -177,6 +224,13 @@ static const unsigned int adxl372_th_reg_high_addr[3] = {
> .channel2 = IIO_MOD_##axis, \
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
> + .scan_index = index,\
> + .scan_type = { \
> + .sign = 's',\
> + .realbits = 12, \
> + .storagebits = 16,
Re: [PATCH v6 4/6] iio:adxl372: Add FIFO and interrupts support
On Fri, 10 Aug 2018 11:46:21 +0300
Stefan Popa wrote:
> This patch adds support for the adxl372 FIFO. In order to accomplish this,
> triggered buffers were used.
>
> The number of FIFO samples which trigger the watermark interrupt can be
> configured by using the buffer watermark. The FIFO format is determined by
> configuring the scan elements for each axis. The FIFO data is pushed to the
> IIO device's buffer.
>
> Signed-off-by: Stefan Popa
one minor item I'd missed previously. I'll fix it whilst applying.
Applied to the togreg branch of iio.git and pushed out as testing
to see what we've all missed that the autobuilders might find.
Thanks,
Jonathan
> ---
> drivers/iio/accel/adxl372.c | 357
> +++-
> 1 file changed, 356 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
> index db9ecd2..1e2519a 100644
> --- a/drivers/iio/accel/adxl372.c
> +++ b/drivers/iio/accel/adxl372.c
> @@ -6,12 +6,19 @@
> */
>
> #include
> +#include
> +#include
> #include
> #include
> #include
>
> #include
> #include
> +#include
> +#include
> +#include
> +#include
> +#include
>
> /* ADXL372 registers definition */
> #define ADXL372_DEVID0x00
> @@ -123,6 +130,9 @@
> #define ADXL372_INT1_MAP_LOW_MSK BIT(7)
> #define ADXL372_INT1_MAP_LOW_MODE(x) (((x) & 0x1) << 7)
>
> +/* The ADXL372 includes a deep, 512 sample FIFO buffer */
> +#define ADXL372_FIFO_SIZE512
> +
> /*
> * At +/- 200g with 12-bit resolution, scale is computed as:
> * (200 + 200) * 9.81 / (2^12 - 1) = 0.958241
> @@ -170,6 +180,43 @@ static const unsigned int adxl372_th_reg_high_addr[3] = {
> [ADXL372_INACTIVITY] = ADXL372_X_THRESH_INACT_H,
> };
>
> +enum adxl372_fifo_format {
> + ADXL372_XYZ_FIFO,
> + ADXL372_X_FIFO,
> + ADXL372_Y_FIFO,
> + ADXL372_XY_FIFO,
> + ADXL372_Z_FIFO,
> + ADXL372_XZ_FIFO,
> + ADXL372_YZ_FIFO,
> + ADXL372_XYZ_PEAK_FIFO,
> +};
> +
> +enum adxl372_fifo_mode {
> + ADXL372_FIFO_BYPASSED,
> + ADXL372_FIFO_STREAMED,
> + ADXL372_FIFO_TRIGGERED,
> + ADXL372_FIFO_OLD_SAVED
> +};
> +
> +static const int adxl372_samp_freq_tbl[5] = {
> + 400, 800, 1600, 3200, 6400,
> +};
> +
> +struct adxl372_axis_lookup {
> + unsigned int bits;
> + enum adxl372_fifo_format fifo_format;
> +};
> +
> +static const struct adxl372_axis_lookup adxl372_axis_lookup_table[] = {
> + { BIT(0), ADXL372_X_FIFO },
> + { BIT(1), ADXL372_Y_FIFO },
> + { BIT(2), ADXL372_Z_FIFO },
> + { BIT(0) | BIT(1), ADXL372_XY_FIFO },
> + { BIT(0) | BIT(2), ADXL372_XZ_FIFO },
> + { BIT(1) | BIT(2), ADXL372_YZ_FIFO },
> + { BIT(0) | BIT(1) | BIT(2), ADXL372_XYZ_FIFO },
> +};
> +
> #define ADXL372_ACCEL_CHANNEL(index, reg, axis) {\
> .type = IIO_ACCEL, \
> .address = reg, \
> @@ -177,6 +224,13 @@ static const unsigned int adxl372_th_reg_high_addr[3] = {
> .channel2 = IIO_MOD_##axis, \
> .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
> .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
> + .scan_index = index,\
> + .scan_type = { \
> + .sign = 's',\
> + .realbits = 12, \
> + .storagebits = 16, \
> + .shift = 4, \
> + }, \
> }
>
> static const struct iio_chan_spec adxl372_channels[] = {
> @@ -188,12 +242,29 @@ static const struct iio_chan_spec adxl372_channels[] = {
> struct adxl372_state {
> struct spi_device *spi;
> struct regmap *regmap;
> + struct iio_trigger *dready_trig;
> + enum adxl372_fifo_mode fifo_mode;
> + enum adxl372_fifo_formatfifo_format;
> enum adxl372_op_modeop_mode;
> enum adxl372_act_proc_mode act_proc_mode;
> enum adxl372_odrodr;
> enum adxl372_bandwidth bw;
> u32 act_time_ms;
> u32 inact_time_ms;
> + u8 fifo_set_size;
> + u8 int1_bitmask;
> + u8 int2_bitmask;
> + u16 watermark;
> + __be16 fifo_buf[ADXL372_FIFO_SIZE];
> +};
> +
> +static const unsigned long adxl372_channel_masks[] = {
> + BIT(0), BIT(1), BIT(2),
> + BIT(0)
Re: [PATCH] iio: chemical: bme680: Add check for val2 in the write_raw function
On Sun, Aug 19, 2018 at 05:25:14PM +0100, Jonathan Cameron wrote: > On Sat, 11 Aug 2018 15:56:36 +0530 > Himanshu Jha wrote: > > > val2 is responsible for the floating part of the number to be > > written to the device. We don't need the floating part > > while writing the oversampling ratio for BME680 since the > > available oversampling ratios are pure natural numbers. > > > > So, add a sanity check to make sure val2 is 0. > > > > Signed-off-by: Himanshu Jha > > As discussed in David's patch series v3, I think this is still relevant > but now needs an update to cover the new code. I already had informed David to reabse his series on top of my patch and he rebased this patch series. So, it should apply cleanly without any further effort. If it doesn't, then ping me. -- Himanshu Jha Undergraduate Student Department of Electronics & Communication Guru Tegh Bahadur Institute of Technology
Re: [PATCH v6 3/6] regmap: Add regmap_noinc_read API
On Fri, 10 Aug 2018 11:38:56 +0100 Mark Brown wrote: > On Fri, Aug 10, 2018 at 11:46:20AM +0300, Stefan Popa wrote: > > From: Crestez Dan Leonard > > > > The regmap API usually assumes that bulk read operations will read a > > range of registers but some I2C/SPI devices have certain registers for > > which a such a read operation will return data from an internal FIFO > > instead. Add an explicit API to support bulk read without range semantics. > > Please don't resubmit patches that have already been applied, you should > submit patches against current code in the tree you're expecting things > to be applied to. If any updates are needed to a patch that's already > been applied you should submit incremental patches which make those > updates. This avoids having to change published git commits which could > cause problems for people working against git. I've merged the regmap branch in question into iio.git. To add to Mark's comment it would have been helpful to have the cover letter mention the need to do that with a copy of what Mark replied with when he took this patch (as it gives me the details I need to pick up that branch). Jonathan
Re: [PATCH v6 2/6] dt-bindings: iio: accel: Add docs for ADXL372
On Fri, 10 Aug 2018 11:46:19 +0300
Stefan Popa wrote:
> Add the device tree binding documentation for the ADXL372 3-axis digital
> accelerometer.
>
> Signed-off-by: Stefan Popa
> Reviewed-by: Rob Herring
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
thanks,
Jonathan
> ---
> .../devicetree/bindings/iio/accel/adxl372.txt | 22
> ++
> MAINTAINERS| 1 +
> 2 files changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/accel/adxl372.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/accel/adxl372.txt
> b/Documentation/devicetree/bindings/iio/accel/adxl372.txt
> new file mode 100644
> index 000..9409984
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/accel/adxl372.txt
> @@ -0,0 +1,22 @@
> +Analog Devices ADXL372 3-Axis, +/-(200g) Digital Accelerometer
> +
> +http://www.analog.com/media/en/technical-documentation/data-sheets/adxl372.pdf
> +
> +Required properties:
> + - compatible : should be "adi,adxl372"
> + - reg: SPI chip select number for the device
> + - spi-max-frequency: Max SPI frequency to use
> +
> +Optional properties:
> + - interrupts: interrupt mapping for IRQ as documented in
> + Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> +
> +Example:
> +
> + accelerometer@0 {
> + compatible = "adi,adxl372";
> + reg = <0>;
> + spi-max-frequency = <100>;
> + interrupt-parent = <&gpio>;
> + interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2ba47bb..c8dd09c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -548,6 +548,7 @@ M:Stefan Popa
> W: http://ez.analog.com/community/linux-device-drivers
> S: Supported
> F: drivers/iio/accel/adxl372.c
> +F: Documentation/devicetree/bindings/iio/accel/adxl372.txt
>
> AF9013 MEDIA DRIVER
> M: Antti Palosaari
Re: [PATCH v6 1/6] iio: adxl372: New driver for Analog Devices ADXL372 Accelerometer
On Fri, 10 Aug 2018 11:46:18 +0300 Stefan Popa wrote: > This patch adds basic support for Analog Devices ADXL372 SPI-Bus > Three-Axis Digital Accelerometer. > > The device is probed and configured the with some initial default > values. With this basic driver, it is possible to read raw acceleration > data. > > Datasheet: > http://www.analog.com/media/en/technical-documentation/data-sheets/ADXL372.pdf > > Signed-off-by: Stefan Popa Applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to play with it. I fixed up the module license - assuming you are fine with the or later version given that is what was documented by SPDX. Thanks, Jonathan > --- > MAINTAINERS | 6 + > drivers/iio/accel/Kconfig | 11 + > drivers/iio/accel/Makefile | 1 + > drivers/iio/accel/adxl372.c | 525 > > 4 files changed, 543 insertions(+) > create mode 100644 drivers/iio/accel/adxl372.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 60b1028..2ba47bb 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -543,6 +543,12 @@ W: > http://ez.analog.com/community/linux-device-drivers > S: Supported > F: drivers/input/misc/adxl34x.c > > +ADXL372 THREE-AXIS DIGITAL ACCELEROMETER DRIVER > +M: Stefan Popa > +W: http://ez.analog.com/community/linux-device-drivers > +S: Supported > +F: drivers/iio/accel/adxl372.c > + > AF9013 MEDIA DRIVER > M: Antti Palosaari > L: linux-me...@vger.kernel.org > diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig > index 62ae7e5..1b496ef 100644 > --- a/drivers/iio/accel/Kconfig > +++ b/drivers/iio/accel/Kconfig > @@ -60,6 +60,17 @@ config ADXL345_SPI > will be called adxl345_spi and you will also get adxl345_core > for the core module. > > +config ADXL372 > + tristate "Analog Devices ADXL372 3-Axis Accelerometer Driver" > + depends on SPI > + select IIO_BUFFER > + select IIO_TRIGGERED_BUFFER > + help > + Say yes here to add support for the Analog Devices ADXL372 triaxial > + acceleration sensor. > + To compile this driver as a module, choose M here: the > + module will be called adxl372. > + > config BMA180 > tristate "Bosch BMA180/BMA250 3-Axis Accelerometer Driver" > depends on I2C > diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile > index 636d4d1..5758ffc 100644 > --- a/drivers/iio/accel/Makefile > +++ b/drivers/iio/accel/Makefile > @@ -9,6 +9,7 @@ obj-$(CONFIG_ADIS16209) += adis16209.o > obj-$(CONFIG_ADXL345) += adxl345_core.o > obj-$(CONFIG_ADXL345_I2C) += adxl345_i2c.o > obj-$(CONFIG_ADXL345_SPI) += adxl345_spi.o > +obj-$(CONFIG_ADXL372) += adxl372.o > obj-$(CONFIG_BMA180) += bma180.o > obj-$(CONFIG_BMA220) += bma220_spi.o > obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel-core.o > diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c > new file mode 100644 > index 000..db9ecd2 > --- /dev/null > +++ b/drivers/iio/accel/adxl372.c > @@ -0,0 +1,525 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * ADXL372 3-Axis Digital Accelerometer SPI driver > + * > + * Copyright 2018 Analog Devices Inc. > + */ > + > +#include > +#include > +#include > +#include > + > +#include > +#include > + > +/* ADXL372 registers definition */ > +#define ADXL372_DEVID0x00 > +#define ADXL372_DEVID_MST0x01 > +#define ADXL372_PARTID 0x02 > +#define ADXL372_REVID0x03 > +#define ADXL372_STATUS_1 0x04 > +#define ADXL372_STATUS_2 0x05 > +#define ADXL372_FIFO_ENTRIES_2 0x06 > +#define ADXL372_FIFO_ENTRIES_1 0x07 > +#define ADXL372_X_DATA_H 0x08 > +#define ADXL372_X_DATA_L 0x09 > +#define ADXL372_Y_DATA_H 0x0A > +#define ADXL372_Y_DATA_L 0x0B > +#define ADXL372_Z_DATA_H 0x0C > +#define ADXL372_Z_DATA_L 0x0D > +#define ADXL372_X_MAXPEAK_H 0x15 > +#define ADXL372_X_MAXPEAK_L 0x16 > +#define ADXL372_Y_MAXPEAK_H 0x17 > +#define ADXL372_Y_MAXPEAK_L 0x18 > +#define ADXL372_Z_MAXPEAK_H 0x19 > +#define ADXL372_Z_MAXPEAK_L 0x1A > +#define ADXL372_OFFSET_X 0x20 > +#define ADXL372_OFFSET_Y 0x21 > +#define ADXL372_OFFSET_Z 0x22 > +#define ADXL372_X_THRESH_ACT_H 0x23 > +#define ADXL372_X_THRESH_ACT_L 0x24 > +#define ADXL372_Y_THRESH_ACT_H 0x25 > +#define ADXL372_Y_THRESH_ACT_L 0x26 > +#define ADXL372_Z_THRESH_ACT_H 0x27 > +#define ADXL372_Z_THRESH_ACT_L 0x28 > +#define ADXL372_TIME_ACT 0x29 > +#define ADXL372_X_THRESH_INACT_H 0x2A > +#define ADXL372_X_THRESH_INACT_L 0x2B > +#define ADXL372_Y_THRESH_INACT_H 0x2C > +#define ADXL372_Y_THRESH_INACT_L 0x2D > +#define ADXL372_Z_THR
Re: [PATCH] iio: adc: qcom-spmi-adc5: Add ADC5_AMUX_THM[24]_100K_PU to rev2 channel list
On Fri, 10 Aug 2018 12:47:02 -0700
Matthias Kaehlcke wrote:
> Add ADC5_AMUX_THM2_100K_PU and ADC5_AMUX_THM4_100K_PU to the list of
> rev2 ADC channels.
>
> Signed-off-by: Matthias Kaehlcke
This is fine and applied to the togreg branch of iio.git.
Pushed out as testing to let the autobuilders play with it.
However, I took a quick look and can't immediately see what prevents us
specifying channels in DT that don't have these definitions in the driver.
Should we have a check for that as at least superficially it seems like
a bad idea!
Jonathan
> ---
> drivers/iio/adc/qcom-spmi-adc5.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/iio/adc/qcom-spmi-adc5.c
> b/drivers/iio/adc/qcom-spmi-adc5.c
> index a4299417f3de..1f9298a5c83d 100644
> --- a/drivers/iio/adc/qcom-spmi-adc5.c
> +++ b/drivers/iio/adc/qcom-spmi-adc5.c
> @@ -491,8 +491,12 @@ static const struct adc5_channels
> adc5_chans_rev2[ADC5_MAX_CHANNEL] = {
> SCALE_HW_CALIB_PMIC_THERM)
> [ADC5_AMUX_THM1_100K_PU] = ADC5_CHAN_TEMP("amux_thm1_100k_pu", 1,
> SCALE_HW_CALIB_THERM_100K_PULLUP)
> + [ADC5_AMUX_THM2_100K_PU] = ADC5_CHAN_TEMP("amux_thm2_100k_pu", 1,
> + SCALE_HW_CALIB_THERM_100K_PULLUP)
> [ADC5_AMUX_THM3_100K_PU] = ADC5_CHAN_TEMP("amux_thm3_100k_pu", 1,
> SCALE_HW_CALIB_THERM_100K_PULLUP)
> + [ADC5_AMUX_THM4_100K_PU] = ADC5_CHAN_TEMP("amux_thm4_100k_pu", 1,
> + SCALE_HW_CALIB_THERM_100K_PULLUP)
> [ADC5_AMUX_THM5_100K_PU] = ADC5_CHAN_TEMP("amux_thm5_100k_pu", 1,
> SCALE_HW_CALIB_THERM_100K_PULLUP)
> [ADC5_XO_THERM_100K_PU] = ADC5_CHAN_TEMP("xo_therm_100k_pu", 1,
Re: [PATCH] iio: adc: max9611: explicitly cast gain_selectors
On Sat, 11 Aug 2018 11:12:19 +0200
Stefan Agner wrote:
> After finding a reasonable gain, the function converts the configured
> gain to a gain configuration option selector enum max9611_csa_gain.
> Make the conversion clearly visible by using an explicit cast. This
> also avoids a warning seen with clang:
> drivers/iio/adc/max9611.c:292:16: warning: implicit conversion from
> enumeration type 'enum max9611_conf_ids' to different enumeration
> type 'enum max9611_csa_gain' [-Wenum-conversion]
> *csa_gain = gain_selectors[i];
> ~ ^
>
> Signed-off-by: Stefan Agner
Hmm. This is a somewhat odd code construct, but it kind of makes sense
as it enforces that we are using a subset of one enum for the other.
Not terribly pretty but not awful I guess.
This patch is fine given that.
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/adc/max9611.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iio/adc/max9611.c b/drivers/iio/adc/max9611.c
> index 0538ff8c4ac1..643a4e66eb80 100644
> --- a/drivers/iio/adc/max9611.c
> +++ b/drivers/iio/adc/max9611.c
> @@ -289,7 +289,7 @@ static int max9611_read_csa_voltage(struct max9611_dev
> *max9611,
> return ret;
>
> if (*adc_raw > 0) {
> - *csa_gain = gain_selectors[i];
> + *csa_gain = (enum max9611_csa_gain)gain_selectors[i];
> return 0;
> }
> }
Re: [PATCH v2] i2c: Remove '-Wno-deprecated-declarations' compiler warning
On Sun, Aug 19, 2018 at 6:51 AM Sedat Dilek wrote:
>
> This can be dropped with commit 771c035372a036f83353eef46dbb829780330234
> ("deprecate the '__deprecated' attribute warnings entirely and for good")
> now in upstream.
Could we please just remove the __deprecated use in i2c entirely?
As fat as I can tell, it's used for one thing, which is the
"attach_adapter" function pointer member in 'struct i2c_driver'.
And I think there is _one_ remaining driver using it, namely the
powermac "therm_windtunnel" driver.
Could somebody who knows the i2c probing just a bit convert that *one*
remaining driver, then remove the "attach_adapter" entirely, and also
remove this thing?
Alternatively, perhaps the driver should be removed? The last actual
powermac change to that driver seems to be from August 2009.
Everything since has been just cleanup unrelated to that driver code
itself (ie spelling fixes, automated coccinelle scripts etc).
Added a few people either because they're still officially maintainers
of that file, or because they touched the code ten years ago.
Linus
Re: [RESEND PATCH] iio: dac: mcp4725: avoid using CONFIG_PM_SLEEP
On Sat, 11 Aug 2018 10:47:25 +0200
Marcus Folkesson wrote:
> This is already handled by SIMPLE_DEV_PM_OPS().
>
> Signed-off-by: Marcus Folkesson
Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to play with it.
> ---
> Somehow git-send-email messed up (?!) the format for (at least) gmail, so
> resend it.
> Mutt still read the mail correct though.
You have my sympathies ;) oh for all email servers and clients being well
behaved.
Thanks,
Jonathan
>
> drivers/iio/dac/mcp4725.c | 12 +++-
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/iio/dac/mcp4725.c b/drivers/iio/dac/mcp4725.c
> index 8b5aad4c32d9..6d71fd905e29 100644
> --- a/drivers/iio/dac/mcp4725.c
> +++ b/drivers/iio/dac/mcp4725.c
> @@ -45,7 +45,7 @@ struct mcp4725_data {
> struct regulator *vref_reg;
> };
>
> -static int mcp4725_suspend(struct device *dev)
> +static int __maybe_unused mcp4725_suspend(struct device *dev)
> {
> struct mcp4725_data *data = iio_priv(i2c_get_clientdata(
> to_i2c_client(dev)));
> @@ -58,7 +58,7 @@ static int mcp4725_suspend(struct device *dev)
> return i2c_master_send(data->client, outbuf, 2);
> }
>
> -static int mcp4725_resume(struct device *dev)
> +static int __maybe_unused mcp4725_resume(struct device *dev)
> {
> struct mcp4725_data *data = iio_priv(i2c_get_clientdata(
> to_i2c_client(dev)));
> @@ -71,13 +71,7 @@ static int mcp4725_resume(struct device *dev)
>
> return i2c_master_send(data->client, outbuf, 2);
> }
> -
> -#ifdef CONFIG_PM_SLEEP
> static SIMPLE_DEV_PM_OPS(mcp4725_pm_ops, mcp4725_suspend, mcp4725_resume);
> -#define MCP4725_PM_OPS (&mcp4725_pm_ops)
> -#else
> -#define MCP4725_PM_OPS NULL
> -#endif
>
> static ssize_t mcp4725_store_eeprom(struct device *dev,
> struct device_attribute *attr, const char *buf, size_t len)
> @@ -547,7 +541,7 @@ static struct i2c_driver mcp4725_driver = {
> .driver = {
> .name = MCP4725_DRV_NAME,
> .of_match_table = of_match_ptr(mcp4725_of_match),
> - .pm = MCP4725_PM_OPS,
> + .pm = &mcp4725_pm_ops,
> },
> .probe = mcp4725_probe,
> .remove = mcp4725_remove,
Re: [RESEND PATCH] iio: dac: max5821: avoid using CONFIG_PM_SLEEP
On Sat, 11 Aug 2018 10:47:18 +0200
Marcus Folkesson wrote:
> This is already handled by SIMPLE_DEV_PM_OPS().
>
> Signed-off-by: Marcus Folkesson
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> Somehow git-send-email messed up (?!) the format for (at least) gmail, so
> resend it.
> Mutt still read the mail correct though.
>
> drivers/iio/dac/max5821.c | 11 +++
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/iio/dac/max5821.c b/drivers/iio/dac/max5821.c
> index d0ecc1fdd8fc..f0cf6903dcd2 100644
> --- a/drivers/iio/dac/max5821.c
> +++ b/drivers/iio/dac/max5821.c
> @@ -270,8 +270,7 @@ static int max5821_write_raw(struct iio_dev *indio_dev,
> }
> }
>
> -#ifdef CONFIG_PM_SLEEP
> -static int max5821_suspend(struct device *dev)
> +static int __maybe_unused max5821_suspend(struct device *dev)
> {
> u8 outbuf[2] = { MAX5821_EXTENDED_COMMAND_MODE,
>MAX5821_EXTENDED_DAC_A |
> @@ -281,7 +280,7 @@ static int max5821_suspend(struct device *dev)
> return i2c_master_send(to_i2c_client(dev), outbuf, 2);
> }
>
> -static int max5821_resume(struct device *dev)
> +static int __maybe_unused max5821_resume(struct device *dev)
> {
> u8 outbuf[2] = { MAX5821_EXTENDED_COMMAND_MODE,
>MAX5821_EXTENDED_DAC_A |
> @@ -292,10 +291,6 @@ static int max5821_resume(struct device *dev)
> }
>
> static SIMPLE_DEV_PM_OPS(max5821_pm_ops, max5821_suspend, max5821_resume);
> -#define MAX5821_PM_OPS (&max5821_pm_ops)
> -#else
> -#define MAX5821_PM_OPS NULL
> -#endif /* CONFIG_PM_SLEEP */
>
> static const struct iio_info max5821_info = {
> .read_raw = max5821_read_raw,
> @@ -392,7 +387,7 @@ static struct i2c_driver max5821_driver = {
> .driver = {
> .name = "max5821",
> .of_match_table = max5821_of_match,
> - .pm = MAX5821_PM_OPS,
> + .pm = &max5821_pm_ops,
> },
> .probe = max5821_probe,
> .remove = max5821_remove,
Re: [RESEND PATCH] iio: dac: max517: avoid using CONFIG_PM_SLEEP
On Sat, 11 Aug 2018 10:47:09 +0200
Marcus Folkesson wrote:
> This is already handled by SIMPLE_DEV_PM_OPS().
>
> Signed-off-by: Marcus Folkesson
Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to play with it.
thanks,
Jonathan
> ---
> Somehow git-send-email messed up (?!) the format for (at least) gmail, so
> resend it.
> Mutt still read the mail correct though.
>
> drivers/iio/dac/max517.c | 11 +++
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/iio/dac/max517.c b/drivers/iio/dac/max517.c
> index 1d853247a205..451d10e323cf 100644
> --- a/drivers/iio/dac/max517.c
> +++ b/drivers/iio/dac/max517.c
> @@ -113,15 +113,14 @@ static int max517_write_raw(struct iio_dev *indio_dev,
> return ret;
> }
>
> -#ifdef CONFIG_PM_SLEEP
> -static int max517_suspend(struct device *dev)
> +static int __maybe_unused max517_suspend(struct device *dev)
> {
> u8 outbuf = COMMAND_PD;
>
> return i2c_master_send(to_i2c_client(dev), &outbuf, 1);
> }
>
> -static int max517_resume(struct device *dev)
> +static int __maybe_unused max517_resume(struct device *dev)
> {
> u8 outbuf = 0;
>
> @@ -129,10 +128,6 @@ static int max517_resume(struct device *dev)
> }
>
> static SIMPLE_DEV_PM_OPS(max517_pm_ops, max517_suspend, max517_resume);
> -#define MAX517_PM_OPS (&max517_pm_ops)
> -#else
> -#define MAX517_PM_OPS NULL
> -#endif
>
> static const struct iio_info max517_info = {
> .read_raw = max517_read_raw,
> @@ -229,7 +224,7 @@ MODULE_DEVICE_TABLE(i2c, max517_id);
> static struct i2c_driver max517_driver = {
> .driver = {
> .name = MAX517_DRV_NAME,
> - .pm = MAX517_PM_OPS,
> + .pm = &max517_pm_ops,
> },
> .probe = max517_probe,
> .remove = max517_remove,
Re: [PATCH 1/3] iio: dac: add support for ltc166x
On Sat, 11 Aug 2018 22:02:24 +0200
Marcus Folkesson wrote:
> LTC1665/LTC1660 is a 8/10-bit Digital-to-Analog Converter
> (DAC) with eight individual channels.
>
> Signed-off-by: Marcus Folkesson
So first rule we try to stick to that this breaks is never use wild cards
in drivers. You probably wouldn't believe how often this has gone wrong with
a manufacturer deciding to use other values that wild card covers...
Please pick a part and name everything after that. Either one is fine.
A few really minor things inline. Nice little driver.
Thanks,
Jonathan
> ---
> drivers/iio/dac/Kconfig | 10 ++
> drivers/iio/dac/Makefile | 1 +
> drivers/iio/dac/ltc166x.c | 244
> ++
> 3 files changed, 255 insertions(+)
> create mode 100644 drivers/iio/dac/ltc166x.c
>
> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
> index 76db0768e454..04cfa6bb9dc1 100644
> --- a/drivers/iio/dac/Kconfig
> +++ b/drivers/iio/dac/Kconfig
> @@ -120,6 +120,16 @@ config AD5624R_SPI
> Say yes here to build support for Analog Devices AD5624R, AD5644R and
> AD5664R converters (DAC). This driver uses the common SPI interface.
>
> +config LTC166X
> + tristate "Linear Technology LTC1660/LTC1665 DAC SPI driver"
> + depends on SPI
> + help
> + Say yes here to build support for Linear Technology
> + LTC1660 and LTC1665 Digital to Analog Converters.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called ltc166x.
> +
> config LTC2632
> tristate "Linear Technology LTC2632-12/10/8 DAC spi driver"
> depends on SPI
> diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
> index 81e710ed7491..380749c87c26 100644
> --- a/drivers/iio/dac/Makefile
> +++ b/drivers/iio/dac/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_CIO_DAC) += cio-dac.o
> obj-$(CONFIG_DPOT_DAC) += dpot-dac.o
> obj-$(CONFIG_DS4424) += ds4424.o
> obj-$(CONFIG_LPC18XX_DAC) += lpc18xx_dac.o
> +obj-$(CONFIG_LTC166X) += ltc166x.o
> obj-$(CONFIG_LTC2632) += ltc2632.o
> obj-$(CONFIG_M62332) += m62332.o
> obj-$(CONFIG_MAX517) += max517.o
> diff --git a/drivers/iio/dac/ltc166x.c b/drivers/iio/dac/ltc166x.c
> new file mode 100644
> index ..0031f2b50f14
> --- /dev/null
> +++ b/drivers/iio/dac/ltc166x.c
> @@ -0,0 +1,244 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Driver for Linear Technology LTC1665/LTC1660, 8 channels DAC
> + *
> + * Copyright (C) 2018 Marcus Folkesson
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define LTC166X_REG_WAKE 0x0
> +#define LTC166X_REG_DAC_A0x1
> +#define LTC166X_REG_DAC_B0x2
> +#define LTC166X_REG_DAC_C0x3
> +#define LTC166X_REG_DAC_D0x4
> +#define LTC166X_REG_DAC_E0x5
> +#define LTC166X_REG_DAC_F0x6
> +#define LTC166X_REG_DAC_G0x7
> +#define LTC166X_REG_DAC_H0x8
> +#define LTC166X_REG_SLEEP0xe
> +
> +#define LTC166X_NUM_CHANNELS 8
> +
> +static const struct regmap_config ltc166x_regmap_config = {
> + .reg_bits = 4,
> + .val_bits = 12,
> +};
> +
> +enum ltc166x_supported_device_ids {
> + ID_LTC1660,
> + ID_LTC1665,
> +};
> +
> +struct ltc166x_priv {
> + struct spi_device *spi;
> + struct regmap *regmap;
> + struct regulator *vref_reg;
> + unsigned int value[LTC166X_NUM_CHANNELS];
> + unsigned int vref_mv;
> +};
> +
> +static int ltc166x_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val,
> + int *val2,
> + long mask)
> +{
> + struct ltc166x_priv *priv = iio_priv(indio_dev);
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + *val = priv->value[chan->channel];
> + return IIO_VAL_INT;
> + case IIO_CHAN_INFO_SCALE:
> + *val = priv->vref_mv;
> + *val2 = chan->scan_type.realbits;
> + return IIO_VAL_FRACTIONAL_LOG2;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int ltc166x_write_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int val,
> + int val2,
> + long mask)
> +{
> + struct ltc166x_priv *priv = iio_priv(indio_dev);
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + if (val2 != 0)
> + return -EINVAL;
> + if (val > GENMASK(chan->scan_type.realbits-1, 0))
> + return -EINVAL;
nothing makes val positive.. Also spaces around the '-'.
> + priv->value[chan->channel] = val;
> + val <<= chan->scan_type.shift;
> + return regmap_write(priv->regmap, chan->channel, val);
Given that this could fail, usual convention is set the cached value
priv->value[] only after we know the write succeeded.
> + default:
> + return -EINVAL;
> +
[PATCH] Staging: fsl-dpaa2: ethsw: dpsw: Use correct SPDX-License-Identifier comment
Use correct comment for SPDX-License-Identifier Signed-off-by: Jannis Nawroth --- drivers/staging/fsl-dpaa2/ethsw/dpsw.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/fsl-dpaa2/ethsw/dpsw.h b/drivers/staging/fsl-dpaa2/ethsw/dpsw.h index db43fa3782b8..95feb7ffd575 100644 --- a/drivers/staging/fsl-dpaa2/ethsw/dpsw.h +++ b/drivers/staging/fsl-dpaa2/ethsw/dpsw.h @@ -1,5 +1,4 @@ -// SPDX-License-Identifier: GPL-2.0 -/* +/* SPDX-License-Identifier: GPL-2.0 * Copyright 2014-2016 Freescale Semiconductor Inc. * Copyright 2017-2018 NXP * -- 2.18.0
Re: [PATCH] iio: chemical: bme680: Add check for val2 in the write_raw function
On Sat, 11 Aug 2018 15:56:36 +0530
Himanshu Jha wrote:
> val2 is responsible for the floating part of the number to be
> written to the device. We don't need the floating part
> while writing the oversampling ratio for BME680 since the
> available oversampling ratios are pure natural numbers.
>
> So, add a sanity check to make sure val2 is 0.
>
> Signed-off-by: Himanshu Jha
As discussed in David's patch series v3, I think this is still relevant
but now needs an update to cover the new code.
Thanks,
Jonathan
> ---
> drivers/iio/chemical/bme680_core.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/iio/chemical/bme680_core.c
> b/drivers/iio/chemical/bme680_core.c
> index 7d9bb62baa3f..9d5a05e054d1 100644
> --- a/drivers/iio/chemical/bme680_core.c
> +++ b/drivers/iio/chemical/bme680_core.c
> @@ -852,6 +852,9 @@ static int bme680_write_raw(struct iio_dev *indio_dev,
> {
> struct bme680_data *data = iio_priv(indio_dev);
>
> + if (val2 != 0)
> + return -EINVAL;
> +
> switch (mask) {
> case IIO_CHAN_INFO_OVERSAMPLING_RATIO:
> switch (chan->type) {
Re: [PATCH] iio: health: max30102: Mark expected switch fall-throughs
On Wed, 15 Aug 2018 11:23:49 -0500
"Gustavo A. R. Silva" wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Notice that in this particular case, I placed the "fall through"
> annotation at the bottom of the case, which is what GCC is expecting
> to find.
>
> Addresses-Coverity-ID: 1458342 ("Missing break in switch")
> Addresses-Coverity-ID: 1458345 ("Missing break in switch")
> Signed-off-by: Gustavo A. R. Silva
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/health/max30102.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iio/health/max30102.c b/drivers/iio/health/max30102.c
> index 15ccadc..3e29562 100644
> --- a/drivers/iio/health/max30102.c
> +++ b/drivers/iio/health/max30102.c
> @@ -282,9 +282,11 @@ static int max30102_read_measurement(struct
> max30102_data *data,
> switch (measurements) {
> case 3:
> MAX30102_COPY_DATA(2);
> - case 2: /* fall-through */
> + /* fall through */
> + case 2:
> MAX30102_COPY_DATA(1);
> - case 1: /* fall-through */
> + /* fall through */
> + case 1:
> MAX30102_COPY_DATA(0);
> break;
> default:
Re: [PATCH] iio: accel: cros_ec_accel_legacy: Mark expected switch fall-throughs
On Sat, 18 Aug 2018 17:34:40 +0200
Marcus Folkesson wrote:
> Hi Gutavo,
>
> Sorry for the delay.
>
> On Wed, Aug 15, 2018 at 12:50:10PM -0500, Gustavo A. R. Silva wrote:
> > Hi Marcus,
> >
> > On 8/15/18 12:27 PM, Marcus Folkesson wrote:
> > > Hi,
> > >
> > > On Wed, Aug 15, 2018 at 11:38:52AM -0500, Gustavo A. R. Silva wrote:
> > >> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> > >> where we are expecting to fall through.
> > >>
> > >> Addresses-Coverity-ID: 1462408 ("Missing break in switch")
> > >> Signed-off-by: Gustavo A. R. Silva
> > >> ---
> > >> drivers/iio/accel/cros_ec_accel_legacy.c | 2 ++
> > >> 1 file changed, 2 insertions(+)
> > >>
> > >> diff --git a/drivers/iio/accel/cros_ec_accel_legacy.c
> > >> b/drivers/iio/accel/cros_ec_accel_legacy.c
> > >> index 063e89e..d609654 100644
> > >> --- a/drivers/iio/accel/cros_ec_accel_legacy.c
> > >> +++ b/drivers/iio/accel/cros_ec_accel_legacy.c
> > >> @@ -385,8 +385,10 @@ static int cros_ec_accel_legacy_probe(struct
> > >> platform_device *pdev)
> > >> switch (i) {
> > >> case X:
> > >> ec_accel_channels[X].scan_index = Y;
> > >> +/* fall through */
> > >> case Y:
> > >> ec_accel_channels[Y].scan_index = X;
> > >> +/* fall through */
> > >> case Z:
> > >> ec_accel_channels[Z].scan_index = Z;
> > >> }
> > >
> > > Hum, I'm not sure we are supposed to fall through here, even if it does
> > > not hurt to do so.
> >
> > Yeah. You're right. It doesn't hurt but is actually redundant. I think
> > the original intention was to break instead of falling through.
> >
> > > I even think we can remove the switch and put that outside the for-loop,
> > > e.g:
> > >
> > > ec_accel_channels[X].scan_index = Y;
> > > ec_accel_channels[Y].scan_index = X;
> > > ec_accel_channels[Z].scan_index = Z;
> > >
> > > for (i = X ; i < MAX_AXIS; i++) {
> > > if (state->sensor_num == MOTIONSENSE_LOC_LID && i != Y)
> > > state->sign[i] = -1;
> > > else
> > > state->sign[i] = 1;
> > > }
> > >
> >
> > I like this, but the code clearly depends on MAX_AXIS. So, if MAX_AXIS
> > will be always 3, then the change you suggest is just fine. Otherwise,
> > it seems that adding a break to each case is the right way to go.
> >
> > What do you think?
>
> Well, I guess it is a matter of taste after all.
> I don't think the number of axis will change, but just put the break in
> place is good enough.
>
> Anyway, If we choose to not use the switch, I think we should remove the
> for-loop as well, eg:
>
> ec_accel_channels[X].scan_index = Y;
> ec_accel_channels[Y].scan_index = X;
> ec_accel_channels[Z].scan_index = Z;
>
> if (state->sensor_num == MOTIONSENSE_LOC_LID) {
> state->sign[X] = -1;
> state->sign[Y] = 1;
> state->sign[Z] = -1;
> } else {
> state->sign[X] = 1;
> state->sign[Y] = 1;
> state->sign[Z] = 1;
> }
>
> But someone else may like to give their point of view on this change.
Looks like the right tidy up to me. The original code was 'novel' :)
Jonathan
>
> >
> > Thanks for the feedback.
> > --
> > Gustavo
>
> Best regards
> Marcus Folkesson
Re: [PATCH] iio: pressure: ms5611: remove deprecated compatible strings
On Thu, 16 Aug 2018 20:49:15 +0200
Tomasz Duszynski wrote:
> Compatible strings tend to follow manufacturer,model format.
> In case one wants to do a matching with manufacturer stripped
> off he can still do so since SPI/I2C core will try id_table
> based matching anyway.
>
> Signed-off-by: Tomasz Duszynski
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/pressure/ms5611_i2c.c | 2 --
> drivers/iio/pressure/ms5611_spi.c | 2 --
> 2 files changed, 4 deletions(-)
>
> diff --git a/drivers/iio/pressure/ms5611_i2c.c
> b/drivers/iio/pressure/ms5611_i2c.c
> index 55fb5fc0b6ea..0469c8ae1134 100644
> --- a/drivers/iio/pressure/ms5611_i2c.c
> +++ b/drivers/iio/pressure/ms5611_i2c.c
> @@ -117,9 +117,7 @@ static int ms5611_i2c_remove(struct i2c_client *client)
> #if defined(CONFIG_OF)
> static const struct of_device_id ms5611_i2c_matches[] = {
> { .compatible = "meas,ms5611" },
> - { .compatible = "ms5611" },
> { .compatible = "meas,ms5607" },
> - { .compatible = "ms5607" },
> { }
> };
> MODULE_DEVICE_TABLE(of, ms5611_i2c_matches);
> diff --git a/drivers/iio/pressure/ms5611_spi.c
> b/drivers/iio/pressure/ms5611_spi.c
> index 932e05001e1a..cd11d022208e 100644
> --- a/drivers/iio/pressure/ms5611_spi.c
> +++ b/drivers/iio/pressure/ms5611_spi.c
> @@ -119,9 +119,7 @@ static int ms5611_spi_remove(struct spi_device *spi)
> #if defined(CONFIG_OF)
> static const struct of_device_id ms5611_spi_matches[] = {
> { .compatible = "meas,ms5611" },
> - { .compatible = "ms5611" },
> { .compatible = "meas,ms5607" },
> - { .compatible = "ms5607" },
> { }
> };
> MODULE_DEVICE_TABLE(of, ms5611_spi_matches);
[PATCH v4 16/16] tools/cpupower: enable Hygon support to cpupower tool
Tool cpupower is useful to get CPU frequency information and monitor
power stats on Hygon platforms. So enable platform support to cpupower
for Hygon Dhyana Family 18h processors by checking vendor ID & family
and vendor string along with AMD.
Signed-off-by: Pu Wen
---
tools/power/cpupower/utils/cpufreq-info.c | 6 --
tools/power/cpupower/utils/helpers/amd.c| 6 --
tools/power/cpupower/utils/helpers/cpuid.c | 8 +---
tools/power/cpupower/utils/helpers/helpers.h| 2 +-
tools/power/cpupower/utils/helpers/misc.c | 3 ++-
tools/power/cpupower/utils/idle_monitor/mperf_monitor.c | 3 ++-
6 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/tools/power/cpupower/utils/cpufreq-info.c
b/tools/power/cpupower/utils/cpufreq-info.c
index df43cd4..56e54ea 100644
--- a/tools/power/cpupower/utils/cpufreq-info.c
+++ b/tools/power/cpupower/utils/cpufreq-info.c
@@ -170,6 +170,7 @@ static int get_boost_mode(unsigned int cpu)
unsigned long pstates[MAX_HW_PSTATES] = {0,};
if (cpupower_cpu_info.vendor != X86_VENDOR_AMD &&
+ cpupower_cpu_info.vendor != X86_VENDOR_HYGON &&
cpupower_cpu_info.vendor != X86_VENDOR_INTEL)
return 0;
@@ -190,8 +191,9 @@ static int get_boost_mode(unsigned int cpu)
printf(_("Supported: %s\n"), support ? _("yes") : _("no"));
printf(_("Active: %s\n"), active ? _("yes") : _("no"));
- if (cpupower_cpu_info.vendor == X86_VENDOR_AMD &&
- cpupower_cpu_info.family >= 0x10) {
+ if ((cpupower_cpu_info.vendor == X86_VENDOR_AMD &&
+cpupower_cpu_info.family >= 0x10) ||
+cpupower_cpu_info.vendor == X86_VENDOR_HYGON) {
ret = decode_pstates(cpu, cpupower_cpu_info.family, b_states,
pstates, &pstate_no);
if (ret)
diff --git a/tools/power/cpupower/utils/helpers/amd.c
b/tools/power/cpupower/utils/helpers/amd.c
index bb41cdd..d9327ee 100644
--- a/tools/power/cpupower/utils/helpers/amd.c
+++ b/tools/power/cpupower/utils/helpers/amd.c
@@ -45,7 +45,8 @@ static int get_did(int family, union msr_pstate pstate)
if (family == 0x12)
t = pstate.val & 0xf;
- else if (family == 0x17)
+ else if (family == 0x17 ||
+ (cpupower_cpu_info.vendor == X86_VENDOR_HYGON && family ==
0x18))
t = pstate.fam17h_bits.did;
else
t = pstate.bits.did;
@@ -59,7 +60,8 @@ static int get_cof(int family, union msr_pstate pstate)
int fid, did, cof;
did = get_did(family, pstate);
- if (family == 0x17) {
+ if (family == 0x17 ||
+ (cpupower_cpu_info.vendor == X86_VENDOR_HYGON && family == 0x18)) {
fid = pstate.fam17h_bits.fid;
cof = 200 * fid / did;
} else {
diff --git a/tools/power/cpupower/utils/helpers/cpuid.c
b/tools/power/cpupower/utils/helpers/cpuid.c
index 732b0b4..5cc39d4 100644
--- a/tools/power/cpupower/utils/helpers/cpuid.c
+++ b/tools/power/cpupower/utils/helpers/cpuid.c
@@ -8,7 +8,7 @@
#include "helpers/helpers.h"
static const char *cpu_vendor_table[X86_VENDOR_MAX] = {
- "Unknown", "GenuineIntel", "AuthenticAMD",
+ "Unknown", "GenuineIntel", "AuthenticAMD", "HygonGenuine",
};
#if defined(__i386__) || defined(__x86_64__)
@@ -109,6 +109,7 @@ int get_cpu_info(struct cpupower_cpu_info *cpu_info)
fclose(fp);
/* Get some useful CPU capabilities from cpuid */
if (cpu_info->vendor != X86_VENDOR_AMD &&
+ cpu_info->vendor != X86_VENDOR_HYGON &&
cpu_info->vendor != X86_VENDOR_INTEL)
return ret;
@@ -124,8 +125,9 @@ int get_cpu_info(struct cpupower_cpu_info *cpu_info)
if (cpuid_level >= 6 && (cpuid_ecx(6) & 0x1))
cpu_info->caps |= CPUPOWER_CAP_APERF;
- /* AMD Boost state enable/disable register */
- if (cpu_info->vendor == X86_VENDOR_AMD) {
+ /* AMD or Hygon Boost state enable/disable register */
+ if (cpu_info->vendor == X86_VENDOR_AMD ||
+ cpu_info->vendor == X86_VENDOR_HYGON) {
if (ext_cpuid_level >= 0x8007 &&
(cpuid_edx(0x8007) & (1 << 9)))
cpu_info->caps |= CPUPOWER_CAP_AMD_CBP;
diff --git a/tools/power/cpupower/utils/helpers/helpers.h
b/tools/power/cpupower/utils/helpers/helpers.h
index 41da392..9021396 100644
--- a/tools/power/cpupower/utils/helpers/helpers.h
+++ b/tools/power/cpupower/utils/helpers/helpers.h
@@ -61,7 +61,7 @@ extern int be_verbose;
/* cpuid and cpuinfo helpers **/
enum cpupower_cpu_vendor {X86_VENDOR_UNKNOWN = 0, X86_VENDOR_INTEL,
- X86_VENDOR_AMD, X86_VENDOR_MAX};
+ X86_VENDOR_AMD, X86_VENDOR_HYGON, X86_VENDOR_MAX};
#define CPUPOWER_CAP_INV_TSC 0x0001
#define CPUPOWER_CAP_APERF
[PATCH v4 14/16] driver/cpufreq: enable Hygon support to cpufreq driver
Enable ACPI cpufreq driver support for Hygon by adding family ID check
along with AMD.
As Hygon platforms have SMBus device(PCI device ID 0x790b), enable Hygon
support to function amd_freq_sensitivity_init().
Acked-by: Rafael J. Wysocki
Signed-off-by: Pu Wen
---
drivers/cpufreq/acpi-cpufreq.c | 5 +
drivers/cpufreq/amd_freq_sensitivity.c | 9 +++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index b61f4ec..d62fd37 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -61,6 +61,7 @@ enum {
#define INTEL_MSR_RANGE(0x)
#define AMD_MSR_RANGE (0x7)
+#define HYGON_MSR_RANGE(0x7)
#define MSR_K7_HWCR_CPB_DIS(1ULL << 25)
@@ -95,6 +96,7 @@ static bool boost_state(unsigned int cpu)
rdmsr_on_cpu(cpu, MSR_IA32_MISC_ENABLE, &lo, &hi);
msr = lo | ((u64)hi << 32);
return !(msr & MSR_IA32_MISC_ENABLE_TURBO_DISABLE);
+ case X86_VENDOR_HYGON:
case X86_VENDOR_AMD:
rdmsr_on_cpu(cpu, MSR_K7_HWCR, &lo, &hi);
msr = lo | ((u64)hi << 32);
@@ -113,6 +115,7 @@ static int boost_set_msr(bool enable)
msr_addr = MSR_IA32_MISC_ENABLE;
msr_mask = MSR_IA32_MISC_ENABLE_TURBO_DISABLE;
break;
+ case X86_VENDOR_HYGON:
case X86_VENDOR_AMD:
msr_addr = MSR_K7_HWCR;
msr_mask = MSR_K7_HWCR_CPB_DIS;
@@ -225,6 +228,8 @@ static unsigned extract_msr(struct cpufreq_policy *policy,
u32 msr)
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
msr &= AMD_MSR_RANGE;
+ else if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
+ msr &= HYGON_MSR_RANGE;
else
msr &= INTEL_MSR_RANGE;
diff --git a/drivers/cpufreq/amd_freq_sensitivity.c
b/drivers/cpufreq/amd_freq_sensitivity.c
index be926d9..4ac7c3c 100644
--- a/drivers/cpufreq/amd_freq_sensitivity.c
+++ b/drivers/cpufreq/amd_freq_sensitivity.c
@@ -111,11 +111,16 @@ static int __init amd_freq_sensitivity_init(void)
{
u64 val;
struct pci_dev *pcidev;
+ unsigned int pci_vendor;
- if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+ pci_vendor = PCI_VENDOR_ID_AMD;
+ else if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
+ pci_vendor = PCI_VENDOR_ID_HYGON;
+ else
return -ENODEV;
- pcidev = pci_get_device(PCI_VENDOR_ID_AMD,
+ pcidev = pci_get_device(pci_vendor,
PCI_DEVICE_ID_AMD_KERNCZ_SMBUS, NULL);
if (!pcidev) {
--
2.7.4
[PATCH v4 15/16] driver/edac: enable Hygon support to AMD64 EDAC driver
To make AMD64 EDAC and MCE drivers working on Hygon platforms, add
vendor checking for Hygon by using the code path of AMD 0x17. Add a
vendor field to struct amd64_pvt and initialize it in per_family_init
for vendor checking.
Also Hygon PCI Device ID DF_F0/DF_F6(0x1460/0x1466) of Host bridges
is needed for edac driver.
Signed-off-by: Pu Wen
---
drivers/edac/amd64_edac.c | 52 ++-
drivers/edac/amd64_edac.h | 5 +
drivers/edac/mce_amd.c| 15 +-
3 files changed, 70 insertions(+), 2 deletions(-)
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 18aeabb..3cefb25 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -211,7 +211,8 @@ static int __set_scrub_rate(struct amd64_pvt *pvt, u32
new_bw, u32 min_rate)
scrubval = scrubrates[i].scrubval;
- if (pvt->fam == 0x17) {
+ if (pvt->fam == 0x17 ||
+ (pvt->vendor == X86_VENDOR_HYGON && pvt->fam == 0x18)) {
__f17h_set_scrubval(pvt, scrubval);
} else if (pvt->fam == 0x15 && pvt->model == 0x60) {
f15h_select_dct(pvt, 0);
@@ -274,6 +275,21 @@ static int get_scrub_rate(struct mem_ctl_info *mci)
}
break;
+ case 0x18:
+ if (pvt->vendor == X86_VENDOR_HYGON) {
+ amd64_read_pci_cfg(pvt->F6, F17H_SCR_BASE_ADDR,
&scrubval);
+ if (scrubval & BIT(0)) {
+ amd64_read_pci_cfg(pvt->F6,
F17H_SCR_LIMIT_ADDR, &scrubval);
+ scrubval &= 0xF;
+ scrubval += 0x5;
+ } else {
+ scrubval = 0;
+ }
+ break;
+ }
+
+ /* fall through */
+
default:
amd64_read_pci_cfg(pvt->F3, SCRCTRL, &scrubval);
break;
@@ -1052,6 +1068,19 @@ static void determine_memory_type(struct amd64_pvt *pvt)
pvt->dram_type = MEM_DDR4;
return;
+ case 0x18:
+ if (pvt->vendor == X86_VENDOR_HYGON) {
+ if ((pvt->umc[0].dimm_cfg | pvt->umc[1].dimm_cfg) &
BIT(5))
+ pvt->dram_type = MEM_LRDDR4;
+ else if ((pvt->umc[0].dimm_cfg | pvt->umc[1].dimm_cfg)
& BIT(4))
+ pvt->dram_type = MEM_RDDR4;
+ else
+ pvt->dram_type = MEM_DDR4;
+ return;
+ }
+
+ /* fall through */
+
default:
WARN(1, KERN_ERR "%s: Family??? 0x%x\n", __func__, pvt->fam);
pvt->dram_type = MEM_EMPTY;
@@ -2200,6 +2229,16 @@ static struct amd64_family_type family_types[] = {
.dbam_to_cs = f17_base_addr_to_cs_size,
}
},
+ [HYGON_F18_CPUS] = {
+ /* Hygon F18h uses the same AMD F17h support */
+ .ctl_name = "Hygon_F18h",
+ .f0_id = PCI_DEVICE_ID_HYGON_18H_DF_F0,
+ .f6_id = PCI_DEVICE_ID_HYGON_18H_DF_F6,
+ .ops = {
+ .early_channel_count= f17_early_channel_count,
+ .dbam_to_cs = f17_base_addr_to_cs_size,
+ }
+ },
};
/*
@@ -3149,6 +3188,7 @@ static struct amd64_family_type *per_family_init(struct
amd64_pvt *pvt)
pvt->ext_model = boot_cpu_data.x86_model >> 4;
pvt->stepping = boot_cpu_data.x86_stepping;
pvt->model = boot_cpu_data.x86_model;
+ pvt->vendor = boot_cpu_data.x86_vendor;
pvt->fam= boot_cpu_data.x86;
switch (pvt->fam) {
@@ -3192,6 +3232,15 @@ static struct amd64_family_type *per_family_init(struct
amd64_pvt *pvt)
pvt->ops= &family_types[F17_CPUS].ops;
break;
+ case 0x18:
+ if (pvt->vendor == X86_VENDOR_HYGON) {
+ fam_type= &family_types[HYGON_F18_CPUS];
+ pvt->ops= &family_types[HYGON_F18_CPUS].ops;
+ break;
+ }
+
+ /* fall through */
+
default:
amd64_err("Unsupported family!\n");
return NULL;
@@ -3428,6 +3477,7 @@ static const struct x86_cpu_id amd64_cpuids[] = {
{ X86_VENDOR_AMD, 0x15, X86_MODEL_ANY, X86_FEATURE_ANY, 0 },
{ X86_VENDOR_AMD, 0x16, X86_MODEL_ANY, X86_FEATURE_ANY, 0 },
{ X86_VENDOR_AMD, 0x17, X86_MODEL_ANY, X86_FEATURE_ANY, 0 },
+ { X86_VENDOR_HYGON, 0x18, X86_MODEL_ANY, X86_FEATURE_ANY, 0 },
{ }
};
MODULE_DEVICE_TABLE(x86cpu, amd64_cpuids);
diff --git a/drivers/edac/amd64_edac.h b/drivers/edac/amd64_edac.h
index 1d4b74e..5176b51 100644
--- a/drivers/edac/amd64_edac.h
+++ b/drivers/edac/amd6
[PATCH v4 13/16] driver/acpi: enable Hygon support to ACPI driver
For Dhyana processors have NONSTOP TSC feature, so enable the support
to ACPI driver.
Acked-by: Rafael J. Wysocki
Signed-off-by: Pu Wen
---
drivers/acpi/acpi_pad.c | 1 +
drivers/acpi/processor_idle.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
index 552c1f7..a47676a 100644
--- a/drivers/acpi/acpi_pad.c
+++ b/drivers/acpi/acpi_pad.c
@@ -70,6 +70,7 @@ static void power_saving_mwait_init(void)
#if defined(CONFIG_X86)
switch (boot_cpu_data.x86_vendor) {
+ case X86_VENDOR_HYGON:
case X86_VENDOR_AMD:
case X86_VENDOR_INTEL:
/*
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index abb559c..b2131c4 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -205,6 +205,7 @@ static void lapic_timer_state_broadcast(struct
acpi_processor *pr,
static void tsc_check_state(int state)
{
switch (boot_cpu_data.x86_vendor) {
+ case X86_VENDOR_HYGON:
case X86_VENDOR_AMD:
case X86_VENDOR_INTEL:
case X86_VENDOR_CENTAUR:
--
2.7.4
Re: [RFC PATCH] compiler.h: give up __compiletime_assert_fallback()
On Sat, Aug 18, 2018 at 10:51 PM, Masahiro Yamada
wrote:
> __compiletime_assert_fallback() is supposed to stop building earlier
> by using the negative-array-size method in case the compiler does not
> support "error" attribute, but has never worked like that.
>
> You can try this simple code:
>
> #include
> void foo(void)
> {
> BUILD_BUG_ON(1);
> }
>
> GCC (precisely, GCC 4.3 or later) immediately terminates the build,
> but Clang does not report anything because Clang does not support the
> "error" attribute now. It will eventually fail in the link stage,
> but at least __compiletime_assert_fallback() is not working.
>
> The root cause is commit 1d6a0d19c855 ("bug.h: prevent double evaluation
> of `condition' in BUILD_BUG_ON"). Prior to that commit, BUILD_BUG_ON()
> was checked by the negative-array-size method *and* the link-time trick.
> Since that commit, the negative-array-size is not effective because
> '__cond' is no longer constant. As the comment in
> says, GCC (and Clang as well) only emits the error for obvious cases.
>
> When '__cond' is a variable,
>
> ((void)sizeof(char[1 - 2 * __cond]))
>
> ... is not obvious for the compiler to know the array size is negative.
>
> One way to fix this is to stop the variable assignment, i.e. to pass
> '!(condition)' directly to __compiletime_error_fallback() at the cost
> of the double evaluation of 'condition'. However, all calls of
> BUILD_BUG() would be turned into errors even if they are called from
> dead-code.
>
> This commit does not change the current behavior since it just rips
> off the code that has not been effective for some years.
>
> Signed-off-by: Masahiro Yamada
Yeah, Clang would only complain about the VLA (and not error) and then
later fail at link time. This seems like a reasonable change to me.
Reviewed-by: Kees Cook
-Kees
> ---
>
> include/linux/compiler.h | 17 +
> 1 file changed, 1 insertion(+), 16 deletions(-)
>
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index 42506e4..c062238f4 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -295,29 +295,14 @@ unsigned long read_word_at_a_time(const void *addr)
> #endif
> #ifndef __compiletime_error
> # define __compiletime_error(message)
> -/*
> - * Sparse complains of variable sized arrays due to the temporary variable in
> - * __compiletime_assert. Unfortunately we can't just expand it out to make
> - * sparse see a constant array size without breaking compiletime_assert on
> old
> - * versions of GCC (e.g. 4.2.4), so hide the array from sparse altogether.
> - */
> -# ifndef __CHECKER__
> -# define __compiletime_error_fallback(condition) \
> - do { ((void)sizeof(char[1 - 2 * condition])); } while (0)
> -# endif
> -#endif
> -#ifndef __compiletime_error_fallback
> -# define __compiletime_error_fallback(condition) do { } while (0)
> #endif
>
> #ifdef __OPTIMIZE__
> # define __compiletime_assert(condition, msg, prefix, suffix) \
> do {\
> - bool __cond = !(condition); \
> extern void prefix ## suffix(void) __compiletime_error(msg); \
> - if (__cond) \
> + if (!(condition)) \
> prefix ## suffix(); \
> - __compiletime_error_fallback(__cond); \
> } while (0)
> #else
> # define __compiletime_assert(condition, msg, prefix, suffix) do { } while
> (0)
> --
> 2.7.4
>
--
Kees Cook
Pixel Security
