Re: [PATCH 4/6] crypto: hkdf - RFC5869 Key Derivation Function

[Stephan Müller]

Am Samstag, 12. Januar 2019, 10:55:35 CET schrieb Herbert Xu:

Hi Herbert,

> On Fri, Jan 11, 2019 at 09:12:54PM -0800, Eric Biggers wrote:
> > Hi Stephan,
> > 
> > On Fri, Jan 11, 2019 at 08:10:39PM +0100, Stephan Müller wrote:
> > > The RFC5869 compliant Key Derivation Function is implemented as a
> > > random number generator considering that it behaves like a deterministic
> > > RNG.
> > 
> > Thanks for the proof of concept!  I guess it ended up okay.  But can you
> > explain more the benefits of using the crypto_rng interface, as opposed
> > to just some crypto_hkdf_*() helper functions that are exported for
> > modules to use?
> I agree.  I see no benefit in adding this through the RNG API as
> opposed to just providing it as a helper.  If some form of hardware
> acceleration were to eventuate in the future we could always revisit
> this.

The advantages for using the kernel crypto API to add KDFs as opposed to 
adding helper wrappers are the following in my view:

- employment of the kernel crypto API testmgr - invocation of the testmgr is 
transparent and thus already provided without any additional code to link to 
it

- FIPS 140-2 compliance: To mark a KDF as FIPS 140-2 approved cipher, it must 
be subject to a known-answer self test (implemented by the testmgr) as well as 
to an enforcement of the integrity check verification. In FIPS 140-2 mode, the 
kernel crypto API panic()s when a kernel crypto API module is loaded and its 
signature does not check out. As this is only relevant for crypto modules (and 
not arbitrary other kernel modules), this is implemented with the invocations 
the crypto_register_alg as well as crypto_register_template functions. Thus, 
when using a wrapper code to implement the KDF, they can per definition not be 
FIPS 140-2 approved.

- The invoker of a KDF has one consistent API. This implies that the KDF 
selection now becomes more of a "configuration" choice. For example, when you 
look at the KDF use case for the keys subsystem (security/keys/dh.c), 
selecting the type of KDF would only necessitate a change of a string 
referencing the KDF. A lot of people somehow favor the extract-and-expand KDFs 
over the traditional KDFs. Now, that the RFC5869 HKDF is also approved as per 
SP800-56A rev3, I could see that folks may want to switch to HKDF for the key 
management. When we have a common API, this choice could even be left to the 
caller.

The question may arise why to plug the KDFs into RNGs. The answer is quite 
simple: KDFs are a form of random number generator. In that they take some 
input for initialization (aka seed, salt, key, personalization string). Then 
they produce pseudo-random bit sequences of arbitrary length. Possibly the 
generation operation can be modified by providing some additional input to be 
used by the generation process (aka label, context, info string, additional 
information string). Thus, the RNG interface is a natural fit for the KDFs.

Ciao
Stephan

Re: [RFT][PATCH v1] gpiolib: acpi: Introduce ACPI_GPIO_QUIRK_ONLY_GPIOIO

[Hans de Goede]

Hi,

On 11-01-19 20:49, Andy Shevchenko wrote:

On Fri, Jan 11, 2019 at 03:21:39PM +0100, Linus Walleij wrote:

On Tue, Jan 8, 2019 at 7:02 PM Andy Shevchenko
 wrote:


New quirk enforces search for GPIO based on its type.
Note, supplied index in the mapping table must be 0.

Signed-off-by: Andy Shevchenko 


(...)


  sound/soc/intel/boards/bytcr_rt5651.c | 74 ---


Do we have an ACK from the maintainer of this file?
It's Hans I think. Ideally also from Mark Brown.


I hope to get Hans' Tested-by on this.


Yes I've testing this on my TODO.

Regards,

Hans

Re: [PATCH 3.18 00/47] 3.18.132-stable review

[Greg Kroah-Hartman]

On Sat, Jan 12, 2019 at 09:42:21AM -0800, Guenter Roeck wrote:
> On 1/11/19 6:07 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.132 release.
> > There are 47 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Jan 13 13:09:31 UTC 2019.
> > Anything received after that time might be too late.
> > 
> 
> 
> Build results:
>   total: 155 pass: 155 fail: 0
> Qemu test results:
>   total: 217 pass: 202 fail: 15
> Failed tests:
>   sparc32:SPARCClassic:nosmp:scsi:hd
>   sparc32:SPARCbook:nosmp:scsi:cd
>   sparc32:LX:nosmp:noapc:scsi:hd
>   sparc32:SS-4:nosmp:initrd
>   sparc32:SS-5:nosmp:scsi:hd
>   sparc32:SS-10:nosmp:scsi:cd
>   sparc32:SS-20:nosmp:scsi:hd
>   sparc32:SS-600MP:nosmp:scsi:hd
>   sparc32:Voyager:nosmp:noapc:scsi:hd
>   sparc32:SS-4:smp:scsi:hd
>   sparc32:SS-5:smp:scsi:cd
>   sparc32:SS-10:smp:scsi:hd
>   sparc32:SS-20:smp:scsi:hd
>   sparc32:SS-600MP:smp:scsi:hd
>   sparc32:Voyager:smp:noapc:scsi:hd
> 
> The failed sparc32 tests are really nothing new, but were discovered due
> to more extensive testing. Observed behavior is a boot hang. sparc32 images
> in v3.18.y (and v3.16.y) have probably been non-functional since commit
> 16c193364b4d ("sparc: Harden signal return frame checks."). The problem
> was fixed upstream with commit 07b5ab3f71d3 ("sparc32: Fix inverted
> invalid_frame_pointer checks on sigreturns"), and applying the same
> commit to v3.18.y (and v3.16.y) fixes the problem.

I'll queue that patch up after this release, thanks.

And thanks for the results of all of the other kernel trees as well.

greg k-h

Re: [PATCH 1/3] arm64: dts: qcom: sdm845: Add Coresight support

[Bjorn Andersson]

On Wed 09 Jan 09:46 PST 2019, Sai Prakash Ranjan wrote:

> Add coresight components found on Qualcomm SDM845 SoC.
> 
> Signed-off-by: Sai Prakash Ranjan 

Hi Sai,

The content of this patch looks good, but please fold it into
sdm845.dtsi (keep the nodes sorted by address).

And mention below the --- that this depends on my AMBA bus pclk change
and include the URL:

https://lore.kernel.org/lkml/20190106080915.4493-7-bjorn.anders...@linaro.org/

Regards,
Bjorn

> ---
>  .../arm64/boot/dts/qcom/sdm845-coresight.dtsi | 437 ++
>  arch/arm64/boot/dts/qcom/sdm845.dtsi  |   2 +
>  2 files changed, 439 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/sdm845-coresight.dtsi
> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-coresight.dtsi 
> b/arch/arm64/boot/dts/qcom/sdm845-coresight.dtsi
> new file mode 100644
> index ..b6ef250b9186
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sdm845-coresight.dtsi
> @@ -0,0 +1,437 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * SDM845 Coresight DTS
> + *
> + * Copyright (c) 2019, The Linux Foundation. All rights reserved.
> + */
> +
> + {
> + stm@6002000 {
> + compatible = "arm,coresight-stm", "arm,primecell";
> + reg = <0x06002000 0x1000>,
> +   <0x1628 0x18>;
> + reg-names = "stm-base", "stm-stimulus-base";
> +
> + power-domains = <_qmp AOSS_QMP_QDSS_CLK>;
> +
> + out-ports {
> + port {
> + stm_out: endpoint {
> + remote-endpoint = <_in7>;
> + };
> + };
> + };
> + };
> +
> + funnel@6041000 {
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0x06041000 0x1000>;
> +
> + power-domains = <_qmp AOSS_QMP_QDSS_CLK>;
> +
> + out-ports {
> + port {
> + funnel0_out: endpoint {
> + remote-endpoint =
> + <_funnel_in0>;
> + };
> + };
> + };
> +
> + in-ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@7 {
> + reg = <7>;
> + funnel0_in7: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> + };
> + };
> +
> + funnel@6043000 {
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0x06043000 0x1000>;
> +
> + power-domains = <_qmp AOSS_QMP_QDSS_CLK>;
> +
> + out-ports {
> + port {
> + funnel2_out: endpoint {
> + remote-endpoint =
> +   <_funnel_in2>;
> + };
> + };
> + };
> +
> + in-ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@5 {
> + reg = <5>;
> + funnel2_in5: endpoint {
> + remote-endpoint =
> +   <_merge_funnel_out>;
> + };
> + };
> + };
> + };
> +
> + funnel@6045000 {
> + compatible = "arm,coresight-funnel", "arm,primecell";
> + reg = <0x06045000 0x1000>;
> +
> + power-domains = <_qmp AOSS_QMP_QDSS_CLK>;
> +
> + out-ports {
> + port {
> + merge_funnel_out: endpoint {
> + remote-endpoint = <_in>;
> + };
> + };
> + };
> +
> + in-ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + merge_funnel_in0: endpoint {
> + remote-endpoint =
> + <_out>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> + merge_funnel_in2: endpoint {
> + remote-endpoint =
> + <_out>;
> + };
> + };
> + };
> + };
> +
> + replicator@6046000 {
> + compatible = "arm,coresight-dynamic-replicator", 
> 

Re: [PATCH 4.20 41/65] Revert "powerpc/tm: Unset MSR[TS] if not recheckpointing"

[Greg Kroah-Hartman]

On Sat, Jan 12, 2019 at 10:35:59PM +0100, Christoph Biedl wrote:
> Greg Kroah-Hartman wrote...
> 
> > 4.20-stable review patch.  If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Greg Kroah-Hartman 
> >
> > This reverts commit d412deb85a4aada382352a8202beb7af8921cd53 which is
> > commit 6f5b9f018f4c7686fd944d920209d1382d320e4e upstream.
> >
> > It breaks the powerpc build, so drop it from the tree until a fix goes
> > upstream.
> 
> Is this necessary on 4.20? The build failures I reported were on 4.19
> only. The 4.20.2-rc1 kernel for my Powermac G5 builds with and without
> that patch, both boot fine, no visible differences. Again however, Breno
> is authoritative here.

If there's no difference on 4.20, then maybe it's not needed there?  :)

And yes, I would like confirmation from Breno as well.

thanks,

greg k-h

Re: [PATCH 4.14 058/105] tools: fix cross-compile var clobbering

[Greg Kroah-Hartman]

On Sat, Jan 12, 2019 at 01:35:35PM -0800, Martin Kelly wrote:
> On 1/12/19 1:18 PM, Sudip Mukherjee wrote:
> > Hi Greg,
> > 
> > On Fri, Jan 11, 2019 at 2:34 PM Greg Kroah-Hartman
> >  wrote:
> > > 
> > > 4.14-stable review patch.  If anyone has any objections, please let me 
> > > know.
> > > 
> > > --
> > > 
> > > From: Martin Kelly 
> > > 
> > > commit 7ed1c1901fe52e6c5828deb155920b44b0adabb1 upstream.
> > 
> > This was fixed upstream by 755396163148 ("tools: power/acpi, revert to
> > LD = gcc")
> > 
> > 
> 
> Yes, both patches should be applied. This patch fixed a bunch of Makefiles
> but caused a regression in power/acpi, which is fixed by
> 755396163148.

Thanks all, now queued up.

greg k-h

Re: [PATCH 4.14 024/105] bnx2x: Remove configured vlans as part of unload sequence.

[Greg Kroah-Hartman]

On Sat, Jan 12, 2019 at 09:22:40PM +, Sudip Mukherjee wrote:
> Hi Greg,
> 
> On Fri, Jan 11, 2019 at 2:33 PM Greg Kroah-Hartman
>  wrote:
> >
> > 4.14-stable review patch.  If anyone has any objections, please let me know.
> >
> > --
> >
> > [ Upstream commit 04f05230c5c13b1384f66f5186a68d7499e34622 ]
> 
> This was fixed upstream by 38355a5f9a22 ("bnx2x: Fix NULL pointer
> dereference in bnx2x_del_all_vlans() on some hw")

Thanks for catching this, queued up to a bunch of trees now.

greg k-h

Re: [BUG] virtio-gpu hung when booting ARM64 virtual machine

[Zheng Xiang]

Sorry for that I missed typing 'd' in the email addreslist.

On 2019/1/10 20:52, Zheng Xiang wrote:
> Hi all,
> 
> Recently I encountered a problem that virtio-gpu driver would have a very low 
> chance of getting hung
> when I boot VM from linux kernel 4.19 on ARM64 server by using qemu. The 
> dmesg log shows bellow:
> 
> [  242.782731] INFO: task systemd:1 blocked for more than 120 seconds.
> [  242.782738]   Tainted: GE 4.19.5-1.2.32.aarch64 #1
> [  242.782739] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
> disables this message.
> [  242.782743] systemd D0 1  0 0x
> [  242.782748] Call trace:
> [  242.782767]  __switch_to+0x94/0xd8
> [  242.782779]  __schedule+0x228/0x8a8
> [  242.782782]  schedule+0x2c/0x88
> [  242.782785]  schedule_timeout+0x234/0x470
> [  242.782787]  __down+0x88/0x108
> [  242.782792]  down+0x88/0xa0
> [  242.782798]  console_lock+0x24/0x48
> [  242.782799]  console_device+0x1c/0x88
> [  242.782806]  tty_lookup_driver+0xa8/0x128
> [  242.782808]  tty_open+0x1f4/0x418
> [  242.782813]  chrdev_open+0xd4/0x248
> [  242.782816]  do_dentry_open+0x1b0/0x380
> [  242.782818]  vfs_open+0x38/0x48
> [  242.782822]  do_last+0x294/0xf58
> [  242.782824]  path_openat+0x88/0x2a0
> [  242.782827]  do_filp_open+0x88/0x108
> [  242.782829]  do_sys_open+0x1a8/0x238
> [  242.782831]  __arm64_sys_openat+0x2c/0x38
> [  242.782834]  el0_svc_common+0x78/0x100
> [  242.782836]  el0_svc_handler+0x38/0x88
> [  242.782839]  el0_svc+0x8/0xc
> [  242.782850] INFO: task kworker/0:1:13 blocked for more than 120 
> seconds.
> [  242.782851]   Tainted: GE 4.19.5-1.2.32.aarch64 #1
> [  242.782853] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
> disables this message.
> [  242.782855] kworker/0:1 D013  2 0x0028
> [  242.782872] Workqueue: events drm_fb_helper_dirty_work
> [  242.782875] Call trace:
> [  242.782877]  __switch_to+0x94/0xd8
> [  242.782880]  __schedule+0x228/0x8a8
> [  242.782882]  schedule+0x2c/0x88
> [  242.782902]  virtio_gpu_queue_ctrl_buffer_locked+0x12c/0x220 
> [virtio_gpu]
> [  242.782906]  virtio_gpu_queue_ctrl_buffer+0x58/0x80 [virtio_gpu]
> [  242.782911]  virtio_gpu_cmd_resource_flush+0x8c/0xb0 [virtio_gpu]
> [  242.782915]  virtio_gpu_surface_dirty+0x60/0x110 [virtio_gpu]
> [  242.782920]  virtio_gpu_framebuffer_surface_dirty+0x34/0x48 
> [virtio_gpu]
> [  242.782922]  drm_fb_helper_dirty_work+0x170/0x1b0
> [  242.782928]  process_one_work+0x1f4/0x458
> [  242.782930]  worker_thread+0x50/0x4c8
> [  242.782932]  kthread+0x134/0x138
> [  242.782934]  ret_from_fork+0x10/0x1c
> [  242.782946] INFO: task kworker/1:1:34 blocked for more than 120 
> seconds.
> [  242.782948]   Tainted: GE 4.19.5-1.2.32.aarch64 #1
> [  242.782949] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
> disables this message.
> [  242.782950] kworker/1:1 D034  2 0x0028
> [  242.782960] Workqueue: events virtio_gpu_fb_dirty_work [virtio_gpu]
> [  242.782963] Call trace:
> [  242.782965]  __switch_to+0x94/0xd8
> [  242.782967]  __schedule+0x228/0x8a8
> [  242.782969]  schedule+0x2c/0x88
> [  242.782974]  virtio_gpu_queue_fenced_ctrl_buffer+0x12c/0x160 
> [virtio_gpu]
> [  242.782978]  virtio_gpu_cmd_transfer_to_host_2d+0xa4/0xd0 [virtio_gpu]
> [  242.782981]  virtio_gpu_dirty_update+0x184/0x200 [virtio_gpu]
> [  242.782986]  virtio_gpu_fb_dirty_work+0x3c/0x48 [virtio_gpu]
> [  242.782988]  process_one_work+0x1f4/0x458
> [  242.782990]  worker_thread+0x50/0x4c8
> [  242.782991]  kthread+0x134/0x138
> [  242.782993]  ret_from_fork+0x10/0x1c
> [  242.783033] INFO: task kworker/0:3:3706 blocked for more than 120 
> seconds.
> [  242.783034]   Tainted: GE 4.19.5-1.2.32.aarch64 #1
> [  242.783035] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" 
> disables this message.
> [  242.783037] kworker/0:3 D0  3706  2 0x0028
> [  242.783046] Workqueue: events console_callback
> [  242.783048] Call trace:
> [  242.783050]  __switch_to+0x94/0xd8
> [  242.783053]  __schedule+0x228/0x8a8
> [  242.783055]  schedule+0x2c/0x88
> [  242.783057]  schedule_timeout+0x234/0x470
> [  242.783059]  __down+0x88/0x108
> [  242.783061]  down+0x88/0xa0
> [  242.783063]  console_lock+0x24/0x48
> [  242.783065]  console_callback+0x40/0x198
> [  242.783067]  process_one_work+0x1f4/0x458
> [  242.783068]  worker_thread+0x50/0x4c8
> [  242.783070]  kthread+0x134/0x138
> [  242.783072]  ret_from_fork+0x10/0x1c
> [  242.783075] INFO: task kworker/u8:6:4901 blocked for more than 120 
> seconds.
> [  242.783077]   Tainted: GE 

[PATCH v5] ftrace: support early boot function tracing

[Abderrahmane Benbachir]

Hi Steven, just noticed that the last patch had issue with the formatting,
this patch is the good one.
Thanks.

Previous changes:
PATCH v1: Initial patch
PATCH v2:
   Removed arch specific code and use the default clock.
   Add more code re-usability
   Add HAVE_EARLY_BOOT_FTRACE config option, which will be disabled by default
PATCH v3:
   Write early boot temporary buffer to a sub-buffer instead of the global one.
   Improve Kconfig help text.

PATCH v4 :
Some code refactoring.

PATCH v5 :
fixing the build failers on arch i386.

Patch starts here:
--

The early boot tracing will start from the beginning of start_kernel()
and will stop at ftrace_init()

start_kernel()
{
  ftrace_early_init() <--- start early boot function tracing
  ...
  (calls)
  ...
  ftrace_init()   <--- stop early boot function tracing
  early_trace_init();
  ...
}

The events are placed in a temporary buffer, which will be copied to
the trace buffer after memory setup.

Dynamic tracing is not implemented with live patching, we use
ftrace_filter and ftrace_notrace to find which functions to be
filtered (traced / not traced), then during the callback from
mcount hook, we do binary search lookup to decide which function
to save and which one to discard.

Signed-off-by: Abderrahmane Benbachir 
Cc: Steven Rostedt 
Cc: Ingo Molnar 
Cc: Peter Zijlstra 
Cc: Mathieu Desnoyers 
Cc: linux-kernel@vger.kernel.org

---
 arch/x86/Kconfig|   1 +
 arch/x86/kernel/ftrace_32.S |  45 --
 arch/x86/kernel/ftrace_64.S |  14 ++
 include/linux/ftrace.h  |  18 ++-
 init/main.c |   1 +
 kernel/trace/Kconfig|  51 +++
 kernel/trace/ftrace.c   | 294 +++-
 kernel/trace/trace.c|  41 +
 8 files changed, 453 insertions(+), 12 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 8689e794a43c..f4f754d4aa7a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -152,6 +152,7 @@ config X86
select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_FUNCTION_TRACER
+   select HAVE_EARLY_BOOT_FTRACE
select HAVE_GCC_PLUGINS
select HAVE_HW_BREAKPOINT
select HAVE_IDE
diff --git a/arch/x86/kernel/ftrace_32.S b/arch/x86/kernel/ftrace_32.S
index 4c8440de3355..a247cbf4c529 100644
--- a/arch/x86/kernel/ftrace_32.S
+++ b/arch/x86/kernel/ftrace_32.S
@@ -31,12 +31,8 @@ EXPORT_SYMBOL(mcount)
 # define MCOUNT_FRAME  0   /* using frame = false */
 #endif
 
-ENTRY(function_hook)
-   ret
-END(function_hook)
-
-ENTRY(ftrace_caller)
 
+.macro save_mcount_regs
 #ifdef USING_FRAME_POINTER
 # ifdef CC_USING_FENTRY
/*
@@ -73,11 +69,9 @@ ENTRY(ftrace_caller)
 
movlfunction_trace_op, %ecx
subl$MCOUNT_INSN_SIZE, %eax
+   .endm
 
-.globl ftrace_call
-ftrace_call:
-   callftrace_stub
-
+.macro restore_mcount_regs
addl$4, %esp/* skip NULL pointer */
popl%edx
popl%ecx
@@ -90,6 +84,39 @@ ftrace_call:
addl$4, %esp/* skip parent ip */
 # endif
 #endif
+   .endm
+
+ENTRY(function_hook)
+#ifdef CONFIG_EARLY_BOOT_FUNCTION_TRACER
+   cmpl$__PAGE_OFFSET, %esp
+   jb  early_boot_stub /* Paging not enabled yet? */
+
+   cmpl$ftrace_stub, ftrace_early_boot_trace_function
+   jnz early_boot_trace
+
+early_boot_stub:
+   ret
+
+early_boot_trace:
+   save_mcount_regs
+   call*ftrace_early_boot_trace_function
+   restore_mcount_regs
+
+   jmp early_boot_stub
+#else
+   ret
+#endif
+END(function_hook)
+
+ENTRY(ftrace_caller)
+   save_mcount_regs
+
+.globl ftrace_call
+ftrace_call:
+   callftrace_stub
+
+   restore_mcount_regs
+
 .Lftrace_ret:
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
 .globl ftrace_graph_call
diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S
index 91b2cff4b79a..81736c6e2f9b 100644
--- a/arch/x86/kernel/ftrace_64.S
+++ b/arch/x86/kernel/ftrace_64.S
@@ -151,7 +151,21 @@ EXPORT_SYMBOL(mcount)
 #ifdef CONFIG_DYNAMIC_FTRACE
 
 ENTRY(function_hook)
+# ifdef CONFIG_EARLY_BOOT_FUNCTION_TRACER
+   cmpq $ftrace_stub, ftrace_early_boot_trace_function
+   jnz early_boot_trace
+
+early_boot_stub:
retq
+
+early_boot_trace:
+   save_mcount_regs
+   call *ftrace_early_boot_trace_function
+   restore_mcount_regs
+   jmp early_boot_stub
+# else
+   retq
+# endif
 ENDPROC(function_hook)
 
 ENTRY(ftrace_caller)
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index dd16e8218db3..b48382de1fd4 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -239,6 +239,18 @@ static inline void ftrace_free_init_mem(void) { }
 static inline void ftrace_free_mem(struct module *mod, void *start, void *end) 
{ }
 #endif /* 

Re: [PATCH net] net: phy: meson-gxl: Use the genphy_soft_reset callback

[Florian Fainelli]

On January 12, 2019 4:22:55 PM PST, Timotej Lazar  
wrote:
>Since the referenced commit, Ethernet fails to come up at boot on the
>board meson-gxl-s905x-libretech-cc. Fix this by re-enabling the
>genphy_soft_reset callback for the Amlogic Meson GXL PHY driver.
>
>Fixes: 6e2d85ec0559 ("net: phy: Stop with excessive soft reset")
>Signed-off-by: Timotej Lazar 

Reviewed-by: Florian Fainelli 
-- 
Florian

Do you need to enhance your photos?

[Ruby]

Do you need to edit your photos?

Here are the editing service we mostly for the photos from our clients.
Photos cut out background , clipping path, and also retouching.

You may send some photos to us. we will let our editing staffs to work on
them.

Thanks,
Ruby

[PATCH] Documentation/ABI: Correct mlxreg-io KernelVersion for 5.0

[Darren Hart (VMware)]

The mlxreg-io for the merge window assumed 4.21 as the next kernel
version. Replace 4.21 with 5.0.

Signed-off-by: Darren Hart (VMware) 
---
 Documentation/ABI/stable/sysfs-driver-mlxreg-io | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/ABI/stable/sysfs-driver-mlxreg-io 
b/Documentation/ABI/stable/sysfs-driver-mlxreg-io
index 9b642669cb16..169fe08a649b 100644
--- a/Documentation/ABI/stable/sysfs-driver-mlxreg-io
+++ b/Documentation/ABI/stable/sysfs-driver-mlxreg-io
@@ -24,7 +24,7 @@ What: 
/sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/
cpld3_version
 
 Date:  November 2018
-KernelVersion: 4.21
+KernelVersion: 5.0
 Contact:   Vadim Pasternak 
 Description:   These files show with which CPLD versions have been burned
on LED board.
@@ -35,7 +35,7 @@ What: 
/sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/
jtag_enable
 
 Date:  November 2018
-KernelVersion: 4.21
+KernelVersion: 5.0
 Contact:   Vadim Pasternak 
 Description:   These files enable and disable the access to the JTAG domain.
By default access to the JTAG domain is disabled.
@@ -105,7 +105,7 @@ What:   
/sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/
reset_voltmon_upgrade_fail
 
 Date:  November 2018
-KernelVersion: 4.21
+KernelVersion: 5.0
 Contact:   Vadim Pasternak 
 Description:   These files show the system reset cause, as following: ComEx
power fail, reset from ComEx, system platform reset, reset
-- 
2.17.2


-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH] platform/x86: intel-hid: Missing power button release on some Dell models

[Darren Hart]

On Mon, Jan 07, 2019 at 03:36:48PM +, mario.limoncie...@dell.com wrote:
> 
> 
> > -Original Message-
> > From: platform-driver-x86-ow...@vger.kernel.org  > ow...@vger.kernel.org> On Behalf Of Jérôme de Bretagne
> > Sent: Sunday, January 6, 2019 11:57 AM
> > To: Alex Hung
> > Cc: platform-driver-...@vger.kernel.org; Andy Shevchenko; Darren Hart;
> > Limonciello, Mario; Rafael J. Wysocki; Chih-Wei Huang; Tristian Celestin; 
> > linux-
> > ker...@vger.kernel.org
> > Subject: [PATCH] platform/x86: intel-hid: Missing power button release on 
> > some
> > Dell models
> > 
> > 
> > [EXTERNAL EMAIL]
> > 
> > Power button suspend for some Dell models was added in:
> > 
> > commit 821b85366284 (intel-hid: Power button suspend on Dell Latitude 7275)

I've addressed this one, but please do run checkpatch and correct reported
errors in the future. It checks commit reference format.

> > 
> > by checking against the power button press notification (0xCE) to report
> > the power button press event. The corresponding power button release
> > notification (0xCF) was caught and ignored to stop it from being reported
> > as an "unknown event" in the logs.
> > 
> > The missing button release event is creating issues on Android-x86, as
> > reported on the project mailing list for a Dell Latitude 5175 model, since
> > the events are expected in down/up pairs.
> > 
> > Report the power button release event to fix this issue.
> > 
> > Link: https://groups.google.com/forum/#!topic/android-x86/aSwZK9Nf9Ro
> > Tested-by: Tristian Celestin 
> > Tested-by: Jérôme de Bretagne 
> > Signed-off-by: Jérôme de Bretagne 

Queued for testing, thanks for the patch.

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH 2/2] arm64: dts: lx2160a: add sata node support

