/tmp/cctnQ1CM.s:35: Error: .err encountered
Hi Dmitry, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 1904148a361a07fb2d7cba1261d1d2c2f33c8d2e commit: 758517202bd2e427664857c9f2aa59da36848aca arm: port KCOV to arm date: 2 weeks ago config: arm-allmodconfig (attached as .config) compiler: arm-linux-gnueabi-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 758517202bd2e427664857c9f2aa59da36848aca # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=arm All errors (new ones prefixed by >>): /tmp/cctnQ1CM.s: Assembler messages: >> /tmp/cctnQ1CM.s:35: Error: .err encountered /tmp/cctnQ1CM.s:36: Error: .err encountered /tmp/cctnQ1CM.s:37: Error: .err encountered --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH] ACPI/PPTT: use ACPI ID whenever ACPI_PPTT_ACPI_PROCESSOR_ID_VALID is set
On Fri, Jun 29, 2018 at 05:17:57PM +0100, Sudeep Holla wrote:
> Currently we use the ACPI processor ID only for the leaf/processor nodes
> as the specification states it must match the value of ACPI processor ID
> field in the processor’s entry in the MADT.
>
> However, if a PPTT structure represents processors group, it match a
> processor container UID in the namespace and ACPI_PPTT_ACPI_PROCESSOR_ID_VALID
> flag describe whether the ACPI processor ID is valid.
>
> Lets use UID whenever ACPI_PPTT_ACPI_PROCESSOR_ID_VALID is set to be
> consistent instead of using table offset as it's currently done for non
> leaf nodes.
>
> Cc: "Rafael J. Wysocki"
> Signed-off-by: Sudeep Holla
> ---
> drivers/acpi/pptt.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> Hi,
>
> There's ongoing discussion on assigning ID based in OS using simple
> counters. It can never be consistent with firmware's view. So if the
> firmware provides valid UID for non-processors node, we must use it.
I agree with this. I've been so focused on the fact that the ACPI offsets
are arbitrary, and thus counters can't be worse, that I nearly forgot how
these IDs are actually defined:
>From Documentation/cputopology.txt
"""
1) /sys/devices/system/cpu/cpuX/topology/physical_package_id:
physical package id of cpuX. Typically corresponds to a physical
socket number, but the actual value is architecture and platform
dependent.
2) /sys/devices/system/cpu/cpuX/topology/core_id:
the CPU core ID of cpuX. Typically it is the hardware platform's
identifier (rather than the kernel's). The actual value is
architecture and platform dependent.
"""
So all my consistency arguments are moot, as no user should expect
consistency from architecture and platform dependent IDs.
A comment on the patch below
>
> Regards,
> Sudeep
>
> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
> index e5ea1974d1e3..d1e26cb599bf 100644
> --- a/drivers/acpi/pptt.c
> +++ b/drivers/acpi/pptt.c
> @@ -481,8 +481,14 @@ static int topology_get_acpi_cpu_tag(struct
> acpi_table_header *table,
> if (cpu_node) {
> cpu_node = acpi_find_processor_package_id(table, cpu_node,
> level, flag);
> - /* Only the first level has a guaranteed id */
> - if (level == 0)
> + /*
> + * As per specification if the processor structure represents
> + * an actual processor, then ACPI processor ID must be valid.
> + * For processor containers ACPI_PPTT_ACPI_PROCESSOR_ID_VALID
> + * should be set if the UID is valid
> + */
> + if (level == 0 ||
> + cpu_node->flags & ACPI_PPTT_ACPI_PROCESSOR_ID_VALID)
> return cpu_node->acpi_processor_id;
> return ACPI_PTR_DIFF(cpu_node, table);
> }
> --
> 2.7.4
>
When the valid flag is set we'll now return a [hopefully] correct platform
dependent ID, but when it's not we'll return an ACPI table offset. How
will users of the ID know? Also, it's possible to return -ENOENT for the
ID when calling find_acpi_cpu_topology(). How can we distinguish that from
an arbitrary platform dependent ID?
Thanks,
drew
Re: general protection fault in vmx_vcpu_run
Looking also at the other crash [0]: msr_bitmap = to_vmx(vcpu)->loaded_vmcs->msr_bitmap; 811f65b7: e8 44 cb 57 00 callq 81773100 <__sanitizer_cov_trace_pc> 811f65bc: 48 8b 54 24 08 mov0x8(%rsp),%rdx 811f65c1: 48 b8 00 00 00 00 00movabs $0xdc00,%rax 811f65c8: fc ff df 811f65cb: 48 c1 ea 03 shr$0x3,%rdx 811f65cf: 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) <- fault here. 811f65d3: 0f 85 36 19 00 00 jne811f7f0f %rdx should contain a pointer to loaded_vmcs. It is directly loaded from the stack [0x8(%rsp)]. This same stack location was just used before the inlined assembly for VMRESUME/VMLAUNCH here: vmx->__launched = vmx->loaded_vmcs->launched; 811f639f: e8 5c cd 57 00 callq 81773100 <__sanitizer_cov_trace_pc> 811f63a4: 48 8b 54 24 08 mov0x8(%rsp),%rdx 811f63a9: 48 b8 00 00 00 00 00movabs $0xdc00,%rax 811f63b0: fc ff df 811f63b3: 48 c1 ea 03 shr$0x3,%rdx 811f63b7: 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) <- used here. ... and this stack location was never touched by anything in between! So something must have corrupted the stack itself not really the kvm_vc pu struct. Obviously the inlined assembly block is using the stack as well, but I can not see anything that would cause this corruption there. That being said, looking at the %rsp and %rbp values that are dumped in the stack trace: RSP: 8801b7d7f380 RBP: 8801b8260140 ... they are almost 4.8 MiB apart! Should not these two register be a bit closer to each other? :) So 2 possibilities here: 1- %rsp is wrong That would explain why the loaded_vmcs was NULL. However, it is a bit harder to understand how it became wrong! It should have been restored during the VMEXIT from the HOST_RSP value in the VMCS! Is this a nested setup? 2- %rbp is wrong That would also explain why the loaded_vmcs was NULL. Whatever corrupted the stack that caused loaded_vmcs to be NULL could have also corrupted the %rbp saved in the stack. That would mean that it happened during a function call. All function calls that happened between the point when the stack was sane (just before the "asm" block for VMLAUNCH) and the crash-site are only kcov related. Looking at kcov, I can not see where the stack would get corrupted though! Obviously another source of corruption can be a completely unrelated thread directly corruption this thread's memory. Maybe it would be easier to just try to repro it first and see which one is true (if at all). [0] https://syzkaller.appspot.com/bug?extid=cc483201a3c6436d3550 On Thu, 2018-06-28 at 10:18 -0700, Jim Mattson wrote: > 22: 0f 01 c3 vmresume > 25: 48 89 4c 24 08mov%rcx,0x8(%rsp) > 2a: 59pop%rcx > > : > 2b: 0f 96 81 88 56 00 00 setbe 0x5688(%rcx) > 32: 48 89 81 00 03 00 00 mov%rax,0x300(%rcx) > 39: 48 89 99 18 03 00 00 mov%rbx,0x318(%rcx) > > %rcx should be pointing to the vcpu_vmx structure, but it's not even > canonical: 110035842e78. > Amazon Development Center Germany GmbH Berlin - Dresden - Aachen main office: Krausenstr. 38, 10117 Berlin Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger Ust-ID: DE289237879 Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
Re: [PATCH v2 5/6] i2c: Add Actions Semi OWL family S900 I2C driver
Hi Peter, Thanks for the review! On Fri, Jun 29, 2018 at 06:45:19AM +0200, Peter Rosin wrote: > On June 28, 2018 8:10:41 PM GMT+02:00, Manivannan Sadhasivam > wrote: > >Add Actions Semi OWL family S900 I2C driver. > > > >Signed-off-by: Manivannan Sadhasivam > >--- > > drivers/i2c/busses/Kconfig | 7 + > > drivers/i2c/busses/Makefile | 1 + > > drivers/i2c/busses/i2c-owl.c | 471 +++ > > 3 files changed, 479 insertions(+) > > create mode 100644 drivers/i2c/busses/i2c-owl.c > > > >diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig > >index 4f8df2ec87b1..2062da17e33b 100644 > >--- a/drivers/i2c/busses/Kconfig > >+++ b/drivers/i2c/busses/Kconfig > >@@ -762,6 +762,13 @@ config I2C_OMAP > > Like OMAP1510/1610/1710/5912 and OMAP242x. > > For details see http://www.ti.com/omap. > > > >+config I2C_OWL > >+tristate "OWL I2C Controller" > >+depends on ARCH_ACTIONS || COMPILE_TEST > >+help > >+ Say Y here if you want to use the I2C bus controller on > >+ the Actions Semi OWL SoCs. > >+ > > config I2C_PASEMI > > tristate "PA Semi SMBus interface" > > depends on PPC_PASEMI && PCI > >diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile > >index 5a869144a0c5..b71618f77880 100644 > >--- a/drivers/i2c/busses/Makefile > >+++ b/drivers/i2c/busses/Makefile > >@@ -76,6 +76,7 @@ obj-$(CONFIG_I2C_MXS) += i2c-mxs.o > > obj-$(CONFIG_I2C_NOMADIK) += i2c-nomadik.o > > obj-$(CONFIG_I2C_OCORES)+= i2c-ocores.o > > obj-$(CONFIG_I2C_OMAP) += i2c-omap.o > >+obj-$(CONFIG_I2C_OWL) += i2c-owl.o > > obj-$(CONFIG_I2C_PASEMI)+= i2c-pasemi.o > > obj-$(CONFIG_I2C_PCA_PLATFORM) += i2c-pca-platform.o > > obj-$(CONFIG_I2C_PMCMSP)+= i2c-pmcmsp.o > >diff --git a/drivers/i2c/busses/i2c-owl.c > >b/drivers/i2c/busses/i2c-owl.c > >new file mode 100644 > >index ..12320fca6755 > >--- /dev/null > >+++ b/drivers/i2c/busses/i2c-owl.c > >@@ -0,0 +1,471 @@ > >+// SPDX-License-Identifier: GPL-2.0+ > >+/* > >+ * OWL SoC's I2C driver > >+ * > >+ * Copyright (c) 2014 Actions Semi Inc. > >+ * Author: David Liu > >+ * > >+ * Copyright (c) 2018 Linaro Ltd. > >+ * Author: Manivannan Sadhasivam > >+ */ > >+ > >+#include > >+#include > >+#include > >+#include > >+#include > >+#include > >+#include > > I would have kept this list fully sorted. > Ack. > >+ > >+/* I2C registers */ > >+#define OWL_I2C_REG_CTL 0x > >+#define OWL_I2C_REG_CLKDIV 0x0004 > >+#define OWL_I2C_REG_STAT0x0008 > >+#define OWL_I2C_REG_ADDR0x000C > >+#define OWL_I2C_REG_TXDAT 0x0010 > >+#define OWL_I2C_REG_RXDAT 0x0014 > >+#define OWL_I2C_REG_CMD 0x0018 > >+#define OWL_I2C_REG_FIFOCTL 0x001C > >+#define OWL_I2C_REG_FIFOSTAT0x0020 > >+#define OWL_I2C_REG_DATCNT 0x0024 > >+#define OWL_I2C_REG_RCNT0x0028 > >+ > >+/* I2Cx_CTL Bit Mask */ > >+#define OWL_I2C_CTL_RB BIT(1) > >+#define OWL_I2C_CTL_GBCC(x) (((x) & 0x3) << 2) > >+#define OWL_I2C_CTL_GBCC_NONE OWL_I2C_CTL_GBCC(0) > >+#define OWL_I2C_CTL_GBCC_START OWL_I2C_CTL_GBCC(1) > >+#define OWL_I2C_CTL_GBCC_STOP OWL_I2C_CTL_GBCC(2) > >+#define OWL_I2C_CTL_GBCC_RSTART OWL_I2C_CTL_GBCC(3) > >+#define OWL_I2C_CTL_IRQEBIT(5) > >+#define OWL_I2C_CTL_EN BIT(7) > >+#define OWL_I2C_CTL_AE BIT(8) > >+#define OWL_I2C_CTL_SHSMBIT(10) > >+ > >+#define OWL_I2C_DIV_FACTOR(x) ((x) & 0xff) > >+ > >+/* I2Cx_STAT Bit Mask */ > >+#define OWL_I2C_STAT_RACK BIT(0) > >+#define OWL_I2C_STAT_BEBBIT(1) > >+#define OWL_I2C_STAT_IRQP BIT(2) > >+#define OWL_I2C_STAT_LABBIT(3) > >+#define OWL_I2C_STAT_STPD BIT(4) > >+#define OWL_I2C_STAT_STAD BIT(5) > >+#define OWL_I2C_STAT_BBBBIT(6) > >+#define OWL_I2C_STAT_TCBBIT(7) > >+#define OWL_I2C_STAT_LBST BIT(8) > >+#define OWL_I2C_STAT_SAMB BIT(9) > >+#define OWL_I2C_STAT_SRGC BIT(10) > >+ > >+/* I2Cx_CMD Bit Mask */ > >+#define OWL_I2C_CMD_SBE BIT(0) > >+#define OWL_I2C_CMD_RBE BIT(4) > >+#define OWL_I2C_CMD_DE BIT(8) > >+#define OWL_I2C_CMD_NS BIT(9) > >+#define OWL_I2C_CMD_SE BIT(10) > >+#define OWL_I2C_CMD_MSS BIT(11) > >+#define OWL_I2C_CMD_WRS BIT(12) > >+#define OWL_I2C_CMD_SECLBIT(15) > >+ > >+#define OWL_I2C_CMD_AS(x) (((x) & 0x7) << 1) > >+#define OWL_I2C_CMD_SAS(x) (((x) & 0x7) << 5) > >+ > >+/* I2Cx_FIFOCTL Bit Mask */ > >+#define OWL_I2C_FIFOCTL_NIB BIT(0) > >+#define OWL_I2C_FIFOCTL_RFR BIT(1) > >+#define OWL_I2C_FIFOCTL_TFR BIT(2) > >+ > >+/* I2Cc_FIFOSTAT Bit Mask */ > >+#define OWL_I2C_FIFOSTAT_RNBBIT(1) > >+#define OWL_I2C_FIFOSTAT_RFEBIT(2) > >+#define OWL_I2C_FIFOSTAT_TFFBIT(5) > >+#define OWL_I2C_FIFOSTAT_TFDGENMASK(23, 16) > >+#define OWL_I2C_FIFOSTAT_RFDGENMASK(15, 8) > >+ > >+/* I2C bus timeout */ > >+#define OWL_I2C_TIMEOUT
[PATCH] staging: rtl8723bs: fix line over 80 characters
Fix line over 80 characters by replacing tab with space.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8723bs/core/rtw_xmit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_xmit.c
b/drivers/staging/rtl8723bs/core/rtw_xmit.c
index 3e7c1f07b8b4..edb678190b4b 100644
--- a/drivers/staging/rtl8723bs/core/rtw_xmit.c
+++ b/drivers/staging/rtl8723bs/core/rtw_xmit.c
@@ -36,7 +36,7 @@ void _rtw_init_sta_xmit_priv(struct sta_xmit_priv
*psta_xmitpriv)
INIT_LIST_HEAD(&psta_xmitpriv->apsd);
}
-s32_rtw_init_xmit_priv(struct xmit_priv *pxmitpriv, struct adapter
*padapter)
+s32 _rtw_init_xmit_priv(struct xmit_priv *pxmitpriv, struct adapter *padapter)
{
int i;
struct xmit_buf *pxmitbuf;
--
2.18.0
Re: [PATCH 2/2] ASoC: es7241: add es7241 codec support
Hi Jerome,
I love your patch! Perhaps something to improve:
[auto build test WARNING on asoc/for-next]
[also build test WARNING on v4.18-rc2 next-20180629]
[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/Jerome-Brunet/ASoC-add-es7241-support/20180630-021159
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
for-next
smatch warnings:
sound/soc/codecs/es7241.c:147 es7241_set_fmt() warn: missing break? reassigning
'priv->is_slave'
#
https://github.com/0day-ci/linux/commit/d494a70ae50e5f95d2ab09bcaf3065b4359bde0e
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout d494a70ae50e5f95d2ab09bcaf3065b4359bde0e
vim +147 sound/soc/codecs/es7241.c
d494a70a Jerome Brunet 2018-06-29 123
d494a70a Jerome Brunet 2018-06-29 124 static int es7241_set_fmt(struct
snd_soc_dai *dai, unsigned int fmt)
d494a70a Jerome Brunet 2018-06-29 125 {
d494a70a Jerome Brunet 2018-06-29 126 struct es7241_data *priv =
snd_soc_dai_get_drvdata(dai);
d494a70a Jerome Brunet 2018-06-29 127
d494a70a Jerome Brunet 2018-06-29 128 if ((fmt &
SND_SOC_DAIFMT_INV_MASK) != SND_SOC_DAIFMT_NB_NF) {
d494a70a Jerome Brunet 2018-06-29 129 dev_err(dai->dev,
"Unsupported dai clock inversion\n");
d494a70a Jerome Brunet 2018-06-29 130 return -EINVAL;
d494a70a Jerome Brunet 2018-06-29 131 }
d494a70a Jerome Brunet 2018-06-29 132
d494a70a Jerome Brunet 2018-06-29 133 switch (fmt &
SND_SOC_DAIFMT_FORMAT_MASK) {
d494a70a Jerome Brunet 2018-06-29 134 case SND_SOC_DAIFMT_I2S:
d494a70a Jerome Brunet 2018-06-29 135 case SND_SOC_DAIFMT_LEFT_J:
d494a70a Jerome Brunet 2018-06-29 136 break;
d494a70a Jerome Brunet 2018-06-29 137
d494a70a Jerome Brunet 2018-06-29 138 default:
d494a70a Jerome Brunet 2018-06-29 139 dev_err(dai->dev,
"Unsupported dai format\n");
d494a70a Jerome Brunet 2018-06-29 140 return -EINVAL;
d494a70a Jerome Brunet 2018-06-29 141 }
d494a70a Jerome Brunet 2018-06-29 142
d494a70a Jerome Brunet 2018-06-29 143 switch (fmt &
SND_SOC_DAIFMT_MASTER_MASK) {
d494a70a Jerome Brunet 2018-06-29 144 case SND_SOC_DAIFMT_CBS_CFS:
d494a70a Jerome Brunet 2018-06-29 145 priv->is_slave = true;
d494a70a Jerome Brunet 2018-06-29 146 case SND_SOC_DAIFMT_CBM_CFM:
d494a70a Jerome Brunet 2018-06-29 @147 priv->is_slave = false;
d494a70a Jerome Brunet 2018-06-29 148 break;
d494a70a Jerome Brunet 2018-06-29 149
d494a70a Jerome Brunet 2018-06-29 150 default:
d494a70a Jerome Brunet 2018-06-29 151 dev_err(dai->dev,
"Unsupported clock configuration\n");
d494a70a Jerome Brunet 2018-06-29 152 return -EINVAL;
d494a70a Jerome Brunet 2018-06-29 153 }
d494a70a Jerome Brunet 2018-06-29 154
d494a70a Jerome Brunet 2018-06-29 155 return 0;
d494a70a Jerome Brunet 2018-06-29 156 }
d494a70a Jerome Brunet 2018-06-29 157
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[GIT PULL] perf fixes
Linus,
Please pull the latest perf-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-for-linus
# HEAD: 9331510135640429711afbd0c810686100824a79 perf/core: Move inline
keyword at the beginning of declaration
Tooling fixes mostly, plus a build warning fix.
Thanks,
Ingo
-->
Adrian Hunter (1):
perf intel-pt: Fix packet decoding of CYC packets
Arnaldo Carvalho de Melo (5):
tools headers uapi: Synchronize drm/drm.h
perf tools: Update x86's syscall_64.tbl, adding 'io_pgetevents' and 'rseq'
tools include powerpc: Update arch/powerpc/include/uapi/asm/unistd.h copy
to get 'rseq' syscall
tools include uapi: Update if_link.h to pick
IFLA_{BRPORT_ISOLATED,VXLAN_TTL_INHERIT}
tools include uapi: Synchronize bpf.h with the kernel
Ingo Molnar (1):
tools/headers: Pick up latest kernel ABIs
Jiri Olsa (3):
perf tests: Add event parsing error handling to parse events test
perf tests: Add valid callback for parse-events test
perf bench: Fix numa report output code
Mathieu Malaterre (1):
perf/core: Move inline keyword at the beginning of declaration
Ravi Bangoria (3):
perf script: Add missing output fields in a hint
perf script: Fix crash because of missing evsel->priv
perf tools: Fix crash caused by accessing feat_ops[HEADER_LAST_FEATURE]
Sandipan Das (1):
perf report powerpc: Fix crash if callchain is empty
Thomas Richter (5):
perf record: Support s390 random socket_id assignment
perf test session topology: Fix test on s390
perf alias: Remove trailing newline when reading sysfs files
perf alias: Rebuild alias expression string to make it comparable
perf stat: Remove duplicate event counting
Yonghong Song (1):
perf tools: Fix a clang 7.0 compilation error
kernel/events/core.c | 2 +-
tools/arch/arm/include/uapi/asm/kvm.h | 1 +
tools/arch/arm64/include/uapi/asm/kvm.h| 1 +
tools/arch/powerpc/include/uapi/asm/kvm.h | 1 +
tools/arch/powerpc/include/uapi/asm/unistd.h | 1 +
tools/arch/x86/include/asm/cpufeatures.h | 2 +
tools/include/uapi/drm/drm.h | 7 ++
tools/include/uapi/linux/bpf.h | 2 +-
tools/include/uapi/linux/if_link.h | 2 +
tools/include/uapi/linux/kvm.h | 1 +
tools/perf/arch/powerpc/util/skip-callchain-idx.c | 2 +-
tools/perf/arch/x86/entry/syscalls/syscall_64.tbl | 2 +
tools/perf/bench/numa.c| 5 +-
tools/perf/builtin-annotate.c | 11 ++-
tools/perf/builtin-report.c| 3 +-
tools/perf/builtin-script.c| 30 ++-
tools/perf/tests/parse-events.c| 25 --
tools/perf/tests/topology.c| 1 +
tools/perf/util/c++/clang.cpp | 11 ++-
tools/perf/util/header.c | 12 ++-
.../util/intel-pt-decoder/intel-pt-pkt-decoder.c | 2 +-
tools/perf/util/pmu.c | 99 +-
22 files changed, 201 insertions(+), 22 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 80cca2b30c4f..8f0434a9951a 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6482,7 +6482,7 @@ void perf_prepare_sample(struct perf_event_header *header,
data->phys_addr = perf_virt_to_phys(data->addr);
}
-static void __always_inline
+static __always_inline void
__perf_event_output(struct perf_event *event,
struct perf_sample_data *data,
struct pt_regs *regs,
diff --git a/tools/arch/arm/include/uapi/asm/kvm.h
b/tools/arch/arm/include/uapi/asm/kvm.h
index caae4843cb70..16e006f708ca 100644
--- a/tools/arch/arm/include/uapi/asm/kvm.h
+++ b/tools/arch/arm/include/uapi/asm/kvm.h
@@ -91,6 +91,7 @@ struct kvm_regs {
#define KVM_VGIC_V3_ADDR_TYPE_DIST 2
#define KVM_VGIC_V3_ADDR_TYPE_REDIST 3
#define KVM_VGIC_ITS_ADDR_TYPE 4
+#define KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION5
#define KVM_VGIC_V3_DIST_SIZE SZ_64K
#define KVM_VGIC_V3_REDIST_SIZE(2 * SZ_64K)
diff --git a/tools/arch/arm64/include/uapi/asm/kvm.h
b/tools/arch/arm64/include/uapi/asm/kvm.h
index 04b3256f8e6d..4e76630dd655 100644
--- a/tools/arch/arm64/include/uapi/asm/kvm.h
+++ b/tools/arch/arm64/include/uapi/asm/kvm.h
@@ -91,6 +91,7 @@ struct kvm_regs {
#define KVM_VGIC_V3_ADDR_TYPE_DIST 2
#define KVM_VGIC_V3_ADDR_TYPE_REDIST 3
#define KVM_VGIC_ITS_ADDR_TYPE 4
+#define KVM_VGIC_V3_ADDR_TYPE_REDIST_REGION5
#define KVM_VGIC_V3_DIST_SIZE SZ_64K
#define KVM_VGIC_V3_REDIST_SIZE(2 * SZ_64K)
diff --git a/tools/arch/powerpc/include/uapi/asm/kvm.h
b/tools/arch/powerpc/include/uapi/asm/kvm.h
index 833ed9a16ad
[GIT PULL] x86 fixes
Linus, Please pull the latest x86-urgent-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-urgent-for-linus # HEAD: d79d0d8ad0cb3d782b41631dfeac8eb05e414bcd x86/mm: Clean up the printk()s in show_fault_oops() The biggest diffstat comes from self-test updates, plus there's entry code fixes, 5-level paging related fixes, console debug output fixes, plus misc fixes. out-of-topic modifications in x86-urgent-for-linus: - tools/testing/selftests/x86/sigreturn.c# e8a445dea219: selftests/x86/sigreturn: Do # ec3480205660: selftests/x86/sigreturn/64: Thanks, Ingo --> Andrey Ryabinin (1): x86/mm: Don't free P4D table when it is folded at runtime Andy Lutomirski (3): x86/entry/64/compat: Fix "x86/entry/64/compat: Preserve r8-r11 in int $0x80" selftests/x86/sigreturn/64: Fix spurious failures on AMD CPUs selftests/x86/sigreturn: Do minor cleanups Dmitry Vyukov (2): x86/mm: Get rid of KERN_CONT in show_fault_oops() x86/mm: Clean up the printk()s in show_fault_oops() Jan Beulich (1): x86/entry/32: Add explicit 'l' instruction suffix Kirill A. Shutemov (2): x86/efi: Fix efi_call_phys_epilog() with CONFIG_X86_5LEVEL=y x86/mm: Drop unneeded __always_inline for p4d page table helpers arch/x86/entry/entry_32.S | 2 +- arch/x86/entry/entry_64_compat.S| 16 - arch/x86/include/asm/pgalloc.h | 3 ++ arch/x86/include/asm/pgtable.h | 2 +- arch/x86/include/asm/pgtable_64.h | 4 +-- arch/x86/mm/fault.c | 21 arch/x86/platform/efi/efi_64.c | 4 +-- tools/testing/selftests/x86/sigreturn.c | 59 - 8 files changed, 60 insertions(+), 51 deletions(-) diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S index 2582881d19ce..c371bfee137a 100644 --- a/arch/x86/entry/entry_32.S +++ b/arch/x86/entry/entry_32.S @@ -477,7 +477,7 @@ ENTRY(entry_SYSENTER_32) * whereas POPF does not.) */ addl$PT_EFLAGS-PT_DS, %esp /* point esp at pt_regs->flags */ - btr $X86_EFLAGS_IF_BIT, (%esp) + btrl$X86_EFLAGS_IF_BIT, (%esp) popfl /* diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S index 9de7f1e1dede..7d0df78db727 100644 --- a/arch/x86/entry/entry_64_compat.S +++ b/arch/x86/entry/entry_64_compat.S @@ -84,13 +84,13 @@ ENTRY(entry_SYSENTER_compat) pushq %rdx/* pt_regs->dx */ pushq %rcx/* pt_regs->cx */ pushq $-ENOSYS/* pt_regs->ax */ - pushq %r8 /* pt_regs->r8 */ + pushq $0 /* pt_regs->r8 = 0 */ xorl%r8d, %r8d /* nospec r8 */ - pushq %r9 /* pt_regs->r9 */ + pushq $0 /* pt_regs->r9 = 0 */ xorl%r9d, %r9d /* nospec r9 */ - pushq %r10/* pt_regs->r10 */ + pushq $0 /* pt_regs->r10 = 0 */ xorl%r10d, %r10d/* nospec r10 */ - pushq %r11/* pt_regs->r11 */ + pushq $0 /* pt_regs->r11 = 0 */ xorl%r11d, %r11d/* nospec r11 */ pushq %rbx/* pt_regs->rbx */ xorl%ebx, %ebx /* nospec rbx */ @@ -374,13 +374,13 @@ ENTRY(entry_INT80_compat) pushq %rcx/* pt_regs->cx */ xorl%ecx, %ecx /* nospec cx */ pushq $-ENOSYS/* pt_regs->ax */ - pushq $0 /* pt_regs->r8 = 0 */ + pushq %r8 /* pt_regs->r8 */ xorl%r8d, %r8d /* nospec r8 */ - pushq $0 /* pt_regs->r9 = 0 */ + pushq %r9 /* pt_regs->r9 */ xorl%r9d, %r9d /* nospec r9 */ - pushq $0 /* pt_regs->r10 = 0 */ + pushq %r10/* pt_regs->r10*/ xorl%r10d, %r10d/* nospec r10 */ - pushq $0 /* pt_regs->r11 = 0 */ + pushq %r11/* pt_regs->r11 */ xorl%r11d, %r11d/* nospec r11 */ pushq %rbx/* pt_regs->rbx */ xorl%ebx, %ebx /* nospec rbx */ diff --git a/arch/x86/include/asm/pgalloc.h b/arch/x86/include/asm/pgalloc.h index ada6410fd2ec..fbd578daa66e 100644 --- a/arch/x86/include/asm/pgalloc.h +++ b/arch/x86/include/asm/pgalloc.h @@ -184,6 +184,9 @@ static inline p4d_t *p4d_alloc_one(struct mm_struct *mm, unsigned long addr) static inline void p4d
Re: [PATCH v2 2/3] clk: actions: Add S700 SoC clock support
Hi Saravanan,
On Thu, Jun 28, 2018 at 09:18:04PM +0200, Saravanan Sekar wrote:
> Add Actions Semi S700 SoC clock support
>
> Signed-off-by: Parthiban Nallathambi
> Signed-off-by: Saravanan Sekar
> ---
> drivers/clk/actions/Kconfig| 7 +
> drivers/clk/actions/Makefile | 1 +
> drivers/clk/actions/owl-s700.c | 614 +
> 3 files changed, 622 insertions(+)
> create mode 100644 drivers/clk/actions/owl-s700.c
>
> diff --git a/drivers/clk/actions/Kconfig b/drivers/clk/actions/Kconfig
> index 8854adb37847..d883b48e4607 100644
> --- a/drivers/clk/actions/Kconfig
> +++ b/drivers/clk/actions/Kconfig
> @@ -1,6 +1,7 @@
> config CLK_ACTIONS
> bool "Clock driver for Actions Semi SoCs"
> depends on ARCH_ACTIONS || COMPILE_TEST
> + select REGMAP_MMIO
This change should be in a separate patch.
> default ARCH_ACTIONS
>
> if CLK_ACTIONS
> @@ -11,4 +12,10 @@ config CLK_OWL_S900
> bool "Support for the Actions Semi OWL S900 clocks"
> depends on (ARM64 && ARCH_ACTIONS) || COMPILE_TEST
> default ARM64 && ARCH_ACTIONS
> +
> +config CLK_OWL_S700
> + bool "Support for the Actions Semi OWL S700 clocks"
> + depends on (ARM64 && ARCH_ACTIONS) || COMPILE_TEST
> + default ARM64 && ARCH_ACTIONS
> +
It's good to keep the symbols alphabetically sorted (ascending order)
> endif
> diff --git a/drivers/clk/actions/Makefile b/drivers/clk/actions/Makefile
> index 76e431434d10..a860973d940d 100644
> --- a/drivers/clk/actions/Makefile
> +++ b/drivers/clk/actions/Makefile
> @@ -9,4 +9,5 @@ clk-owl-y += owl-composite.o
> clk-owl-y+= owl-pll.o
>
> # SoC support
> +obj-$(CONFIG_CLK_OWL_S900) += owl-s700.o
Should be CONFIG_CLK_OWL_S700
> obj-$(CONFIG_CLK_OWL_S900) += owl-s900.o
> diff --git a/drivers/clk/actions/owl-s700.c b/drivers/clk/actions/owl-s700.c
> new file mode 100644
> index ..cc8d1f947171
> --- /dev/null
> +++ b/drivers/clk/actions/owl-s700.c
> @@ -0,0 +1,614 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Actions S700 clock driver
> + *
> + * Copyright (c) 2014 Actions Semi Inc.
> + * Author: David Liu
> + *
> + * Author: Pathiban Nallathambi
> + * Author: Saravanan Sekar
> + */
> +
> +#include
> +#include
> +
> +#include "owl-common.h"
> +#include "owl-composite.h"
> +#include "owl-divider.h"
> +#include "owl-factor.h"
> +#include "owl-fixed-factor.h"
> +#include "owl-gate.h"
> +#include "owl-mux.h"
> +#include "owl-pll.h"
> +
> +#include
> +
> +#define CMU_COREPLL (0x)
> +#define CMU_DEVPLL (0x0004)
> +#define CMU_DDRPLL (0x0008)
> +#define CMU_NANDPLL (0x000C)
> +#define CMU_DISPLAYPLL (0x0010)
> +#define CMU_AUDIOPLL (0x0014)
> +#define CMU_TVOUTPLL (0x0018)
> +#define CMU_BUSCLK (0x001C)
> +#define CMU_SENSORCLK(0x0020)
> +#define CMU_LCDCLK (0x0024)
> +#define CMU_DSIPLLCLK(0x0028)
> +#define CMU_CSICLK (0x002C)
> +#define CMU_DECLK(0x0030)
> +#define CMU_SICLK(0x0034)
> +#define CMU_BUSCLK1 (0x0038)
> +#define CMU_HDECLK (0x003C)
> +#define CMU_VDECLK (0x0040)
> +#define CMU_VCECLK (0x0044)
> +#define CMU_NANDCCLK (0x004C)
> +#define CMU_SD0CLK (0x0050)
> +#define CMU_SD1CLK (0x0054)
> +#define CMU_SD2CLK (0x0058)
> +#define CMU_UART0CLK (0x005C)
> +#define CMU_UART1CLK (0x0060)
> +#define CMU_UART2CLK (0x0064)
> +#define CMU_UART3CLK (0x0068)
> +#define CMU_UART4CLK (0x006C)
> +#define CMU_UART5CLK (0x0070)
> +#define CMU_UART6CLK (0x0074)
> +#define CMU_PWM0CLK (0x0078)
> +#define CMU_PWM1CLK (0x007C)
> +#define CMU_PWM2CLK (0x0080)
> +#define CMU_PWM3CLK (0x0084)
> +#define CMU_PWM4CLK (0x0088)
> +#define CMU_PWM5CLK (0x008C)
> +#define CMU_GPU3DCLK (0x0090)
> +#define CMU_CORECTL (0x009C)
> +#define CMU_DEVCLKEN0(0x00A0)
> +#define CMU_DEVCLKEN1(0x00A4)
> +#define CMU_DEVRST0 (0x00A8)
> +#define CMU_DEVRST1 (0x00AC)
> +#define CMU_USBPLL (0x00B0)
> +#define CMU_ETHERNETPLL (0x00B4)
> +#define CMU_CVBSPLL (0x00B8)
> +#define CMU_SSTSCLK (0x00C0)
> +
> +static struct clk_pll_table clk_audio_pll_table[] = {
> + {0, 45158400}, {1, 49152000},
> + {0, 0},
> +};
> +
> +static struct clk_pll_table clk_cvbs_pll_table[] = {
> + {27, 29*1200}, {28, 30*1200}, {29, 31*1200},
Please leave a space around *
> + {30, 32*1200}, {31, 33*1200}, {32, 34*1200},
> + {33, 35*1200}, {34, 36*1200}, {35, 37*1200},
> + {36, 38*1200}, {37, 39*1200}, {38, 40*1200},
> + {39, 41*1200}, {40, 42*1200}, {41, 43*1200},
> + {42, 44*1200}, {43,
Re: [PATCH v1 0/6] x86/tsc: Clean up legacy code for Intel MID
On Fri, 29 Jun 2018, Andy Shevchenko wrote: > As Thomas noticed there is unusual initialization is going on on Intel MID > platforms when TSC is being calibrated. > > It appears that we have tsc_msr.c to support Intel MID in a more generic way. > > So, this patch series removes legacy calibration code and does accompanying > clean ups. > > Has been tested on Intel Medfield and Intel Merrifield platforms. Nice series from a quick glance! I'll have a deeper look on monday. One thing on top. From your earlier reply: > This sounds like a stub against very old calibration code since Intel > MID has no PIT, HPET, PMTIMER to calibrate from. As we already know that the legacy calibration cannot work on those machines, we really should splt out the msr/cpuid based calibration method into a separate function, which is set for the intel MID stuff and called from native_calibrate_tsc/cpu. Hmm? Thanks, tglx
Re: [PATCH v2 3/3] dt-bindings: clock: Modify Actions Soc clock bindings
Hi Saravanan,
I agree with modifying the existing binding to accomodate other
SoC's of the same family. But the binding should be
"actions,owl-cmu.txt" since it reflects the family name.
Andreas, what do you think?
On Thu, Jun 28, 2018 at 09:18:05PM +0200, Saravanan Sekar wrote:
> Modify clock bindings common Actions Semi Soc family S700/S900.
>
> Signed-off-by: Parthiban Nallathambi
> Signed-off-by: Saravanan Sekar
> ---
> ...tions,s900-cmu.txt => actions,sx00-cmu.txt} | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
> rename Documentation/devicetree/bindings/clock/{actions,s900-cmu.txt =>
> actions,sx00-cmu.txt} (71%)
>
> diff --git a/Documentation/devicetree/bindings/clock/actions,s900-cmu.txt
> b/Documentation/devicetree/bindings/clock/actions,sx00-cmu.txt
> similarity index 71%
> rename from Documentation/devicetree/bindings/clock/actions,s900-cmu.txt
> rename to Documentation/devicetree/bindings/clock/actions,sx00-cmu.txt
> index 93e4fb827cd6..8dc7edb4d198 100644
> --- a/Documentation/devicetree/bindings/clock/actions,s900-cmu.txt
> +++ b/Documentation/devicetree/bindings/clock/actions,sx00-cmu.txt
> @@ -1,12 +1,14 @@
> -* Actions S900 Clock Management Unit (CMU)
> +* Actions S900/S700 Clock Management Unit (CMU)
>
Same as above. Should be Actions OWL SoC's Clock Management Unit (CMU).
> -The Actions S900 clock management unit generates and supplies clock to
> various
> -controllers within the SoC. The clock binding described here is applicable to
> -S900 SoC.
> +The Actions S900/S700 clock management unit generates and supplies clock to
> +various controllers within the SoC. The clock binding described here is
> +applicable to S900/S700 SoC.
>
> Required Properties:
>
> -- compatible: should be "actions,s900-cmu"
> +- compatible: should be one of this
Change to: compatible: should be one of the following:
Thanks,
Mani
> + "actions,s900-cmu"
> + "actions,s700-cmu"
> - reg: physical base address of the controller and length of memory mapped
>region.
> - clocks: Reference to the parent clocks ("hosc", "losc")
> @@ -15,9 +17,9 @@ Required Properties:
> Each clock is assigned an identifier, and client nodes can use this
> identifier
> to specify the clock which they consume.
>
> -All available clocks are defined as preprocessor macros in
> -dt-bindings/clock/actions,s900-cmu.h header and can be used in device
> -tree sources.
> +All available clocks are defined as preprocessor macros in corresponding
> +dt-bindings/clock/actions,s900-cmu.h or s700-cmu.h header and can be used in
> +device tree sources.
>
> External clocks:
>
> --
> 2.18.0
>
Re: [PATCH v2 1/3] arm64: dts: actions: Enable clock controller for S700
On Thu, Jun 28, 2018 at 09:18:03PM +0200, Saravanan Sekar wrote:
> Added clock management controller for S700
>
> Signed-off-by: Parthiban Nallathambi
> Signed-off-by: Saravanan Sekar
> ---
> .../boot/dts/actions/s700-cubieboard7.dts | 7 -
> arch/arm64/boot/dts/actions/s700.dtsi | 8 ++
> include/dt-bindings/clock/actions,s700-cmu.h | 128 ++
> 3 files changed, 136 insertions(+), 7 deletions(-)
> create mode 100644 include/dt-bindings/clock/actions,s700-cmu.h
>
> diff --git a/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
> b/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
> index ef79d7905f44..28f3f4a0f7f0 100644
> --- a/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
> +++ b/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
> @@ -28,12 +28,6 @@
> device_type = "memory";
> reg = <0x1 0xe000 0x0 0x0>;
> };
> -
> - uart3_clk: uart3-clk {
> - compatible = "fixed-clock";
> - clock-frequency = <921600>;
> - #clock-cells = <0>;
> - };
Sourcing CMU clock for UART should be in a separate patch.
> };
>
> &timer {
> @@ -42,5 +36,4 @@
>
> &uart3 {
> status = "okay";
> - clocks = <&uart3_clk>;
> };
> diff --git a/arch/arm64/boot/dts/actions/s700.dtsi
> b/arch/arm64/boot/dts/actions/s700.dtsi
> index 66dd5309f0a2..3530b705df90 100644
> --- a/arch/arm64/boot/dts/actions/s700.dtsi
> +++ b/arch/arm64/boot/dts/actions/s700.dtsi
> @@ -4,6 +4,7 @@
> */
>
> #include
> +#include
>
> / {
> compatible = "actions,s700";
> @@ -44,6 +45,12 @@
> };
> };
>
> + clock: clock-controller@e0168000 {
> + compatible = "actions,s700-cmu";
> + reg = <0 0xe0168000 0 0x1000>;
> + #clock-cells = <1>;
> + };
> +
There is no fixed rate clock like losc?
> reserved-memory {
> #address-cells = <2>;
> #size-cells = <2>;
> @@ -129,6 +136,7 @@
> compatible = "actions,s900-uart", "actions,owl-uart";
> reg = <0x0 0xe0126000 0x0 0x2000>;
> interrupts = ;
> + clocks = <&clock CLK_UART3>;
> status = "disabled";
> };
>
> diff --git a/include/dt-bindings/clock/actions,s700-cmu.h
> b/include/dt-bindings/clock/actions,s700-cmu.h
> new file mode 100644
> index ..e5b4ea130953
> --- /dev/null
> +++ b/include/dt-bindings/clock/actions,s700-cmu.h
> @@ -0,0 +1,128 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Actions S700 clock driver
> + *
> + * Copyright (c) 2014 Actions Semi Inc.
> + * Author: David Liu
> + *
> + * Author: Pathiban Nallathambi
> + * Author: Saravanan Sekar
> + */
> +
> +#ifndef __DT_BINDINGS_CLOCK_S700_H
> +#define __DT_BINDINGS_CLOCK_S700_H
> +
> +#define CLK_NONE 0
> +
> +/* fixed rate clocks */
> +#define CLK_LOSC 1
> +#define CLK_HOSC 2
> +
> +/* pll clocks */
> +#define CLK_CORE_PLL 3
> +#define CLK_DEV_PLL 4
> +#define CLK_DDR_PLL 5
> +#define CLK_NAND_PLL 6
> +#define CLK_DISPLAY_PLL 7
> +#define CLK_TVOUT_PLL8
> +#define CLK_CVBS_PLL 9
> +#define CLK_AUDIO_PLL10
> +#define CLK_ETHERNET_PLL 11
> +
Remove extra new line please.
> +
> +/* system clock */
> +#define CLK_SYS_BASE 12
> +#define CLK_CPU CLK_SYS_BASE
> +#define CLK_DEV (CLK_SYS_BASE+1)
> +#define CLK_AHB (CLK_SYS_BASE+2)
> +#define CLK_APB (CLK_SYS_BASE+3)
> +#define CLK_DMAC (CLK_SYS_BASE+4)
> +#define CLK_NOC0_CLK_MUX (CLK_SYS_BASE+5)
> +#define CLK_NOC1_CLK_MUX (CLK_SYS_BASE+6)
> +#define CLK_HP_CLK_MUX (CLK_SYS_BASE+7)
> +#define CLK_HP_CLK_DIV (CLK_SYS_BASE+8)
> +#define CLK_NOC1_CLK_DIV (CLK_SYS_BASE+9)
> +#define CLK_NOC0 (CLK_SYS_BASE+10)
> +#define CLK_NOC1 (CLK_SYS_BASE+11)
> +#define CLK_SENOR_SRC(CLK_SYS_BASE+12)
> +
> +/* peripheral device clock */
> +#define CLK_PERIP_BASE 25
> +#define CLK_GPIO (CLK_PERIP_BASE)
> +#define CLK_TIMER(CLK_PERIP_BASE+1)
> +#define CLK_DSI (CLK_PERIP_BASE+2)
> +#define CLK_CSI (CLK_PERIP_BASE+3)
> +#define CLK_SI (CLK_PERIP_BASE+4)
> +#define CLK_DE (CLK_PERIP_BASE+5)
> +#define CLK_HDE (CLK_PERIP_BASE+6)
> +#define CLK_VDE (CLK_PERIP_BASE+7)
> +#define CLK_VCE
Re: [PATCH v2 1/2] iio: light: Add support for vishay vcnl4035
> Add support for VCNL4035, which is capable of Ambient light
> sensing (ALS) and proximity function. This patch adds support
> only for ALS function
comments below
a lot of effort is in getting a timestamp; is it worth it for ALS
measurement? also the implementation is quite involved, what is the idea?
> 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
> ---
> drivers/iio/light/Kconfig| 12 +
> drivers/iio/light/Makefile | 1 +
> drivers/iio/light/vcnl4035.c | 682
> +++
> 3 files changed, 695 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 ..45eccb462ed0
> --- /dev/null
> +++ b/drivers/iio/light/vcnl4035.c
> @@ -0,0 +1,682 @@
> +// 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
> +
> +#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_INT_FLAG 0x0D
there seems to be a tab before VCNL4035_INT_FLAG, should be space
> +#define VCNL4035_DEV_ID 0x0E
> +
> +/* Register masks */
> +#define VCNL4035_MODE_ALS_MASK BIT(0)
> +#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 */
> +#define VCNL4035_MODE_ALS_ENABLE BIT(0)
> +#define VCNL4035_MODE_ALS_DISABLE0x00
> +#define VCNL4035_MODE_ALS_INT_ENABLE BIT(1)
> +#define VCNL4035_MODE_ALS_INT_DISABLE0x00
> +#define VCNL4035_DEV_ID_VAL 0x80
> +#define VCNL4035_ALS_IT_DEFAULT 0x01
> +#define VCNL4035_ALS_PERS_DEFAULT0x00
> +#define VCNL4035_ALS_THDH_DEFAULT5000
> +#define VCNL4035_ALS_THDL_DEFAULT100
> +#define VCNL4035_SLEEP_DELAY_MS 2000
> +
> +struct vcnl4035_data {
> + struct i2c_client *client;
> + struct regmap *regmap;
> + /* protect device settings persistence, integration time, threshold */
> + struct mutex lock;
> + unsigned int als_it_val;
> + unsigned int als_persistence:4;
> + unsigned int als_thresh_low;
> + unsigned int als_thresh_high;
> + struct iio_trigger *drdy_trigger0;
> + s64 irq_timestamp;
> +};
> +
> +static inline bool vcnl4035_is_triggered(struct vcnl4035_data *data)
> +{
> + int ret;
> + int reg;
> +
> + ret = regmap_read(data->regmap, VCNL4035_INT_FLAG, ®);
> + if (ret < 0)
> + return false;
> + if (reg & (VCNL4035_INT_ALS_IF_H_MASK | VCNL4035_INT_ALS_IF_L_MASK))
> + return true;
> + else
> +
[PATCH] staging: rtl8723bs: fix comparsion to true/false and brace issues
Use if(x) and if(!x) instead of comparsion to true/false.
Reported by checkpatch.
Remove unrequired braces from single if else statements.
Add missing space after else: else{ -> else {
Signed-off-by: Michael Straube
---
drivers/staging/rtl8723bs/core/rtw_btcoex.c | 13 ++---
drivers/staging/rtl8723bs/core/rtw_efuse.c | 5 ++---
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_btcoex.c
b/drivers/staging/rtl8723bs/core/rtw_btcoex.c
index adac915a2153..922628c59f80 100644
--- a/drivers/staging/rtl8723bs/core/rtw_btcoex.c
+++ b/drivers/staging/rtl8723bs/core/rtw_btcoex.c
@@ -77,14 +77,14 @@ void rtw_btcoex_SuspendNotify(struct adapter *padapter, u8
state)
void rtw_btcoex_HaltNotify(struct adapter *padapter)
{
- if (false == padapter->bup) {
+ if (!padapter->bup) {
DBG_871X(FUNC_ADPT_FMT ": bup =%d Skip!\n",
FUNC_ADPT_ARG(padapter), padapter->bup);
return;
}
- if (true == padapter->bSurpriseRemoved) {
+ if (padapter->bSurpriseRemoved) {
DBG_871X(FUNC_ADPT_FMT ": bSurpriseRemoved =%d Skip!\n",
FUNC_ADPT_ARG(padapter), padapter->bSurpriseRemoved);
@@ -115,11 +115,10 @@ s32 rtw_btcoex_IsBTCoexCtrlAMPDUSize(struct adapter
*padapter)
void rtw_btcoex_SetManualControl(struct adapter *padapter, u8 manual)
{
- if (true == manual) {
+ if (manual)
hal_btcoex_SetManualControl(padapter, true);
- } else{
+ else
hal_btcoex_SetManualControl(padapter, false);
- }
}
u8 rtw_btcoex_IsBtControlLps(struct adapter *padapter)
@@ -198,11 +197,11 @@ void rtw_btcoex_RejectApAggregatedPacket(struct adapter
*padapter, u8 enable)
pmlmeinfo = &padapter->mlmeextpriv.mlmext_info;
psta = rtw_get_stainfo(&padapter->stapriv,
get_bssid(&padapter->mlmepriv));
- if (true == enable) {
+ if (enable) {
pmlmeinfo->accept_addba_req = false;
if (psta)
send_delba(padapter, 0, psta->hwaddr);
- } else{
+ } else {
pmlmeinfo->accept_addba_req = true;
}
}
diff --git a/drivers/staging/rtl8723bs/core/rtw_efuse.c
b/drivers/staging/rtl8723bs/core/rtw_efuse.c
index c306ad7e395c..b3247c9642ea 100644
--- a/drivers/staging/rtl8723bs/core/rtw_efuse.c
+++ b/drivers/staging/rtl8723bs/core/rtw_efuse.c
@@ -580,11 +580,10 @@ void EFUSE_ShadowMapUpdate(
EFUSE_GetEfuseDefinition(padapter, efuseType, TYPE_EFUSE_MAP_LEN, (void
*)&mapLen, bPseudoTest);
- if (pEEPROM->bautoload_fail_flag == true) {
+ if (pEEPROM->bautoload_fail_flag)
memset(pEEPROM->efuse_eeprom_data, 0xFF, mapLen);
- } else{
+ else
Efuse_ReadAllMap(padapter, efuseType,
pEEPROM->efuse_eeprom_data, bPseudoTest);
- }
/* PlatformMoveMemory((void *)&pHalData->EfuseMap[EFUSE_MODIFY_MAP][0],
*/
/* void *)&pHalData->EfuseMap[EFUSE_INIT_MAP][0], mapLen); */
--
2.18.0
Re: [PATCH 1/2] KVM: X86: Implement PV IPI in linux guest
On Fri, 29 Jun 2018 at 18:10, Vitaly Kuznetsov wrote:
>
> Wanpeng Li writes:
>
> > From: Wanpeng Li
> >
> > Implement PV IPIs in guest kernel.
> >
> > Cc: Paolo Bonzini
> > Cc: Radim Krčmář
> > Cc: Vitaly Kuznetsov
> > Signed-off-by: Wanpeng Li
> > ---
> > arch/x86/include/uapi/asm/kvm_para.h | 1 +
> > arch/x86/kernel/kvm.c| 63
> >
> > 2 files changed, 64 insertions(+)
> >
> > diff --git a/arch/x86/include/uapi/asm/kvm_para.h
> > b/arch/x86/include/uapi/asm/kvm_para.h
> > index 0ede697..19980ec 100644
> > --- a/arch/x86/include/uapi/asm/kvm_para.h
> > +++ b/arch/x86/include/uapi/asm/kvm_para.h
> > @@ -28,6 +28,7 @@
> > #define KVM_FEATURE_PV_UNHALT7
> > #define KVM_FEATURE_PV_TLB_FLUSH 9
> > #define KVM_FEATURE_ASYNC_PF_VMEXIT 10
> > +#define KVM_FEATURE_PV_SEND_IPI 11
> >
> > #define KVM_HINTS_REALTIME 0
> >
> > diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> > index 5b2300b..b4f8dc3 100644
> > --- a/arch/x86/kernel/kvm.c
> > +++ b/arch/x86/kernel/kvm.c
> > @@ -454,6 +454,57 @@ static void __init sev_map_percpu_data(void)
> > }
> >
> > #ifdef CONFIG_SMP
> > +
> > +static void __send_ipi_mask(const struct cpumask *mask, int vector)
> > +{
> > + unsigned long flags, ipi_bitmap = 0;
> > + int cpu;
> > +
> > + local_irq_save(flags);
> > +
> > + for_each_cpu(cpu, mask)
> > + __set_bit(per_cpu(x86_cpu_to_apicid, cpu), &ipi_bitmap);
>
> We need a protection against per_cpu(x86_cpu_to_apicid, cpu) > here.
Will do in v2.
Regards,
Wanpeng Li
Re: [PATCH 2/2] KVM: X86: Implement PV send IPI support
On Fri, 29 Jun 2018 at 18:45, Paolo Bonzini wrote: > > On 29/06/2018 11:51, Wanpeng Li wrote: > > From: Wanpeng Li > > > > Using hypercall to send IPIs by one vmexit instead of one by one for > > xAPIC/x2APIC physical mode and one vmexit per-cluster for x2APIC cluster > > mode. > > > > Even if enable qemu interrupt remapping and PV TLB Shootdown, I can still > > observe ~14% performance boost by ebizzy benchmark for 64 vCPUs VM, the > > total msr-induced vmexits reduce ~70%. > > > > Cc: Paolo Bonzini > > Cc: Radim Krčmář > > Cc: Vitaly Kuznetsov > > Signed-off-by: Wanpeng Li > > --- > > Documentation/virtual/kvm/cpuid.txt | 4 > > arch/x86/kvm/cpuid.c| 3 ++- > > arch/x86/kvm/x86.c | 25 + > > include/uapi/linux/kvm_para.h | 1 + > > 4 files changed, 32 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/virtual/kvm/cpuid.txt > > b/Documentation/virtual/kvm/cpuid.txt > > index ab022dc..d72359f 100644 > > --- a/Documentation/virtual/kvm/cpuid.txt > > +++ b/Documentation/virtual/kvm/cpuid.txt > > @@ -62,6 +62,10 @@ KVM_FEATURE_ASYNC_PF_VMEXIT||10 || > > paravirtualized async PF VM exit > > || || can be enabled by setting > > bit 2 > > || || when writing to msr > > 0x4b564d02 > > > > -- > > +KVM_FEATURE_PV_SEND_IPI||11 || guest checks this feature > > bit > > + || || before enabling > > paravirtualized > > + || || send IPIs. > > It's not "enabling" but "using". You also need to document the > hypercall itself. Will fix it in v2. Regards, Wanpeng Li
Re: [PATCH 2/2] KVM: X86: Implement PV send IPI support
On Fri, 29 Jun 2018 at 18:49, Paolo Bonzini wrote: > > On 29/06/2018 12:09, Vitaly Kuznetsov wrote: > >> +KVM_FEATURE_PV_SEND_IPI||11 || guest checks this feature > >> bit > >> + || || before enabling > >> paravirtualized > >> + || || send IPIs. > > In case we decide to apply this as-is we'll likely need a new feature > > for PV IPI with > 64 vCPUs (or how else would the guest know if the host > > is capable or not?) > > > > Yes, it makes sense. Perhaps we can do one of the following, or both: > > 1) add an argument for a "base vCPU id", so that you can use the > hypercall to send the IPI to CPUs 64..127, 128..191 etc. > > 2) have two bitmask arguments so that one hypercall handles 128 vCPUs. > > to remove or limit the need for the more generic hypercall. Have already done 2) in v2, will send out later. Regards, Wanpeng Li
Re: [PATCH] staging: rtl8723bs: fix comparsion to true/false and brace issues
On Jun 30 2018, Michael Straube wrote:
> @@ -115,11 +115,10 @@ s32 rtw_btcoex_IsBTCoexCtrlAMPDUSize(struct adapter
> *padapter)
>
> void rtw_btcoex_SetManualControl(struct adapter *padapter, u8 manual)
> {
> - if (true == manual) {
> + if (manual)
> hal_btcoex_SetManualControl(padapter, true);
> - } else{
> + else
> hal_btcoex_SetManualControl(padapter, false);
> - }
aka. hal_btcoex_SetManualControl(padapter, manual);
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: [PATCH v2 5/7] mm: rename and change semantics of nr_indirectly_reclaimable_bytes
On 06/29/2018 11:12 PM, Roman Gushchin wrote:
>>
>> The vmstat counter NR_INDIRECTLY_RECLAIMABLE_BYTES was introduced by commit
>> eb59254608bc ("mm: introduce NR_INDIRECTLY_RECLAIMABLE_BYTES") with the goal
>> of
>> accounting objects that can be reclaimed, but cannot be allocated via a
>> SLAB_RECLAIM_ACCOUNT cache. This is now possible via kmalloc() with
>> __GFP_RECLAIMABLE flag, and the dcache external names user is converted.
>>
>> The counter is however still useful for accounting direct page allocations
>> (i.e. not slab) with a shrinker, such as the ION page pool. So keep it, and:
>
> Btw, it looks like I've another example of usefulness of this counter:
> dynamic per-cpu data.
Hmm, but are those reclaimable? Most likely not in general? Do you have
examples that are?
Re: /tmp/cctnQ1CM.s:35: Error: .err encountered
On Sat, Jun 30, 2018 at 9:15 AM, kbuild test robot wrote: > Hi Dmitry, > > FYI, the error/warning still remains. > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 1904148a361a07fb2d7cba1261d1d2c2f33c8d2e > commit: 758517202bd2e427664857c9f2aa59da36848aca arm: port KCOV to arm > date: 2 weeks ago > config: arm-allmodconfig (attached as .config) > compiler: arm-linux-gnueabi-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 758517202bd2e427664857c9f2aa59da36848aca > # save the attached .config to linux build tree > GCC_VERSION=7.2.0 make.cross ARCH=arm > > All errors (new ones prefixed by >>): > >/tmp/cctnQ1CM.s: Assembler messages: >>> /tmp/cctnQ1CM.s:35: Error: .err encountered >/tmp/cctnQ1CM.s:36: Error: .err encountered >/tmp/cctnQ1CM.s:37: Error: .err encountered Hi kbuild test robot, The fix was mailed more than a month ago, but still not merged into the tree. That's linux...
[PATCH 0/5] ti_am335x_tsc: Enable wakeup capability
On AM335x, resistive TSC can wakeup the system from low power state. Currently, parent MFD device is marked as wakeup source, which is inaccurate as its the touch event generated by TSC thats the wakeup source. This series moves all wakeup related calls to operate on TSC device instead of MFD. It also marks TSC IRQ as wakeup capable, so that its not disabled during system suspend. This series is based on Dmitry's comments here: https://lkml.org/lkml/2018/4/24/65 There are many new patches in this series, hence did not mark this as v4. Vignesh R (5): mfd: ti_am335x_tscadc: Don't mark TSCADC MFD as wakeup capable Input: ti_am335x_tsc: Mark TSC device as wakeup source mfd: ti_am335x_tscadc: Keep ADC interface on if child is wakeup capable iio: adc: ti_am335x_adc: Disable ADC during suspend unconditionally Input: ti_am335x_tsc: Mark IRQ as wakeup capable drivers/iio/adc/ti_am335x_adc.c | 12 drivers/input/touchscreen/ti_am335x_tsc.c | 22 +- drivers/mfd/ti_am335x_tscadc.c| 14 +- 3 files changed, 34 insertions(+), 14 deletions(-) -- 2.18.0
[PATCH 2/5] Input: ti_am335x_tsc: Mark TSC device as wakeup source
Instead of TSCADC MFD device, mark TSC as wakeup source and change all
wakeup related PM calls to operate on TSC device.
Signed-off-by: Vignesh R
---
drivers/input/touchscreen/ti_am335x_tsc.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index b86c1e5fbc11..a4f25a915ffc 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -46,6 +46,7 @@ static const int config_pins[] = {
struct titsc {
struct input_dev*input;
struct ti_tscadc_dev*mfd_tscadc;
+ struct device *dev;
unsigned intirq;
unsigned intwires;
unsigned intx_plate_resistance;
@@ -276,7 +277,7 @@ static irqreturn_t titsc_irq(int irq, void *dev)
if (status & IRQENB_HW_PEN) {
ts_dev->pen_down = true;
irqclr |= IRQENB_HW_PEN;
- pm_stay_awake(ts_dev->mfd_tscadc->dev);
+ pm_stay_awake(ts_dev->dev);
}
if (status & IRQENB_PENUP) {
@@ -286,7 +287,7 @@ static irqreturn_t titsc_irq(int irq, void *dev)
input_report_key(input_dev, BTN_TOUCH, 0);
input_report_abs(input_dev, ABS_PRESSURE, 0);
input_sync(input_dev);
- pm_relax(ts_dev->mfd_tscadc->dev);
+ pm_relax(ts_dev->dev);
} else {
ts_dev->pen_down = true;
}
@@ -422,6 +423,7 @@ static int titsc_probe(struct platform_device *pdev)
ts_dev->mfd_tscadc = tscadc_dev;
ts_dev->input = input_dev;
ts_dev->irq = tscadc_dev->irq;
+ ts_dev->dev = &pdev->dev;
err = titsc_parse_dt(pdev, ts_dev);
if (err) {
@@ -436,6 +438,8 @@ static int titsc_probe(struct platform_device *pdev)
goto err_free_mem;
}
+ device_init_wakeup(&pdev->dev, true);
+
titsc_writel(ts_dev, REG_IRQSTATUS, TSC_IRQENB_MASK);
titsc_writel(ts_dev, REG_IRQENABLE, IRQENB_FIFO0THRES);
titsc_writel(ts_dev, REG_IRQENABLE, IRQENB_EOS);
@@ -467,6 +471,7 @@ static int titsc_probe(struct platform_device *pdev)
return 0;
err_free_irq:
+ device_init_wakeup(&pdev->dev, false);
free_irq(ts_dev->irq, ts_dev);
err_free_mem:
input_free_device(input_dev);
@@ -479,6 +484,7 @@ static int titsc_remove(struct platform_device *pdev)
struct titsc *ts_dev = platform_get_drvdata(pdev);
u32 steps;
+ device_init_wakeup(&pdev->dev, false);
free_irq(ts_dev->irq, ts_dev);
/* total steps followed by the enable mask */
@@ -499,7 +505,7 @@ static int __maybe_unused titsc_suspend(struct device *dev)
unsigned int idle;
tscadc_dev = ti_tscadc_dev_get(to_platform_device(dev));
- if (device_may_wakeup(tscadc_dev->dev)) {
+ if (device_may_wakeup(dev)) {
titsc_writel(ts_dev, REG_IRQSTATUS, TSC_IRQENB_MASK);
idle = titsc_readl(ts_dev, REG_IRQENABLE);
titsc_writel(ts_dev, REG_IRQENABLE,
@@ -515,11 +521,11 @@ static int __maybe_unused titsc_resume(struct device *dev)
struct ti_tscadc_dev *tscadc_dev;
tscadc_dev = ti_tscadc_dev_get(to_platform_device(dev));
- if (device_may_wakeup(tscadc_dev->dev)) {
+ if (device_may_wakeup(dev)) {
titsc_writel(ts_dev, REG_IRQWAKEUP,
0x00);
titsc_writel(ts_dev, REG_IRQCLR, IRQENB_HW_PEN);
- pm_relax(ts_dev->mfd_tscadc->dev);
+ pm_relax(dev);
}
titsc_step_config(ts_dev);
titsc_writel(ts_dev, REG_FIFO0THR,
--
2.18.0
[PATCH 4/5] iio: adc: ti_am335x_adc: Disable ADC during suspend unconditionally
Parent MFD device takes care of enabling ADC interface whenever
touchscreen is marked wakeup capable. Therefore, unconditionally disable
ADC interface during system suspend to save power in case of system with
just ADC and no TSC.
Signed-off-by: Vignesh R
---
drivers/iio/adc/ti_am335x_adc.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index 80df5a377d30..cafb1dcadc48 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -693,16 +693,12 @@ static int __maybe_unused tiadc_suspend(struct device
*dev)
{
struct iio_dev *indio_dev = dev_get_drvdata(dev);
struct tiadc_device *adc_dev = iio_priv(indio_dev);
- struct ti_tscadc_dev *tscadc_dev;
unsigned int idle;
- tscadc_dev = ti_tscadc_dev_get(to_platform_device(dev));
- if (!device_may_wakeup(tscadc_dev->dev)) {
- idle = tiadc_readl(adc_dev, REG_CTRL);
- idle &= ~(CNTRLREG_TSCSSENB);
- tiadc_writel(adc_dev, REG_CTRL, (idle |
- CNTRLREG_POWERDOWN));
- }
+ idle = tiadc_readl(adc_dev, REG_CTRL);
+ idle &= ~(CNTRLREG_TSCSSENB);
+ tiadc_writel(adc_dev, REG_CTRL, (idle |
+ CNTRLREG_POWERDOWN));
return 0;
}
--
2.18.0
[PATCH 3/5] mfd: ti_am335x_tscadc: Keep ADC interface on if child is wakeup capable
If a child device like touchscreen is wakeup capable, then keep ADC
interface on, so that a touching resistive screen will generate wakeup
event to the system.
Signed-off-by: Vignesh R
---
drivers/mfd/ti_am335x_tscadc.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index 858c1a071a81..c21ed54d1662 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -294,11 +294,24 @@ static int ti_tscadc_remove(struct platform_device *pdev)
return 0;
}
+static int __maybe_unused ti_tscadc_can_wakeup(struct device *dev, void *data)
+{
+ return device_may_wakeup(dev);
+}
+
static int __maybe_unused tscadc_suspend(struct device *dev)
{
struct ti_tscadc_dev*tscadc = dev_get_drvdata(dev);
regmap_write(tscadc->regmap, REG_SE, 0x00);
+ if (device_for_each_child(dev, NULL, ti_tscadc_can_wakeup)) {
+ u32 ctrl;
+
+ regmap_read(tscadc->regmap, REG_CTRL, &ctrl);
+ ctrl &= ~(CNTRLREG_POWERDOWN);
+ ctrl |= CNTRLREG_TSCSSENB;
+ regmap_write(tscadc->regmap, REG_CTRL, ctrl);
+ }
pm_runtime_put_sync(dev);
return 0;
--
2.18.0
[PATCH 5/5] Input: ti_am335x_tsc: Mark IRQ as wakeup capable
On AM335x, ti_am335x_tsc can wake up the system from suspend, mark the IRQ as wakeup capable, so that device irq is not disabled during system suspend. Signed-off-by: Vignesh R --- drivers/input/touchscreen/ti_am335x_tsc.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c b/drivers/input/touchscreen/ti_am335x_tsc.c index a4f25a915ffc..9e8684ab48f4 100644 --- a/drivers/input/touchscreen/ti_am335x_tsc.c +++ b/drivers/input/touchscreen/ti_am335x_tsc.c @@ -27,6 +27,7 @@ #include #include #include +#include #include @@ -439,6 +440,9 @@ static int titsc_probe(struct platform_device *pdev) } device_init_wakeup(&pdev->dev, true); + err = dev_pm_set_wake_irq(&pdev->dev, ts_dev->irq); + if (err) + dev_err(&pdev->dev, "irq wake enable failed.\n"); titsc_writel(ts_dev, REG_IRQSTATUS, TSC_IRQENB_MASK); titsc_writel(ts_dev, REG_IRQENABLE, IRQENB_FIFO0THRES); @@ -471,6 +475,7 @@ static int titsc_probe(struct platform_device *pdev) return 0; err_free_irq: + dev_pm_clear_wake_irq(&pdev->dev); device_init_wakeup(&pdev->dev, false); free_irq(ts_dev->irq, ts_dev); err_free_mem: @@ -484,6 +489,7 @@ static int titsc_remove(struct platform_device *pdev) struct titsc *ts_dev = platform_get_drvdata(pdev); u32 steps; + dev_pm_clear_wake_irq(&pdev->dev); device_init_wakeup(&pdev->dev, false); free_irq(ts_dev->irq, ts_dev); -- 2.18.0
[PATCH 1/5] mfd: ti_am335x_tscadc: Don't mark TSCADC MFD as wakeup capable
Currently tscadc MFD is marked as wakeup capable which incorrect because, its actually touch event by child TSC device that wakes up the system. Therefore, remove device_init_wakeup() call that marks TSCADC device as wakeup capable in favor of moving to mark TSC input device as wakeup capable later. Signed-off-by: Vignesh R --- drivers/mfd/ti_am335x_tscadc.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c index 47012c0899cd..858c1a071a81 100644 --- a/drivers/mfd/ti_am335x_tscadc.c +++ b/drivers/mfd/ti_am335x_tscadc.c @@ -270,7 +270,6 @@ static int ti_tscadc_probe(struct platform_device *pdev) if (err < 0) goto err_disable_clk; - device_init_wakeup(&pdev->dev, true); platform_set_drvdata(pdev, tscadc); return 0; -- 2.18.0
Re: [PATCH] staging: rtl8723bs: fix comparsion to true/false and brace issues
On 06/30/18 12:08, Andreas Schwab wrote:
On Jun 30 2018, Michael Straube wrote:
@@ -115,11 +115,10 @@ s32 rtw_btcoex_IsBTCoexCtrlAMPDUSize(struct adapter
*padapter)
void rtw_btcoex_SetManualControl(struct adapter *padapter, u8 manual)
{
- if (true == manual) {
+ if (manual)
hal_btcoex_SetManualControl(padapter, true);
- } else{
+ else
hal_btcoex_SetManualControl(padapter, false);
- }
aka. hal_btcoex_SetManualControl(padapter, manual);
Andreas.
Ah, thanks!
Michael
[PATCH] mtd: spi-nor: cadence-quadspi: Fix direct mode write timeouts
Sometimes when writing large size files to flash in direct/memory mapped
mode, it is seen that flash write enable command times out with error:
[ 503.146293] cadence-qspi 4704.ospi: Flash command execution timed out.
This is because, we need to make sure previous direct write operation
is complete by polling for IDLE bit in CONFIG_REG before starting the
next operation.
Fix this by polling for IDLE bit after memory mapped write.
Fixes: a27f2eaf2b27 ("mtd: spi-nor: cadence-quadspi: Add support for direct
access mode")
Cc: sta...@vger.kernel.org
Signed-off-by: Vignesh R
---
drivers/mtd/spi-nor/cadence-quadspi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
b/drivers/mtd/spi-nor/cadence-quadspi.c
index c3f7aaa5d18f..d7e10b36a0b9 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -926,10 +926,12 @@ static ssize_t cqspi_write(struct spi_nor *nor, loff_t to,
if (ret)
return ret;
- if (f_pdata->use_direct_mode)
+ if (f_pdata->use_direct_mode) {
memcpy_toio(cqspi->ahb_base + to, buf, len);
- else
+ ret = cqspi_wait_idle(cqspi);
+ } else {
ret = cqspi_indirect_write_execute(nor, to, buf, len);
+ }
if (ret)
return ret;
--
2.18.0
[PATCH][next] gnss: make struct ubx_gserial_ops static
From: Colin Ian King
The structure ubx_gserial_ops is local to the source and does not need
to be in global scope, so make it static.
Cleans up sparse warning:
symbol 'ubx_gserial_ops' was not declared. Should it be static?
Signed-off-by: Colin Ian King
---
drivers/gnss/ubx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gnss/ubx.c b/drivers/gnss/ubx.c
index 902b6854b7db..12568aebb7f6 100644
--- a/drivers/gnss/ubx.c
+++ b/drivers/gnss/ubx.c
@@ -59,7 +59,7 @@ static int ubx_set_power(struct gnss_serial *gserial,
return -EINVAL;
}
-const struct gnss_serial_ops ubx_gserial_ops = {
+static const struct gnss_serial_ops ubx_gserial_ops = {
.set_power = ubx_set_power,
};
--
2.17.1
[PATCH v2 1/2] staging: rtl8723bs: fix comparsion to true/false and brace issues
Use if(x) and if(!x) instead of comparsion to true/false.
Reported by checkpatch.
Remove unrequired braces from single if else statement.
Add missing space after else: else{ -> else {
Signed-off-by: Michael Straube
---
drivers/staging/rtl8723bs/core/rtw_btcoex.c | 8
drivers/staging/rtl8723bs/core/rtw_efuse.c | 5 ++---
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_btcoex.c
b/drivers/staging/rtl8723bs/core/rtw_btcoex.c
index adac915a2153..e56502e301ec 100644
--- a/drivers/staging/rtl8723bs/core/rtw_btcoex.c
+++ b/drivers/staging/rtl8723bs/core/rtw_btcoex.c
@@ -77,14 +77,14 @@ void rtw_btcoex_SuspendNotify(struct adapter *padapter, u8
state)
void rtw_btcoex_HaltNotify(struct adapter *padapter)
{
- if (false == padapter->bup) {
+ if (!padapter->bup) {
DBG_871X(FUNC_ADPT_FMT ": bup =%d Skip!\n",
FUNC_ADPT_ARG(padapter), padapter->bup);
return;
}
- if (true == padapter->bSurpriseRemoved) {
+ if (padapter->bSurpriseRemoved) {
DBG_871X(FUNC_ADPT_FMT ": bSurpriseRemoved =%d Skip!\n",
FUNC_ADPT_ARG(padapter), padapter->bSurpriseRemoved);
@@ -198,11 +198,11 @@ void rtw_btcoex_RejectApAggregatedPacket(struct adapter
*padapter, u8 enable)
pmlmeinfo = &padapter->mlmeextpriv.mlmext_info;
psta = rtw_get_stainfo(&padapter->stapriv,
get_bssid(&padapter->mlmepriv));
- if (true == enable) {
+ if (enable) {
pmlmeinfo->accept_addba_req = false;
if (psta)
send_delba(padapter, 0, psta->hwaddr);
- } else{
+ } else {
pmlmeinfo->accept_addba_req = true;
}
}
diff --git a/drivers/staging/rtl8723bs/core/rtw_efuse.c
b/drivers/staging/rtl8723bs/core/rtw_efuse.c
index c306ad7e395c..b3247c9642ea 100644
--- a/drivers/staging/rtl8723bs/core/rtw_efuse.c
+++ b/drivers/staging/rtl8723bs/core/rtw_efuse.c
@@ -580,11 +580,10 @@ void EFUSE_ShadowMapUpdate(
EFUSE_GetEfuseDefinition(padapter, efuseType, TYPE_EFUSE_MAP_LEN, (void
*)&mapLen, bPseudoTest);
- if (pEEPROM->bautoload_fail_flag == true) {
+ if (pEEPROM->bautoload_fail_flag)
memset(pEEPROM->efuse_eeprom_data, 0xFF, mapLen);
- } else{
+ else
Efuse_ReadAllMap(padapter, efuseType,
pEEPROM->efuse_eeprom_data, bPseudoTest);
- }
/* PlatformMoveMemory((void *)&pHalData->EfuseMap[EFUSE_MODIFY_MAP][0],
*/
/* void *)&pHalData->EfuseMap[EFUSE_INIT_MAP][0], mapLen); */
--
2.18.0
[PATCH v2 2/2] staging: rtl8723bs: simplify if else statement
Simplify if else statement to a single function call
by passing the variable.
Suggested-by: Andreas Schwab
Signed-off-by: Michael Straube
---
drivers/staging/rtl8723bs/core/rtw_btcoex.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_btcoex.c
b/drivers/staging/rtl8723bs/core/rtw_btcoex.c
index e56502e301ec..35310e8e0806 100644
--- a/drivers/staging/rtl8723bs/core/rtw_btcoex.c
+++ b/drivers/staging/rtl8723bs/core/rtw_btcoex.c
@@ -115,11 +115,7 @@ s32 rtw_btcoex_IsBTCoexCtrlAMPDUSize(struct adapter
*padapter)
void rtw_btcoex_SetManualControl(struct adapter *padapter, u8 manual)
{
- if (true == manual) {
- hal_btcoex_SetManualControl(padapter, true);
- } else{
- hal_btcoex_SetManualControl(padapter, false);
- }
+ hal_btcoex_SetManualControl(padapter, manual);
}
u8 rtw_btcoex_IsBtControlLps(struct adapter *padapter)
--
2.18.0
Re: [PATCH v1 0/6] x86/tsc: Clean up legacy code for Intel MID
On Sat, Jun 30, 2018 at 12:24 PM, Thomas Gleixner wrote: > On Fri, 29 Jun 2018, Andy Shevchenko wrote: > >> As Thomas noticed there is unusual initialization is going on on Intel MID >> platforms when TSC is being calibrated. >> >> It appears that we have tsc_msr.c to support Intel MID in a more generic way. >> >> So, this patch series removes legacy calibration code and does accompanying >> clean ups. >> >> Has been tested on Intel Medfield and Intel Merrifield platforms. > > Nice series from a quick glance! I'll have a deeper look on monday. > > One thing on top. From your earlier reply: > >> This sounds like a stub against very old calibration code since Intel >> MID has no PIT, HPET, PMTIMER to calibrate from. > > As we already know that the legacy calibration cannot work on those > machines, we really should splt out the msr/cpuid based calibration method > into a separate function, which is set for the intel MID stuff and called > from native_calibrate_tsc/cpu. > > Hmm? But that's what has been done back in 2013! By some reason, I dunno why, the same author didn't clean up it. -- With Best Regards, Andy Shevchenko
[PATCH] vfs: make helper function to_mnt_ns static
From: Colin Ian King
The function to_mnt_ns is local to the source and does not need to be
in global scope, so make it static.
Cleans up sparse warning:
symbol 'to_mnt_ns' was not declared. Should it be static?
Signed-off-by: Colin Ian King
---
fs/namespace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/namespace.c b/fs/namespace.c
index 4e630dcb75c9..e7d2119656a4 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1641,7 +1641,7 @@ static bool is_mnt_ns_file(struct dentry *dentry)
dentry->d_fsdata == &mntns_operations;
}
-struct mnt_namespace *to_mnt_ns(struct ns_common *ns)
+static struct mnt_namespace *to_mnt_ns(struct ns_common *ns)
{
return container_of(ns, struct mnt_namespace, ns);
}
--
2.17.1
A little video of me, and summary of research, computing part: What should be the way forward for OS's
A complete and coherent philosophy is needed, that is compatible with the level of intelligence needed in the computing space, that will ofcourse affect society in general. Chaos theory, dictates that the wings of a butterfly may cause a storm elsewhere. Zén buddhism will add, did the ego of the butterfly indeed cause so much distress? We choose a transcendental angle on life, for high accuracy of philosophical impact, without associations to vain gods, for ego. Our website is: http://www.nyt.cloud Peace (Go With Théé) Ywe Cærlyn Léad 0‐ṅīt Ž - 'A Transcendental Angle On Life' Video Of Me: https://youtu.be/M-wT5xy5qoA
[PATCH] platform/x86: dell-smbios-wmi: make function dell_smbios_wmi_call static
From: Colin Ian King
The function dell_smbios_wmi_call is local to the source and does not
need to be in global scope, so make it static.
Cleans up sparse warning:
symbol 'dell_smbios_wmi_call' was not declared. Should it be static?
Signed-off-by: Colin Ian King
---
drivers/platform/x86/dell-smbios-wmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/x86/dell-smbios-wmi.c
b/drivers/platform/x86/dell-smbios-wmi.c
index fbefedb1c172..88afe5651d24 100644
--- a/drivers/platform/x86/dell-smbios-wmi.c
+++ b/drivers/platform/x86/dell-smbios-wmi.c
@@ -82,7 +82,7 @@ static int run_smbios_call(struct wmi_device *wdev)
return 0;
}
-int dell_smbios_wmi_call(struct calling_interface_buffer *buffer)
+static int dell_smbios_wmi_call(struct calling_interface_buffer *buffer)
{
struct wmi_smbios_priv *priv;
size_t difference;
--
2.17.1
Re: [PATCH v2 5/6] i2c: Add Actions Semi OWL family S900 I2C driver
On Thu, Jun 28, 2018 at 9:10 PM, Manivannan Sadhasivam
wrote:
> Add Actions Semi OWL family S900 I2C driver.
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Perhaps keep in order?
> +#define OWL_I2C_DEFAULT_SPEED 10
> +#define OWL_I2C_MAX_SPEED 40
..._SPEED -> ..._SPEED_HZ ?
DEFAULT -> DEF ?
> +static int owl_i2c_reset(struct owl_i2c_dev *i2c_dev)
> +{
> + unsigned int val, timeout = 0;
> +
> + owl_i2c_update_reg(i2c_dev->base + OWL_I2C_REG_CTL,
> + OWL_I2C_CTL_EN, false);
> + mdelay(1);
1 ms keeping CPU busy for nothing. Perhaps usleep_range() / msleep()?
Is it called in atomic context?
> + owl_i2c_update_reg(i2c_dev->base + OWL_I2C_REG_CTL,
> + OWL_I2C_CTL_EN, true);
> +
> + /* Reset FIFO */
> + owl_i2c_update_reg(i2c_dev->base + OWL_I2C_REG_FIFOCTL,
> + OWL_I2C_FIFOCTL_RFR | OWL_I2C_FIFOCTL_TFR,
> + true);
> +
> + /* Wait 50ms for FIFO reset complete */
> + do {
> + val = readl(i2c_dev->base + OWL_I2C_REG_FIFOCTL);
> + if (!(val & (OWL_I2C_FIFOCTL_RFR | OWL_I2C_FIFOCTL_TFR)))
> + break;
> + mdelay(1);
Ditto.
> + } while (timeout++ < OWL_I2C_MAX_RETRIES);
OK, I see you call it from IRQ context. 50ms for IRQ handler is
inappropriate. (1ms either, but at least not so drastically).
> +}
> +static irqreturn_t owl_i2c_interrupt(int irq, void *_dev)
> +{
> + stat = readl(i2c_dev->base + OWL_I2C_REG_STAT);
> + if (stat & OWL_I2C_STAT_BEB) {
> + dev_dbg(&i2c_dev->adap.dev, "bus error");
> + owl_i2c_reset(i2c_dev);
This is questionable to be here (looking at so loong delays in it).
> + goto stop;
> + }
> + return IRQ_HANDLED;
> +}
> +static int owl_i2c_master_xfer(struct i2c_adapter *adap, struct i2c_msg
> *msgs,
> + int num)
> +{
> + int ret = 0, idx;
Redundant assignment.
> + ret = owl_i2c_hw_init(i2c_dev);
> + if (ret)
> + return ret;
> +}
> +static const struct i2c_algorithm owl_i2c_algorithm = {
> + .master_xfer= owl_i2c_master_xfer,
> + .functionality = owl_i2c_func
Slightly better to keep comma at the end
> +};
> +
> +static const struct i2c_adapter_quirks owl_i2c_quirks = {
> + .flags = I2C_AQ_COMB | I2C_AQ_COMB_WRITE_FIRST,
> + .max_read_len = 240,
> + .max_write_len = 240,
> + .max_comb_1st_msg_len = 6,
> + .max_comb_2nd_msg_len = 240
Ditto.
> +};
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v2 1/6] dt-bindings: i2c: Add binding for Actions Semi OWL I2C controller
Am 28.06.2018 um 20:10 schrieb Manivannan Sadhasivam:
> Add devicetree binding for Actions Semi OWL I2C controller
>
> Signed-off-by: Manivannan Sadhasivam
> ---
> .../devicetree/bindings/i2c/i2c-owl.txt | 27 +++
> 1 file changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-owl.txt
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-owl.txt
> b/Documentation/devicetree/bindings/i2c/i2c-owl.txt
> new file mode 100644
> index ..9b691968cffd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-owl.txt
> @@ -0,0 +1,27 @@
> +OWL I2C controller
As mentioned elsewhere, please fix all subjects, commit messages and
bindings to say Owl, not OWL. There's no need to upper-case it besides
defines.
Also, this title should mention Actions Semiconductor please, not just
the codename Owl.
> +
> +Required properties:
> +
> +- compatible: Should be "actions,s900-i2c".
What about S500? Are you expecting it to carry an S900 compatible? That
seems strange. Are there any differences in the implementations?
Otherwise looks okay.
Thanks,
Andreas
> +- reg : Offset and length of the register set for the device.
> +- #address-cells: Should be 1.
> +- #size-cells : Should be 0.
> +- interrupts: A single interrupt specifier.
> +- clocks: Phandle of the clock feeding the I2C controller.
> +
> +Optional properties:
> +
> +- clock-frequency : Desired I2C bus clock frequency in Hz. As only Normal
> and
> + Fast modes are supported, possible values are 10
> and
> + 40.
> +Examples:
> +
> +i2c0: i2c@e017 {
> +compatible = "actions,s900-i2c";
> +reg = <0 0xe017 0 0x1000>;
> +#address-cells = <1>;
> +#size-cells = <0>;
> +interrupts = ;
> +clocks = <&clock CLK_I2C0>;
> +clock-frequency = <10>;
> +};
>
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Re: [PATCH v2 1/6] dt-bindings: i2c: Add binding for Actions Semi OWL I2C controller
Hi Andreas,
On Sat, Jun 30, 2018 at 02:23:30PM +0200, Andreas Färber wrote:
> Am 28.06.2018 um 20:10 schrieb Manivannan Sadhasivam:
> > Add devicetree binding for Actions Semi OWL I2C controller
> >
> > Signed-off-by: Manivannan Sadhasivam
> > ---
> > .../devicetree/bindings/i2c/i2c-owl.txt | 27 +++
> > 1 file changed, 27 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/i2c/i2c-owl.txt
> >
> > diff --git a/Documentation/devicetree/bindings/i2c/i2c-owl.txt
> > b/Documentation/devicetree/bindings/i2c/i2c-owl.txt
> > new file mode 100644
> > index ..9b691968cffd
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/i2c/i2c-owl.txt
> > @@ -0,0 +1,27 @@
> > +OWL I2C controller
>
> As mentioned elsewhere, please fix all subjects, commit messages and
> bindings to say Owl, not OWL. There's no need to upper-case it besides
> defines.
>
> Also, this title should mention Actions Semiconductor please, not just
> the codename Owl.
>
Sure
> > +
> > +Required properties:
> > +
> > +- compatible: Should be "actions,s900-i2c".
>
> What about S500? Are you expecting it to carry an S900 compatible? That
> seems strange. Are there any differences in the implementations?
>
I haven't tested it on S500 eventhough the implementation looks same. But
anyway if we want to add support for S500 or S700 we can just do the
modifications (if any) slightly and add a separate compatible like we
did for other drivers.
Thanks,
Mani
> Otherwise looks okay.
>
> Thanks,
> Andreas
>
> > +- reg : Offset and length of the register set for the device.
> > +- #address-cells: Should be 1.
> > +- #size-cells : Should be 0.
> > +- interrupts: A single interrupt specifier.
> > +- clocks: Phandle of the clock feeding the I2C controller.
> > +
> > +Optional properties:
> > +
> > +- clock-frequency : Desired I2C bus clock frequency in Hz. As only
> > Normal and
> > + Fast modes are supported, possible values are 10
> > and
> > + 40.
> > +Examples:
> > +
> > +i2c0: i2c@e017 {
> > +compatible = "actions,s900-i2c";
> > +reg = <0 0xe017 0 0x1000>;
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +interrupts = ;
> > +clocks = <&clock CLK_I2C0>;
> > +clock-frequency = <10>;
> > +};
> >
>
>
> --
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)
Assalamu`Alaikum.
Dear Sir/Madam. Assalamu`Alaikum. I am Dr mohammad ouattara, I have ($14.6 Million us dollars) to transfer into your account, I will send you more details about this deal and the procedures to follow when I receive a positive response from you, Have a great day, Dr mohammad ouattara.
Re: [PATCH v2 5/6] i2c: Add Actions Semi OWL family S900 I2C driver
Hi Andy,
On Sat, Jun 30, 2018 at 03:14:37PM +0300, Andy Shevchenko wrote:
> On Thu, Jun 28, 2018 at 9:10 PM, Manivannan Sadhasivam
> wrote:
> > Add Actions Semi OWL family S900 I2C driver.
>
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> > +#include
>
> Perhaps keep in order?
>
Fixed in next revision.
> > +#define OWL_I2C_DEFAULT_SPEED 10
> > +#define OWL_I2C_MAX_SPEED 40
>
> ..._SPEED -> ..._SPEED_HZ ?
>
> DEFAULT -> DEF ?
>
Okay.
> > +static int owl_i2c_reset(struct owl_i2c_dev *i2c_dev)
> > +{
> > + unsigned int val, timeout = 0;
> > +
> > + owl_i2c_update_reg(i2c_dev->base + OWL_I2C_REG_CTL,
> > + OWL_I2C_CTL_EN, false);
>
> > + mdelay(1);
>
> 1 ms keeping CPU busy for nothing. Perhaps usleep_range() / msleep()?
> Is it called in atomic context?
>
I have removed reset function from the interrupt handler and gave the
justification to my reply to Peter's review.
> > + owl_i2c_update_reg(i2c_dev->base + OWL_I2C_REG_CTL,
> > + OWL_I2C_CTL_EN, true);
> > +
> > + /* Reset FIFO */
> > + owl_i2c_update_reg(i2c_dev->base + OWL_I2C_REG_FIFOCTL,
> > + OWL_I2C_FIFOCTL_RFR | OWL_I2C_FIFOCTL_TFR,
> > + true);
> > +
> > + /* Wait 50ms for FIFO reset complete */
> > + do {
> > + val = readl(i2c_dev->base + OWL_I2C_REG_FIFOCTL);
> > + if (!(val & (OWL_I2C_FIFOCTL_RFR | OWL_I2C_FIFOCTL_TFR)))
> > + break;
>
> > + mdelay(1);
>
> Ditto.
>
Same as above.
> > + } while (timeout++ < OWL_I2C_MAX_RETRIES);
>
> OK, I see you call it from IRQ context. 50ms for IRQ handler is
> inappropriate. (1ms either, but at least not so drastically).
>
Same as above.
> > +}
>
> > +static irqreturn_t owl_i2c_interrupt(int irq, void *_dev)
> > +{
>
> > + stat = readl(i2c_dev->base + OWL_I2C_REG_STAT);
> > + if (stat & OWL_I2C_STAT_BEB) {
> > + dev_dbg(&i2c_dev->adap.dev, "bus error");
>
> > + owl_i2c_reset(i2c_dev);
>
> This is questionable to be here (looking at so loong delays in it).
>
Same as above.
> > + goto stop;
> > + }
>
> > + return IRQ_HANDLED;
> > +}
>
> > +static int owl_i2c_master_xfer(struct i2c_adapter *adap, struct i2c_msg
> > *msgs,
> > + int num)
> > +{
>
> > + int ret = 0, idx;
>
> Redundant assignment.
>
No. Actually the return path will be fixed in next iteration. Please
see my reply to Peter's review for explanation.
> > + ret = owl_i2c_hw_init(i2c_dev);
> > + if (ret)
> > + return ret;
>
> > +}
>
> > +static const struct i2c_algorithm owl_i2c_algorithm = {
> > + .master_xfer= owl_i2c_master_xfer,
>
> > + .functionality = owl_i2c_func
>
> Slightly better to keep comma at the end
>
Okay.
> > +};
> > +
> > +static const struct i2c_adapter_quirks owl_i2c_quirks = {
> > + .flags = I2C_AQ_COMB | I2C_AQ_COMB_WRITE_FIRST,
> > + .max_read_len = 240,
> > + .max_write_len = 240,
> > + .max_comb_1st_msg_len = 6,
> > + .max_comb_2nd_msg_len = 240
>
> Ditto.
>
Okay.
Thanks,
Mani
> > +};
>
> --
> With Best Regards,
> Andy Shevchenko
Re: [PATCH v2 5/6] i2c: Add Actions Semi OWL family S900 I2C driver
On Sat, Jun 30, 2018 at 3:44 PM, Manivannan Sadhasivam
wrote:
> On Sat, Jun 30, 2018 at 03:14:37PM +0300, Andy Shevchenko wrote:
>> On Thu, Jun 28, 2018 at 9:10 PM, Manivannan Sadhasivam
>> wrote:
>> > +static int owl_i2c_master_xfer(struct i2c_adapter *adap, struct i2c_msg
>> > *msgs,
>> > + int num)
>> > +{
>>
>> > + int ret = 0, idx;
>>
>> Redundant assignment.
>>
>
> No. Actually the return path will be fixed in next iteration. Please
> see my reply to Peter's review for explanation.
How come? I didn't find anything related to this comment in reply you
are referring to.
I left deliberately the below part to show you the pointlessness of an
assignment to 0.
>> > + ret = owl_i2c_hw_init(i2c_dev);
>> > + if (ret)
>> > + return ret;
Do you mean you are dropping this in next revision?
--
With Best Regards,
Andy Shevchenko
Re: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices
On Sat, Jun 30, 2018 at 01:26:43AM +, Gaoming (ming, consumer BG) wrote: > Yes, it is caused by using 1024 blocksize. > It is historical problem, and I have to admit that's not good idea. I don't > know why somebody choose it some years before. > It has been corrected two years before or more early. But some ancient > devices exist. > It is not user data, no need to do file-based encryption. It is a small > partition for some use. > > However, 1024 is legal though not good, somebody may use it. > And we should fix it. So you understand my position --- the reason why I've been pushing so hard is I'm trying to figure out how big of a problem this is. Specifically speaking, is this a Huawei-specific problem, or something across the entire Android ecosystem. I *thought* I had fixed most of the disaster back in 2011. There have periodic headaches where testers would discover problems where android handsets get bricked after doing a factory reset that I had tracked down to make_ext4fs, and the existence of make_ext4fs is not something I agreed to, and have been fighting for years. So I've been cleaning up after make_ext4fs for a while, even though it's not my responsiblity. (For one thing my work responsibilities are for data center servers at Google, *not* Android; for another, no one asked *me* before they came up with the abomination which is make_ext4fs.) So I don't feel particularly, or personally, responsible for bugs caused by make_ext4fs, because if it had been up to me, it would have never existed in the first place. If it's only in ancient Huawei devices, I don't see a strong reason to support his in upstream e2fsprogs. Are you really going to be backporting the latest e2fsprogs into these ancient Huawei devices? In my experience, the Android team has a hard enough time getting their Android partners to backport kernel fixes for severe security bugs into old Android devices --- never mind versions of e2fsprogs. If not, what's the point? Regards, - Ted
Re: [PATCH v2 5/6] i2c: Add Actions Semi OWL family S900 I2C driver
Hi Andy,
On Sat, Jun 30, 2018 at 04:04:20PM +0300, Andy Shevchenko wrote:
> On Sat, Jun 30, 2018 at 3:44 PM, Manivannan Sadhasivam
> wrote:
> > On Sat, Jun 30, 2018 at 03:14:37PM +0300, Andy Shevchenko wrote:
> >> On Thu, Jun 28, 2018 at 9:10 PM, Manivannan Sadhasivam
> >> wrote:
>
> >> > +static int owl_i2c_master_xfer(struct i2c_adapter *adap, struct i2c_msg
> >> > *msgs,
> >> > + int num)
> >> > +{
> >>
> >> > + int ret = 0, idx;
> >>
> >> Redundant assignment.
> >>
> >
> > No. Actually the return path will be fixed in next iteration. Please
> > see my reply to Peter's review for explanation.
>
> How come? I didn't find anything related to this comment in reply you
> are referring to.
> I left deliberately the below part to show you the pointlessness of an
> assignment to 0.
>
Sorry, my bad. I overlooked this part. This assignment will be dropped.
> >> > + ret = owl_i2c_hw_init(i2c_dev);
> >> > + if (ret)
> >> > + return ret;
>
> Do you mean you are dropping this in next revision?
>
Nope :)
Thanks,
Mani
> --
> With Best Regards,
> Andy Shevchenko
v4.18-rc2 on droid4: screen turns red
Hi! After longer inactivity, attempt to wake up the screen results in screen being completely red. Not too useful. I can still connect over ssh. This happens all the time: Jun 30 11:34:08 devuan kernel: [ 143.605499] [ cut here ] Jun 30 11:34:08 devuan kernel: [ 143.610168] WARNING: CPU: 1 PID: 2220 at drivers/gpu/drm/omapdrm/ dss/hdmi4.c:667 hdmi_audio_stop+0x5c/0x68 Jun 30 11:34:08 devuan kernel: [ 143.619873] Modules linked in: Jun 30 11:34:08 devuan kernel: [ 143.622955] CPU: 1 PID: 2220 Comm: pulseaudio Not tainted 4.18.0- rc2-88315-g3452793-dirty #756 Jun 30 11:34:08 devuan kernel: [ 143.631591] Hardware name: Generic OMAP4 (Flattened Device Tree) Jun 30 11:34:08 devuan kernel: [ 143.637634] [] (unwind_backtrace) from [] (sh ow_stack+0x10/0x14) Jun 30 11:34:08 devuan kernel: [ 143.645446] [] (show_stack) from [] (dump_sta ck+0x8c/0xac) Jun 30 11:34:08 devuan kernel: [ 143.652740] [] (dump_stack) from [] (__warn+0 xe8/0x114) Jun 30 11:34:08 devuan kernel: [ 143.659729] [] (__warn) from [] (warn_slowpath_null+0x3c/0x48) Jun 30 11:34:08 devuan kernel: [ 143.667358] [] (warn_slowpath_null) from [] (hdmi_audio_stop+0x5c/0x68) Jun 30 11:34:08 devuan kernel: [ 143.675750] [] (hdmi_audio_stop) from [] (hdmi_dai_trigger+0x6c/0x88) Jun 30 11:34:08 devuan kernel: [ 143.683990] [] (hdmi_dai_trigger) from [] (soc_pcm_trigger+0xf0/0x130) Jun 30 11:34:08 devuan kernel: [ 143.692291] [] (soc_pcm_trigger) from [] (snd_pcm_do_stop+0x54/0x58) Jun 30 11:34:08 devuan kernel: [ 143.700439] [] (snd_pcm_do_stop) from [] (snd_pcm_action_single+0x38/0x78) Jun 30 11:34:08 devuan kernel: [ 143.709075] [] (snd_pcm_action_single) from [] (snd_pcm_drop+0x48/0x94) Jun 30 11:34:08 devuan kernel: [ 143.717468] [] (snd_pcm_drop) from [] (snd_pcm_ioctl+0x870/0x1180) Jun 30 11:34:08 devuan kernel: [ 143.725433] [] (snd_pcm_ioctl) from [] (do_vfs_ioctl+0x80/0x960) Jun 30 11:34:08 devuan kernel: [ 143.733215] [] (do_vfs_ioctl) from [] (ksys_ioctl+0x5c/0x80) Jun 30 11:34:08 devuan kernel: [ 143.740661] [] (ksys_ioctl) from [] (ret_fast_syscall+0x0/0x54) Jun 30 11:34:08 devuan kernel: [ 143.748352] Exception stack(0xeb8fffa8 to 0xeb80) Jun 30 11:34:08 devuan kernel: [ 143.753448] ffa0: 005129b0 b1971394 0015 4143 00512960 This is probably unrelated: [13215.125732] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host [13245.205535] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host [13252.969940] power_supply battery: driver failed to report `power_now' property: -22 [13275.285369] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host [13291.993652] Charging, 435 uV, 532000 uA [13292.001708] Charging, 435 uV, 532000 uA [13305.364837] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host [13335.445037] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host [13365.524291] cpcap-usb-phy cpcap-usb-phy.0: connected to USB host [13372.940093] power_supply battery: driver failed to report `power_now' property: -22 [13383.554412] g_ether gadget: packet filter 0e [13383.558715] g_ether gadget: ecm req21.43 v000e i l0 [13383.580261] g_ether gadget: notify connect true [13383.612243] g_ether gadget: notify speed 425984000 [13387.213256] cpcap_adc cpcap_adc.0: error reading ADC: -110 [13387.218780] cpcap_battery cpcap_battery.0: cpcap_battery_get_voltage failed: -110 [13387.523254] cpcap_adc cpcap_adc.0: error reading ADC: -110 [13387.528778] cpcap_battery cpcap_battery.0: cpcap_battery_get_current failed: -110 Ideas welcome. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[PATCH v3 0/6] Add Actions Semiconductor Owl S900 I2C support
This patchset adds I2C controller support for Actions Semiconductor S900 SoC. This driver has been structured in a way such that there will be only one controller driver for the whole Owl family series (S500, S700 and S900 SoCs). There are 6 I2C controllers with separate memory mapped register space. The I2C controller can handle atmost two messages concatenated by a repeated start via its internal address feature. Hence the driver uses this feature for messages of length greater than 1. In those cases, the first message of the combined message should be a `write` with maximum message length 6 and the second message's maximum length should be 240 bytes. As far as the bus speed is concerned, this driver only supports Standard (100KHz) and High speed (400KHz) for now. The pinctrl definitions are only available for I2C0, I2C1 and I2C2. With the mux option available only for I2C0. For Bubblegum-96 board utilizing the S900 SoC, only I2C1 and I2C2 which are exposed on the Low speed expansion connector are enabled. This series depends on the pinctrl patch [1] is still not merged by the platform maintainer Andreas but it has been reviewed by the pinctrl maintainer Linus Walleij. For the reference, I have queued up all reviewed dts patches in my tree [2] from which Andreas is picking them for 4.19. For this series, since the dts patches will go through the ARM SoC tree, Andreas will pick it up once it is reviewed. Thanks, Mani [1] https://patchwork.kernel.org/patch/10322937/ [2] https://git.linaro.org/people/manivannan.sadhasivam/linux.git/log/?h=s900-for-next Changes in v3: As per Peter, Andy and Andreas review: * Removed owl_i2c_reset function from interrupt handler since is involves the use of delays. * Fixed the return path in owl_i2c_master_xfer and added a note * Changed "base" parameter to "reg" in owl_i2c_update_reg for better understandability * Ordered the includes in alphabetical order * Small changes to defines and added comma at the end of struct members * Removed rendundant 0 assignment in owl_i2c_master_xfer * Changed all OWL naming convention to Owl and also changed Actions Semi Actions Semiconductor Changes in v2: As per Andy's review: * Modified infinite loops to fixed number of retries * Used i2c_8bit_addr_from_msg for constructing the slave address * Removed unnecessary parenthesis around defines * Modified certain dev_warn to dev_dbg * Modified the error handling to more generic pattern * Fixed the return value in owl_i2c_master_xfer * Added MAINTAINERS patch for I2C driver and its binding Manivannan Sadhasivam (6): dt-bindings: i2c: Add binding for Actions Semiconductor Owl I2C controller arm64: dts: actions: Add Actions Semiconductor S900 I2C controller nodes arm64: dts: actions: Add pinctrl definition for S900 I2C controller arm64: dts: actions: Enable I2C1 and I2C2 in Bubblegum-96 board i2c: Add Actions Semiconductor Owl family S900 I2C driver MAINTAINERS: Add entry for Actions Semiconductor Owl I2C driver .../devicetree/bindings/i2c/i2c-owl.txt | 27 + MAINTAINERS | 2 + .../dts/actions/s900-bubblegum-96-pins.dtsi | 29 ++ .../boot/dts/actions/s900-bubblegum-96.dts| 11 + arch/arm64/boot/dts/actions/s900.dtsi | 60 +++ drivers/i2c/busses/Kconfig| 7 + drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-owl.c | 477 ++ 8 files changed, 614 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-owl.txt create mode 100644 arch/arm64/boot/dts/actions/s900-bubblegum-96-pins.dtsi create mode 100644 drivers/i2c/busses/i2c-owl.c -- 2.17.1
[PATCH v3 1/6] dt-bindings: i2c: Add binding for Actions Semiconductor Owl I2C controller
Add devicetree binding for Actions Semiconductor Owl I2C controller
Signed-off-by: Manivannan Sadhasivam
---
.../devicetree/bindings/i2c/i2c-owl.txt | 27 +++
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-owl.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-owl.txt
b/Documentation/devicetree/bindings/i2c/i2c-owl.txt
new file mode 100644
index ..b743fe444e9f
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-owl.txt
@@ -0,0 +1,27 @@
+Actions Semiconductor Owl I2C controller
+
+Required properties:
+
+- compatible: Should be "actions,s900-i2c".
+- reg : Offset and length of the register set for the device.
+- #address-cells: Should be 1.
+- #size-cells : Should be 0.
+- interrupts: A single interrupt specifier.
+- clocks: Phandle of the clock feeding the I2C controller.
+
+Optional properties:
+
+- clock-frequency : Desired I2C bus clock frequency in Hz. As only Normal and
+ Fast modes are supported, possible values are 10 and
+ 40.
+Examples:
+
+i2c0: i2c@e017 {
+compatible = "actions,s900-i2c";
+reg = <0 0xe017 0 0x1000>;
+#address-cells = <1>;
+#size-cells = <0>;
+interrupts = ;
+clocks = <&clock CLK_I2C0>;
+clock-frequency = <10>;
+};
--
2.17.1
[PATCH v3 2/6] arm64: dts: actions: Add Actions Semiconductor S900 I2C controller nodes
Add I2C controller nodes for Actions Semiconductor S900 SoC.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/actions/s900.dtsi | 60 +++
1 file changed, 60 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s900.dtsi
b/arch/arm64/boot/dts/actions/s900.dtsi
index 7ae8b931f000..6f7b89edbe4d 100644
--- a/arch/arm64/boot/dts/actions/s900.dtsi
+++ b/arch/arm64/boot/dts/actions/s900.dtsi
@@ -174,6 +174,66 @@
#clock-cells = <1>;
};
+ i2c0: i2c@e017 {
+ compatible = "actions,s900-i2c";
+ reg = <0 0xe017 0 0x1000>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_default>;
+ };
+
+ i2c1: i2c@e0172000 {
+ compatible = "actions,s900-i2c";
+ reg = <0 0xe0172000 0 0x1000>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_default>;
+ };
+
+ i2c2: i2c@e0174000 {
+ compatible = "actions,s900-i2c";
+ reg = <0 0xe0174000 0 0x1000>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_default>;
+ };
+
+ i2c3: i2c@e0176000 {
+ compatible = "actions,s900-i2c";
+ reg = <0 0xe0176000 0 0x1000>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c4: i2c@e0178000 {
+ compatible = "actions,s900-i2c";
+ reg = <0 0xe0178000 0 0x1000>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c5: i2c@e017a000 {
+ compatible = "actions,s900-i2c";
+ reg = <0 0xe017a000 0 0x1000>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
pinctrl: pinctrl@e01b {
compatible = "actions,s900-pinctrl";
reg = <0x0 0xe01b 0x0 0x1000>;
--
2.17.1
[PATCH v3 3/6] arm64: dts: actions: Add pinctrl definition for S900 I2C controller
Add pinctrl definition for Actions Semiconductor S900 I2C controller.
Pinctrl definitions are only available for I2C0, I2C1, and I2C2.
Signed-off-by: Manivannan Sadhasivam
---
.../dts/actions/s900-bubblegum-96-pins.dtsi | 29 +++
1 file changed, 29 insertions(+)
create mode 100644 arch/arm64/boot/dts/actions/s900-bubblegum-96-pins.dtsi
diff --git a/arch/arm64/boot/dts/actions/s900-bubblegum-96-pins.dtsi
b/arch/arm64/boot/dts/actions/s900-bubblegum-96-pins.dtsi
new file mode 100644
index ..95e8b31071f9
--- /dev/null
+++ b/arch/arm64/boot/dts/actions/s900-bubblegum-96-pins.dtsi
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+&pinctrl {
+
+ i2c0_default: i2c0_default {
+ pinmux {
+ groups = "i2c0_mfp";
+ function = "i2c0";
+ };
+ pinconf {
+ pins = "i2c0_sclk", "i2c0_sdata";
+ bias-pull-up;
+ };
+ };
+
+ i2c1_default: i2c1_default {
+ pinconf {
+ pins = "i2c1_sclk", "i2c1_sdata";
+ bias-pull-up;
+ };
+ };
+
+ i2c2_default: i2c2_default {
+ pinconf {
+ pins = "i2c2_sclk", "i2c2_sdata";
+ bias-pull-up;
+ };
+ };
+};
--
2.17.1
[PATCH v3 4/6] arm64: dts: actions: Enable I2C1 and I2C2 in Bubblegum-96 board
Enable I2C1 and I2C2 exposed on the low speed expansion connector in
Bubblegum-96 board.
Signed-off-by: Manivannan Sadhasivam
---
arch/arm64/boot/dts/actions/s900-bubblegum-96.dts | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
b/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
index d0ba35df9015..57ae374cfb5a 100644
--- a/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
+++ b/arch/arm64/boot/dts/actions/s900-bubblegum-96.dts
@@ -7,6 +7,7 @@
/dts-v1/;
#include "s900.dtsi"
+#include "s900-bubblegum-96-pins.dtsi"
/ {
compatible = "ucrobotics,bubblegum-96", "actions,s900";
@@ -35,6 +36,16 @@
clocks = <&cmu CLK_UART5>;
};
+&i2c1 {
+ status = "okay";
+ clocks = <&cmu CLK_I2C1>;
+};
+
+&i2c2 {
+ status = "okay";
+ clocks = <&cmu CLK_I2C2>;
+};
+
/*
* GPIO name legend: proper name = the GPIO line is used as GPIO
* NC = not connected (pin out but not routed from the chip to
--
2.17.1
[PATCH v3 5/6] i2c: Add Actions Semiconductor Owl family S900 I2C driver
Add Actions Semiconductor Owl family S900 I2C driver.
Signed-off-by: Manivannan Sadhasivam
---
drivers/i2c/busses/Kconfig | 7 +
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-owl.c | 477 +++
3 files changed, 485 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-owl.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 4f8df2ec87b1..8c8025f87ce4 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -762,6 +762,13 @@ config I2C_OMAP
Like OMAP1510/1610/1710/5912 and OMAP242x.
For details see http://www.ti.com/omap.
+config I2C_OWL
+ tristate "Actions Semiconductor Owl I2C Controller"
+ depends on ARCH_ACTIONS || COMPILE_TEST
+ help
+ Say Y here if you want to use the I2C bus controller on
+ the Actions Semiconductor Owl SoC's.
+
config I2C_PASEMI
tristate "PA Semi SMBus interface"
depends on PPC_PASEMI && PCI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 5a869144a0c5..b71618f77880 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_I2C_MXS) += i2c-mxs.o
obj-$(CONFIG_I2C_NOMADIK) += i2c-nomadik.o
obj-$(CONFIG_I2C_OCORES) += i2c-ocores.o
obj-$(CONFIG_I2C_OMAP) += i2c-omap.o
+obj-$(CONFIG_I2C_OWL) += i2c-owl.o
obj-$(CONFIG_I2C_PASEMI) += i2c-pasemi.o
obj-$(CONFIG_I2C_PCA_PLATFORM) += i2c-pca-platform.o
obj-$(CONFIG_I2C_PMCMSP) += i2c-pmcmsp.o
diff --git a/drivers/i2c/busses/i2c-owl.c b/drivers/i2c/busses/i2c-owl.c
new file mode 100644
index ..144a249bf994
--- /dev/null
+++ b/drivers/i2c/busses/i2c-owl.c
@@ -0,0 +1,477 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Actions Semiconductor Owl SoC's I2C driver
+ *
+ * Copyright (c) 2014 Actions Semi Inc.
+ * Author: David Liu
+ *
+ * Copyright (c) 2018 Linaro Ltd.
+ * Author: Manivannan Sadhasivam
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* I2C registers */
+#define OWL_I2C_REG_CTL0x
+#define OWL_I2C_REG_CLKDIV 0x0004
+#define OWL_I2C_REG_STAT 0x0008
+#define OWL_I2C_REG_ADDR 0x000C
+#define OWL_I2C_REG_TXDAT 0x0010
+#define OWL_I2C_REG_RXDAT 0x0014
+#define OWL_I2C_REG_CMD0x0018
+#define OWL_I2C_REG_FIFOCTL0x001C
+#define OWL_I2C_REG_FIFOSTAT 0x0020
+#define OWL_I2C_REG_DATCNT 0x0024
+#define OWL_I2C_REG_RCNT 0x0028
+
+/* I2Cx_CTL Bit Mask */
+#define OWL_I2C_CTL_RB BIT(1)
+#define OWL_I2C_CTL_GBCC(x)(((x) & 0x3) << 2)
+#defineOWL_I2C_CTL_GBCC_NONE OWL_I2C_CTL_GBCC(0)
+#defineOWL_I2C_CTL_GBCC_START OWL_I2C_CTL_GBCC(1)
+#defineOWL_I2C_CTL_GBCC_STOP OWL_I2C_CTL_GBCC(2)
+#defineOWL_I2C_CTL_GBCC_RSTART OWL_I2C_CTL_GBCC(3)
+#define OWL_I2C_CTL_IRQE BIT(5)
+#define OWL_I2C_CTL_EN BIT(7)
+#define OWL_I2C_CTL_AE BIT(8)
+#define OWL_I2C_CTL_SHSM BIT(10)
+
+#define OWL_I2C_DIV_FACTOR(x) ((x) & 0xff)
+
+/* I2Cx_STAT Bit Mask */
+#define OWL_I2C_STAT_RACK BIT(0)
+#define OWL_I2C_STAT_BEB BIT(1)
+#define OWL_I2C_STAT_IRQP BIT(2)
+#define OWL_I2C_STAT_LAB BIT(3)
+#define OWL_I2C_STAT_STPD BIT(4)
+#define OWL_I2C_STAT_STAD BIT(5)
+#define OWL_I2C_STAT_BBB BIT(6)
+#define OWL_I2C_STAT_TCB BIT(7)
+#define OWL_I2C_STAT_LBST BIT(8)
+#define OWL_I2C_STAT_SAMB BIT(9)
+#define OWL_I2C_STAT_SRGC BIT(10)
+
+/* I2Cx_CMD Bit Mask */
+#define OWL_I2C_CMD_SBEBIT(0)
+#define OWL_I2C_CMD_RBEBIT(4)
+#define OWL_I2C_CMD_DE BIT(8)
+#define OWL_I2C_CMD_NS BIT(9)
+#define OWL_I2C_CMD_SE BIT(10)
+#define OWL_I2C_CMD_MSSBIT(11)
+#define OWL_I2C_CMD_WRSBIT(12)
+#define OWL_I2C_CMD_SECL BIT(15)
+
+#define OWL_I2C_CMD_AS(x) (((x) & 0x7) << 1)
+#define OWL_I2C_CMD_SAS(x) (((x) & 0x7) << 5)
+
+/* I2Cx_FIFOCTL Bit Mask */
+#define OWL_I2C_FIFOCTL_NIBBIT(0)
+#define OWL_I2C_FIFOCTL_RFRBIT(1)
+#define OWL_I2C_FIFOCTL_TFRBIT(2)
+
+/* I2Cc_FIFOSTAT Bit Mask */
+#define OWL_I2C_FIFOSTAT_RNB BIT(1)
+#define OWL_I2C_FIFOSTAT_RFE BIT(2)
+#define OWL_I2C_FIFOSTAT_TFF BIT(5)
+#define OWL_I2C_FIFOSTAT_TFD GENMASK(23, 16)
+#define OWL_I2C_FIFOSTAT_RFD GENMASK(15, 8)
+
+/* I2C bus timeout */
+#define OWL_I2C_TIMEOUTmsecs_to_jiffies(4 * 1000)
+
+#define OWL_I2C_MAX_RETRIES50
+
+#define OWL_I2C_DEF_SPEED_HZ 10
+#define OWL_I2C_MAX_SPEED_HZ 40
+
+struct owl_i2c_dev {
+ struct i2c_adapter adap;
+ struct i2c_msg *msg;
+ struct completion msg_complete;
+ struct clk *clk;
+ void __iomem*base;
+ unsigned long clk_rate;
+ u32 bus_freq;
+ u32 msg_ptr
[PATCH v3 6/6] MAINTAINERS: Add entry for Actions Semiconductor Owl I2C driver
Add entry for Actions Semiconductor Owl I2C driver under ARM/ACTIONS Signed-off-by: Manivannan Sadhasivam --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 09b54e9ebc6f..5084c62712fa 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1145,12 +1145,14 @@ F: arch/arm/boot/dts/owl-* F: arch/arm64/boot/dts/actions/ F: drivers/clk/actions/ F: drivers/clocksource/owl-* +F: drivers/i2c/busses/i2c-owl.c F: drivers/pinctrl/actions/* F: drivers/soc/actions/ F: include/dt-bindings/power/owl-* F: include/linux/soc/actions/ F: Documentation/devicetree/bindings/arm/actions.txt F: Documentation/devicetree/bindings/clock/actions,s900-cmu.txt +F: Documentation/devicetree/bindings/i2c/i2c-owl.txt F: Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt F: Documentation/devicetree/bindings/power/actions,owl-sps.txt F: Documentation/devicetree/bindings/timer/actions,owl-timer.txt -- 2.17.1
Re: [PATCH v7] drivers/staging: Gasket driver framework + Apex driver
> The Gasket (Google ASIC Software, Kernel Extensions, and Tools) kernel > framework is a generic, flexible system that supports thin kernel > drivers. Gasket kernel drivers are expected to handle opening and > closing devices, mmap'ing BAR space as requested, a small selection of > ioctls, and handling page table translation (covered below). Any other > functions should be handled by userspace code. So it seems to me that we shouldn't have one random layer for Google ASIC, another chunk of code for FPGA and so on. This all really ought to be unified including where possible making things meaningfully self describe. You also don't seem to consider partitioning of an ASIC, eg if it implements a serial port abstraction for debug that ought to routed to the kernel, nor how to handle an ASIC that provides services to multiple consumers ? > One of the core assumptions of the Gasket framework is that precisely > one process is allowed to have an open write handle to the device node > at any given time. (That process may, once it has one write handle, open Why ? That's a very un-Linuxlike and un-Unixlike model. It's more like Windows and with all the problems we know that model causes. > any number of additional write handles.) This is accomplished by > tracking open and close data for each driver instance. What if I want to have multiple threads not sharing an mm, or pass an ASIC by handle to another instance - eg if I have a master process assigning resources wanting to pass a handle into a container ? And what about fd passing ? It seems completely weird to try and do this given I can (given permissions) equally just ptrace the person with it open and use ptrace as a multiplexor ??? Also how about pointers to a real world use case example and user space ? Alan
[GIT PULL] Kbuild fixes for v4.18-rc3
Hi Linus, Please pull Kbuild fixes. Thanks! The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git tags/kbuild-fixes-v4.18 for you to fetch changes up to 73d1c580f92b203f4c3a189ee98c917c65712f7e: kconfig: loop boundary condition fix (2018-06-28 22:48:08 +0900) Kbuild fixes for v4.18 - introduce __diag_* macros and suppress -Wattribute-alias warnings from GCC 8 - fix stack protector test script for x86_64 - fix line number handling in Kconfig - document that '#' starts a comment in Kconfig - handle P_SYMBOL property in dump debugging of Kconfig - correct help message of LD_DEAD_CODE_DATA_ELIMINATION - fix occasional segmentation faults in Kconfig Arnd Bergmann (2): kbuild: add macro for controlling warnings to linux/compiler.h disable -Wattribute-alias warning for SYSCALL_DEFINEx() Dirk Gouders (2): kconfig: fix line numbers for if-entries in menu tree kconfig: handle P_SYMBOL in print_symbol() Jerry James (1): kconfig: loop boundary condition fix Masahiro Yamada (1): kbuild: reword help of LD_DEAD_CODE_DATA_ELIMINATION Paul Burton (1): powerpc: Remove -Wattribute-alias pragmas Randy Dunlap (1): kconfig: document Kconfig source file comments Sven Joachim (1): stack-protector: Fix test with 32-bit userland and CONFIG_64BIT=y Documentation/kbuild/kconfig-language.txt | 6 ++ arch/powerpc/kernel/pci_32.c | 4 arch/powerpc/kernel/pci_64.c | 4 arch/powerpc/kernel/rtas.c| 4 arch/powerpc/kernel/signal_32.c | 8 arch/powerpc/kernel/signal_64.c | 4 arch/powerpc/kernel/syscalls.c| 4 arch/powerpc/mm/subpage-prot.c| 4 include/linux/compat.h| 8 +++- include/linux/compiler-gcc.h | 25 + include/linux/compiler_types.h| 18 ++ include/linux/syscalls.h | 4 init/Kconfig | 7 +++ scripts/gcc-x86_64-has-stack-protector.sh | 2 +- scripts/kconfig/expr.h| 3 +++ scripts/kconfig/preprocess.c | 2 +- scripts/kconfig/zconf.y | 8 ++-- 17 files changed, 74 insertions(+), 41 deletions(-) -- Best Regards Masahiro Yamada
Re: [PATCH v4] kconfig: check for pkg-config on make {menu,n,g,x}config
2018-06-29 8:39 GMT+09:00 Randy Dunlap :
> From: Randy Dunlap
>
> Each of 'make {menu,n,g,x}config' uses (needs) pkg-config to make sure
> that other required files are present and to determine build flags
> settings, but none of these check that pkg-config itself is present.
> Add a check for all 4 of these targets and update
> Documentation/process/changes.rst to mention 'pkg-config'.
>
> Fixes kernel bugzilla #77511:
> https://bugzilla.kernel.org/show_bug.cgi?id=77511
>
> Signed-off-by: Randy Dunlap
> Cc: Bjørn Forsman
> ---
Applied to linux-kbuild/kconfig. Thanks!
> v4: apply Masahiro's suggestions
>
> Strictly speaking, pkg-config is not required if someone is only
> using 'make {menu,n}config' since there are fallbacks for those
> two targets.
>
> Documentation/process/changes.rst |8
> scripts/kconfig/Makefile |1 +
> scripts/kconfig/check-pkgconfig.sh |8
> 3 files changed, 17 insertions(+)
>
> --- linux-next-20180628.orig/scripts/kconfig/Makefile
> +++ linux-next-20180628/scripts/kconfig/Makefile
> @@ -215,6 +215,7 @@ $(obj)/zconf.tab.o: $(obj)/zconf.lex.c
>
> # check if necessary packages are available, and configure build flags
> define filechk_conf_cfg
> + $(CONFIG_SHELL) $(srctree)/scripts/kconfig/check-pkgconfig.sh; \
> $(CONFIG_SHELL) $<
> endef
>
> --- /dev/null
> +++ linux-next-20180628/scripts/kconfig/check-pkgconfig.sh
> @@ -0,0 +1,8 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0
> +# Check for pkg-config presence
> +
> +if [ -z $(command -v pkg-config) ]; then
> + echo "'make *config' requires 'pkg-config'. Please install it." 1>&2
> + exit 1
> +fi
> --- linux-next-20180628.orig/Documentation/process/changes.rst
> +++ linux-next-20180628/Documentation/process/changes.rst
> @@ -81,6 +81,14 @@ The build system has, as of 4.13, switch
> rather than incremental linking (`ld -r`) for built-in.a intermediate steps.
> This requires binutils 2.20 or newer.
>
> +pkg-config
> +--
> +
> +The build system, as of 4.18, requires pkg-config to check for installed
> +kconfig tools and to determine flags settings for use in
> +'make {menu,n,g,x}config'. Previously pkg-config was being used but not
> +verified or documented.
> +
> Flex
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" 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] PCI: Enable PASID when End-to-End TLP is supported by all bridges
On 6/29/2018 8:49 PM, Bjorn Helgaas wrote:
> On Tue, Jun 19, 2018 at 10:14:46PM -0400, Sinan Kaya wrote:
>> A PCIe endpoint carries the process address space identifier (PASID) in
>> the TLP prefix as part of the memory read/write transaction. The address
>> information in the TLP is relevant only for a given PASID context.
>>
>> An IOMMU takes PASID value and the address information from the
>> TLP to look up the physical address in the system.
>>
>> If a bridge drops the TLP prefix, the translation agent can resolve the
>> address to an incorrect location and cause data corruption. Prevent
>> this condition by requiring End-to-End TLP prefix to be supported on the
>> entire data path between the endpoint and the root port.
>
> PASID is an End-End TLP Prefix (PCIe r4.0, sec 6.20). Sec 2.2.10.2 says
>
> It is an error to receive a TLP with an End-End TLP Prefix by a
> Receiver that does not support End-End TLP Prefixes. A TLP in
> violation of this rule is handled as a Malformed TLP. This is a
> reported error associated with the Receiving Port (see Section 6.2).
>
> So I agree that we shouldn't enable PASID in an endpoint unless all
> the switch ports leading to it support End-End prefixes. But I don't
> see how a bridge can drop a prefix and cause data corruption -- if it
> doesn't support End-End prefixes, shouldn't the bridge raise a
> Malformed TLP error instead of forwarding the TLP?
It should under normal circumstances.
I remember reading that most PCIe switches don't support TLP prefixes.
I don't know if it is because of buggy behavior or if it is just plain
unsupported while dropping the request as Malformed TLP.
I was trying to be proactive and not enable PASID if the entire path
is incapable.
>
>> Signed-off-by: Sinan Kaya
>> ---
>> drivers/pci/ats.c | 9 +
>> drivers/pci/probe.c | 17 +
>> include/linux/pci.h | 1 +
>> include/uapi/linux/pci_regs.h | 1 +
>> 4 files changed, 28 insertions(+)
>>
>> diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
>> index 4923a2a..e1b2e6d 100644
>> --- a/drivers/pci/ats.c
>> +++ b/drivers/pci/ats.c
>> @@ -268,6 +268,7 @@ EXPORT_SYMBOL_GPL(pci_reset_pri);
>> int pci_enable_pasid(struct pci_dev *pdev, int features)
>> {
>> u16 control, supported;
>> +struct pci_dev *bridge;
>> int pos;
>>
>> if (WARN_ON(pdev->pasid_enabled))
>> @@ -277,6 +278,14 @@ int pci_enable_pasid(struct pci_dev *pdev, int features)
>> if (!pos)
>> return -EINVAL;
>>
>> +bridge = pci_upstream_bridge(pdev);
>> +while (bridge) {
>> +if (!bridge->eetlp_prefix)
>> +return -EINVAL;
>> +
>> +bridge = pci_upstream_bridge(bridge);
>> +}
>
> I was hoping to avoid even this loop by having the eetlp_prefix bit
> indicate that "End-End TLP Prefixes are supported from the Root Port
> to here".
>
I see.
>> pci_read_config_word(pdev, pos + PCI_PASID_CAP, &supported);
>> supported &= PCI_PASID_CAP_EXEC | PCI_PASID_CAP_PRIV;
>>
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index ac876e3..a7f7ac1 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -2042,6 +2042,22 @@ static void pci_configure_ltr(struct pci_dev *dev)
>> #endif
>> }
>>
>> +static void pci_configure_eetlp_prefix(struct pci_dev *dev)
>> +{
>> +#ifdef CONFIG_PCI_PASID
>> +u32 cap;
>> +
>> +if (!pci_is_pcie(dev))
>> +return;
>> +
>> +pcie_capability_read_dword(dev, PCI_EXP_DEVCAP2, &cap);
>> +if (!(cap & PCI_EXP_DEVCAP2_E2ETLP))
>> +return;
>> +
>> +dev->eetlp_prefix = 1;
>
> I.e., here we would do:
>
> if (pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT)
> dev->eetlp_prefix_path = 1;
> else {
> bridge = pci_upstream_bridge(dev);
> if (bridge && bridge->eetlp_prefix_path)
> dev->eetlp_prefix_path = 1;
> }
Sure, let me make the changes and post a new version.
>
>> +#endif
>> +}
>> +
>> static void pci_configure_device(struct pci_dev *dev)
>> {
>> struct hotplug_params hpp;
>> @@ -2051,6 +2067,7 @@ static void pci_configure_device(struct pci_dev *dev)
>> pci_configure_extended_tags(dev, NULL);
>> pci_configure_relaxed_ordering(dev);
>> pci_configure_ltr(dev);
>> +pci_configure_eetlp_prefix(dev);
>>
>> memset(&hpp, 0, sizeof(hpp));
>> ret = pci_get_hp_params(dev, &hpp);
>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>> index 340029b..cf88d47 100644
>> --- a/include/linux/pci.h
>> +++ b/include/linux/pci.h
>> @@ -350,6 +350,7 @@ struct pci_dev {
>> unsigned intltr_path:1; /* Latency Tolerance Reporting
>> supported from root to here */
>> #endif
>> +unsigned inteetlp_prefix:1; /* End-to-End TLP Prefix */
>>
>> pci_channel_state_t error_state;/* Current connectivity state */
>> struct device dev;/* Gener
[PATCH] staging: rtl8188eu: remove rtw_ioctl_rtl.h
The header rtw_ioctl_rtl.h is not used anywhere. Running 'grep -r rtw_ioctl_rtl *' from kernel root directory returns nothing, remove the file. Signed-off-by: Michael Straube --- .../staging/rtl8188eu/include/rtw_ioctl_rtl.h | 66 --- 1 file changed, 66 deletions(-) delete mode 100644 drivers/staging/rtl8188eu/include/rtw_ioctl_rtl.h diff --git a/drivers/staging/rtl8188eu/include/rtw_ioctl_rtl.h b/drivers/staging/rtl8188eu/include/rtw_ioctl_rtl.h deleted file mode 100644 index e29ebfd40a58.. --- a/drivers/staging/rtl8188eu/include/rtw_ioctl_rtl.h +++ /dev/null @@ -1,66 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -/** - * - * Copyright(c) 2007 - 2011 Realtek Corporation. All rights reserved. - * - **/ -#ifndef _RTW_IOCTL_RTL_H_ -#define _RTW_IOCTL_RTL_H_ - -#include -#include - -/* oid_rtl_seg_01_01 ** */ -int oid_rt_get_signal_quality_hdl(struct oid_par_priv *poid_par_priv);/* 84 */ -int oid_rt_get_small_packet_crc_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_get_middle_packet_crc_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_get_large_packet_crc_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_get_tx_retry_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_get_rx_retry_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_get_rx_total_packet_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_get_tx_beacon_ok_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_get_tx_beacon_err_hdl(struct oid_par_priv *poid_par_priv); - -int oid_rt_pro_set_fw_dig_state_hdl(struct oid_par_priv *poid_par_priv);/* 8a */ -int oid_rt_pro_set_fw_ra_state_hdl(struct oid_par_priv *poid_par_priv); /* 8b */ - -int oid_rt_get_rx_icv_err_hdl(struct oid_par_priv *poid_par_priv);/* 93 */ -int oid_rt_set_encryption_algorithm_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_get_preamble_mode_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_get_ap_ip_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_get_channelplan_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_set_channelplan_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_set_preamble_mode_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_set_bcn_intvl_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_dedicate_probe_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_get_total_tx_bytes_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_get_total_rx_bytes_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_current_tx_power_level_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_get_enc_key_mismatch_count_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_get_enc_key_match_count_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_get_channel_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_get_hardware_radio_off_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_get_key_mismatch_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_supported_wireless_mode_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_get_channel_list_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_get_scan_in_progress_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_forced_data_rate_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_wireless_mode_for_scan_list_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_get_bss_wireless_mode_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_scan_with_magic_packet_hdl(struct oid_par_priv *poid_par_priv); - -/* oid_rtl_seg_01_03 section start ** */ -int oid_rt_ap_get_associated_station_list_hdl(struct oid_par_priv *priv); -int oid_rt_ap_switch_into_ap_mode_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_ap_supported_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_ap_set_passphrase_hdl(struct oid_par_priv *poid_par_priv); - -/* oid_rtl_seg_01_11 */ -int oid_rt_pro_rf_write_registry_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_pro_rf_read_registry_hdl(struct oid_par_priv *poid_par_priv); - -/* oid_rtl_seg_03_00 section start ** */ -int oid_rt_get_connect_state_hdl(struct oid_par_priv *poid_par_priv); -int oid_rt_set_default_key_id_hdl(struct oid_par_priv *poid_par_priv); - -#endif -- 2.18.0
[PATCH v2] staging:r8188eu: Use lib80211 to encrypt (WEP) tx frames
Put data to skb, decrypt with lib80211_crypt_wep, and place back to tx buffer.
---
v2:
- refactor error handling.
Signed-off-by: Ivan Safonov
---
drivers/staging/rtl8188eu/core/rtw_security.c | 82 +++
1 file changed, 47 insertions(+), 35 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c
b/drivers/staging/rtl8188eu/core/rtw_security.c
index 5b8d7288a4e7..a01290467c64 100644
--- a/drivers/staging/rtl8188eu/core/rtw_security.c
+++ b/drivers/staging/rtl8188eu/core/rtw_security.c
@@ -131,60 +131,72 @@ static __le32 getcrc32(u8 *buf, int len)
Need to consider the fragment situation
*/
void rtw_wep_encrypt(struct adapter *padapter, u8 *pxmitframe)
-{ /* exclude ICV */
-
- unsigned char crc[4];
- struct arc4context mycontext;
-
+{
int curfragnum, length;
- u32 keylength;
-
- u8 *pframe, *payload, *iv;/* wepkey */
- u8 wepkey[16];
- u8 hw_hdr_offset = 0;
+ u8 *pframe;
+ u8 hw_hdr_offset = 0;
struct pkt_attrib *pattrib = &((struct xmit_frame
*)pxmitframe)->attrib;
struct security_priv *psecuritypriv = &padapter->securitypriv;
struct xmit_priv *pxmitpriv = &padapter->xmitpriv;
-
+ const int keyindex = psecuritypriv->dot11PrivacyKeyIndex;
+ void *crypto_private;
+ struct sk_buff *skb;
+ struct lib80211_crypto_ops *crypto_ops;
if (((struct xmit_frame *)pxmitframe)->buf_addr == NULL)
return;
+ if ((pattrib->encrypt != _WEP40_) && (pattrib->encrypt != _WEP104_))
+ return;
+
hw_hdr_offset = TXDESC_SIZE +
(((struct xmit_frame *)pxmitframe)->pkt_offset *
PACKET_OFFSET_SZ);
pframe = ((struct xmit_frame *)pxmitframe)->buf_addr + hw_hdr_offset;
- /* start to encrypt each fragment */
- if ((pattrib->encrypt == _WEP40_) || (pattrib->encrypt == _WEP104_)) {
- keylength =
psecuritypriv->dot11DefKeylen[psecuritypriv->dot11PrivacyKeyIndex];
+ crypto_ops = try_then_request_module(lib80211_get_crypto_ops("WEP"),
"lib80211_crypt_wep");
- for (curfragnum = 0; curfragnum < pattrib->nr_frags;
curfragnum++) {
- iv = pframe+pattrib->hdrlen;
- memcpy(&wepkey[0], iv, 3);
- memcpy(&wepkey[3],
&psecuritypriv->dot11DefKey[psecuritypriv->dot11PrivacyKeyIndex].skey[0],
keylength);
- payload = pframe+pattrib->iv_len+pattrib->hdrlen;
+ if (!crypto_ops)
+ return;
- if ((curfragnum+1) == pattrib->nr_frags) { /* the
last fragment */
- length =
pattrib->last_txcmdsz-pattrib->hdrlen-pattrib->iv_len-pattrib->icv_len;
+ crypto_private = crypto_ops->init(keyindex);
+ if (!crypto_private)
+ return;
- *((__le32 *)crc) = getcrc32(payload, length);
+ if (crypto_ops->set_key(psecuritypriv->dot11DefKey[keyindex].skey,
+ psecuritypriv->dot11DefKeylen[keyindex], NULL,
crypto_private) < 0)
+ goto free_crypto_private;
- arcfour_init(&mycontext, wepkey, 3+keylength);
- arcfour_encrypt(&mycontext, payload, payload,
length);
- arcfour_encrypt(&mycontext, payload+length,
crc, 4);
- } else {
- length =
pxmitpriv->frag_len-pattrib->hdrlen-pattrib->iv_len-pattrib->icv_len;
- *((__le32 *)crc) = getcrc32(payload, length);
- arcfour_init(&mycontext, wepkey, 3+keylength);
- arcfour_encrypt(&mycontext, payload, payload,
length);
- arcfour_encrypt(&mycontext, payload+length,
crc, 4);
-
- pframe += pxmitpriv->frag_len;
- pframe = (u8 *)round_up((size_t)(pframe), 4);
- }
+ for (curfragnum = 0; curfragnum < pattrib->nr_frags; curfragnum++) {
+ if (curfragnum + 1 == pattrib->nr_frags)
+ length = pattrib->last_txcmdsz;
+ else
+ length = pxmitpriv->frag_len;
+ skb = dev_alloc_skb(length);
+ if (!skb)
+ goto free_crypto_private;
+
+ skb_put_data(skb, pframe, length);
+
+ memmove(skb->data + 4, skb->data, pattrib->hdrlen);
+ skb_pull(skb, 4);
+ skb_trim(skb, skb->len - 4);
+
+ if (crypto_ops->encrypt_mpdu(skb, pattrib->hdrlen,
crypto_private)) {
+ kfree_skb(skb);
+ goto free_crypto_private;
}
+
+ memcpy(pframe, skb->data, skb->len);
+
+
[PATCH 1/2] FBTFT: fb_sh: Fix alignment and style problems Fixed Coding style issues Signed-off-by: Tamir Suliman
---
drivers/staging/fbtft/fb_sh1106.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/fbtft/fb_sh1106.c
b/drivers/staging/fbtft/fb_sh1106.c
index 3fc18c0..c18763b 100644
--- a/drivers/staging/fbtft/fb_sh1106.c
+++ b/drivers/staging/fbtft/fb_sh1106.c
@@ -36,27 +36,27 @@ static int init_display(struct fbtft_par *par)
par->fbtftops.reset(par);
/* Set Display OFF */
- write_reg(par, 0xAE);
+ write_reg(par, 0xAE);
/* Set Display Clock Divide Ratio/ Oscillator Frequency */
- write_reg(par, 0xD5, 0x80);
+ write_reg(par, 0xD5, 0x80);
/* Set Multiplex Ratio */
- write_reg(par, 0xA8, par->info->var.yres - 1);
+ write_reg(par, 0xA8, par->info->var.yres - 1);
/* Set Display Offset */
- write_reg(par, 0xD3, 0x00);
+ write_reg(par, 0xD3, 0x00);
/* Set Display Start Line */
- write_reg(par, 0x40 | 0x0);
+ write_reg(par, 0x40 | 0x0);
/* Set Segment Re-map */
/* column address 127 is mapped to SEG0 */
- write_reg(par, 0xA0 | 0x1);
+ write_reg(par, 0xA0 | 0x1);
/* Set COM Output Scan Direction */
/* remapped mode. Scan from COM[N-1] to COM0 */
- write_reg(par, 0xC8);
+ write_reg(par, 0xC8);
/* Set COM Pins Hardware Configuration */
if (par->info->var.yres == 64)
@@ -70,15 +70,15 @@ static int init_display(struct fbtft_par *par)
write_reg(par, 0xDA, 0x02);
/* Set Pre-charge Period */
- write_reg(par, 0xD9, 0xF1);
+ write_reg(par, 0xD9, 0xF1);
/* Set VCOMH Deselect Level */
- write_reg(par, 0xDB, 0x40);
+ write_reg(par, 0xDB, 0x40);
/* Set Display ON */
- write_reg(par, 0xAF);
+ write_reg(par, 0xAF);
- msleep(150);
+ msleep(150);
return 0;
}
@@ -89,8 +89,8 @@ static void set_addr_win(struct fbtft_par *par, int xs, int
ys, int xe, int ye)
static int blank(struct fbtft_par *par, bool on)
{
- fbtft_par_dbg(DEBUG_BLANK, par, "%s(blank=%s)\n",
- __func__, on ? "true" : "false");
+ fbtft_par_dbg(DEBUG_BLANK, par, "%s(_func_=%s)\n",
+ __func__, on ? "true" : "false");
write_reg(par, on ? 0xAE : 0xAF);
--
1.8.3.1
[PATCH 2/2] NETLOGIC: Kconfig: Fixed help and coding style warnings
Fixed Coding style issues Signed-off-by: Tamir Suliman --- drivers/staging/netlogic/Kconfig | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/staging/netlogic/Kconfig b/drivers/staging/netlogic/Kconfig index d660de5..6e8e56a 100644 --- a/drivers/staging/netlogic/Kconfig +++ b/drivers/staging/netlogic/Kconfig @@ -2,6 +2,8 @@ config NETLOGIC_XLR_NET tristate "Netlogic XLR/XLS network device" depends on CPU_XLR select PHYLIB - ---help--- + help This driver support Netlogic XLR/XLS on chip gigabit - Ethernet. + Ethernet.The XLR/XLS NAE blocks can be configured as one 10G + interface or four 1G interfaces. This driver supports blocks + with 1G ports. -- 1.8.3.1
Re: [PATCH 4/5] iio: adc: ti_am335x_adc: Disable ADC during suspend unconditionally
On Sat, 30 Jun 2018 16:03:17 +0530
Vignesh R wrote:
> Parent MFD device takes care of enabling ADC interface whenever
> touchscreen is marked wakeup capable. Therefore, unconditionally disable
> ADC interface during system suspend to save power in case of system with
> just ADC and no TSC.
>
> Signed-off-by: Vignesh R
This sounds like a sensible change to me. Is it applicable without the
rest of the series? If so I'll take it through IIO. If the answer
is that it needs to go with the rest then
Acked-by: Jonathan Cameron
Thanks,
Jonathan
> ---
> drivers/iio/adc/ti_am335x_adc.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
> index 80df5a377d30..cafb1dcadc48 100644
> --- a/drivers/iio/adc/ti_am335x_adc.c
> +++ b/drivers/iio/adc/ti_am335x_adc.c
> @@ -693,16 +693,12 @@ static int __maybe_unused tiadc_suspend(struct device
> *dev)
> {
> struct iio_dev *indio_dev = dev_get_drvdata(dev);
> struct tiadc_device *adc_dev = iio_priv(indio_dev);
> - struct ti_tscadc_dev *tscadc_dev;
> unsigned int idle;
>
> - tscadc_dev = ti_tscadc_dev_get(to_platform_device(dev));
> - if (!device_may_wakeup(tscadc_dev->dev)) {
> - idle = tiadc_readl(adc_dev, REG_CTRL);
> - idle &= ~(CNTRLREG_TSCSSENB);
> - tiadc_writel(adc_dev, REG_CTRL, (idle |
> - CNTRLREG_POWERDOWN));
> - }
> + idle = tiadc_readl(adc_dev, REG_CTRL);
> + idle &= ~(CNTRLREG_TSCSSENB);
> + tiadc_writel(adc_dev, REG_CTRL, (idle |
> + CNTRLREG_POWERDOWN));
>
> return 0;
> }
[PATCH V3] PCI: Enable PASID when End-to-End TLP is supported by all bridges
A PCIe endpoint carries the process address space identifier (PASID) in
the TLP prefix as part of the memory read/write transaction. The address
information in the TLP is relevant only for a given PASID context.
An IOMMU takes PASID value and the address information from the
TLP to look up the physical address in the system.
PASID is an End-End TLP Prefix (PCIe r4.0, sec 6.20). Sec 2.2.10.2 says
It is an error to receive a TLP with an End-End TLP Prefix by a
Receiver that does not support End-End TLP Prefixes. A TLP in
violation of this rule is handled as a Malformed TLP. This is a
reported error associated with the Receiving Port (see Section 6.2).
Prevent error condition by proactively requiring End-to-End TLP
prefix to be supported on the entire data path between the endpoint and
the root port before enabling PASID.
Signed-off-by: Sinan Kaya
---
drivers/pci/ats.c | 3 +++
drivers/pci/probe.c | 24
include/linux/pci.h | 1 +
include/uapi/linux/pci_regs.h | 1 +
4 files changed, 29 insertions(+)
diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
index 4923a2a..5b78f3b 100644
--- a/drivers/pci/ats.c
+++ b/drivers/pci/ats.c
@@ -273,6 +273,9 @@ int pci_enable_pasid(struct pci_dev *pdev, int features)
if (WARN_ON(pdev->pasid_enabled))
return -EBUSY;
+ if (!pdev->eetlp_prefix_path)
+ return -EINVAL;
+
pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_PASID);
if (!pos)
return -EINVAL;
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index ac876e3..39fd3ac 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2042,6 +2042,29 @@ static void pci_configure_ltr(struct pci_dev *dev)
#endif
}
+static void pci_configure_eetlp_prefix(struct pci_dev *dev)
+{
+#ifdef CONFIG_PCI_PASID
+ struct pci_dev *bridge;
+ u32 cap;
+
+ if (!pci_is_pcie(dev))
+ return;
+
+ pcie_capability_read_dword(dev, PCI_EXP_DEVCAP2, &cap);
+ if (!(cap & PCI_EXP_DEVCAP2_E2ETLP))
+ return;
+
+ if (pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT)
+ dev->eetlp_prefix_path = 1;
+ else {
+ bridge = pci_upstream_bridge(dev);
+ if (bridge && bridge->eetlp_prefix_path)
+ dev->eetlp_prefix_path = 1;
+ }
+#endif
+}
+
static void pci_configure_device(struct pci_dev *dev)
{
struct hotplug_params hpp;
@@ -2051,6 +2074,7 @@ static void pci_configure_device(struct pci_dev *dev)
pci_configure_extended_tags(dev, NULL);
pci_configure_relaxed_ordering(dev);
pci_configure_ltr(dev);
+ pci_configure_eetlp_prefix(dev);
memset(&hpp, 0, sizeof(hpp));
ret = pci_get_hp_params(dev, &hpp);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 340029b..6ba8184 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -350,6 +350,7 @@ struct pci_dev {
unsigned intltr_path:1; /* Latency Tolerance Reporting
supported from root to here */
#endif
+ unsigned inteetlp_prefix_path:1;/* End-to-End TLP Prefix */
pci_channel_state_t error_state;/* Current connectivity state */
struct device dev;/* Generic device interface */
diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
index 4da87e2..a617ab2 100644
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -636,6 +636,7 @@
#define PCI_EXP_DEVCAP2_OBFF_MASK 0x000c /* OBFF support mechanism */
#define PCI_EXP_DEVCAP2_OBFF_MSG 0x0004 /* New message signaling */
#define PCI_EXP_DEVCAP2_OBFF_WAKE 0x0008 /* Re-use WAKE# for OBFF */
+#define PCI_EXP_DEVCAP2_E2ETLP 0x0020 /* End-to-End TLP Prefix */
#define PCI_EXP_DEVCTL240 /* Device Control 2 */
#define PCI_EXP_DEVCTL2_COMP_TIMEOUT 0x000f /* Completion Timeout Value */
#define PCI_EXP_DEVCTL2_COMP_TMOUT_DIS0x0010 /* Completion Timeout
Disable */
--
2.7.4
Re: [PATCH 1/3] IIO: st_accel_i2c.c: Use fallback if DT/ACPI enum failed
On Fri, 29 Jun 2018 10:10:10 +0200
Nikolaus Voss wrote:
> Currently, the driver bails out if not explicitly referred to in
> DT or ACPI tables. This prevents fallback mechanisms from coming
> into effect, e.g. I2C device ID table match via DT or ACPI
> PRP0001 HID. However DT/ACPI enum should take precedence over
> the fallback, so evaluate that first.
>
> Signed-off-by: Nikolaus Voss
Is the change to probe_new actually related to the rest of the change?
I can't immediately see why... If not I would prefer that as a separate
change.
> ---
> drivers/iio/accel/st_accel_i2c.c | 21 -
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/iio/accel/st_accel_i2c.c
> b/drivers/iio/accel/st_accel_i2c.c
> index 6bdec8c451e0..e360da407027 100644
> --- a/drivers/iio/accel/st_accel_i2c.c
> +++ b/drivers/iio/accel/st_accel_i2c.c
> @@ -138,8 +138,7 @@ static const struct i2c_device_id st_accel_id_table[] = {
> };
> MODULE_DEVICE_TABLE(i2c, st_accel_id_table);
>
> -static int st_accel_i2c_probe(struct i2c_client *client,
> - const struct i2c_device_id *id)
> +static int st_accel_i2c_probe(struct i2c_client *client)
> {
> struct iio_dev *indio_dev;
> struct st_sensor_data *adata;
> @@ -156,14 +155,18 @@ static int st_accel_i2c_probe(struct i2c_client *client,
>client->name, sizeof(client->name));
> } else if (ACPI_HANDLE(&client->dev)) {
> ret = st_sensors_match_acpi_device(&client->dev);
> - if ((ret < 0) || (ret >= ST_ACCEL_MAX))
> - return -ENODEV;
> -
> - strlcpy(client->name, st_accel_id_table[ret].name,
> + if ((ret >= 0) && (ret < ST_ACCEL_MAX))
> + strlcpy(client->name, st_accel_id_table[ret].name,
> sizeof(client->name));
> - } else if (!id)
> - return -ENODEV;
> + }
>
> + /*
> + * If OF and ACPI enumeration failed, there could still be platform
> + * information via fallback enumeration or explicit instantiation, so
> + * check if id table has been matched via client->name.
> + */
> + if (!client->name)
> + return -ENODEV;
>
> st_sensors_i2c_configure(indio_dev, client, adata);
>
> @@ -187,7 +190,7 @@ static struct i2c_driver st_accel_driver = {
> .of_match_table = of_match_ptr(st_accel_of_match),
> .acpi_match_table = ACPI_PTR(st_accel_acpi_match),
> },
> - .probe = st_accel_i2c_probe,
> + .probe_new = st_accel_i2c_probe,
> .remove = st_accel_i2c_remove,
> .id_table = st_accel_id_table,
> };
Re: [PATCH 3/3] IIO: st_accel.h: sync DT and I2C device ID table strings
On Fri, 29 Jun 2018 10:45:54 +0200
Nikolaus Voss wrote:
> I2C device ID table strings should really match the DT compatible
> strings (without the manufacturer prefix) to avoid confusion. This is
> especially reasonable when using ACPI PRP0001 HID /DT compatibility
> entries along with the DT compatible property in DSD which is
> used as a modalias (with manufacturer prefix stripped off) by the ACPI
> layer and thus as i2c_board_info->type by the I2C layer.
>
> Signed-off-by: Nikolaus Voss
Nice to have I agree. However, it's an ABI change as this is exposed
via
/sys/bus/iio/devices/iio:\deviceN/name and is used by lots of scripts
etc to identify the device. So we are stuck with it.
There is a reason we've kept this mess here for quite some time.
Jonathan
> ---
> drivers/iio/accel/st_accel.h | 32
> 1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/iio/accel/st_accel.h b/drivers/iio/accel/st_accel.h
> index 2f931e4837e5..be4a4a41f849 100644
> --- a/drivers/iio/accel/st_accel.h
> +++ b/drivers/iio/accel/st_accel.h
> @@ -37,23 +37,23 @@ enum st_accel_type {
> ST_ACCEL_MAX,
> };
>
> -#define H3LIS331DL_ACCEL_DEV_NAME"h3lis331dl_accel"
> -#define LIS3LV02DL_ACCEL_DEV_NAME"lis3lv02dl_accel"
> -#define LSM303DLHC_ACCEL_DEV_NAME"lsm303dlhc_accel"
> -#define LIS3DH_ACCEL_DEV_NAME"lis3dh"
> -#define LSM330D_ACCEL_DEV_NAME "lsm330d_accel"
> -#define LSM330DL_ACCEL_DEV_NAME "lsm330dl_accel"
> -#define LSM330DLC_ACCEL_DEV_NAME "lsm330dlc_accel"
> -#define LIS331DL_ACCEL_DEV_NAME "lis331dl_accel"
> -#define LIS331DLH_ACCEL_DEV_NAME "lis331dlh"
> -#define LSM303DL_ACCEL_DEV_NAME "lsm303dl_accel"
> -#define LSM303DLH_ACCEL_DEV_NAME "lsm303dlh_accel"
> -#define LSM303DLM_ACCEL_DEV_NAME "lsm303dlm_accel"
> -#define LSM330_ACCEL_DEV_NAME"lsm330_accel"
> -#define LSM303AGR_ACCEL_DEV_NAME "lsm303agr_accel"
> -#define LIS2DH12_ACCEL_DEV_NAME "lis2dh12_accel"
> +#define H3LIS331DL_ACCEL_DEV_NAME"h3lis331dl-accel"
> +#define LIS3LV02DL_ACCEL_DEV_NAME"lis3lv02dl-accel"
> +#define LSM303DLHC_ACCEL_DEV_NAME"lsm303dlhc-accel"
> +#define LIS3DH_ACCEL_DEV_NAME"lis3dh-accel"
> +#define LSM330D_ACCEL_DEV_NAME "lsm330d-accel"
> +#define LSM330DL_ACCEL_DEV_NAME "lsm330dl-accel"
> +#define LSM330DLC_ACCEL_DEV_NAME "lsm330dlc-accel"
> +#define LIS331DL_ACCEL_DEV_NAME "lis331dl-accel"
> +#define LIS331DLH_ACCEL_DEV_NAME "lis331dlh-accel"
> +#define LSM303DL_ACCEL_DEV_NAME "lsm303dl-accel"
> +#define LSM303DLH_ACCEL_DEV_NAME "lsm303dlh-accel"
> +#define LSM303DLM_ACCEL_DEV_NAME "lsm303dlm-accel"
> +#define LSM330_ACCEL_DEV_NAME"lsm330-accel"
> +#define LSM303AGR_ACCEL_DEV_NAME "lsm303agr-accel"
> +#define LIS2DH12_ACCEL_DEV_NAME "lis2dh12-accel"
> #define LIS3L02DQ_ACCEL_DEV_NAME "lis3l02dq"
> -#define LNG2DM_ACCEL_DEV_NAME"lng2dm"
> +#define LNG2DM_ACCEL_DEV_NAME"lng2dm-accel"
> #define LIS2DW12_ACCEL_DEV_NAME "lis2dw12"
> #define LIS3DHH_ACCEL_DEV_NAME "lis3dhh"
>
Re: [PATCH v4 1/2] iio: dac: Add AD5758 support
On Fri, 29 Jun 2018 11:38:36 +0300 Stefan Popa wrote: > The AD5758 is a single channel DAC with 16-bit precision which uses the > SPI interface that operates at clock rates up to 50MHz. > > The output can be configured as voltage or current and is available on a > single terminal. > > Datasheet: > http://www.analog.com/media/en/technical-documentation/data-sheets/ad5758.pdf > > Signed-off-by: Stefan Popa Hi Stefan, A few minors + the way you currently handle the choice of voltage vs current prevents you having multiple instances of this device with different settings. I would pick between between two constant options of the whole structure. Alternative would be to make a fresh copy of the structure for each instance of the device, but that is fiddlier for such a simple case. Jonathan > --- > Changes in v4: > - fixed kbuild test robot warnings. > Changes in v3: > - AD5758 can be both a current and voltage output DAC. The > decision is made based on the DT and the channel type is set > during probe. > - dc-dc-mode, range-microvolt and range-microamp are required > properties. > - Introduced a slew-time-us property from which slew rate clock > and slew rate step are calculated using a best match algorithm. > - Dropped the union from ad5758_state struct. > - Introduced a IIO_CHAN_INFO_OFFSET case part of ad5758_read_raw(). > - Added a TODO comment which specifies that CRC is not supported. > - Kept the includes in order and removed the unused ones. > - Removed unused macros and shortened the lengthy ones. > - Renamed AD5758_REG_WRITE to AD5758_WR_FLAG_MSK. > - Added an explanation for enum ad5758_output_range. > - Used bsearch() instead of ad5758_get_array_index(). > - Reduced the delays. > - strtobool() -> kstrtobool(). > > Changes in v2: > - removed unnecessary parenthesis in AD5758_REG_WRITE macro. > - added missing documentation fields of ad5758_state struct. > - changed the type of pwr_down attribute to bool. > - changed ad5758_dc_dc_ilimt[] to ad5758_dc_dc_ilim[]. > - ad5758_spi_reg_write() now returns spi_write(st->spi, > &st->data[0].d32, sizeof(st->data[0].d32)); > - removed unnecessary new line in ad5758_calib_mem_refresh(). > - changed the type of the mode parameter in > ad5758_set_dc_dc_conv_mode() from unsigned int to enum > ad5758_dc_dc_mode. > - removed unnecessary parenthesis in ad5758_slew_rate_config(). > - changed the type of the enable parameter in > ad5758_fault_prot_switch_en() from unsigned char to bool. > - the same as above, but for ad5758_internal_buffers_en(). > - added a missing mutex_unlock() in ad5758_reg_access(). > - moved the mutex_unlock() in ad5758_read_raw() and removed the > unreachable return. > - returned directly where it was possible in ad5758_write_raw(). > - removed the channel, scan_type and scan_index fields. > - in ad5758_parse_dt(), added missing "\n", and specified what the > default mode actually is. > - returned directly at the end of ad5758_init(). > - in ad5758_probe() used device managed for registering the device > and returned directly without the error message. > > MAINTAINERS | 7 + > drivers/iio/dac/Kconfig | 10 + > drivers/iio/dac/Makefile | 1 + > drivers/iio/dac/ad5758.c | 899 > +++ > 4 files changed, 917 insertions(+) > create mode 100644 drivers/iio/dac/ad5758.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index 00e9670..12d102d 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -796,6 +796,13 @@ M: Michael Hanselmann > S: Supported > F: drivers/macintosh/ams/ > > +ANALOG DEVICES INC AD5758 DRIVER > +M: Stefan Popa > +L: linux-...@vger.kernel.org > +W: http://ez.analog.com/community/linux-device-drivers > +S: Supported > +F: drivers/iio/dac/ad5758.c > + > ANALOG DEVICES INC AD5686 DRIVER > M: Stefan Popa > L: linux...@vger.kernel.org > diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig > index 06e90de..80beb64 100644 > --- a/drivers/iio/dac/Kconfig > +++ b/drivers/iio/dac/Kconfig > @@ -167,6 +167,16 @@ config AD5755 > To compile this driver as a module, choose M here: the > module will be called ad5755. > > +config AD5758 > + tristate "Analog Devices AD5758 DAC driver" > + depends on SPI_MASTER > + help > + Say yes here to build support for Analog Devices AD5758 single channel > + Digital to Analog Converter. > + > + To compile this driver as a module, choose M here: the > + module will be called ad5758. > + > config AD5761 > tristate "Analog Devices AD5761/61R/21/21R DAC driver" > depends on SPI_MASTER > diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile > index 57aa230.
Re: [PATCH v4 2/2] dt-bindings: iio: dac: Add docs for AD5758 DAC
On Fri, 29 Jun 2018 11:39:10 +0300
Stefan Popa wrote:
> Signed-off-by: Stefan Popa
One minor inline.
We could look at making some of these properties generic
(slew-time for example) but I'm not sure we fully understand
the 'space' yet to know exactly how this could be described
for all devices. Hence perhaps best to leave it as it is for now.
Jonathan
> ---
> Changes in v4:
> - Nothing changed, just to follow the patch set version.
> Changes in v3:
> - AD5758 can be both a current and voltage output DAC. The
> decision is made based on the DT and the channel type is set
> during probe.
> - range was replaced by range-microvolt and range-microamp
> - dc-dc-mode, range-microvolt and range-microamp are required
> properties.
> - Introduced a slew-time-us property from which slew rate clock
> and slew rate step are calculated using a best match algorithm.
> - Added units in the name of the properties.
> - Offered more explanation for the various modes of operation.
>
> Changes in v2:
> - Nothing changed, just to follow the patch set version.
>
> .../devicetree/bindings/iio/dac/ad5758.txt | 73
> ++
> MAINTAINERS| 1 +
> 2 files changed, 74 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/dac/ad5758.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/dac/ad5758.txt
> b/Documentation/devicetree/bindings/iio/dac/ad5758.txt
> new file mode 100644
> index 000..797df9b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/dac/ad5758.txt
> @@ -0,0 +1,73 @@
> +Analog Devices AD5758 DAC device driver
> +
> +Required properties for the AD5758:
> + - compatible: Must be "adi,ad5758"
> + - reg: SPI chip select number for the device
> + - spi-max-frequency: Max SPI frequency to use (< 5000)
> + - spi-cpha: is the only mode that is supported
> +
> +Required properties:
> +
> + - adi,dc-dc-mode: Mode of operation of the dc-to-dc converter
> +Dynamic Power Control (DPC)
> +In this mode, the AD5758 circuitry senses the output voltage
> and
> +dynamically regulates the supply voltage, VDPC+, to meet
> compliance
> +requirements plus an optimized headroom voltage for the
> output buffer.
> +
> +Programmable Power Control (PPC)
> +In this mode, the VDPC+ voltage is user-programmable to a
> fixed level
> +that needs to accommodate the maximum output load required.
> +
> +The output of the DAC core is either converted to a current
> or voltage
> +output at the VIOUT pin. Only one mode can be enabled at any
> one time.
> +
> +The following values are currently supported:
> + * 1: DPC current mode
> + * 2: DPC voltage mode
> + * 3: PPC current mode
> +
> + Depending on the selected output mode (voltage or current) one of the two
> properties must
> + be present:
> +
> + - adi,range-microvolt: Voltage output range
> + The array of voltage output ranges must contain two fields:
> + * <0 500>: 0 V to 5 V voltage range
> + * <0 1000>: 0 V to 10 V voltage range
> + * <(-500) 500>: ±5 V voltage range
> + * <(-1000) 1000>: ±10 V voltage range
> + - adi,range-microamp: Current output range
> + The array of current output ranges must contain two fields:
> + * <0 2>: 0 mA to 20 mA current range
> + * <0 24000>: 0 mA to 24 mA current range
> + * <4 24000>: 4 mA to 20 mA current range
> + * <(-2) 2>: ±20 mA current range
> + * <(-24000) 24000>: ±24 mA current range
> + * <(-1000) 22000>: −1 mA to +22 mA current range
> +
> +Optional properties:
> +
> + - adi,dc-dc-ilim-microamp: The dc-to-dc converter current limit
> +The following values are currently supported [uA]:
> + * 15
> + * 20
> + * 25
> + * 30
> + * 35
> + * 40
> +
> + - adi,slew-time-us: The time it takes for the output to reach the full
> scale [uS]
> + The supported range is between 133us up to 1023984375us
> +
> +AD5758 Example:
> +
> + ad5758@0 {
Node names should be generic - now we don't have dac in the device tree
spec but it feels like the right choice rather than the part number.
https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.2
> + compatible = "adi,ad5758";
> + reg = <0>;
> + spi-max-frequency = <100>;
> + spi-cpha;
> +
> + adi,dc-dc-mode = <2>;
> + adi,range-microvolt
Re: [PATCH 1/2] FBTFT: fb_sh: Fix alignment and style problems Fixed Coding style issues Signed-off-by: Tamir Suliman
On Sat, Jun 30, 2018 at 02:32:39PM +, Tamir Suliman wrote:
> ---
> drivers/staging/fbtft/fb_sh1106.c | 26 +-
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/staging/fbtft/fb_sh1106.c
> b/drivers/staging/fbtft/fb_sh1106.c
> index 3fc18c0..c18763b 100644
> --- a/drivers/staging/fbtft/fb_sh1106.c
> +++ b/drivers/staging/fbtft/fb_sh1106.c
> @@ -36,27 +36,27 @@ static int init_display(struct fbtft_par *par)
> par->fbtftops.reset(par);
>
> /* Set Display OFF */
> - write_reg(par, 0xAE);
> + write_reg(par, 0xAE);
>
> /* Set Display Clock Divide Ratio/ Oscillator Frequency */
> - write_reg(par, 0xD5, 0x80);
> + write_reg(par, 0xD5, 0x80);
>
> /* Set Multiplex Ratio */
> - write_reg(par, 0xA8, par->info->var.yres - 1);
> + write_reg(par, 0xA8, par->info->var.yres - 1);
>
> /* Set Display Offset */
> - write_reg(par, 0xD3, 0x00);
> + write_reg(par, 0xD3, 0x00);
>
> /* Set Display Start Line */
> - write_reg(par, 0x40 | 0x0);
> + write_reg(par, 0x40 | 0x0);
>
> /* Set Segment Re-map */
> /* column address 127 is mapped to SEG0 */
> - write_reg(par, 0xA0 | 0x1);
> + write_reg(par, 0xA0 | 0x1);
>
> /* Set COM Output Scan Direction */
> /* remapped mode. Scan from COM[N-1] to COM0 */
> - write_reg(par, 0xC8);
> + write_reg(par, 0xC8);
>
> /* Set COM Pins Hardware Configuration */
> if (par->info->var.yres == 64)
> @@ -70,15 +70,15 @@ static int init_display(struct fbtft_par *par)
> write_reg(par, 0xDA, 0x02);
>
> /* Set Pre-charge Period */
> - write_reg(par, 0xD9, 0xF1);
> + write_reg(par, 0xD9, 0xF1);
>
> /* Set VCOMH Deselect Level */
> - write_reg(par, 0xDB, 0x40);
> + write_reg(par, 0xDB, 0x40);
>
> /* Set Display ON */
> - write_reg(par, 0xAF);
> + write_reg(par, 0xAF);
>
> - msleep(150);
> + msleep(150);
>
> return 0;
> }
> @@ -89,8 +89,8 @@ static void set_addr_win(struct fbtft_par *par, int xs, int
> ys, int xe, int ye)
>
> static int blank(struct fbtft_par *par, bool on)
> {
> - fbtft_par_dbg(DEBUG_BLANK, par, "%s(blank=%s)\n",
> - __func__, on ? "true" : "false");
> + fbtft_par_dbg(DEBUG_BLANK, par, "%s(_func_=%s)\n",
> + __func__, on ? "true" : "false");
>
> write_reg(par, on ? 0xAE : 0xAF);
>
> --
> 1.8.3.1
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- Your patch does not have a Signed-off-by: line. Please read the
kernel file, Documentation/SubmittingPatches and resend it after
adding that line. Note, the line needs to be in the body of the
email, before the patch, not at the bottom of the patch or in the
email signature.
- Your patch did many different things all at once, making it difficult
to review. All Linux kernel patches need to only do one thing at a
time. If you need to do multiple things (such as clean up all coding
style issues in a file/driver), do it in a sequence of patches, each
one doing only one thing. This will make it easier to review the
patches to ensure that they are correct, and to help alleviate any
merge issues that larger patches can cause.
- You did not specify a description of why the patch is needed, or
possibly, any description at all, in the email body. Please read the
section entitled "The canonical patch format" in the kernel file,
Documentation/SubmittingPatches for what is needed in order to
properly describe the change.
- You did not write a descriptive Subject: for the patch, allowing Greg,
and everyone else, to know what this patch is all about. Please read
the section entitled "The canonical patch format" in the kernel file,
Documentation/SubmittingPatches for what a proper Subject: line should
look like.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
Re: [PATCH 2/2] NETLOGIC: Kconfig: Fixed help and coding style warnings
On Sat, Jun 30, 2018 at 02:30:44PM +, Tamir Suliman wrote: > Fixed Coding style issues > > Signed-off-by: Tamir Suliman > --- > drivers/staging/netlogic/Kconfig | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/netlogic/Kconfig > b/drivers/staging/netlogic/Kconfig > index d660de5..6e8e56a 100644 > --- a/drivers/staging/netlogic/Kconfig > +++ b/drivers/staging/netlogic/Kconfig > @@ -2,6 +2,8 @@ config NETLOGIC_XLR_NET > tristate "Netlogic XLR/XLS network device" > depends on CPU_XLR > select PHYLIB > - ---help--- > + help > This driver support Netlogic XLR/XLS on chip gigabit > - Ethernet. > + Ethernet.The XLR/XLS NAE blocks can be configured as one 10G > + interface or four 1G interfaces. This driver supports blocks > + with 1G ports. > -- > 1.8.3.1 Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - You did not specify a description of why the patch is needed, or possibly, any description at all, in the email body. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what is needed in order to properly describe the change. - You did not write a descriptive Subject: for the patch, allowing Greg, and everyone else, to know what this patch is all about. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what a proper Subject: line should look like. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot
Re: [PATCH 1/2] FBTFT: fb_sh: Fix alignment and style problems Fixed Coding style issues Signed-off-by: Tamir Suliman
On Sat, 2018-06-30 at 14:32 +, Tamir Suliman wrote:
> ---
> drivers/staging/fbtft/fb_sh1106.c | 26 +-
> 1 file changed, 13 insertions(+), 13 deletions(-)
Adding to what Greg's patchbot already wrote:
> diff --git a/drivers/staging/fbtft/fb_sh1106.c
> b/drivers/staging/fbtft/fb_sh1106.c
[]
> @@ -36,27 +36,27 @@ static int init_display(struct fbtft_par *par)
> par->fbtftops.reset(par);
>
> /* Set Display OFF */
> - write_reg(par, 0xAE);
> + write_reg(par, 0xAE);
Nope.
You are overly indenting already correctly indented code.
Statements start in the same column unless following an
if/for/do/while/else/case.
> @@ -89,8 +89,8 @@ static void set_addr_win(struct fbtft_par *par, int xs, int
> ys, int xe, int ye)
>
> static int blank(struct fbtft_par *par, bool on)
> {
> - fbtft_par_dbg(DEBUG_BLANK, par, "%s(blank=%s)\n",
> - __func__, on ? "true" : "false");
> + fbtft_par_dbg(DEBUG_BLANK, par, "%s(_func_=%s)\n",
> + __func__, on ? "true" : "false");
Again, nope.
Here you are misaligning a multi-line continuation
which is correctly aligned to the open parenthesis.
[PATCH v11 2/2] Add the missing information in dump_header
From: yuzhoujian
Add a new func mem_cgroup_print_oom_context to print missing information
for the system-wide oom report which includes the oom memcg that has
reached its limit, task memcg that contains the killed task.
Signed-off-by: yuzhoujian
---
include/linux/memcontrol.h | 15 ---
mm/memcontrol.c| 36 ++--
mm/oom_kill.c | 10 ++
3 files changed, 40 insertions(+), 21 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 6c6fb116e925..90855880bca2 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -491,8 +492,10 @@ void mem_cgroup_handle_over_high(void);
unsigned long mem_cgroup_get_max(struct mem_cgroup *memcg);
-void mem_cgroup_print_oom_info(struct mem_cgroup *memcg,
- struct task_struct *p);
+void mem_cgroup_print_oom_context(struct mem_cgroup *memcg,
+ struct task_struct *p);
+
+void mem_cgroup_print_oom_meminfo(struct mem_cgroup *memcg);
static inline void mem_cgroup_oom_enable(void)
{
@@ -903,7 +906,13 @@ static inline unsigned long mem_cgroup_get_max(struct
mem_cgroup *memcg)
}
static inline void
-mem_cgroup_print_oom_info(struct mem_cgroup *memcg, struct task_struct *p)
+mem_cgroup_print_oom_context(struct mem_cgroup *memcg,
+ struct task_struct *p)
+{
+}
+
+static inline void
+mem_cgroup_print_oom_meminfo(struct mem_cgroup *memcg)
{
}
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index e6f0d5ef320a..18deea974cfd 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1119,32 +1119,40 @@ static const char *const memcg1_stat_names[] = {
#define K(x) ((x) << (PAGE_SHIFT-10))
/**
- * mem_cgroup_print_oom_info: Print OOM information relevant to memory
controller.
- * @memcg: The memory cgroup that went over limit
+ * mem_cgroup_print_oom_context: Print OOM context information relevant to
+ * memory controller.
+ * @memcg: The origin memory cgroup that went over limit
* @p: Task that is going to be killed
*
* NOTE: @memcg and @p's mem_cgroup can be different when hierarchy is
* enabled
*/
-void mem_cgroup_print_oom_info(struct mem_cgroup *memcg, struct task_struct *p)
+void mem_cgroup_print_oom_context(struct mem_cgroup *memcg, struct task_struct
*p)
{
- struct mem_cgroup *iter;
- unsigned int i;
+ struct cgroup *origin_cgrp, *kill_cgrp;
rcu_read_lock();
-
+ if (memcg) {
+ pr_cont(",oom_memcg=");
+ pr_cont_cgroup_path(memcg->css.cgroup);
+ } else
+ pr_cont(",global_oom");
if (p) {
- pr_info("Task in ");
+ pr_cont(",task_memcg=");
pr_cont_cgroup_path(task_cgroup(p, memory_cgrp_id));
- pr_cont(" killed as a result of limit of ");
- } else {
- pr_info("Memory limit reached of cgroup ");
}
-
- pr_cont_cgroup_path(memcg->css.cgroup);
- pr_cont("\n");
-
rcu_read_unlock();
+}
+
+/**
+ * mem_cgroup_print_oom_meminfo: Print OOM memory information relevant to
+ * memory controller.
+ * @memcg: The memory cgroup that went over limit
+ */
+void mem_cgroup_print_oom_meminfo(struct mem_cgroup *memcg)
+{
+ struct mem_cgroup *iter;
+ unsigned int i;
pr_info("memory: usage %llukB, limit %llukB, failcnt %lu\n",
K((u64)page_counter_read(&memcg->memory)),
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index f9b08e455fd1..e990c45d2e7d 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -424,12 +424,14 @@ static void dump_header(struct oom_control *oc, struct
task_struct *p)
dump_stack();
/* one line summary of the oom killer context. */
- pr_info("oom-kill:constraint=%s,nodemask=%*pbl,task=%s,pid=%5d,uid=%5d",
+ pr_info("oom-kill:constraint=%s,nodemask=%*pbl",
oom_constraint_text[oc->constraint],
- nodemask_pr_args(oc->nodemask),
- p->comm, p->pid, from_kuid(&init_user_ns, task_uid(p)));
+ nodemask_pr_args(oc->nodemask));
+ mem_cgroup_print_oom_context(oc->memcg, p);
+ pr_cont(",task=%s,pid=%5d,uid=%5d\n", p->comm, p->pid,
+ from_kuid(&init_user_ns, task_uid(p)));
if (is_memcg_oom(oc))
- mem_cgroup_print_oom_info(oc->memcg, p);
+ mem_cgroup_print_oom_meminfo(oc->memcg);
else {
show_mem(SHOW_MEM_FILTER_NODES, oc->nodemask);
if (is_dump_unreclaim_slabs())
--
2.14.1
[PATCH v11 1/2] Refactor part of the oom report in dump_header
From: yuzhoujian The current system wide oom report prints information about the victim and the allocation context and restrictions. It, however, doesn't provide any information about memory cgroup the victim belongs to. This information can be interesting for container users because they can find the victim's container much more easily. I follow the advices of David Rientjes and Michal Hocko, and refactor part of the oom report. After this patch, users can get the memcg's path from the oom report and check the certain container more quickly. The oom print info after this patch: oom-kill:constraint=,nodemask=,oom_memcg=,task_memcg=,task=,pid=,uid= Signed-off-by: yuzhoujian --- Below is the part of the oom report in the dmesg ... [ 126.168182] panic invoked oom-killer: gfp_mask=0x6280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), order=0, oom_score_adj=0 [ 126.169115] panic cpuset=/ mems_allowed=0-1 [ 126.169806] CPU: 23 PID: 8668 Comm: panic Not tainted 4.18.0-rc2+ #36 [ 126.170494] Hardware name: Inspur SA5212M4/YZMB-00370-107, BIOS 4.1.10 11/14/2016 [ 126.171197] Call Trace: [ 126.171901] dump_stack+0x5a/0x73 [ 126.172593] dump_header+0x58/0x2dc [ 126.173294] oom_kill_process+0x228/0x420 [ 126.173999] ? oom_badness+0x2a/0x130 [ 126.174705] out_of_memory+0x11a/0x4a0 [ 126.175415] __alloc_pages_slowpath+0x7cc/0xa1e [ 126.176128] ? __alloc_pages_slowpath+0x194/0xa1e [ 126.176853] ? page_counter_try_charge+0x54/0xc0 [ 126.177580] __alloc_pages_nodemask+0x277/0x290 [ 126.178319] alloc_pages_vma+0x73/0x180 [ 126.179058] do_anonymous_page+0xed/0x5a0 [ 126.179825] __handle_mm_fault+0xbb3/0xe70 [ 126.180566] handle_mm_fault+0xfa/0x210 [ 126.181313] __do_page_fault+0x233/0x4c0 [ 126.182063] do_page_fault+0x32/0x140 [ 126.182812] ? page_fault+0x8/0x30 [ 126.183560] page_fault+0x1e/0x30 [ 126.184311] RIP: 0033:0x7f62c9e65860 [ 126.185059] Code: Bad RIP value. [ 126.185819] RSP: 002b:7ffcf7bc9288 EFLAGS: 00010206 [ 126.186589] RAX: 7f6209bd8000 RBX: RCX: 7f6236914000 [ 126.187383] RDX: 7f6249bd8000 RSI: RDI: 7f6209bd8000 [ 126.188179] RBP: 7ffcf7bc92b0 R08: R09: [ 126.188981] R10: 0022 R11: 0246 R12: 00400490 [ 126.189793] R13: 7ffcf7bc9390 R14: R15: [ 126.190619] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),global_oom,task_memcg=/test/test1/test2,task=panic,pid= 8673,uid=0 ... Changes since v10: - divide the patch v8 into two parts. One part is to add the array of const char and put enum oom_constaint into oom.h; the other adds a new func to print the missing information for the system- wide oom report. Changes since v9: - divide the patch v8 into two parts. One part is to move enum oom_constraint into memcontrol.h; the other refactors the output info in the dump_header. - replace orgin_memcg and kill_memcg with oom_memcg and task_memcg resptively. Changes since v8: - add the constraint in the oom_control structure. - put enum oom_constraint and constraint array into the oom.h file. - simplify the description for mem_cgroup_print_oom_context. Changes since v7: - add the constraint parameter to dump_header and oom_kill_process. - remove the static char array in the mem_cgroup_print_oom_context, and invoke pr_cont_cgroup_path to print memcg' name. - combine the patchset v6 into one. Changes since v6: - divide the patch v5 into two parts. One part is to add an array of const char and put enum oom_constraint into the memcontrol.h; the other refactors the output in the dump_header. - limit the memory usage for the static char array by using NAME_MAX in the mem_cgroup_print_oom_context. - eliminate the spurious spaces in the oom's output and fix the spelling of "constrain". Changes since v5: - add an array of const char for each constraint. - replace all of the pr_cont with a single line print of the pr_info. - put enum oom_constraint into the memcontrol.c file for printing oom constraint. Changes since v4: - rename the helper's name to mem_cgroup_print_oom_context. - rename the mem_cgroup_print_oom_info to mem_cgroup_print_oom_meminfo. - add the constrain info in the dump_header. Changes since v3: - rename the helper's name to mem_cgroup_print_oom_memcg_name. - add the rcu lock held to the helper. - remove the print info of memcg's name in mem_cgroup_print_oom_info. Changes since v2: - add the mem_cgroup_print_memcg_name helper to print the memcg's name which contains the task that will be killed by the oom-killer. Changes since v1: - replace adding mem_cgroup_print_oom_info with printing the memcg's name only. include/linux/oom.h | 17 + mm/oom_kill.c | 31 ++- 2 files changed, 31 insertions(+), 17 deletions(-) diff --git a/include/linux/oom.h b/include/linux/oom.h index 6adac113e96d..5bed78d4bfb8 100644 --- a/include/
Re: [PATCH] mm,oom: Bring OOM notifier callbacks to outside of OOM killer.
On Fri, Jun 29, 2018 at 03:26:38PM +0200, Michal Hocko wrote:
> On Fri 29-06-18 05:52:18, Paul E. McKenney wrote:
> > On Fri, Jun 29, 2018 at 11:04:19AM +0200, Michal Hocko wrote:
> > > On Thu 28-06-18 14:31:05, Paul E. McKenney wrote:
> > > > On Thu, Jun 28, 2018 at 01:39:42PM +0200, Michal Hocko wrote:
> [...]
> > > > > Well, I am not really sure what is the objective of the oom notifier
> > > > > to
> > > > > point you to the right direction. IIUC you just want to kick callbacks
> > > > > to be handled sooner under a heavy memory pressure, right? How is that
> > > > > achieved? Kick a worker?
> > > >
> > > > That is achieved by enqueuing a non-lazy callback on each CPU's callback
> > > > list, but only for those CPUs having non-empty lists. This causes
> > > > CPUs with lists containing only lazy callbacks to be more aggressive,
> > > > in particular, it prevents such CPUs from hanging out idle for seconds
> > > > at a time while they have callbacks on their lists.
> > > >
> > > > The enqueuing happens via an IPI to the CPU in question.
> > >
> > > I am afraid this is too low level for my to understand what is going on
> > > here. What are lazy callbacks and why do they need any specific action
> > > when we are getting close to OOM? I mean, I do understand that we might
> > > have many callers of call_rcu and free memory lazily. But there is quite
> > > a long way before we start the reclaim until we reach the OOM killer path.
> > > So why don't those callbacks get called during that time period? How are
> > > their triggered when we are not hitting the OOM path? They surely cannot
> > > sit there for ever, right? Can we trigger them sooner? Maybe the
> > > shrinker is not the best fit but we have a retry feedback loop in the page
> > > allocator, maybe we can kick this processing from there.
> >
> > The effect of RCU's current OOM code is to speed up callback invocation
> > by at most a few seconds (assuming no stalled CPUs, in which case
> > it is not possible to speed up callback invocation).
> >
> > Given that, I should just remove RCU's OOM code entirely?
>
> Yeah, it seems so. I do not see how this would really help much. If we
> really need some way to kick callbacks then we should do so much earlier
> in the reclaim process - e.g. when we start struggling to reclaim any
> memory.
One approach would be to tell RCU "It is time to trade CPU for memory"
at the beginning of that struggle and then tell RCU "Go back to optimizing
for CPU" at the end of that struggle. Is there already a way to do this?
If so, RCU should probably just switch to it.
But what is the typical duration of such a struggle? Does this duration
change with workload? (I suspect that the answers are "who knows?" and
"yes", but you tell me!) Are there other oom handlers that would prefer
the approach of the previous paragraph?
> I am curious. Has the notifier been motivated by a real world use case
> or it was "nice thing to do"?
It was introduced by b626c1b689364 ("rcu: Provide OOM handler to motivate
lazy RCU callbacks"). The motivation for this commit was a set of changes
that improved energy efficiency by making CPUs sleep for longer when all
of their pending callbacks were known to only free memory (as opposed
to doing a wakeup or some such). Prior to this set of changes, a CPU
with callbacks would invoke those callbacks (thus freeing the memory)
within a jiffy or so of the end of a grace period. After this set of
changes, a CPU might wait several seconds. This was a concern to people
with small-memory systems, hence commit b626c1b689364.
Thanx, Paul
Re: [PATCH] mm,oom: Bring OOM notifier callbacks to outside of OOM killer.
On Fri, Jun 29, 2018 at 11:35:48PM +0900, Tetsuo Handa wrote: > On 2018/06/29 21:52, Paul E. McKenney wrote: > > The effect of RCU's current OOM code is to speed up callback invocation > > by at most a few seconds (assuming no stalled CPUs, in which case > > it is not possible to speed up callback invocation). > > > > Given that, I should just remove RCU's OOM code entirely? > > out_of_memory() will start selecting an OOM victim without calling > get_page_from_freelist() since rcu_oom_notify() does not set non-zero > value to "freed" field. > > I think that rcu_oom_notify() needs to wait for completion of callback > invocations (possibly with timeout in case there are stalling CPUs) and > set non-zero value to "freed" field if pending callbacks did release memory. Waiting for the callbacks is easy. Timeouts would be a bit harder, but still doable. I have no idea how to tell which callbacks freed memory and how much -- all RCU does is invoke a function, and that function can do whatever its developer wants. > However, what will be difficult to tell is whether invocation of pending > callbacks > did release memory. Lack of last second get_page_from_freelist() call after > blocking_notifier_call_chain(&oom_notify_list, 0, &freed) forces > rcu_oom_notify() > to set appropriate value (i.e. zero or non-zero) to "freed" field. > > We have tried to move really last second get_page_from_freelist() call to > inside > out_of_memory() after blocking_notifier_call_chain(&oom_notify_list, 0, > &freed). > But that proposal was not accepted... > > We could move blocking_notifier_call_chain(&oom_notify_list, 0, &freed) to > before last second get_page_from_freelist() call (and this is what this patch > is trying to do) which would allow rcu_oom_notify() to always return 0... > or update rcu_oom_notify() to use shrinker API... Would it be possible to tell RCU that memory was starting to get tight with one call, and then tell it that things are OK with another call? That would make much more sense from an RCU perspective. Thanx, Paul
[PATCH] staging: mt7621-pinctrl: Replaces "unsigned" with "unsigned int", fixes mixed indentation, and puts spaces after commas.
Signed-off-by: Peter Vernia
---
drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c | 35 +
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
b/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
index 0c3e498..6894510 100644
--- a/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
+++ b/drivers/staging/mt7621-pinctrl/pinctrl-rt2880.c
@@ -54,7 +54,7 @@ static int rt2880_get_group_count(struct pinctrl_dev
*pctrldev)
}
static const char *rt2880_get_group_name(struct pinctrl_dev *pctrldev,
-unsigned group)
+unsigned int group)
{
struct rt2880_priv *p = pinctrl_dev_get_drvdata(pctrldev);
@@ -65,9 +65,9 @@ static const char *rt2880_get_group_name(struct pinctrl_dev
*pctrldev,
}
static int rt2880_get_group_pins(struct pinctrl_dev *pctrldev,
-unsigned group,
-const unsigned **pins,
-unsigned *num_pins)
+unsigned int group,
+const unsigned int **pins,
+unsigned int *num_pins)
{
struct rt2880_priv *p = pinctrl_dev_get_drvdata(pctrldev);
@@ -81,7 +81,8 @@ static int rt2880_get_group_pins(struct pinctrl_dev *pctrldev,
}
static void rt2880_pinctrl_dt_free_map(struct pinctrl_dev *pctrldev,
- struct pinctrl_map *map, unsigned num_maps)
+ struct pinctrl_map *map,
+ unsigned int num_maps)
{
int i;
@@ -94,7 +95,7 @@ static void rt2880_pinctrl_dt_free_map(struct pinctrl_dev
*pctrldev,
static void rt2880_pinctrl_pin_dbg_show(struct pinctrl_dev *pctrldev,
struct seq_file *s,
- unsigned offset)
+ unsigned int offset)
{
seq_printf(s, "ralink pio");
}
@@ -103,7 +104,7 @@ static void rt2880_pinctrl_dt_subnode_to_map(struct
pinctrl_dev *pctrldev,
struct device_node *np,
struct pinctrl_map **map)
{
-const char *function;
+ const char *function;
int func = of_property_read_string(np, "ralink,function", &function);
int grps = of_property_count_strings(np, "ralink,group");
int i;
@@ -112,7 +113,7 @@ static void rt2880_pinctrl_dt_subnode_to_map(struct
pinctrl_dev *pctrldev,
return;
for (i = 0; i < grps; i++) {
- const char *group;
+ const char *group;
of_property_read_string_index(np, "ralink,group", i, &group);
@@ -127,7 +128,7 @@ static void rt2880_pinctrl_dt_subnode_to_map(struct
pinctrl_dev *pctrldev,
static int rt2880_pinctrl_dt_node_to_map(struct pinctrl_dev *pctrldev,
struct device_node *np_config,
struct pinctrl_map **map,
- unsigned *num_maps)
+ unsigned int *num_maps)
{
int max_maps = 0;
struct pinctrl_map *tmp;
@@ -173,7 +174,7 @@ static int rt2880_pmx_func_count(struct pinctrl_dev
*pctrldev)
}
static const char *rt2880_pmx_func_name(struct pinctrl_dev *pctrldev,
-unsigned func)
+unsigned int func)
{
struct rt2880_priv *p = pinctrl_dev_get_drvdata(pctrldev);
@@ -181,7 +182,7 @@ static const char *rt2880_pmx_func_name(struct pinctrl_dev
*pctrldev,
}
static int rt2880_pmx_group_get_groups(struct pinctrl_dev *pctrldev,
- unsigned func,
+ unsigned int func,
const char * const **groups,
unsigned * const num_groups)
{
@@ -198,11 +199,11 @@ static int rt2880_pmx_group_get_groups(struct pinctrl_dev
*pctrldev,
}
static int rt2880_pmx_group_enable(struct pinctrl_dev *pctrldev,
- unsigned func,
- unsigned group)
+ unsigned int func,
+ unsigned int group)
{
struct rt2880_priv *p = pinctrl_dev_get_drvdata(pctrldev);
-u32 mode = 0;
+ u32 mode = 0;
u32 reg = SYSC_REG_GPIO_MODE;
int i;
int shift;
@@ -243,7 +244,7 @@ static int rt2880_pmx_group_enable(struct pinctrl_dev
*pctrldev,
static int rt2880_pmx_group_gpio_request_enable(struct pinctrl_dev *pctrldev,
struct pinctrl_gpio_range *range,
- unsigned pin)
+ unsigned int pin)
{
struct rt2880_priv *p = pinctrl_dev_get_drvdata(pctrldev);
@@ -355,13 +356,13 @@ static
Re: [PATCH v2] staging:iio:impedance-analyzer:ad5933: Macro replacement Cleanups.
On Mon, 25 Jun 2018 21:11:23 +0200
Karim Eshapa wrote:
> Doing some macro replacement to start an array of structures
> so it can be reused by manipulating it with different values.
>
> Signed-off-by: Karim Eshapa
There are all sorts of issues with the ABI this driver is providing to
userspace, but this isn't a bad bit of cleanup none the less.
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> .../staging/iio/impedance-analyzer/ad5933.c | 57 +++
> 1 file changed, 19 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c
> b/drivers/staging/iio/impedance-analyzer/ad5933.c
> index 3bcf49466361..14df89510396 100644
> --- a/drivers/staging/iio/impedance-analyzer/ad5933.c
> +++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
> @@ -116,45 +116,26 @@ static struct ad5933_platform_data ad5933_default_pdata
> = {
> .vref_mv = 3300,
> };
>
> +#define AD5933_CHANNEL(_type, _extend_name, _info_mask_separate, _address, \
> + _scan_index, _realbits) { \
> + .type = (_type), \
> + .extend_name = (_extend_name), \
> + .info_mask_separate = (_info_mask_separate), \
> + .address = (_address), \
> + .scan_index = (_scan_index), \
> + .scan_type = { \
> + .sign = 's', \
> + .realbits = (_realbits), \
> + .storagebits = 16, \
> + }, \
> +}
> +
> static const struct iio_chan_spec ad5933_channels[] = {
> - {
> - .type = IIO_TEMP,
> - .indexed = 1,
> - .channel = 0,
> - .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> - BIT(IIO_CHAN_INFO_SCALE),
> - .address = AD5933_REG_TEMP_DATA,
> - .scan_index = -1,
> - .scan_type = {
> - .sign = 's',
> - .realbits = 14,
> - .storagebits = 16,
> - },
> - }, { /* Ring Channels */
> - .type = IIO_VOLTAGE,
> - .indexed = 1,
> - .channel = 0,
> - .extend_name = "real",
> - .address = AD5933_REG_REAL_DATA,
> - .scan_index = 0,
> - .scan_type = {
> - .sign = 's',
> - .realbits = 16,
> - .storagebits = 16,
> - },
> - }, {
> - .type = IIO_VOLTAGE,
> - .indexed = 1,
> - .channel = 0,
> - .extend_name = "imag",
> - .address = AD5933_REG_IMAG_DATA,
> - .scan_index = 1,
> - .scan_type = {
> - .sign = 's',
> - .realbits = 16,
> - .storagebits = 16,
> - },
> - },
> + AD5933_CHANNEL(IIO_TEMP, NULL, BIT(IIO_CHAN_INFO_RAW) |
> + BIT(IIO_CHAN_INFO_SCALE), AD5933_REG_TEMP_DATA, -1, 14),
> + /* Ring Channels */
> + AD5933_CHANNEL(IIO_VOLTAGE, "real", 0, AD5933_REG_REAL_DATA, 0, 16),
> + AD5933_CHANNEL(IIO_VOLTAGE, "imag", 0, AD5933_REG_IMAG_DATA, 1, 16),
> };
>
> static int ad5933_i2c_write(struct i2c_client *client, u8 reg, u8 len, u8
> *data)
[PATCH v2 0/2] ASoC: add es7241 support
Add support for the es7241 which is a simple 2 channels analog to digital converter. Changes since v1: [0] * Add missing break as reported by smatch [1] My device is hardwired in slave mode, which probably why this slipped through unnoticed. [0]: https://lkml.kernel.org/r/20180629152444.21525-1-jbru...@baylibre.com [1]: https://lkml.kernel.org/r/20180630082829.qwnhkk4f76n32omm@mwanda Jerome Brunet (2): ASoC: es7241: add dt-bindings documentation for the es7241 adc ASoC: es7241: add es7241 codec support .../devicetree/bindings/sound/everest,es7241.txt | 23 ++ sound/soc/codecs/Kconfig | 4 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/es7241.c | 308 + 4 files changed, 337 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/everest,es7241.txt create mode 100644 sound/soc/codecs/es7241.c -- 2.14.4
[PATCH v2 1/2] ASoC: es7241: add dt-bindings documentation for the es7241 adc
Signed-off-by: Jerome Brunet
---
.../devicetree/bindings/sound/everest,es7241.txt | 23 ++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/everest,es7241.txt
diff --git a/Documentation/devicetree/bindings/sound/everest,es7241.txt
b/Documentation/devicetree/bindings/sound/everest,es7241.txt
new file mode 100644
index ..adee52281b3c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/everest,es7241.txt
@@ -0,0 +1,23 @@
+ES7134 i2s DA converter
+
+Required properties:
+- compatible : "everest,es7241"
+
+Optional properties:
+- VDDP-supply: regulator phandle for the VDDA supply
+- VDDA-supply: regulator phandle for the VDDP supply
+- VDDD-supply: regulator phandle for the VDDD supply
+- reset-gpios: gpio connected to the reset pin
+- m0-gpios : gpio connected to the m0 pin
+- m1-gpios : gpio connected to the m1 pin
+
+Example:
+
+linein: audio-codec@2 {
+ #sound-dai-cells = <0>;
+ compatible = "everest,es7241";
+ VDDA-supply = <&vcc_3v3>;
+ VDDP-supply = <&vcc_3v3>;
+ VDDD-supply = <&vcc_3v3>;
+ reset-gpios = <&gpio GPIOH_42>;
+};
--
2.14.4
[PATCH v2 2/2] ASoC: es7241: add es7241 codec support
Add support for the everest es7241 which is a simple 2 channels
analog to digital converter.
Signed-off-by: Jerome Brunet
---
sound/soc/codecs/Kconfig | 4 +
sound/soc/codecs/Makefile | 2 +
sound/soc/codecs/es7241.c | 308 ++
3 files changed, 314 insertions(+)
create mode 100644 sound/soc/codecs/es7241.c
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index f5839d5e..047ac28ba40f 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -79,6 +79,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_ES8328_SPI if SPI_MASTER
select SND_SOC_ES8328_I2C if I2C
select SND_SOC_ES7134
+ select SND_SOC_ES7241
select SND_SOC_GTM601
select SND_SOC_HDAC_HDMI
select SND_SOC_ICS43432
@@ -584,6 +585,9 @@ config SND_SOC_HDMI_CODEC
config SND_SOC_ES7134
tristate "Everest Semi ES7134 CODEC"
+config SND_SOC_ES7241
+ tristate "Everest Semi ES7241 CODEC"
+
config SND_SOC_ES8316
tristate "Everest Semi ES8316 CODEC"
depends on I2C
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 6cc15d1c5767..719653a4c882 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -71,6 +71,7 @@ snd-soc-da732x-objs := da732x.o
snd-soc-da9055-objs := da9055.o
snd-soc-dmic-objs := dmic.o
snd-soc-es7134-objs := es7134.o
+snd-soc-es7241-objs := es7241.o
snd-soc-es8316-objs := es8316.o
snd-soc-es8328-objs := es8328.o
snd-soc-es8328-i2c-objs := es8328-i2c.o
@@ -329,6 +330,7 @@ obj-$(CONFIG_SND_SOC_DA732X)+= snd-soc-da732x.o
obj-$(CONFIG_SND_SOC_DA9055) += snd-soc-da9055.o
obj-$(CONFIG_SND_SOC_DMIC) += snd-soc-dmic.o
obj-$(CONFIG_SND_SOC_ES7134) += snd-soc-es7134.o
+obj-$(CONFIG_SND_SOC_ES7241) += snd-soc-es7241.o
obj-$(CONFIG_SND_SOC_ES8316)+= snd-soc-es8316.o
obj-$(CONFIG_SND_SOC_ES8328) += snd-soc-es8328.o
obj-$(CONFIG_SND_SOC_ES8328_I2C)+= snd-soc-es8328-i2c.o
diff --git a/sound/soc/codecs/es7241.c b/sound/soc/codecs/es7241.c
new file mode 100644
index ..11958671aa80
--- /dev/null
+++ b/sound/soc/codecs/es7241.c
@@ -0,0 +1,308 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+//
+// Copyright (c) 2018 BayLibre, SAS.
+// Author: Jerome Brunet
+
+#include
+#include
+#include
+#include
+
+struct es7241_clock_mode {
+ unsigned int rate_min;
+ unsigned int rate_max;
+ unsigned int *slv_mfs;
+ unsigned int slv_mfs_num;
+ unsigned int mst_mfs;
+ unsigned int mst_m0:1;
+ unsigned int mst_m1:1;
+};
+
+struct es7241_chip {
+ const struct es7241_clock_mode *modes;
+ unsigned int mode_num;
+};
+
+struct es7241_data {
+ struct gpio_desc *reset;
+ struct gpio_desc *m0;
+ struct gpio_desc *m1;
+ unsigned int mclk;
+ bool is_slave;
+ const struct es7241_chip *chip;
+};
+
+static void es7241_set_mode(struct es7241_data *priv, int m0, int m1)
+{
+ /* put the device in reset */
+ gpiod_set_value_cansleep(priv->reset, 0);
+
+ /* set the mode */
+ gpiod_set_value_cansleep(priv->m0, m0);
+ gpiod_set_value_cansleep(priv->m1, m1);
+
+ /* take the device out of reset - datasheet does not specify a delay */
+ gpiod_set_value_cansleep(priv->reset, 1);
+}
+
+static int es7241_set_slave_mode(struct es7241_data *priv,
+const struct es7241_clock_mode *mode,
+unsigned int mfs)
+{
+ int j;
+
+ if (!mfs)
+ goto out_ok;
+
+ for (j = 0; j < mode->slv_mfs_num; j++) {
+ if (mode->slv_mfs[j] == mfs)
+ goto out_ok;
+ }
+
+ return -EINVAL;
+
+out_ok:
+ es7241_set_mode(priv, 1, 1);
+ return 0;
+}
+
+static int es7241_set_master_mode(struct es7241_data *priv,
+ const struct es7241_clock_mode *mode,
+ unsigned int mfs)
+{
+ /*
+* We can't really set clock ratio, if the mclk/lrclk is different
+* from what we provide, then error out
+*/
+ if (mfs && mfs != mode->mst_mfs)
+ return -EINVAL;
+
+ es7241_set_mode(priv, mode->mst_m0, mode->mst_m1);
+
+ return 0;
+}
+
+static int es7241_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params,
+ struct snd_soc_dai *dai)
+{
+ struct es7241_data *priv = snd_soc_dai_get_drvdata(dai);
+ unsigned int rate = params_rate(params);
+ unsigned int mfs = priv->mclk / rate;
+ int i;
+
+ for (i = 0; i < priv->chip->mode_num; i++) {
+ const struct es7241_clock_mode *mode = &priv->chip->modes[i];
+
+ if (rate < mode->rate_min || rate >= mode->rate_max)
+ continue;
+
+ if (priv->is_slave)
+ return es7241_set_sla
[PATCH v3] staging:r8188eu: Use lib80211 to encrypt (WEP) tx frames
Put data to skb, decrypt with lib80211_crypt_wep, and place back to tx buffer.
Signed-off-by: Ivan Safonov
---
v2:
- refactor error handling,
v3:
- fix commit message.
drivers/staging/rtl8188eu/core/rtw_security.c | 82 +++
1 file changed, 47 insertions(+), 35 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c
b/drivers/staging/rtl8188eu/core/rtw_security.c
index 5b8d7288a4e7..a01290467c64 100644
--- a/drivers/staging/rtl8188eu/core/rtw_security.c
+++ b/drivers/staging/rtl8188eu/core/rtw_security.c
@@ -131,60 +131,72 @@ static __le32 getcrc32(u8 *buf, int len)
Need to consider the fragment situation
*/
void rtw_wep_encrypt(struct adapter *padapter, u8 *pxmitframe)
-{ /* exclude ICV */
-
- unsigned char crc[4];
- struct arc4context mycontext;
-
+{
int curfragnum, length;
- u32 keylength;
-
- u8 *pframe, *payload, *iv;/* wepkey */
- u8 wepkey[16];
- u8 hw_hdr_offset = 0;
+ u8 *pframe;
+ u8 hw_hdr_offset = 0;
struct pkt_attrib *pattrib = &((struct xmit_frame
*)pxmitframe)->attrib;
struct security_priv *psecuritypriv = &padapter->securitypriv;
struct xmit_priv *pxmitpriv = &padapter->xmitpriv;
-
+ const int keyindex = psecuritypriv->dot11PrivacyKeyIndex;
+ void *crypto_private;
+ struct sk_buff *skb;
+ struct lib80211_crypto_ops *crypto_ops;
if (((struct xmit_frame *)pxmitframe)->buf_addr == NULL)
return;
+ if ((pattrib->encrypt != _WEP40_) && (pattrib->encrypt != _WEP104_))
+ return;
+
hw_hdr_offset = TXDESC_SIZE +
(((struct xmit_frame *)pxmitframe)->pkt_offset *
PACKET_OFFSET_SZ);
pframe = ((struct xmit_frame *)pxmitframe)->buf_addr + hw_hdr_offset;
- /* start to encrypt each fragment */
- if ((pattrib->encrypt == _WEP40_) || (pattrib->encrypt == _WEP104_)) {
- keylength =
psecuritypriv->dot11DefKeylen[psecuritypriv->dot11PrivacyKeyIndex];
+ crypto_ops = try_then_request_module(lib80211_get_crypto_ops("WEP"),
"lib80211_crypt_wep");
- for (curfragnum = 0; curfragnum < pattrib->nr_frags;
curfragnum++) {
- iv = pframe+pattrib->hdrlen;
- memcpy(&wepkey[0], iv, 3);
- memcpy(&wepkey[3],
&psecuritypriv->dot11DefKey[psecuritypriv->dot11PrivacyKeyIndex].skey[0],
keylength);
- payload = pframe+pattrib->iv_len+pattrib->hdrlen;
+ if (!crypto_ops)
+ return;
- if ((curfragnum+1) == pattrib->nr_frags) { /* the
last fragment */
- length =
pattrib->last_txcmdsz-pattrib->hdrlen-pattrib->iv_len-pattrib->icv_len;
+ crypto_private = crypto_ops->init(keyindex);
+ if (!crypto_private)
+ return;
- *((__le32 *)crc) = getcrc32(payload, length);
+ if (crypto_ops->set_key(psecuritypriv->dot11DefKey[keyindex].skey,
+ psecuritypriv->dot11DefKeylen[keyindex], NULL,
crypto_private) < 0)
+ goto free_crypto_private;
- arcfour_init(&mycontext, wepkey, 3+keylength);
- arcfour_encrypt(&mycontext, payload, payload,
length);
- arcfour_encrypt(&mycontext, payload+length,
crc, 4);
- } else {
- length =
pxmitpriv->frag_len-pattrib->hdrlen-pattrib->iv_len-pattrib->icv_len;
- *((__le32 *)crc) = getcrc32(payload, length);
- arcfour_init(&mycontext, wepkey, 3+keylength);
- arcfour_encrypt(&mycontext, payload, payload,
length);
- arcfour_encrypt(&mycontext, payload+length,
crc, 4);
-
- pframe += pxmitpriv->frag_len;
- pframe = (u8 *)round_up((size_t)(pframe), 4);
- }
+ for (curfragnum = 0; curfragnum < pattrib->nr_frags; curfragnum++) {
+ if (curfragnum + 1 == pattrib->nr_frags)
+ length = pattrib->last_txcmdsz;
+ else
+ length = pxmitpriv->frag_len;
+ skb = dev_alloc_skb(length);
+ if (!skb)
+ goto free_crypto_private;
+
+ skb_put_data(skb, pframe, length);
+
+ memmove(skb->data + 4, skb->data, pattrib->hdrlen);
+ skb_pull(skb, 4);
+ skb_trim(skb, skb->len - 4);
+
+ if (crypto_ops->encrypt_mpdu(skb, pattrib->hdrlen,
crypto_private)) {
+ kfree_skb(skb);
+ goto free_crypto_private;
}
+
+ memcpy(pframe, sk
Re: [PATCH v2 1/4] iio: hx711: add data-ready-delay-ns property in DT
On Mon, 25 Jun 2018 17:18:02 +0200
Andreas Klinger wrote:
> add data-ready-delay-ns property for hx711 ADC
> this is the delay after rising PD_SCK until DOUT is read and assumed to be
> ready
>
> Signed-off-by: Andreas Klinger
Hmm. It's not particularly generic... I think this should have
have vendor prefix until we have some visibility of whether it
is a common thing we want to standardise around or not.
I'll also be waiting for a devicetree ack on this one as it's a
tiny bit unusual.
Thanks,
Jonathan
> ---
> Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> index b3629405f568..d0c066e3df69 100644
> --- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> +++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> @@ -8,11 +8,18 @@ Required properties:
> See Documentation/devicetree/bindings/gpio/gpio.txt
> - avdd-supply: Definition of the regulator used as analog supply
>
> +Optional properties:
> + - data-ready-delay-ns: additional delay in nanoseconds between rising
> of
> + PD_SCK until DOUT is ready
> + should be less then maximum PD_SCK high time which
> + is 5 in the datasheet
> +
> Example:
> weight@0 {
> compatible = "avia,hx711";
> sck-gpios = <&gpio3 10 GPIO_ACTIVE_HIGH>;
> dout-gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
> avdd-suppy = <&avdd>;
> + data-ready-delay-ns = <1000>;
> };
>
Re: [PATCH v2 3/4] iio: hx711: add maintainer for driver
On Mon, 25 Jun 2018 17:18:45 +0200 Andreas Klinger wrote: > add a maintainer for driver hx711 > > Signed-off-by: Andreas Klinger I applied this one before (not certain I emailed to say that) so please drop from future versions of the patch set. Thanks, Jonathan > --- > MAINTAINERS | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 4b65225d443a..cfb8a08777ac 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2535,6 +2535,13 @@ S: Maintained > F: drivers/auxdisplay/ > F: include/linux/cfag12864b.h > > +AVIA HX711 ANALOG DIGITAL CONVERTER IIO DRIVER > +M: Andreas Klinger > +L: linux-...@vger.kernel.org > +S: Maintained > +F: Documentation/devicetree/bindings/iio/adc/avia-hx711.txt > +F: drivers/iio/adc/hx711.c > + > AX.25 NETWORK LAYER > M: Ralf Baechle > L: linux-h...@vger.kernel.org
Re: [PATCH v2 4/4] iio: hx711: warning in dt binding example doc
On Mon, 25 Jun 2018 17:19:26 +0200
Andreas Klinger wrote:
> device tree compiler (dtc) gives a warning if a device node has "@" with a
> following number as it's name but no reg property.
>
> fix the example in the documentation of avia,hx711 to conform to dtc
> behavior
>
> Signed-off-by: Andreas Klinger
Given there will be fuzz, I'll pick this up when patches 1 and 2 are
ready and Acked by a devicetree maintainer.
Thanks,
Jonathan
> ---
> Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> index d0c066e3df69..8c9bcaa4d750 100644
> --- a/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> +++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
> @@ -15,7 +15,7 @@ Optional properties:
> is 5 in the datasheet
>
> Example:
> -weight@0 {
> +weight {
> compatible = "avia,hx711";
> sck-gpios = <&gpio3 10 GPIO_ACTIVE_HIGH>;
> dout-gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
Re: [PATCH] mtd: spi-nor: cadence-quadspi: Fix direct mode write timeouts
On 06/30/2018 12:54 PM, Vignesh R wrote:
> Sometimes when writing large size files to flash in direct/memory mapped
> mode, it is seen that flash write enable command times out with error:
> [ 503.146293] cadence-qspi 4704.ospi: Flash command execution timed out.
>
> This is because, we need to make sure previous direct write operation
> is complete by polling for IDLE bit in CONFIG_REG before starting the
> next operation.
>
> Fix this by polling for IDLE bit after memory mapped write.
>
> Fixes: a27f2eaf2b27 ("mtd: spi-nor: cadence-quadspi: Add support for direct
> access mode")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Vignesh R
Reviewed-by: Marek Vasut
> ---
> drivers/mtd/spi-nor/cadence-quadspi.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
> b/drivers/mtd/spi-nor/cadence-quadspi.c
> index c3f7aaa5d18f..d7e10b36a0b9 100644
> --- a/drivers/mtd/spi-nor/cadence-quadspi.c
> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c
> @@ -926,10 +926,12 @@ static ssize_t cqspi_write(struct spi_nor *nor, loff_t
> to,
> if (ret)
> return ret;
>
> - if (f_pdata->use_direct_mode)
> + if (f_pdata->use_direct_mode) {
> memcpy_toio(cqspi->ahb_base + to, buf, len);
> - else
> + ret = cqspi_wait_idle(cqspi);
> + } else {
> ret = cqspi_indirect_write_execute(nor, to, buf, len);
> + }
> if (ret)
> return ret;
>
>
--
Best regards,
Marek Vasut
Re: [PATCH v3 2/2] iio: adc: Add Spreadtrum SC27XX PMICs ADC support
On Mon, 25 Jun 2018 09:47:54 +0800 Baolin Wang wrote: > Hi Jonathan, > > On 24 June 2018 at 21:47, Jonathan Cameron > wrote: > > On Sun, 24 Jun 2018 14:30:09 +0100 > > Jonathan Cameron wrote: > > > >> On Sun, 24 Jun 2018 17:13:00 +0800 > >> Baolin Wang wrote: > >> > >> > Hi Jonathan, > >> > > >> > On 22 June 2018 at 22:13, Jonathan Cameron > >> > wrote: > >> > > On Thu, 21 Jun 2018 11:14:05 +0800 > >> > > Baolin Wang wrote: > >> > > > >> > >> From: Freeman Liu > >> > >> > >> > >> The Spreadtrum SC27XX PMICs ADC controller contains 32 channels, > >> > >> which is used to sample voltages with 12 bits conversion. > >> > >> > >> > >> [Baolin Wang did lots of improvements] > >> > >> > >> > >> Signed-off-by: Freeman Liu > >> > >> Signed-off-by: Baolin Wang > >> > > > >> > > One trivial missed bit of cleanup inline. I'll sort that > >> > > when applying if no one else points anything out before I get back to > >> > > my > >> > > development machine. > >> > > >> > Thanks. > >> > >> Applied to the togreg branch of iio.git and pushed out as testing > >> for the autobuilders to play with it. > > Sorry, backed out for now. My togreg tree is non rebasing and > > this is dependant on some stuff that only went in during the merge > > window. > > > > I'll send a pull request to GregKH fairly soon and after that do > > the merge back into my tree to pick that hwspin lock stuff up. > > > > So this will be a week or two before I can apply it without issues. > > > > Give me a poke if I seem to have forgotten about it. > > OK. Many thanks for your help. > Applied now with dependencies in place. Applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to play with it. Thanks, Jonathan
Re: /tmp/cctnQ1CM.s:35: Error: .err encountered
On Sat, 30 Jun 2018 12:27:09 +0200 Dmitry Vyukov wrote: > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > master > > head: 1904148a361a07fb2d7cba1261d1d2c2f33c8d2e > > commit: 758517202bd2e427664857c9f2aa59da36848aca arm: port KCOV to arm > > date: 2 weeks ago > > config: arm-allmodconfig (attached as .config) > > compiler: arm-linux-gnueabi-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 758517202bd2e427664857c9f2aa59da36848aca > > # save the attached .config to linux build tree > > GCC_VERSION=7.2.0 make.cross ARCH=arm > > > > All errors (new ones prefixed by >>): > > > >/tmp/cctnQ1CM.s: Assembler messages: > >>> /tmp/cctnQ1CM.s:35: Error: .err encountered > >/tmp/cctnQ1CM.s:36: Error: .err encountered > >/tmp/cctnQ1CM.s:37: Error: .err encountered > > Hi kbuild test robot, > > The fix was mailed more than a month ago, but still not merged into > the tree. That's linux... That was a rather unhelpful email. I've just scanned all your lkml emails since the start of May and cannot find anything which looks like a fix for this issue. Please resend. About three weks ago :(
Re: /tmp/cctnQ1CM.s:35: Error: .err encountered
On Sat, 30 Jun 2018 11:07:20 -0700 Andrew Morton
wrote:
> On Sat, 30 Jun 2018 12:27:09 +0200 Dmitry Vyukov wrote:
>
> > > tree:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > > head: 1904148a361a07fb2d7cba1261d1d2c2f33c8d2e
> > > commit: 758517202bd2e427664857c9f2aa59da36848aca arm: port KCOV to arm
> > > date: 2 weeks ago
> > > config: arm-allmodconfig (attached as .config)
> > > compiler: arm-linux-gnueabi-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 758517202bd2e427664857c9f2aa59da36848aca
> > > # save the attached .config to linux build tree
> > > GCC_VERSION=7.2.0 make.cross ARCH=arm
> > >
> > > All errors (new ones prefixed by >>):
> > >
> > >/tmp/cctnQ1CM.s: Assembler messages:
> > >>> /tmp/cctnQ1CM.s:35: Error: .err encountered
> > >/tmp/cctnQ1CM.s:36: Error: .err encountered
> > >/tmp/cctnQ1CM.s:37: Error: .err encountered
> >
> > Hi kbuild test robot,
> >
> > The fix was mailed more than a month ago, but still not merged into
> > the tree. That's linux...
>
> That was a rather unhelpful email.
>
> I've just scanned all your lkml emails since the start of May and
> cannot find anything which looks like a fix for this issue.
>
> Please resend. About three weks ago :(
OK, with a bi of amazing sleuthing I found this from Arnd, which is what
I presume you're referring to?
From: Arnd Bergmann
Subject: ARM: disable KCOV for trusted foundations code
The ARM trusted foundations code is currently broken in linux-next when
CONFIG_KCOV_INSTRUMENT_ALL is set:
/tmp/ccHdQsCI.s: Assembler messages:
/tmp/ccHdQsCI.s:37: Error: .err encountered
/tmp/ccHdQsCI.s:38: Error: .err encountered
/tmp/ccHdQsCI.s:39: Error: .err encountered
scripts/Makefile.build:311: recipe for target
'arch/arm/firmware/trusted_foundations.o' failed
I could not find a function attribute that lets me disable
-fsanitize-coverage=trace-pc for just one function, so this turns it off
for the entire file instead.
Link: http://lkml.kernel.org/r/20180529103636.1535457-1-a...@arndb.de
Fixes: 758517202bd2e4 ("arm: port KCOV to arm")
Signed-off-by: Arnd Bergmann
Cc: Dmitry Vyukov
Cc: Mark Rutland
Signed-off-by: Andrew Morton
---
diff -puN
arch/arm/firmware/Makefile~arm-disable-kcov-for-trusted-foundations-code
arch/arm/firmware/Makefile
--- a/arch/arm/firmware/Makefile~arm-disable-kcov-for-trusted-foundations-code
+++ a/arch/arm/firmware/Makefile
@@ -1 +1,4 @@
obj-$(CONFIG_TRUSTED_FOUNDATIONS) += trusted_foundations.o
+
+# tf_generic_smc() fails to build with -fsanitize-coverage=trace-pc
+KCOV_INSTRUMENT:= n
_
[PATCH 1/3] staging: rtl8188eu: reorder switch cases and remove default break
Reorder the cases of a switch statement to be in ascending order.
Remove unrequired break from default case.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/hal/hal_com.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8188eu/hal/hal_com.c
b/drivers/staging/rtl8188eu/hal/hal_com.c
index b91902cdb34c..b2ea3d435af0 100644
--- a/drivers/staging/rtl8188eu/hal/hal_com.c
+++ b/drivers/staging/rtl8188eu/hal/hal_com.c
@@ -264,18 +264,17 @@ bool Hal_MappingOutPipe(struct adapter *adapter, u8
numoutpipe)
bool result = true;
switch (numoutpipe) {
+ case 1:
+ one_out_pipe(adapter);
+ break;
case 2:
two_out_pipe(adapter, wifi_cfg);
break;
case 3:
three_out_pipe(adapter, wifi_cfg);
break;
- case 1:
- one_out_pipe(adapter);
- break;
default:
result = false;
- break;
}
return result;
}
--
2.18.0
[PATCH 3/3] staging: rtl8188eu: fix block comments - coding style
Write multiple single line comments as block comments to
follow kernel coding style and improve readability.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/hal/hal_com.c | 50 ++---
1 file changed, 28 insertions(+), 22 deletions(-)
diff --git a/drivers/staging/rtl8188eu/hal/hal_com.c
b/drivers/staging/rtl8188eu/hal/hal_com.c
index ca26a4f4dd86..7202e1767fc0 100644
--- a/drivers/staging/rtl8188eu/hal/hal_com.c
+++ b/drivers/staging/rtl8188eu/hal/hal_com.c
@@ -189,11 +189,13 @@ static void two_out_pipe(struct adapter *adapter, bool
wifi_cfg)
{
struct dvobj_priv *pdvobjpriv = adapter_to_dvobj(adapter);
- if (wifi_cfg) { /* WMM */
- /* BK, BE, VI, VO, BCN, CMD, MGT, HIGH, HCCA */
- /* 0, 1, 0, 1, 0, 0, 0,0,0}; */
- /* 0:H, 1:L */
-
+ if (wifi_cfg) {
+ /*
+* WMM
+* BK, BE, VI, VO, BCN, CMD, MGT, HIGH, HCCA
+* 0, 1, 0, 1, 0, 0, 0,0,0
+* 0:H, 1:L
+*/
pdvobjpriv->Queue2Pipe[0] = pdvobjpriv->RtOutPipe[1];/* VO */
pdvobjpriv->Queue2Pipe[1] = pdvobjpriv->RtOutPipe[0];/* VI */
pdvobjpriv->Queue2Pipe[2] = pdvobjpriv->RtOutPipe[1];/* BE */
@@ -203,12 +205,13 @@ static void two_out_pipe(struct adapter *adapter, bool
wifi_cfg)
pdvobjpriv->Queue2Pipe[5] = pdvobjpriv->RtOutPipe[0];/* MGT */
pdvobjpriv->Queue2Pipe[6] = pdvobjpriv->RtOutPipe[0];/* HIGH */
pdvobjpriv->Queue2Pipe[7] = pdvobjpriv->RtOutPipe[0];/* TXCMD */
-
- } else {/* typical setting */
- /* BK, BE, VI, VO, BCN, CMD, MGT, HIGH, HCCA */
- /* 1, 1, 0, 0, 0, 0, 0,0,0}; */
- /* 0:H, 1:L */
-
+ } else {
+ /*
+* typical setting
+* BK, BE, VI, VO, BCN, CMD, MGT, HIGH, HCCA
+* 1, 1, 0, 0, 0, 0, 0,0,0
+* 0:H, 1:L
+*/
pdvobjpriv->Queue2Pipe[0] = pdvobjpriv->RtOutPipe[0];/* VO */
pdvobjpriv->Queue2Pipe[1] = pdvobjpriv->RtOutPipe[0];/* VI */
pdvobjpriv->Queue2Pipe[2] = pdvobjpriv->RtOutPipe[1];/* BE */
@@ -225,11 +228,13 @@ static void three_out_pipe(struct adapter *adapter, bool
wifi_cfg)
{
struct dvobj_priv *pdvobjpriv = adapter_to_dvobj(adapter);
- if (wifi_cfg) {/* for WMM */
- /* BK, BE, VI, VO, BCN, CMD, MGT, HIGH, HCCA */
- /* 1, 2, 1, 0, 0, 0, 0,0,0}; */
- /* 0:H, 1:N, 2:L */
-
+ if (wifi_cfg) {
+ /*
+* for WMM
+* BK, BE, VI, VO, BCN, CMD, MGT, HIGH, HCCA
+* 1, 2, 1, 0, 0, 0, 0,0,0
+* 0:H, 1:N, 2:L
+*/
pdvobjpriv->Queue2Pipe[0] = pdvobjpriv->RtOutPipe[0];/* VO */
pdvobjpriv->Queue2Pipe[1] = pdvobjpriv->RtOutPipe[1];/* VI */
pdvobjpriv->Queue2Pipe[2] = pdvobjpriv->RtOutPipe[2];/* BE */
@@ -239,12 +244,13 @@ static void three_out_pipe(struct adapter *adapter, bool
wifi_cfg)
pdvobjpriv->Queue2Pipe[5] = pdvobjpriv->RtOutPipe[0];/* MGT */
pdvobjpriv->Queue2Pipe[6] = pdvobjpriv->RtOutPipe[0];/* HIGH */
pdvobjpriv->Queue2Pipe[7] = pdvobjpriv->RtOutPipe[0];/* TXCMD */
-
- } else {/* typical setting */
- /* BK, BE, VI, VO, BCN, CMD, MGT, HIGH, HCCA */
- /* 2, 2, 1, 0, 0, 0, 0,0,0}; */
- /* 0:H, 1:N, 2:L */
-
+ } else {
+ /*
+* typical setting
+* BK, BE, VI, VO, BCN, CMD, MGT, HIGH, HCCA
+* 2, 2, 1, 0, 0, 0, 0,0,0
+* 0:H, 1:N, 2:L
+*/
pdvobjpriv->Queue2Pipe[0] = pdvobjpriv->RtOutPipe[0];/* VO */
pdvobjpriv->Queue2Pipe[1] = pdvobjpriv->RtOutPipe[1];/* VI */
pdvobjpriv->Queue2Pipe[2] = pdvobjpriv->RtOutPipe[2];/* BE */
--
2.18.0
[PATCH 2/3] staging: rtl8188eu: move return type to functions definition line
The return type of a function should be on the same line as the
definition.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/hal/hal_com.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8188eu/hal/hal_com.c
b/drivers/staging/rtl8188eu/hal/hal_com.c
index b2ea3d435af0..ca26a4f4dd86 100644
--- a/drivers/staging/rtl8188eu/hal/hal_com.c
+++ b/drivers/staging/rtl8188eu/hal/hal_com.c
@@ -44,10 +44,10 @@ void dump_chip_info(struct HAL_VERSION chip_vers)
#defineCHAN_PLAN_HW0x80
-u8 /* return the final channel plan decision */
-hal_com_get_channel_plan(struct adapter *padapter, u8 hw_channel_plan,
-u8 sw_channel_plan, u8 def_channel_plan,
-bool load_fail)
+/* return the final channel plan decision */
+u8 hal_com_get_channel_plan(struct adapter *padapter, u8 hw_channel_plan,
+ u8 sw_channel_plan, u8 def_channel_plan,
+ bool load_fail)
{
u8 sw_cfg;
u8 chnlplan;
--
2.18.0
Re: [PATCH] synaptics: Enable RMI4 for Clevo P870DM laptops
On Sat, Jun 23, 2018 at 11:05 PM Teika Kazura wrote:
>
> Hi, Rosen. Thank you for your patch. (@Jan Steffens and @Pablo Cholaky:
> Thanks for your reports.) But I'm afraid some more work is necessary. Let me
> propose some points.
Too much work for me. I'll just use the kernel pareameter.
>
> I'm not a kernel developer, but have been working on this issue to help them.
> (See https://www.spinics.net/lists/linux-input/msg55950.html )
>
> 0.
> Could you resend it, cc-ing to the relevant developers. (Use the one of my
> reply here. You can use /scripts/get_maintainer.pl next
> time.) Otherwise, it is unlikely to be noticed by them.
>
> 1.
> You added your device to forcepad_pnp_ids[], but I guess it should be
> smbus_pnp_ids[].
>
> When making the patch again, please use the kernel 4.17 or newer, because
> smbus_pnp_ids was changed recently.
>
> If it works by using smbus_pnp_ids, please test it for a week or so,
> especially making sure that suspend/resume works without any problem.
>
> 2.
> Though it's my personal impression, the change description looked somewhat
> personal. At the same time, it's important, guaranteeing the stability of the
> patch.- I know you originally reported it last August [1]. Furthermore, there
> have been two other users [2] who reported SMBus worked for the same device,
> namely SYN1219. (They two are cc-ed to in this reply.)
>
> You can use "$ git format-patch --cover-letter"; it will generate a
> "cover-letter", the introductory part of the patch, explaining the
> acceptability of the patch to kernel developers. (For an example, see
> https://www.spinics.net/lists/linux-input/msg57041.html)
>
> So the full description can be given in the cover letter, and the real patch
> description can be something like "This enables SMBus for xxx", being almost
> identical to the email subject.
>
> 3. This is not essential, but the style of the email subject that the device
> maintainer prefers might be:
>
> [PATCH v2] Input: synaptics - Enable RMI4 for Clevo P870DM laptops
>
> after looking at this tree [3]. ("v2" meaning version 2, due to the above
> change.) You can feed "--subject-prefix='PATCH v2'" to "$ git format-patch".
>
> 4. If you want to give the credit for my reply, you can add
>
> Suggested-by: Teika Kazura
>
> after Signed-off-by. It's completely ok without it. :-)
>
> [1] https://marc.info/?l=linux-input&m=150284057602358&w=2
> [2] https://marc.info/?l=linux-input&m=150049625613055&w=2
> https://marc.info/?l=linux-input&m=15009456026&w=2
> [3] https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/log/
>
> Best regards,
> Teika (Teika kazura)
>
>
> From: Rosen Penev
> Subject: [PATCH] synaptics: Enable RMI4 for Clevo P870DM laptops
> Date: Sat, 16 Jun 2018 18:42:16 -0700
>
> > I have been testing this for half a year with no issues to report.
> >
> > Signed-off-by: Rosen Penev
> > ---
> > drivers/input/mouse/synaptics.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/input/mouse/synaptics.c
> > b/drivers/input/mouse/synaptics.c
> > index 55d33500d55e..23f5bb2cf9da 100644
> > --- a/drivers/input/mouse/synaptics.c
> > +++ b/drivers/input/mouse/synaptics.c
> > @@ -183,6 +183,7 @@ static const char * const smbus_pnp_ids[] = {
> > };
> >
> > static const char * const forcepad_pnp_ids[] = {
> > + "SYN1219",
> > "SYN300D",
> > "SYN3014",
> > NULL
> > --
> > 2.17.1
> >
Re: [PATCH v2 0/2] PCI Quirk Patchset for Microsemi Switchtec NTB
On Fri, Jun 29, 2018 at 08:50:02PM -0500, Bjorn Helgaas wrote:
> On Wed, May 23, 2018 at 01:18:04PM -0700, dme...@gigaio.com wrote:
> > From: Doug Meyer
> >
> > This is a resend of the patch series to enable Microsemi Switchtec
> > NTB configurations to run with the IOMMU in the hosts turned on.
> > Because of the nature PCI Quirk implementation, it was preferable
> > to migrate the Microsemi PCI vendor and device definitions to the
> > Linux canonical location. Logan Gunthorpe requested that this
> > migration be done as a separate patch in a set, and so this patch
> > series was created as shown here.
> >
> > The first patch encapsulates the movement of constants from
> > switchtec.h to pci_ids.h, with commensurate changes to the source
> > files. This patch is not dependent on any other work.
> >
> > The second patch is the PCI quirk implementation itself, and is
> > completely dependent upon the first patch in this series.
> >
> > Testing of the quirk was done on with a 2-host x86-64 system
> > with all combinations of IOMMU off/on. The ntb_perf module was
> > used as test stimulus.
> >
> > Blessings,
> > Doug Meyer
> >
> > Changes since v1:
> > - Call pci_device_disable() at return points to clean up properly.
> > - Changed all dev_* print macros to pci_* macros.
> > - Removed superfluous variable initializations.
> >
> > Doug Meyer (2):
> > NTB: Migrate PCI Constants to Cannonical PCI Header
> > NTB: PCI Quirk to Enable Switchtec NT Functionality with IOMMU On
> >
> > drivers/ntb/hw/mscc/ntb_hw_switchtec.c | 3 +-
> > drivers/pci/quirks.c | 197
> > +
> > drivers/pci/switch/switchtec.c | 15 ++-
> > include/linux/pci_ids.h| 32 ++
> > include/linux/switchtec.h | 4 -
> > 5 files changed, 238 insertions(+), 13 deletions(-)
>
> I applied these with Logan's reviewed-by to my pci/switchtec branch for
> v4.19 with the following updates:
>
> - You removed the SPDX tag from drivers/pci/switch/switchtec.c. I assume
> that was a mistake, so I restored it.
>
> - I moved the PCI_VENDOR_ID_MICROSEMI definition to keep the file sorted.
>
> - I dropped the Device ID definitions per the policy at the top of the
> file (which I mentioned on your v1 posting).
>
> - I converted all the Device ID definition uses to raw hex constants. I
> noticed that the following were defined by your patch, but not used:
>
> PCI_DEVICE_ID_MICROSEMI_PSX24XG3
> PCI_DEVICE_ID_MICROSEMI_PSX32XG3
>
> I can't tell whether the quirk is supposed to apply to them or not.
>
> Please review and holler if I broke something.
>
> This touches drivers/ntb/hw/..., which isn't my area. Let me know if you'd
> rather take these through a different tree.
I also:
- Fixed the sparse warnings reported by the kbuild test robot.
- Removed some (void * __iomem) casts in the ioread32() parameters and
the (u64) cast on the return value. I noticed that
switchtec_ntb_init_sndev() does an ioread64() of ep_map instead of two
ioread32() calls. I suspect both places could and should do it the
same way.
- Used %02x.%d instead of %02d.%d when printing the DMA alias, so it
matches the other places that print PCI device addresses.
- Replaced DECLARE_PCI_FIXUP_CLASS_FINAL with DECLARE_PCI_FIXUP_FINAL,
since it should be sufficient to filter on Vendor and Device ID,
without worrying about the class.
Here's the diff from what you originally posted to what's currently on my
pci/switchtec branch:
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index f178cecdc001..d54a182a09cf 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4787,14 +4787,13 @@ static void quirk_switchtec_ntb_dma_alias(struct
pci_dev *pdev)
pci_info(pdev, "Setting Switchtec proxy ID aliases\n");
mmio_ntb = mmio + SWITCHTEC_GAS_NTB_OFFSET;
- mmio_ctrl = (void * __iomem) mmio_ntb + SWITCHTEC_NTB_REG_CTRL_OFFSET;
+ mmio_ctrl = (void __iomem *) mmio_ntb + SWITCHTEC_NTB_REG_CTRL_OFFSET;
mmio_sys_info = mmio + SWITCHTEC_GAS_SYS_INFO_OFFSET;
partition = ioread8(&mmio_ntb->partition_id);
- partition_map = (u64) ioread32((void * __iomem) &mmio_ntb->ep_map);
- partition_map |=
- ((u64) ioread32((void * __iomem) &mmio_ntb->ep_map + 4)) << 32;
+ partition_map = ioread32(&mmio_ntb->ep_map);
+ partition_map |= ((u64) ioread32(&mmio_ntb->ep_map + 4)) << 32;
partition_map &= ~(1ULL << partition);
for (pp = 0; pp < (sizeof(partition_map) * 8); pp++) {
@@ -4829,7 +4828,7 @@ static void quirk_switchtec_ntb_dma_alias(struct pci_dev
*pdev)
rid_entry = ioread32(&mmio_peer_ctrl->req_id_table[te]);
devfn = (rid_entry >> 1) & 0xFF;
pci_dbg(pdev,
- "Aliasing Partition %d Proxy ID %02d.%d\n",
+
Re: [GIT PULL] x86 fixes
On Sat, Jun 30, 2018 at 1:49 AM Ingo Molnar wrote:
>
> --- a/arch/x86/entry/entry_32.S
> +++ b/arch/x86/entry/entry_32.S
> @@ -477,7 +477,7 @@ ENTRY(entry_SYSENTER_32)
> * whereas POPF does not.)
> */
> addl$PT_EFLAGS-PT_DS, %esp /* point esp at pt_regs->flags */
> - btr $X86_EFLAGS_IF_BIT, (%esp)
> + btrl$X86_EFLAGS_IF_BIT, (%esp)
> popfl
Ho humm. Just looking at this patch, my reaction was "why isn't this
an 'andl $~X86_EFLAGS_IF' instead"?
Yeah, I guess the 'andl' is two bytes longer (due to the 32-bit
constant - because IF is bit 9, you can't use a byte constant, and you
don't want to get a partial word write just before the popfl).
But btr is really pretty heavy operation for older CPU's (it's gotten
better, but 32-bit code presumably cares more about the older CPUs).
It really doesn't matter, I guess. The btr goes back to commit
c2c9b52fab0d ("x86/entry/32: Restore FLAGS on SYSEXIT").
Andy?
Linus
Re: [PATCH] vmw_pvrdma: Release netdev when vmxnet3 module is removed
Hi Neil,
I love your patch! Perhaps something to improve:
url:
https://github.com/0day-ci/linux/commits/Neil-Horman/vmw_pvrdma-Release-netdev-when-vmxnet3-module-is-removed/20180628-232414
smatch warnings:
drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c:987 pvrdma_pci_probe() warn:
variable dereferenced before check 'dev->netdev' (see line 985)
#
https://github.com/0day-ci/linux/commit/d5bb424e18e2ecab4ac590a66b0cca9dfb96d3da
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout d5bb424e18e2ecab4ac590a66b0cca9dfb96d3da
vim +987 drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c
29c8d9eb Adit Ranadive 2016-10-02 784
29c8d9eb Adit Ranadive 2016-10-02 785 static int pvrdma_pci_probe(struct
pci_dev *pdev,
29c8d9eb Adit Ranadive 2016-10-02 786 const
struct pci_device_id *id)
29c8d9eb Adit Ranadive 2016-10-02 787 {
29c8d9eb Adit Ranadive 2016-10-02 788 struct pci_dev *pdev_net;
29c8d9eb Adit Ranadive 2016-10-02 789 struct pvrdma_dev *dev;
29c8d9eb Adit Ranadive 2016-10-02 790 int ret;
29c8d9eb Adit Ranadive 2016-10-02 791 unsigned long start;
29c8d9eb Adit Ranadive 2016-10-02 792 unsigned long len;
29c8d9eb Adit Ranadive 2016-10-02 793 dma_addr_t slot_dma = 0;
29c8d9eb Adit Ranadive 2016-10-02 794
29c8d9eb Adit Ranadive 2016-10-02 795 dev_dbg(&pdev->dev,
"initializing driver %s\n", pci_name(pdev));
29c8d9eb Adit Ranadive 2016-10-02 796
29c8d9eb Adit Ranadive 2016-10-02 797 /* Allocate zero-out device */
29c8d9eb Adit Ranadive 2016-10-02 798 dev = (struct pvrdma_dev
*)ib_alloc_device(sizeof(*dev));
29c8d9eb Adit Ranadive 2016-10-02 799 if (!dev) {
29c8d9eb Adit Ranadive 2016-10-02 800 dev_err(&pdev->dev,
"failed to allocate IB device\n");
29c8d9eb Adit Ranadive 2016-10-02 801 return -ENOMEM;
29c8d9eb Adit Ranadive 2016-10-02 802 }
29c8d9eb Adit Ranadive 2016-10-02 803
29c8d9eb Adit Ranadive 2016-10-02 804
mutex_lock(&pvrdma_device_list_lock);
29c8d9eb Adit Ranadive 2016-10-02 805 list_add(&dev->device_link,
&pvrdma_device_list);
29c8d9eb Adit Ranadive 2016-10-02 806
mutex_unlock(&pvrdma_device_list_lock);
29c8d9eb Adit Ranadive 2016-10-02 807
29c8d9eb Adit Ranadive 2016-10-02 808 ret = pvrdma_init_device(dev);
29c8d9eb Adit Ranadive 2016-10-02 809 if (ret)
29c8d9eb Adit Ranadive 2016-10-02 810 goto err_free_device;
29c8d9eb Adit Ranadive 2016-10-02 811
29c8d9eb Adit Ranadive 2016-10-02 812 dev->pdev = pdev;
29c8d9eb Adit Ranadive 2016-10-02 813 pci_set_drvdata(pdev, dev);
29c8d9eb Adit Ranadive 2016-10-02 814
29c8d9eb Adit Ranadive 2016-10-02 815 ret = pci_enable_device(pdev);
29c8d9eb Adit Ranadive 2016-10-02 816 if (ret) {
29c8d9eb Adit Ranadive 2016-10-02 817 dev_err(&pdev->dev,
"cannot enable PCI device\n");
29c8d9eb Adit Ranadive 2016-10-02 818 goto err_free_device;
29c8d9eb Adit Ranadive 2016-10-02 819 }
29c8d9eb Adit Ranadive 2016-10-02 820
29c8d9eb Adit Ranadive 2016-10-02 821 dev_dbg(&pdev->dev, "PCI
resource flags BAR0 %#lx\n",
29c8d9eb Adit Ranadive 2016-10-02 822
pci_resource_flags(pdev, 0));
29c8d9eb Adit Ranadive 2016-10-02 823 dev_dbg(&pdev->dev, "PCI
resource len %#llx\n",
29c8d9eb Adit Ranadive 2016-10-02 824 (unsigned long
long)pci_resource_len(pdev, 0));
29c8d9eb Adit Ranadive 2016-10-02 825 dev_dbg(&pdev->dev, "PCI
resource start %#llx\n",
29c8d9eb Adit Ranadive 2016-10-02 826 (unsigned long
long)pci_resource_start(pdev, 0));
29c8d9eb Adit Ranadive 2016-10-02 827 dev_dbg(&pdev->dev, "PCI
resource flags BAR1 %#lx\n",
29c8d9eb Adit Ranadive 2016-10-02 828
pci_resource_flags(pdev, 1));
29c8d9eb Adit Ranadive 2016-10-02 829 dev_dbg(&pdev->dev, "PCI
resource len %#llx\n",
29c8d9eb Adit Ranadive 2016-10-02 830 (unsigned long
long)pci_resource_len(pdev, 1));
29c8d9eb Adit Ranadive 2016-10-02 831 dev_dbg(&pdev->dev, "PCI
resource start %#llx\n",
29c8d9eb Adit Ranadive 2016-10-02 832 (unsigned long
long)pci_resource_start(pdev, 1));
29c8d9eb Adit Ranadive 2016-10-02 833
29c8d9eb Adit Ranadive 2016-10-02 834 if (!(pci_resource_flags(pdev,
0) & IORESOURCE_MEM) ||
29c8d9eb Adit Ranadive 2016-10-02 835 !(pci_resource_flags(pdev,
1) & IORESOURCE_MEM)) {
29c8d9eb Adit Ranadive 2016-10-02 836 dev_err(&pdev->dev,
"PCI BAR region not MMIO\n");
29c8d9eb Adit Ranadive 2016-10-02 837 ret = -ENOMEM;
29c8d9eb Adit Ranadive 2016-10-02 838 goto err_free_device;
29c8d9eb Adit Ranadive 2
Re: [PATCH V2] PCI: Enable PASID when End-to-End TLP is supported by all bridges
On Sat, Jun 30, 2018 at 10:45:21AM -0400, Sinan Kaya wrote: > On 6/29/2018 8:49 PM, Bjorn Helgaas wrote: > > On Tue, Jun 19, 2018 at 10:14:46PM -0400, Sinan Kaya wrote: > >> A PCIe endpoint carries the process address space identifier (PASID) in > >> the TLP prefix as part of the memory read/write transaction. The address > >> information in the TLP is relevant only for a given PASID context. > >> > >> An IOMMU takes PASID value and the address information from the > >> TLP to look up the physical address in the system. > >> > >> If a bridge drops the TLP prefix, the translation agent can resolve the > >> address to an incorrect location and cause data corruption. Prevent > >> this condition by requiring End-to-End TLP prefix to be supported on the > >> entire data path between the endpoint and the root port. > > > > PASID is an End-End TLP Prefix (PCIe r4.0, sec 6.20). Sec 2.2.10.2 says > > > > It is an error to receive a TLP with an End-End TLP Prefix by a > > Receiver that does not support End-End TLP Prefixes. A TLP in > > violation of this rule is handled as a Malformed TLP. This is a > > reported error associated with the Receiving Port (see Section 6.2). > > > > So I agree that we shouldn't enable PASID in an endpoint unless all > > the switch ports leading to it support End-End prefixes. But I don't > > see how a bridge can drop a prefix and cause data corruption -- if it > > doesn't support End-End prefixes, shouldn't the bridge raise a > > Malformed TLP error instead of forwarding the TLP? > > It should under normal circumstances. > > I remember reading that most PCIe switches don't support TLP prefixes. > I don't know if it is because of buggy behavior or if it is just plain > unsupported while dropping the request as Malformed TLP. > > I was trying to be proactive and not enable PASID if the entire path > is incapable. Absolutely, that makes perfect sense. Much better to fail to enable PASID rather than enabling it and seeing Malformed TLP errors or data corruption later. I was trying to figure out if you can actually force data corruption this way. If you can, I'd say that sounds like a buggy switch that we might want to be aware of. Bjorn
Re: [PATCH V3] PCI: Enable PASID when End-to-End TLP is supported by all bridges
On Sat, Jun 30, 2018 at 11:24:24AM -0400, Sinan Kaya wrote:
> A PCIe endpoint carries the process address space identifier (PASID) in
> the TLP prefix as part of the memory read/write transaction. The address
> information in the TLP is relevant only for a given PASID context.
>
> An IOMMU takes PASID value and the address information from the
> TLP to look up the physical address in the system.
>
> PASID is an End-End TLP Prefix (PCIe r4.0, sec 6.20). Sec 2.2.10.2 says
>
> It is an error to receive a TLP with an End-End TLP Prefix by a
> Receiver that does not support End-End TLP Prefixes. A TLP in
> violation of this rule is handled as a Malformed TLP. This is a
> reported error associated with the Receiving Port (see Section 6.2).
>
> Prevent error condition by proactively requiring End-to-End TLP
> prefix to be supported on the entire data path between the endpoint and
> the root port before enabling PASID.
>
> Signed-off-by: Sinan Kaya
Applied to pci/virtualization for v4.19, thanks!
> ---
> drivers/pci/ats.c | 3 +++
> drivers/pci/probe.c | 24
> include/linux/pci.h | 1 +
> include/uapi/linux/pci_regs.h | 1 +
> 4 files changed, 29 insertions(+)
>
> diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
> index 4923a2a..5b78f3b 100644
> --- a/drivers/pci/ats.c
> +++ b/drivers/pci/ats.c
> @@ -273,6 +273,9 @@ int pci_enable_pasid(struct pci_dev *pdev, int features)
> if (WARN_ON(pdev->pasid_enabled))
> return -EBUSY;
>
> + if (!pdev->eetlp_prefix_path)
> + return -EINVAL;
> +
> pos = pci_find_ext_capability(pdev, PCI_EXT_CAP_ID_PASID);
> if (!pos)
> return -EINVAL;
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index ac876e3..39fd3ac 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -2042,6 +2042,29 @@ static void pci_configure_ltr(struct pci_dev *dev)
> #endif
> }
>
> +static void pci_configure_eetlp_prefix(struct pci_dev *dev)
> +{
> +#ifdef CONFIG_PCI_PASID
> + struct pci_dev *bridge;
> + u32 cap;
> +
> + if (!pci_is_pcie(dev))
> + return;
> +
> + pcie_capability_read_dword(dev, PCI_EXP_DEVCAP2, &cap);
> + if (!(cap & PCI_EXP_DEVCAP2_E2ETLP))
> + return;
> +
> + if (pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT)
> + dev->eetlp_prefix_path = 1;
> + else {
> + bridge = pci_upstream_bridge(dev);
> + if (bridge && bridge->eetlp_prefix_path)
> + dev->eetlp_prefix_path = 1;
> + }
> +#endif
> +}
> +
> static void pci_configure_device(struct pci_dev *dev)
> {
> struct hotplug_params hpp;
> @@ -2051,6 +2074,7 @@ static void pci_configure_device(struct pci_dev *dev)
> pci_configure_extended_tags(dev, NULL);
> pci_configure_relaxed_ordering(dev);
> pci_configure_ltr(dev);
> + pci_configure_eetlp_prefix(dev);
>
> memset(&hpp, 0, sizeof(hpp));
> ret = pci_get_hp_params(dev, &hpp);
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 340029b..6ba8184 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -350,6 +350,7 @@ struct pci_dev {
> unsigned intltr_path:1; /* Latency Tolerance Reporting
> supported from root to here */
> #endif
> + unsigned inteetlp_prefix_path:1;/* End-to-End TLP Prefix */
>
> pci_channel_state_t error_state;/* Current connectivity state */
> struct device dev;/* Generic device interface */
> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> index 4da87e2..a617ab2 100644
> --- a/include/uapi/linux/pci_regs.h
> +++ b/include/uapi/linux/pci_regs.h
> @@ -636,6 +636,7 @@
> #define PCI_EXP_DEVCAP2_OBFF_MASK 0x000c /* OBFF support mechanism */
> #define PCI_EXP_DEVCAP2_OBFF_MSG0x0004 /* New message signaling */
> #define PCI_EXP_DEVCAP2_OBFF_WAKE 0x0008 /* Re-use WAKE# for OBFF */
> +#define PCI_EXP_DEVCAP2_E2ETLP 0x0020 /* End-to-End TLP
> Prefix */
> #define PCI_EXP_DEVCTL2 40 /* Device Control 2 */
> #define PCI_EXP_DEVCTL2_COMP_TIMEOUT0x000f /* Completion Timeout
> Value */
> #define PCI_EXP_DEVCTL2_COMP_TMOUT_DIS 0x0010 /* Completion Timeout
> Disable */
> --
> 2.7.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
[GIT PULL] ARM: SoC fixes
Hi Linus, The following changes since commit 86676c4685f774d818f7a6c401c925bbf2a92903: arm64: dts: uniphier: fix widget name of headphone for LD11/LD20 boards (2018-06-27 07:14:47 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-fixes for you to fetch changes up to 4ca2f0b945fad835959fa596df47817797987cd2: Merge tag 'davinci-fixes-for-v4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into fixes (2018-06-29 14:08:27 -0700) ARM: SoC fixes for 4.18-rc A smaller batch for the end of the week (let's see if I can keep the weekly cadence going for once). All medium-grade fixes here, nothing worrisome: - Fixes for some fairly old bugs around SD card write-protect detection and GPIO interrupt assignments on Davinci. - Wifi module suspend fix for Hikey. - Minor DT tweaks to fix inaccuracies for Amlogic platforms, on of which solves booting with third-party u-boot. Adam Ford (1): ARM: davinci: board-da850-evm: fix WP pin polarity for MMC/SD Jerome Brunet (2): ARM64: dts: meson: disable sd-uhs modes on the libretech-cc ARM64: dts: meson-axg: fix ethernet stability issue Keerthy (1): ARM: dts: da850: Fix interrups property for gpio Kevin Hilman (2): ARM64: dts: meson: fix register ranges for SD/eMMC ARM64: dts: meson-gx: fix ATF reserved memory region Martin Blumenstingl (1): ARM64: dts: meson-gxl: fix Mali GPU compatible string Neil Armstrong (1): ARM64: dts: meson-gxl-s905x-p212: Add phy-supply for usb0 Olof Johansson (3): Merge tag 'amlogic-fixes' of https://git.kernel.org/.../khilman/linux-amlogic into fixes Merge tag 'hisi-fixes-for-4.18' of git://github.com/hisilicon/linux-hisi into fixes Merge tag 'davinci-fixes-for-v4.18' of git://git.kernel.org/.../nsekhar/linux-davinci into fixes oscardagrach (2): arm64: dts: hikey: Define wl1835 power capabilities arm64: dts: hikey960: Define wl1837 power capabilities arch/arm/boot/dts/da850.dtsi | 6 +- arch/arm/mach-davinci/board-da850-evm.c | 2 +- arch/arm64/boot/dts/amlogic/meson-axg-s400.dts| 15 ++- arch/arm64/boot/dts/amlogic/meson-axg.dtsi| 4 ++-- arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 12 +--- arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi | 2 +- .../boot/dts/amlogic/meson-gxl-s905x-libretech-cc.dts | 3 --- arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi | 7 +++ arch/arm64/boot/dts/amlogic/meson-gxl.dtsi| 8 arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 2 ++ arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts| 2 ++ 11 files changed, 39 insertions(+), 24 deletions(-)
Re: [PATCH] staging: mt7621-pinctrl: Replaces "unsigned" with "unsigned int", fixes mixed indentation, and puts spaces after commas.
On Sat, Jun 30, 2018 at 01:17:29PM -0400, Peter Vernia wrote: > Signed-off-by: Peter Vernia The subject is over 72 characters or whatever the limit is and there isn't a commit message. regards, dan carpenter
Re: [PATCH 1/2] drivers: core: Don't try to use a dead glue_dir
On Thu, Jun 28, 2018 at 7:21 PM Benjamin Herrenschmidt wrote: > > Under some circumstances (such as when using kobject debugging) > a gluedir whose kref is 0 might remain in the class kset for > a long time. The reason is that we don't actively remove glue > dirs when they become empty, but instead rely on the implicit > removal done by kobject_release(), which can happen some amount > of time after the last kobject_put(). > > Using such a dead object is a bad idea and will lead to warnings > and crashes. So with the other patch in mind, here's my comments on this one. Pick one of two scenarios: (a) it's obviously correct. We obviously can *not* take an object with a zero refcount, because it is already been scheduled for kobject_cleanup(), and incrementing the refcount is simply fundamentally wrong, because incrementing the refcount won't unschedule the deletion of the object. (b) the patch is wrong, and our "kobject_get()" should cancel the kobject_cleanup() instead. There are problems with both of the above cases. The "patch is obviously correct" case leads to another issue: why would kobject_get() _ever_ succeed on an object wioth a zero refcount? IOW, why do we have kobject_get() vs kobject_get_unless_zero() in the first place? It is *never* ok to get an kobject with a zero refcount because of the above "it's already scheduled for deletion" issue. The (b) case sounds nice, and would actually fix the problem that patch 2/2 was tryihng to address, and would make CONFIG_DEBUG_KOBJECT_RELEASE work. HOWEVER. It's completely untenable in reality - it's a nightmare from a locking standpoint, because kref_put() literally depends not on locking, but on the exclusive "went to zero". So I think (b) is practically not acceptable. Which means that (a) is the right reaction, and "kobject_get()" on an object with a zero refcount is _always_ wrong. But that says that "yes, the patch is obviously correct", but it also says "the patch should be pointless, because kobject_get() should just _always_ have the semantics of "kobject_get_unless_zero()", and the latter shouldn't even exist. Greg? When would it possibly be valid to do "kobject_get()" on a zero refcount object? I don't see it. But this is all very much your code. Linus
Re: [PATCH] PCI/AER: Adopt lspci naming convention for AER prints
On Tue, Jun 26, 2018 at 11:44:15AM -0400, Tyler Baicar wrote:
> lspci uses abbreviated naming for AER error strings. Adopt the
> same naming convention for the AER printing so they match.
>
> Signed-off-by: Tyler Baicar
Applied with Oza's reviewed-by to pci/aer for v4.19, thanks!
> ---
> drivers/pci/pcie/aer.c | 46 +++---
> 1 file changed, 23 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index a2e8838..08a5219 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -459,22 +459,22 @@ int pci_aer_init(struct pci_dev *dev)
> };
>
> static const char *aer_correctable_error_string[] = {
> - "Receiver Error", /* Bit Position 0 */
> + "RxErr",/* Bit Position 0 */
> NULL,
> NULL,
> NULL,
> NULL,
> NULL,
> - "Bad TLP", /* Bit Position 6 */
> - "Bad DLLP", /* Bit Position 7 */
> - "RELAY_NUM Rollover", /* Bit Position 8 */
> + "BadTLP", /* Bit Position 6 */
> + "BadDLLP", /* Bit Position 7 */
> + "Rollover", /* Bit Position 8 */
> NULL,
> NULL,
> NULL,
> - "Replay Timer Timeout", /* Bit Position 12 */
> - "Advisory Non-Fatal", /* Bit Position 13 */
> - "Corrected Internal Error", /* Bit Position 14 */
> - "Header Log Overflow", /* Bit Position 15 */
> + "Timeout", /* Bit Position 12 */
> + "NonFatalErr", /* Bit Position 13 */
> + "CorrIntErr", /* Bit Position 14 */
> + "HeaderOF", /* Bit Position 15 */
> };
>
> static const char *aer_uncorrectable_error_string[] = {
> @@ -482,28 +482,28 @@ int pci_aer_init(struct pci_dev *dev)
> NULL,
> NULL,
> NULL,
> - "Data Link Protocol", /* Bit Position 4 */
> - "Surprise Down Error", /* Bit Position 5 */
> + "DLP", /* Bit Position 4 */
> + "SDES", /* Bit Position 5 */
> NULL,
> NULL,
> NULL,
> NULL,
> NULL,
> NULL,
> - "Poisoned TLP", /* Bit Position 12 */
> - "Flow Control Protocol",/* Bit Position 13 */
> - "Completion Timeout", /* Bit Position 14 */
> - "Completer Abort", /* Bit Position 15 */
> - "Unexpected Completion",/* Bit Position 16 */
> - "Receiver Overflow",/* Bit Position 17 */
> - "Malformed TLP",/* Bit Position 18 */
> + "TLP", /* Bit Position 12 */
> + "FCP", /* Bit Position 13 */
> + "CmpltTO", /* Bit Position 14 */
> + "CmpltAbrt",/* Bit Position 15 */
> + "UnxCmplt", /* Bit Position 16 */
> + "RxOF", /* Bit Position 17 */
> + "MalfTLP", /* Bit Position 18 */
> "ECRC", /* Bit Position 19 */
> - "Unsupported Request", /* Bit Position 20 */
> - "ACS Violation",/* Bit Position 21 */
> - "Uncorrectable Internal Error", /* Bit Position 22 */
> - "MC Blocked TLP", /* Bit Position 23 */
> - "AtomicOp Egress Blocked", /* Bit Position 24 */
> - "TLP Prefix Blocked Error", /* Bit Position 25 */
> + "UnsupReq", /* Bit Position 20 */
> + "ACSViol", /* Bit Position 21 */
> + "UncorrIntErr", /* Bit Position 22 */
> + "BlockedTLP", /* Bit Position 23 */
> + "AtomicOpBlocked", /* Bit Position 24 */
> + "TLPBlockedErr",/* Bit Position 25 */
> };
>
> static const char *aer_agent_string[] = {
> --
> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
> Technologies, Inc.
> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project.
>
Re: [PATCH v3] add param that allows bootline control of hardened usercopy
On Wed, Jun 27, 2018 at 5:07 AM, Chris von Recklinghausen
wrote:
> Enabling HARDENED_USER_COPY causes measurable regressions in
nit: HARDENED_USERCOPY
> networking performance, up to 8% under UDP flood.
>
> I'm running an a small packet UDP flood using pktgen vs. a host b2b
> connected. On the receiver side the UDP packets are processed by a
> simple user space process that just reads and drops them:
>
> https://github.com/netoptimizer/network-testing/blob/master/src/udp_sink.c
>
> Not very useful from a functional PoV, but it helps to pin-point
> bottlenecks in the networking stack.
>
> When running a kernel with CONFIG_HARDENED_USERCOPY=y, I see a 5-8%
> regression in the receive tput, compared to the same kernel without
> this option enabled.
>
> With CONFIG_HARDENED_USERCOPY=y, perf shows ~6% of CPU time spent
> cumulatively in __check_object_size (~4%) and __virt_addr_valid (~2%).
>
> The call-chain is:
>
> __GI___libc_recvfrom
> entry_SYSCALL_64_after_hwframe
> do_syscall_64
> __x64_sys_recvfrom
> __sys_recvfrom
> inet_recvmsg
> udp_recvmsg
> __check_object_size
>
> udp_recvmsg() actually calls copy_to_iter() (inlined) and the latters
> calls check_copy_size() (again, inlined).
Thanks for including these details!
>
> A generic distro may want to enable HARDENED_USER_COPY in their default
same nit :)
> kernel config, but at the same time, such distro may want to be able to
> avoid the performance penalties in with the default configuration and
> disable the stricter check on a per-boot basis.
>
> This change adds a boot parameter that conditionally disables
> HARDENED_USERCOPY at boot time.
>
> v2->v3:
> add benchmark details to commit comments
> Don't add new item to Documentation/admin-guide/kernel-parameters.rst
> rename boot param to "hardened_usercopy="
> update description in Documentation/admin-guide/kernel-parameters.txt
> static_branch_likely -> static_branch_unlikely
> add __ro_after_init versions of DEFINE_STATIC_KEY_FALSE,
> DEFINE_STATIC_KEY_TRUE
> disable_huc_atboot -> enable_checks (strtobool "on" == true)
>
> v1->v2:
> remove CONFIG_HUC_DEFAULT_OFF
> default is now enabled, boot param disables
> move check to __check_object_size so as to not break optimization of
> __builtin_constant_p()
> include linux/atomic.h before linux/jump_label.h
>
> Signed-off-by: Chris von Recklinghausen
> ---
> .../admin-guide/kernel-parameters.txt | 11
> include/linux/jump_label.h| 6 +
> include/linux/thread_info.h | 5
> mm/usercopy.c | 26 +++
> 4 files changed, 48 insertions(+)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index efc7aa7a0670..560d4dc66f02 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -816,6 +816,17 @@
> disable=[IPV6]
> See Documentation/networking/ipv6.txt.
>
> + hardened_usercopy=
> +[KNL] Under CONFIG_HARDENED_USERCOPY, whether
> +hardening is enabled for this boot. Hardened
> +usercopy checking is used to protect the kernel
> +from reading or writing beyond known memory
> +allocation boundaries as a proactive defense
> +against bounds-checking flaws in the kernel's
> +copy_to_user()/copy_from_user() interface.
> +on Perform hardened usercopy checks (default).
> +off Disable hardened usercopy checks.
> +
> disable_radix [PPC]
> Disable RADIX MMU mode on POWER9
>
> diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
> index b46b541c67c4..1a0b6f17a5d6 100644
> --- a/include/linux/jump_label.h
> +++ b/include/linux/jump_label.h
> @@ -299,12 +299,18 @@ struct static_key_false {
> #define DEFINE_STATIC_KEY_TRUE(name) \
> struct static_key_true name = STATIC_KEY_TRUE_INIT
>
> +#define DEFINE_STATIC_KEY_TRUE_RO(name)\
> + struct static_key_true name __ro_after_init = STATIC_KEY_TRUE_INIT
> +
> #define DECLARE_STATIC_KEY_TRUE(name) \
> extern struct static_key_true name
>
> #define DEFINE_STATIC_KEY_FALSE(name) \
> struct static_key_false name = STATIC_KEY_FALSE_INIT
>
> +#define DEFINE_STATIC_KEY_FALSE_RO(name) \
> + struct static_key_false name __ro_after_init = STATIC_KEY_FALSE_INIT
> +
> #define DECLARE_STATIC_KEY_FALSE(name) \
> extern struct static_key_false name
>
> diff --git a/include/linux/thread_info.h b/include/linux/thread_info.h
> index 8d8821b3689a..ab24fe2d3f87 100644
> --- a/include/linux/thread_info.h
> +++ b/include/li
[GIT PULL] parisc architecture code cleanups and fixes
Hi Linus, please pull some patches for the parisc architecture from: git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-4.18-1 Nothing exiting in this patchset, just small cleanups of header files, kernel now defaults to 4 CPUs when building a SMP kernel, mark 16- and 64-kB page sizes broken and addition of the new io_pgetevents syscall. Thanks, Helge Andy Shevchenko (1): parisc: Convert printk(KERN_LEVEL) to pr_lvl() Helge Deller (6): parisc: Drop struct sigaction from not exported header file parisc: Mark 16kB and 64kB page sizes BROKEN parisc: Default to 4 SMP CPUs parisc: Wire up io_pgetevents syscall parisc: Reduce debug output in unwind code parisc: Build kernel without -ffunction-sections arch/parisc/Kconfig | 6 +++--- arch/parisc/Makefile | 4 arch/parisc/include/asm/signal.h | 8 arch/parisc/include/uapi/asm/unistd.h | 3 ++- arch/parisc/kernel/drivers.c | 25 + arch/parisc/kernel/syscall_table.S| 1 + arch/parisc/kernel/unwind.c | 4 ++-- 7 files changed, 17 insertions(+), 34 deletions(-)