[Shawn Guo]

On Thu, Jan 10, 2019 at 06:05:33PM +0800, Peng Ma wrote:
> Add sata node support and Enable sata support
> 
> Signed-off-by: Peng Ma 
> ---
>  arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts |   16 +++
>  arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi|   44 
> +
>  2 files changed, 60 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts 
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> index 6481e5f..aacca27 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
> @@ -117,3 +117,19 @@
>   {
>   status = "okay";
>  };
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi 
> b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> index a79f5c1..e857a14 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> @@ -762,5 +762,49 @@
>;
>   dma-coherent;
>   };
> +
> + sata0: sata@320 {
> + status = "disabled";

We usually have 'status' at the end of property list.

Shawn

> + compatible = "fsl,lx2160a-ahci";
> + reg = <0x0 0x320 0x0 0x1>,
> +   <0x7 0x100520 0x0 0x4>;
> + reg-names = "ahci", "sata-ecc";
> + interrupts = ;
> + clocks = < 4 3>;
> + dma-coherent;
> + };
> +
> + sata1: sata@321 {
> + status = "disabled";
> + compatible = "fsl,lx2160a-ahci";
> + reg = <0x0 0x321 0x0 0x1>,
> +   <0x7 0x100520 0x0 0x4>;
> + reg-names = "ahci", "sata-ecc";
> + interrupts = ;
> + clocks = < 4 3>;
> + dma-coherent;
> + };
> +
> + sata2: sata@322 {
> + status = "disabled";
> + compatible = "fsl,lx2160a-ahci";
> + reg = <0x0 0x322 0x0 0x1>,
> +   <0x7 0x100520 0x0 0x4>;
> + reg-names = "ahci", "sata-ecc";
> + interrupts = ;
> + clocks = < 4 3>;
> + dma-coherent;
> + };
> +
> + sata3: sata@323 {
> + status = "disabled";
> + compatible = "fsl,lx2160a-ahci";
> + reg = <0x0 0x323 0x0 0x1>,
> +   <0x7 0x100520 0x0 0x4>;
> + reg-names = "ahci", "sata-ecc";
> + interrupts = ;
> + clocks = < 4 3>;
> + dma-coherent;
> + };
>   };
>  };
> -- 
> 1.7.1
> 

Re: Keyboard backlight not working on my NP900X5N laptop

[Darren Hart]

On Fri, Jan 04, 2019 at 05:16:38PM +0100, Jan Vlietland wrote:
> Hi Darren,
> 
> I understand your extra workload. For me it is just being another user
> complaining about some bug. Sorry for that :-) Good to know the response
> time. I will keep that in mind.
> 
> Anyway. I have changed the static variable to "0A", recompiled the module
> and I get the same output 'no such device'.
> 
> However I am now running in EFI mode based on another bug:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=109209
> 
> ...and I see in the code
> 
>     struct samsung_laptop *samsung;
>     int ret;
> 
>     if (efi_enabled(EFI_BOOT))
>         return -ENODEV;
> 
>     quirks = _unknown;
>     if (!force && !dmi_check_system(samsung_dmi_table))
>         return -ENODEV;
> 
>     samsung = kzalloc(sizeof(*samsung), GFP_KERNEL);
>     if (!samsung)
>         return -ENOMEM
> 
> Is that EFI restriction still valid. As far as I remember Samsung repaired
> their BIOS. Or does the driver not work in EFI mode anyway?

Hi Jan,

Taking a closer look at the driver and the git log, the driver was disabled for
EFI because it pokes at BIOS memory and that would mean poking at a completely
different memory map when in EFI mode - it would be expected to fail - and in
some cases it failed by bricking the laptop. See:

e0094244e41c samsung-laptop: Disable on EFI hardware

What appears to be needed here is for someone with the hardware and some
experience tracing ACPI calls from whatever OS it ships with to figure out the
new interface. I suspect it is either pure ACPI or possibly WMI, and a new
driver may be needed.

Have you tried this driver in BIOS mode with the OA change above?

> 
> 
> On 03-01-19 03:03, Darren Hart wrote:
> > On Mon, Dec 31, 2018 at 08:40:43PM +0100, Jan Vlietland wrote:
> > > Hi all,
> > > 
> > Hey Jan,
> > 
> > > Greg K-H suggested to mail you guys.
> > > 
> > > I installed Linux 4.20.0-rc7 (downloaded, compiled and installed) on a 
> > > Samsung NP900X5N laptop and have noticed 3 bugs. 2 of them I found in 
> > > Bugzilla and replied on them (i915 and Nouveau issues). I am currently 
> > > discussing them with an intel engineer.
> > > 
> > > On other bug I haven't found so therefore a mail directly to you guys as 
> > > maintainers.
> > > 
> > > On my other machine, a Samsung NP900X4D (just bought it in the USA, 2017 
> > > model), the samsung-laptop.ko module is enabling the use of the keyboard 
> > > backlight keys.
> > > 
> > > It is not working on my new machine NP900X5N. My samsung-laptop.ko driver 
> > > isn't loading. If I try to load it manually it complains about 'no such 
> > > device".
> > > 
> > > My Linux kernel is working in CSM mode. The module is still not loaded.
> > > 
> > That's correct.
> > 
> > > As it is weekend I did some more reading and debugging of the module. To 
> > > my understanding the module checks the model and type of the laptop. The 
> > > known models and types are stored in the struct:
> > > 
> > > static struct dmi_system_id __initdata samsung_dmi_table[]
> > > 
> > > I wondr if the NP900X5N notebook is included in this list.
> > > 
> > > With dmidecode -t chassis it shows:
> > > Getting SMBIOS data from sysfs.
> > > SMBIOS 3.0.0 present.
> > > 
> > > Handle 0x0003, DMI type 3, 22 bytes
> > > Chassis Information
> > >  Manufacturer: SAMSUNG ELECTRONICS CO., LTD.
> > >  Type: Notebook
> > >  Lock: Not Present
> > >  Version: N/A
> > >  Serial Number: 0F4C91CJ900346
> > >  Asset Tag: No Asset Tag
> > >  Boot-up State: Safe
> > >  Power Supply State: Safe
> > >  Thermal State: Other
> > >  Security Status: None
> > >  OEM Information: 0x
> > >  Height: Unspecified
> > >  Number Of Power Cords: 1
> > >  Contained Elements: 0
> > >  SKU Number: Chassis
> > > 
> > > If I use the -u flag. The notebook value is 0x0A, not 0x10!!!
> > > 
> > > Could that be the reason for not loading?
> > Seems likely.
> > 
> > >   .matches = {
> > >   DMI_MATCH(DMI_SYS_VENDOR,
> > >   "SAMSUNG ELECTRONICS CO., LTD."),
> > >   DMI_MATCH(DMI_CHASSIS_TYPE, "10"), /* Notebook */
> > >   },
> > > 
> > > Maybe another reason could that that either the i915 and Nouveau modules 
> > > are
> > > not working well. I get black screens with the i915 and MMIO faults with 
> > > the
> > > nouveau driver. That is another issue that I need to tackle.
> > > 
> > I would expect a different error than "no such device" in that case.
> > I think your first thought was correct.
> > 
> > As a simple test, I'd suggest replacing "10" with "0A" in the existing
> > DMI_CHASSIS_TYPE match, recompile, and see if it loads and works
> > correctly.  Would you be able to test this?
> > 
> > > Oh happy new year :-)
> > 
> > Happy New Year!
> > 
> 
> 
> 

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH 1/1] phy: fix build breakage: add PHY_MODE_SATA

[Olof Johansson]

On Sat, Jan 12, 2019 at 6:05 PM Jens Axboe  wrote:
>
> On 1/12/19 6:29 PM, john.hubb...@gmail.com wrote:
> > From: John Hubbard 
> >
> > Commit 49e54187ae0b ("ata: libahci_platform: comply to PHY framework") uses
> > the PHY_MODE_SATA, but that enum had not yet been added. This caused a
> > build failure for me, with today's linux.git.
> >
> > Also, there is a potentially conflicting (mis-named) PHY_MODE_SATA, hiding
> > in the Marvell Berlin SATA PHY driver.
> >
> > Fix the build by:
> >
> > 1) Renaming Marvell's defined value to a more scoped name,
> >in order to avoid any potential conflicts: PHY_BERLIN_MODE_SATA.
> >
> > 2) Adding the missing enum, which was going to be added anyway as part
> >of [1].
> >
> > [1] 
> > https://lkml.kernel.org/r/20190108163124.6409-3-miquel.ray...@bootlin.com
> >
> > Fixes: 49e54187ae0b ("ata: libahci_platform: comply to PHY framework")
>
> Linus, this is probably a better option in terms of what should go in to
> fix that commit.

I'm OK with this, but it does beg the question how the patch was
tested before submitting, if it didn't build.

Is there functional breakage behind it? I currently lack online
hardware to test myself, unfortunately.


-Olof

Re: [PATCH] kconfig: clean generated *conf-cfg files

[Masahiro Yamada]

On Fri, Jan 11, 2019 at 2:12 PM Masahiro Yamada
 wrote:
>
> I accidentally dropped '*' in the previous renaming patch.
>
> Revive it so that 'make mrproper' can clean the generated files.
>
> Fixes: d86271af6460 ("kconfig: rename generated .*conf-cfg to *conf-cfg")
> Signed-off-by: Masahiro Yamada 
> ---


Applied to linux-kbuild/fixes.




-- 
Best Regards
Masahiro Yamada

Re: [PATCH v2] kbuild: Disable LD_DEAD_CODE_DATA_ELIMINATION with ftrace & GCC <= 4.7

[Masahiro Yamada]

On Sat, Jan 12, 2019 at 6:00 AM Paul Burton  wrote:
>
> When building using GCC 4.7 or older, -ffunction-sections & the -pg flag
> used by ftrace are incompatible. This causes warnings or build failures
> (where -Werror applies) such as the following:
>
>   arch/mips/generic/init.c:
> error: -ffunction-sections disabled; it makes profiling impossible
>
> This used to be taken into account by the ordering of calls to cc-option
> from within the top-level Makefile, which was introduced by commit
> 90ad4052e85c ("kbuild: avoid conflict between -ffunction-sections and
> -pg on gcc-4.7"). Unfortunately this was broken when the
> CONFIG_LD_DEAD_CODE_DATA_ELIMINATION cc-option check was moved to
> Kconfig in commit e85d1d65cd8a ("kbuild: test dead code/data elimination
> support in Kconfig"), because the flags used by this check no longer
> include -pg.
>
> Fix this by not allowing CONFIG_LD_DEAD_CODE_DATA_ELIMINATION to be
> enabled at the same time as ftrace/CONFIG_FUNCTION_TRACER when building
> using GCC 4.7 or older.
>
> Signed-off-by: Paul Burton 
> Fixes: e85d1d65cd8a ("kbuild: test dead code/data elimination support in 
> Kconfig")
> Reported-by: Geert Uytterhoeven 
> Cc: Masahiro Yamada 
> Cc: Nicholas Piggin 
> Cc: sta...@vger.kernel.org # v4.19+
> Cc: linux-kbu...@vger.kernel.org
> Cc: linux-m...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> Changes in v2:
> - Invert the dependency as Masahiro suggested.


Applied to linux-kbuild/fixes.


Thanks!


-- 
Best Regards
Masahiro Yamada

WARNING in tty_set_termios

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:66c56cfa64d9 Merge tag 'remove-dma_zalloc_coherent-5.0' of..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=167fd6d8c0
kernel config:  https://syzkaller.appspot.com/x/.config?x=b05cfdb4ee8ab9b2
dashboard link: https://syzkaller.appspot.com/bug?extid=a950165cbb86bdd023a4
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=121cee0740
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16fdaed8c0

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+a950165cbb86bdd02...@syzkaller.appspotmail.com

WARNING: CPU: 0 PID: 1171 at drivers/tty/tty_ioctl.c:319  
tty_set_termios+0x93a/0xac0 drivers/tty/tty_ioctl.c:319

Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 1171 Comm: kworker/u5:0 Not tainted 5.0.0-rc1+ #22
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Workqueue: hci0 hci_power_on
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1db/0x2d0 lib/dump_stack.c:113
 panic+0x2cb/0x65c kernel/panic.c:214
 __warn.cold+0x20/0x48 kernel/panic.c:571
 report_bug+0x263/0x2b0 lib/bug.c:186
 fixup_bug arch/x86/kernel/traps.c:178 [inline]
 fixup_bug arch/x86/kernel/traps.c:173 [inline]
 do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
 do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:290
 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973
RIP: 0010:tty_set_termios+0x93a/0xac0 drivers/tty/tty_ioctl.c:319
Code: 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 ec 00  
00 00 41 89 9f d0 03 00 00 e9 f6 fd ff ff e8 d6 18 a8 fd <0f> 0b e9 a9 f7  
ff ff e8 4a 04 ec fd e9 48 f9 ff ff 4c 89 ef e8 9d

RSP: 0018:8880a74f7600 EFLAGS: 00010293
RAX: 8880a74d4300 RBX: 8880a74f76c0 RCX: 83d9d62d
RDX:  RSI: 83d9de8a RDI: 0005
RBP: 8880a74f76e8 R08: 8880a74d4300 R09: fbfff181d7b5
R10: fbfff181d7b4 R11: 0003 R12: 8880a74f7728
R13: 00010004 R14: 0001c200 R15: 88808e3e60c0
 hci_uart_set_baudrate+0x1cc/0x250 drivers/bluetooth/hci_ldisc.c:378
 hci_uart_setup+0xa2/0x490 drivers/bluetooth/hci_ldisc.c:401
 hci_dev_do_open+0x6b1/0x1920 net/bluetooth/hci_core.c:1423
 hci_power_on+0x10d/0x880 net/bluetooth/hci_core.c:2130
 process_one_work+0xd0c/0x1ce0 kernel/workqueue.c:2153
 worker_thread+0x143/0x14a0 kernel/workqueue.c:2296
 kthread+0x357/0x430 kernel/kthread.c:246
 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with  
syzbot.

syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

Re: [PATCH RESEND] ARM: dts: imx6sx: Add DISPLAY power domain support

[Shawn Guo]

On Mon, Jan 07, 2019 at 01:28:48PM +, Leonard Crestez wrote:
> This was implemented in the driver but not actually defined and
> referenced in dts. This makes it always on.
> 
> From reference manual in section "10.4.1.4.1 Power Distribution":
> 
> "Display domain - The DISPLAY domain contains GIS, CSI, PXP, LCDIF,
> PCIe, DCIC, and LDB. It is supplied by internal regulator."
> 
> The current pd_pcie is actually only for PCIE_PHY, the PCIE ip block is
> actually inside the DISPLAY domain. Handle this by adding the pcie node
> in both power domains.
> 
> Signed-off-by: Leonard Crestez 

Applied, thanks.

Re: [PATCH 1/2] ARM: dts: imx6ul: add DMA properties for ECSPI

[Shawn Guo]

On Mon, Jan 07, 2019 at 02:22:25PM +0100, Stefan Agner wrote:
> Allow to use DMA for SPI by adding the appropriate DMA properites
> to the ecspi nodes.
> 
> Signed-off-by: Stefan Agner 

Applied both, thanks.

Re: [PATCH v8 6/7] ARM64: dts: ls1046a: Remove fsl,qspi-has-second-chip as it is not used

[Shawn Guo]

On Mon, Jan 07, 2019 at 09:29:55AM +, Schrempf Frieder wrote:
> From: Frieder Schrempf 
> 
> After switching to the new FSL QSPI driver the property
> 'fsl,qspi-has-second-chip' is not needed anymore.
> 
> The driver now uses the 'reg' property to determine the bus and
> the chipselect.
> 
> Signed-off-by: Frieder Schrempf 

Different from arm dts files, we use prefix 'arm64: dts: ...'.
I fixed it up and applied the patch.

Shawn

Re: [PATCH v8 5/7] ARM: dts: ls1021a: Remove fsl,qspi-has-second-chip as it is not used

[Shawn Guo]

On Mon, Jan 07, 2019 at 09:29:54AM +, Schrempf Frieder wrote:
> From: Frieder Schrempf 
> 
> After switching to the new FSL QSPI driver the property
> 'fsl,qspi-has-second-chip' is not needed anymore.
> 
> The driver now uses the 'reg' property to determine the bus and
> the chipselect.
> 
> Signed-off-by: Frieder Schrempf 

Applied, thanks.

Do you need to edit your photos?

[Ruby]

Do you need to edit your photos?

Here are the editing service we mostly for the photos from our clients.
Photos cut out background , clipping path, and also retouching.

You may send some photos to us. we will let our editing staffs to work on
them.

Thanks,
Ruby

Do you need to retouch your photos?

[Ruby]

Do you need to edit your photos?

Here are the editing service we mostly for the photos from our clients.
Photos cut out background , clipping path, and also retouching.

You may send some photos to us. we will let our editing staffs to work on
them.

Thanks,
Ruby

Re: [PATCH] ARM: imx: don't build ssi-fiq if not required

[Shawn Guo]

On Thu, Jan 03, 2019 at 03:36:31PM +0100, Stefan Agner wrote:
> The symbols provided by ssi-fiq are used in sound/soc/fsl/imx-pcm-fiq.c
> only. Build ssi-fiq.o/ssi-fiq-ksym.o only if SND_SOC_IMX_PCM_FIQ is
> enabled.
> 
> Signed-off-by: Stefan Agner 

Applied, thanks.

Re: [PATCH] ARM: dts: imx6sx: correct backward compatible of gpt

[Shawn Guo]

On Sat, Dec 29, 2018 at 10:01:18AM +, Anson Huang wrote:
> i.MX6SX has same GPT type as i.MX6DL, in GPT driver, it uses
> below TIMER_OF_DECLARE, so the backward compatible should be
> "fsl,imx6dl-gpt", correct it.
> 
> TIMER_OF_DECLARE(imx6sx_timer, "fsl,imx6sx-gpt", imx6dl_timer_init_dt);
> 
> Signed-off-by: Anson Huang 

Applied, thanks.

Re: [Qemu-devel] [PATCH v3 0/5] kvm "virtio pmem" device

[Pankaj Gupta]

> >
> >
> >
> > >
> > > On Thu 10-01-19 12:26:17, Dave Chinner wrote:
> > > > On Wed, Jan 09, 2019 at 08:17:31PM +0530, Pankaj Gupta wrote:
> > > > >  This patch series has implementation for "virtio pmem".
> > > > >  "virtio pmem" is fake persistent memory(nvdimm) in guest
> > > > >  which allows to bypass the guest page cache. This also
> > > > >  implements a VIRTIO based asynchronous flush mechanism.
> > > >
> > > > H. Sharing the host page cache direct into the guest VM. Sounds
> > > > like a good idea, but.
> > > >
> > > > This means the guest VM can now run timing attacks to observe host
> > > > side page cache residency, and depending on the implementation I'm
> > > > guessing that the guest will be able to control host side page
> > > > cache eviction, too (e.g. via discard or hole punch operations).
> > > >
> > > > Which means this functionality looks to me like a new vector for
> > > > information leakage into and out of the guest VM via guest
> > > > controlled host page cache manipulation.
> > > >
> > > > https://arxiv.org/pdf/1901.01161
> > > >
> > > > I might be wrong, but if I'm not we're going to have to be very
> > > > careful about how guest VMs can access and manipulate host side
> > > > resources like the page cache.
> > >
> > > Right. Thinking about this I would be more concerned about the fact that
> > > guest can effectively pin amount of host's page cache upto size of the
> > > device/file passed to guest as PMEM, can't it Pankaj? Or is there some
> > > QEMU
> > > magic that avoids this?
> >
> > Yes, guest will pin these host page cache pages using 'get_user_pages' by
> > elevating the page reference count. But these pages can be reclaimed by
> > host
> > at any time when there is memory pressure.
> 
> Wait, how can the guest pin the host pages? I would expect this to
> happen only when using vfio and device assignment. Otherwise, no the
> host can't reclaim a pinned page, that's the whole point of a pin to
> prevent the mm from reclaiming ownership.

yes. You are right I just used the pin word but it does not actually pin pages 
permanently. I had gone through the discussion on existing problems with 
get_user_pages and DMA e.g [1] to understand Jan's POV. It does mention GUP 
pin pages so I also used the word 'pin'. But guest does not permanently pin 
these pages and these pages can be reclaimed by host.

> 
> > KVM does not permanently pin pages. vfio does that but we are not using
> > it here.
> 
> Right, so I'm confused by your pin assertion above.

Sorry! for the confusion. 

[1] https://lwn.net/Articles/753027/

Thanks,
Pankaj

[PATCH v3 0/2] Allwinner A64 timer workaround

[Samuel Holland]

This is the third version of a patch series to fix system clock jumps
and other timer instability on the Allwinner A64 SoC. It has now been
tested for a week, and I've received no reports of date jumps with this
version. So this is, as far as I can tell, a complete workaround.

See the commit messages for a detailed description of the issue, but the
summary is that, when a high counter bit rolls over, indeterminance in
the low bits causes CNTPCT/CNTVCT and their respective TVAL registers to
jump forward or backward. Backward jumps (or the next read after forward
jumps) are sometimes seen by the kernel and interpreted as the timer
wrapping around after 2^56 cycles. This causes the system clock to jump
forward approximately 91 years.

changes since v2;
- Reduced workaround threshold from 11 to 10 bits based on reports from
  other hardare and the U-Boot version of this workaround
- Added TVAL handling based on Marc's suggestion
- Added erratum documentation and renamed symbols to match
- Added Maxime's Acked-by

changes since v1:
- Add an iteration limit like most other arch timer workarounds
- Added Andre's Tested-by

Samuel Holland (2):
  arm64: arch_timer: Workaround for Allwinner A64 timer instability
  arm64: dts: allwinner: a64: Enable A64 timer workaround

 Documentation/arm64/silicon-errata.txt|  2 +
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi |  1 +
 drivers/clocksource/Kconfig   | 10 
 drivers/clocksource/arm_arch_timer.c  | 55 +++
 4 files changed, 68 insertions(+)

-- 
2.19.2

[PATCH v3 2/2] arm64: dts: allwinner: a64: Enable A64 timer workaround

[Samuel Holland]

As instability in the architectural timer has been observed on multiple
devices using this SoC, inluding the Pine64 and the Orange Pi Win,
enable the workaround in the SoC's device tree.

Acked-by: Maxime Ripard 
Signed-off-by: Samuel Holland 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index f3a66f888205..13eac92a8c55 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -175,6 +175,7 @@
 
timer {
compatible = "arm,armv8-timer";
+   allwinner,erratum-unknown1;
interrupts = ,
 

[PATCH v3 1/2] arm64: arch_timer: Workaround for Allwinner A64 timer instability

[Samuel Holland]

The Allwinner A64 SoC is known[1] to have an unstable architectural
timer, which manifests itself most obviously in the time jumping forward
a multiple of 95 years[2][3]. This coincides with 2^56 cycles at a
timer frequency of 24 MHz, implying that the time went slightly backward
(and this was interpreted by the kernel as it jumping forward and
wrapping around past the epoch).

Investigation revealed instability in the low bits of CNTVCT at the
point a high bit rolls over. This leads to power-of-two cycle forward
and backward jumps. (Testing shows that forward jumps are about twice as
likely as backward jumps.) Since the counter value returns to normal
after an indeterminate read, each "jump" really consists of both a
forward and backward jump from the software perspective.

Unless the kernel is trapping CNTVCT reads, a userspace program is able
to read the register in a loop faster than it changes. A test program
running on all 4 CPU cores that reported jumps larger than 100 ms was
run for 13.6 hours and reported the following:

 Count | Event
---+---
  9940 | jumped backward  699ms
   268 | jumped backward 1398ms
 1 | jumped backward 2097ms
 16020 | jumped forward   175ms
  6443 | jumped forward   699ms
  2976 | jumped forward  1398ms
 9 | jumped forward356516ms
 9 | jumped forward357215ms
 4 | jumped forward714430ms
 1 | jumped forward   3578440ms

This works out to a jump larger than 100 ms about every 5.5 seconds on
each CPU core.

The largest jump (almost an hour!) was the following sequence of reads:
0x007f → 0x0093feff → 0x0080

Note that the middle bits don't necessarily all read as all zeroes or
all ones during the anomalous behavior; however the low 10 bits checked
by the function in this patch have never been observed with any other
value.

Also note that smaller jumps are much more common, with backward jumps
of 2048 (2^11) cycles observed over 400 times per second on each core.
(Of course, this is partially explained by lower bits rolling over more
frequently.) Any one of these could have caused the 95 year time skip.

Similar anomalies were observed while reading CNTPCT (after patching the
kernel to allow reads from userspace). However, the CNTPCT jumps are
much less frequent, and only small jumps were observed. The same program
as before (except now reading CNTPCT) observed after 72 hours:

 Count | Event
---+---
17 | jumped backward  699ms
52 | jumped forward   175ms
  2831 | jumped forward   699ms
 5 | jumped forward  1398ms

Further investigation showed that the instability in CNTPCT/CNTVCT also
affected the respective timer's TVAL register. The following values were
observed immediately after writing CNVT_TVAL to 0x1000:

 CNTVCT | CNTV_TVAL  | CNTV_CVAL  | CNTV_TVAL Error
+++-
 0x00d4a2d8bfff | 0x10003fff | 0x00d4b2d8bfff | +0x4000
 0x00d4a2d94000 | 0x0fff | 0x00d4b2d97fff | -0x4000
 0x00d4a2d97fff | 0x10003fff | 0x00d4b2d97fff | +0x4000
 0x00d4a2d9c000 | 0x0fff | 0x00d4b2d9 | -0x4000

The pattern of errors in CNTV_TVAL seemed to depend on exactly which
value was written to it. For example, after writing 0x10101010:

 CNTVCT | CNTV_TVAL  | CNTV_CVAL  | CNTV_TVAL Error
+++-
 0x01ac3eff | 0x1110100f | 0x01ac4f10100f | +0x100
 0x01ac4000 | 0x1010100f | 0x01ac5110100f | -0x100
 0x01ac58ff | 0x1110100f | 0x01ac6910100f | +0x100
 0x01ac6600 | 0x1010100f | 0x01ac7710100f | -0x100
 0x01ac6aff | 0x1110100f | 0x01ac7b10100f | +0x100
 0x01ac6e00 | 0x1010100f | 0x01ac7f10100f | -0x100

I was also twice able to reproduce the issue covered by Allwinner's
workaround[4], that writing to TVAL sometimes fails, and both CVAL and
TVAL are left with entirely bogus values. One was the following values:

 CNTVCT | CNTV_TVAL  | CNTV_CVAL
++--
 0x00d4a2d6014c | 0x8fbd5721 | 0x00d132935fff (615s in the past)



Because the CPU can read the CNTPCT/CNTVCT registers faster than they
change, performing two reads of the register and comparing the high bits
(like other workarounds) is not a workable solution. And because the
timer can jump both forward and backward, no pair of reads can
distinguish a good value from a bad one. The only way to guarantee a
good value from consecutive reads would be to read _three_ times, and
take the middle value only if the three values are 1) each unique and
2) increasing. This takes at minimum 3 counter cycles (125 ns), or 

Re: [PATCH 1/1] phy: fix build breakage: add PHY_MODE_SATA

[Jens Axboe]

On 1/12/19 6:29 PM, john.hubb...@gmail.com wrote:
> From: John Hubbard 
> 
> Commit 49e54187ae0b ("ata: libahci_platform: comply to PHY framework") uses
> the PHY_MODE_SATA, but that enum had not yet been added. This caused a
> build failure for me, with today's linux.git.
> 
> Also, there is a potentially conflicting (mis-named) PHY_MODE_SATA, hiding
> in the Marvell Berlin SATA PHY driver.
> 
> Fix the build by:
> 
> 1) Renaming Marvell's defined value to a more scoped name,
>in order to avoid any potential conflicts: PHY_BERLIN_MODE_SATA.
> 
> 2) Adding the missing enum, which was going to be added anyway as part
>of [1].
> 
> [1] https://lkml.kernel.org/r/20190108163124.6409-3-miquel.ray...@bootlin.com
> 
> Fixes: 49e54187ae0b ("ata: libahci_platform: comply to PHY framework")

Linus, this is probably a better option in terms of what should go in to
fix that commit.

> 
> Cc: Grzegorz Jaszczyk 
> Cc: Miquel Raynal 
> Cc: Hans de Goede 
> Cc: Jens Axboe 
> Signed-off-by: John Hubbard 
> ---
>  drivers/phy/marvell/phy-berlin-sata.c | 5 +++--
>  include/linux/phy/phy.h   | 1 +
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/phy/marvell/phy-berlin-sata.c 
> b/drivers/phy/marvell/phy-berlin-sata.c
> index a91fc67fc4e0..d70ba9bc42d9 100644
> --- a/drivers/phy/marvell/phy-berlin-sata.c
> +++ b/drivers/phy/marvell/phy-berlin-sata.c
> @@ -32,7 +32,7 @@
>  
>  /* register 0x01 */
>  #define REF_FREF_SEL_25  BIT(0)
> -#define PHY_MODE_SATA(0x0 << 5)
> +#define PHY_BERLIN_MODE_SATA (0x0 << 5)
>  
>  /* register 0x02 */
>  #define USE_MAX_PLL_RATE BIT(12)
> @@ -102,7 +102,8 @@ static int phy_berlin_sata_power_on(struct phy *phy)
>  
>   /* set PHY mode and ref freq to 25 MHz */
>   phy_berlin_sata_reg_setbits(ctrl_reg, priv->phy_base, 0x01,
> - 0x00ff, REF_FREF_SEL_25 | PHY_MODE_SATA);
> + 0x00ff,
> + REF_FREF_SEL_25 | PHY_BERLIN_MODE_SATA);
>  
>   /* set PHY up to 6 Gbps */
>   phy_berlin_sata_reg_setbits(ctrl_reg, priv->phy_base, 0x25,
> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
> index e8e118d70fd7..3f350e2749fe 100644
> --- a/include/linux/phy/phy.h
> +++ b/include/linux/phy/phy.h
> @@ -42,6 +42,7 @@ enum phy_mode {
>   PHY_MODE_PCIE,
>   PHY_MODE_ETHERNET,
>   PHY_MODE_MIPI_DPHY,
> + PHY_MODE_SATA
>  };
>  
>  /**
> 


-- 
Jens Axboe

Re: [PATCH v3 0/5] kvm "virtio pmem" device

[Dan Williams]

On Sat, Jan 12, 2019 at 5:38 PM Pankaj Gupta  wrote:
>
>
>
> >
> > On Thu 10-01-19 12:26:17, Dave Chinner wrote:
> > > On Wed, Jan 09, 2019 at 08:17:31PM +0530, Pankaj Gupta wrote:
> > > >  This patch series has implementation for "virtio pmem".
> > > >  "virtio pmem" is fake persistent memory(nvdimm) in guest
> > > >  which allows to bypass the guest page cache. This also
> > > >  implements a VIRTIO based asynchronous flush mechanism.
> > >
> > > H. Sharing the host page cache direct into the guest VM. Sounds
> > > like a good idea, but.
> > >
> > > This means the guest VM can now run timing attacks to observe host
> > > side page cache residency, and depending on the implementation I'm
> > > guessing that the guest will be able to control host side page
> > > cache eviction, too (e.g. via discard or hole punch operations).
> > >
> > > Which means this functionality looks to me like a new vector for
> > > information leakage into and out of the guest VM via guest
> > > controlled host page cache manipulation.
> > >
> > > https://arxiv.org/pdf/1901.01161
> > >
> > > I might be wrong, but if I'm not we're going to have to be very
> > > careful about how guest VMs can access and manipulate host side
> > > resources like the page cache.
> >
> > Right. Thinking about this I would be more concerned about the fact that
> > guest can effectively pin amount of host's page cache upto size of the
> > device/file passed to guest as PMEM, can't it Pankaj? Or is there some QEMU
> > magic that avoids this?
>
> Yes, guest will pin these host page cache pages using 'get_user_pages' by
> elevating the page reference count. But these pages can be reclaimed by host
> at any time when there is memory pressure.

Wait, how can the guest pin the host pages? I would expect this to
happen only when using vfio and device assignment. Otherwise, no the
host can't reclaim a pinned page, that's the whole point of a pin to
prevent the mm from reclaiming ownership.

> KVM does not permanently pin pages. vfio does that but we are not using
> it here.

Right, so I'm confused by your pin assertion above.

Re: [RFC PATCH 2/2] kexec, KEYS: Make use of platform keyring for signature verify

[Dave Young]

Hi,

On 01/11/19 at 11:13am, Mimi Zohar wrote:
> On Fri, 2019-01-11 at 21:43 +0800, Dave Young wrote:
> [snip]
> 
> > Personally I would like to see platform key separated from integrity.
> > But for the kexec_file part I think it is good at least it works with
> > this fix.
> > 
> > Acked-by: Dave Young 
> 
> The original "platform" keyring patches that Nayna posted multiple
> times were in the certs directory, but nobody commented/responded.  So
> she reworked the patches, moving them to the integrity directory and
> posted them (cc'ing the kexec mailing list).  It's a bit late to be
> asking to move it, isn't it?

Hmm, apologize for being late,  I did not get chance to have a look the
old series.  Since we have the needs now, it should be still fine

Maybe Kairui can check Nayna's old series, see if he can do something
again?

> 
> Mimi
> 

Thanks
Dave

Re: [PATCH v3 0/5] kvm "virtio pmem" device

[Pankaj Gupta]

> 
> On Thu 10-01-19 12:26:17, Dave Chinner wrote:
> > On Wed, Jan 09, 2019 at 08:17:31PM +0530, Pankaj Gupta wrote:
> > >  This patch series has implementation for "virtio pmem".
> > >  "virtio pmem" is fake persistent memory(nvdimm) in guest
> > >  which allows to bypass the guest page cache. This also
> > >  implements a VIRTIO based asynchronous flush mechanism.
> > 
> > H. Sharing the host page cache direct into the guest VM. Sounds
> > like a good idea, but.
> > 
> > This means the guest VM can now run timing attacks to observe host
> > side page cache residency, and depending on the implementation I'm
> > guessing that the guest will be able to control host side page
> > cache eviction, too (e.g. via discard or hole punch operations).
> > 
> > Which means this functionality looks to me like a new vector for
> > information leakage into and out of the guest VM via guest
> > controlled host page cache manipulation.
> > 
> > https://arxiv.org/pdf/1901.01161
> > 
> > I might be wrong, but if I'm not we're going to have to be very
> > careful about how guest VMs can access and manipulate host side
> > resources like the page cache.
> 
> Right. Thinking about this I would be more concerned about the fact that
> guest can effectively pin amount of host's page cache upto size of the
> device/file passed to guest as PMEM, can't it Pankaj? Or is there some QEMU
> magic that avoids this?

Yes, guest will pin these host page cache pages using 'get_user_pages' by
elevating the page reference count. But these pages can be reclaimed by host
at any time when there is memory pressure.

KVM does not permanently pin pages. vfio does that but we are not using
it here.

Could you please elaborate what you are thinking?

Thanks,
Pankaj

[PATCH 1/1] phy: fix build breakage: add PHY_MODE_SATA

[john . hubbard]

From: John Hubbard 

Commit 49e54187ae0b ("ata: libahci_platform: comply to PHY framework") uses
the PHY_MODE_SATA, but that enum had not yet been added. This caused a
build failure for me, with today's linux.git.

Also, there is a potentially conflicting (mis-named) PHY_MODE_SATA, hiding
in the Marvell Berlin SATA PHY driver.

Fix the build by:

1) Renaming Marvell's defined value to a more scoped name,
   in order to avoid any potential conflicts: PHY_BERLIN_MODE_SATA.

2) Adding the missing enum, which was going to be added anyway as part
   of [1].

[1] https://lkml.kernel.org/r/20190108163124.6409-3-miquel.ray...@bootlin.com

Fixes: 49e54187ae0b ("ata: libahci_platform: comply to PHY framework")

Cc: Grzegorz Jaszczyk 
Cc: Miquel Raynal 
Cc: Hans de Goede 
Cc: Jens Axboe 
Signed-off-by: John Hubbard 
---
 drivers/phy/marvell/phy-berlin-sata.c | 5 +++--
 include/linux/phy/phy.h   | 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/marvell/phy-berlin-sata.c 
b/drivers/phy/marvell/phy-berlin-sata.c
index a91fc67fc4e0..d70ba9bc42d9 100644
--- a/drivers/phy/marvell/phy-berlin-sata.c
+++ b/drivers/phy/marvell/phy-berlin-sata.c
@@ -32,7 +32,7 @@
 
 /* register 0x01 */
 #define REF_FREF_SEL_25BIT(0)
-#define PHY_MODE_SATA  (0x0 << 5)
+#define PHY_BERLIN_MODE_SATA   (0x0 << 5)
 
 /* register 0x02 */
 #define USE_MAX_PLL_RATE   BIT(12)
@@ -102,7 +102,8 @@ static int phy_berlin_sata_power_on(struct phy *phy)
 
/* set PHY mode and ref freq to 25 MHz */
phy_berlin_sata_reg_setbits(ctrl_reg, priv->phy_base, 0x01,
-   0x00ff, REF_FREF_SEL_25 | PHY_MODE_SATA);
+   0x00ff,
+   REF_FREF_SEL_25 | PHY_BERLIN_MODE_SATA);
 
/* set PHY up to 6 Gbps */
phy_berlin_sata_reg_setbits(ctrl_reg, priv->phy_base, 0x25,
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index e8e118d70fd7..3f350e2749fe 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -42,6 +42,7 @@ enum phy_mode {
PHY_MODE_PCIE,
PHY_MODE_ETHERNET,
PHY_MODE_MIPI_DPHY,
+   PHY_MODE_SATA
 };
 
 /**
-- 
2.20.1

[PATCH 0/1] PHY_MODE_SATA build fix

[john . hubbard]

From: John Hubbard 

Hi,

Say, I just ran into this build breakage on today's linux.git, and after
checking the email threads, I do realize that PHY_MODE_SATA is about to be
added as part of [1]. However, I also noticed that it was not identified
as a build fix, nor did anyone notice the potential naming conflict. So
here is a patch for that.

Please feel free to merge, reword, discard, etc, as you see fit. :)

[1] https://lkml.kernel.org/r/20190108163124.6409-3-miquel.ray...@bootlin.com

John Hubbard (1):
  phy: fix build breakage: add PHY_MODE_SATA

 drivers/phy/marvell/phy-berlin-sata.c | 5 +++--
 include/linux/phy/phy.h   | 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

-- 
2.20.1

Re: [PATCH v3 0/6] Static calls

[hpa]

On January 11, 2019 11:34:34 AM PST, Linus Torvalds 
 wrote:
>On Fri, Jan 11, 2019 at 11:24 AM  wrote:
>>
>> I still don't see why can't simply spin in the #BP handler until the
>patch is complete.
>
>So here's at least one problem:
>
>text_poke_bp()
>  text_poke(addr, , sizeof(int3));
>   *interrupt*
>  interrupt has a static call
>*BP*
>  poke_int3_handler
> *BOOM*
>
>Note how at BOOM we cannot just spin (or return) to wait for the
>'int3' to be switched back. Becuase it never will. Because we are
>interrupting the thing that would do that switch-back.
>
>So we'd have to do the 'text_poke_bp()' sequence with interrupts
>disabled. Which we can't do right now at least, because part of that
>sequence involves that on_each_cpu(do_sync_core) thing, which needs
>interrupts enabled.
>
>See?
>
>Or am I missing something?
>
>Linus

Ok, I was thinking far more about spinning with an IRET and letting the 
exception be delivered. Patching with interrupts disabled have other 
problems... 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [PATCH v3 0/6] Static calls

[hpa]

On January 11, 2019 11:34:34 AM PST, Linus Torvalds 
 wrote:
>On Fri, Jan 11, 2019 at 11:24 AM  wrote:
>>
>> I still don't see why can't simply spin in the #BP handler until the
>patch is complete.
>
>So here's at least one problem:
>
>text_poke_bp()
>  text_poke(addr, , sizeof(int3));
>   *interrupt*
>  interrupt has a static call
>*BP*
>  poke_int3_handler
> *BOOM*
>
>Note how at BOOM we cannot just spin (or return) to wait for the
>'int3' to be switched back. Becuase it never will. Because we are
>interrupting the thing that would do that switch-back.
>
>So we'd have to do the 'text_poke_bp()' sequence with interrupts
>disabled. Which we can't do right now at least, because part of that
>sequence involves that on_each_cpu(do_sync_core) thing, which needs
>interrupts enabled.
>
>See?
>
>Or am I missing something?
>
>Linus

Let me think about it.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[PATCH net] net: phy: meson-gxl: Use the genphy_soft_reset callback

[Timotej Lazar]

Since the referenced commit, Ethernet fails to come up at boot on the
board meson-gxl-s905x-libretech-cc. Fix this by re-enabling the
genphy_soft_reset callback for the Amlogic Meson GXL PHY driver.

Fixes: 6e2d85ec0559 ("net: phy: Stop with excessive soft reset")
Signed-off-by: Timotej Lazar 
---
 drivers/net/phy/meson-gxl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/phy/meson-gxl.c b/drivers/net/phy/meson-gxl.c
index b03bcf2c388a..3ddaf9595697 100644
--- a/drivers/net/phy/meson-gxl.c
+++ b/drivers/net/phy/meson-gxl.c
@@ -233,6 +233,7 @@ static struct phy_driver meson_gxl_phy[] = {
.name   = "Meson GXL Internal PHY",
.features   = PHY_BASIC_FEATURES,
.flags  = PHY_IS_INTERNAL,
+   .soft_reset = genphy_soft_reset,
.config_init= meson_gxl_config_init,
.aneg_done  = genphy_aneg_done,
.read_status= meson_gxl_read_status,
-- 
2.20.1

Re: Preserving a rev 0.0 ext2 filesystem

[Andreas Dilger]

On Jan 12, 2019, at 2:43 AM, Geert Uytterhoeven  wrote:
> 
> Hi Ted,
> 
> I'm still regularly using a Linux rev 0.0 ext2 filesystem as a  ramdisk
> on m68k, containing mid-90's binaries, from right after the a.out-to-ELF
> transition, so I notice if someone breaks old syscall support.
> 
> Recently I wanted to change /dev/console on that ramdisk from a symlink
> to chardev 5 0.  Unfortunately I cannot mount it, without it being
> upgraded automatically to a rev 1.0 ext2 filesystem.  Apparently the
> kernel has been doing that upgrade for ages.
> 
> Do you have a suggestion how to make that change, while preserving the
> ext2 revision?

It looks like there is a "gratuitous" call to ext4_update_dynamic_rev() in the
mount path that is left over from when ext3 always set the INCOMPAT_RECOVER and
COMPAT_HAS_JOURNAL features on every mount.  With the "nojournal" mount option
these are no longer needed.  You could probably just remove this call with no 
ill
effects, or better yet apply the patch that I'll push shortly to this effect.
It's been there since the start of git history (2.6.12-rc2) in the ext3 code
that was later copied to become ext4, but digging through my email archives it
looks like adding the call to "ext3_update_fs_rev()" was actually one of my 
first
patches against the original ext3 code "[Ext2-devel] Re: RECOVER INCOMPAT flag",
dated Nov 18, 2000.

The only thing ext4_update_dynamic_rev() does is update s_rev_level, and set
s_first_ino and s_inode_size on disk to the values that the kernel already
assumes to be true (newer kernels can use different values).  Those fields are
also set in memory later during the mount, so the rest of the code should work
OK (I haven't tested). This will probably only affect your filesysem (everything
else in the last 20 years uses EXT2_DYNAMIC_REV) so it won't be much of a 
change.

The "real" ext2 code looks like it does not call ext2_update_dynamic_rev() for
every filesystem during mount, only if you write a file > 2GB in size, so it 
would
also be possible to mount with the ext2.ko driver (if your kernel provides it).
There looks like a minor bug in ext2 that it doesn't call 
ext2_update_dynamic_rev()
if an xattr is stored on the filesystem and it sets EXT2_FEATURE_COMPAT_EXT_ATTR
in ext2_xattr_update_super_block().  However, nobody noticed in since xattrs 
landed.


In any case, it would be fun to give my patch a try to see if it allows your old
filesystem to be mounted and modified with a modern kernel and then mounted on
the old kernel again, as a testament to ext2/ext4 feature compatibility.

Cheers, Andreas







signature.asc
Description: Message signed with OpenPGP

[PATCH -manpage 2/2] memfd_create.2: Update manpage with new memfd F_SEAL_FUTURE_WRITE seal

[Joel Fernandes]

From: "Joel Fernandes (Google)" 

More details of the seal can be found in the LKML patch:
https://lore.kernel.org/lkml/20181120052137.74317-1-j...@joelfernandes.org/T/#t

Signed-off-by: Joel Fernandes (Google) 
---
 man2/memfd_create.2 | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/man2/memfd_create.2 b/man2/memfd_create.2
index 3cd392d1b..fce2bf8d0 100644
--- a/man2/memfd_create.2
+++ b/man2/memfd_create.2
@@ -280,7 +280,15 @@ in order to restrict further modifications on the file.
 (If placing the seal
 .BR F_SEAL_WRITE ,
 then it will be necessary to first unmap the shared writable mapping
-created in the previous step.)
+created in the previous step. Otherwise, behavior similar to
+.BR F_SEAL_WRITE
+can be achieved, by using
+.BR F_SEAL_FUTURE_WRITE
+which will prevent future writes via
+.BR mmap (2)
+and
+.BR write (2)
+from succeeding, while keeping existing shared writable mappings).
 .IP 4.
 A second process obtains a file descriptor for the
 .BR tmpfs (5)
@@ -425,6 +433,7 @@ main(int argc, char *argv[])
 fprintf(stderr, "\\t\\tg \- F_SEAL_GROW\\n");
 fprintf(stderr, "\\t\\ts \- F_SEAL_SHRINK\\n");
 fprintf(stderr, "\\t\\tw \- F_SEAL_WRITE\\n");
+fprintf(stderr, "\\t\\tW \- F_SEAL_FUTURE_WRITE\\n");
 fprintf(stderr, "\\t\\tS \- F_SEAL_SEAL\\n");
 exit(EXIT_FAILURE);
 }
@@ -463,6 +472,8 @@ main(int argc, char *argv[])
 seals |= F_SEAL_SHRINK;
 if (strchr(seals_arg, \(aqw\(aq) != NULL)
 seals |= F_SEAL_WRITE;
+if (strchr(seals_arg, \(aqW\(aq) != NULL)
+seals |= F_SEAL_FUTURE_WRITE;
 if (strchr(seals_arg, \(aqS\(aq) != NULL)
 seals |= F_SEAL_SEAL;
 
@@ -518,6 +529,8 @@ main(int argc, char *argv[])
 printf(" GROW");
 if (seals & F_SEAL_WRITE)
 printf(" WRITE");
+if (seals & F_SEAL_FUTURE_WRITE)
+printf(" FUTURE_WRITE");
 if (seals & F_SEAL_SHRINK)
 printf(" SHRINK");
 printf("\\n");
-- 
2.20.1.97.g81188d93c3-goog

[PATCH -manpage 1/2] fcntl.2: Update manpage with new memfd F_SEAL_FUTURE_WRITE seal

[Joel Fernandes]

From: "Joel Fernandes (Google)" 

More details of the seal can be found in the LKML patch:
https://lore.kernel.org/lkml/20181120052137.74317-1-j...@joelfernandes.org/T/#t

Signed-off-by: Joel Fernandes (Google) 
---
 man2/fcntl.2 | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/man2/fcntl.2 b/man2/fcntl.2
index 03533d65b..54772f949 100644
--- a/man2/fcntl.2
+++ b/man2/fcntl.2
@@ -1525,6 +1525,21 @@ Furthermore, if there are any asynchronous I/O operations
 .RB ( io_submit (2))
 pending on the file,
 all outstanding writes will be discarded.
+.TP
+.BR F_SEAL_FUTURE_WRITE
+If this seal is set, the contents of the file can be modified only from
+existing writeable mappings that were created prior to the seal being set.
+Any attempt to create a new writeable mapping on the memfd via
+.BR mmap (2)
+will fail with
+.BR EPERM.
+Also any attempts to write to the memfd via
+.BR write (2)
+will fail with
+.BR EPERM.
+This is useful in situations where existing writable mapped regions need to be
+kept intact while preventing any future writes. For example, to share a
+read-only memory buffer to other processes that only the sender can write to.
 .\"
 .SS File read/write hints
 Write lifetime hints can be used to inform the kernel about the relative
-- 
2.20.1.97.g81188d93c3-goog

[PATCH -manpage 0/2] Document memfd F_SEAL_FUTURE_WRITE seal

[Joel Fernandes]

Hello,

These manpages correspond to the following kernel patches:
https://lore.kernel.org/patchwork/patch/1031550/
https://lore.kernel.org/patchwork/patch/1031551/

This is just a resend with no changes from last time.

Joel Fernandes (Google) (2):
fcntl.2: Update manpage with new memfd F_SEAL_FUTURE_WRITE seal
memfd_create.2: Update manpage with new memfd F_SEAL_FUTURE_WRITE seal

man2/fcntl.2| 15 +++
man2/memfd_create.2 | 15 ++-
2 files changed, 29 insertions(+), 1 deletion(-)

--
2.20.1.97.g81188d93c3-goog

Re: [PATCH v3 0/6] Static calls

[Andy Lutomirski]

On Fri, Jan 11, 2019 at 1:22 PM Josh Poimboeuf  wrote:
>
> On Fri, Jan 11, 2019 at 12:46:39PM -0800, Linus Torvalds wrote:
> > On Fri, Jan 11, 2019 at 12:31 PM Josh Poimboeuf  wrote:
> > >
> > > I was referring to the fact that a single static call key update will
> > > usually result in patching multiple call sites.  But you're right, it's
> > > only 1-2 trampolines per text_poke_bp() invocation.  Though eventually
> > > we may want to batch all the writes like what Daniel has proposed for
> > > jump labels, to reduce IPIs.
> >
> > Yeah, my suggestion doesn't allow for batching, since it would
> > basically generate one trampoline for every rewritten instruction.
>
> As Andy said, I think batching would still be possible, it's just that
> we'd have to create multiple trampolines at a time.
>
> Or... we could do a hybrid approach: create a single custom trampoline
> which has the call destination patched in, but put the return address in
> %rax -- which is always clobbered, even for callee-saved PV ops.  Like:
>

One think I particularly like about the current design is that there
are no requirements at all on the calling convention.  I think it
seems fragile to add a calling convention constraint that only applies
when there's a race.  I'd rather do a longjmp-like hack or a stack gap
adding hack than make the actual static calls more fragile.

Re: [PATCH v5 1/2] powerpc/32: add stack protector support

[Samuel Holland]

Hello all,

On 09/27/18 02:05, Christophe Leroy wrote:
[..snip..]
> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index 07d9dce7eda6..45b8eb4d8fe7 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -112,6 +112,9 @@ KBUILD_LDFLAGS+= -m elf$(BITS)$(LDEMULATION)
>  KBUILD_ARFLAGS   += --target=elf$(BITS)-$(GNUTARGET)
>  endif
>  
> +cflags-$(CONFIG_STACKPROTECTOR)  += -mstack-protector-guard=tls
> +cflags-$(CONFIG_STACKPROTECTOR)  += -mstack-protector-guard-reg=r2
> +
>  LDFLAGS_vmlinux-y := -Bstatic
>  LDFLAGS_vmlinux-$(CONFIG_RELOCATABLE) := -pie
>  LDFLAGS_vmlinux  := $(LDFLAGS_vmlinux-y)
> @@ -404,6 +407,13 @@ archclean:
>  
>  archprepare: checkbin
>  
> +ifdef CONFIG_STACKPROTECTOR
> +prepare: stack_protector_prepare
> +
> +stack_protector_prepare: prepare0
> + $(eval KBUILD_CFLAGS += -mstack-protector-guard-offset=$(shell awk '{if 
> ($$2 == "TASK_CANARY") print $$3;}' include/generated/asm-offsets.h))
> +endif
> +

This breaks when building out-of-tree kernel modules. GCC is not getting passed
the -mstack-protector-guard-offset argument, so the default offset is used. The
kernel then panics the first time a function with stack protector is called.

I'm seeing this on powerpc64. It looks like it was reported for powerpc on
kernel bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201891

Linux 4.20 does not have a "prepare" target when KBUILD_EXTMOD is set. One is
added by:

  commit e07db28eea38ed4e332b3a89f3995c86b713cb5b
  Author: Masahiro Yamada 
  Date:   Thu Nov 22 08:11:54 2018 +0900

  kbuild: fix single target build for external module

However, after cherry-picking that patch, the build fails because it's missing
prepare0. I applied the patch below and I successfully built an out-of-tree
module with CONFIG_STACKPROTECTOR=y.

diff --git a/Makefile b/Makefile
index 826826553085..f0a93e1ba1b6 100644
--- a/Makefile
+++ b/Makefile
@@ -1596,9 +1596,10 @@ help:
@echo  ''

 # Dummies...
-PHONY += prepare scripts
-prepare:
+PHONY += prepare prepare0 scripts
+prepare: prepare0
$(cmd_crmodverdir)
+prepare0: ;
 scripts: ;
 endif # KBUILD_EXTMOD

The context has been changed some in later patches, but I think a change like
this one should go into 5.0, and it e07db28eea38 should go into 4.20.y.

Thanks,
Samuel

Re: stack-protector: fix CC_HAS_STACKPROTECTOR_NONE depend on -fno-stack-protector

[Masahiro Yamada]

On Sat, Jan 12, 2019 at 12:57 PM 隆春  wrote:
>
> commit（2a61f4747eeaa85ce26ca9fbd81421b15facd018）rename CC_STACKPROTECTOR_NONE
> config. but unfortunately if the compiler support option -fno-stack-protector,
> CC_HAS_STACKPROTECTOR_NONE will not be disabled.

You completely misunderstood that commit.


The meaning of CC_HAS_STACKPROTECTOR_NONE is
"the compiler recognizes -fno-stack-protector option"
instead of "disable the stack protector".




Now that STACKPROTECTOR is a boolean option,
CONFIG_STACKPROTECTOR=n means "disable the stack protector".




> CC_HAS_STACKPROTECTOR_NONE and CC_STACKPROTECTOR_STRONG will be enabled at 
> once,
> as the following conditions:
> 1. gcc support -fno-stack-protector & -fstack-protector-strong
> 2. enabled CC_STACKPROTECTOR_STRONG & STACKPROTECTOR


CC_STACKPROTECTOR_STRONG does not exist any more.

STACKPROTECTOR_STRONG and STACKPROTECTOR exist.




> 3. disabled CC_HAS_STACKPROTECTOR_NONE

This represents the compiler capability.

Not a user-configurable option.



>
>
>


-- 
Best Regards
Masahiro Yamada

Re: [PATCH] Input: synaptics - add PNP IDs for Dell XPS models to forcepad

[Kim Phillips]

On 1/11/19 7:40 PM, Dmitry Torokhov wrote:
> Hi Kim,

Hi Dmitry,

> On Fri, Jan 11, 2019 at 02:54:30PM -0600, Kim Phillips wrote:
>> This patch is the result of seeing this message:
>>
>> psmouse serio1: synaptics: Your touchpad (PNP: DLL087c PNP0f13) says it can 
>> support a different bus. If i2c-hid and hid-rmi are not used, you might want 
>> to try setting psmouse.synaptics_intertouch to 1 and report this to 
>> linux-in...@vger.kernel.org.
>>
>> If I set psmouse.synaptics_intertouch=1, or add the PNP ID to
>> smbus_pnp_ids, the touchpad continues to work, and the above message
>> goes away, but we now get:
>>
>> psmouse serio1: synaptics: Trying to set up SMBus access
>> psmouse serio1: synaptics: SMbus companion is not ready yet
>>
>> With this patch applied, i.e., the PNP IDs are added to the forcepad
>> array, the touchpad continues to work and all of the above messages
>> disappear.
> 
> Are you sure the touchpad in XPSes is a forcepad (i.e. it does not have
> physical button underneath it)? As far as I know there were only couple
> of HP laptops with forcepads and when switching to RMI mode forcepads
> need F21 handler that we do not currently have in the kernel.

I see, no, I'm not sure, but assuming you're right, the IDs 
should be added to the smbus array instead, after fixing 
the SMbus "companion not ready" problem?  Pointers for that and 
the below interrupts when touchpad idle after resume, welcome.

Also, the link to get the RMI4 spec in
Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
is broken.  Any pointers for that also appreciated.

>> ---
>> With or without this patch, I'm seeing a problem where when the XPS 15
>> comes out of a resume, and without even touching the touchpad, I notice
>> about 600 interrupts per second firing on the "IR-IO-APIC   51-fasteoi
>> SYNA2393:00" line in /proc/interrupts.  If I start using the touchpad,
>> then leave it alone, I check if there are still interrupts firing, and
>> they have indeed stopped.  This adversely affects my battery life when
>> using an external mouse.  Any ideas on how to debug the situation?
>> Could it be related to the 'vdd not found' messages?:
>>
>> $ dmesg | grep -C 1 -i syna
>> probe of 1-12 returned 1 after 2343 usecs
>> psmouse serio1: synaptics: queried max coordinates: x [..5664], y [..4646]
>> psmouse serio1: synaptics: queried min coordinates: x [1278..], y [1206..]
>> psmouse serio1: synaptics: Touchpad model: 1, fw: 8.2, id: 0x1e2b1, caps: 
>> 0xf00123/0x840300/0x12e800/0x0, board id: 3125, fw id: 2378871
>> input: SynPS/2 Synaptics TouchPad as 
>> /devices/platform/i8042/serio1/input/input6
>> probe of serio1 returned 1 after 939332 usecs
>> --
>> probe of idma64.1 returned 1 after 72 usecs
>> i2c_hid i2c-SYNA2393:00: i2c-SYNA2393:00 supply vdd not found, using dummy 
>> regulator
>> i2c_hid i2c-SYNA2393:00: Linked as a consumer to regulator.0
>> i2c_hid i2c-SYNA2393:00: i2c-SYNA2393:00 supply vddl not found, using dummy 
>> regulator
>> ath10k_pci :3b:00.0: qca6174 hw3.2 target 0x0503 chip_id 0x00340aff 
>> sub 1a56:1535
>> --
>> ath10k_pci :3b:00.0: firmware ver WLAN.RM.4.4.1-00079-QCARMSWPZ-1 api 6 
>> features wowlan,ignore-otp crc32 fd869beb
>> probe of i2c-SYNA2393:00 returned 1 after 23978 usecs
>> ath10k_pci :3b:00.0: board_file api 2 bmi_id N/A crc32 20d869c3
>> --
>> probe of 0018:056A:488F.0001 returned 1 after 1366 usecs
>> input: SYNA2393:00 06CB:7A13 Mouse as 
>> /devices/pci:00/:00:15.1/i2c_designware.1/i2c-10/i2c-SYNA2393:00/0018:06CB:7A13.0002/input/input23
>> input: SYNA2393:00 06CB:7A13 Touchpad as 
>> /devices/pci:00/:00:15.1/i2c_designware.1/i2c-10/i2c-SYNA2393:00/0018:06CB:7A13.0002/input/input24
>> hid-generic 0018:06CB:7A13.0002: input,hidraw1: I2C HID v1.00 Mouse 
>> [SYNA2393:00 06CB:7A13] on i2c-SYNA2393:00
>> probe of 0018:06CB:7A13.0002 returned 1 after 320 usecs
>> --
>> probe of 0018:06CB:7A13.0002 returned 0 after 5 usecs
>> input: SYNA2393:00 06CB:7A13 Touchpad as 
>> /devices/pci:00/:00:15.1/i2c_designware.1/i2c-10/i2c-SYNA2393:00/0018:06CB:7A13.0002/input/input27
>> hid-multitouch 0018:06CB:7A13.0002: input,hidraw1: I2C HID v1.00 Mouse 
>> [SYNA2393:00 06CB:7A13] on i2c-SYNA2393:00
>> probe of 0018:06CB:7A13.0002 returned 1 after 25104 usecs

Thanks,

Kim

[PATCH v5 4/4] PCI: imx6: Add support for i.MX8MQ

[Andrey Smirnov]

Add code needed to support i.MX8MQ variant.

Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Reviewed-by: Lucas Stach 
Signed-off-by: Andrey Smirnov 
---
 .../bindings/pci/fsl,imx6q-pcie.txt   |  3 +-
 drivers/pci/controller/dwc/Kconfig|  4 +-
 drivers/pci/controller/dwc/pci-imx6.c | 77 ++-
 3 files changed, 79 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt 
b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
index d514c1f2365f..920ca93870a8 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
@@ -9,6 +9,7 @@ Required properties:
- "fsl,imx6sx-pcie",
- "fsl,imx6qp-pcie"
- "fsl,imx7d-pcie"
+   - "fsl,imx8mq-pcie"
 - reg: base address and length of the PCIe controller
 - interrupts: A list of interrupt outputs of the controller. Must contain an
   entry for each entry in the interrupt-names property.
@@ -45,7 +46,7 @@ Additional required properties for imx6sx-pcie:
   PCIE_PHY power domains
 - power-domain-names: Must be "pcie", "pcie_phy"
 
-Additional required properties for imx7d-pcie:
+Additional required properties for imx7d-pcie and imx8mq-pcie:
 - power-domains: Must be set to a phandle pointing to PCIE_PHY power domain
 - resets: Must contain phandles to PCIe-related reset lines exposed by SRC
   IP block
diff --git a/drivers/pci/controller/dwc/Kconfig 
b/drivers/pci/controller/dwc/Kconfig
index 6aafec3fad00..adf7f2061890 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -89,8 +89,8 @@ config PCI_EXYNOS
select PCIE_DW_HOST
 
 config PCI_IMX6
-   bool "Freescale i.MX6/7 PCIe controller"
-   depends on SOC_IMX6Q || SOC_IMX7D || (ARM && COMPILE_TEST)
+   bool "Freescale i.MX6/7/8 PCIe controller"
+   depends on SOC_IMX6Q || SOC_IMX7D || (ARM64 && ARCH_MXC) || COMPILE_TEST
depends on PCI_MSI_IRQ_DOMAIN
select PCIE_DW_HOST
 
diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 75ee0cd7af3b..dd9d8732f6ba 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -8,6 +8,7 @@
  * Author: Sean Cross 
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -32,6 +33,12 @@
 
 #include "pcie-designware.h"
 
+#define IMX8MQ_GPR_PCIE_REF_USE_PADBIT(9)
+#define IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE_ENBIT(10)
+#define IMX8MQ_GPR_PCIE_CLK_REQ_OVERRIDE   BIT(11)
+#define IMX8MQ_GPR12_PCIE2_CTRL_DEVICE_TYPEGENMASK(11, 8)
+#define IMX8MQ_PCIE2_BASE_ADDR 0x33c0
+
 #define to_imx6_pcie(x)dev_get_drvdata((x)->dev)
 
 enum imx6_pcie_variants {
@@ -39,6 +46,7 @@ enum imx6_pcie_variants {
IMX6SX,
IMX6QP,
IMX7D,
+   IMX8MQ,
 };
 
 #define IMX6_PCIE_FLAG_IMX6_PHYBIT(0)
@@ -58,6 +66,7 @@ struct imx6_pcie {
struct clk  *pcie_inbound_axi;
struct clk  *pcie;
struct regmap   *iomuxc_gpr;
+   u32 controller_id;
struct reset_control*pciephy_reset;
struct reset_control*apps_reset;
struct reset_control*turnoff_reset;
@@ -276,6 +285,7 @@ static void imx6_pcie_reset_phy(struct imx6_pcie *imx6_pcie)
pcie_phy_write(imx6_pcie, PHY_RX_OVRD_IN_LO, tmp);
 }
 
+#ifdef CONFIG_ARM
 /*  Added for PCI abort handling */
 static int imx6q_pcie_abort_handler(unsigned long addr,
unsigned int fsr, struct pt_regs *regs)
@@ -309,6 +319,7 @@ static int imx6q_pcie_abort_handler(unsigned long addr,
 
return 1;
 }
+#endif
 
 static int imx6_pcie_attach_pd(struct device *dev)
 {
@@ -353,6 +364,7 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie 
*imx6_pcie)
 
switch (imx6_pcie->drvdata->variant) {
case IMX7D:
+   case IMX8MQ:
reset_control_assert(imx6_pcie->pciephy_reset);
reset_control_assert(imx6_pcie->apps_reset);
break;
@@ -387,10 +399,17 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie 
*imx6_pcie)
}
 }
 
+static unsigned int imx6_pcie_grp_offset(const struct imx6_pcie *imx6_pcie)
+{
+   WARN_ON(imx6_pcie->drvdata->variant != IMX8MQ);
+   return imx6_pcie->controller_id == 1 ? IOMUXC_GPR16 : IOMUXC_GPR14;
+}
+
 static int imx6_pcie_enable_ref_clk(struct imx6_pcie *imx6_pcie)
 {
struct dw_pcie *pci = imx6_pcie->pci;
struct device *dev = pci->dev;
+   unsigned int offset;
int ret = 0;
 
switch (imx6_pcie->drvdata->variant) {
@@ -421,6 +440,19 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie 

[PATCH v5 3/4] PCI: imx6: Convert DIRECT_SPEED_CHANGE quirk code to use a flag

[Andrey Smirnov]

Both i.MX7D and i.MX8MQ have the same behaviour when it comes to
clearing DIRECT_SPEED_CHANGE bit when no speed change occur. To
account for that change the code handling that to use a generic flag
instead of checking IP block variant.

Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Reviewed-by: Lucas Stach 
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pci-imx6.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index c55d93c1187d..75ee0cd7af3b 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -42,6 +42,7 @@ enum imx6_pcie_variants {
 };
 
 #define IMX6_PCIE_FLAG_IMX6_PHYBIT(0)
+#define IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE   BIT(1)
 
 struct imx6_pcie_drvdata {
enum imx6_pcie_variants variant;
@@ -711,7 +712,8 @@ static int imx6_pcie_establish_link(struct imx6_pcie 
*imx6_pcie)
tmp |= PORT_LOGIC_SPEED_CHANGE;
dw_pcie_writel_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL, tmp);
 
-   if (imx6_pcie->drvdata->variant != IMX7D) {
+   if (imx6_pcie->drvdata->flags &
+   IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE) {
/*
 * On i.MX7, DIRECT_SPEED_CHANGE behaves differently
 * from i.MX6 family when no link speed transition
@@ -1097,15 +1099,18 @@ static void imx6_pcie_shutdown(struct platform_device 
*pdev)
 static const struct imx6_pcie_drvdata drvdata[] = {
[IMX6Q] = {
.variant = IMX6Q,
-   .flags = IMX6_PCIE_FLAG_IMX6_PHY,
+   .flags = IMX6_PCIE_FLAG_IMX6_PHY |
+IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE,
},
[IMX6SX] = {
.variant = IMX6SX,
-   .flags = IMX6_PCIE_FLAG_IMX6_PHY,
+   .flags = IMX6_PCIE_FLAG_IMX6_PHY |
+IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE,
},
[IMX6QP] = {
.variant = IMX6QP,
-   .flags = IMX6_PCIE_FLAG_IMX6_PHY,
+   .flags = IMX6_PCIE_FLAG_IMX6_PHY |
+IMX6_PCIE_FLAG_IMX6_SPEED_CHANGE,
},
[IMX7D] = {
.variant = IMX7D,
-- 
2.20.1

[PATCH v5 2/4] PCI: imx6: Mark PHY functions as i.MX6 specific

[Andrey Smirnov]

PCIE PHY IP block on i.MX7D differs from the one used on i.MX6 family,
so none of the code in current implementation of imx6_setup_phy_mpll()
is applicable.

Tested-by: Trent Piepho 
Signed-off-by: Andrey Smirnov 
Reviewed-by: Lucas Stach 
Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/pci/controller/dwc/pci-imx6.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index efff3d5e9162..c55d93c1187d 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -41,8 +41,11 @@ enum imx6_pcie_variants {
IMX7D,
 };
 
+#define IMX6_PCIE_FLAG_IMX6_PHYBIT(0)
+
 struct imx6_pcie_drvdata {
enum imx6_pcie_variants variant;
+   u32 flags;
 };
 
 struct imx6_pcie {
@@ -256,6 +259,9 @@ static void imx6_pcie_reset_phy(struct imx6_pcie *imx6_pcie)
 {
u32 tmp;
 
+   if (!(imx6_pcie->drvdata->flags & IMX6_PCIE_FLAG_IMX6_PHY))
+   return;
+
pcie_phy_read(imx6_pcie, PHY_RX_OVRD_IN_LO, );
tmp |= (PHY_RX_OVRD_IN_LO_RX_DATA_EN |
PHY_RX_OVRD_IN_LO_RX_PLL_EN);
@@ -573,6 +579,9 @@ static int imx6_setup_phy_mpll(struct imx6_pcie *imx6_pcie)
int mult, div;
u32 val;
 
+   if (!(imx6_pcie->drvdata->flags & IMX6_PCIE_FLAG_IMX6_PHY))
+   return 0;
+
switch (phy_rate) {
case 12500:
/*
@@ -1088,12 +1097,15 @@ static void imx6_pcie_shutdown(struct platform_device 
*pdev)
 static const struct imx6_pcie_drvdata drvdata[] = {
[IMX6Q] = {
.variant = IMX6Q,
+   .flags = IMX6_PCIE_FLAG_IMX6_PHY,
},
[IMX6SX] = {
.variant = IMX6SX,
+   .flags = IMX6_PCIE_FLAG_IMX6_PHY,
},
[IMX6QP] = {
.variant = IMX6QP,
+   .flags = IMX6_PCIE_FLAG_IMX6_PHY,
},
[IMX7D] = {
.variant = IMX7D,
-- 
2.20.1

[PATCH v5 0/4] PCIE support for i.MX8MQ

[Andrey Smirnov]

Everyone:

This series contains changes I made in order to enable support of PCIE
IP block on i.MX8MQ SoCs.

Changes since [v4]:

 - Collected Reviewed-by from Lucas

 - Replaced ((ARM || ARM64) && COMPILE_TEST) with COMPILE_TEST as per
   suggestion from Rob

Changes since [v3]:

 - Based on feedback from NXP, DIRECT_SPEED_CHANGE quirk was expanded
   to cover both i.MX7 and i.MX8MQ

 - Code setting device type in GPR12 moved to a standalone function

 - Explicit "fsl,controller-id" binding was dropped, replaced by using
   controller physical address to determine logical ID

 - Dropped Reviewed-by from Lucas for patch 4/4 due to the change
   above (haven't heard explicit "yea" for it from him)

Changes since [v2], [fixes]:

 - Incorporated [patch] introducing drvdata

 - i.MX6 PHY operation gating converted to a single patch and to use a
   dedicated flag instead of doing explicit variant check

 - Kconfig entry changed to use ARM64 && ARCH_MXC

 - Dropped FALLTHROUGH annotations

Changes since [v1]:

 - Driver changed to use single "fsl,controller-id" property to
   distinguish between two intances of PCIE IP block

 - All code pertaining to L1SS was dropped to simplify the patch

 - Documented additions to DT bindings

Feedback is welcome!

Thanks,
Andrey Smirnov

[v4] 
https://lore.kernel.org/linux-arm-kernel/20190104165335.13205-1-andrew.smir...@gmail.com
[v3] 
https://lore.kernel.org/linux-arm-kernel/20181218040702.29231-1-andrew.smir...@gmail.com
[patch] https://patchwork.kernel.org/patch/10712261/
[fixes] 
https://lore.kernel.org/linux-arm-kernel/20181216230916.22982-1-andrew.smir...@gmail.com
[v2] 
https://lore.kernel.org/linux-arm-kernel/20181206073545.10967-1-andrew.smir...@gmail.com
[v1] 
https://lore.kernel.org/linux-arm-kernel/20181117181225.10737-1-andrew.smir...@gmail.com/

Andrey Smirnov (4):
  PCI: imx6: introduce drvdata
  PCI: imx6: Mark PHY functions as i.MX6 specific
  PCI: imx6: Convert DIRECT_SPEED_CHANGE quirk code to use a flag
  PCI: imx6: Add support for i.MX8MQ

 .../bindings/pci/fsl,imx6q-pcie.txt   |   3 +-
 drivers/pci/controller/dwc/Kconfig|   4 +-
 drivers/pci/controller/dwc/pci-imx6.c | 150 +++---
 3 files changed, 133 insertions(+), 24 deletions(-)

-- 
2.20.1

[PATCH v5 1/4] PCI: imx6: introduce drvdata

[Andrey Smirnov]

Introduce driver data struct. This will simplify handling of device
specific differences.

Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Stefan Agner 
Reviewed-by: Lucas Stach 
[andrew.smir...@gmail.com reformatted drvdata, to simplify future diffs]
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pci-imx6.c | 56 ++-
 1 file changed, 37 insertions(+), 19 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 25a2b7683e55..efff3d5e9162 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -41,6 +41,10 @@ enum imx6_pcie_variants {
IMX7D,
 };
 
+struct imx6_pcie_drvdata {
+   enum imx6_pcie_variants variant;
+};
+
 struct imx6_pcie {
struct dw_pcie  *pci;
int reset_gpio;
@@ -53,7 +57,6 @@ struct imx6_pcie {
struct reset_control*pciephy_reset;
struct reset_control*apps_reset;
struct reset_control*turnoff_reset;
-   enum imx6_pcie_variants variant;
u32 tx_deemph_gen1;
u32 tx_deemph_gen2_3p5db;
u32 tx_deemph_gen2_6db;
@@ -66,6 +69,7 @@ struct imx6_pcie {
struct device   *pd_pcie;
/* power domain for pcie phy */
struct device   *pd_pcie_phy;
+   const struct imx6_pcie_drvdata *drvdata;
 };
 
 /* Parameters for the waiting for PCIe PHY PLL to lock on i.MX7 */
@@ -340,7 +344,7 @@ static void imx6_pcie_assert_core_reset(struct imx6_pcie 
*imx6_pcie)
 {
struct device *dev = imx6_pcie->pci->dev;
 
-   switch (imx6_pcie->variant) {
+   switch (imx6_pcie->drvdata->variant) {
case IMX7D:
reset_control_assert(imx6_pcie->pciephy_reset);
reset_control_assert(imx6_pcie->apps_reset);
@@ -382,7 +386,7 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie 
*imx6_pcie)
struct device *dev = pci->dev;
int ret = 0;
 
-   switch (imx6_pcie->variant) {
+   switch (imx6_pcie->drvdata->variant) {
case IMX6SX:
ret = clk_prepare_enable(imx6_pcie->pcie_inbound_axi);
if (ret) {
@@ -485,7 +489,7 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie 
*imx6_pcie)
!imx6_pcie->gpio_active_high);
}
 
-   switch (imx6_pcie->variant) {
+   switch (imx6_pcie->drvdata->variant) {
case IMX7D:
reset_control_deassert(imx6_pcie->pciephy_reset);
imx7d_pcie_wait_for_phy_pll_lock(imx6_pcie);
@@ -523,7 +527,7 @@ static void imx6_pcie_deassert_core_reset(struct imx6_pcie 
*imx6_pcie)
 
 static void imx6_pcie_init_phy(struct imx6_pcie *imx6_pcie)
 {
-   switch (imx6_pcie->variant) {
+   switch (imx6_pcie->drvdata->variant) {
case IMX7D:
regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL, 0);
@@ -645,7 +649,7 @@ static void imx6_pcie_ltssm_enable(struct device *dev)
 {
struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
 
-   switch (imx6_pcie->variant) {
+   switch (imx6_pcie->drvdata->variant) {
case IMX6Q:
case IMX6SX:
case IMX6QP:
@@ -698,7 +702,7 @@ static int imx6_pcie_establish_link(struct imx6_pcie 
*imx6_pcie)
tmp |= PORT_LOGIC_SPEED_CHANGE;
dw_pcie_writel_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL, tmp);
 
-   if (imx6_pcie->variant != IMX7D) {
+   if (imx6_pcie->drvdata->variant != IMX7D) {
/*
 * On i.MX7, DIRECT_SPEED_CHANGE behaves differently
 * from i.MX6 family when no link speed transition
@@ -801,7 +805,7 @@ static void imx6_pcie_ltssm_disable(struct device *dev)
 {
struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
 
-   switch (imx6_pcie->variant) {
+   switch (imx6_pcie->drvdata->variant) {
case IMX6SX:
case IMX6QP:
regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
@@ -827,7 +831,7 @@ static void imx6_pcie_pm_turnoff(struct imx6_pcie 
*imx6_pcie)
}
 
/* Others poke directly at IOMUXC registers */
-   switch (imx6_pcie->variant) {
+   switch (imx6_pcie->drvdata->variant) {
case IMX6SX:
regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
IMX6SX_GPR12_PCIE_PM_TURN_OFF,
@@ -857,7 +861,7 @@ static void imx6_pcie_clk_disable(struct imx6_pcie 
*imx6_pcie)
clk_disable_unprepare(imx6_pcie->pcie_phy);

Re: [PATCH v2] arm64: dts: rockchip: add ROCK Pi 4 DTS support

[Heiko Stuebner]

Am Sonntag, 6. Januar 2019, 05:40:10 CET schrieb pragnesh_pa...@mentor.com:
> From: Akash Gajjar 
> 
> ROCK Pi 4 is RK3399 based SBC from radxa.com. board has a 1G/2G/4G lpddr4, 
> CSI,
> DSI, HDMI, OTG, USB 2.0, USB 3.0, 10/100/1000 RGMII Ethernet Phy, es8316 
> codec,
> POE, WIFI (for Model B only), PCIE M.2 support on board.
> 
> This patch enables
> - HDMI Display
> - Console
> - MMC, EMMC
> - USB 2.0, USB-3.0
> - Ethernet
> 
> Signed-off-by: Akash Gajjar 
> Signed-off-by: Pragnesh Patel 

applied for 5.1

Thanks
Heiko

Re: [PATCH 4.20 41/65] Revert "powerpc/tm: Unset MSR[TS] if not recheckpointing"

[Christoph Biedl]

Greg Kroah-Hartman wrote...

> 4.20-stable review patch.  If anyone has any objections, please let me know.
>
> --
>
> From: Greg Kroah-Hartman 
>
> This reverts commit d412deb85a4aada382352a8202beb7af8921cd53 which is
> commit 6f5b9f018f4c7686fd944d920209d1382d320e4e upstream.
>
> It breaks the powerpc build, so drop it from the tree until a fix goes
> upstream.

Is this necessary on 4.20? The build failures I reported were on 4.19
only. The 4.20.2-rc1 kernel for my Powermac G5 builds with and without
that patch, both boot fine, no visible differences. Again however, Breno
is authoritative here.

Aside, I also checked 4.19.15-rc1, builds and runs without any
noticeable problems.

Christoph

Re: [PATCH 4.14 058/105] tools: fix cross-compile var clobbering

[Martin Kelly]

On 1/12/19 1:18 PM, Sudip Mukherjee wrote:

Hi Greg,

On Fri, Jan 11, 2019 at 2:34 PM Greg Kroah-Hartman
 wrote:


4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Martin Kelly 

commit 7ed1c1901fe52e6c5828deb155920b44b0adabb1 upstream.


This was fixed upstream by 755396163148 ("tools: power/acpi, revert to
LD = gcc")




Yes, both patches should be applied. This patch fixed a bunch of 
Makefiles but caused a regression in power/acpi, which is fixed by

755396163148.

Re: UBSAN: Undefined behaviour in net/can/bcm.c

[Oliver Hartkopp]

On 1/12/19 10:03 PM, Kyungtae Kim wrote:

On Sat, Jan 12, 2019 at 3:02 PM Oliver Hartkopp  wrote:


So there could potentially be some other users of timeval_to_ktime()
that might have the same issue.



The following would be the one related.


Yes - it is also in bcm_rx_setup(). Same issue can potentially occur in 
bcm_tx_setup().


Will send a patch for testing in a minute.

Many thanks,
Oliver



=
UBSAN: Undefined behaviour in ./include/linux/ktime.h:42:14
signed integer overflow:
-3428892174463270912 * 10 cannot be represented in type 'long int'
CPU: 0 PID: 7024 Comm: syz-executor6 Not tainted 4.19.13 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
  __dump_stack lib/dump_stack.c:77 [inline]
  dump_stack+0xd2/0x148 lib/dump_stack.c:113
  ubsan_epilogue+0x12/0x94 lib/ubsan.c:159
  handle_overflow+0x1cf/0x21a lib/ubsan.c:190
  __ubsan_handle_mul_overflow+0x2a/0x35 lib/ubsan.c:214
  bcm_timeval_to_ktime include/linux/ktime.h:42 [inline]
  bcm_rx_setup net/can/bcm.c:1189 [inline]
  bcm_sendmsg+0x35ea/0x3fd0 net/can/bcm.c:1355
  sock_sendmsg_nosec net/socket.c:621 [inline]
  sock_sendmsg+0xdd/0x130 net/socket.c:631
  sock_write_iter+0x24b/0x3d0 net/socket.c:900
  call_write_iter include/linux/fs.h:1811 [inline]
  new_sync_write fs/read_write.c:474 [inline]
  __vfs_write+0x538/0x6e0 fs/read_write.c:487
  vfs_write+0x1b3/0x520 fs/read_write.c:549
  ksys_write+0xde/0x1c0 fs/read_write.c:598
  __do_sys_write fs/read_write.c:610 [inline]
  __se_sys_write fs/read_write.c:607 [inline]
  __x64_sys_write+0x7e/0xc0 fs/read_write.c:607
  do_syscall_64+0xc4/0x510 arch/x86/entry/common.c:290
  entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4497b9
Code: e8 8c 9f 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
01 f0 ff ff 0f 83 9b 6b fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f6045f43c68 EFLAGS: 0246 ORIG_RAX: 0001
RAX: ffda RBX: 7f6045f446cc RCX: 004497b9
RDX: 0048 RSI: 20c0 RDI: 0013
RBP: 0071bea0 R08:  R09: 
R10:  R11: 0246 R12: 
R13: ba60 R14: 006f4b00 R15: 7f6045f44700
=

Thanks,
Kyungtae Kim

Re: [PATCH v4 4/4] PCI: imx6: Add support for i.MX8MQ

[Andrey Smirnov]

On Fri, Jan 11, 2019 at 11:53 AM Rob Herring  wrote:
>
> On Fri, Jan 04, 2019 at 08:53:35AM -0800, Andrey Smirnov wrote:
> > Add code needed to support i.MX8MQ variant.
> >
> > Cc: Bjorn Helgaas 
> > Cc: Fabio Estevam 
> > Cc: Chris Healy 
> > Cc: Lucas Stach 
> > Cc: Leonard Crestez 
> > Cc: "A.s. Dong" 
> > Cc: Richard Zhu 
> > Cc: Rob Herring ,
> > Cc: devicet...@vger.kernel.org,
> > Cc: linux-...@nxp.com
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-kernel@vger.kernel.org
> > Cc: linux-...@vger.kernel.org
> > Signed-off-by: Andrey Smirnov 
> > ---
> >  .../bindings/pci/fsl,imx6q-pcie.txt   |  3 +-
> >  drivers/pci/controller/dwc/Kconfig|  4 +-
> >  drivers/pci/controller/dwc/pci-imx6.c | 77 ++-
> >  3 files changed, 79 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt 
> > b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> > index d514c1f2365f..920ca93870a8 100644
> > --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> > +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> > @@ -9,6 +9,7 @@ Required properties:
> >   - "fsl,imx6sx-pcie",
> >   - "fsl,imx6qp-pcie"
> >   - "fsl,imx7d-pcie"
> > + - "fsl,imx8mq-pcie"
> >  - reg: base address and length of the PCIe controller
> >  - interrupts: A list of interrupt outputs of the controller. Must contain 
> > an
> >entry for each entry in the interrupt-names property.
> > @@ -45,7 +46,7 @@ Additional required properties for imx6sx-pcie:
> >PCIE_PHY power domains
> >  - power-domain-names: Must be "pcie", "pcie_phy"
> >
> > -Additional required properties for imx7d-pcie:
> > +Additional required properties for imx7d-pcie and imx8mq-pcie:
> >  - power-domains: Must be set to a phandle pointing to PCIE_PHY power domain
> >  - resets: Must contain phandles to PCIe-related reset lines exposed by SRC
> >IP block
> > diff --git a/drivers/pci/controller/dwc/Kconfig 
> > b/drivers/pci/controller/dwc/Kconfig
> > index 6aafec3fad00..83ea318ad989 100644
> > --- a/drivers/pci/controller/dwc/Kconfig
> > +++ b/drivers/pci/controller/dwc/Kconfig
> > @@ -89,8 +89,8 @@ config PCI_EXYNOS
> >   select PCIE_DW_HOST
> >
> >  config PCI_IMX6
> > - bool "Freescale i.MX6/7 PCIe controller"
> > - depends on SOC_IMX6Q || SOC_IMX7D || (ARM && COMPILE_TEST)
> > + bool "Freescale i.MX6/7/8 PCIe controller"
> > + depends on SOC_IMX6Q || SOC_IMX7D || (ARM64 && ARCH_MXC) || ((ARM || 
> > ARM64) && COMPILE_TEST)
>
> Since you added the ifdef around the abort handler, I think you can drop
> "(ARM || ARM64)" and enable building other arches.
>

OK, makes sense. I'll give it a go in v5.

Thanks,
Andrey Smirnov

Re: [PATCH 4.14 024/105] bnx2x: Remove configured vlans as part of unload sequence.

[Sudip Mukherjee]

Hi Greg,

On Fri, Jan 11, 2019 at 2:33 PM Greg Kroah-Hartman
 wrote:
>
> 4.14-stable review patch.  If anyone has any objections, please let me know.
>
> --
>
> [ Upstream commit 04f05230c5c13b1384f66f5186a68d7499e34622 ]

This was fixed upstream by 38355a5f9a22 ("bnx2x: Fix NULL pointer
dereference in bnx2x_del_all_vlans() on some hw")


-- 
Regards
Sudip

Re: [PATCH 4.14 058/105] tools: fix cross-compile var clobbering

[Sudip Mukherjee]

Hi Greg,

On Fri, Jan 11, 2019 at 2:34 PM Greg Kroah-Hartman
 wrote:
>
> 4.14-stable review patch.  If anyone has any objections, please let me know.
>
> --
>
> From: Martin Kelly 
>
> commit 7ed1c1901fe52e6c5828deb155920b44b0adabb1 upstream.

This was fixed upstream by 755396163148 ("tools: power/acpi, revert to
LD = gcc")


-- 
Regards
Sudip

Re: [PATCH] mmc: Fix Kconfig warnings on keystone_defconfig

[Borislav Petkov]

On Wed, Jan 09, 2019 at 06:13:12PM +0530, Faiz Abbas wrote:
> Commit 961de0a856e3 ("mmc: sdhci-omap: Workaround errata regarding
> SDR104/HS200 tuning failures (i929)") added a select on TI_SOC_THERMAL
> for the driver to get temperature for tuning.
> 
> However, this causes the following warning on keystone_defconfig because
> keystone does not support TI_SOC_THERMAL:
> 
> "WARNING: unmet direct dependencies detected for TI_SOC_THERMAL"
> 
> Fix this by changing the select to imply.
> 
> Fixes: 961de0a856e3 ("mmc: sdhci-omap: Workaround errata regarding
> SDR104/HS200 tuning failures (i929)")
> Signed-off-by: Faiz Abbas 
> ---
>  drivers/mmc/host/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index e26b8145efb3..bc61eefcb695 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -978,7 +978,7 @@ config MMC_SDHCI_OMAP
>   tristate "TI SDHCI Controller Support"
>   depends on MMC_SDHCI_PLTFM && OF
>   select THERMAL
> - select TI_SOC_THERMAL
> + imply TI_SOC_THERMAL
>   help
> This selects the Secure Digital Host Controller Interface (SDHCI)
> support present in TI's DRA7 SOCs. The controller supports
> -- 

Fixes the warnings I'm seeing with randconfig builds.

Tested-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: UBSAN: Undefined behaviour in net/can/bcm.c

[Kyungtae Kim]

On Sat, Jan 12, 2019 at 3:02 PM Oliver Hartkopp  wrote:
>
> So there could potentially be some other users of timeval_to_ktime()
> that might have the same issue.
>

The following would be the one related.

=
UBSAN: Undefined behaviour in ./include/linux/ktime.h:42:14
signed integer overflow:
-3428892174463270912 * 10 cannot be represented in type 'long int'
CPU: 0 PID: 7024 Comm: syz-executor6 Not tainted 4.19.13 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0xd2/0x148 lib/dump_stack.c:113
 ubsan_epilogue+0x12/0x94 lib/ubsan.c:159
 handle_overflow+0x1cf/0x21a lib/ubsan.c:190
 __ubsan_handle_mul_overflow+0x2a/0x35 lib/ubsan.c:214
 bcm_timeval_to_ktime include/linux/ktime.h:42 [inline]
 bcm_rx_setup net/can/bcm.c:1189 [inline]
 bcm_sendmsg+0x35ea/0x3fd0 net/can/bcm.c:1355
 sock_sendmsg_nosec net/socket.c:621 [inline]
 sock_sendmsg+0xdd/0x130 net/socket.c:631
 sock_write_iter+0x24b/0x3d0 net/socket.c:900
 call_write_iter include/linux/fs.h:1811 [inline]
 new_sync_write fs/read_write.c:474 [inline]
 __vfs_write+0x538/0x6e0 fs/read_write.c:487
 vfs_write+0x1b3/0x520 fs/read_write.c:549
 ksys_write+0xde/0x1c0 fs/read_write.c:598
 __do_sys_write fs/read_write.c:610 [inline]
 __se_sys_write fs/read_write.c:607 [inline]
 __x64_sys_write+0x7e/0xc0 fs/read_write.c:607
 do_syscall_64+0xc4/0x510 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4497b9
Code: e8 8c 9f 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
01 f0 ff ff 0f 83 9b 6b fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f6045f43c68 EFLAGS: 0246 ORIG_RAX: 0001
RAX: ffda RBX: 7f6045f446cc RCX: 004497b9
RDX: 0048 RSI: 20c0 RDI: 0013
RBP: 0071bea0 R08:  R09: 
R10:  R11: 0246 R12: 
R13: ba60 R14: 006f4b00 R15: 7f6045f44700
=

Thanks,
Kyungtae Kim

radeon 0000:1d:00.0: GPU lockup (current fence id 0x00000000017a66bf last fence id 0x00000000017a67a1 on ring 0)

[Borislav Petkov]

Hi guys,

my odyssey with the GPU continues. This time it didn't reset itself
but started spewing a single line about the hardware locking up.

The machine was responsive to sysrq so I was able to write out
/var/log/messages and reboot.

This is still with 4.20-rc7 but I'm building 5.0-rc1 to see if there's a
difference.

Any and all ideas what to do here are greatly appreciated.

Thx.

Jan 12 21:38:16 zn vmunix: [257393.853806] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a0 on ring 0)
Jan 12 21:38:16 zn vmunix: [257394.369780] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a0 on ring 0)
Jan 12 21:38:17 zn vmunix: [257394.877795] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:17 zn vmunix: [257395.389789] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:18 zn vmunix: [257395.901786] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:18 zn vmunix: [257396.413787] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:19 zn vmunix: [257396.925790] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:19 zn vmunix: [257397.437787] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:20 zn vmunix: [257397.949788] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:20 zn vmunix: [257398.461786] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:21 zn vmunix: [257398.973824] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:21 zn vmunix: [257399.485828] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:22 zn vmunix: [257399.997842] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:22 zn vmunix: [257400.509852] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:23 zn vmunix: [257401.021845] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:23 zn vmunix: [257401.533826] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:24 zn vmunix: [257402.045822] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:24 zn vmunix: [257402.557826] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:25 zn vmunix: [257403.069833] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:25 zn vmunix: [257403.581826] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:26 zn vmunix: [257404.093828] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:26 zn vmunix: [257404.605827] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:27 zn vmunix: [257405.117821] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:27 zn vmunix: [257405.629883] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:28 zn vmunix: [257406.141842] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:28 zn vmunix: [257406.653828] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:29 zn vmunix: [257407.165827] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:29 zn vmunix: [257407.677827] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:30 zn vmunix: [257408.189823] radeon :1d:00.0: GPU lockup 
(current fence id 0x017a66bf last fence id 0x017a67a1 on ring 0)
Jan 12 21:38:30 zn vmunix: [257408.701827] radeon 

[PATCH] checkpatch: Add some new alloc functions to various tests

[Joe Perches]

Many new generic allocation functions like the
kvmalloc family have been added recently to the kernel.

The allocation functions test now includes:

o kvmalloc and variants
o kstrdup_const
o kmemdup_nul
o dma_alloc_coherent
o alloc_skb and variants

Add a separate $allocFunctions variable to help make
the allocation functions test a bit more readable.

Miscellanea:

o Use $allocFunctions in the unnecessary OOM message test and
  add exclude uses with __GFP_NOWARN
o Use $allocFunctions in the unnecessary cast test
o Add the kvmalloc family to the preferred sizeof alloc style
  foo = kvmalloc(sizeof(*foo), ...)

Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 155fa9305166..551da83cb00f 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -466,6 +466,16 @@ our $logFunctions = qr{(?x:
seq_vprintf|seq_printf|seq_puts
 )};
 
+our $allocFunctions = qr{(?x:
+   (?:(?:devm_)?
+   (?:kv|k|v)[czm]alloc(?:_node|_array)? |
+   kstrdup(?:_const)? |
+   kmemdup(?:_nul)?) |
+   (?:\w+)?alloc_skb(?:ip_align)? |
+   # dev_alloc_skb/netdev_alloc_skb, et al
+   dma_alloc_coherent
+)};
+
 our $signature_tags = qr{(?xi:
Signed-off-by:|
Co-developed-by:|
@@ -5547,7 +5557,8 @@ sub process {
my ($s, $c) = ctx_statement_block($linenr - 3, 
$realcnt, 0);
 #  print("line: <$line>\nprevline: <$prevline>\ns: 
<$s>\nc: <$c>\n\n\n");
 
-   if ($s =~ /(?:^|\n)[ 
\+]\s*(?:$Type\s*)?\Q$testval\E\s*=\s*(?:\([^\)]*\)\s*)?\s*(?:devm_)?(?:[kv][czm]alloc(?:_node|_array)?\b|kstrdup|kmemdup|(?:dev_)?alloc_skb)/)
 {
+   if ($s =~ /(?:^|\n)[ 
\+]\s*(?:$Type\s*)?\Q$testval\E\s*=\s*(?:\([^\)]*\)\s*)?\s*$allocFunctions\s*\(/
 &&
+   $s !~ /\b__GFP_NOWARN\b/ ) {
WARN("OOM_MESSAGE",
 "Possible unnecessary 'out of memory' 
message\n" . $hereprev);
}
@@ -6198,8 +6209,8 @@ sub process {
}
}
 
-# check for pointless casting of kmalloc return
-   if ($line =~ /\*\s*\)\s*[kv][czm]alloc(_node){0,1}\b/) {
+# check for pointless casting of alloc functions
+   if ($line =~ /\*\s*\)\s*$allocFunctions\b/) {
WARN("UNNECESSARY_CASTS",
 "unnecessary cast may hide bugs, see 
http://c-faq.com/malloc/mallocnocast.html\n; . $herecurr);
}
@@ -6207,7 +6218,7 @@ sub process {
 # alloc style
 # p = alloc(sizeof(struct foo), ...) should be p = alloc(sizeof(*p), ...)
if ($perl_version_ok &&
-   $line =~ 
/\b($Lval)\s*\=\s*(?:$balanced_parens)?\s*([kv][mz]alloc(?:_node)?)\s*\(\s*(sizeof\s*\(\s*struct\s+$Lval\s*\))/)
 {
+   $line =~ 
/\b($Lval)\s*\=\s*(?:$balanced_parens)?\s*((?:kv|k|v)[mz]alloc(?:_node)?)\s*\(\s*(sizeof\s*\(\s*struct\s+$Lval\s*\))/)
 {
CHK("ALLOC_SIZEOF_STRUCT",
"Prefer $3(sizeof(*$1)...) over $3($4...)\n" . 
$herecurr);
}

Re: [PATCH 1/2] mm: introduce put_user_page*(), placeholder versions

[John Hubbard]

On 1/11/19 7:25 PM, Jerome Glisse wrote:
[...]
 Why is it that page lock cannot be used for gup fast, btw?
>>>
>>> Well it can not happen within the preempt disable section. But after
>>> as a post pass before GUP_fast return and after reenabling preempt then
>>> it is fine like it would be for regular GUP. But locking page for GUP
>>> is also likely to slow down some workload (with direct-IO).
>>>
>>
>> Right, and so to crux of the matter: taking an uncontended page lock involves
>> pretty much the same set of operations that your approach does. (If gup ends 
>> up
>> contended with the page lock for other reasons than these paths, that seems
>> surprising.) I'd expect very similar performance.
>>
>> But the page lock approach leads to really dramatically simpler code (and 
>> code
>> reviews, let's not forget). Any objection to my going that direction, and 
>> keeping
>> this idea as a Plan B? I think the next step will be, once again, to gather 
>> some
>> performance metrics, so maybe that will help us decide.
> 
> They are already work load that suffer from the page lock so adding more
> code that need it will only worsen those situations. I guess i will do a
> patchset with my solution as it is definitly lighter weight that having to
> take the page lock.
> 

Hi Jerome,

I expect that you're right, and in any case, having you code up the new 
synchronization parts is probably a smart idea--you understand it best. To avoid
duplicating work, may I propose these steps:

1. I'll post a new RFC, using your mapcount idea, but with a minor variation: 
using the page lock to synchronize gup() and page_mkclean(). 

   a) I'll also include a github path that has enough gup callsite conversions
   done, to allow performance testing. 

   b) And also, you and others have provided a lot of information that I want to
   turn into nice neat comments and documentation.

2. Then your proposed synchronization system would only need to replace probably
one or two of the patches, instead of duplicating the whole patchset. I dread
having two large, overlapping patchsets competing, and hope we can avoid that 
mess.

3. We can run performance tests on both approaches, hopefully finding some test
cases that will highlight whether page lock is a noticeable problem here.

Or, the other thing that could happen is someone will jump in here and NAK 
anything
involving the page lock, based on long experience, and we'll just go straight to
your scheme anyway.  I'm sorta expecting that any minute now. :)

thanks,
-- 
John Hubbard
NVIDIA

[PATCH v4 1/2] mm/memfd: Add an F_SEAL_FUTURE_WRITE seal to memfd

[Joel Fernandes]

From: "Joel Fernandes (Google)" 

Android uses ashmem for sharing memory regions.  We are looking forward to
migrating all usecases of ashmem to memfd so that we can possibly remove
the ashmem driver in the future from staging while also benefiting from
using memfd and contributing to it.  Note staging drivers are also not ABI
and generally can be removed at anytime.

One of the main usecases Android has is the ability to create a region and
mmap it as writeable, then add protection against making any "future"
writes while keeping the existing already mmap'ed writeable-region active.
This allows us to implement a usecase where receivers of the shared
memory buffer can get a read-only view, while the sender continues to
write to the buffer.  See CursorWindow documentation in Android for more
details:
https://developer.android.com/reference/android/database/CursorWindow

This usecase cannot be implemented with the existing F_SEAL_WRITE seal.
To support the usecase, this patch adds a new F_SEAL_FUTURE_WRITE seal
which prevents any future mmap and write syscalls from succeeding while
keeping the existing mmap active.

A better way to do F_SEAL_FUTURE_WRITE seal was discussed [1] last week
where we don't need to modify core VFS structures to get the same
behavior of the seal. This solves several side-effects pointed by Andy.
self-tests are provided in later patch to verify the expected semantics.

[1] https://lore.kernel.org/lkml/2018173650.ga256...@google.com/

[Thanks a lot to Andy for suggestions to improve code]
Cc: Andy Lutomirski 
Signed-off-by: Joel Fernandes (Google) 
---
 fs/hugetlbfs/inode.c   |  2 +-
 include/uapi/linux/fcntl.h |  1 +
 mm/memfd.c |  3 ++-
 mm/shmem.c | 25 ++---
 4 files changed, 26 insertions(+), 5 deletions(-)

diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index 53ea3cef526e..3daf471bbd92 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -557,7 +557,7 @@ static long hugetlbfs_punch_hole(struct inode *inode, 
loff_t offset, loff_t len)
inode_lock(inode);
 
/* protected by i_mutex */
-   if (info->seals & F_SEAL_WRITE) {
+   if (info->seals & (F_SEAL_WRITE | F_SEAL_FUTURE_WRITE)) {
inode_unlock(inode);
return -EPERM;
}
diff --git a/include/uapi/linux/fcntl.h b/include/uapi/linux/fcntl.h
index 6448cdd9a350..a2f8658f1c55 100644
--- a/include/uapi/linux/fcntl.h
+++ b/include/uapi/linux/fcntl.h
@@ -41,6 +41,7 @@
 #define F_SEAL_SHRINK  0x0002  /* prevent file from shrinking */
 #define F_SEAL_GROW0x0004  /* prevent file from growing */
 #define F_SEAL_WRITE   0x0008  /* prevent writes */
+#define F_SEAL_FUTURE_WRITE0x0010  /* prevent future writes while mapped */
 /* (1U << 31) is reserved for signed error codes */
 
 /*
diff --git a/mm/memfd.c b/mm/memfd.c
index 97264c79d2cd..650e65a46b9c 100644
--- a/mm/memfd.c
+++ b/mm/memfd.c
@@ -131,7 +131,8 @@ static unsigned int *memfd_file_seals_ptr(struct file *file)
 #define F_ALL_SEALS (F_SEAL_SEAL | \
 F_SEAL_SHRINK | \
 F_SEAL_GROW | \
-F_SEAL_WRITE)
+F_SEAL_WRITE | \
+F_SEAL_FUTURE_WRITE)
 
 static int memfd_add_seals(struct file *file, unsigned int seals)
 {
diff --git a/mm/shmem.c b/mm/shmem.c
index 6ece1e2fe76e..3c98cc9655b4 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2125,6 +2125,24 @@ int shmem_lock(struct file *file, int lock, struct 
user_struct *user)
 
 static int shmem_mmap(struct file *file, struct vm_area_struct *vma)
 {
+   struct shmem_inode_info *info = SHMEM_I(file_inode(file));
+
+   if (info->seals & F_SEAL_FUTURE_WRITE) {
+   /*
+* New PROT_WRITE and MAP_SHARED mmaps are not allowed when
+* "future write" seal active.
+*/
+   if ((vma->vm_flags & VM_SHARED) && (vma->vm_flags & VM_WRITE))
+   return -EPERM;
+
+   /*
+* Since the F_SEAL_FUTURE_WRITE seals allow for a MAP_SHARED
+* read-only mapping, take care to not allow mprotect to revert
+* protections.
+*/
+   vma->vm_flags &= ~(VM_MAYWRITE);
+   }
+
file_accessed(file);
vma->vm_ops = _vm_ops;
if (IS_ENABLED(CONFIG_TRANSPARENT_HUGE_PAGECACHE) &&
@@ -2375,8 +2393,9 @@ shmem_write_begin(struct file *file, struct address_space 
*mapping,
pgoff_t index = pos >> PAGE_SHIFT;
 
/* i_mutex is held by caller */
-   if (unlikely(info->seals & (F_SEAL_WRITE | F_SEAL_GROW))) {
-   if (info->seals & F_SEAL_WRITE)
+   if (unlikely(info->seals & (F_SEAL_GROW |
+  F_SEAL_WRITE | F_SEAL_FUTURE_WRITE))) {
+   if (info->seals & (F_SEAL_WRITE | F_SEAL_FUTURE_WRITE))

[PATCH v4 0/2] Add a future write seal to memfd

[Joel Fernandes]

From: "Joel Fernandes (Google)" 

This is just a resend of the previous series at
https://lore.kernel.org/patchwork/patch/1014892/
with a small if block refactor as Andy suggested:
https://lore.kernel.org/patchwork/comment/1198679/

All,
Could you please provide your Reviewed-by / Acked-by tags?

I will also resend the manpage changes shortly.

Joel Fernandes (Google) (2):
mm/memfd: Add an F_SEAL_FUTURE_WRITE seal to memfd
selftests/memfd: Add tests for F_SEAL_FUTURE_WRITE seal

fs/hugetlbfs/inode.c   |  2 +-
include/uapi/linux/fcntl.h |  1 +
mm/memfd.c |  3 +-
mm/shmem.c | 25 +++-
tools/testing/selftests/memfd/memfd_test.c | 74 ++
5 files changed, 100 insertions(+), 5 deletions(-)

--
2.20.1.97.g81188d93c3-goog

[PATCH v4 2/2] selftests/memfd: Add tests for F_SEAL_FUTURE_WRITE seal

[Joel Fernandes]

From: "Joel Fernandes (Google)" 

Add tests to verify sealing memfds with the F_SEAL_FUTURE_WRITE works as
expected.

Cc: dan...@google.com
Cc: minc...@kernel.org
Cc: Jann Horn 
Cc: John Stultz 
Signed-off-by: Joel Fernandes (Google) 
---
 tools/testing/selftests/memfd/memfd_test.c | 74 ++
 1 file changed, 74 insertions(+)

diff --git a/tools/testing/selftests/memfd/memfd_test.c 
b/tools/testing/selftests/memfd/memfd_test.c
index 10baa1652fc2..c67d32eeb668 100644
--- a/tools/testing/selftests/memfd/memfd_test.c
+++ b/tools/testing/selftests/memfd/memfd_test.c
@@ -54,6 +54,22 @@ static int mfd_assert_new(const char *name, loff_t sz, 
unsigned int flags)
return fd;
 }
 
+static int mfd_assert_reopen_fd(int fd_in)
+{
+   int r, fd;
+   char path[100];
+
+   sprintf(path, "/proc/self/fd/%d", fd_in);
+
+   fd = open(path, O_RDWR);
+   if (fd < 0) {
+   printf("re-open of existing fd %d failed\n", fd_in);
+   abort();
+   }
+
+   return fd;
+}
+
 static void mfd_fail_new(const char *name, unsigned int flags)
 {
int r;
@@ -255,6 +271,25 @@ static void mfd_assert_read(int fd)
munmap(p, mfd_def_size);
 }
 
+/* Test that PROT_READ + MAP_SHARED mappings work. */
+static void mfd_assert_read_shared(int fd)
+{
+   void *p;
+
+   /* verify PROT_READ and MAP_SHARED *is* allowed */
+   p = mmap(NULL,
+mfd_def_size,
+PROT_READ,
+MAP_SHARED,
+fd,
+0);
+   if (p == MAP_FAILED) {
+   printf("mmap() failed: %m\n");
+   abort();
+   }
+   munmap(p, mfd_def_size);
+}
+
 static void mfd_assert_write(int fd)
 {
ssize_t l;
@@ -692,6 +727,44 @@ static void test_seal_write(void)
close(fd);
 }
 
+/*
+ * Test SEAL_FUTURE_WRITE
+ * Test whether SEAL_FUTURE_WRITE actually prevents modifications.
+ */
+static void test_seal_future_write(void)
+{
+   int fd, fd2;
+   void *p;
+
+   printf("%s SEAL-FUTURE-WRITE\n", memfd_str);
+
+   fd = mfd_assert_new("kern_memfd_seal_future_write",
+   mfd_def_size,
+   MFD_CLOEXEC | MFD_ALLOW_SEALING);
+
+   p = mfd_assert_mmap_shared(fd);
+
+   mfd_assert_has_seals(fd, 0);
+
+   mfd_assert_add_seals(fd, F_SEAL_FUTURE_WRITE);
+   mfd_assert_has_seals(fd, F_SEAL_FUTURE_WRITE);
+
+   /* read should pass, writes should fail */
+   mfd_assert_read(fd);
+   mfd_assert_read_shared(fd);
+   mfd_fail_write(fd);
+
+   fd2 = mfd_assert_reopen_fd(fd);
+   /* read should pass, writes should still fail */
+   mfd_assert_read(fd2);
+   mfd_assert_read_shared(fd2);
+   mfd_fail_write(fd2);
+
+   munmap(p, mfd_def_size);
+   close(fd2);
+   close(fd);
+}
+
 /*
  * Test SEAL_SHRINK
  * Test whether SEAL_SHRINK actually prevents shrinking
@@ -945,6 +1018,7 @@ int main(int argc, char **argv)
test_basic();
 
test_seal_write();
+   test_seal_future_write();
test_seal_shrink();
test_seal_grow();
test_seal_resize();
-- 
2.20.1.97.g81188d93c3-goog

Re: [PATCH 4/4] ARM: dts: rv1108: Add support for rv1108-elgin-r1 board

[Heiko Stuebner]

Am Freitag, 4. Januar 2019, 02:40:23 CET schrieb Otavio Salvador:
> rv1108-elgin-r1 board is based on Rockchip RV1108 SoC.
> 
> Signed-off-by: Otavio Salvador 

applied all 4 patches (including the vendor-prefix) for 5.1

I've rearranged some minor properties in the board-dts to follow
alphabetical ordering (emmc and gmac).


Thanks
Heiko

Re: UBSAN: Undefined behaviour in net/can/bcm.c

[Oliver Hartkopp]

Hi,

thanks for the report!

On 1/12/19 8:25 PM, Kyungtae Kim wrote:

We report a bug in linux-4.19.13: "UBSAN: Undefined behaviour in net/can/bcm.c"

kernel config: https://kt0755.github.io/etc/config_4.19.13
repro: https://kt0755.github.io/etc/repro.296b5.c

An integer overflow arose in bcm_timeval_to_ktime() when
tv.tv_usec * NSEC_PER_USEC is larger than its boundary of the
destination (i.e., long).
To fix, an appropriate boundary check should be placed right before the usage.


Just checked the commit that introduced the issue:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ba61a8d9d7809

In fact the tv.tv_usec needs to be checked to be smaller than 1000*1000 
before multiplying with 1000 (NSEC_PER_USEC).


The code in question

static inline ktime_t bcm_timeval_to_ktime(struct bcm_timeval tv)
{
   return ktime_set(tv.tv_sec, tv.tv_usec * NSEC_PER_USEC);
}

is a 1:1 copy of the standard function in ktime.h

/* convert a timeval to ktime_t format: */
static inline ktime_t timeval_to_ktime(struct timeval tv)
{
return ktime_set(tv.tv_sec, tv.tv_usec * NSEC_PER_USEC);
}

https://elixir.bootlin.com/linux/v4.20.1/source/include/linux/ktime.h#L81

And therefore I thought it was a good choice ;-)

So there could potentially be some other users of timeval_to_ktime() 
that might have the same issue.


Will provide a check in bcm.c in rx_setup and tx_setup as the timeval 
content can be provided from user space there.


@Arnd: Do you have a better idea?

Thanks & best regards,
Oliver


=
UBSAN: Undefined behaviour in net/can/bcm.c:140:41
signed integer overflow:
60870466536963773 * 1000 cannot be represented in type 'long int'
CPU: 0 PID: 7063 Comm: syz-executor3 Not tainted 4.19.13 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
  __dump_stack lib/dump_stack.c:77 [inline]
  dump_stack+0xd2/0x148 lib/dump_stack.c:113
  ubsan_epilogue+0x12/0x94 lib/ubsan.c:159
  handle_overflow+0x1cf/0x21a lib/ubsan.c:190
  __ubsan_handle_mul_overflow+0x2a/0x35 lib/ubsan.c:214
  bcm_timeval_to_ktime net/can/bcm.c:140 [inline]
  bcm_rx_setup net/can/bcm.c:1190 [inline]
  bcm_sendmsg+0x3807/0x3fd0 net/can/bcm.c:1355
  sock_sendmsg_nosec net/socket.c:621 [inline]
  sock_sendmsg+0xdd/0x130 net/socket.c:631
  sock_write_iter+0x24b/0x3d0 net/socket.c:900
  call_write_iter include/linux/fs.h:1811 [inline]
  new_sync_write fs/read_write.c:474 [inline]
  __vfs_write+0x538/0x6e0 fs/read_write.c:487
  vfs_write+0x1b3/0x520 fs/read_write.c:549
  ksys_write+0xde/0x1c0 fs/read_write.c:598
  __do_sys_write fs/read_write.c:610 [inline]
  __se_sys_write fs/read_write.c:607 [inline]
  __x64_sys_write+0x7e/0xc0 fs/read_write.c:607
  do_syscall_64+0xc4/0x510 arch/x86/entry/common.c:290
  entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4497b9
Code: e8 8c 9f 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
01 f0 ff ff 0f 83 9b 6b fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7fc2e6feac68 EFLAGS: 0246 ORIG_RAX: 0001
RAX: ffda RBX: 7fc2e6feb6cc RCX: 004497b9
RDX: 0048 RSI: 20c0 RDI: 0013
RBP: 0071bea0 R08:  R09: 
R10:  R11: 0246 R12: 
R13: ba60 R14: 006f4b00 R15: 7fc2e6feb700
=

Thanks,
Kyungtae Kim

Re: [PATCH 1/2] dt: bindings: lp5024: Introduce the lp5024 and lp5018 RGB driver

[Jacek Anaszewski]

Hi Dan,

On 1/12/19 6:09 PM, Dan Murphy wrote:

Jacek

On 1/11/19 3:52 PM, Jacek Anaszewski wrote:

Dan,

On 1/11/19 1:38 PM, Dan Murphy wrote:

Jacek

Sorry I missed some replies

On 1/10/19 4:03 PM, Jacek Anaszewski wrote:

On 1/10/19 9:43 PM, Dan Murphy wrote:

Jacek

On 1/10/19 1:57 PM, Jacek Anaszewski wrote:

Dan,

On 1/10/19 8:22 PM, Dan Murphy wrote:

Jacek

On 1/10/19 12:44 PM, Jacek Anaszewski wrote:

Hi Dan,

On 1/9/19 10:31 PM, Dan Murphy wrote:

Jacek

On 1/9/19 3:28 PM, Jacek Anaszewski wrote:

On 1/9/19 10:12 PM, Dan Murphy wrote:

On 1/9/19 2:12 PM, Jacek Anaszewski wrote:

Hi Dan,

On 1/8/19 10:22 PM, Dan Murphy wrote:

On 1/8/19 3:16 PM, Jacek Anaszewski wrote:

On 1/8/19 9:53 PM, Dan Murphy wrote:

Jacek

On 1/8/19 2:33 PM, Jacek Anaszewski wrote:

Dan,

On 12/19/18 5:26 PM, Dan Murphy wrote:

Introduce the bindings for the Texas Instruments LP5024 and the LP5018
RGB LED device driver.  The LP5024/18 can control RGB LEDs individually
or as part of a control bank group.  These devices have the ability
to adjust the mixing control for the RGB LEDs to obtain different colors
independent of the overall brightness of the LED grouping.

Datasheet:
http://www.ti.com/lit/ds/symlink/lp5024.pdf

Signed-off-by: Dan Murphy 
---
  .../devicetree/bindings/leds/leds-lp5024.txt  | 63 +++
  1 file changed, 63 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/leds/leds-lp5024.txt

diff --git a/Documentation/devicetree/bindings/leds/leds-lp5024.txt 
b/Documentation/devicetree/bindings/leds/leds-lp5024.txt
new file mode 100644
index ..9567aa6f7813
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lp5024.txt
@@ -0,0 +1,63 @@
+* Texas Instruments - LP5024/18 RGB LED driver
+
+The LM3692x is an ultra-compact, highly efficient,
+white-LED driver designed for LCD display backlighting.
+
+The main difference between the LP5024 and L5018 is the number of
+RGB LEDs they support.  The LP5024 supports twenty four strings while the
+LP5018 supports eighteen strings.
+
+Required properties:
+    - compatible:
+    "ti,lp5018"
+    "ti,lp5024"
+    - reg :  I2C slave address
+    - #address-cells : 1
+    - #size-cells : 0
+
+Optional properties:
+    - enable-gpios : gpio pin to enable/disable the device.
+    - vled-supply : LED supply
+
+Required child properties:
+    - reg : Is the child node iteration.
+    - led-sources : LP5024 - 0 - 7
+    LP5018 - 0 - 5
+    Declares the LED string or strings that the child node
+    will control.  If ti,control-bank is set then this
+    property will contain multiple LED IDs.
+
+Optional child properties:
+    - label : see Documentation/devicetree/bindings/leds/common.txt
+    - linux,default-trigger :
+   see Documentation/devicetree/bindings/leds/common.txt
+    - ti,control-bank : Indicates that the LED strings declared in the
+    led-sources property are grouped within a control
+    bank for brightness and mixing control.
+
+Example:
+
+led-controller@28 {
+    compatible = "ti,lp5024";
+    reg = <0x28>;
+    #address-cells = <1>;
+    #size-cells = <0>;
+
+    enable-gpios = < 28 GPIO_ACTIVE_HIGH>;
+    vled-supply = <>;
+
+    led@0 {
+    reg = <0>;
+    led-sources = <1>;
+    };
+
+    led@1 {
+    reg = <1>;
+    led-sources = <0 6>;
+    ti,control-bank;


Do you really need ti,control-bank? Doesn't led-sources array size
greater than 1 mean that the node describes control bank?



That will work too.



Also, does it make sense to have only two LEDs in the bank?


The array can populate all 7 LEDs in a single node.  I only show 2 here as the 
example.
See the description above of the led-sources


OK, I confused RGB LED modules with banks.

Shouldn't we allow for defining either strings or RGB LED
triplets somehow then?



Well that is what this should be doing.  If you define a single LED in LED 
sources then
the triplet is controlled via the associated LEDx_brightness register.


led-sources should map to iouts directly.
So, for RGB LED modules I would expect:

LED0: led-sources = <0 1 2>;
LED1: led-sources = <3 4 5>;
LED2: led-sources = <6 7 8>;
and so on.




for banks:

Bank A with iouts 0,3,6,9: led-sources<0 3 6 9>;
Bank B with iouts 2,4,10:  led-sources<2 4 10>;
Bank C with iouts 5,8,11,14,17: led-sources<5 8 11 14 17>;



Ok the led-sources would need to be different then this as I don't define the 
sources for banks.

The led-sources for the banks and the individual groups will have different 
meanings within the same
document.  I was attempting to keep the led-sources mapped to the 
LEDx_brightness registers as opposed to
the hardware outputs since the RGB LEDs are controlled and grouped by a single 
brightness register and if banked then
it would be controlled by the bank brightness register.

Describing these in the DT seems wrought with potential issues as the data 
sheet 

Re: [PATCH v5 07/17] drm/sun4i: sun6i_mipi_dsi: Refactor vertical video start delay

[Jagan Teki]

On Sat, Jan 12, 2019 at 10:13 PM Maxime Ripard
 wrote:
>
> On Wed, Jan 09, 2019 at 06:57:57PM +0530, Jagan Teki wrote:
> > On Tue, Jan 8, 2019 at 2:28 PM Maxime Ripard  
> > wrote:
> > >
> > > On Mon, Jan 07, 2019 at 08:48:21PM +0530, Jagan Teki wrote:
> > > > On Mon, Jan 7, 2019 at 7:42 PM Maxime Ripard 
> > > >  wrote:
> > > > >
> > > > > On Fri, Dec 21, 2018 at 02:26:11AM +0530, Jagan Teki wrote:
> > > > > > On Tue, Dec 11, 2018 at 10:19 PM Maxime Ripard
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Mon, Dec 10, 2018 at 09:47:19PM +0530, Jagan Teki wrote:
> > > > > > > > Video start delay can be computed by subtracting total vertical
> > > > > > > > timing with front porch timing and with adding 1 delay line for 
> > > > > > > > TCON.
> > > > > > > >
> > > > > > > > BSP code form BPI-M64-bsp is computing video start delay as
> > > > > > > > (from linux-sunxi/
> > > > > > > > drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
> > > > > > > >
> > > > > > > > u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp;
> > > > > > > > => (panel->lcd_vt) - panel->lcd_y - (panel->lcd_vbp)
> > > > > > > > => (timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y)
> > > > > > > >- panel->lcd_y - (panel->lcd_vbp)
> > > > > > > > => timmings->ver_front_porch + panel->lcd_vbp + panel->lcd_y
> > > > > > > >- panel->lcd_y - panel->lcd_vbp
> > > > > > > > => timmings->ver_front_porch
> > > > > > > >
> > > > > > > > So, update the start delay computation accordingly.
> > > > > > > >
> > > > > > > > Signed-off-by: Jagan Teki 
> > > > > > >
> > > > > > > Even though it's a bit better now on my A33 board and I don't 
> > > > > > > have the
> > > > > > > white stripes on the bottom of the display, there's still some
> > > > > > > flickering with your patches applied.
> > > > > > >
> > > > > > > Bisecting it seems to point at that patch, but reverting it 
> > > > > > > doesn't
> > > > > > > make the issue go away, so it's not really clear which one 
> > > > > > > exactly is
> > > > > > > at fault.
> > > > > >
> > > > > > Is reverting this patch, work fine or not?
> > > > >
> > > > > As I was saying, it doesn't.
> > > > >
> > > > > > This patch is trying to make use of front porch instead of existing
> > > > > > back porch to compute the delay. Since we revert the VBP fix 
> > > > > > patch[1]
> > > > > > to assume VBP as VFP value look like your setup would also require 
> > > > > > to
> > > > > > revert this change. But as per BSP or drm_mode details all of my
> > > > > > displays even work with and w/o reverting these two.
> > > > >
> > > > > Again, I cannot help you without the datasheet for the panels you're
> > > > > trying to submit.
> > > >
> > > > The panel bound with Sitronix ST7701 IC
> > > > http://www.startek-lcd.com/res/starteklcd/pdres/201705/20170512144242904.pdf
> > >
> > > It's the controller, not the panel
> >
> > As I said before, the datasheet of that panel doesn't have any
> > information except electrical characteristics and used IC which is
> > ST7701.
> >
> > I have one more panel, which is from Bananapi, S070WV20-CT16 ICN621
> > please find the attachment for the same.
> >
> > Here is some more details of the same.
> >
> > https://github.com/yesnoandor/x300/blob/master/kernel/arch/arm/boot/dts/erobbing/x300/x300.dtsi#L81
> > https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/main.c#L15
> >
> > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/drivers/video/msm/mdss/mdss_i2c_interface.c#L152
> > matches timings for
> > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/arm/boot/dts/qcom/dsi-mipi-2-rgb_1280p_video.dtsi#L20
> >
> > https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#L169
>
> Where did you get the timings from then?

You mean drm_mode timings, the same panel with RGB available in
panel-simple[1], and dsi driver in Mailing list[2] and actual DSI
sequence commands from BSP[3]

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/panel/panel-simple.c?id=7ad8b41cd8f5c2842646d01cdd576663caee04a7
[2] https://patchwork.kernel.org/patch/10680331/
[3] 
https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/lcd/S070WV20_MIPI_RGB.c

Re: [GIT PULL] remove dma_zalloc_coherent

[pr-tracker-bot]

The pull request you sent on Sat, 12 Jan 2019 19:13:55 +0100:

> git://git.infradead.org/users/hch/dma-mapping.git 
> tags/remove-dma_zalloc_coherent-5.0

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/66c56cfa64d9dbb9efa8a06c1aece77e8d57ea19

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

[PATCH v4 2/8] drm: move EXPORT_SYMBOL_FOR_TESTS_ONLY to drm_util.h

[Sam Ravnborg]

In the quest to get rid of drmP.h move the newly
added EXPORT_SYMBOL_FOR_TESTS_ONLY to drm_util.h.
Fix the single user.

Add a note to drmP.h to avoid further use of it.

Signed-off-by: Sam Ravnborg 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_framebuffer.c |  1 +
 include/drm/drmP.h| 11 ++-
 include/drm/drm_util.h| 10 ++
 3 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index fcaea8f50513..7abcb265a108 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "drm_internal.h"
 #include "drm_crtc_internal.h"
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index bc4cb3732407..3f5c577c9dbd 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -94,10 +94,11 @@ struct dma_buf_attachment;
 struct pci_dev;
 struct pci_controller;
 
-#if defined(CONFIG_DRM_DEBUG_SELFTEST_MODULE)
-#define EXPORT_SYMBOL_FOR_TESTS_ONLY(x) EXPORT_SYMBOL(x)
-#else
-#define EXPORT_SYMBOL_FOR_TESTS_ONLY(x)
-#endif
+/*
+ * NOTE: drmP.h is obsolete - do NOT add anything to this file
+ *
+ * Do not include drmP.h in new files.
+ * Work is ongoing to remove drmP.h includes from existing files
+ */
 
 #endif
diff --git a/include/drm/drm_util.h b/include/drm/drm_util.h
index f776a55e5508..0500da65b1d1 100644
--- a/include/drm/drm_util.h
+++ b/include/drm/drm_util.h
@@ -37,6 +37,16 @@
 #include 
 #include 
 
+/*
+ * Use EXPORT_SYMBOL_FOR_TESTS_ONLY() for functions that shall
+ * only be visible for drmselftests.
+ */
+#if defined(CONFIG_DRM_DEBUG_SELFTEST_MODULE)
+#define EXPORT_SYMBOL_FOR_TESTS_ONLY(x) EXPORT_SYMBOL(x)
+#else
+#define EXPORT_SYMBOL_FOR_TESTS_ONLY(x)
+#endif
+
 /**
  * for_each_if - helper for handling conditionals in various for_each macros
  * @condition: The condition to check
-- 
2.12.0

[PATCH v4 3/8] drm/stm: prepare for drmP.h removal from drm_modeset_helper.h

[Sam Ravnborg]

The use of drmP.h is discouraged and removal of it from
drm_modeset_helper.h caused drm/stm to fail to build.

This patch introduce the necessary fixes to prepare for the
drmP.h removal from drm_modeset_helper.h.

Build tested on arm and x86 allmodconfig

Signed-off-by: Sam Ravnborg 
Cc: Yannick Fertre 
Cc: Philippe Cornu 
Cc: Benjamin Gaignard 
Cc: Vincent Abriou 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/stm/drv.c  | 4 
 drivers/gpu/drm/stm/ltdc.c | 7 +++
 2 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
index 8dec001b9d37..58bf8bae789c 100644
--- a/drivers/gpu/drm/stm/drv.c
+++ b/drivers/gpu/drm/stm/drv.c
@@ -9,15 +9,19 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include "ltdc.h"
 
diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 61dd661aa0ac..de29f4713140 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -10,18 +10,25 @@
 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
-- 
2.12.0

[PATCH v4 6/8] drm/bridge: cdns: prepare for drmP.h removal from drm_modeset_helper.h

[Sam Ravnborg]

The use of drmP.h is discouraged and removal of it from
drm_modeset_helper.h caused cdns to fail to build.

This patch introduce the necessary fixes to prepare for the
drmP.h removal from drm_modeset_helper.h.

Build tested on arm x86 and arm allmodconfig.

Signed-off-by: Sam Ravnborg 
Cc: Andrzej Hajda 
Cc: Laurent Pinchart 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/bridge/cdns-dsi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c 
b/drivers/gpu/drm/bridge/cdns-dsi.c
index ce9496d13986..4b73d0969468 100644
--- a/drivers/gpu/drm/bridge/cdns-dsi.c
+++ b/drivers/gpu/drm/bridge/cdns-dsi.c
@@ -8,11 +8,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.12.0

[PATCH v4 7/8] drmi/rcar-du: prepare for drmP.h removal from drm_modeset_helper.h

[Sam Ravnborg]

The use of drmP.h is discouraged and removal of it from
drm_modeset_helper.h caused rcar-du to fail to build.

This patch introduce the necessary fixes to prepare for the
drmP.h removal from drm_modeset_helper.h.

Build tested on arm x86 and arm allmodconfig.

Signed-off-by: Sam Ravnborg 
Cc: Laurent Pinchart 
Cc: Kieran Bingham 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/rcar-du/rcar_lvds.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c 
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 534a128a869d..8010ed702509 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.12.0

[PATCH v4 0/8] drm: minimize drmP.h dependencies

[Sam Ravnborg]

Updated patchset, with merged patches removed.
And one patch split in merge frindly bits.

As noted in the commit message for kirin a hack
to kirin/Kconfig was required to build it on my box.
It would be good if we could have this driver covered
by COMPILE_TEST.
There are likely others that could benefit from the same, but
this driver got my attention as Daniel reported build errors
that my setup did not trigger.
Build failed with my arm (32bit) toolchain, I did not investigate
this further.

>From the original mail:

- drmP.h is now stripped down to include files and forward declarations.
- All header files in include/drm/ no longer include drmP.h.

The series was made on top of drm-misc-next
Build tested using arm and x86 allmodconfig

The patches are trivial but touches a lot of files,
so a lot of people on cc: for the individual patches.

I expect the full series to be applied to drm-misc-next

Sam

v4:
- Rebased on top of drm-misc-next and dropped patches already merged
- Include build test of kirin (Daniel)
- Plug drm_util.h into drm-internals.rst (Daniel)
- Fix kernel-doc syntax in drm_util.h (Daniel)
- Split removal of drmP.h from drm_modeset_helper.h
  in smaller patches, to ease the merge process

v3:
- Added Acks/Reviewed annotations (thanks!)
- Add forward of drm_gem_object to drm_framebuffer.h (Noralf)
- Drop "drm: move DRM_IF_VERSION to drm_internal.h" as it is applied to drm-misc
- Drop "drm: make drm_file.h self contained" as Jan made a similar patch that 
was appleid to drm-misc
- Rebased on top of drm-misc-next

v2:
- DRM_SWITCH_POWER as enum (Daniel Vetter)
- Prefer forward decalration over includes (Laurent Pinchart)
- Updated drm_device to use kerneldoc style (Daniel Vetter)
- Improved commit messages (David Lechner)
- Split up patch when removing drmP.h from drm_gem_cma_helper.h
- rebased on top of drm-misc-next
- dropped patch already applied
- added reviewed-by from Laurent Pinchart (Laurent Pinchart)
- add drm_framebuffer.h patch
- add kernel-doc comments to drm_util.h
- moved EXPORT_SYMBOL_FOR_TESTS_ONLY to drm_util.h
- added note to drmP.h not to add new stuff and not to use in new files



Sam Ravnborg (8):
  drm: move drm_can_sleep() to drm_util.h
  drm: move EXPORT_SYMBOL_FOR_TESTS_ONLY to drm_util.h
  drm/stm: prepare for drmP.h removal from drm_modeset_helper.h
  drm/hisilicon/kirin: prepare for drmP.h removal from drm_modeset_helper.h
  drm/arcpgu: prepare for drmP.h removal from drm_modeset_helper.h
  drm/bridge: cdns: prepare for drmP.h removal from drm_modeset_helper.h
  drmi/rcar-du: prepare for drmP.h removal from drm_modeset_helper.h
  drm: remove drmP.h from drm_modeset_helper.h

 Documentation/gpu/drm-internals.rst |  9 +
 drivers/gpu/drm/amd/amdgpu/atom.c   |  2 +
 drivers/gpu/drm/arc/arcpgu_sim.c|  3 +-
 drivers/gpu/drm/ast/ast_fb.c|  2 +
 drivers/gpu/drm/bridge/cdns-dsi.c   |  2 +
 drivers/gpu/drm/cirrus/cirrus_fbdev.c   |  1 +
 drivers/gpu/drm/drm_damage_helper.c |  1 +
 drivers/gpu/drm/drm_flip_work.c |  1 +
 drivers/gpu/drm/drm_framebuffer.c   |  1 +
 drivers/gpu/drm/drm_modeset_helper.c|  2 +
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c| 11 +++--
 drivers/gpu/drm/mgag200/mgag200_fb.c|  1 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c|  1 +
 drivers/gpu/drm/omapdrm/omap_fbdev.c|  1 +
 drivers/gpu/drm/qxl/qxl_cmd.c   |  2 +
 drivers/gpu/drm/radeon/atom.c   |  2 +
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |  1 +
 drivers/gpu/drm/rcar-du/rcar_lvds.c |  1 +
 drivers/gpu/drm/stm/drv.c   |  4 ++
 drivers/gpu/drm/stm/ltdc.c  |  7 
 drivers/gpu/drm/vc4/vc4_drv.h   |  1 +
 include/drm/drmP.h  | 19 +++--
 include/drm/drm_modeset_helper.h|  6 ++-
 include/drm/drm_util.h  | 53 -
 24 files changed, 115 insertions(+), 19 deletions(-)

[PATCH v4 1/8] drm: move drm_can_sleep() to drm_util.h

[Sam Ravnborg]

Move drm_can_sleep() out of drmP.h to allow users
to get rid of the drmP.h include.

There was no header file that was a good match for this helper function.
So add this to drm_util with the relevant includes.

Add include of drm_util.h to all users.

v2:
- Update comments to use kernel-doc style (Daniel)
- Add FIXME to drm_can_sleep and add note that this
  function should not be used in new code (Daniel)

v3:
- Fix kernel-doc syntax (Daniel)
- Plug drm_util.h into drm-internels.rst (Daniel)

Signed-off-by: Sam Ravnborg 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: "David (ChunMing) Zhou" 
Cc: Gerd Hoffmann 
Cc: Rob Clark 
Cc: Tomi Valkeinen 
Cc: Eric Anholt 
---
 Documentation/gpu/drm-internals.rst |  9 ++
 drivers/gpu/drm/amd/amdgpu/atom.c   |  2 ++
 drivers/gpu/drm/ast/ast_fb.c|  2 ++
 drivers/gpu/drm/cirrus/cirrus_fbdev.c   |  1 +
 drivers/gpu/drm/drm_flip_work.c |  1 +
 drivers/gpu/drm/mgag200/mgag200_fb.c|  1 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c|  1 +
 drivers/gpu/drm/omapdrm/omap_fbdev.c|  1 +
 drivers/gpu/drm/qxl/qxl_cmd.c   |  2 ++
 drivers/gpu/drm/radeon/atom.c   |  2 ++
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |  1 +
 drivers/gpu/drm/vc4/vc4_drv.h   |  1 +
 include/drm/drmP.h  |  8 -
 include/drm/drm_util.h  | 43 -
 14 files changed, 66 insertions(+), 9 deletions(-)

diff --git a/Documentation/gpu/drm-internals.rst 
b/Documentation/gpu/drm-internals.rst
index 9090fabf3f7a..2caf21effd28 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -233,6 +233,15 @@ Printer
 .. kernel-doc:: drivers/gpu/drm/drm_print.c
:export:
 
+Utilities
+-
+
+.. kernel-doc:: include/drm/drm_util.h
+   :doc: drm utils
+
+.. kernel-doc:: include/drm/drm_util.h
+   :internal:
+
 
 Legacy Support Code
 ===
diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c 
b/drivers/gpu/drm/amd/amdgpu/atom.c
index e9934de1b9cf..dd30f4e61a8c 100644
--- a/drivers/gpu/drm/amd/amdgpu/atom.c
+++ b/drivers/gpu/drm/amd/amdgpu/atom.c
@@ -27,6 +27,8 @@
 #include 
 #include 
 
+#include 
+
 #define ATOM_DEBUG
 
 #include "atom.h"
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index 75f867d00031..2c9f8dd9733a 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -39,7 +39,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+
 #include "ast_drv.h"
 
 static void ast_dirty_update(struct ast_fbdev *afbdev,
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 4dd499c7d1ba..79fea1b8bc14 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -10,6 +10,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/drm_flip_work.c b/drivers/gpu/drm/drm_flip_work.c
index 12dea16f22a8..3da3bf5af405 100644
--- a/drivers/gpu/drm/drm_flip_work.c
+++ b/drivers/gpu/drm/drm_flip_work.c
@@ -22,6 +22,7 @@
  */
 
 #include 
+#include 
 #include 
 
 /**
diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c 
b/drivers/gpu/drm/mgag200/mgag200_fb.c
index 30726c9fe28c..6893934b26c0 100644
--- a/drivers/gpu/drm/mgag200/mgag200_fb.c
+++ b/drivers/gpu/drm/mgag200/mgag200_fb.c
@@ -12,6 +12,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
index 7cebcb2b3a37..6153514db04c 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
@@ -16,6 +16,7 @@
  * this program.  If not, see .
  */
 
+#include 
 
 #include "mdp5_kms.h"
 #include "mdp5_smp.h"
diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index aee99194499f..851c59f07eb1 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -16,6 +16,7 @@
  */
 
 #include 
+#include 
 #include 
 
 #include "omap_drv.h"
diff --git a/drivers/gpu/drm/qxl/qxl_cmd.c b/drivers/gpu/drm/qxl/qxl_cmd.c
index dffc5093ff16..2e100f644236 100644
--- a/drivers/gpu/drm/qxl/qxl_cmd.c
+++ b/drivers/gpu/drm/qxl/qxl_cmd.c
@@ -25,6 +25,8 @@
 
 /* QXL cmd/ring handling */
 
+#include 
+
 #include "qxl_drv.h"
 #include "qxl_object.h"
 
diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
index e55cbeee7a53..ac98ad561870 100644
--- a/drivers/gpu/drm/radeon/atom.c
+++ b/drivers/gpu/drm/radeon/atom.c
@@ -27,6 +27,8 @@
 #include 
 #include 
 
+#include 
+
 #define ATOM_DEBUG
 
 #include "atom.h"
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c 
b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c

[PATCH v4 8/8] drm: remove drmP.h from drm_modeset_helper.h

[Sam Ravnborg]

With the removal of drmP.h from drm_modeset_helper.h
the drmP.h are no longer included by any include files
in include/drm.
The drmP.h file is thus only included explicit
either in .c files or in local .h files.
This makes the process of deleting the drmP.h includes easier
as we have a more local dependency chain.

Include build failures fixes in drm files after the drmP.h removal.

Signed-off-by: Sam Ravnborg 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_damage_helper.c  | 1 +
 drivers/gpu/drm/drm_modeset_helper.c | 2 ++
 include/drm/drm_modeset_helper.h | 6 +-
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_damage_helper.c 
b/drivers/gpu/drm/drm_damage_helper.c
index 31032407254d..b575a768f51c 100644
--- a/drivers/gpu/drm/drm_damage_helper.c
+++ b/drivers/gpu/drm/drm_damage_helper.c
@@ -32,6 +32,7 @@
 
 #include 
 #include 
+#include 
 
 /**
  * DOC: overview
diff --git a/drivers/gpu/drm/drm_modeset_helper.c 
b/drivers/gpu/drm/drm_modeset_helper.c
index 9150fa385bba..9bc1ef788c77 100644
--- a/drivers/gpu/drm/drm_modeset_helper.c
+++ b/drivers/gpu/drm/drm_modeset_helper.c
@@ -23,8 +23,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 
 /**
  * DOC: aux kms helpers
diff --git a/include/drm/drm_modeset_helper.h b/include/drm/drm_modeset_helper.h
index efa337f03129..995fd981cab0 100644
--- a/include/drm/drm_modeset_helper.h
+++ b/include/drm/drm_modeset_helper.h
@@ -23,7 +23,11 @@
 #ifndef __DRM_KMS_HELPER_H__
 #define __DRM_KMS_HELPER_H__
 
-#include 
+struct drm_crtc;
+struct drm_crtc_funcs;
+struct drm_device;
+struct drm_framebuffer;
+struct drm_mode_fb_cmd2;
 
 void drm_helper_move_panel_connectors_to_head(struct drm_device *);
 
-- 
2.12.0

[PATCH v4 4/8] drm/hisilicon/kirin: prepare for drmP.h removal from drm_modeset_helper.h

[Sam Ravnborg]

The use of drmP.h is discouraged and removal of it from
drm_modeset_helper.h caused kirin to fail to build.

This patch introduce the necessary fixes to prepare for the
drmP.h removal from drm_modeset_helper.h.
List of include files sorted alphabetically.

Build tested on arm x86 allmodconfig using the following hack
to the Kconfig file:

| -   depends on DRM && OF && ARM64
| +   depends on DRM && OF && (ARM64 || (X86_64 && COMPILE_TEST))

Build failed on 32bit ARM - so the X86_64 hack was required.
The COMPILE_TEST hack is not submitted as the preferred fix
is something where we have coverage on 32bit ARM too.

Signed-off-by: Sam Ravnborg 
Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c 
b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
index b4c7af3ab6ae..7ffebdd843a2 100644
--- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -16,13 +16,18 @@
  */
 
 #include 
+#include 
 #include 
+#include 
+#include 
 
-#include 
+#include 
 #include 
-#include 
+#include 
 #include 
-#include 
+#include 
+#include 
+#include 
 
 #include "dw_dsi_reg.h"
 
-- 
2.12.0

[PATCH v4 5/8] drm/arcpgu: prepare for drmP.h removal from drm_modeset_helper.h

[Sam Ravnborg]

The use of drmP.h is discouraged and removal of it from
drm_modeset_helper.h caused arcgpu to fail to build.

This patch introduce the necessary fixes to prepare for the
drmP.h removal from drm_modeset_helper.h.
List of include files sorted alphabetically.

Build tested on arm x86 and arm allmodconfig.

Signed-off-by: Sam Ravnborg 
Cc: Alexey Brodkin 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/arc/arcpgu_sim.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c b/drivers/gpu/drm/arc/arcpgu_sim.c
index 6530d88f7293..b1119bc62630 100644
--- a/drivers/gpu/drm/arc/arcpgu_sim.c
+++ b/drivers/gpu/drm/arc/arcpgu_sim.c
@@ -14,8 +14,9 @@
  *
  */
 
-#include 
 #include 
+#include 
+#include 
 
 #include "arcpgu.h"
 
-- 
2.12.0

Re: [PATCH] vfs: fix preadv64v2 and pwritev64v2 compat syscalls with offset == -1

[Aurelien Jarno]

On 2018-12-06 20:05, Aurelien Jarno wrote:
> The preadv2 and pwritev2 syscalls are supposed to emulate the readv and
> writev syscalls when offset == -1. Therefore the compat code should
> check for offset before calling do_compat_preadv64 and
> do_compat_pwritev64. This is the case for the preadv2 and pwritev2
> syscalls, but handling of offset == -1 is missing in their 64-bit
> equivalent.
> 
> This patch fixes that, calling do_compat_readv and do_compat_writev when
> offset == -1. This fixes the following glibc tests on x32:
>  - misc/tst-preadvwritev2
>  - misc/tst-preadvwritev64v2
> 
> Cc: Alexander Viro 
> Cc: H.J. Lu 
> Signed-off-by: Aurelien Jarno 
> ---
>  fs/read_write.c | 6 ++
>  1 file changed, 6 insertions(+)

Any news about this patch?

Thanks,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

UBSAN: Undefined behaviour in net/can/bcm.c

[Kyungtae Kim]

We report a bug in linux-4.19.13: "UBSAN: Undefined behaviour in net/can/bcm.c"

kernel config: https://kt0755.github.io/etc/config_4.19.13
repro: https://kt0755.github.io/etc/repro.296b5.c

An integer overflow arose in bcm_timeval_to_ktime() when
tv.tv_usec * NSEC_PER_USEC is larger than its boundary of the
destination (i.e., long).
To fix, an appropriate boundary check should be placed right before the usage.

=
UBSAN: Undefined behaviour in net/can/bcm.c:140:41
signed integer overflow:
60870466536963773 * 1000 cannot be represented in type 'long int'
CPU: 0 PID: 7063 Comm: syz-executor3 Not tainted 4.19.13 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0xd2/0x148 lib/dump_stack.c:113
 ubsan_epilogue+0x12/0x94 lib/ubsan.c:159
 handle_overflow+0x1cf/0x21a lib/ubsan.c:190
 __ubsan_handle_mul_overflow+0x2a/0x35 lib/ubsan.c:214
 bcm_timeval_to_ktime net/can/bcm.c:140 [inline]
 bcm_rx_setup net/can/bcm.c:1190 [inline]
 bcm_sendmsg+0x3807/0x3fd0 net/can/bcm.c:1355
 sock_sendmsg_nosec net/socket.c:621 [inline]
 sock_sendmsg+0xdd/0x130 net/socket.c:631
 sock_write_iter+0x24b/0x3d0 net/socket.c:900
 call_write_iter include/linux/fs.h:1811 [inline]
 new_sync_write fs/read_write.c:474 [inline]
 __vfs_write+0x538/0x6e0 fs/read_write.c:487
 vfs_write+0x1b3/0x520 fs/read_write.c:549
 ksys_write+0xde/0x1c0 fs/read_write.c:598
 __do_sys_write fs/read_write.c:610 [inline]
 __se_sys_write fs/read_write.c:607 [inline]
 __x64_sys_write+0x7e/0xc0 fs/read_write.c:607
 do_syscall_64+0xc4/0x510 arch/x86/entry/common.c:290
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4497b9
Code: e8 8c 9f 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
01 f0 ff ff 0f 83 9b 6b fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7fc2e6feac68 EFLAGS: 0246 ORIG_RAX: 0001
RAX: ffda RBX: 7fc2e6feb6cc RCX: 004497b9
RDX: 0048 RSI: 20c0 RDI: 0013
RBP: 0071bea0 R08:  R09: 
R10:  R11: 0246 R12: 
R13: ba60 R14: 006f4b00 R15: 7fc2e6feb700
=

Thanks,
Kyungtae Kim

Re: [PATCH v2 5/7] ARM: dts: rockchip: add rk3066 vop display nodes

[Heiko Stuebner]

Am Samstag, 29. Dezember 2018, 14:33:16 CET schrieb Johan Jonker:
> From: Mark Yao 
> 
> This patch adds the core display subsystem and vop nodes to rk3066.
> 
> Signed-off-by: Mark Yao 
> Signed-off-by: Johan Jonker 

applied for 5.1

Thanks
Heiko

Re: [PATCH V7 2/2] iio: accell: mma8452: add vdd/vddio regulator operation support

[Jonathan Cameron]

On Tue, 8 Jan 2019 14:48:48 +
Anson Huang  wrote:

> Hi, Martin
> 
> From Anson's iPhone 6
> 
> 
> > 在 2019年1月8日，19:41，Martin Kepplinger  写道：
> >   
> >> On 08.01.19 10:14, Anson Huang wrote:
> >> The accelerometer's power supply could be controllable on some
> >> platforms, such as i.MX6Q-SABRESD board, the mma8451's power supplies
> >> are controlled by a GPIO fixed regulator, need to make sure the
> >> regulators are enabled before any communication with mma8451, this
> >> patch adds vdd/vddio regulator operation support.
> >> 
> >> Signed-off-by: Anson Huang 
> >> Acked-by: Martin Kepplinger 
> >> ---
> >> ChangeLog Since V6:
> >>  - separate the error handling of regulators get to make code easy to read.
> >> ---
> >> drivers/iio/accel/mma8452.c | 105 
> >> ++--
> >> 1 file changed, 83 insertions(+), 22 deletions(-)
> >> 
> >> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> >> index 421a0a8..3027811 100644
> >> --- a/drivers/iio/accel/mma8452.c
> >> +++ b/drivers/iio/accel/mma8452.c
> >> @@ -31,6 +31,7 @@
> >> #include 
> >> #include 
> >> #include 
> >> +#include 
> >> 
> >> #define MMA8452_STATUS0x00
> >> #define  MMA8452_STATUS_DRDY(BIT(2) | BIT(1) | BIT(0))
> >> @@ -107,6 +108,8 @@ struct mma8452_data {
> >>u8 data_cfg;
> >>const struct mma_chip_info *chip_info;
> >>int sleep_val;
> >> +struct regulator *vdd_reg;
> >> +struct regulator *vddio_reg;
> >> };
> >> 
> >>  /**
> >> @@ -1534,9 +1537,39 @@ static int mma8452_probe(struct i2c_client *client,
> >>mutex_init(>lock);
> >>data->chip_info = match->data;
> >> 
> >> +data->vdd_reg = devm_regulator_get(>dev, "vdd");
> >> +if (IS_ERR(data->vdd_reg)) {
> >> +if (PTR_ERR(data->vdd_reg) == -EPROBE_DEFER)
> >> +return -EPROBE_DEFER;
> >> +
> >> +dev_err(>dev, "failed to get VDD regulator!\n");
> >> +return PTR_ERR(data->vdd_reg);
> >> +}
> >> +
> >> +data->vddio_reg = devm_regulator_get(>dev, "vddio");
> >> +if (IS_ERR(data->vddio_reg)) {
> >> +if (PTR_ERR(data->vddio_reg) == -EPROBE_DEFER)
> >> +return -EPROBE_DEFER;
> >> +
> >> +dev_err(>dev, "failed to get VDDIO regulator!\n");
> >> +return PTR_ERR(data->vddio_reg);
> >> +}
> >> +
> >> +ret = regulator_enable(data->vdd_reg);
> >> +if (ret) {
> >> +dev_err(>dev, "failed to enable VDD regulator!\n");
> >> +return ret;
> >> +}
> >> +
> >> +ret = regulator_enable(data->vddio_reg);
> >> +if (ret) {
> >> +dev_err(>dev, "failed to enable VDDIO regulator!\n");
> >> +goto disable_regulator_vdd;
> >> +}
> >> +
> >>ret = i2c_smbus_read_byte_data(client, MMA8452_WHO_AM_I);
> >>if (ret < 0)
> >> -return ret;
> >> +goto disable_regulators;
> >> 
> >>switch (ret) {
> >>case MMA8451_DEVICE_ID:
> >> @@ -1549,7 +1582,8 @@ static int mma8452_probe(struct i2c_client *client,
> >>break;
> >>/* else: fall through */
> >>default:
> >> -return -ENODEV;
> >> +ret = -ENODEV;
> >> +goto disable_regulators;
> >>}
> >> 
> >>dev_info(>dev, "registering %s accelerometer; ID 0x%x\n",
> >> @@ -1566,13 +1600,13 @@ static int mma8452_probe(struct i2c_client *client,
> >> 
> >>ret = mma8452_reset(client);
> >>if (ret < 0)
> >> -return ret;
> >> +goto disable_regulators;
> >> 
> >>data->data_cfg = MMA8452_DATA_CFG_FS_2G;
> >>ret = i2c_smbus_write_byte_data(client, MMA8452_DATA_CFG,
> >>data->data_cfg);
> >>if (ret < 0)
> >> -return ret;
> >> +goto disable_regulators;
> >> 
> >>/*
> >> * By default set transient threshold to max to avoid events if
> >> @@ -1581,7 +1615,7 @@ static int mma8452_probe(struct i2c_client *client,
> >>ret = i2c_smbus_write_byte_data(client, MMA8452_TRANSIENT_THS,
> >>MMA8452_TRANSIENT_THS_MASK);
> >>if (ret < 0)
> >> -return ret;
> >> +goto disable_regulators;
> >> 
> >>if (client->irq) {
> >>int irq2;
> >> @@ -1595,7 +1629,7 @@ static int mma8452_probe(struct i2c_client *client,
> >>MMA8452_CTRL_REG5,
> >>data->chip_info->all_events);
> >>if (ret < 0)
> >> -return ret;
> >> +goto disable_regulators;
> >> 
> >>dev_dbg(>dev, "using interrupt line INT1\n");
> >>}
> >> @@ -1604,11 +1638,11 @@ static int mma8452_probe(struct i2c_client *client,
> >>MMA8452_CTRL_REG4,
> >>data->chip_info->enabled_events);
> >>if (ret < 0)
> >> -return ret;
> >> +goto disable_regulators;
> >> 
> >>ret = mma8452_trigger_setup(indio_dev);
> >>if (ret < 0)
> >> -return ret;
> >> +goto disable_regulators;
> >>}
> >> 
> 

Re: [PATCH V7 1/2] dt-bindings: iio: accel: mma8452: add power supplies property

[Jonathan Cameron]

On Fri, 11 Jan 2019 08:32:19 -0600
Rob Herring  wrote:

> On Tue, 8 Jan 2019 09:14:01 +, Anson Huang wrote:
> > The accelerometer's power supplies could be controllable on some
> > platforms, add property "vdd/vddio" power supply to let device tree
> > to pass phandles to the regulators to driver.
> > 
> > Signed-off-by: Anson Huang 
> > ---
> >  Documentation/devicetree/bindings/iio/accel/mma8452.txt | 4 
> >  1 file changed, 4 insertions(+)
> >   
> 
> Please add Acked-by/Reviewed-by tags when posting new versions. However,
> there's no need to repost patches *only* to add the tags. The upstream
> maintainer will do that for acks received on the version they apply.
> 
> If a tag was not added on purpose, please state why and what changed.

On this occasion I've gone back and found Rob's Ack. On future occasions
I might just ignore a patch where Rob or someone else has pointed out
there previous tag / explanation for dropping it is missing.
Depends what mood I'm in :) (also Rob had pointed this out on v6 as well
so you should have been extra careful).

Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.

Thanks,

Jonathan

Re: [PATCH] lib/scatterlist: Provide a DMA page iterator

[Shiraz Saleem]

On Sat, Jan 12, 2019 at 06:37:58PM +, Jason Gunthorpe wrote:
> On Sat, Jan 12, 2019 at 12:27:05PM -0600, Shiraz Saleem wrote:
> > On Fri, Jan 04, 2019 at 10:35:43PM +, Jason Gunthorpe wrote:
> > > Commit 2db76d7c3c6d ("lib/scatterlist: sg_page_iter: support sg lists w/o
> > > backing pages") introduced the sg_page_iter_dma_address() function without
> > > providing a way to use it in the general case. If the sg_dma_len is not
> > > equal to the dma_length callers cannot safely use the
> > > for_each_sg_page/sg_page_iter_dma_address combination.
> > > 
> > > Resolve this API mistake by providing a DMA specific iterator,
> > > for_each_sg_dma_page(), that uses the right length so
> > > sg_page_iter_dma_address() works as expected with all sglists. A new
> > > iterator type is introduced to provide compile-time safety against wrongly
> > > mixing accessors and iterators.
> > [..]
> > 
> > >  
> > > +/*
> > > + * sg page iterator for DMA addresses
> > > + *
> > > + * This is the same as sg_page_iter however you can call
> > > + * sg_page_iter_dma_address(@dma_iter) to get the page's DMA
> > > + * address. sg_page_iter_page() cannot be called on this iterator.
> > > + */
> > Does it make sense to have a variant of sg_page_iter_page() to get the
> > page descriptor with this dma_iter? This can be used when walking DMA-mapped
> > SG lists with for_each_sg_dma_page.
> 
> I think that would be a complicated cacluation to find the right
> offset into the page sg list to get the page pointer back. We can't
> just naively use the existing iterator location.
> 
> Probably places that need this are better to run with two iterators,
> less computationally expensive.
> 
> Did you find a need for this? 
> 

Well I was trying convert the RDMA drivers to use your new iterator variant
and saw the need for it in locations where we need virtual address of the pages
contained in the SGEs.

diff --git a/drivers/infiniband/hw/bnxt_re/qplib_res.c 
b/drivers/infiniband/hw/bnxt_re/qplib_res.c
index 59eeac5..7d26903 100644
--- a/drivers/infiniband/hw/bnxt_re/qplib_res.c
+++ b/drivers/infiniband/hw/bnxt_re/qplib_res.c
@@ -85,7 +85,7 @@ static void __free_pbl(struct pci_dev *pdev, struct 
bnxt_qplib_pbl *pbl,
 static int __alloc_pbl(struct pci_dev *pdev, struct bnxt_qplib_pbl *pbl,
   struct scatterlist *sghead, u32 pages, u32 pg_size)
 {
-   struct scatterlist *sg;
+   struct sg_dma_page_iter sg_iter;
bool is_umem = false;
int i;

@@ -116,12 +116,13 @@ static int __alloc_pbl(struct pci_dev *pdev, struct 
bnxt_qplib_pbl *pbl,
} else {
i = 0;
is_umem = true;
-   for_each_sg(sghead, sg, pages, i) {
-   pbl->pg_map_arr[i] = sg_dma_address(sg);
-   pbl->pg_arr[i] = sg_virt(sg);
+   for_each_sg_dma_page(sghead, _iter, pages, 0) {
+   pbl->pg_map_arr[i] = sg_page_iter_dma_address(_iter);
+   pbl->pg_arr[i] = 
page_address(sg_page_iter_page(_iter.base)); ???
^

if (!pbl->pg_arr[i])
goto fail;

+   i++;
pbl->pg_count++;
}
}
--

@@ -191,16 +190,16 @@ int rxe_mem_init_user(struct rxe_pd *pd, u64 start,
goto err1;
}

-   mem->page_shift = umem->page_shift;
-   mem->page_mask  = BIT(umem->page_shift) - 1;
+   mem->page_shift = PAGE_SHIFT;
+   mem->page_mask  = PAGE_SIZE - 1;

num_buf = 0;
map = mem->map;
if (length > 0) {
buf = map[0]->buf;

-   for_each_sg(umem->sg_head.sgl, sg, umem->nmap, entry) {
-   vaddr = page_address(sg_page(sg));
+   for_each_sg_dma_page(umem->sg_head.sgl, _iter, umem->nmap, 
0) {
+   vaddr = page_address(sg_page_iter_page(_iter.base)); 
  ?



if (!vaddr) {
pr_warn("null vaddr\n");
err = -ENOMEM;
@@ -208,7 +207,7 @@ int rxe_mem_init_user(struct rxe_pd *pd, u64 start,
}

buf->addr = (uintptr_t)vaddr;
-   buf->size = BIT(umem->page_shift);
+   buf->size = PAGE_SIZE;

1.8.3.1

Re: [PATCH V9] iio: light: isl29018: add vcc regulator operation support

[Jonathan Cameron]

On Tue, 8 Jan 2019 09:09:39 +
Anson Huang  wrote:

> The light sensor's power supply could be controllable by regulator
> on some platforms, such as i.MX6Q-SABRESD board, the light sensor
> isl29023's power supply is controlled by a GPIO fixed regulator,
> need to make sure the regulator is enabled before any operation of
> sensor, this patch adds vcc regulator operation support.
> 
> Signed-off-by: Anson Huang 
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.

Thanks,

Jonathan

> ---
> ChangeLog since V8:
>   - use devm_add_action_or_reset instead of devm_add_action to avoid calling 
> regulator disable when failed;
> ---
>  drivers/iio/light/isl29018.c | 46 
> +++-
>  1 file changed, 45 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/light/isl29018.c b/drivers/iio/light/isl29018.c
> index b45400f..846df4d 100644
> --- a/drivers/iio/light/isl29018.c
> +++ b/drivers/iio/light/isl29018.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -95,6 +96,7 @@ struct isl29018_chip {
>   struct isl29018_scale   scale;
>   int prox_scheme;
>   boolsuspended;
> + struct regulator*vcc_reg;
>  };
>  
>  static int isl29018_set_integration_time(struct isl29018_chip *chip,
> @@ -708,6 +710,16 @@ static const char *isl29018_match_acpi_device(struct 
> device *dev, int *data)
>   return dev_name(dev);
>  }
>  
> +static void isl29018_disable_regulator_action(void *_data)
> +{
> + struct isl29018_chip *chip = _data;
> + int err;
> +
> + err = regulator_disable(chip->vcc_reg);
> + if (err)
> + pr_err("failed to disable isl29018's VCC regulator!\n");
> +}
> +
>  static int isl29018_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
>  {
> @@ -742,6 +754,27 @@ static int isl29018_probe(struct i2c_client *client,
>   chip->scale = isl29018_scales[chip->int_time][0];
>   chip->suspended = false;
>  
> + chip->vcc_reg = devm_regulator_get(>dev, "vcc");
> + if (IS_ERR(chip->vcc_reg)) {
> + err = PTR_ERR(chip->vcc_reg);
> + if (err != -EPROBE_DEFER)
> + dev_err(>dev, "failed to get VCC regulator!\n");
> + return err;
> + }
> +
> + err = regulator_enable(chip->vcc_reg);
> + if (err) {
> + dev_err(>dev, "failed to enable VCC regulator!\n");
> + return err;
> + }
> +
> + err = devm_add_action_or_reset(>dev, 
> isl29018_disable_regulator_action,
> +  chip);
> + if (err) {
> + dev_err(>dev, "failed to setup regulator cleanup 
> action!\n");
> + return err;
> + }
> +
>   chip->regmap = devm_regmap_init_i2c(client,
>   isl29018_chip_info_tbl[dev_id].regmap_cfg);
>   if (IS_ERR(chip->regmap)) {
> @@ -768,6 +801,7 @@ static int isl29018_probe(struct i2c_client *client,
>  static int isl29018_suspend(struct device *dev)
>  {
>   struct isl29018_chip *chip = iio_priv(dev_get_drvdata(dev));
> + int ret;
>  
>   mutex_lock(>lock);
>  
> @@ -777,10 +811,13 @@ static int isl29018_suspend(struct device *dev)
>* So we do not have much to do here.
>*/
>   chip->suspended = true;
> + ret = regulator_disable(chip->vcc_reg);
> + if (ret)
> + dev_err(dev, "failed to disable VCC regulator\n");
>  
>   mutex_unlock(>lock);
>  
> - return 0;
> + return ret;
>  }
>  
>  static int isl29018_resume(struct device *dev)
> @@ -790,6 +827,13 @@ static int isl29018_resume(struct device *dev)
>  
>   mutex_lock(>lock);
>  
> + err = regulator_enable(chip->vcc_reg);
> + if (err) {
> + dev_err(dev, "failed to enable VCC regulator\n");
> + mutex_unlock(>lock);
> + return err;
> + }
> +
>   err = isl29018_chip_init(chip);
>   if (!err)
>   chip->suspended = false;

Re: [PATCH V7] iio: magnetometer: mag3110: add vdd/vddio regulator operation support

[Jonathan Cameron]

On Tue, 8 Jan 2019 09:16:04 +
Anson Huang  wrote:

> The magnetometer's power supplies could be controllable on some platforms,
> such as i.MX6Q-SABRESD board, the mag3110's power supplies are controlled
> by a GPIO fixed regulator, need to make sure the regulators are enabled
> before any communication with mag3110, this patch adds vdd/vddio regulator
> operation support.
> 
> Signed-off-by: Anson Huang 
Thanks for you persistence on these.

Applied to the togreg branch of iio.git and pushed out as testing to let
the autobuilders see if we missed anything.

Thanks,
Jonathan

> ---
> ChangeLog Since V6:
>   - separate the error handling of regulators get to make code easy to read.
> ---
>  drivers/iio/magnetometer/mag3110.c | 94 
> ++
>  1 file changed, 86 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/iio/magnetometer/mag3110.c 
> b/drivers/iio/magnetometer/mag3110.c
> index f063355..dd990cd 100644
> --- a/drivers/iio/magnetometer/mag3110.c
> +++ b/drivers/iio/magnetometer/mag3110.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define MAG3110_STATUS 0x00
>  #define MAG3110_OUT_X 0x01 /* MSB first */
> @@ -56,6 +57,8 @@ struct mag3110_data {
>   struct mutex lock;
>   u8 ctrl_reg1;
>   int sleep_val;
> + struct regulator *vdd_reg;
> + struct regulator *vddio_reg;
>  };
>  
>  static int mag3110_request(struct mag3110_data *data)
> @@ -469,17 +472,50 @@ static int mag3110_probe(struct i2c_client *client,
>   struct iio_dev *indio_dev;
>   int ret;
>  
> - ret = i2c_smbus_read_byte_data(client, MAG3110_WHO_AM_I);
> - if (ret < 0)
> - return ret;
> - if (ret != MAG3110_DEVICE_ID)
> - return -ENODEV;
> -
>   indio_dev = devm_iio_device_alloc(>dev, sizeof(*data));
>   if (!indio_dev)
>   return -ENOMEM;
>  
>   data = iio_priv(indio_dev);
> +
> + data->vdd_reg = devm_regulator_get(>dev, "vdd");
> + if (IS_ERR(data->vdd_reg)) {
> + if (PTR_ERR(data->vdd_reg) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> +
> + dev_err(>dev, "failed to get VDD regulator!\n");
> + return PTR_ERR(data->vdd_reg);
> + }
> +
> + data->vddio_reg = devm_regulator_get(>dev, "vddio");
> + if (IS_ERR(data->vddio_reg)) {
> + if (PTR_ERR(data->vddio_reg) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> +
> + dev_err(>dev, "failed to get VDDIO regulator!\n");
> + return PTR_ERR(data->vddio_reg);
> + }
> +
> + ret = regulator_enable(data->vdd_reg);
> + if (ret) {
> + dev_err(>dev, "failed to enable VDD regulator!\n");
> + return ret;
> + }
> +
> + ret = regulator_enable(data->vddio_reg);
> + if (ret) {
> + dev_err(>dev, "failed to enable VDDIO regulator!\n");
> + goto disable_regulator_vdd;
> + }
> +
> + ret = i2c_smbus_read_byte_data(client, MAG3110_WHO_AM_I);
> + if (ret < 0)
> + goto disable_regulators;
> + if (ret != MAG3110_DEVICE_ID) {
> + ret = -ENODEV;
> + goto disable_regulators;
> + }
> +
>   data->client = client;
>   mutex_init(>lock);
>  
> @@ -499,7 +535,7 @@ static int mag3110_probe(struct i2c_client *client,
>  
>   ret = mag3110_change_config(data, MAG3110_CTRL_REG1, data->ctrl_reg1);
>   if (ret < 0)
> - return ret;
> + goto disable_regulators;
>  
>   ret = i2c_smbus_write_byte_data(client, MAG3110_CTRL_REG2,
>   MAG3110_CTRL_AUTO_MRST_EN);
> @@ -520,16 +556,24 @@ static int mag3110_probe(struct i2c_client *client,
>   iio_triggered_buffer_cleanup(indio_dev);
>  standby_on_error:
>   mag3110_standby(iio_priv(indio_dev));
> +disable_regulators:
> + regulator_disable(data->vddio_reg);
> +disable_regulator_vdd:
> + regulator_disable(data->vdd_reg);
> +
>   return ret;
>  }
>  
>  static int mag3110_remove(struct i2c_client *client)
>  {
>   struct iio_dev *indio_dev = i2c_get_clientdata(client);
> + struct mag3110_data *data = iio_priv(indio_dev);
>  
>   iio_device_unregister(indio_dev);
>   iio_triggered_buffer_cleanup(indio_dev);
>   mag3110_standby(iio_priv(indio_dev));
> + regulator_disable(data->vddio_reg);
> + regulator_disable(data->vdd_reg);
>  
>   return 0;
>  }
> @@ -537,14 +581,48 @@ static int mag3110_remove(struct i2c_client *client)
>  #ifdef CONFIG_PM_SLEEP
>  static int mag3110_suspend(struct device *dev)
>  {
> - return mag3110_standby(iio_priv(i2c_get_clientdata(
> + struct mag3110_data *data = iio_priv(i2c_get_clientdata(
> + to_i2c_client(dev)));
> + int ret;
> +
> + ret = mag3110_standby(iio_priv(i2c_get_clientdata(
>   to_i2c_client(dev;
> + if (ret)
> + return ret;
> +
> + ret = regulator_disable(data->vddio_reg);

Re: [PATCH] iio: dac: ad5686: Add support for AD5674R/AD5679R

[Jonathan Cameron]

On Wed, 9 Jan 2019 11:14:16 +0200
Mircea Caprioru  wrote:

> The AD5674R/AD5679R are low power, 16-channel, 12-/16-bit buffered voltage
> output digital-to-analog converters (DACs). They include a 2.5 V internal
> reference (enabled by default).
> 
> These devices are very similar to AD5684R/AD5686R, except that they have 16
> channels.
> 
> Signed-off-by: Mircea Caprioru 
Looks good to me.  

One comment inline, but just ignore it ;)

Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.

Thanks,

Jonathan

> ---
>  drivers/iio/dac/Kconfig  |  6 +++---
>  drivers/iio/dac/ad5686-spi.c |  7 --
>  drivers/iio/dac/ad5686.c | 42 ++--
>  drivers/iio/dac/ad5686.h |  2 ++
>  4 files changed, 50 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
> index 851b61eaf3da..f28daf67db6a 100644
> --- a/drivers/iio/dac/Kconfig
> +++ b/drivers/iio/dac/Kconfig
> @@ -148,9 +148,9 @@ config AD5686_SPI
>   depends on SPI
>   select AD5686
>   help
> -   Say yes here to build support for Analog Devices AD5672R, AD5676,
> -   AD5676R, AD5684, AD5684R, AD5684R, AD5685R, AD5686, AD5686R.
> -   Voltage Output Digital to Analog Converter.
> +   Say yes here to build support for Analog Devices AD5672R, AD5674R,
> +   AD5676, AD5676R, AD5679R, AD5684, AD5684R, AD5684R, AD5685R, AD5686,
> +   AD5686R Voltage Output Digital to Analog Converter.
>  
> To compile this driver as a module, choose M here: the
> module will be called ad5686.
> diff --git a/drivers/iio/dac/ad5686-spi.c b/drivers/iio/dac/ad5686-spi.c
> index 665fa6bd9ced..4d857c8da2d2 100644
> --- a/drivers/iio/dac/ad5686-spi.c
> +++ b/drivers/iio/dac/ad5686-spi.c
> @@ -1,7 +1,8 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  /*
> - * AD5672R, AD5676, AD5676R, AD5681R, AD5682R, AD5683, AD5683R,
> - * AD5684, AD5684R, AD5685R, AD5686, AD5686R
> + * AD5672R, AD5674R, AD5676, AD5676R, AD5679R,
> + * AD5681R, AD5682R, AD5683, AD5683R, AD5684,
> + * AD5684R, AD5685R, AD5686, AD5686R
This goes to show that listing the parts supported by the driver at the top
is more trouble than it's worth.  The nice id tables tell us the same
thing and have much less churn ;)

oh well. I don't really care obviously.

>   * Digital to analog converters driver
>   *
>   * Copyright 2018 Analog Devices Inc.
> @@ -102,8 +103,10 @@ static int ad5686_spi_remove(struct spi_device *spi)
>  static const struct spi_device_id ad5686_spi_id[] = {
>   {"ad5310r", ID_AD5310R},
>   {"ad5672r", ID_AD5672R},
> + {"ad5674r", ID_AD5674R},
>   {"ad5676", ID_AD5676},
>   {"ad5676r", ID_AD5676R},
> + {"ad5679r", ID_AD5679R},
>   {"ad5681r", ID_AD5681R},
>   {"ad5682r", ID_AD5682R},
>   {"ad5683", ID_AD5683},
> diff --git a/drivers/iio/dac/ad5686.c b/drivers/iio/dac/ad5686.c
> index a332b93ca2c4..6dd2759b9092 100644
> --- a/drivers/iio/dac/ad5686.c
> +++ b/drivers/iio/dac/ad5686.c
> @@ -71,7 +71,7 @@ static ssize_t ad5686_write_dac_powerdown(struct iio_dev 
> *indio_dev,
>   int ret;
>   struct ad5686_state *st = iio_priv(indio_dev);
>   unsigned int val, ref_bit_msk;
> - u8 shift;
> + u8 shift, address = 0;
>  
>   ret = strtobool(buf, );
>   if (ret)
> @@ -94,6 +94,9 @@ static ssize_t ad5686_write_dac_powerdown(struct iio_dev 
> *indio_dev,
>   case AD5686_REGMAP:
>   shift = 0;
>   ref_bit_msk = 0;
> + /* AD5674R/AD5679R have 16 channels and 2 powerdown registers */
> + if (chan->channel > 0x7)
> + address = 0x8;
>   break;
>   case AD5693_REGMAP:
>   shift = 13;
> @@ -107,7 +110,8 @@ static ssize_t ad5686_write_dac_powerdown(struct iio_dev 
> *indio_dev,
>   if (!st->use_internal_vref)
>   val |= ref_bit_msk;
>  
> - ret = st->write(st, AD5686_CMD_POWERDOWN_DAC, 0, val);
> + ret = st->write(st, AD5686_CMD_POWERDOWN_DAC,
> + address, val >> (address * 2));
>  
>   return ret ? ret : len;
>  }
> @@ -226,10 +230,32 @@ static struct iio_chan_spec name[] = {  
> \
>   AD5868_CHANNEL(7, 7, bits, _shift), \
>  }
>  
> +#define DECLARE_AD5679_CHANNELS(name, bits, _shift)  \
> +static struct iio_chan_spec name[] = {   \
> + AD5868_CHANNEL(0, 0, bits, _shift), \
> + AD5868_CHANNEL(1, 1, bits, _shift), \
> + AD5868_CHANNEL(2, 2, bits, _shift), \
> + AD5868_CHANNEL(3, 3, bits, _shift), \
> + AD5868_CHANNEL(4, 4, bits, _shift), \
> + AD5868_CHANNEL(5, 5, bits, _shift), \
> + AD5868_CHANNEL(6, 6, bits, _shift), \
> + AD5868_CHANNEL(7, 7, bits, _shift), \
> + 

Re: [PATCH v2 2/2] iio: adc: add NPCM ADC driver

[Jonathan Cameron]

On Wed,  9 Jan 2019 18:43:43 +0200
Tomer Maimon  wrote:

> Add Nuvoton NPCM BMC Analog-to-Digital Converter(ADC) driver.
> 
> The NPCM ADC is a 10-bit converter for eight channel inputs.
> 
> Signed-off-by: Tomer Maimon 
Hi Tomer,

Only remaining element I think needs tidying up is the relative
ordering of probe vs remove and the interaction with devm managed
cleanup.

I really like to see the two elements being as near as possible
to opposite in order. It's a lot harder to review if they aren't.
Chances are there isn't a race condition in here, but if they are
in the 'right' order it becomes much more obvious that there isn't!

Thanks,

Jonathan

> ---
>  drivers/iio/adc/Kconfig|  10 ++
>  drivers/iio/adc/Makefile   |   1 +
>  drivers/iio/adc/npcm_adc.c | 338 
> +
>  3 files changed, 349 insertions(+)
>  create mode 100644 drivers/iio/adc/npcm_adc.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 7a3ca4ec0cb7..2d1e70a7d5c4 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -576,6 +576,16 @@ config NAU7802
> To compile this driver as a module, choose M here: the
> module will be called nau7802.
>  
> +config NPCM_ADC
> + tristate "Nuvoton NPCM ADC driver"
> + depends on ARCH_NPCM || COMPILE_TEST
> + depends on HAS_IOMEM
> + help
> +   Say yes here to build support for Nuvoton NPCM ADC.
> +
> +   This driver can also be built as a module. If so, the module
> +   will be called npcm_adc.
> +
>  config PALMAS_GPADC
>   tristate "TI Palmas General Purpose ADC"
>   depends on MFD_PALMAS
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 07df37f621bd..3337eb1f4c30 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -55,6 +55,7 @@ obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
>  obj-$(CONFIG_MESON_SARADC) += meson_saradc.o
>  obj-$(CONFIG_MXS_LRADC_ADC) += mxs-lradc-adc.o
>  obj-$(CONFIG_NAU7802) += nau7802.o
> +obj-$(CONFIG_NPCM_ADC) += npcm_adc.o
>  obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
>  obj-$(CONFIG_QCOM_SPMI_ADC5) += qcom-spmi-adc5.o
>  obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
> diff --git a/drivers/iio/adc/npcm_adc.c b/drivers/iio/adc/npcm_adc.c
> new file mode 100644
> index ..c364f2dbd702
> --- /dev/null
> +++ b/drivers/iio/adc/npcm_adc.c
> @@ -0,0 +1,338 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2019 Nuvoton Technology corporation.
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct npcm_adc {
> + bool int_status;
> + u32 adc_sample_hz;
> + struct device *dev;
> + void __iomem *regs;
> + struct clk *adc_clk;
> + wait_queue_head_t wq;
> + struct regulator *vref;
> + struct regmap *rst_regmap;
> +};
> +
> +/* NPCM7xx reset module */
> +#define NPCM7XX_IPSRST1_OFFSET   0x020
> +#define NPCM7XX_IPSRST1_ADC_RST  BIT(27)
> +
> +/* ADC registers */
> +#define NPCM_ADCCON   0x00
> +#define NPCM_ADCDATA  0x04
> +
> +/* ADCCON Register Bits */
> +#define NPCM_ADCCON_ADC_INT_EN   BIT(21)
> +#define NPCM_ADCCON_REFSEL   BIT(19)
> +#define NPCM_ADCCON_ADC_INT_ST   BIT(18)
> +#define NPCM_ADCCON_ADC_EN   BIT(17)
> +#define NPCM_ADCCON_ADC_RST  BIT(16)
> +#define NPCM_ADCCON_ADC_CONV BIT(13)
> +
> +#define NPCM_ADCCON_CH_MASK  GENMASK(27, 24)
> +#define NPCM_ADCCON_CH(x)((x) << 24)
> +#define NPCM_ADCCON_DIV_SHIFT1
> +#define NPCM_ADCCON_DIV_MASK GENMASK(8, 1)
> +#define NPCM_ADC_DATA_MASK(x)((x) & GENMASK(9, 0))
> +
> +#define NPCM_ADC_ENABLE  (NPCM_ADCCON_ADC_EN | 
> NPCM_ADCCON_ADC_INT_EN)
> +
> +/* ADC General Definition */
> +#define NPCM_RESOLUTION_BITS 10
> +#define NPCM_ADC_DEFAULT_SAMPLE_RATE 1250
> +#define NPCM_INT_VREF_MV 2000
> +
> +#define NPCM_ADC_CHAN(ch) {  \
> + .type = IIO_VOLTAGE,\
> + .indexed = 1,   \
> + .channel = ch,  \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),   \
> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |  \
> + BIT(IIO_CHAN_INFO_SAMP_FREQ),   \
> +}
> +
> +static const struct iio_chan_spec npcm_adc_iio_channels[] = {
> + NPCM_ADC_CHAN(0),
> + NPCM_ADC_CHAN(1),
> + NPCM_ADC_CHAN(2),
> + NPCM_ADC_CHAN(3),
> + NPCM_ADC_CHAN(4),
> + NPCM_ADC_CHAN(5),
> + NPCM_ADC_CHAN(6),
> + NPCM_ADC_CHAN(7),
> +};
> +
> +static irqreturn_t npcm_adc_isr(int irq, void *data)
> +{
> + u32 regtemp;
> + struct iio_dev *indio_dev = data;
> + struct npcm_adc *info = 

Re: [PATCH v2 3/7] drm: rockchip: vop: add rk3066 vop definitions

[Heiko Stuebner]

Am Freitag, 11. Januar 2019, 15:54:24 CET schrieb Rob Herring:
> On Sun, Dec 30, 2018 at 06:22:00PM +0100, Heiko Stuebner wrote:
> > Hi Johan,
> > 
> > Am Samstag, 29. Dezember 2018, 14:33:14 CET schrieb Johan Jonker:
> > > From: Mark Yao 
> > > 
> > > This patch adds the rk3066 VOP definitions.
> > > 
> > > The VOP or LCD Controller serves as interface between
> > > framebuffer memory and a display device (LCD panel or TV set).
> > > 
> > > This SOC has two symmetrical LCDC's for a dual panel application.
> > > 
> > > A LCDC has 5 display layers.
> > > Only 3 are used here.
> > > 
> > > - Video layer 0 (Win0)
> > > - Video layer 1 (Win1)
> > > - OSD layer (Win2)
> > 
> > Patch itself looks good, we'll need to wait a bit to give Rob a chance
> > to look at the (simple) dt-binding change and I'll drop the paragraph
> > about the display layers when applying.
> 
> Don't wait on me for simple oneline compatible additions.

This more or less was the fault of the year change :-D ... most of
the time I'd apply a simple new compatible earlier and possibly
without Ack ;-) .

And I've applied the patch to drm-misc-next now (for 5.1).

Heiko

Re: [GIT PULL] remove dma_zalloc_coherent

[Linus Torvalds]

On Sat, Jan 12, 2019 at 10:31 AM Christoph Hellwig  wrote:
>
> Many users don't need it for security reasons, but given that x86
> and arm have done it forever various drivers started relying on the
> behavior.

Ok, I guess that's a pretty strong argument.

  Linus

Re: [PATCH v2 1/2] dt-binding: iio: add NPCM ADC documentation

[Jonathan Cameron]

On Wed,  9 Jan 2019 18:43:42 +0200
Tomer Maimon  wrote:

> Added device tree binding documentation for Nuvoton BMC
> NPCM Analog-to-Digital Converter(ADC).
> 
> Signed-off-by: Tomer Maimon 
This looks fine to me, but I would like Rob's confirmation that
he is happy with the reset part in particular.

Thanks,

Jonathan

> ---
>  .../bindings/iio/adc/nuvoton,npcm-adc.txt  | 35 
> ++
>  1 file changed, 35 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/iio/adc/nuvoton,npcm-adc.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/nuvoton,npcm-adc.txt 
> b/Documentation/devicetree/bindings/iio/adc/nuvoton,npcm-adc.txt
> new file mode 100644
> index ..1b8132cd9060
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/nuvoton,npcm-adc.txt
> @@ -0,0 +1,35 @@
> +Nuvoton NPCM Analog to Digital Converter (ADC)
> +
> +The NPCM ADC is a 10-bit converter for eight channel inputs.
> +
> +Required properties:
> +- compatible: "nuvoton,npcm750-adc" for the NPCM7XX BMC.
> +- reg: specifies physical base address and size of the registers.
> +- interrupts: Contain the ADC interrupt with flags for falling edge.
> +
> +Optional properties:
> +- clocks: phandle of ADC reference clock, in case the clock is not
> +   added the ADC will use the default ADC sample rate.
> +- vref-supply: The regulator supply ADC reference voltage, in case the
> +vref-supply is not added the ADC will use internal 
> voltage
> +reference.
> +
> +Required Node in the NPCM7xx BMC:
> +An additional register is present in the NPCM7xx SOC which is
> +assumed to be in the same device tree, with and marked as
> +compatible with "nuvoton,npcm750-rst".
> +
> +Example:
> +
> +adc: adc@f000c000 {
> + compatible = "nuvoton,npcm750-adc";
> + reg = <0xf000c000 0x8>;
> + interrupts = ;
> + clocks = < NPCM7XX_CLK_ADC>;
> +};
> +
> +rst: rst@f0801000 {
> + compatible = "nuvoton,npcm750-rst", "syscon",
> + "simple-mfd";
> + reg = <0xf0801000 0x6C>;
> +};

Re: [GIT PULL] KVM fixes for Linux 5.0-rc2

[pr-tracker-bot]

The pull request you sent on Sat, 12 Jan 2019 13:30:38 +0100:

> git://git.kernel.org/pub/scm/virt/kvm/kvm tags/for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/473348891c36ff6de3e224fefa0b3fc86a629178

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [PULL] drm-fixes

[pr-tracker-bot]

The pull request you sent on Sat, 12 Jan 2019 00:06:48 +0100:

> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-01-11-1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7b5c8f5226bd0eb77da8a055f43b2f1a06e92ba8

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: stack-protector: fix CC_HAS_STACKPROTECTOR_NONE depend on -fno-stack-protector

[Kees Cook]

On Fri, Jan 11, 2019 at 7:56 PM 隆春  wrote:
>
> commit（2a61f4747eeaa85ce26ca9fbd81421b15facd018）rename CC_STACKPROTECTOR_NONE
> config. but unfortunately if the compiler support option -fno-stack-protector,
> CC_HAS_STACKPROTECTOR_NONE will not be disabled.
>
> CC_HAS_STACKPROTECTOR_NONE and CC_STACKPROTECTOR_STRONG will be enabled at 
> once,
> as the following conditions:
> 1. gcc support -fno-stack-protector & -fstack-protector-strong
> 2. enabled CC_STACKPROTECTOR_STRONG & STACKPROTECTOR
> 3. disabled CC_HAS_STACKPROTECTOR_NONE

While it's not very obvious, it's safe to include both
-fno-stack-protector and -fstack-protector* on the gcc command line
since the latter one is the only one that is used.

Are you seeing miscompilation or error conditions without this patch?

-Kees

-- 
Kees Cook

Re: [PATCH v3 2/3] iio: adc: Add the TI ads124s08 ADC code

[Jonathan Cameron]

On Sat, 12 Jan 2019 18:42:49 +
Jonathan Cameron  wrote:

> On Fri, 11 Jan 2019 13:57:06 -0600
> Dan Murphy  wrote:
> 
> > Introduce the TI ADS124S08 and the ADS124S06 ADC
> > devices from TI.  The ADS124S08 is the 12 channel ADC
> > and the ADS124S06 is the 6 channel ADC device
> > 
> > These devices share a common datasheet:
> > http://www.ti.com/lit/gpn/ads124s08
> > 
> > Signed-off-by: Dan Murphy   
> Hi Dan,
> 
> The only real change in here (there is another nitpick) that I think
> needs to be made is that the buffer length in the private stucture is
> not longer connected to the number of channels.  You effectively use it
> as a bounce buffer now and I think the maximum is 5.
> 
> As that's it I'll just clean it up whilst applying.  If you could
> confirm I'm not crazy and didn't mess it up that would be great!
Probably would help if I added.

Applied to the togreg branch of iio.git but for now just pushed out
as testing for the autobuilders to play with it.

Thanks,

Jonathan

> 
> Thanks,
> 
> Jonathan
> 
> > ---
> > v3 - Fixed the IIO channel definition, reduce long line in probe and
> > fixed the buffer allocation definition - 
> > https://lore.kernel.org/patchwork/patch/1023970/
> > 
> > v2 - Removed the fill_noop call, updated probe to use device managed calls,
> > removed regulator support, fixed the buffer to allow 64 bit timestamp, 
> > changed
> > all the defines from S0X to S08, added an enum for the IDs and updated 
> > copyright
> > header format.  I may have missed a few summary changes here but here is the
> > review reference - https://lore.kernel.org/patchwork/patch/1021048/
> > 
> >  drivers/iio/adc/Kconfig|  10 +
> >  drivers/iio/adc/Makefile   |   1 +
> >  drivers/iio/adc/ti-ads124s08.c | 375 +
> >  3 files changed, 386 insertions(+)
> >  create mode 100644 drivers/iio/adc/ti-ads124s08.c
> > 
> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > index 7a3ca4ec0cb7..8cf9e007ea76 100644
> > --- a/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -908,6 +908,16 @@ config TI_ADS8688
> >   This driver can also be built as a module. If so, the module will be
> >   called ti-ads8688.
> >  
> > +config TI_ADS124S08
> > +   tristate "Texas Instruments ADS124S08"
> > +   depends on SPI && OF
> > +   help
> > + If you say yes here you get support for Texas Instruments ADS124S08
> > + and ADS124S06 ADC chips
> > +
> > + This driver can also be built as a module. If so, the module will be
> > + called ti-ads124s08.
> > +
> >  config TI_AM335X_ADC
> > tristate "TI's AM335X ADC driver"
> > depends on MFD_TI_AM335X_TSCADC && HAS_DMA
> > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> > index 07df37f621bd..49b203bf4e0e 100644
> > --- a/drivers/iio/adc/Makefile
> > +++ b/drivers/iio/adc/Makefile
> > @@ -81,6 +81,7 @@ obj-$(CONFIG_TI_ADC161S626) += ti-adc161s626.o
> >  obj-$(CONFIG_TI_ADS1015) += ti-ads1015.o
> >  obj-$(CONFIG_TI_ADS7950) += ti-ads7950.o
> >  obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
> > +obj-$(CONFIG_TI_ADS124S08) += ti-ads124s08.o
> >  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
> >  obj-$(CONFIG_TI_TLC4541) += ti-tlc4541.o
> >  obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
> > diff --git a/drivers/iio/adc/ti-ads124s08.c b/drivers/iio/adc/ti-ads124s08.c
> > new file mode 100644
> > index ..3d7f2300e0f6
> > --- /dev/null
> > +++ b/drivers/iio/adc/ti-ads124s08.c
> > @@ -0,0 +1,375 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/* TI ADS124S0X chip family driver
> > + * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/* Commands */
> > +#define ADS124S08_CMD_NOP  0x00
> > +#define ADS124S08_CMD_WAKEUP   0x02
> > +#define ADS124S08_CMD_PWRDWN   0x04
> > +#define ADS124S08_CMD_RESET0x06
> > +#define ADS124S08_CMD_START0x08
> > +#define ADS124S08_CMD_STOP 0x0a
> > +#define ADS124S08_CMD_SYOCAL   0x16
> > +#define ADS124S08_CMD_SYGCAL   0x17
> > +#define ADS124S08_CMD_SFOCAL   0x19
> > +#define ADS124S08_CMD_RDATA0x12
> > +#define ADS124S08_CMD_RREG 0x20
> > +#define ADS124S08_CMD_WREG 0x40
> > +
> > +/* Registers */
> > +#define ADS124S08_ID_REG   0x00
> > +#define ADS124S08_STATUS   0x01
> > +#define ADS124S08_INPUT_MUX0x02
> > +#define ADS124S08_PGA  0x03
> > +#define ADS124S08_DATA_RATE0x04
> > +#define ADS124S08_REF  0x05
> > +#define ADS124S08_IDACMAG  0x06
> > +#define ADS124S08_IDACMUX  0x07
> > +#define ADS124S08_VBIAS0x08
> > +#define ADS124S08_SYS  0x09
> > +#define ADS124S08_OFCAL0   0x0a
> > +#define ADS124S08_OFCAL1   0x0b
> > 

Re: [PATCH v5 8/8] arm64: dts: qcom: sdm845: Add Q6V5 MSS node

[Bjorn Andersson]

On Fri 11 Jan 13:06 PST 2019, Doug Anderson wrote:

> Hi,
> 
> On Wed, Jan 9, 2019 at 9:00 AM Sibi Sankar  wrote:
> >
> > This patch adds Q6V5 MSS remoteproc node for SDM845 SoCs.
> >
> > Signed-off-by: Sibi Sankar 
> > Reviewed-by: Douglas Anderson 
> > ---
> >
> > v5:
> >   * Use qmp_aop updated dt binding
> 
> nit: since this is now a singleton patch in v5 (because patches #1 -
> #7 landed), the general policy is to drop the "8/8" in the subject.
> AKA I believe the subject of the patch ought to have been:
> 
> [PATCH v5] arm64: dts: qcom: sdm845: Add Q6V5 MSS node
> 
> 
> > v3:
> >   * with shutdown-ack irq redesign make it mandatory,
> > merge multiple patches into a single one
> >
> > v2:
> >   * Fixed style changes
> >   * Added missing clocks in the dt-bindings
> >   * Split mss remoteproc node into a number of patches
> >
> > This patch depends on the following bindings:
> > https://patchwork.kernel.org/patch/10662089/ - mba/mpss reserved regions
> > https://patchwork.kernel.org/patch/10657325/ - pdc reset node
> > https://patchwork.kernel.org/patch/10753659/ - rpmhpd dt node
> > https://patchwork.kernel.org/patch/10749469/ - AOP QMP dt bindings
> > https://patchwork.kernel.org/patch/10751757/ - shutdown-irq binding
> >
> >  arch/arm64/boot/dts/qcom/sdm845.dtsi | 60 
> >  1 file changed, 60 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
> > b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > index 5da9fa1feb8a..e021b15f87fd 100644
> > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > @@ -1366,6 +1366,66 @@
> > };
> > };
> >
> > +   remoteproc@408 {
> 
> It would be handy if you added a label here, AKA:
> 
> mss_pil: remoteproc@408 {
> 
> It's expected that boards will need to refer to this node so that they
> can provide a firmware-name, so you need to give them a label to grab
> onto.
> 

I agree.

> ...and actually, I wonder if boards will also need to be able to set
> status = "okay"?  Right now they don't because you don't have a status
> = "disabled" in sdm845.dtsi, but maybe you should?  Are there ever
> going to be any boards with sdm845 that don't hook up the modem?
> 

The modem is status "ok" on my SDA845 device (but haven't verified
upstream myself yet), so I think it's fine to leave it enabled.

But merging this as is will cause the modem to crash repeatedly until
rmtfs is present. Sibi is making progress on tying this to rmtfs, which
would be accompanied by the following commit:

https://lore.kernel.org/lkml/20180524192141.20323-1-ramon.fr...@gmail.com/

I'm okay with merging that now, to unblock the merge of this patch.
Would appreciate an Ack on this.


Also, Sibi, the glink-edge binding doesn't define the mbox-names
property, so please drop it.

Regards,
Bjorn