date:20190110

Linus,

Please pull the latest efi-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
efi-urgent-for-linus

   # HEAD: b12f5440d8ca02e8f9ab4f1461f9214295cc4f66 Merge branch 'linus' into 
efi/urgent, to resolve conflict

A single fix that adds an annotation to resolve a kmemleak false 
positive.

 Thanks,

Ingo

-->
Qian Cai (1):
  efi: Let kmemleak ignore false positives


 drivers/firmware/efi/efi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 4c46ff6f2242..7ac09dd8f268 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -1026,6 +1027,8 @@ int __ref efi_mem_reserve_persistent(phys_addr_t addr, 
u64 size)
if (!rsv)
return -ENOMEM;
 
+   kmemleak_ignore(rsv);
+
rsv->size = EFI_MEMRESERVE_COUNT(PAGE_SIZE);
atomic_set(>count, 1);
rsv->entry[0].base = addr;

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

2019-01-10 Thread Pankaj Gupta

> 
> 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).

Not sure how? this is similar to mmapping virtual memory by any userspace 
process. Any host userspace process can do such attack on host page cache
using mincore & mmap shared file. 

But i don't think guest can do this alone. For virtio-pmem usecase guest 
won't be using page cache so timing attack from only guest side is not 
possible unless host userspace can run checks on page cache eviction state
using mincore etc. 

As rightly described by Rik, guest will only access its own page cache pages 
and if guest page cache is managed directly by host, this saves alot of 
effort for guest in transferring guest state of page cache.  

> 
> 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.

If I am following correctly the discussions in MM thread. 
Important steps to mitigate this:

* Avoid running mincore in privilege mode: to safeguard page evict state of any 
  page cache page.
* tweaking RWF_NOWAIT 

I think if we secure ways to find current state(cached/evicted) of a page in 
host, 
we should be able to mitigate the impact for any page cache page access attack 
including virtio-pmem.

Thanks,
Pankaj

[GIT PULL] perf fixes

Linus,

Please pull the latest perf-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
perf-urgent-for-linus

   # HEAD: 4e72ee8872279a70ebe973172133b98e8acbf54e Merge tag 
'perf-core-for-mingo-5.0-20190110' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent

Tooling changes only: fixes and a few stray improvements.

Most of the diffstat is dominated by a PowerPC related fix of system call 
trace output beautification that allows us to (again) use the UAPI header 
version and sync up with the kernel's version of PowerPC system call 
names in the arch/powerpc/kernel/syscalls/syscall.tbl header.

 Thanks,

Ingo

-->
Arnaldo Carvalho de Melo (19):
  tools headers x86: Sync disabled-features.h
  tools headers uapi: Sync prctl.h with the kernel sources
  tools beauty: Make the prctl option table generator catch all PR_ options
  tools headers uapi: Update i915_drm.h
  tools headers uapi: Sync linux/in.h copy from the kernel sources
  tools headers uapi: Sync linux/kvm.h with the kernel sources
  tools headers uapi: Sync copy of asm-generic/unistd.h with the kernel 
sources
  tools headers x86: Sync asm/cpufeatures.h copy with the kernel sources
  perf python: Make sure the python binding output directory is in place
  perf test shell: Use a fallback to get the pathname in vfs_getname
  perf trace: Fix ')' placement in "interrupted" syscall lines
  perf trace: Fix alignment for [continued] lines
  perf top: Lift restriction on using callchains without "sym" in --sort
  tools include uapi: Grab a copy of linux/mount.h
  perf beauty: Switch from using uapi/linux/fs.h to uapi/linux/mount.h
  tools include uapi: Sync linux/fs.h copy with the kernel sources
  tools include uapi: Sync linux/vhost.h with the kernel sources
  tools include uapi: Sync linux/if_link.h copy with the kernel sources
  perf symbols: Add 'arch_cpu_idle' to the list of kernel idle symbols

Florian Fainelli (2):
  perf tools: Make find_vdso_map() more modular
  perf tests: Add a test for the ARM 32-bit [vectors] page

Ivan Krylov (1):
  perf annotate: Pass filename to objdump via execl

Jin Yao (2):
  perf stat: Fix endless wait for child process
  perf report: Fix wrong iteration count in --branch-history

Jiri Olsa (2):
  tools thermal tmon: Use -O3 instead of -O1 if available
  tools iio: Override CFLAGS assignments

Mattias Jacobsson (1):
  perf strbuf: Remove redundant va_end() in strbuf_addv()

Ravi Bangoria (2):
  perf powerpc: Rework syscall table generation
  tools headers powerpc: Remove unistd.h

Tzvetomir Stoyanov (7):
  tools lib traceevent: Introduce new libtracevent API: tep_override_comm()
  tools lib traceevent: Initialize host_bigendian at tep_handle allocation
  tools lib traceevent: Rename struct cmdline to struct tep_cmdline
  tools lib traceevent: Changed return logic of trace_seq_printf() and 
trace_seq_vprintf() APIs
  tools lib traceevent: Changed return logic of 
tep_register_event_handler() API
  tools lib traceevent: Rename tep_is_file_bigendian() to 
tep_file_bigendian()
  tools lib traceevent: Remove tep_data_event_from_type() API


 tools/arch/powerpc/include/uapi/asm/unistd.h   | 404 ---
 tools/arch/x86/include/asm/cpufeatures.h   |   2 +
 tools/arch/x86/include/asm/disabled-features.h |   8 +-
 tools/include/uapi/asm-generic/unistd.h|   4 +-
 tools/include/uapi/drm/i915_drm.h  |   8 +
 tools/include/uapi/linux/fs.h  |  60 +--
 tools/include/uapi/linux/if_link.h |  19 +
 tools/include/uapi/linux/in.h  |  10 +-
 tools/include/uapi/linux/kvm.h |  19 +
 tools/include/uapi/linux/mount.h   |  58 +++
 tools/include/uapi/linux/prctl.h   |   8 +
 tools/include/uapi/linux/vhost.h   | 113 +-
 tools/lib/traceevent/event-parse-api.c |   4 +-
 tools/lib/traceevent/event-parse-local.h   |   4 +-
 tools/lib/traceevent/event-parse.c | 129 ---
 tools/lib/traceevent/event-parse.h |  17 +-
 tools/lib/traceevent/plugin_kvm.c  |   2 +-
 tools/lib/traceevent/trace-seq.c   |  17 +-
 tools/perf/Makefile.perf   |   8 +-
 tools/perf/arch/arm/tests/Build|   1 +
 tools/perf/arch/arm/tests/arch-tests.c |   4 +
 tools/perf/arch/arm/tests/vectors-page.c   |  24 ++
 tools/perf/arch/powerpc/Makefile   |  15 +-
 .../perf/arch/powerpc/entry/syscalls/mksyscalltbl  |  22 +-
 tools/perf/arch/powerpc/entry/syscalls/syscall.tbl | 427 +
 tools/perf/builtin-stat.c  |   3 +-
 t

Re: [PATCH] usb: dwc3: gadget: Fail request submission if it was already queued

2019-01-10 Thread Felipe Balbi

Hi,

Manu Gautam  writes:
> If a function driver tries to re-submit an already queued request,
> it can results in corruption of pending/started request lists.
> Catch such conditions and fail the request submission to DCD.
>
> Signed-off-by: Manu Gautam 
> ---
>  drivers/usb/dwc3/gadget.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 679c12e14522..51716c6b286a 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -1290,6 +1290,12 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, 
> struct dwc3_request *req)
>   >request, req->dep->name))
>   return -EINVAL;
>  
> + if (req->request.status == -EINPROGRESS) {

this test is really not enough. What if gadget driver set status to
EINPROGRESS before submission? A better check would involve making sure
req isn't part of dep->pending_list or dep->started_list or
dep->cancelled_list. It's clear that this won't work very well as the
amount of requests grow.

Anyway, which gadget driver did this? Why is it only affecting dwc3?

-- 
balbi

signature.asc
Description: PGP signature

Re: [PATCH 05/41] scsi: aic7xxx: aic79xx: mark expected switch fall-through

2019-01-10 Thread Hannes Reinecke


On 1/10/19 9:15 PM, Gustavo A. R. Silva wrote:

Hi,

Friendly ping (second one):

Who can ack/review/take this patch, please?

Thanks
--
Gustavo

On 12/19/18 9:36 AM, Gustavo A. R. Silva wrote:

Hi,

Friendly ping:

Who can ack or review this patch, please?

Thanks
--
Gustavo

On 11/27/18 10:26 PM, Gustavo A. R. Silva wrote:

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Notice that, in some cases, I replaced "FALLTHROUGH" with a "fall 
through"

annotation and then placed it at the bottom of the corresponding switch
case, which is what GCC is expecting to find.

Addresses-Coverity-ID: 114961 ("Missing break in switch")
Addresses-Coverity-ID: 114962 ("Missing break in switch")
Addresses-Coverity-ID: 114963 ("Missing break in switch")
Addresses-Coverity-ID: 114964 ("Missing break in switch")
Signed-off-by: Gustavo A. R. Silva 
---
  drivers/scsi/aic7xxx/aic79xx_core.c | 14 +-
  1 file changed, 9 insertions(+), 5 deletions(-)


Sorry, I thought I'd done so already.

Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
--
Dr. Hannes ReineckezSeries & Storage
h...@suse.com  +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged

2019-01-10 Thread Jiri Kosina

On Thu, 10 Jan 2019, Dave Chinner wrote:

> Sounds nice from a theoretical POV, but reality has taught us very 
> different lessons.
> 
> FWIW, a quick check of XFS's history so you understand how long this 
> behaviour has been around. It was introduced in the linux port in 2001 
> as direct IO support was being added:
> 
> commit e837eac23662afae603aaaef7c94bc839c1b8f67
> Author: Steve Lord 
> Date:   Mon Mar 5 16:47:52 2001 +
> 
> Add bounds checking for direct I/O, do the cache invalidation for
> data coherency on direct I/O.

Out of curiosity, which repository is this from please? Even google 
doesn't seem to know about this SHA.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged

2019-01-10 Thread Dave Chinner

On Thu, Jan 10, 2019 at 11:08:07PM -0800, Linus Torvalds wrote:
> On Thu, Jan 10, 2019 at 8:04 PM Dave Chinner  wrote:
> >
> > So it will only read the single page we tried to access and won't
> > perturb the rest of the message encoded into subsequent pages in
> > file.
> 
> Dave, you're being intentionally obtuse, aren't you?
> 
> It's only that single page that *matters*. That's the page that the
> probe reveals the status of - but it's also the page that the probe
> then *changes* the status of.

It changes the state of it /after/ we've already got the information
we need from it. It's not up to date, it has to come from disk, we
return EAGAIN, which means it was not in the cache.

i.e. if we return EAGAIN, we've leaked the inforation the attacker
wants regardless of how the act of initiating readahead on the page
change the state of the page.  Yes, it raises the complexity bar a
bit, and lowers the monitoring frequency somewhat, but that's about
it.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged

2019-01-10 Thread Dominique Martinet

Linus Torvalds wrote on Thu, Jan 10, 2019:
> But those numbers aren't about the mincore() change. That's just from
> dropping caches.
> 
> Now, what's the difference with the mincore change, and without? Is it
> actually measurable?
> 
> Because that's all that matters: is the mincore change something you
> can even notice? Is it a big regression?
> 
> The fact that things are slower when they are cold in the cache isn't
> the issue. The issue is whether the change to mincore semantics makes
> any difference to real loads.

mincore itself isn't used to reload the data, but is necessary to know
*what* you need to reload.
If you don't know what pages are hot, how can you preload them?

For small enough a database and with enough memory you can act stupid
and load the whole tables in cache, that's what I did because I was lazy
and only had a big mysql data set around. But the container warming up
automaton Dave mentioned and postgresql db preloading with pgfincore
explicitely depend on being able to tell what they need to preload.


pgfincore documentation states:

set of PostgreSQL functions to manage blocks in memory

Those functions let you know which and how many disk block from a
relation are in the page cache of the operating system, and eventually
write the result to a file. Then using this file, it is possible to
restore the page cache state for each block of the relation.

If you cannot dump an arbitrary "hot state" x, you cannot restore it.


This is all basically a repeat of the other subthread; sure precaching
itself doesn't need mincore and if you're all-knowing the syscall isn't
needed, but mere mortals need it.


If it's about the commit itself, vmtouch tells me 0 page in these
database files are in cache when I reboot to a 5.0-rc1 kernel and run
some queries, so the difference after a fresh boot is exactly what I
stated. I'm probably missing something but I'm not quite sure in what
situation the "new mincore" has any use right now.
-- 
Dominique Martinet | Asmadeus

Re: [PATCH] xen: Fix x86 sched_clock() interface for xen

2019-01-10 Thread Juergen Gross

On 11/01/2019 08:15, Juergen Gross wrote:
> On 11/01/2019 00:10, Boris Ostrovsky wrote:
>> On 1/10/19 12:17 PM, Boris Ostrovsky wrote:
>>> On 1/10/19 11:14 AM, Juergen Gross wrote:
 On 10/01/2019 16:34, Boris Ostrovsky wrote:
> On 1/10/19 5:07 AM, Juergen Gross wrote:
>>  
>> +void xen_clocksource_suspend(void)
>> +{
>> +xen_clock_value_saved = xen_clocksource_read() - 
>> xen_sched_clock_offset;
> xen_clock_value_saved = xen_sched_clock() maybe? 
 I wanted xen_clocksource_suspend() and xen_clocksource_resume() to
 be symmetrical to each other.
>>> OK.
>>>
>>> Reviewed-by: Boris Ostrovsky 
>>>
 In case you are feeling strong about that, I'm not. :-) So in case
 you insist on it I can change it. Or you can do so while committing.
>>
>>
>> I did some basic testing and noticed this (at loglevel=8):
>>
>> [   64.336488] Freezing user space processes ... (elapsed 0.001 seconds)
>> done.
>> [   64.337805] OOM killer disabled.
>> [   64.337814] Freezing remaining freezable tasks ... (elapsed 0.000
>> seconds) done.
>> [   64.339066] suspending xenstore...
>> [   85.888340] xen:grant_table: Grant tables using version 1 layout
>> [   64.359729] OOM killer enabled.
>> [   64.359736] Restarting tasks ... done.
>>
>>
>> Which made me think that perhaps we should do suspend/restore of the
>> clocksource as close as possible to HYPERVISOR_suspend() call, e.g. in
>> xen_arch_pre_suspend()/xen_arch_post_suspend():
>>
>> diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
>> index 45fc9caf3880..80ecba3fcc8c 100644
>> --- a/arch/x86/xen/suspend.c
>> +++ b/arch/x86/xen/suspend.c
>> @@ -22,6 +22,7 @@ static DEFINE_PER_CPU(u64, spec_ctrl);
>>  
>>  void xen_arch_pre_suspend(void)
>>  {
>> +   xen_clocksource_suspend();
>>     xen_save_time_memory_area();
>>  
>>     if (xen_pv_domain())
>> @@ -36,6 +37,7 @@ void xen_arch_post_suspend(int cancelled)
>>     xen_hvm_post_suspend(cancelled);
>>  
>>     xen_restore_time_memory_area();
>> +   xen_clocksource_resume();
>>  }
>>  
>>  static void xen_vcpu_notify_restore(void *data)
>>
>>
>> This still has a window of incorrect clock value (you can see it, for
>> example, when xen_hvm_post_suspend() does pr_info("Xen HVM callback
>> vector for event delivery is enabled\n")), but it's smaller than before.
>> In particular, we will make time right before dpm_resume_start() call.
> 
> You are right, this is better.

In fact, I can just handle this entirely inside arch/x86/xen/time.c by
moving the required statements into xen_save_time_memory_area() and
xen_restore_time_memory_area().


Juergen

Re: [PATCH v2 3/4] tee: add supp_nowait flag in tee_context struct

On Thu, 10 Jan 2019 at 19:53, Daniel Thompson
 wrote:
>
> On Thu, Jan 10, 2019 at 05:54:56PM +0530, Sumit Garg wrote:
> > This flag indicates that requests in this context should not wait for
> > tee-supplicant daemon to be started if not present and just return
> > with an error code. It is needed for requests which should be
> > non-blocking in nature like ones arising from TEE based kernel drivers
> > or any in kernel api that uses TEE internal client interface.
>
> This patch seems out of order in the patch set: Doesn't
> optee_enumarate_devices() require this feature if it is to
> work correctly with a TEE that does not implement the enumeate pTA.
>
> If so better to implement the feature first so that
> optee_emumerate_devices() works correctly when it first appears.
>

Agree, will make this patch as #2 in next version.

> >
> > Signed-off-by: Sumit Garg 
> > ---
> >  drivers/tee/optee/supp.c | 10 +-
> >  drivers/tee/tee_core.c   |  2 ++
> >  include/linux/tee_drv.h  |  6 ++
> >  3 files changed, 17 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/tee/optee/supp.c b/drivers/tee/optee/supp.c
> > index 43626e1..92f56b8 100644
> > --- a/drivers/tee/optee/supp.c
> > +++ b/drivers/tee/optee/supp.c
> > @@ -88,10 +88,18 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 
> > func, size_t num_params,
> >  {
> >   struct optee *optee = tee_get_drvdata(ctx->teedev);
> >   struct optee_supp *supp = >supp;
> > - struct optee_supp_req *req = kzalloc(sizeof(*req), GFP_KERNEL);
> > + struct optee_supp_req *req;
> >   bool interruptable;
> >   u32 ret;
> >
> > + /*
> > +  * Return in case there is no supplicant available and
> > +  * non-blocking request.
> > +  */
> > + if (!supp->ctx && ctx->supp_nowait)
> > + return TEEC_ERROR_COMMUNICATION;
> > +
> > + req = kzalloc(sizeof(*req), GFP_KERNEL);
> >   if (!req)
> >   return TEEC_ERROR_OUT_OF_MEMORY;
> >
> > diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
> > index 9ddb89e..5d6c317 100644
> > --- a/drivers/tee/tee_core.c
> > +++ b/drivers/tee/tee_core.c
> > @@ -105,6 +105,7 @@ static int tee_open(struct inode *inode, struct file 
> > *filp)
> >   if (IS_ERR(ctx))
> >   return PTR_ERR(ctx);
> >
> > + ctx->supp_nowait = false;
> >   filp->private_data = ctx;
> >   return 0;
> >  }
> > @@ -981,6 +982,7 @@ tee_client_open_context(struct tee_context *start,
> >   } while (IS_ERR(ctx) && PTR_ERR(ctx) != -ENOMEM);
> >
> >   put_device(put_dev);
> > + ctx->supp_nowait = true;
>
> Why automatically set supp_nowait inside open_context() ?
>

I think this is the default behaviour (non-blocking request) that any
in kernel client would expect. Also this flag could be configured
again before call to open_session() if any in kernel client requires
different behaviour.

-Sumit

>
> >   return ctx;
> >  }
> >  EXPORT_SYMBOL_GPL(tee_client_open_context);
> > diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h
> > index ed16bf1..fe1a920 100644
> > --- a/include/linux/tee_drv.h
> > +++ b/include/linux/tee_drv.h
> > @@ -49,6 +49,11 @@ struct tee_shm_pool;
> >   * @releasing:  flag that indicates if context is being released right now.
> >   *   It is needed to break circular dependency on context during
> >   *  shared memory release.
> > + * @supp_nowait: flag that indicates that requests in this context should 
> > not
> > + *  wait for tee-supplicant daemon to be started if not present
> > + *  and just return with an error code. It is needed for 
> > requests
> > + *  that arises from TEE based kernel drivers that should be
> > + *  non-blocking in nature.
> >   */
> >  struct tee_context {
> >   struct tee_device *teedev;
> > @@ -56,6 +61,7 @@ struct tee_context {
> >   void *data;
> >   struct kref refcount;
> >   bool releasing;
> > + bool supp_nowait;
> >  };
> >
> >  struct tee_param_memref {
> > --
> > 2.7.4
> >

Re: [PATCHv3 1/5] ARM: dts: ls1021a: add num-viewport property for PCIe DT nodes

2019-01-10 Thread Shawn Guo

On Tue, Dec 18, 2018 at 04:19:26AM +, Z.q. Hou wrote:
> From: Hou Zhiqiang 
> 
> Add num-viewport property for PCIe DT nodes to specify how many
> viewports are implemented.
> 
> Signed-off-by: Hou Zhiqiang 

Applied, thanks.

Re: [PATCHv3 2/5] arm64: dts: layerscape: add num-viewport property for PCIe DT nodes

2019-01-10 Thread Shawn Guo

On Tue, Dec 18, 2018 at 04:19:32AM +, Z.q. Hou wrote:
> From: Hou Zhiqiang 
> 
> Add num-viewport property for PCIe DT nodes to specify how many
> viewports are implemented.
> 
> Signed-off-by: Hou Zhiqiang 

Applied, thanks.

Re: [V3, 4/4] media: platform: dwc: Add MIPI CSI-2 controller driver

2019-01-10 Thread Eugen.Hristev



On 10.01.2019 18:18, Luis de Oliveira wrote:
> 
> 
> On 09-Jan-19 13:07, eugen.hris...@microchip.com wrote:
>>
>>
>> On 19.10.2018 15:52, Luis Oliveira wrote:
>>> Add the Synopsys MIPI CSI-2 controller driver. This
>>> controller driver is divided in platform dependent functions
>>> and core functions. It also includes a platform for future
>>> DesignWare drivers.
>>>
>>> Signed-off-by: Luis Oliveira 
>>> ---
>>> Changelog
>>> v2-V3
>>> - exposed IPI settings to userspace
>>> - fixed headers
>>>
>>>MAINTAINERS  |  11 +
>>>drivers/media/platform/dwc/Kconfig   |  30 +-
>>>drivers/media/platform/dwc/Makefile  |   2 +
>>>drivers/media/platform/dwc/dw-csi-plat.c | 699 
>>> +++
>>>drivers/media/platform/dwc/dw-csi-plat.h |  77 
>>>drivers/media/platform/dwc/dw-mipi-csi.c | 494 ++
>>>drivers/media/platform/dwc/dw-mipi-csi.h | 202 +
>>>include/media/dwc/dw-mipi-csi-pltfrm.h   | 102 +
>>>8 files changed, 1616 insertions(+), 1 deletion(-)
>>>create mode 100644 drivers/media/platform/dwc/dw-csi-plat.c
>>>create mode 100644 drivers/media/platform/dwc/dw-csi-plat.h
>>>create mode 100644 drivers/media/platform/dwc/dw-mipi-csi.c
>>>create mode 100644 drivers/media/platform/dwc/dw-mipi-csi.h
>>>create mode 100644 include/media/dwc/dw-mipi-csi-pltfrm.h
>>>
>>
>> [snip]
>>
>>> +/* Video formats supported by the MIPI CSI-2 */
>>> +const struct mipi_fmt dw_mipi_csi_formats[] = {
>>> +   {
>>> +   /* RAW 8 */
>>> +   .code = MEDIA_BUS_FMT_SBGGR8_1X8,
>>> +   .depth = 8,
>>> +   },
>>> +   {
>>> +   /* RAW 10 */
>>> +   .code = MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_BE,
>>> +   .depth = 10,
>>> +   },
>>
>> Hi Luis,
>>
>> Any reason why RAW12 format is not handled here ?
>>
>> Here, namely MEDIA_BUS_FMT_SBGGR12_1X12 etc.
>>
> Hi Eugen,
> 
> My Hw testing setup currently does not support it, so I didn't add it.
> 
>>> +   {
>>> +   /* RGB 565 */
>>> +   .code = MEDIA_BUS_FMT_RGB565_2X8_BE,
>>> +   .depth = 16,
>>> +   },
>>> +   {
>>> +   /* BGR 565 */
>>> +   .code = MEDIA_BUS_FMT_RGB565_2X8_LE,
>>> +   .depth = 16,
>>> +   },
>>> +   {
>>> +   /* RGB 888 */
>>> +   .code = MEDIA_BUS_FMT_RGB888_2X12_LE,
>>> +   .depth = 24,
>>> +   },
>>> +   {
>>> +   /* BGR 888 */
>>> +   .code = MEDIA_BUS_FMT_RGB888_2X12_BE,
>>> +   .depth = 24,
>>> +   },
>>> +};
>>
>> [snip]
>>
>>> +
>>> +void dw_mipi_csi_set_ipi_fmt(struct mipi_csi_dev *csi_dev)
>>> +{
>>> +   struct device *dev = csi_dev->dev;
>>> +
>>> +   if (csi_dev->ipi_dt)
>>> +   dw_mipi_csi_write(csi_dev, reg.IPI_DATA_TYPE, csi_dev->ipi_dt);
>>> +   else {
>>> +   switch (csi_dev->fmt->code) {
>>> +   case MEDIA_BUS_FMT_RGB565_2X8_BE:
>>> +   case MEDIA_BUS_FMT_RGB565_2X8_LE:
>>> +   dw_mipi_csi_write(csi_dev,
>>> +   reg.IPI_DATA_TYPE, CSI_2_RGB565);
>>> +   dev_dbg(dev, "DT: RGB 565");
>>> +   break;
>>> +
>>> +   case MEDIA_BUS_FMT_RGB888_2X12_LE:
>>> +   case MEDIA_BUS_FMT_RGB888_2X12_BE:
>>> +   dw_mipi_csi_write(csi_dev,
>>> +   reg.IPI_DATA_TYPE, CSI_2_RGB888);
>>> +   dev_dbg(dev, "DT: RGB 888");
>>> +   break;
>>> +   case MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_BE:
>>> +   dw_mipi_csi_write(csi_dev,
>>> +   reg.IPI_DATA_TYPE, CSI_2_RAW10);
>>> +   dev_dbg(dev, "DT: RAW 10");
>>> +   break;
>>> +   case MEDIA_BUS_FMT_SBGGR8_1X8:
>>> +   dw_mipi_csi_write(csi_dev,
>>> +   reg.IPI_DATA_TYPE, CSI_2_RAW8);
>>> +   dev_dbg(dev, "DT: RAW 8");
>>> +   break;
>>
>> Same here, in CSI_2_RAW12 case it will default to a RGB565 case.
>>
>> Thanks,
>>
>> Eugen
>>
>>
> I will try to add the support for this data type in my next patchset if not I
> will flag it as unsupported for now in the commit message and code.

Hi Luis,

I am currently trying to see if your driver works , and I need the RAW12 
type, that's why I am asking about it.

One question related to the subdevice you create here, how do you 
register this subdev into the media subsystem ? sync or async, or not at 
all ?
After the driver probes, there is no call to the set format functions, I 
added a node inside the Device tree, I see you are registering media 
pads, but the other endpoint needs to be an async waiting for completion 
node or your subdev registers in some other way ? (maybe some link 
validation required ?)

Thanks for your help,

Eugen

> 
> Thanks for your review,
> Luis
> 
>>
>>> +   default:
>>> +

Re: [PATCH v2 2/4] tee: optee: add TEE bus device enumeration support

On Thu, 10 Jan 2019 at 19:49, Daniel Thompson
 wrote:
>
> On Thu, Jan 10, 2019 at 05:54:55PM +0530, Sumit Garg wrote:
> > OP-TEE provides a pseudo TA to enumerate TAs which can act as devices/
> > services for TEE bus. So implement device enumeration using invoke
> > function: PTA_CMD_GET_DEVICES provided by pseudo TA to fetch array of
> > device UUIDs. Also register these enumerated devices with TEE bus as
> > "optee-clntX" device.
> >
> > Signed-off-by: Sumit Garg 
> > ---
> >  drivers/tee/optee/Makefile|   1 +
> >  drivers/tee/optee/core.c  |   4 +
> >  drivers/tee/optee/device.c| 150 
> > ++
> >  drivers/tee/optee/optee_private.h |   3 +
> >  4 files changed, 158 insertions(+)
> >  create mode 100644 drivers/tee/optee/device.c
> >
> > diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile
> > index 48d262a..56263ae 100644
> > --- a/drivers/tee/optee/Makefile
> > +++ b/drivers/tee/optee/Makefile
> > @@ -5,3 +5,4 @@ optee-objs += call.o
> >  optee-objs += rpc.o
> >  optee-objs += supp.o
> >  optee-objs += shm_pool.o
> > +optee-objs += device.o
> > diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> > index e5efce3..ac59c77 100644
> > --- a/drivers/tee/optee/core.c
> > +++ b/drivers/tee/optee/core.c
> > @@ -634,6 +634,10 @@ static struct optee *optee_probe(struct device_node 
> > *np)
> >   if (optee->sec_caps & OPTEE_SMC_SEC_CAP_DYNAMIC_SHM)
> >   pr_info("dynamic shared memory is enabled\n");
> >
> > + rc = optee_enumerate_devices();
> > + if (rc)
> > + goto err;
> > +
> >   pr_info("initialized driver\n");
> >   return optee;
> >  err:
> > diff --git a/drivers/tee/optee/device.c b/drivers/tee/optee/device.c
> > new file mode 100644
> > index 000..b38d24b
> > --- /dev/null
> > +++ b/drivers/tee/optee/device.c
> > @@ -0,0 +1,150 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2019 Linaro Ltd.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include "optee_private.h"
> > +
> > +/*
> > + * Get device UUIDs
> > + *
> > + * [out] memref[0]Array of device UUIDs
> > + *
> > + * Return codes:
> > + * TEE_SUCCESS - Invoke command success
> > + * TEE_ERROR_BAD_PARAMETERS - Incorrect input param
> > + * TEE_ERROR_SHORT_BUFFER - Output buffer size less than required
> > + */
> > +#define PTA_CMD_GET_DEVICES  0x0
> > +
> > +static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void 
> > *data)
> > +{
> > + if (ver->impl_id == TEE_IMPL_ID_OPTEE)
> > + return 1;
> > + else
> > + return 0;
> > +}
> > +
> > +static int get_devices(struct tee_context *ctx, u32 session,
> > +struct tee_shm *device_uuid, u32 *shm_size)
>
> Missing const on device_uuid?
>

I don't think we should have a const for device_uuid here as this is
shared memory struct pointer which is dynamically allocated and used
to fetch device UUIDs.

>
> > +{
> > + u32 ret = 0;
> > + struct tee_ioctl_invoke_arg inv_arg = {0};
> > + struct tee_param param[4] = {0};
> > +
> > + /* Invoke PTA_CMD_GET_DEVICES function */
> > + inv_arg.func = PTA_CMD_GET_DEVICES;
> > + inv_arg.session = session;
> > + inv_arg.num_params = 4;
> > +
> > + /* Fill invoke cmd params */
> > + param[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT;
> > + param[0].u.memref.shm = device_uuid;
> > + param[0].u.memref.size = *shm_size;
> > + param[0].u.memref.shm_offs = 0;
> > +
> > + ret = tee_client_invoke_func(ctx, _arg, param);
> > + if ((ret < 0) || ((inv_arg.ret != TEEC_SUCCESS) &&
> > +   (inv_arg.ret != TEEC_ERROR_SHORT_BUFFER))) {
> > + pr_err("PTA_CMD_GET_DEVICES invoke function err: %x\n",
> > +inv_arg.ret);
> > + return -EINVAL;
> > + }
> > +
> > + *shm_size = param[0].u.memref.size;
> > +
> > + return 0;
> > +}
> > +
> > +static int optee_register_device(uuid_t *device_uuid, u32 device_id)
>
> const?
>

Will add const here.

>
> > +{
> > + struct tee_client_device *optee_device = NULL;
> > + int rc;
> > +
> > + optee_device = kzalloc(sizeof(*optee_device), GFP_KERNEL);
> > + if (!optee_device)
> > + return -ENOMEM;
> > +
> > + optee_device->dev.bus = _bus_type;
> > + dev_set_name(_device->dev, "optee-clnt%u", device_id);
> > + uuid_copy(_device->id.uuid, device_uuid);
> > +
> > + rc = device_register(_device->dev);
> > + if (rc)
> > + pr_err("device registration failed, err: %d\n", rc);
>
> Leak optee_device?
>

Will fix.

>
> > +
> > + return rc;
> > +}
> > +
> > +int optee_enumerate_devices(void)
> > +{
> > + uuid_t pta_uuid =
> > + UUID_INIT(0x7011a688, 0xddde, 0x4053,
> > +   0xa5, 0xa9, 0x7b, 0x3c, 0x4d, 0xdf, 0x13, 0xb8);
>
> I think this could/should be const too.

Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged

2019-01-10 Thread Dave Chinner

On Thu, Jan 10, 2019 at 08:08:37PM -0800, Andy Lutomirski wrote:
> > On Jan 10, 2019, at 8:04 PM, Dave Chinner 
> > wrote:
> > 
> >> On Thu, Jan 10, 2019 at 06:18:16PM -0800, Linus Torvalds
> >> wrote:
> >>> On Thu, Jan 10, 2019 at 6:03 PM Dave Chinner
> >>>  wrote:
> >>> 
>  On Thu, Jan 10, 2019 at 02:11:01PM -0800, Linus Torvalds
>  wrote: And we *can* do sane things about RWF_NOWAIT. For
>  example, we could start async IO on RWF_NOWAIT, and suddenly
>  it would go from "probe the page cache" to "probe and fill",
>  and be much harder to use as an attack vector..
> >>> 
> >>> We can only do that if the application submits the read via
> >>> AIO and has an async IO completion reporting mechanism.
> >> 
> >> Oh, no, you misunderstand.
> >> 
> >> RWF_NOWAIT has a lot of situations where it will potentially
> >> return early (the DAX and direct IO ones have their own), but I
> >> was thinking of the one in generic_file_buffered_read(), which
> >> triggers when you don't find a page mapping. That looks like
> >> the obvious "probe page cache" case.
> >> 
> >> But we could literally move that test down just a few lines.
> >> Let it start read-ahead.
> >> 
> >> .. and then it will actually trigger on the *second* case
> >> instead, where we have
> >> 
> >>if (!PageUptodate(page)) { if (iocb->ki_flags &
> >>IOCB_NOWAIT) { put_page(page); goto would_block;
> >>}
> >> 
> >> and that's where RWF_MNOWAIT would act.
> >> 
> >> It would still return EAGAIN.
> >> 
> >> But it would have started filling the page cache. So now the
> >> act of probing would fill the page cache, and the attacker
> >> would be left high and dry - the fact that the page cache now
> >> exists is because of the attack, not because of whatever it was
> >> trying to measure.
> >> 
> >> See?
> > 
> > Except for fadvise(POSIX_FADV_RANDOM) which triggers this code
> > in page_cache_sync_readahead():
> > 
> >/* be dumb */ if (filp && (filp->f_mode & FMODE_RANDOM))
> >{ force_page_cache_readahead(mapping, filp, offset,
> >req_size); return; }
> > 
> > So it will only read the single page we tried to access and
> > won't perturb the rest of the message encoded into subsequent
> > pages in file.
> 
> There are two types of attacks.  One is an intentional side
> channel where two cooperating processes communicate.  This is,
> under some circumstances, a problem,

Yes, that's the covert communication channel that can cross container
and machine boundaries without any required privileges.

> but it’s not one
> we’re about to solve in general. The other is an attacker
> monitoring an unwilling process.

Which uses exactly the same mechanisms as the first case. i.e.
controlled invalidation and page cache residency monitoring.If we
aren't going to solve the first problem case, the we aren't going to
solve the second because they are one and the same problem...

However, I suspect you have misunderstood the monitoring mechanism
here - dispatch IO for this page doesn't prevent the information
leak about that page. It's when we return EAGAIN that we leak
information about page cache residency.

What Linus is attempting to do is perturb the nearby state of the
page cache by triggering async readahead in the EAGAIN case.  Async
readahead will fill all the holes in readahead window and hence
destroy the information about where the page fault landed and
instantiated the page cache. That would prevent the attacker from
determining what code the executable is running as they would only
be able to check a single page in an executable at a time and that
makes the attack highly impractical.

But if the attacker uses FADV_RANDOM, readahead is only triggered
for the page the attacker is trying to read. Hence it does not
disturb the nearby page cache residency pattern the executable's
page faults left behind and so doesn't destroy the information that
they are trying to extract from the unwilling process.

Sure, Linus's change makes monitoring the executable file after
FADV_RANDOM a "read-once" mechanism. However, detection of what code
is executing is a repeated invalidate-and-sweep exercise to begin
with, so it basically doesn't change the information or the rate at
which the monitoring process can extract information from the file.

/me hasn't thought about this sort of stuff since he was running
page cache invalidation attacks on Irix system libraries way back in
2002 when he found a libc bug that killed the init process and
paniced the kernel.

This isn't my first rodeo - it's been well known for a long, long
time that the system page cache can be exploited to monitor
executing code...

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH v4 0/3] bus: imx-weim

2019-01-10 Thread Shawn Guo

On Mon, Dec 17, 2018 at 10:47:57AM -0500, Sven Van Asbroeck wrote:
> Sven Van Asbroeck (3):
>   dt-bindings: bus: imx-weim: document multiple address ranges per child
> node
>   bus: imx-weim: support multiple address ranges per child node
>   bus: imx-weim: guard against timing configuration conflicts

Applied all, thanks.

Re: [PATCH] xen: Fix x86 sched_clock() interface for xen

2019-01-10 Thread Juergen Gross

On 11/01/2019 00:10, Boris Ostrovsky wrote:
> On 1/10/19 12:17 PM, Boris Ostrovsky wrote:
>> On 1/10/19 11:14 AM, Juergen Gross wrote:
>>> On 10/01/2019 16:34, Boris Ostrovsky wrote:
 On 1/10/19 5:07 AM, Juergen Gross wrote:
>  
> +void xen_clocksource_suspend(void)
> +{
> + xen_clock_value_saved = xen_clocksource_read() - xen_sched_clock_offset;
 xen_clock_value_saved = xen_sched_clock() maybe? 
>>> I wanted xen_clocksource_suspend() and xen_clocksource_resume() to
>>> be symmetrical to each other.
>> OK.
>>
>> Reviewed-by: Boris Ostrovsky 
>>
>>> In case you are feeling strong about that, I'm not. :-) So in case
>>> you insist on it I can change it. Or you can do so while committing.
> 
> 
> I did some basic testing and noticed this (at loglevel=8):
> 
> [   64.336488] Freezing user space processes ... (elapsed 0.001 seconds)
> done.
> [   64.337805] OOM killer disabled.
> [   64.337814] Freezing remaining freezable tasks ... (elapsed 0.000
> seconds) done.
> [   64.339066] suspending xenstore...
> [   85.888340] xen:grant_table: Grant tables using version 1 layout
> [   64.359729] OOM killer enabled.
> [   64.359736] Restarting tasks ... done.
> 
> 
> Which made me think that perhaps we should do suspend/restore of the
> clocksource as close as possible to HYPERVISOR_suspend() call, e.g. in
> xen_arch_pre_suspend()/xen_arch_post_suspend():
> 
> diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
> index 45fc9caf3880..80ecba3fcc8c 100644
> --- a/arch/x86/xen/suspend.c
> +++ b/arch/x86/xen/suspend.c
> @@ -22,6 +22,7 @@ static DEFINE_PER_CPU(u64, spec_ctrl);
>  
>  void xen_arch_pre_suspend(void)
>  {
> +   xen_clocksource_suspend();
>     xen_save_time_memory_area();
>  
>     if (xen_pv_domain())
> @@ -36,6 +37,7 @@ void xen_arch_post_suspend(int cancelled)
>     xen_hvm_post_suspend(cancelled);
>  
>     xen_restore_time_memory_area();
> +   xen_clocksource_resume();
>  }
>  
>  static void xen_vcpu_notify_restore(void *data)
> 
> 
> This still has a window of incorrect clock value (you can see it, for
> example, when xen_hvm_post_suspend() does pr_info("Xen HVM callback
> vector for event delivery is enabled\n")), but it's smaller than before.
> In particular, we will make time right before dpm_resume_start() call.

You are right, this is better.

Sending out V2 soon.


Juergen

[GIT PULL] x86 fixes

Linus,

Please pull the latest x86-urgent-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
x86-urgent-for-linus

   # HEAD: e4f358916d528d479c3c12bd2fd03f2d5a576380 x86, modpost: Replace last 
remnants of RETPOLINE with CONFIG_RETPOLINE

A 32-bit build fix, CONFIG_RETPOLINE fixes and rename CONFIG_RESCTRL to 
CONFIG_X86_RESCTRL.

  out-of-topic modifications in x86-urgent-for-linus:
  -
  include/linux/module.h # e4f358916d52: x86, modpost: Replace last 
r
  samples/seccomp/Makefile   # a77d1d196bc6: samples/seccomp: Fix 
32-bit 
  scripts/mod/modpost.c  # e4f358916d52: x86, modpost: Replace last 
r

 Thanks,

Ingo

-->
Borislav Petkov (1):
  x86/cache: Rename config option to CONFIG_X86_RESCTRL

Tycho Andersen (1):
  samples/seccomp: Fix 32-bit build

WANG Chao (1):
  x86, modpost: Replace last remnants of RETPOLINE with CONFIG_RETPOLINE


 Documentation/x86/resctrl_ui.txt | 2 +-
 arch/x86/Kconfig | 2 +-
 arch/x86/include/asm/resctrl_sched.h | 4 ++--
 arch/x86/kernel/cpu/Makefile | 2 +-
 arch/x86/kernel/cpu/bugs.c   | 2 +-
 arch/x86/kernel/cpu/resctrl/Makefile | 4 ++--
 include/linux/compiler-gcc.h | 2 +-
 include/linux/module.h   | 2 +-
 include/linux/sched.h| 2 +-
 samples/seccomp/Makefile | 1 +
 scripts/mod/modpost.c| 2 +-
 11 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/Documentation/x86/resctrl_ui.txt b/Documentation/x86/resctrl_ui.txt
index d9aed8303984..e8e8d14d3c4e 100644
--- a/Documentation/x86/resctrl_ui.txt
+++ b/Documentation/x86/resctrl_ui.txt
@@ -9,7 +9,7 @@ Fenghua Yu 
 Tony Luck 
 Vikas Shivappa 
 
-This feature is enabled by the CONFIG_RESCTRL and the X86 /proc/cpuinfo
+This feature is enabled by the CONFIG_X86_RESCTRL and the x86 /proc/cpuinfo
 flag bits:
 RDT (Resource Director Technology) Allocation - "rdt_a"
 CAT (Cache Allocation Technology) - "cat_l3", "cat_l2"
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 6185d4f33296..15af091611e2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -446,7 +446,7 @@ config RETPOLINE
  branches. Requires a compiler with -mindirect-branch=thunk-extern
  support for full protection. The kernel may run slower.
 
-config RESCTRL
+config X86_RESCTRL
bool "Resource Control support"
depends on X86 && (CPU_SUP_INTEL || CPU_SUP_AMD)
select KERNFS
diff --git a/arch/x86/include/asm/resctrl_sched.h 
b/arch/x86/include/asm/resctrl_sched.h
index 54990fe2a3ae..40ebddde6ac2 100644
--- a/arch/x86/include/asm/resctrl_sched.h
+++ b/arch/x86/include/asm/resctrl_sched.h
@@ -2,7 +2,7 @@
 #ifndef _ASM_X86_RESCTRL_SCHED_H
 #define _ASM_X86_RESCTRL_SCHED_H
 
-#ifdef CONFIG_RESCTRL
+#ifdef CONFIG_X86_RESCTRL
 
 #include 
 #include 
@@ -88,6 +88,6 @@ static inline void resctrl_sched_in(void)
 
 static inline void resctrl_sched_in(void) {}
 
-#endif /* CONFIG_RESCTRL */
+#endif /* CONFIG_X86_RESCTRL */
 
 #endif /* _ASM_X86_RESCTRL_SCHED_H */
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index ac78f90aea56..b6fa0869f7aa 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -39,7 +39,7 @@ obj-$(CONFIG_CPU_SUP_UMC_32)  += umc.o
 obj-$(CONFIG_X86_MCE)  += mce/
 obj-$(CONFIG_MTRR) += mtrr/
 obj-$(CONFIG_MICROCODE)+= microcode/
-obj-$(CONFIG_RESCTRL)  += resctrl/
+obj-$(CONFIG_X86_RESCTRL)  += resctrl/
 
 obj-$(CONFIG_X86_LOCAL_APIC)   += perfctr-watchdog.o
 
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 8654b8b0c848..1de0f4170178 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -215,7 +215,7 @@ static enum spectre_v2_mitigation spectre_v2_enabled 
__ro_after_init =
 static enum spectre_v2_user_mitigation spectre_v2_user __ro_after_init =
SPECTRE_V2_USER_NONE;
 
-#ifdef RETPOLINE
+#ifdef CONFIG_RETPOLINE
 static bool spectre_v2_bad_module;
 
 bool retpoline_module_ok(bool has_retpoline)
diff --git a/arch/x86/kernel/cpu/resctrl/Makefile 
b/arch/x86/kernel/cpu/resctrl/Makefile
index 6895049ceef7..1cabe6fd8e11 100644
--- a/arch/x86/kernel/cpu/resctrl/Makefile
+++ b/arch/x86/kernel/cpu/resctrl/Makefile
@@ -1,4 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_RESCTRL)  += core.o rdtgroup.o monitor.o
-obj-$(CONFIG_RESCTRL)  += ctrlmondata.o pseudo_lock.o
+obj-$(CONFIG_X86_RESCTRL)  += core.o rdtgroup.o monitor.o
+obj-$(CONFIG_X86_RESCTRL)  += ctrlmondata.o pseudo_lock.o
 CFLAGS_pseudo_lock.o = -I$(src)
diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
index 5776da43da97..dd8268f5f5f0 100644
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -68,7 +68,7 @@
  */
 #define

Re: [GIT PULL 0/4] perf/core fixes and improvements



* Arnaldo Carvalho de Melo  wrote:

> Hi Ingo,
> 
>   Please consider pulling, now there are no more ABI header
> warnings,
> 
> - Arnaldo
> 
> Test results at the end of this message, as usual.
> 
> The following changes since commit 576b50ea235699d83758c0c514c65b8d486a159d:
> 
>   Merge tag 'perf-core-for-mingo-5.0-20190108' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent 
> (2019-01-09 07:59:40 +0100)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
> tags/perf-core-for-mingo-5.0-20190110
> 
> for you to fetch changes up to 15c03092a9fbcdd041f58e5f832bf76c21c42e6a:
> 
>   tools headers powerpc: Remove unistd.h (2019-01-10 10:42:08 -0300)
> 
> 
> perf/core fixes and improvements:
> 
> perf trace:
> 
>   Ravi Bangoria:
> 
>   - Rework PowerPC syscall table generation, now using a .tbl file just like
> x86_64 and S/390, also silencing a tools build warning about headers out 
> of
> sync with the kernel sources.
> 
> tools include uapi:
> 
>   Arnaldo Carvalho de Melo:
> 
>   - Sync linux/if_link.h copy with the kernel sources, silencing a build 
> warning.
> 
> perf top:
> 
>   Arnaldo Carvalho de Melo:
> 
>   - Add 'arch_cpu_idle' to the list of kernel idle symbols, noticed on a 
> Orange
> Pi Zero ARM board, just like with other symbols in other arches.
> 
> Signed-off-by: Arnaldo Carvalho de Melo 
> 
> 
> Arnaldo Carvalho de Melo (2):
>   tools include uapi: Sync linux/if_link.h copy with the kernel sources
>   perf symbols: Add 'arch_cpu_idle' to the list of kernel idle symbols
> 
> Ravi Bangoria (2):
>   perf powerpc: Rework syscall table generation
>   tools headers powerpc: Remove unistd.h
> 
>  tools/arch/powerpc/include/uapi/asm/unistd.h   | 404 ---
>  tools/include/uapi/linux/if_link.h |  19 +
>  tools/perf/arch/powerpc/Makefile   |  15 +-
>  .../perf/arch/powerpc/entry/syscalls/mksyscalltbl  |  22 +-
>  tools/perf/arch/powerpc/entry/syscalls/syscall.tbl | 427 
> +
>  tools/perf/check-headers.sh|   1 -
>  tools/perf/util/symbol.c   |   1 +
>  7 files changed, 470 insertions(+), 419 deletions(-)
>  delete mode 100644 tools/arch/powerpc/include/uapi/asm/unistd.h
>  create mode 100644 tools/perf/arch/powerpc/entry/syscalls/syscall.tbl

Pulled, thanks a lot Arnaldo!

Ingo

Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged

2019-01-10 Thread Linus Torvalds

On Thu, Jan 10, 2019 at 8:58 PM Dominique Martinet
 wrote:
>
> I get on average over a few queries approximately a real time of 350ms,
> 230ms and 220ms immediately after drop cache and service restart, and
> 150ms, 60ms and 60ms after a prefetch (hand-wavy average over 3 runs, I
> didn't have the patience to do proper testing).
> (In both cases, user/sys are less than 10ms; I don't see much difference
> there)

But those numbers aren't about the mincore() change. That's just from
dropping caches.

Now, what's the difference with the mincore change, and without? Is it
actually measurable?

Because that's all that matters: is the mincore change something you
can even notice? Is it a big regression?

The fact that things are slower when they are cold in the cache isn't
the issue. The issue is whether the change to mincore semantics makes
any difference to real loads.

Linus

Re: [PATCH 4.19 000/170] 4.19.14-stable review

On Thu, Jan 10, 2019 at 06:27:33AM -0800, Guenter Roeck wrote:
> On 1/10/19 5:17 AM, Greg Kroah-Hartman wrote:
> > On Thu, Jan 10, 2019 at 07:52:07AM +0100, Greg Kroah-Hartman wrote:
> > > On Wed, Jan 09, 2019 at 11:40:48AM -0800, Guenter Roeck wrote:
> > > > On Wed, Jan 09, 2019 at 03:38:11PM +0100, Greg Kroah-Hartman wrote:
> > > > > On Tue, Jan 08, 2019 at 03:07:31PM -0800, Guenter Roeck wrote:
> > > > > > On Mon, Jan 07, 2019 at 01:30:27PM +0100, Greg Kroah-Hartman wrote:
> > > > > > > This is the start of the stable review cycle for the 4.19.14 
> > > > > > > release.
> > > > > > > There are 170 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 Wed Jan  9 10:43:54 UTC 2019.
> > > > > > > Anything received after that time might be too late.
> > > > > > > 
> > > > > > 
> > > > > > For v4.19.13-171-gc68ce175c3b8:
> > > > > > 
> > > > > > Build results:
> > > > > > total: 155 pass: 152 fail: 3
> > > > > > Failed builds:
> > > > > > powerpc:ppc64e_defconfig
> > > > > > powerpc:cell_defconfig
> > > > > > powerpc:maple_defconfig
> > > > > > Qemu test results:
> > > > > > total: 332 pass: 319 fail: 13
> > > > > > Failed tests:
> > > > > > ppc64:mac99:ppc64_book3s_defconfig:nosmp:initrd
> > > > > > ppc64:mac99:ppc64_book3s_defconfig:smp:initrd
> > > > > > ppc64:mac99:ppc64_book3s_defconfig:smp:ide:rootfs
> > > > > > ppc64:mac99:ppc64_book3s_defconfig:smp:mmc:rootfs
> > > > > > ppc64:mac99:ppc64_book3s_defconfig:smp:nvme:rootfs
> > > > > > ppc64:mac99:ppc64_book3s_defconfig:smp:scsi[DC395]:rootfs
> > > > > > ppc64:mpc8544ds:ppc64_e5500_defconfig:nosmp:initrd
> > > > > > ppc64:mpc8544ds:ppc64_e5500_defconfig:smp:initrd
> > > > > > ppc64:ppce500:corenet64_smp_defconfig:e5500:initrd
> > > > > > ppc64:ppce500:corenet64_smp_defconfig:e5500:nvme:rootfs
> > > > > > ppc64:ppce500:corenet64_smp_defconfig:e5500:mmc:rootfs
> > > > > > ppc64:ppce500:corenet64_smp_defconfig:e5500:scsi[53C895A]:rootfs
> > > > > > ppc64:ppce500:corenet64_smp_defconfig:e5500:sata-sii3112:rootfs
> > > > > 
> > > > > Ugh, I thought this was just the cell build, didn't realize it hit 
> > > > > more.
> > > > > 
> > > > > Ok, I've dropped the patch from all queues.  Odd that it only causes
> > > > > problems on 4.19.y :(
> > > > > 
> > > > I don't know what you dropped, but v4.19.14 fails to build with
> > > > the same error. Did you drop it after the release ?
> > > 
> > > No, I should have dropped it before the release.  Let me go see what I
> > > messed up...
> > 
> > I dropped e1c3743e1a20 ("powerpc/tm: Set MSR[TS] just prior to 
> > recheckpoint")
> > from the stable trees, which is what I was told was the commit that was
> > causing the problems by Christoph and Breno (on to: now).
> > 
> > Was that not the offending commit?  If so, what one was?
> > 
> $ git describe
> v4.19.14
> groeck@server:~/src/linux-stable$ git log --oneline v4.19.13.. arch/powerpc/
> a9935a127688 powerpc/tm: Unset MSR[TS] if not recheckpointing
> 34fc09193486 powerpc/fsl: Fix spectre_v2 mitigations reporting
> groeck@server:~/src/linux-stable$
> 
> a9935a127688 is the culprit.

Thanks for this, now reverted.

greg k-h

Re: [GIT PULL] seccomp: build fix for v5.0-rc2



* Tycho Andersen  wrote:

> On Wed, Jan 09, 2019 at 07:59:16AM +0100, Ingo Molnar wrote:
> > 
> > * Kees Cook  wrote:
> > 
> > > This was already picked up by x86-urgent...
> > > 
> > > -Kees
> > 
> > I'm fine with both routes - if Linus pulls this I'll zap the x86/urgent 
> > one.
> 
> The patches are different actually. I've confirmed the one in
> x86/urgent is correct, and this one is from the initial thread where I
> was just guessing. The difference is HOSTCFLAGS vs. HOSTLDFLAGS for .o
> files. So I think we should drop this and just keep the one in
> x86/urgent.

Ok - will send this to Linus now.

Thanks,

Ingo

Re: [PATCH 4.19 000/170] 4.19.14-stable review

On Thu, Jan 10, 2019 at 11:55:45PM +0100, Christoph Biedl wrote:
> Greg Kroah-Hartman wrote...
> 
> > Ok, Breno and Christoph, what should I do here?  Should I drop this
> > patch in the tree or add this new one?  Ideally I can fix this soon as I
> > don't like having broken trees out there...
> 
> Whatever Breno says - I don't feel competent enough to decide what's
> right here.

Ok, I'm reverting it and adding back the patch that I accidentally
dropped thinking it was the broken one.

thanks,

greg k-h

[PATCH] rtc: snvs: make sure clock is enabled for interrupt handle

During system suspend, the SNVS RTC's clock will be disabled in
noirq suspend phase, but SNVS RTC's alarm interrupt could still
arrive, system will hang if SNVS RTC driver tries to access register
without clock enabled, this patch fixes the issue of this scenario.

Signed-off-by: Anson Huang 
---
 drivers/rtc/rtc-snvs.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/rtc/rtc-snvs.c b/drivers/rtc/rtc-snvs.c
index b2483a7..0b9eff1 100644
--- a/drivers/rtc/rtc-snvs.c
+++ b/drivers/rtc/rtc-snvs.c
@@ -239,6 +239,9 @@ static irqreturn_t snvs_rtc_irq_handler(int irq, void 
*dev_id)
u32 lpsr;
u32 events = 0;
 
+   if (data->clk)
+   clk_enable(data->clk);
+
regmap_read(data->regmap, data->offset + SNVS_LPSR, );
 
if (lpsr & SNVS_LPSR_LPTA) {
@@ -253,6 +256,9 @@ static irqreturn_t snvs_rtc_irq_handler(int irq, void 
*dev_id)
/* clear interrupt status */
regmap_write(data->regmap, data->offset + SNVS_LPSR, lpsr);
 
+   if (data->clk)
+   clk_disable(data->clk);
+
return events ? IRQ_HANDLED : IRQ_NONE;
 }
 
-- 
2.7.4

Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged

2019-01-10 Thread Linus Torvalds

On Thu, Jan 10, 2019 at 8:04 PM Dave Chinner  wrote:
>
> So it will only read the single page we tried to access and won't
> perturb the rest of the message encoded into subsequent pages in
> file.

Dave, you're being intentionally obtuse, aren't you?

It's only that single page that *matters*. That's the page that the
probe reveals the status of - but it's also the page that the probe
then *changes* the status of.

See?

Think of it as "the act of measurement changes that which is
measured". And that makes the measurement pointless.

  Linus

Re: kmemleak: Cannot allocate a kmemleak_object structure - Kernel 4.19.13

2019-01-10 Thread Nathan Royce

One more thought that may be nothing, but when kmemleak crashed,
SUnreclaim was at 932552 kB, and after reclaimed/cleared 299840 kB.
There weren't any performance issues like when I had a leak of 5.5 gB
in the 4.18 kernel.

On Mon, Jan 7, 2019 at 3:52 AM Catalin Marinas  wrote:
>
> Under memory pressure, kmemleak may fail to allocate memory. See this
> patch for an attempt to slightly improve things but it's not a proper
> solution:
>
> http://lkml.kernel.org/r/20190102180619.12392-1-...@lca.pw
>
> --
> Catalin

[PATCH] Bluetooth: hci_uart: Add a local variable to store the result of h4_recv_buf()

2019-01-10 Thread Myungho Jung

In h4_recv(), if h4_recv_buf() returns error and h4_recv() is
asynchronously called again before setting rx_skb to NULL, ERR_PTR will
be dereferenced in h4_recv_buf(). Check return value in a local variable
before writing to rx_skb.

Reported-by: syzbot+017a32f149406df32...@syzkaller.appspotmail.com
Signed-off-by: Myungho Jung 
---
 drivers/bluetooth/hci_h4.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/bluetooth/hci_h4.c b/drivers/bluetooth/hci_h4.c
index fb97a3bf069b..fa30ec9cebd4 100644
--- a/drivers/bluetooth/hci_h4.c
+++ b/drivers/bluetooth/hci_h4.c
@@ -124,19 +124,22 @@ static const struct h4_recv_pkt h4_recv_pkts[] = {
 static int h4_recv(struct hci_uart *hu, const void *data, int count)
 {
struct h4_struct *h4 = hu->priv;
+   struct sk_buff *skb;
 
if (!test_bit(HCI_UART_REGISTERED, >flags))
return -EUNATCH;
 
-   h4->rx_skb = h4_recv_buf(hu->hdev, h4->rx_skb, data, count,
-h4_recv_pkts, ARRAY_SIZE(h4_recv_pkts));
-   if (IS_ERR(h4->rx_skb)) {
-   int err = PTR_ERR(h4->rx_skb);
+   skb = h4_recv_buf(hu->hdev, h4->rx_skb, data, count,
+ h4_recv_pkts, ARRAY_SIZE(h4_recv_pkts));
+   if (IS_ERR(skb)) {
+   int err = PTR_ERR(skb);
bt_dev_err(hu->hdev, "Frame reassembly failed (%d)", err);
h4->rx_skb = NULL;
return err;
}
 
+   h4->rx_skb = skb;
+
return count;
 }
 
-- 
2.17.1

[PATCH] fs/cachefiles/namei.c: Remove duplicate header

2019-01-10 Thread Sabyasachi Gupta

Remove linux/xattr.h which is included more than once

Signed-off-by: Sabyasachi Gupta 
---
 fs/cachefiles/namei.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/cachefiles/namei.c b/fs/cachefiles/namei.c
index 95983c7..edecb7f 100644
--- a/fs/cachefiles/namei.c
+++ b/fs/cachefiles/namei.c
@@ -20,7 +20,6 @@
 #include 
 #include 
 #include 
-#include 
 #include "internal.h"
 
 #define CACHEFILES_KEYBUF_SIZE 512
-- 
2.7.4

Re: [PATCH v2 1/4] tee: add bus driver framework for TEE based devices

On Thu, 10 Jan 2019 at 19:36, Daniel Thompson
 wrote:
>
> On Thu, Jan 10, 2019 at 05:54:54PM +0530, Sumit Garg wrote:
> > Introduce a generic TEE bus driver concept for TEE based kernel drivers
> > which would like to communicate with TEE based devices/services.
> >
> > In this TEE bus concept, devices/services are identified via Universally
> > Unique Identifier (UUID) and drivers register a table of device UUIDs
> > which they can support.
> >
> > So this TEE bus framework registers a match() callback function which
> > iterates over the driver UUID table to find a corresponding match for
> > device UUID. If a match is found, then this particular device is probed
> > via corresponding probe api registered by the driver. This process
> > happens whenever a device or a driver is registered with TEE bus.
> >
> > Also this framework allows for device enumeration to be specific to
> > corresponding TEE implementation like OP-TEE etc.
> >
> > Signed-off-by: Sumit Garg 
> > ---
> >  drivers/tee/tee_core.c  | 41 ++---
> >  include/linux/tee_drv.h | 36 
> >  2 files changed, 74 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
> > index 7b2bb4c..9ddb89e 100644
> > --- a/drivers/tee/tee_core.c
> > +++ b/drivers/tee/tee_core.c
> > @@ -15,7 +15,6 @@
> >  #define pr_fmt(fmt) "%s: " fmt, __func__
> >
> >  #include 
> > -#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -1027,6 +1026,30 @@ int tee_client_invoke_func(struct tee_context *ctx,
> >  }
> >  EXPORT_SYMBOL_GPL(tee_client_invoke_func);
> >
> > +static int tee_client_device_match(struct device *dev,
> > +struct device_driver *drv)
> > +{
> > + struct tee_client_device *tee_device;
> > + const struct tee_client_device_id *id_table;
> > +
> > + tee_device = to_tee_client_device(dev);
> > + id_table = to_tee_client_driver(drv)->id_table;
> > +
> > + while (!uuid_is_null(_table->uuid)) {
> > + if (uuid_equal(_device->id.uuid, _table->uuid))
> > + return 1;
> > + id_table++;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +struct bus_type tee_bus_type = {
> > + .name   = "tee",
> > + .match  = tee_client_device_match,
> > +};
> > +EXPORT_SYMBOL_GPL(tee_bus_type);
> > +
> >  static int __init tee_init(void)
> >  {
> >   int rc;
> > @@ -1040,10 +1063,21 @@ static int __init tee_init(void)
> >   rc = alloc_chrdev_region(_devt, 0, TEE_NUM_DEVICES, "tee");
> >   if (rc) {
> >   pr_err("failed to allocate char dev region\n");
> > - class_destroy(tee_class);
> > - tee_class = NULL;
> > + goto class_err;
> >   }
> >
> > + rc = bus_register(_bus_type);
> > + if (rc) {
> > + pr_err("failed to register tee bus\n");
> > + goto class_err;
>
> There is an unregister_chrdev_region() in tee_exit(). Why isn't it
> needed on this error path?
>

Will add "unregister_chrdev_region()" on this error path.

-Sumit

>
> > + }
> > +
> > + return 0;
> > +
> > +class_err:
> > + class_destroy(tee_class);
> > + tee_class = NULL;
> > +
> >   return rc;
> >  }
> >
> > @@ -1052,6 +1086,7 @@ static void __exit tee_exit(void)
> >   class_destroy(tee_class);
> >   tee_class = NULL;
> >   unregister_chrdev_region(tee_devt, TEE_NUM_DEVICES);
> > + bus_unregister(_bus_type);
> >  }
> >
> >  subsys_initcall(tee_init);
> > diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h
> > index 6cfe058..ed16bf1 100644
> > --- a/include/linux/tee_drv.h
> > +++ b/include/linux/tee_drv.h
> > @@ -20,6 +20,8 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >
> >  /*
> >   * The file describes the API provided by the generic TEE driver to the
> > @@ -538,4 +540,38 @@ static inline bool tee_param_is_memref(struct 
> > tee_param *param)
> >   }
> >  }
> >
> > +extern struct bus_type tee_bus_type;
> > +
> > +/**
> > + * struct tee_client_device_id - tee based device identifier
> > + * @uuid:For TEE based client devices we use the device uuid
> > + *   as the identifier.
> > + */
> > +struct tee_client_device_id {
> > + uuid_t uuid;
> > +};
> > +
> > +/**
> > + * struct tee_client_device - tee based device
> > + * @id:  device identifier
> > + * @dev: device structure
> > + */
> > +struct tee_client_device {
> > + struct tee_client_device_id id;
> > + struct device dev;
> > +};
> > +#define to_tee_client_device(d) container_of(d, struct tee_client_device, 
> > dev)
> > +
> > +/**
> > + * struct tee_client_driver - tee client driver
> > + * @id_table:device id table supported by this driver
> > + * @driver:  driver structure
> > + */
> > +struct tee_client_driver {
> > + const struct

Re: ufshcd_queuecommand() triggering after ufshcd_suspend()?

2019-01-10 Thread Avri Altman

+Zang

Thanks,
Avri




From: John Stultz 
Sent: Friday, January 11, 2019 1:02:21 AM
To: Sahitya Tummala; Christoph Hellwig; Wei Li; Martin K. Petersen
Cc: Evan Green; Avri Altman; Vijay Viswanath; lkml; linux-s...@vger.kernel.org
Subject: ufshcd_queuecommand() triggering after ufshcd_suspend()?

Hey all,
  Frequently, since support for the HiKey960's UFS code landed in
4.19, I've noticed the following warning on reboot:

[   23.086860] WARNING: CPU: 0 PID: 2507 at
drivers/scsi/ufs/ufshcd.c:2460 ufshcd_queuecommand+0x59c/0x5a8
[   23.096256] Modules linked in:
[   23.099313] CPU: 0 PID: 2507 Comm: kworker/0:1H Tainted: G S
5.0.0-rc1-00068-g3f81a19 #273
[   23.108873] Hardware name: HiKey960 (DT)
[   23.112802] Workqueue: kblockd blk_mq_requeue_work
[   23.117591] pstate: 8045 (Nzcv daif +PAN -UAO)
[   23.122378] pc : ufshcd_queuecommand+0x59c/0x5a8
[   23.126990] lr : ufshcd_queuecommand+0x58c/0x5a8
[   23.131600] sp : ff8015e1ba80
[   23.134907] x29: ff8015e1ba80 x28: ffc217f94048
[   23.140214] x27: 0010 x26: ffc217a7c8b8
[   23.145520] x25: ffc217a7c000 x24: ffc217a7ceb0
[   23.150827] x23:  x22: ffc217a7c808
[   23.156133] x21: ffc217f94120 x20: 0010
[   23.161440] x19: ff801186d000 x18: ff801186db08
[   23.166746] x17:  x16: 
[   23.172053] x15: ff8095e1b7c7 x14: 692064616574736e
[   23.177360] x13: 6928204e4f5f534b x12: 4c43203d21206574
[   23.182666] x11: 6174732e676e6974 x10: 61675f6b6c633e2d
[   23.187973] x9 : 61626820646e616d x8 : 6d6f636575657571
[   23.193280] x7 :  x6 : ff801186e000
[   23.198586] x5 : ff801186e270 x4 : ff8010096dc0
[   23.203894] x3 : 0001 x2 : 47dd99afde511d00
[   23.209201] x1 :  x0 : 
[   23.214509] Call trace:
[   23.216952]  ufshcd_queuecommand+0x59c/0x5a8
[   23.221220]  scsi_queue_rq+0x5b4/0x880
[   23.224964]  blk_mq_dispatch_rq_list+0xb0/0x510
[   23.229492]  blk_mq_sched_dispatch_requests+0xf4/0x198
[   23.234626]  __blk_mq_run_hw_queue+0xb4/0x120
[   23.238978]  __blk_mq_delay_run_hw_queue+0x110/0x200
[   23.243937]  blk_mq_run_hw_queue+0xb8/0x118
[   23.248114]  blk_mq_run_hw_queues+0x58/0x78
[   23.252291]  blk_mq_requeue_work+0x140/0x168
[   23.256560]  process_one_work+0x158/0x468
[   23.260564]  worker_thread+0x50/0x460
[   23.264222]  kthread+0x104/0x130
[   23.267447]  ret_from_fork+0x10/0x1c
[   23.271017] ---[ end trace 45f1ee04059cdf00 ]---

Since the warning is triggering from the WARN_ON(hba->clk_gating.state
!= CLKS_ON) line, I annotated the clk_gating.state changes, and am
seeing on reboot:
  vdc: Waited 0ms for vold
  sd 0:0:0:3: [sdd] Synchronizing SCSI cache
  sd 0:0:0:2: [sdc] Synchronizing SCSI cache
  sd 0:0:0:1: [sdb] Synchronizing SCSI cache
  sd 0:0:0:0: [sda] Synchronizing SCSI cache
  ufshcd_suspend: setting clk_gating.state CLKS_OFF
  ufshcd_queuecommand hba->clk_gating.state != CLKS_ON (instead its 0)


So it seems like ufshcd_suspend() is has run, but then the workqueue
(occasionally) fires afterwards triggering the issue.

Maybe should something in ufshcd_queuecommand be checking the
clk_gating.is_suspended flag before proceeding?

Other ideas?  The logic all seems to be in the generic code, but I'm
not sure if maybe the ufs-hisi.c code is mis-managing something?

thanks
-john

RE: [PATCH 1/2] ahci: qoriq: add lx2160 platforms support

2019-01-10 Thread Peng Ma



>-Original Message-
>From: Leo Li
>Sent: 2019年1月11日 4:30
>To: Peng Ma ; shawn...@kernel.org; ax...@kernel.dk
>Cc: robh...@kernel.org; mark.rutl...@arm.com;
>linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
>linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; Andy Tang
>
>Subject: RE: [PATCH 1/2] ahci: qoriq: add lx2160 platforms support
>
>
>
>> -Original Message-
>> From: Peng Ma
>> Sent: Thursday, January 10, 2019 4:32 AM
>> To: Peng Ma ; shawn...@kernel.org; ax...@kernel.dk
>> Cc: Leo Li ; robh...@kernel.org;
>> mark.rutl...@arm.com; linux-arm-ker...@lists.infradead.org;
>> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
>> i...@vger.kernel.org; Andy Tang 
>> Subject: RE: [PATCH 1/2] ahci: qoriq: add lx2160 platforms support
>>
>> Hi Jens，
>>
>>  I send the sata patchs to the upstream patchwork with
>> ./scripts/get_maintainer.pl, but I find my patch on
>> http://patchwork.ozlabs.org/project/linux-ide/list/ , I saw the
>> MAINTAINERS, the driver/ata/* should be on
>> https://patchwork.kernel.org/project/linux-
>> block/list/ . could you please help me what the patchwork is right.
>
>Peng,
>
>The patchwork used is related to the mailing list which you send the patch to
>not the maintainer's git tree used.  Since the MAINTAINERS file says
>drivers/ata should use linux-ide mailing list, patches will appear in linux-ide
>patchwork.
>
>Regards,
>Leo
>
[Peng Ma] got it, thanks.
Best Regards,
Peng
>>  Thanks a lot.
>>
>> Best Regards,
>> Peng
>>
>> >-Original Message-
>> >From: Peng Ma 
>> >Sent: 2019年1月10日 18:06
>> >To: shawn...@kernel.org; ax...@kernel.dk
>> >Cc: Leo Li ; robh...@kernel.org;
>> >mark.rutl...@arm.com; linux-arm-ker...@lists.infradead.org;
>> >devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
>> >linux-...@vger.kernel.org; Peng Ma 
>> >Subject: [PATCH 1/2] ahci: qoriq: add lx2160 platforms support
>> >
>> >Lx2160a is a new introduced soc which supports ATA3.0 and Clean up
>> >some code
>> >
>> >Signed-off-by: Peng Ma 
>> >---
>> > drivers/ata/ahci_qoriq.c |   44 
>> > 
>> > 1 files changed, 12 insertions(+), 32 deletions(-)
>> >
>> >diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
>> >index
>> >ce59253..1994bf2 100644
>> >--- a/drivers/ata/ahci_qoriq.c
>> >+++ b/drivers/ata/ahci_qoriq.c
>> >@@ -57,7 +57,7 @@ enum ahci_qoriq_type {
>> >AHCI_LS2080A,
>> >AHCI_LS1046A,
>> >AHCI_LS1088A,
>> >-   AHCI_LS2088A,
>> >+   AHCI_LX2160A,
>> > };
>> >
>> > struct ahci_qoriq_priv {
>> >@@ -73,7 +73,7 @@ struct ahci_qoriq_priv {
>> >{ .compatible = "fsl,ls2080a-ahci", .data = (void *)AHCI_LS2080A},
>> >{ .compatible = "fsl,ls1046a-ahci", .data = (void *)AHCI_LS1046A},
>> >{ .compatible = "fsl,ls1088a-ahci", .data = (void *)AHCI_LS1088A},
>> >-   { .compatible = "fsl,ls2088a-ahci", .data = (void *)AHCI_LS2088A},
>> >+   { .compatible = "fsl,lx2160a-ahci", .data = (void *)AHCI_LX2160A},
>> >{},
>> > };
>> > MODULE_DEVICE_TABLE(of, ahci_qoriq_of_match); @@ -174,12 +174,10
>> @@
>> >static int ahci_qoriq_phy_init(struct ahci_host_priv *hpriv)
>> >writel(LS1021A_PORT_PHY4, reg_base + PORT_PHY4);
>> >writel(LS1021A_PORT_PHY5, reg_base + PORT_PHY5);
>> >writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
>> >-   if (qpriv->is_dmacoherent)
>> >-   writel(AHCI_PORT_AXICC_CFG,
>> >-   reg_base + LS1021A_AXICC_ADDR);
>> >break;
>> >
>> >case AHCI_LS1043A:
>> >+   case AHCI_LS1046A:
>> >if (!qpriv->ecc_addr)
>> >return -EINVAL;
>> >writel(readl(qpriv->ecc_addr) | ECC_DIS_ARMV8_CH2, @@ -
>> 188,8
>> >+186,6 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv
>> >+*hpriv)
>> >writel(AHCI_PORT_PHY2_CFG, reg_base + PORT_PHY2);
>> >writel(AHCI_PORT_PHY3_CFG, reg_base + PORT_PHY3);
>> >writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
>> >-   if (qpriv->is_dmacoherent)
>> >-   writel(AHCI_PORT_AXICC_CFG, reg_base +
>> PORT_AXICC);
>> >break;
>> >
>> >case AHCI_LS2080A:
>> >@@ -197,24 +193,10 @@ static int ahci_qoriq_phy_init(struct
>> >ahci_host_priv
>> >*hpriv)
>> >writel(AHCI_PORT_PHY2_CFG, reg_base + PORT_PHY2);
>> >writel(AHCI_PORT_PHY3_CFG, reg_base + PORT_PHY3);
>> >writel(AHCI_PORT_TRANS_CFG, reg_base + PORT_TRANS);
>> >-   if (qpriv->is_dmacoherent)
>> >-   writel(AHCI_PORT_AXICC_CFG, reg_base +
>> PORT_AXICC);
>> >-   break;
>> >-
>> >-   case AHCI_LS1046A:
>> >-   if (!qpriv->ecc_addr)
>> >-   return -EINVAL;
>> >-   writel(readl(qpriv->ecc_addr) | ECC_DIS_ARMV8_CH2,
>> >-   qpriv->ecc_addr);
>> >-   writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
>> >-

Re: [PATCH 3/4] crypto: hisilicon: Add HiSilicon ZIP accelerator support

2019-01-10 Thread Zhou Wang

On 2019/1/11 14:08, Herbert Xu wrote:
> On Sat, Dec 22, 2018 at 03:51:44PM +0800, Zhou Wang wrote:
>>
>> +static struct crypto_alg hisi_zip_zlib = {
>> +.cra_name   = "zlib-deflate",
>> +.cra_flags  = CRYPTO_ALG_TYPE_COMPRESS,
>> +.cra_ctxsize= sizeof(struct hisi_zip_ctx),
>> +.cra_priority   = 300,
>> +.cra_module = THIS_MODULE,
>> +.cra_init   = hisi_zip_alloc_comp_ctx,
>> +.cra_exit   = hisi_zip_free_comp_ctx,
>> +.cra_u  = {
>> +.compress = {
>> +.coa_compress   = hisi_zip_compress,
>> +.coa_decompress = hisi_zip_decompress
>> +}
>> +}
>> +};
> 
> Please do not add any new implementations using the compress
> interface.  You should either use scomp or acomp depending on
> whether your driver is synchronous or async.

OK, current this driver only supports synchronous interface.
Will fix it in v2.

Thanks,
Zhou

> 
> Thanks,
>

Re: [Tee-dev] [PATCH v2 4/4] hwrng: add OP-TEE based rng driver

On Thu, 10 Jan 2019 at 19:26, Joakim Bech  wrote:
>
> On Thu, Jan 10, 2019 at 05:54:57PM +0530, Sumit Garg wrote:
> > On ARM SoC's with TrustZone enabled, peripherals like entropy sources
> > might not be accessible to normal world (linux in this case) and rather
> > accessible to secure world (OP-TEE in this case) only. So this driver
> > aims to provides a generic interface to OP-TEE based random number
> > generator service.
> >
> > This driver registers on TEE bus to interact with OP-TEE based rng
> >
> > device/service.
> >
> > Signed-off-by: Sumit Garg 
> > ---
> >  MAINTAINERS|   5 +
> >  drivers/char/hw_random/Kconfig |  15 ++
> >  drivers/char/hw_random/Makefile|   1 +
> >  drivers/char/hw_random/optee-rng.c | 272 
> > +
> >  4 files changed, 293 insertions(+)
> >  create mode 100644 drivers/char/hw_random/optee-rng.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 32d7..502733c 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -11260,6 +11260,11 @@ M:   Jens Wiklander 
> >  S:   Maintained
> >  F:   drivers/tee/optee/
> >
> > +OP-TEE RANDOM NUMBER GENERATOR (RNG) DRIVER
> > +M:   Sumit Garg 
> > +S:   Maintained
> > +F:   drivers/char/hw_random/optee-rng.c
> > +
> >  OPA-VNIC DRIVER
> >  M:   Dennis Dalessandro 
> >  M:   Niranjana Vishwanathapura 
> > diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
> > index dac895d..25a7d8f 100644
> > --- a/drivers/char/hw_random/Kconfig
> > +++ b/drivers/char/hw_random/Kconfig
> > @@ -424,6 +424,21 @@ config HW_RANDOM_EXYNOS
> > will be called exynos-trng.
> >
> > If unsure, say Y.
> > +
> > +config HW_RANDOM_OPTEE
> > + tristate "OP-TEE based Random Number Generator support"
> > + depends on OPTEE
> > + default HW_RANDOM
> > + help
> > +   This  driver provides support for OP-TEE based Random Number
> > +   Generator on ARM SoCs where hardware entropy sources are not
> > +   accessible to normal world (Linux).
> > +
> > +   To compile this driver as a module, choose M here: the module
> > +   will be called optee-rng.
> > +
> > +   If unsure, say Y.
> > +
> >  endif # HW_RANDOM
> >
> >  config UML_RANDOM
> > diff --git a/drivers/char/hw_random/Makefile 
> > b/drivers/char/hw_random/Makefile
> > index e35ec3c..7c9ef4a 100644
> > --- a/drivers/char/hw_random/Makefile
> > +++ b/drivers/char/hw_random/Makefile
> > @@ -38,3 +38,4 @@ obj-$(CONFIG_HW_RANDOM_CAVIUM) += cavium-rng.o 
> > cavium-rng-vf.o
> >  obj-$(CONFIG_HW_RANDOM_MTK)  += mtk-rng.o
> >  obj-$(CONFIG_HW_RANDOM_S390) += s390-trng.o
> >  obj-$(CONFIG_HW_RANDOM_KEYSTONE) += ks-sa-rng.o
> > +obj-$(CONFIG_HW_RANDOM_OPTEE) += optee-rng.o
> > diff --git a/drivers/char/hw_random/optee-rng.c 
> > b/drivers/char/hw_random/optee-rng.c
> > new file mode 100644
> > index 000..ebfe1f2c
> > --- /dev/null
> > +++ b/drivers/char/hw_random/optee-rng.c
> > @@ -0,0 +1,272 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2018-2019 Linaro Ltd.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define DRIVER_NAME "optee-rng"
> > +
> > +#define TEE_ERROR_HEALTH_TEST_FAIL   0x0001
> > +
> > +/*
> > + * TA_CMD_GET_ENTROPY - Get Entropy from RNG
> > + *
> > + * param[0] (inout memref) - Entropy buffer memory reference
> > + * param[1] unused
> > + * param[2] unused
> > + * param[3] unused
> > + *
> > + * Result:
> > + * TEE_SUCCESS - Invoke command success
> > + * TEE_ERROR_BAD_PARAMETERS - Incorrect input param
> > + * TEE_ERROR_NOT_SUPPORTED - Requested entropy size greater than size of 
> > pool
> > + * TEE_ERROR_HEALTH_TEST_FAIL - Continuous health testing failed
> > + */
> > +#define TA_CMD_GET_ENTROPY   0x0
> > +
> > +/*
> > + * TA_CMD_GET_RNG_INFO - Get RNG information
> > + *
> > + * param[0] (out value) - value.a: RNG data-rate in bytes per second
> > + *value.b: Quality/Entropy per 1024 bit of data
> > + * param[1] unused
> > + * param[2] unused
> > + * param[3] unused
> > + *
> > + * Result:
> > + * TEE_SUCCESS - Invoke command success
> > + * TEE_ERROR_BAD_PARAMETERS - Incorrect input param
> > + */
> > +#define TA_CMD_GET_RNG_INFO  0x1
> > +
> > +#define MAX_ENTROPY_REQ_SZ   (4 * 1024)
> > +
> > +static struct tee_context *ctx;
> > +static struct tee_shm *entropy_shm_pool;
> > +static u32 ta_rng_data_rate;
> > +static u32 ta_rng_session_id;
> > +
> > +static size_t get_optee_rng_data(void *buf, size_t req_size)
> > +{
> > + u32 ret = 0;
> > + u8 *rng_data = NULL;
> > + size_t rng_size = 0;
> > + struct tee_ioctl_invoke_arg inv_arg = {0};
> > + struct tee_param param[4] = {0};
> > +
> > + /* Invoke TA_CMD_GET_RNG function of Trusted App */
> >
> TA_CMD_GET_ENTROPY?
>

Will correct.

> > + inv_arg.func = TA_CMD_GET_ENTROPY;
> > +

RE: [PATCH 11/41] scsi: bfa: bfa_fcs_rport: Mark expected switch fall-throughs

2019-01-10 Thread Sudarsana Reddy Kalluru


-Original Message-
From: Gustavo A. R. Silva [mailto:gust...@embeddedor.com] 
Sent: 11 January 2019 01:42
To: Anil Gurumurthy ; Sudarsana Kalluru 

Cc: James E.J. Bottomley ; Martin K. Petersen 
; linux-s...@vger.kernel.org; 
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 11/41] scsi: bfa: bfa_fcs_rport: Mark expected switch 
fall-throughs

External Email

Hi,

Friendly ping (second one):

Who can ack/review/take this patch, please?

Thanks
--
Gustavo

On 12/19/18 9:39 AM, Gustavo A. R. Silva wrote:
> Hi,
>
> Friendly ping:
>
> Who can ack or review this patch, please?
>
> Thanks
> --
> Gustavo
>
> On 11/27/18 10:27 PM, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases 
>> where we are expecting to fall through.
>>
>> Notice that I replaced "!! fall through !!" and "!!! fall through !!!"
>> comments with "fall through" annotations, which is what GCC is 
>> expecting to find.
>>
>> Addresses-Coverity-ID: 744899 ("Missing break in switch")
>> Addresses-Coverity-ID: 744900 ("Missing break in switch")
>> Addresses-Coverity-ID: 744901 ("Missing break in switch")
>> Signed-off-by: Gustavo A. R. Silva 
>> ---
>>   drivers/scsi/bfa/bfa_fcs_rport.c | 19 +++
>>   1 file changed, 7 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/scsi/bfa/bfa_fcs_rport.c 
>> b/drivers/scsi/bfa/bfa_fcs_rport.c
>> index de50349a39ce..1e400f2aaece 100644
>> --- a/drivers/scsi/bfa/bfa_fcs_rport.c
>> +++ b/drivers/scsi/bfa/bfa_fcs_rport.c
>> @@ -427,17 +427,13 @@ bfa_fcs_rport_sm_plogi(struct bfa_fcs_rport_s *rport, 
>> enum rport_event event)
>>   case RPSM_EVENT_LOGO_RCVD:
>>   bfa_fcs_rport_send_logo_acc(rport);
>> -/*
>> - * !! fall through !!
>> - */
>> +/* fall through */
>>   case RPSM_EVENT_PRLO_RCVD:
>>   if (rport->prlo == BFA_TRUE)
>>   bfa_fcs_rport_send_prlo_acc(rport);
>>   bfa_fcxp_discard(rport->fcxp);
>> -/*
>> - * !! fall through !!
>> - */
>> +/* fall through */
>>   case RPSM_EVENT_FAILED:
>>   if (rport->plogi_retries < BFA_FCS_RPORT_MAX_RETRIES) {
>>   rport->plogi_retries++; @@ -868,9 +864,7 @@ 
>> bfa_fcs_rport_sm_adisc_online(struct bfa_fcs_rport_s *rport,
>>* At least go offline when a PLOGI is received.
>>*/
>>   bfa_fcxp_discard(rport->fcxp);
>> -/*
>> - * !!! fall through !!!
>> - */
>> +/* fall through */
>>   case RPSM_EVENT_FAILED:
>>   case RPSM_EVENT_ADDRESS_CHANGE:
>> @@ -1056,6 +1050,7 @@ bfa_fcs_rport_sm_fc4_logosend(struct bfa_fcs_rport_s 
>> *rport,
>>   case RPSM_EVENT_LOGO_RCVD:
>>   bfa_fcs_rport_send_logo_acc(rport);
>> +/* fall through */
>>   case RPSM_EVENT_PRLO_RCVD:
>>   if (rport->prlo == BFA_TRUE)
>>   bfa_fcs_rport_send_prlo_acc(rport);
>> @@ -1144,9 +1139,7 @@ bfa_fcs_rport_sm_hcb_offline(struct bfa_fcs_rport_s 
>> *rport,
>>   bfa_fcs_rport_send_plogiacc(rport, NULL);
>>   break;
>>   }
>> -/*
>> - * !! fall through !!
>> - */
>> +/* fall through */
>>   case RPSM_EVENT_ADDRESS_CHANGE:
>>   if (!bfa_fcs_lport_is_online(rport->port)) { @@ -1303,6 
>> +1296,7 @@ bfa_fcs_rport_sm_hcb_logosend(struct bfa_fcs_rport_s *rport,
>>   case RPSM_EVENT_LOGO_RCVD:
>>   bfa_fcs_rport_send_logo_acc(rport);
>> +/* fall through */
>>   case RPSM_EVENT_PRLO_RCVD:
>>   if (rport->prlo == BFA_TRUE)
>>   bfa_fcs_rport_send_prlo_acc(rport);
>> @@ -1346,6 +1340,7 @@ bfa_fcs_rport_sm_logo_sending(struct bfa_fcs_rport_s 
>> *rport,
>>   case RPSM_EVENT_LOGO_RCVD:
>>   bfa_fcs_rport_send_logo_acc(rport);
>> +/* fall through */
>>   case RPSM_EVENT_PRLO_RCVD:
>>   if (rport->prlo == BFA_TRUE)
>>   bfa_fcs_rport_send_prlo_acc(rport);
>>

Acked-by: Sudarsana Kalluru

RE: [PATCH 12/41] scsi: bfa: bfa_ioc: Mark expected switch fall-throughs

2019-01-10 Thread Sudarsana Reddy Kalluru



-Original Message-
From: Gustavo A. R. Silva [mailto:gust...@embeddedor.com] 
Sent: 11 January 2019 01:41
To: Anil Gurumurthy ; Sudarsana Kalluru 

Cc: James E.J. Bottomley ; Martin K. Petersen 
; linux-s...@vger.kernel.org; 
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 12/41] scsi: bfa: bfa_ioc: Mark expected switch 
fall-throughs

External Email

Hi,

Friendly ping (second one):

Who can ack/review/take this patch, please?

Thanks
--
Gustavo

On 12/19/18 9:39 AM, Gustavo A. R. Silva wrote:
> Hi,
>
> Friendly ping:
>
> Who can ack or review this patch, please?
>
> Thanks
> --
> Gustavo
>
> On 11/27/18 10:27 PM, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases 
>> where we are expecting to fall through.
>>
>> Notice that, in this particular case, I replaced "!!! fall through !!!"
>> comment with "fall through" annotations, which is what GCC is 
>> expecting to find.
>>
>> Addresses-Coverity-ID: 146155 ("Missing break in switch")
>> Signed-off-by: Gustavo A. R. Silva 
>> ---
>>   drivers/scsi/bfa/bfa_ioc.c | 9 +++--
>>   1 file changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/scsi/bfa/bfa_ioc.c b/drivers/scsi/bfa/bfa_ioc.c 
>> index 16d3aeb0e572..32b24e51cce6 100644
>> --- a/drivers/scsi/bfa/bfa_ioc.c
>> +++ b/drivers/scsi/bfa/bfa_ioc.c
>> @@ -978,9 +978,7 @@ bfa_iocpf_sm_enabling(struct bfa_iocpf_s *iocpf, enum 
>> iocpf_event event)
>>   case IOCPF_E_INITFAIL:
>>   bfa_iocpf_timer_stop(ioc);
>> -/*
>> - * !!! fall through !!!
>> - */
>> +/* fall through */
>>   case IOCPF_E_TIMEOUT:
>>   writel(1, ioc->ioc_regs.ioc_sem_reg); @@ -1056,9 +1054,7 @@ 
>> bfa_iocpf_sm_disabling(struct bfa_iocpf_s *iocpf, enum iocpf_event event)
>>   case IOCPF_E_FAIL:
>>   bfa_iocpf_timer_stop(ioc);
>> -/*
>> - * !!! fall through !!!
>> - */
>> +/* fall through */
>>   case IOCPF_E_TIMEOUT:
>>   bfa_ioc_set_cur_ioc_fwstate(ioc, BFI_IOC_FAIL); @@ -6007,6 
>> +6003,7 @@ bfa_dconf_sm_final_sync(struct bfa_dconf_mod_s *dconf,
>>   case BFA_DCONF_SM_IOCDISABLE:
>>   case BFA_DCONF_SM_FLASH_COMP:
>>   bfa_timer_stop(>timer);
>> +/* fall through */
>>   case BFA_DCONF_SM_TIMEOUT:
>>   bfa_sm_set_state(dconf, bfa_dconf_sm_uninit);
>>   bfa_fsm_send_event(>bfa->iocfc, IOCFC_E_DCONF_DONE);
>>

Acked-by: Sudarsana Kalluru

RE: [PATCH 10/41] scsi: bfa: bfa_fcs_lport: Mark expected switch fall-throughs

2019-01-10 Thread Sudarsana Reddy Kalluru


-Original Message-
From: Gustavo A. R. Silva [mailto:gust...@embeddedor.com] 
Sent: 11 January 2019 01:42
To: Anil Gurumurthy ; Sudarsana Kalluru 

Cc: James E.J. Bottomley ; Martin K. Petersen 
; linux-s...@vger.kernel.org; 
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 10/41] scsi: bfa: bfa_fcs_lport: Mark expected switch 
fall-throughs

External Email

Hi,

Friendly ping (second one):

Who can ack/review/take this patch, please?

Thanks
--
Gustavo

On 12/19/18 9:39 AM, Gustavo A. R. Silva wrote:
> Hi,
>
> Friendly ping:
>
> Who can ack or review this patch, please?
>
> Thanks
> --
> Gustavo
>
> On 11/27/18 10:27 PM, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases 
>> where we are expecting to fall through.
>>
>> Notice that, in this particular case, I replaced "!!! fall through !!!"
>> with a "fall through" annotation, which is what GCC is expecting to 
>> find.
>>
>> Signed-off-by: Gustavo A. R. Silva 
>> ---
>>   drivers/scsi/bfa/bfa_fcs_lport.c | 8 ++--
>>   1 file changed, 2 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/scsi/bfa/bfa_fcs_lport.c 
>> b/drivers/scsi/bfa/bfa_fcs_lport.c
>> index b4f2c1d8742e..646f09f66443 100644
>> --- a/drivers/scsi/bfa/bfa_fcs_lport.c
>> +++ b/drivers/scsi/bfa/bfa_fcs_lport.c
>> @@ -6430,9 +6430,7 @@ bfa_fcs_vport_sm_logo_for_stop(struct bfa_fcs_vport_s 
>> *vport,
>>   switch (event) {
>>   case BFA_FCS_VPORT_SM_OFFLINE:
>>   bfa_sm_send_event(vport->lps, BFA_LPS_SM_OFFLINE);
>> -/*
>> - * !!! fall through !!!
>> - */
>> +/* fall through */
>>   case BFA_FCS_VPORT_SM_RSP_OK:
>>   case BFA_FCS_VPORT_SM_RSP_ERROR:
>> @@ -6458,9 +6456,7 @@ bfa_fcs_vport_sm_logo(struct bfa_fcs_vport_s *vport,
>>   switch (event) {
>>   case BFA_FCS_VPORT_SM_OFFLINE:
>>   bfa_sm_send_event(vport->lps, BFA_LPS_SM_OFFLINE);
>> -/*
>> - * !!! fall through !!!
>> - */
>> +/* fall through */
>>   case BFA_FCS_VPORT_SM_RSP_OK:
>>   case BFA_FCS_VPORT_SM_RSP_ERROR:
>>

Acked-by: Sudarsana Kalluru

Re: [PATCH -next] crypto: chelsio - check set_msg_len overflow in generate_b0

2019-01-10 Thread Herbert Xu

On Fri, Dec 28, 2018 at 02:41:00PM +0800, YueHaibing wrote:
> set_msg_len may fails with -EOVERFLOW, It should be propagate
> to upstream.
> 
> Fixes: 2debd3325e55 ("crypto: chcr - Add AEAD algos.")
> Signed-off-by: YueHaibing 
> ---
>  drivers/crypto/chelsio/chcr_algo.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Fwd: [PATCH 4/7] CIFS: Do not hide EINTR after sending network packets

Pavel's patch looks correct to me, but since this may be a common
issue, how to better handle unexpected EINTR on sock_sendmsg, others
outside cifs/smb3 world may have run into this before and have
additional comments.

-- Forwarded message -
From: Pavel Shilovsky 
Date: Thu, Jan 10, 2019 at 4:25 PM
Subject: [PATCH 4/7] CIFS: Do not hide EINTR after sending network packets
To: 
Cc: Steve French , Ronnie Sahlberg 

Currently we hide EINTR code returned from sock_sendmsg()
and return 0 instead. This makes a caller think that we
have successfully completed the network operation which is
not true. Fix this by properly returning EINTR to callers.

Cc: 
Signed-off-by: Pavel Shilovsky 
---
 fs/cifs/transport.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/cifs/transport.c b/fs/cifs/transport.c
index e047f06..aaff9c5 100644
--- a/fs/cifs/transport.c
+++ b/fs/cifs/transport.c
@@ -387,7 +387,7 @@ __smb_send_rqst(struct TCP_Server_Info *server,
int num_rqst,
if (rc < 0 && rc != -EINTR)
cifs_dbg(VFS, "Error %d sending data on socket to server\n",
 rc);
-   else
+   else if (rc > 0)
rc = 0;

return rc;
--
2.7.4

-- 
Thanks,

Steve

Re: linux-next: Signed-off-by missing for commit in the net tree

2019-01-10 Thread Frank Wunderlich

Should i make v3 with all tags or me as author?

Regards Frank

Re: [PATCH RESEND] crypto: caam - move shared symbols in a common location

2019-01-10 Thread Herbert Xu

On Thu, Jan 10, 2019 at 03:58:12PM +0200, Horia Geantă wrote:
> There are several issues with symbols shared b/w:
> -caam/jr and caam/qi drivers on one hand
> -caam/qi2 driver on the other hand
> 
> Commit 52813ab24959 ("crypto: caam/qi2 - avoid double export") fixed
> some of them, however compilation still fails for CRYPTO_DEV_FSL_CAAM=m
> and CRYPTO_DEV_FSL_DPAA2_CAAM=y.
> 
> Another issue is related to dependency cycles reported by depmod when
> CRYPTO_DEV_FSL_CAAM=n and CRYPTO_DEV_FSL_DPAA2_CAAM=m, as mentioned in
> 82c7b351be3f ("Revert "arm64: defconfig: Enable FSL_MC_BUS and FSL_MC_DPIO"")
> 
> To fix all these, move the symbols shared by these drivers in a common
> location. The only existing possibility is error.c file (note that naming
> doesn't help and should probably change).
> 
> Fixes: 52813ab24959 ("crypto: caam/qi2 - avoid double export")
> Reported-by: Arnd Bergmann 
> Signed-off-by: Horia Geantă 
> ---
> 
> Resending to fix patchwork tracking.
> Initial submission done inline here:
> https://patchwork.kernel.org/patch/10739071/
> 
>  drivers/crypto/caam/caamalg_qi2.c | 7 ---
>  drivers/crypto/caam/ctrl.c| 4 
>  drivers/crypto/caam/error.c   | 6 ++
>  3 files changed, 6 insertions(+), 11 deletions(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v2 1/5] fs: kernfs: add poll file operation

2019-01-10 Thread Greg KH

On Thu, Jan 10, 2019 at 02:07:14PM -0800, Suren Baghdasaryan wrote:
> From: Johannes Weiner 
> 
> Kernfs has a standardized poll/notification mechanism for waking all
> pollers on all fds when a filesystem node changes. To allow polling
> for custom events, add a .poll callback that can override the default.
> 
> This is in preparation for pollable cgroup pressure files which have
> per-fd trigger configurations.
> 
> Signed-off-by: Johannes Weiner 
> Signed-off-by: Suren Baghdasaryan 

Reviewed-by: Greg Kroah-Hartman

Fwd: [PATCH 7/7] CIFS: Fix error paths in writeback code

These changes in writepage and writepages for cifs remind me of
loosely related writeback changes that Jeff and Brian have done in the
VFS/MM layer, so was hopeful that others might have comments if they
see anything missing from Pavel's patch.

-- Forwarded message -
From: Pavel Shilovsky 
Date: Thu, Jan 10, 2019 at 4:25 PM
Subject: [PATCH 7/7] CIFS: Fix error paths in writeback code
To: 
Cc: Steve French , Ronnie Sahlberg 


This patch aims to address writeback code problems related to error
paths. In particular it respects EINTR and related error codes and
stores the first error occured during writeback in order to return it
to a caller.

Signed-off-by: Pavel Shilovsky 
---
 fs/cifs/cifsglob.h | 19 +++
 fs/cifs/cifssmb.c  |  7 ---
 fs/cifs/file.c | 29 +++--
 fs/cifs/inode.c| 10 ++
 4 files changed, 56 insertions(+), 9 deletions(-)

diff --git a/fs/cifs/cifsglob.h b/fs/cifs/cifsglob.h
index 7709268..94dbdbe 100644
--- a/fs/cifs/cifsglob.h
+++ b/fs/cifs/cifsglob.h
@@ -1575,6 +1575,25 @@ static inline void free_dfs_info_array(struct
dfs_info3_param *param,
kfree(param);
 }

+static inline bool is_interrupt_error(int error)
+{
+   switch (error) {
+   case -EINTR:
+   case -ERESTARTSYS:
+   case -ERESTARTNOHAND:
+   case -ERESTARTNOINTR:
+   return true;
+   }
+   return false;
+}
+
+static inline bool is_retryable_error(int error)
+{
+   if (is_interrupt_error(error) || error == -EAGAIN)
+   return true;
+   return false;
+}
+
 #define   MID_FREE 0
 #define   MID_REQUEST_ALLOCATED 1
 #define   MID_REQUEST_SUBMITTED 2
diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c
index b1f49c1..6930cdb 100644
--- a/fs/cifs/cifssmb.c
+++ b/fs/cifs/cifssmb.c
@@ -2114,7 +2114,7 @@ cifs_writev_requeue(struct cifs_writedata *wdata)

for (j = 0; j < nr_pages; j++) {
unlock_page(wdata2->pages[j]);
-   if (rc != 0 && rc != -EAGAIN) {
+   if (rc != 0 && !is_retryable_error(rc)) {
SetPageError(wdata2->pages[j]);
end_page_writeback(wdata2->pages[j]);
put_page(wdata2->pages[j]);
@@ -2123,7 +2123,7 @@ cifs_writev_requeue(struct cifs_writedata *wdata)

if (rc) {
kref_put(>refcount, cifs_writedata_release);
-   if (rc == -EAGAIN)
+   if (is_retryable_error(rc))
continue;
break;
}
@@ -2132,7 +2132,8 @@ cifs_writev_requeue(struct cifs_writedata *wdata)
i += nr_pages;
} while (i < wdata->nr_pages);

-   mapping_set_error(inode->i_mapping, rc);
+   if (rc != 0 && !is_retryable_error(rc))
+   mapping_set_error(inode->i_mapping, rc);
kref_put(>refcount, cifs_writedata_release);
 }

diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index c23bf9d..109b1ef 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -732,7 +732,8 @@ cifs_reopen_file(struct cifsFileInfo *cfile, bool can_flush)

if (can_flush) {
rc = filemap_write_and_wait(inode->i_mapping);
-   mapping_set_error(inode->i_mapping, rc);
+   if (!is_interrupt_error(rc))
+   mapping_set_error(inode->i_mapping, rc);

if (tcon->unix_ext)
rc = cifs_get_inode_info_unix(, full_path,
@@ -2109,6 +2110,7 @@ static int cifs_writepages(struct address_space *mapping,
pgoff_t end, index;
struct cifs_writedata *wdata;
int rc = 0;
+   int saved_rc = 0;
unsigned int xid;

/*
@@ -2137,8 +2139,10 @@ static int cifs_writepages(struct address_space *mapping,

rc = server->ops->wait_mtu_credits(server, cifs_sb->wsize,
   , );
-   if (rc)
+   if (rc != 0) {
+   done = true;
break;
+   }

tofind = min((wsize / PAGE_SIZE) - 1, end - index) + 1;

@@ -2146,6 +2150,7 @@ static int cifs_writepages(struct address_space *mapping,
  _pages);
if (!wdata) {
rc = -ENOMEM;
+   done = true;
add_credits_and_wake_if(server, credits, 0);
break;
}
@@ -2174,7 +2179,7 @@ static int cifs_writepages(struct address_space *mapping,
if (rc != 0) {
add_credits_and_wake_if(server, wdata->credits, 0);
for (i = 0; i < nr_pages; ++i) {
-   if (rc == -EAGAIN)
+   if (is_retryable_error(rc))

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

2019-01-10 Thread Kash Pande

On 2019-01-10 9:40 p.m., Greg Kroah-Hartman wrote:
> Sorry, no, we do not keep symbols exported for no in-kernel users.
>
> greg k-h


Hi Greg,


Can you please address the email that Lukas was responding to?


Thanks.




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v5 2/6] media: sun6i: Add mod_rate quirk

2019-01-10 Thread Jagan Teki

On Mon, Jan 7, 2019 at 6:59 PM Maxime Ripard  wrote:
>
> On Mon, Dec 24, 2018 at 08:57:48PM +0530, Jagan Teki wrote:
> > On Fri, Dec 21, 2018 at 6:30 PM Maxime Ripard  
> > wrote:
> > >
> > > On Thu, Dec 20, 2018 at 06:24:34PM +0530, Jagan Teki wrote:
> > > > Unfortunately default CSI_SCLK rate cannot work properly to
> > > > drive the connected sensor interface, particularly on few
> > > > Allwinner SoC's like A64.
> > > >
> > > > So, add mod_rate quirk via driver data so-that the respective
> > > > SoC's which require to alter the default mod clock rate can assign
> > > > the operating clock rate.
> > > >
> > > > Signed-off-by: Jagan Teki 
> > > > ---
> > > >  .../platform/sunxi/sun6i-csi/sun6i_csi.c  | 34 +++
> > > >  1 file changed, 28 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c 
> > > > b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > > > index ee882b66a5ea..fe002beae09c 100644
> > > > --- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > > > +++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > > > @@ -15,6 +15,7 @@
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > @@ -28,8 +29,13 @@
> > > >
> > > >  #define MODULE_NAME  "sun6i-csi"
> > > >
> > > > +struct sun6i_csi_variant {
> > > > + unsigned long   mod_rate;
> > > > +};
> > > > +
> > > >  struct sun6i_csi_dev {
> > > >   struct sun6i_csicsi;
> > > > + const struct sun6i_csi_variant  *variant;
> > > >   struct device   *dev;
> > > >
> > > >   struct regmap   *regmap;
> > > > @@ -822,33 +828,43 @@ static int sun6i_csi_resource_request(struct 
> > > > sun6i_csi_dev *sdev,
> > > >   return PTR_ERR(sdev->clk_mod);
> > > >   }
> > > >
> > > > + if (sdev->variant->mod_rate)
> > > > + clk_set_rate_exclusive(sdev->clk_mod, 
> > > > sdev->variant->mod_rate);
> > > > +
> > >
> > > It still doesn't make any sense to do it in the probe function...
> >
> > I'm not sure we discussed about the context wrt probe, we discussed
> > about exclusive put clock.
>
> https://lkml.org/lkml/2018/12/18/584
>
> "Doing it here is not really optimal either, since you'll put a
> constraint on the system (maintaining that clock at 300MHz), while
> it's not in use."

But this constraint is only set, for SoC's who need mod_rate change
not for whole SoCs.

>
> > Since clocks were enabling in set_power and clock rate can be set
> > during probe in single time instead of setting it in set_power for
> > every power enablement. anything wrong with that.
>
> See above.
>
> Plus, a clock running draws power. It doesn't really make sense to
> draw power for something that is unused.

True, but clock is enabled only on sun6i_csi_set_power so setting
clock frequency in probe will draw power?
(sorry same message sent accidentally)

>
> > > We discussed this in the previous iteration already.
> > >
> > > What we didn't discuss is the variant function that you introduce,
> > > while the previous approach was enough.
> >
> > We discussed about clk_rate_exclusive_put, and that even handle it in
> > .remove right? so I have variant to handle it in sun6i_csi_remove.
>
> We indeed discussed the clk_rate_exclusive_put. However, you chose to
> implement it using a variant structure which really isn't needed.

Because clk_rate_exclusive_put will also do it .remove so adding
driver variant with mod_rate can do this job easily. do you have any
suggestion?

[PATCH V2 1/3] dt-bindings: fsl: add imx7ulp system integration module binding

Add i.MX7ULP system integration module (SIM) binding.

Signed-off-by: Anson Huang 
---
 .../bindings/arm/freescale/fsl,imx7ulp-sim.txt   | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-sim.txt

diff --git 
a/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-sim.txt 
b/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-sim.txt
new file mode 100644
index 000..7d0c7f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-sim.txt
@@ -0,0 +1,16 @@
+Freescale i.MX7ULP System Integration Module
+--
+The system integration module (SIM) provides system control and chip 
configuration
+registers. In this module, chip revision information is located in JTAG ID 
register,
+and a set of registers have been made available in DGO domain for SW use, with 
the
+objective to maintain its value between system resets.
+
+Required properties:
+- compatible:  Should be "fsl,imx7ulp-sim".
+- reg: Specifies base physical address and size of the register sets.
+
+Example:
+sim: sim@410a3000 {
+   compatible = "fsl,imx7ulp-sim", "syscon";
+   reg = <0x410a3000 0x1000>;
+};
-- 
2.7.4

[PATCH V2 2/3] ARM: imx: add i.MX7ULP SoC revision support

i.MX7ULP SoC's revision info is inside the SIM module,
bit[31:28] of JTAG_ID register defines revision as below
from B0:

0001B0
0010B1

This patch adds SoC revision support for i.MX7ULP, test
result as below:

root@imx7ulp-evk ~$ cat /sys/devices/soc0/revision
2.1

Signed-off-by: Anson Huang 
---
 arch/arm/mach-imx/mach-imx7ulp.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/mach-imx/mach-imx7ulp.c b/arch/arm/mach-imx/mach-imx7ulp.c
index 19c5b30..11ac71a 100644
--- a/arch/arm/mach-imx/mach-imx7ulp.c
+++ b/arch/arm/mach-imx/mach-imx7ulp.c
@@ -6,18 +6,57 @@
  */
 
 #include 
+#include 
 #include 
+#include 
 #include 
 
 #include "common.h"
 #include "cpuidle.h"
 #include "hardware.h"
 
+#define SIM_JTAG_ID_REG0x8c
+
+static void __init imx7ulp_set_revision(void)
+{
+   struct regmap *sim;
+   u32 revision;
+
+   sim = syscon_regmap_lookup_by_compatible("fsl,imx7ulp-sim");
+   if (IS_ERR(sim)) {
+   pr_warn("failed to find fsl,imx7ulp-sim regmap!\n");
+   return;
+   }
+
+   if (regmap_read(sim, SIM_JTAG_ID_REG, )) {
+   pr_warn("failed to read sim regmap!\n");
+   return;
+   }
+
+   /*
+* bit[31:28] of JTAG_ID register defines revision as below from B0:
+* 0001B0
+* 0010B1
+*/
+   switch (revision >> 28) {
+   case 1:
+   imx_set_soc_revision(IMX_CHIP_REVISION_2_0);
+   break;
+   case 2:
+   imx_set_soc_revision(IMX_CHIP_REVISION_2_1);
+   break;
+   default:
+   imx_set_soc_revision(IMX_CHIP_REVISION_1_0);
+   break;
+   }
+}
+
 static void __init imx7ulp_init_machine(void)
 {
imx7ulp_pm_init();
 
mxc_set_cpu_type(MXC_CPU_IMX7ULP);
+   imx7ulp_set_revision();
of_platform_default_populate(NULL, NULL, imx_soc_device_init());
 }
 
-- 
2.7.4

[PATCH V2 3/3] ARM: dts: imx7ulp: add sim node

i.MX7ULP SoC revision info is inside the SIM mode's JTAG_ID
register, add sim node to support SoC revision check.

Signed-off-by: Anson Huang 
---
 arch/arm/boot/dts/imx7ulp.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/imx7ulp.dtsi b/arch/arm/boot/dts/imx7ulp.dtsi
index b86daf7..fca6e50 100644
--- a/arch/arm/boot/dts/imx7ulp.dtsi
+++ b/arch/arm/boot/dts/imx7ulp.dtsi
@@ -347,4 +347,17 @@
gpio-ranges = < 0 96 32>;
};
};
+
+   m4aips1: bus@4108 {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x4108 0x8>;
+   ranges;
+
+   sim: sim@410a3000 {
+   compatible = "fsl,imx7ulp-sim", "syscon";
+   reg = <0x410a3000 0x1000>;
+   };
+   };
 };
-- 
2.7.4

Fwd: [PATCH 0/7] SMB3 credit flow control handling and writeback fixes

This is an important series, addressing various problems with
crediting (flow control) but more importantly patches 4 and 7 deal
with error cases in writeback, in writepages and writepage which may
be of more general interest. Brian and Jeff have changed loosely
related code in the VFS and may have insight into whether additional
changes would be helpful beyond what Pavel has done in patches 4 and 7
in this series.

-- Forwarded message -
From: Pavel Shilovsky 
Date: Thu, Jan 10, 2019 at 4:25 PM
Subject: [PATCH 0/7] SMB3 credit flow control handling and writeback fixes
To: 
Cc: Steve French , Ronnie Sahlberg 


This is the series of patches that address few problems with the current code.

Patch #1 adjusts credits properly for MTU credits if we didn't use all the
credits taken for an operation. This prevents loosing credits in error paths.

Patch #2 removes resetting credit number to 1 if server didn't grant us
any credits for the compounding chain. The current code didn't follow
the protocol correctly.

Patch #3 fixes credits handling for compounded requests by taking
one credit per part of the chain. All error paths that return credits
back are fixed accordingly.

Patch #4 fixes hiding EINTR error code returned after an interrupted attemp
to send SMB packet through the network.

Patch #5 removes wrong assumption that the server grants us one credit
for a cancelled request and parse the actual response to get the credit
number.

Patch #6 moves process credits granted by the server in the demultiplex
thread in order to avoid races with reconnects.

Patch #7 addresses few problems in writeback code, in particular related
to interrupted error code returned by the transport layer.

Patches #1-4 as marked for stable. Reviews are welcome.

Pavel Shilovsky (7):
  CIFS: Fix adjustment of credits for MTU requests
  CIFS: Do not set credits to 1 if the server didn't grant anything
  CIFS: Fix credit computation for compounded requests
  CIFS: Do not hide EINTR while sending network packets
  CIFS: Fix credits calculation for cancelled requests
  CIFS: Move credit processing to mid callbacks for SMB3
  CIFS: Fix error paths in writeback code

 fs/cifs/cifsglob.h  |  20 +
 fs/cifs/cifssmb.c   |   7 +--
 fs/cifs/file.c  |  29 ++---
 fs/cifs/inode.c |  10 +
 fs/cifs/smb2pdu.c   |   8 +++-
 fs/cifs/transport.c | 122 +++-
 6 files changed, 155 insertions(+), 41 deletions(-)

--
2.7.4



-- 
Thanks,

Steve

Re: [PATCH 1/3] riscv: Introduce huge page support for 32/64bit kernel

2019-01-10 Thread Paul Walmsley

Hello Alexandre,

On Mon, 10 Dec 2018, Alexandre Ghiti wrote:

> This patch implements both 4MB huge page support for 32bit kernel
> and 2MB/1GB huge pages support for 64bit kernel.
> 
> Signed-off-by: Alexandre Ghiti 

This patch introduces a few minor checkpatch and strict checkpatch 
warnings, when tested against both v4.20 and v5.0-rc1 checkpatch versions.  
Could you fix those?  The other two patches in the series look OK from 
that point of view.

- Paul

Re:[PATCH] 8250_pci.c: Only check for communication class in serial_pci_guess_board

2019-01-10 Thread Guan Yung Tseng

On Thu, Jan 10, 2019 at 04:12:12PM +0800, Guan Yung Tseng wrote:
> Some multiport serial cards, such as the NI PXI-8430/2, NI PXI-8430/8,
> and NI PXI-8432/4 use PCI_CLASS_COMMUNICATION_OTHER and this fail the
> serial_pci_is_class_communication test added in the commit 7d8905d06405
> ("serial: 8250_pci: Enable device after we check black list").
> 
> Since these devices are correctly listed in serial_pci_tbl, we
> shouldn't need to check the PCI class IDs. This change relocates the
> class checking solely into "serial_pci_guess_board" where it had been
> before so that the class-check doesn't hinder initialization.
> 
> Signed-off-by: Guan Yung Tseng 
> ---
>  drivers/tty/serial/8250/8250_pci.c | 28 +---
>  1 file changed, 9 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_pci.c 
> b/drivers/tty/serial/8250/8250_pci.c
> index 4986b4a..e33a869 100644
> --- a/drivers/tty/serial/8250/8250_pci.c
> +++ b/drivers/tty/serial/8250/8250_pci.c
> @@ -3382,21 +3382,6 @@ static const struct pci_device_id blacklist[] = {
>   { PCI_VDEVICE(COMMTECH, PCI_ANY_ID), },
>  };
>  
> -static int serial_pci_is_class_communication(struct pci_dev *dev)
> -{
> - /*
> -  * If it is not a communications device or the programming
> -  * interface is greater than 6, give up.
> -  */
> - if dev->class >> 8) != PCI_CLASS_COMMUNICATION_SERIAL) &&
> -  ((dev->class >> 8) != PCI_CLASS_COMMUNICATION_MULTISERIAL) &&
> -  ((dev->class >> 8) != PCI_CLASS_COMMUNICATION_MODEM)) ||
> - (dev->class & 0xff) > 6)
> - return -ENODEV;
> -
> - return 0;
> -}

>
> Noted.
>

Please leave this as a function, no need to move it inside another
function at this point in time.


>  static int serial_pci_is_blacklisted(struct pci_dev *dev)
>  {
>   const struct pci_device_id *bldev;
> @@ -3427,6 +3412,15 @@ serial_pci_guess_board(struct pci_dev *dev, struct 
> pciserial_board *board)
>   int num_iomem, num_port, first_port = -1, i;
>  
>   /*
> +  * If it is not a communications device or the programming
> +  * interface is greater than 6, give up.
> +  *
> +  */
> + if dev->class >> 8) != PCI_CLASS_COMMUNICATION_SERIAL) &&
> +  ((dev->class >> 8) != PCI_CLASS_COMMUNICATION_MODEM)) ||
> + (dev->class & 0xff) > 6)
> + return -ENODEV;
> + /*

>
> It was my mistake. I should not remove it.
> I will fix them and submit another patch.
>

what happened to the multiserial check?

You should just call the function here.

thanks,

greg k-h

Fwd: scp bug due to progress indicator when copying from remote to local on Linux

-- Forwarded message -
From: Steve French 
Date: Fri, Jan 11, 2019 at 12:11 AM
Subject: scp bug due to progress indicator when copying from remote to
local on Linux
To: CIFS , linux-fsdevel

Cc: CIFS , Pavel Shilovsky 

In discussing an interesting problem with scp recently with Pavel, we
found a fairly obvious bug in scp when it is run with a progress
indicator (which is the default when the source file is remote).

scp triggers "SIGALRM" probably from update_progress_meter() in
progressmeter.c when executed with "scp localhost:somelargefile /mnt"
ie with an ssh source path but a local path for the target, as long as
the flush of the large amount of cached data to disk (which seems to
be triggered by the ftruncate call in scp.c) takes more than a few
seconds (which can be common depending on disk or network speed).

It is interesting that this can be avoided easily by running in quiet
mode ("-q") which disables the progress meter in scp, but it seems
very, very broken that scp of a large file can 'fail' when using a
progress meter (unless caching were disabled on the file system) due
to the slight delay in ftruncate due to triggering a flush of a large
amount of cached data to disk sequentially.

Any thoughts of whether scp is actively maintained and best approach
to fix progressmeter.c so it doesn't break on Linux?

--
Thanks,

Steve

-- 
Thanks,

Steve

Re: [PATCHv2 1/7] x86/mm: concentrate the code to memblock allocator enabled

2019-01-10 Thread Chao Fan

On Fri, Jan 11, 2019 at 01:12:51PM +0800, Pingfan Liu wrote:
>This patch identifies the point where memblock alloc start. It has no
>functional.
[...]
>+#ifdef CONFIG_MEMORY_HOTPLUG
>+  /*
>+   * Memory used by the kernel cannot be hot-removed because Linux
>+   * cannot migrate the kernel pages. When memory hotplug is
>+   * enabled, we should prevent memblock from allocating memory
>+   * for the kernel.
>+   *
>+   * ACPI SRAT records all hotpluggable memory ranges. But before
>+   * SRAT is parsed, we don't know about it.
>+   *
>+   * The kernel image is loaded into memory at very early time. We
>+   * cannot prevent this anyway. So on NUMA system, we set any
>+   * node the kernel resides in as un-hotpluggable.
>+   *
>+   * Since on modern servers, one node could have double-digit
>+   * gigabytes memory, we can assume the memory around the kernel
>+   * image is also un-hotpluggable. So before SRAT is parsed, just
>+   * allocate memory near the kernel image to try the best to keep
>+   * the kernel away from hotpluggable memory.
>+   */
>+  if (movable_node_is_enabled())
>+  memblock_set_bottom_up(true);

Hi Pingfan,

In my understanding, 'movable_node' is based on the that memory near
kernel is considered as in the same node as kernel in high possibility.

If SRAT has been parsed early, do we still need the kernel parameter
'movable_node'? Since you have got the memory information about hot-remove,
so I wonder if it's OK to drop 'movable_node', and if memory-hotremove is
enabled, change memblock allocation according to SRAT.

If there is something wrong in my understanding, please let me know.

Thanks,
Chao Fan

>+#endif
>   init_mem_mapping();
>+  memblock_set_current_limit(get_max_mapped());
> 
>   idt_setup_early_pf();
> 
>@@ -1145,8 +1145,6 @@ void __init setup_arch(char **cmdline_p)
>*/
>   mmu_cr4_features = __read_cr4() & ~X86_CR4_PCIDE;
> 
>-  memblock_set_current_limit(get_max_mapped());
>-
>   /*
>* NOTE: On x86-32, only from this point on, fixmaps are ready for use.
>*/
>-- 
>2.7.4
>
>
>

Re: linux-next: Signed-off-by missing for commit in the net tree

2019-01-10 Thread Heiner Kallweit

On 11.01.2019 04:48, Stephen Rothwell wrote:
> Hi all,
> 
> Commit
> 
>   b19bce0335e2 ("net: ethernet: mediatek: fix warning in phy_start_aneg")
> 
> is missing a Signed-off-by from its author.
> 
I suggested the changes and Frank prepared the patch with me as author.
Therefore:

Suggested-by: Heiner Kallweit 
Signed-off-by: Frank Wunderlich

Re: [PATCH 1/2] dma-mapping: zero memory returned from dma_alloc_*

2019-01-10 Thread Greg Ungerer

Hi Christoph,

On 17/12/18 9:59 pm, Christoph Hellwig wrote:

On Sat, Dec 15, 2018 at 12:14:29AM +1000, Greg Ungerer wrote:

Yep, that is right. Certainly the MMU case is broken. Some noMMU cases work
by virtue of the SoC only having an instruction cache (the older V2 cores).

Is there a good an easy case to detect if a core has a cache? Either
runtime or in Kconfig?

The MMU case is fixable, but I think it will mean changing away from
the fall-back virtual:physical 1:1 mapping it uses for the kernel address
space. So not completely trivial. Either that or a dedicated area of RAM
for coherent allocations that we can mark as non-cachable via the really
course grained and limited ACR registers - not really very appealing.

What about CF_PAGE_NOCACHE? Reading arch/m68k/include/asm/mcf_pgtable.h
suggest this would cause an uncached mapping, in which case something
like this should work:

http://git.infradead.org/users/hch/misc.git/commitdiff/4b8711d436e8d56edbc5ca19aa2be639705bbfef

No, that won't work.

The current MMU setup for ColdFire relies on a quirk of the cache
control subsystem to map kernel mapping (actually all of RAM when
accessed in supervisor mode).

The effective address calculation by the CPU/MMU firstly checks
the RAMBAR access, then

From the ColdFire 5475 Reference Manual (section 5.5.1):

If virtual mode is enabled, any normal mode access that does not hit in the
MMUBAR,
RAMBARs, ROMBARs, or ACRs is considered a normal mode virtual address request
and
generates its access attributes from the MMU. For this case, the default CACR
address attributes
are not used.

The MMUBAR is the MMU control registers, the RAMBAR/ROMBAR are the
internal static RAM/ROM regions and the ACR are the cache control
registers. The code in arch/m68k/coldfire/head.S sets up the ACR
registers so that all of RAM is accessible and cached when in supervisor
mode. So kernel code and data accesses will hit this and use the
address for access. User pages won't hit this and will go through to
hit the MMU mappings.

The net out is we don't need page mappings or use TLB entries
for kernel code/data. The problem is we also can't map individual
regions as not cached for coherent allocations... The ACR mapping
means all-or-nothing.

This leads back to what I mentioned earlier about changing the
VM mapping to not use the ACR mapping method and actually page
mapping the kernel space. Not completely trivial and I expect
there will be a performance hit with the extra TLB pressure and
their setup/remapping overhead.

The noMMU case in general is probably limited to something like that same
type of dedicated RAM/ACR register mechamism.

The most commonly used periperal with DMA is the FEC ethernet module,
and it has some "special" (used very loosely) cache flushing for
parts like the 532x family which probably makes it mostly work right.
There is a PCI bus on the 54xx family of parts, and I know general
ethernet cards on it (like e1000's) have problems I am sure are
related to the fact that coherent memory allocations aren't.

If we really just care about FEC we can just switch it do use
DMA_ATTR_NON_CONSISTENT and do explicit cache flushing. But as far
as I can tell FEC only uses DMA coherent allocations for the TSO
headers anyway, is TSO even used on this SOC?

The FEC is the most commonly used, but not the only. I test generic PCI
NICs on the PCI bus on the ColdFire 5475 - and a lot of those drivers
rely on coherent allocations.

Regards
Greg

Re: [PATCH 3/4] crypto: hisilicon: Add HiSilicon ZIP accelerator support

2019-01-10 Thread Herbert Xu

On Sat, Dec 22, 2018 at 03:51:44PM +0800, Zhou Wang wrote:
>
> +static struct crypto_alg hisi_zip_zlib = {
> + .cra_name   = "zlib-deflate",
> + .cra_flags  = CRYPTO_ALG_TYPE_COMPRESS,
> + .cra_ctxsize= sizeof(struct hisi_zip_ctx),
> + .cra_priority   = 300,
> + .cra_module = THIS_MODULE,
> + .cra_init   = hisi_zip_alloc_comp_ctx,
> + .cra_exit   = hisi_zip_free_comp_ctx,
> + .cra_u  = {
> + .compress = {
> + .coa_compress   = hisi_zip_compress,
> + .coa_decompress = hisi_zip_decompress
> + }
> + }
> +};

Please do not add any new implementations using the compress
interface.  You should either use scomp or acomp depending on
whether your driver is synchronous or async.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v11 10/15] tracing: Add alternative synthetic event trace action syntax

2019-01-10 Thread Namhyung Kim

On Wed, Jan 09, 2019 at 01:49:17PM -0600, Tom Zanussi wrote:
> From: Tom Zanussi 
> 
> Add a 'trace(synthetic_event_name, params)' alternative to
> synthetic_event_name(params).
> 
> Currently, the syntax used for generating synthetic events is to
> invoke synthetic_event_name(params) i.e. use the synthetic event name
> as a function call.
> 
> Users requested a new form that more explicitly shows that the
> synthetic event is in effect being traced.  In this version, a new
> 'trace()' keyword is used, and the synthetic event name is passed in
> as the first argument.
> 
> Signed-off-by: Tom Zanussi 
> ---
>  Documentation/trace/histogram.rst | 21 
>  kernel/trace/trace.c  |  1 +
>  kernel/trace/trace_events_hist.c  | 42 
> +++
>  3 files changed, 60 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/trace/histogram.rst 
> b/Documentation/trace/histogram.rst
> index 79476c906b1a..4939bad1c1cd 100644
> --- a/Documentation/trace/histogram.rst
> +++ b/Documentation/trace/histogram.rst
> @@ -1874,6 +1874,7 @@ The available handlers are:
>  The available actions are:
>  
>- (param list) - generate synthetic event
> +  - trace(,(param list)) - generate synthetic event

Shouldn't it be

"trace(,param list)"

?  Otherwise it looks like we need two parentheses.

IMHO, it seems better for consistency using this new syntax only.
Of course it should support the old syntax as well for compatibility
(and maybe make it undocumented?).  But I won't insist strongly..


>- save(field,...)- save current event fields
>- snapshot() - snapshot the trace buffer
>  
> @@ -1881,6 +1882,10 @@ The following commonly-used handler.action pairs are 
> available:
>  
>- onmatch(matching.event).(param list)
>  
> +or
> +
> +  - onmatch(matching.event).trace(,(param list))
> +

Ditto.


>  The 'onmatch(matching.event).(params)' hist
>  trigger action is invoked whenever an event matches and the
>  histogram entry would be added or updated.  It causes the named
> @@ -1889,6 +1894,16 @@ The following commonly-used handler.action pairs are 
> available:
>  that consists of the values contained in those variables at the
>  time the invoking event was hit.
>  
> +There are two equivalent forms available for generating synthetic
> +events.  In the first form, the synthetic event name is used as if
> +it were a function name.  For example, if the synthetic event name
> +is 'wakeup_latency', the wakeup_latency event would be generated
> +by invoking it as if it were a function call, with the event field
> +values passed in as arguments: wakeup_latency(arg1,arg2).  The
> +second form simply uses the 'trace' keyword as the function name
> +and passes in the synthetic event name as the first argument,
> +followed by the field values: trace(wakeup_latency,arg1,arg2).
> +
>  The 'param list' consists of one or more parameters which may be
>  either variables or fields defined on either the 'matching.event'
>  or the target event.  The variables or fields specified in the
> @@ -1928,6 +1943,12 @@ The following commonly-used handler.action pairs are 
> available:
>wakeup_new_test($testpid) if comm=="cyclictest"' >> \
>/sys/kernel/debug/tracing/events/sched/sched_wakeup_new/trigger
>  
> +Or, equivalently, using the 'trace' keyword syntax:
> +
> +# echo 'hist:keys=$testpid:testpid=pid:onmatch(sched.sched_wakeup_new).\
> +trace(wakeup_new_test,$testpid) if comm=="cyclictest"' >> \
> +/sys/kernel/debug/tracing/events/sched/sched_wakeup_new/trigger
> +
>  Creating and displaying a histogram based on those events is now
>  just a matter of using the fields and new synthetic event in the
>  tracing/events/synthetic directory, as usual::
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 917677a9bcaa..aae0e4127afc 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -4900,6 +4900,7 @@ static const char readme_msg[] =
>   "\tonchange(var)- invoke action if var changes\n\n"
>   "\tThe available actions are:\n\n"
>   "\t(param list)- generate synthetic 
> event\n"
> + "\ttrace(,(param list))- generate synthetic 
> event\n"

Ditto.

Thanks,
Namhyung


>   "\tsave(field,...)  - save current event 
> fields\n"
>   "\tsnapshot()   - snapshot the trace 
> buffer\n"
>  #endif

Re: [PATCH v2] RISC-V: defconfig: Enable Generic PCIE by default

2019-01-10 Thread Paul Walmsley

Hi Alistair,

Looks like you're still sending patches to "palmpalmer" ?

On Thu, 10 Jan 2019, Alistair Francis wrote:

> Enable generic PCIe by default in the RISC-V defconfig, this allows us
> to use QEMU's PCIe support out of the box.
>
> Signed-off-by: Alistair Francis 
> ---
>  arch/riscv/configs/defconfig | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
> index f399659d3b8d..ccfd3f05223c 100644
> --- a/arch/riscv/configs/defconfig
> +++ b/arch/riscv/configs/defconfig
> @@ -14,6 +14,8 @@ CONFIG_EXPERT=y
>  CONFIG_BPF_SYSCALL=y
>  CONFIG_SMP=y
>  CONFIG_PCI=y
> +CONFIG_PCIEPORTBUS=y
> +CONFIG_PCI_HOST_GENERIC=y
>  CONFIG_PCIE_XILINX=y
>  CONFIG_MODULES=y
>  CONFIG_MODULE_UNLOAD=y
> @@ -77,5 +79,6 @@ CONFIG_NFS_V4_1=y
>  CONFIG_NFS_V4_2=y
>  CONFIG_ROOT_NFS=y
>  CONFIG_CRYPTO_USER_API_HASH=y
> +CONFIG_CRYPTO_DEV_VIRTIO=y
>  CONFIG_PRINTK_TIME=y
>  # CONFIG_RCU_TRACE is not set

Not sure what commit this patch is against - I picked v5.0-rc1.  Before 
applying your patch, I generated a seedconfig with "make defconfig 
savedefconfig; mv defconfig defconfig.1".  Then applied your patch and did 
a "make defconfig savedefconfig" and then ran "diff -u defconfig.1 
defconfig".

That should have shown me just the patch above.  But it also included a 
line removing CONFIG_RAS=y.  I am sorry to ask you to fix such a nitpicky 
item, but it is good practice for these defconfig patches.  Otherwise the 
defconfig deltas gradually get out of control.

When you repost it, if you verify that the ./defconfig delta from running 
"make savedefconfig" before and after your patch applied is simply your 
patch, then feel free to add a Reviewed-by: line from my E-mail address 
above.

- Paul

Re: Kconfig label updates

2019-01-10 Thread Michael Ellerman

Tyrel Datwyler  writes:
> On 01/09/2019 04:37 AM, Michael Ellerman wrote:
>> Bjorn Helgaas  writes:
>>> I want to update the PCI Kconfig labels so they're more consistent and
>>> useful to users, something like the patch below.  IIUC, the items
>>> below are all IBM-related; please correct me if not.
>>>
>>> I'd also like to expand (or remove) "RPA" because Google doesn't find
>>> anything about "IBM RPA", except Robotic Process Automation, which I
>>> think must be something else.
>> 
>> Yeah I think just remove it, it's not a well known term and is unlikely
>> to help anyone these days.
>> 
>> It stands for "RISC Platform Architecture", which was some kind of
>> specification for Power machines back in the day, but from what I can
>> tell it was never used in marketing or manuals much (hence so few hits
>> on Google).
>
> It is basically the predecessor to PAPR "Power Architecture Platform 
> Reference".
> Which the LoPAPR document is available through power.org. Not sure if there is
> any desire to adopt PAPR in place of RPA. It is the platform reference doc 
> that
> outlines how we do DLPAR and PCI Hotplug.

True. But a user is unlikely to know "PAPR" either, and it googles badly.

LoPAPR I guess is better, you can google for it, though I'm not entirely
sure if everything used by this code is actually in LoPAPR, because some
bits of PAPR were ripped out of LoPAPR.

>>> Ideally the PCI Kconfig labels would match the terms used in
>>> arch/.../Kconfig, e.g.,
>>>
>>>   config PPC_POWERNV
>>> bool "IBM PowerNV (Non-Virtualized) platform support"
>>>
>>>   config PPC_PSERIES
>>> bool "IBM pSeries & new (POWER5-based) iSeries"
>> 
>> TBH these are pretty unhelpful too. PowerNV is not a marketing name and
>> so doesn't appear anywhere much in official manuals or brochures and
>> it's also used on non-IBM branded machines. And pSeries & iSeries were
>> marketing names but are no longer used.
>
> pseries is still used as a machine type for PAPR compliant qemu/kvm instances.

Yeah so I guess it's helpful for someone configuring a kernel with that
in mind.

But if you've bought an IBM branded system the "pseries" name is not
used anywhere AFAIK.

cheers

Re: [PATCH v5 2/6] media: sun6i: Add mod_rate quirk

2019-01-10 Thread Jagan Teki

On Mon, Jan 7, 2019 at 6:59 PM Maxime Ripard  wrote:
>
> On Mon, Dec 24, 2018 at 08:57:48PM +0530, Jagan Teki wrote:
> > On Fri, Dec 21, 2018 at 6:30 PM Maxime Ripard  
> > wrote:
> > >
> > > On Thu, Dec 20, 2018 at 06:24:34PM +0530, Jagan Teki wrote:
> > > > Unfortunately default CSI_SCLK rate cannot work properly to
> > > > drive the connected sensor interface, particularly on few
> > > > Allwinner SoC's like A64.
> > > >
> > > > So, add mod_rate quirk via driver data so-that the respective
> > > > SoC's which require to alter the default mod clock rate can assign
> > > > the operating clock rate.
> > > >
> > > > Signed-off-by: Jagan Teki 
> > > > ---
> > > >  .../platform/sunxi/sun6i-csi/sun6i_csi.c  | 34 +++
> > > >  1 file changed, 28 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c 
> > > > b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > > > index ee882b66a5ea..fe002beae09c 100644
> > > > --- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > > > +++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
> > > > @@ -15,6 +15,7 @@
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > @@ -28,8 +29,13 @@
> > > >
> > > >  #define MODULE_NAME  "sun6i-csi"
> > > >
> > > > +struct sun6i_csi_variant {
> > > > + unsigned long   mod_rate;
> > > > +};
> > > > +
> > > >  struct sun6i_csi_dev {
> > > >   struct sun6i_csicsi;
> > > > + const struct sun6i_csi_variant  *variant;
> > > >   struct device   *dev;
> > > >
> > > >   struct regmap   *regmap;
> > > > @@ -822,33 +828,43 @@ static int sun6i_csi_resource_request(struct 
> > > > sun6i_csi_dev *sdev,
> > > >   return PTR_ERR(sdev->clk_mod);
> > > >   }
> > > >
> > > > + if (sdev->variant->mod_rate)
> > > > + clk_set_rate_exclusive(sdev->clk_mod, 
> > > > sdev->variant->mod_rate);
> > > > +
> > >
> > > It still doesn't make any sense to do it in the probe function...
> >
> > I'm not sure we discussed about the context wrt probe, we discussed
> > about exclusive put clock.
>
> https://lkml.org/lkml/2018/12/18/584
>
> "Doing it here is not really optimal either, since you'll put a
> constraint on the system (maintaining that clock at 300MHz), while
> it's not in use."
>
> > Since clocks were enabling in set_power and clock rate can be set
> > during probe in single time instead of setting it in set_power for
> > every power enablement. anything wrong with that.
>
> See above.
>
> Plus, a clock running draws power. It doesn't really make sense to
> draw power for something that is unused.

True, but clock is enabled only on sun6i_csi_set_power so setting
clock frequency in probe will draw power?

[PATCH] usb: dwc3: gadget: Fail request submission if it was already queued

2019-01-10 Thread Manu Gautam

If a function driver tries to re-submit an already queued request,
it can results in corruption of pending/started request lists.
Catch such conditions and fail the request submission to DCD.

Signed-off-by: Manu Gautam 
---
 drivers/usb/dwc3/gadget.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 679c12e14522..51716c6b286a 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1290,6 +1290,12 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep *dep, 
struct dwc3_request *req)
>request, req->dep->name))
return -EINVAL;
 
+   if (req->request.status == -EINPROGRESS) {
+   dev_err(dwc->dev, "%s: %pK request already in queue\n",
+   dep->name, req);
+   return -EBUSY;
+   }
+
pm_runtime_get(dwc->dev);
 
req->request.actual = 0;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH V2] ARM: imx: add i.MX7ULP cpuidle support

This patch adds cpuidle support for i.MX7ULP, 3 cpuidle
states supported as below:

1. WFI, just ARM wfi;
2. WAIT mode, mapped to SoC's partial stop mode #3;
3. STOP mode, mapped to SoC's partial stop mode #1.

In WAIT mode, system clock and bus clock will be enabled;
In STOP mode, system clock and bus clock will be disabled.

Signed-off-by: Anson Huang 
---
ChangeLog Since V1:
  - add prefix for power mode name;
  - use tab instead of spaces, sorry for this stupid mistake.
---
 arch/arm/mach-imx/Makefile  |  1 +
 arch/arm/mach-imx/common.h  | 10 +++
 arch/arm/mach-imx/cpuidle-imx7ulp.c | 60 +
 arch/arm/mach-imx/cpuidle.h |  5 
 arch/arm/mach-imx/mach-imx7ulp.c|  7 +
 arch/arm/mach-imx/pm-imx7ulp.c  | 49 ++
 6 files changed, 127 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm/mach-imx/cpuidle-imx7ulp.c

diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 8af2f7e..12aa44a 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_SOC_IMX6SL) += cpuidle-imx6sl.o
 obj-$(CONFIG_SOC_IMX6SLL) += cpuidle-imx6sx.o
 obj-$(CONFIG_SOC_IMX6SX) += cpuidle-imx6sx.o
 obj-$(CONFIG_SOC_IMX6UL) += cpuidle-imx6sx.o
+obj-$(CONFIG_SOC_IMX7ULP) += cpuidle-imx7ulp.o
 endif
 
 ifdef CONFIG_SND_IMX_SOC
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index bc915e5..c51764a 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -72,6 +72,15 @@ enum mxc_cpu_pwr_mode {
STOP_POWER_OFF, /* STOP + SRPG */
 };
 
+enum ulp_cpu_pwr_mode {
+   ULP_PM_HSRUN,/* High speed run mode */
+   ULP_PM_RUN,  /* Run mode */
+   ULP_PM_WAIT, /* Wait mode */
+   ULP_PM_STOP, /* Stop mode */
+   ULP_PM_VLPS, /* Very low power stop mode */
+   ULP_PM_VLLS, /* very low leakage stop mode */
+};
+
 void imx_enable_cpu(int cpu, bool enable);
 void imx_set_cpu_jump(int cpu, void *jump_addr);
 u32 imx_get_cpu_arg(int cpu);
@@ -98,6 +107,7 @@ int imx6_set_lpm(enum mxc_cpu_pwr_mode mode);
 void imx6_set_int_mem_clk_lpm(bool enable);
 void imx6sl_set_wait_clk(bool enter);
 int imx_mmdc_get_ddr_type(void);
+int imx7ulp_set_lpm(enum ulp_cpu_pwr_mode mode);
 
 void imx_cpu_die(unsigned int cpu);
 int imx_cpu_kill(unsigned int cpu);
diff --git a/arch/arm/mach-imx/cpuidle-imx7ulp.c 
b/arch/arm/mach-imx/cpuidle-imx7ulp.c
new file mode 100644
index 000..ca86c96
--- /dev/null
+++ b/arch/arm/mach-imx/cpuidle-imx7ulp.c
@@ -0,0 +1,60 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017-2018 NXP
+ *   Anson Huang 
+ */
+
+#include 
+#include 
+#include 
+
+#include "common.h"
+#include "cpuidle.h"
+
+static int imx7ulp_enter_wait(struct cpuidle_device *dev,
+   struct cpuidle_driver *drv, int index)
+{
+   if (index == 1)
+   imx7ulp_set_lpm(ULP_PM_WAIT);
+   else
+   imx7ulp_set_lpm(ULP_PM_STOP);
+
+   cpu_do_idle();
+
+   imx7ulp_set_lpm(ULP_PM_RUN);
+
+   return index;
+}
+
+static struct cpuidle_driver imx7ulp_cpuidle_driver = {
+   .name = "imx7ulp_cpuidle",
+   .owner = THIS_MODULE,
+   .states = {
+   /* WFI */
+   ARM_CPUIDLE_WFI_STATE,
+   /* WAIT */
+   {
+   .exit_latency = 50,
+   .target_residency = 75,
+   .enter = imx7ulp_enter_wait,
+   .name = "WAIT",
+   .desc = "PSTOP2",
+   },
+   /* STOP */
+   {
+   .exit_latency = 100,
+   .target_residency = 150,
+   .enter = imx7ulp_enter_wait,
+   .name = "STOP",
+   .desc = "PSTOP1",
+   },
+   },
+   .state_count = 3,
+   .safe_state_index = 0,
+};
+
+int __init imx7ulp_cpuidle_init(void)
+{
+   return cpuidle_register(_cpuidle_driver, NULL);
+}
diff --git a/arch/arm/mach-imx/cpuidle.h b/arch/arm/mach-imx/cpuidle.h
index f914012..7694c8f 100644
--- a/arch/arm/mach-imx/cpuidle.h
+++ b/arch/arm/mach-imx/cpuidle.h
@@ -15,6 +15,7 @@ extern int imx5_cpuidle_init(void);
 extern int imx6q_cpuidle_init(void);
 extern int imx6sl_cpuidle_init(void);
 extern int imx6sx_cpuidle_init(void);
+extern int imx7ulp_cpuidle_init(void);
 #else
 static inline int imx5_cpuidle_init(void)
 {
@@ -32,4 +33,8 @@ static inline int imx6sx_cpuidle_init(void)
 {
return 0;
 }
+static inline int imx7ulp_cpuidle_init(void)
+{
+   return 0;
+}
 #endif
diff --git a/arch/arm/mach-imx/mach-imx7ulp.c b/arch/arm/mach-imx/mach-imx7ulp.c
index 16b295b..11ac71a 100644
--- a/arch/arm/mach-imx/mach-imx7ulp.c
+++ b/arch/arm/mach-imx/mach-imx7ulp.c
@@ -12,6 +12,7 @@
 #include 
 
 #include "common.h"
+#include

[PATCH v2] tracing/kprobes: fix NULL pointer dereference in trace_kprobe_create()

2019-01-10 Thread Andrea Righi

It is possible to trigger a NULL pointer dereference by writing an
incorrectly formatted string to krpobe_events (trying to create a
kretprobe omitting the symbol).

Example:

 echo "r:event_1 " >> /sys/kernel/debug/tracing/kprobe_events

That triggers this:

 BUG: unable to handle kernel NULL pointer dereference at 
 #PF error: [normal kernel read fault]
 PGD 0 P4D 0
 Oops:  [#1] SMP PTI
 CPU: 6 PID: 1757 Comm: bash Not tainted 5.0.0-rc1+ #125
 Hardware name: Dell Inc. XPS 13 9370/0F6P3V, BIOS 1.5.1 08/09/2018
 RIP: 0010:kstrtoull+0x2/0x20
 Code: 28 00 00 00 75 17 48 83 c4 18 5b 41 5c 5d c3 b8 ea ff ff ff eb e1 b8 de 
ff ff ff eb da e8 d6 36 bb ff 66 0f 1f 44 00 00 31 c0 <80> 3f 2b 55 48 89 e5 0f 
94 c0 48 01 c7 e8 5c ff ff ff 5d c3 66 2e
 RSP: 0018:b5d482e57cb8 EFLAGS: 00010246
 RAX:  RBX: 0001 RCX: 82b12720
 RDX: b5d482e57cf8 RSI:  RDI: 
 RBP: b5d482e57d70 R08: a0c05e5a7080 R09: a0c05e003980
 R10:  R11: 4000 R12: a0c04fe87b08
 R13: 0001 R14: 000b R15: a0c058d749e1
 FS:  7f137c7f7740() GS:a0c05e58() knlGS:
 CS:  0010 DS:  ES:  CR0: 80050033
 CR2:  CR3: 000497d46004 CR4: 003606e0
 Call Trace:
  ? trace_kprobe_create+0xb6/0x840
  ? _cond_resched+0x19/0x40
  ? _cond_resched+0x19/0x40
  ? __kmalloc+0x62/0x210
  ? argv_split+0x8f/0x140
  ? trace_kprobe_create+0x840/0x840
  ? trace_kprobe_create+0x840/0x840
  create_or_delete_trace_kprobe+0x11/0x30
  trace_run_command+0x50/0x90
  trace_parse_run_command+0xc1/0x160
  probes_write+0x10/0x20
  __vfs_write+0x3a/0x1b0
  ? apparmor_file_permission+0x1a/0x20
  ? security_file_permission+0x31/0xf0
  ? _cond_resched+0x19/0x40
  vfs_write+0xb1/0x1a0
  ksys_write+0x55/0xc0
  __x64_sys_write+0x1a/0x20
  do_syscall_64+0x5a/0x120
  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fix by doing the proper argument checks in trace_kprobe_create().

Link: 
https://lore.kernel.org/lkml/20190111095108.b79a2ee026185cbd62365...@kernel.org
Fixes: 6212dd29683e ("tracing/kprobes: Use dyn_event framework for kprobe 
events")
Cc: sta...@vger.kernel.org
Signed-off-by: Andrea Righi 
Signed-off-by: Masami Hiramatsu 
---
 v2: argument check refactoring

 kernel/trace/trace_kprobe.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 5c19b8c41c7e..d5fb09ebba8b 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -607,11 +607,17 @@ static int trace_kprobe_create(int argc, const char 
*argv[])
char buf[MAX_EVENT_NAME_LEN];
unsigned int flags = TPARG_FL_KERNEL;
 
-   /* argc must be >= 1 */
-   if (argv[0][0] == 'r') {
+   switch (argv[0][0]) {
+   case 'r':
is_return = true;
flags |= TPARG_FL_RETURN;
-   } else if (argv[0][0] != 'p' || argc < 2)
+   break;
+   case 'p':
+   break;
+   default:
+   return -ECANCELED;
+   }
+   if (argc < 2)
return -ECANCELED;
 
event = strchr([0][1], ':');
-- 
2.17.1

Re: [PATCH v3 0/2] Add Stratix 10 PCIe Root Port support

2019-01-10 Thread Ley Foon Tan

On Wed, 2019-01-02 at 14:16 +0800, Ley Foon Tan wrote:
> Add PCIe Root Port support for Stratix 10 device and also update
> device tree binding documentation.
> 
> v2 -> v3:
> -
> - Rename Stratix10 to Stratix 10.
> - Change bool s10_flag to enum version.
> 
> v1 -> v2:
> -
> - Add define S10_TLP_FMTTYPE_* macros.
> - Remove initialize structure members to NULL/zero.
> - Rename *_funcs to *_data.
> - Update comment and fix coding style warning from checkpatch.pl.
> - Rename StratixXX to stratix10.
> 
> History:
> 
> [v1]: https://lkml.org/lkml/2018/12/26/68
> [v2]: https://lkml.org/lkml/2018/12/31/46
> 
> Ley Foon Tan (2):
>   PCI: altera: Add Stratix 10 PCIe support
>   dt-bindings: PCI: altera: Add altr,pcie-root-port-2.0
> 
>  .../devicetree/bindings/pci/altera-pcie.txt|4 +-
>  drivers/pci/controller/Kconfig |2 +-
>  drivers/pci/controller/pcie-altera.c   |  246
> ++--
>  3 files changed, 226 insertions(+), 26 deletions(-)
> 
Hi,

Any further comment on these patches?

Regards
Ley Foon

Re: x86/fpu: Don't export __kernel_fpu_{begin,end}()

On Fri, Jan 11, 2019 at 06:04:07AM +0100, Lukas Wunner wrote:
> On Thu, Jan 10, 2019 at 07:24:13PM +0100, Greg Kroah-Hartman wrote:
> > My tolerance for ZFS is pretty non-existant.  Sun explicitly did not
> > want their code to work on Linux, so why would we do extra work to get
> > their code to work properly?
> 
> ZoL facilitates seamless r/w cross-mounting with macOS, something no
> other filesystem allows, and that feature is critical for me to work
> on Linux drivers for Mac hardware.  Please don't make life harder than
> necessary for developers like me.  Your "extra work" argument seems
> disingenuous to me, Sebastian's patch is causing extra work for
> ZFS developers, not the kernel community.  The maintenance burden
> for the kernel community to retain the export is zero.

Sorry, no, we do not keep symbols exported for no in-kernel users.

greg k-h

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

2019-01-10 Thread Mika Westerberg

On Wed, Jan 09, 2019 at 12:52:45PM +0200, Andy Shevchenko wrote:
> New quirk enforces search for GPIO based on its type,
> i.e. iterate over GpioIo resources only.
> 
> Signed-off-by: Andy Shevchenko 

Acked-by: Mika Westerberg

[PATCH v4 03/16] drm/bochs: atomic: add atomic_flush+atomic_enable callbacks.

Conversion to atomic modesetting, step one.
Add atomic crtc helper callbacks.

Signed-off-by: Gerd Hoffmann 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs_kms.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index f7e6d1a9b3..2cbd406b1f 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -115,6 +115,29 @@ static int bochs_crtc_page_flip(struct drm_crtc *crtc,
return 0;
 }
 
+static void bochs_crtc_atomic_enable(struct drm_crtc *crtc,
+struct drm_crtc_state *old_crtc_state)
+{
+}
+
+static void bochs_crtc_atomic_flush(struct drm_crtc *crtc,
+   struct drm_crtc_state *old_crtc_state)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_pending_vblank_event *event;
+
+   if (crtc->state && crtc->state->event) {
+   unsigned long irqflags;
+
+   spin_lock_irqsave(>event_lock, irqflags);
+   event = crtc->state->event;
+   crtc->state->event = NULL;
+   drm_crtc_send_vblank_event(crtc, event);
+   spin_unlock_irqrestore(>event_lock, irqflags);
+   }
+}
+
+
 /* These provide the minimum set of functions required to handle a CRTC */
 static const struct drm_crtc_funcs bochs_crtc_funcs = {
.set_config = drm_crtc_helper_set_config,
@@ -128,6 +151,8 @@ static const struct drm_crtc_helper_funcs 
bochs_helper_funcs = {
.mode_set_base = bochs_crtc_mode_set_base,
.prepare = bochs_crtc_prepare,
.commit = bochs_crtc_commit,
+   .atomic_enable = bochs_crtc_atomic_enable,
+   .atomic_flush = bochs_crtc_atomic_flush,
 };
 
 static const uint32_t bochs_formats[] = {
-- 
2.9.3

[PATCH v4 06/16] drm/bochs: atomic: use atomic set_config helper

Conversion to atomic modesetting, step four.
Use atomic set_config helper for crtc.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Oleksandr Andrushchenko 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs_kms.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index c6993c2d59..646f897cb2 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -150,7 +150,7 @@ static void bochs_crtc_atomic_flush(struct drm_crtc *crtc,
 
 /* These provide the minimum set of functions required to handle a CRTC */
 static const struct drm_crtc_funcs bochs_crtc_funcs = {
-   .set_config = drm_crtc_helper_set_config,
+   .set_config = drm_atomic_helper_set_config,
.destroy = drm_crtc_cleanup,
.page_flip = bochs_crtc_page_flip,
.reset = drm_atomic_helper_crtc_reset,
-- 
2.9.3

[PATCH v4 01/16] drm/bochs: encoder cleanup

Most unused callbacks can be NULL pointers these days.
Drop a bunch of empty encoder callbacks.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Oleksandr Andrushchenko 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs_kms.c | 26 --
 1 file changed, 26 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index f87c284dd9..c8ce54498d 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -170,31 +170,6 @@ static void bochs_crtc_init(struct drm_device *dev)
drm_crtc_helper_add(crtc, _helper_funcs);
 }
 
-static void bochs_encoder_mode_set(struct drm_encoder *encoder,
-  struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode)
-{
-}
-
-static void bochs_encoder_dpms(struct drm_encoder *encoder, int state)
-{
-}
-
-static void bochs_encoder_prepare(struct drm_encoder *encoder)
-{
-}
-
-static void bochs_encoder_commit(struct drm_encoder *encoder)
-{
-}
-
-static const struct drm_encoder_helper_funcs bochs_encoder_helper_funcs = {
-   .dpms = bochs_encoder_dpms,
-   .mode_set = bochs_encoder_mode_set,
-   .prepare = bochs_encoder_prepare,
-   .commit = bochs_encoder_commit,
-};
-
 static const struct drm_encoder_funcs bochs_encoder_encoder_funcs = {
.destroy = drm_encoder_cleanup,
 };
@@ -207,7 +182,6 @@ static void bochs_encoder_init(struct drm_device *dev)
encoder->possible_crtcs = 0x1;
drm_encoder_init(dev, encoder, _encoder_encoder_funcs,
 DRM_MODE_ENCODER_DAC, NULL);
-   drm_encoder_helper_add(encoder, _encoder_helper_funcs);
 }
 
 
-- 
2.9.3

[PATCH v4 16/16] drm/bochs: move remaining fb bits to kms

bochs_fbdev.c is almost empty now.  Move the remaining framebuffer bits
over to bochs_kms.c.  Pure code motion. No functional change.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Oleksandr Andrushchenko 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs_fbdev.c | 29 -
 drivers/gpu/drm/bochs/bochs_kms.c   | 17 +
 drivers/gpu/drm/bochs/Makefile  |  2 +-
 3 files changed, 18 insertions(+), 30 deletions(-)
 delete mode 100644 drivers/gpu/drm/bochs/bochs_fbdev.c

diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
b/drivers/gpu/drm/bochs/bochs_fbdev.c
deleted file mode 100644
index 7cac3f5253..00
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ /dev/null
@@ -1,29 +0,0 @@
-/*
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#include "bochs.h"
-#include 
-#include 
-
-/* -- */
-
-static struct drm_framebuffer *
-bochs_gem_fb_create(struct drm_device *dev, struct drm_file *file,
-   const struct drm_mode_fb_cmd2 *mode_cmd)
-{
-   if (mode_cmd->pixel_format != DRM_FORMAT_XRGB &&
-   mode_cmd->pixel_format != DRM_FORMAT_BGRX)
-   return ERR_PTR(-EINVAL);
-
-   return drm_gem_fb_create(dev, file, mode_cmd);
-}
-
-const struct drm_mode_config_funcs bochs_mode_funcs = {
-   .fb_create = bochs_gem_fb_create,
-   .atomic_check = drm_atomic_helper_check,
-   .atomic_commit = drm_atomic_helper_commit,
-};
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index fc856a02a2..e9d5dbc346 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static int defx = 1024;
 static int defy = 768;
@@ -256,6 +257,22 @@ static void bochs_connector_init(struct drm_device *dev)
}
 }
 
+static struct drm_framebuffer *
+bochs_gem_fb_create(struct drm_device *dev, struct drm_file *file,
+   const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+   if (mode_cmd->pixel_format != DRM_FORMAT_XRGB &&
+   mode_cmd->pixel_format != DRM_FORMAT_BGRX)
+   return ERR_PTR(-EINVAL);
+
+   return drm_gem_fb_create(dev, file, mode_cmd);
+}
+
+const struct drm_mode_config_funcs bochs_mode_funcs = {
+   .fb_create = bochs_gem_fb_create,
+   .atomic_check = drm_atomic_helper_check,
+   .atomic_commit = drm_atomic_helper_commit,
+};
 
 int bochs_kms_init(struct bochs_device *bochs)
 {
diff --git a/drivers/gpu/drm/bochs/Makefile b/drivers/gpu/drm/bochs/Makefile
index 98ef60a19e..e9e0f8f5eb 100644
--- a/drivers/gpu/drm/bochs/Makefile
+++ b/drivers/gpu/drm/bochs/Makefile
@@ -1,3 +1,3 @@
-bochs-drm-y := bochs_drv.o bochs_mm.o bochs_kms.o bochs_fbdev.o bochs_hw.o
+bochs-drm-y := bochs_drv.o bochs_mm.o bochs_kms.o bochs_hw.o
 
 obj-$(CONFIG_DRM_BOCHS)+= bochs-drm.o
-- 
2.9.3

[PATCH v4 12/16] drm/bochs: move ttm_bo_(un)reserve calls into bochs_bo_{pin,unpin}

Signed-off-by: Gerd Hoffmann 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs_fbdev.c |  8 
 drivers/gpu/drm/bochs/bochs_kms.c   | 14 +-
 drivers/gpu/drm/bochs/bochs_mm.c|  8 
 3 files changed, 9 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index 92feb817ff..ccf783b038 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -77,14 +77,9 @@ static int bochsfb_create(struct drm_fb_helper *helper,
 
bo = gem_to_bochs_bo(gobj);
 
-   ret = ttm_bo_reserve(>bo, true, false, NULL);
-   if (ret)
-   return ret;
-
ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM);
if (ret) {
DRM_ERROR("failed to pin fbcon\n");
-   ttm_bo_unreserve(>bo);
return ret;
}
 
@@ -92,12 +87,9 @@ static int bochsfb_create(struct drm_fb_helper *helper,
  >kmap);
if (ret) {
DRM_ERROR("failed to kmap fbcon\n");
-   ttm_bo_unreserve(>bo);
return ret;
}
 
-   ttm_bo_unreserve(>bo);
-
/* init fb device */
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info)) {
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index f663c54185..fc856a02a2 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -92,34 +92,22 @@ static int bochs_plane_prepare_fb(struct drm_plane *plane,
struct drm_plane_state *new_state)
 {
struct bochs_bo *bo;
-   int ret;
 
if (!new_state->fb)
return 0;
bo = gem_to_bochs_bo(new_state->fb->obj[0]);
-
-   ret = ttm_bo_reserve(>bo, true, false, NULL);
-   if (ret)
-   return ret;
-   ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM);
-   ttm_bo_unreserve(>bo);
-   return ret;
+   return bochs_bo_pin(bo, TTM_PL_FLAG_VRAM);
 }
 
 static void bochs_plane_cleanup_fb(struct drm_plane *plane,
   struct drm_plane_state *old_state)
 {
struct bochs_bo *bo;
-   int ret;
 
if (!old_state->fb)
return;
bo = gem_to_bochs_bo(old_state->fb->obj[0]);
-   ret = ttm_bo_reserve(>bo, true, false, NULL);
-   if (ret)
-   return;
bochs_bo_unpin(bo);
-   ttm_bo_unreserve(>bo);
 }
 
 static const struct drm_plane_helper_funcs bochs_plane_helper_funcs = {
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index 5a0e092847..fcbf35456d 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -223,7 +223,11 @@ int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag)
bochs_ttm_placement(bo, pl_flag);
for (i = 0; i < bo->placement.num_placement; i++)
bo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT;
+   ret = ttm_bo_reserve(>bo, true, false, NULL);
+   if (ret)
+   return ret;
ret = ttm_bo_validate(>bo, >placement, );
+   ttm_bo_unreserve(>bo);
if (ret)
return ret;
 
@@ -247,7 +251,11 @@ int bochs_bo_unpin(struct bochs_bo *bo)
 
for (i = 0; i < bo->placement.num_placement; i++)
bo->placements[i].flags &= ~TTM_PL_FLAG_NO_EVICT;
+   ret = ttm_bo_reserve(>bo, true, false, NULL);
+   if (ret)
+   return ret;
ret = ttm_bo_validate(>bo, >placement, );
+   ttm_bo_unreserve(>bo);
if (ret)
return ret;
 
-- 
2.9.3

[PATCH v4 14/16] drm/bochs: switch to generic drm fbdev emulation

Signed-off-by: Gerd Hoffmann 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs_drv.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
b/drivers/gpu/drm/bochs/bochs_drv.c
index a3f4e21078..cea42ac64d 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -16,10 +16,6 @@ static int bochs_modeset = -1;
 module_param_named(modeset, bochs_modeset, int, 0444);
 MODULE_PARM_DESC(modeset, "enable/disable kernel modesetting");
 
-static bool enable_fbdev = true;
-module_param_named(fbdev, enable_fbdev, bool, 0444);
-MODULE_PARM_DESC(fbdev, "register fbdev device");
-
 /* -- */
 /* drm interface  */
 
@@ -27,7 +23,6 @@ static void bochs_unload(struct drm_device *dev)
 {
struct bochs_device *bochs = dev->dev_private;
 
-   bochs_fbdev_fini(bochs);
bochs_kms_fini(bochs);
bochs_mm_fini(bochs);
bochs_hw_fini(dev);
@@ -58,9 +53,6 @@ static int bochs_load(struct drm_device *dev)
if (ret)
goto err;
 
-   if (enable_fbdev)
-   bochs_fbdev_init(bochs);
-
return 0;
 
 err:
@@ -110,9 +102,7 @@ static int bochs_pm_suspend(struct device *dev)
 {
struct pci_dev *pdev = to_pci_dev(dev);
struct drm_device *drm_dev = pci_get_drvdata(pdev);
-   struct bochs_device *bochs = drm_dev->dev_private;
 
-   drm_fb_helper_set_suspend_unlocked(>fb.helper, 1);
return drm_mode_config_helper_suspend(drm_dev);
 }
 
@@ -120,9 +110,7 @@ static int bochs_pm_resume(struct device *dev)
 {
struct pci_dev *pdev = to_pci_dev(dev);
struct drm_device *drm_dev = pci_get_drvdata(pdev);
-   struct bochs_device *bochs = drm_dev->dev_private;
 
-   drm_fb_helper_set_suspend_unlocked(>fb.helper, 0);
return drm_mode_config_helper_resume(drm_dev);
 }
 #endif
@@ -167,6 +155,7 @@ static int bochs_pci_probe(struct pci_dev *pdev,
if (ret)
goto err_unload;
 
+   drm_fbdev_generic_setup(dev, 32);
return ret;
 
 err_unload:
-- 
2.9.3

[PATCH v4 04/16] drm/bochs: atomic: add mode_set_nofb callback.

Conversion to atomic modesetting, step two.
Add mode_set_nofb crtc helper callback.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Oleksandr Andrushchenko 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs_kms.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index 2cbd406b1f..56fd7be933 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -86,6 +86,14 @@ static int bochs_crtc_mode_set(struct drm_crtc *crtc,
return 0;
 }
 
+static void bochs_crtc_mode_set_nofb(struct drm_crtc *crtc)
+{
+   struct bochs_device *bochs =
+   container_of(crtc, struct bochs_device, crtc);
+
+   bochs_hw_setmode(bochs, >mode);
+}
+
 static void bochs_crtc_prepare(struct drm_crtc *crtc)
 {
 }
@@ -149,6 +157,7 @@ static const struct drm_crtc_helper_funcs 
bochs_helper_funcs = {
.dpms = bochs_crtc_dpms,
.mode_set = bochs_crtc_mode_set,
.mode_set_base = bochs_crtc_mode_set_base,
+   .mode_set_nofb = bochs_crtc_mode_set_nofb,
.prepare = bochs_crtc_prepare,
.commit = bochs_crtc_commit,
.atomic_enable = bochs_crtc_atomic_enable,
-- 
2.9.3

[PATCH v4 08/16] drm/bochs: atomic: use suspend/resume helpers

Switch to atomic helpers: drm_mode_config_helper_suspend/resume().

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/bochs/bochs_drv.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
b/drivers/gpu/drm/bochs/bochs_drv.c
index f3dd66ae99..08ba6029d2 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -103,11 +103,8 @@ static int bochs_pm_suspend(struct device *dev)
struct drm_device *drm_dev = pci_get_drvdata(pdev);
struct bochs_device *bochs = drm_dev->dev_private;
 
-   drm_kms_helper_poll_disable(drm_dev);
-
drm_fb_helper_set_suspend_unlocked(>fb.helper, 1);
-
-   return 0;
+   return drm_mode_config_helper_suspend(drm_dev);
 }
 
 static int bochs_pm_resume(struct device *dev)
@@ -116,12 +113,8 @@ static int bochs_pm_resume(struct device *dev)
struct drm_device *drm_dev = pci_get_drvdata(pdev);
struct bochs_device *bochs = drm_dev->dev_private;
 
-   drm_helper_resume_force_mode(drm_dev);
-
drm_fb_helper_set_suspend_unlocked(>fb.helper, 0);
-
-   drm_kms_helper_poll_enable(drm_dev);
-   return 0;
+   return drm_mode_config_helper_resume(drm_dev);
 }
 #endif
 
-- 
2.9.3

[PATCH v4 09/16] drm/bochs: atomic: set DRIVER_ATOMIC

Conversion to atomic modesetting, final step.
Set the DRIVER_ATOMIC flag.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Oleksandr Andrushchenko 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
b/drivers/gpu/drm/bochs/bochs_drv.c
index 08ba6029d2..a8cb22cffe 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -81,7 +81,7 @@ static const struct file_operations bochs_fops = {
 };
 
 static struct drm_driver bochs_driver = {
-   .driver_features= DRIVER_GEM | DRIVER_MODESET,
+   .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
.fops   = _fops,
.name   = "bochs-drm",
.desc   = "bochs dispi vga interface (qemu stdvga)",
-- 
2.9.3

[PATCH v4 11/16] drm/bochs: drop unused gpu_addr arg from bochs_bo_pin()

It's always NULL, so just remove it.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Oleksandr Andrushchenko 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs.h   |  2 +-
 drivers/gpu/drm/bochs/bochs_fbdev.c |  2 +-
 drivers/gpu/drm/bochs/bochs_kms.c   |  2 +-
 drivers/gpu/drm/bochs/bochs_mm.c| 11 +--
 4 files changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index 4dc1b6384e..d0d474e06f 100644
--- a/drivers/gpu/drm/bochs/bochs.h
+++ b/drivers/gpu/drm/bochs/bochs.h
@@ -142,7 +142,7 @@ int bochs_dumb_create(struct drm_file *file, struct 
drm_device *dev,
 int bochs_dumb_mmap_offset(struct drm_file *file, struct drm_device *dev,
   uint32_t handle, uint64_t *offset);
 
-int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag, u64 *gpu_addr);
+int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag);
 int bochs_bo_unpin(struct bochs_bo *bo);
 
 /* bochs_kms.c */
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index d9f3d42999..92feb817ff 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -81,7 +81,7 @@ static int bochsfb_create(struct drm_fb_helper *helper,
if (ret)
return ret;
 
-   ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM, NULL);
+   ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM);
if (ret) {
DRM_ERROR("failed to pin fbcon\n");
ttm_bo_unreserve(>bo);
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index 5b7e1a7c6b..f663c54185 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -101,7 +101,7 @@ static int bochs_plane_prepare_fb(struct drm_plane *plane,
ret = ttm_bo_reserve(>bo, true, false, NULL);
if (ret)
return ret;
-   ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM, NULL);
+   ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM);
ttm_bo_unreserve(>bo);
return ret;
 }
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index 0980411e41..5a0e092847 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -210,20 +210,13 @@ static void bochs_ttm_placement(struct bochs_bo *bo, int 
domain)
bo->placement.num_busy_placement = c;
 }
 
-static inline u64 bochs_bo_gpu_offset(struct bochs_bo *bo)
-{
-   return bo->bo.offset;
-}
-
-int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag, u64 *gpu_addr)
+int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag)
 {
struct ttm_operation_ctx ctx = { false, false };
int i, ret;
 
if (bo->pin_count) {
bo->pin_count++;
-   if (gpu_addr)
-   *gpu_addr = bochs_bo_gpu_offset(bo);
return 0;
}
 
@@ -235,8 +228,6 @@ int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag, u64 
*gpu_addr)
return ret;
 
bo->pin_count = 1;
-   if (gpu_addr)
-   *gpu_addr = bochs_bo_gpu_offset(bo);
return 0;
 }
 
-- 
2.9.3

[PATCH v4 05/16] drm/bochs: atomic: switch planes to atomic, wire up helpers.

Conversion to atomic modesetting, step three.
Wire up atomic helpers.  Switch planes to atomic.

We are late to the party, the transitional helpers are gone,
so this can't be splitted into smaller steps any more.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Oleksandr Andrushchenko 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs_fbdev.c |  3 ++
 drivers/gpu/drm/bochs/bochs_kms.c   | 82 +++--
 2 files changed, 82 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index dd3c7df267..d9f3d42999 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -6,6 +6,7 @@
  */
 
 #include "bochs.h"
+#include 
 #include 
 
 /* -- */
@@ -149,6 +150,8 @@ bochs_gem_fb_create(struct drm_device *dev, struct drm_file 
*file,
 
 const struct drm_mode_config_funcs bochs_mode_funcs = {
.fb_create = bochs_gem_fb_create,
+   .atomic_check = drm_atomic_helper_check,
+   .atomic_commit = drm_atomic_helper_commit,
 };
 
 int bochs_fbdev_init(struct bochs_device *bochs)
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index 56fd7be933..c6993c2d59 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -6,7 +6,9 @@
  */
 
 #include "bochs.h"
+#include 
 #include 
+#include 
 
 static int defx = 1024;
 static int defy = 768;
@@ -113,7 +115,7 @@ static int bochs_crtc_page_flip(struct drm_crtc *crtc,
struct drm_framebuffer *old_fb = crtc->primary->fb;
unsigned long irqflags;
 
-   crtc->primary->fb = fb;
+   drm_atomic_set_fb_for_plane(crtc->primary->state, fb);
bochs_crtc_mode_set_base(crtc, 0, 0, old_fb);
if (event) {
spin_lock_irqsave(>dev->event_lock, irqflags);
@@ -151,6 +153,9 @@ static const struct drm_crtc_funcs bochs_crtc_funcs = {
.set_config = drm_crtc_helper_set_config,
.destroy = drm_crtc_cleanup,
.page_flip = bochs_crtc_page_flip,
+   .reset = drm_atomic_helper_crtc_reset,
+   .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
 };
 
 static const struct drm_crtc_helper_funcs bochs_helper_funcs = {
@@ -169,6 +174,71 @@ static const uint32_t bochs_formats[] = {
DRM_FORMAT_BGRX,
 };
 
+static void bochs_plane_atomic_update(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
+{
+   struct bochs_device *bochs = plane->dev->dev_private;
+   struct bochs_bo *bo;
+
+   if (!plane->state->fb)
+   return;
+   bo = gem_to_bochs_bo(plane->state->fb->obj[0]);
+   bochs_hw_setbase(bochs,
+plane->state->crtc_x,
+plane->state->crtc_y,
+bo->bo.offset);
+   bochs_hw_setformat(bochs, plane->state->fb->format);
+}
+
+static int bochs_plane_prepare_fb(struct drm_plane *plane,
+   struct drm_plane_state *new_state)
+{
+   struct bochs_bo *bo;
+   int ret;
+
+   if (!new_state->fb)
+   return 0;
+   bo = gem_to_bochs_bo(new_state->fb->obj[0]);
+
+   ret = ttm_bo_reserve(>bo, true, false, NULL);
+   if (ret)
+   return ret;
+   ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM, NULL);
+   ttm_bo_unreserve(>bo);
+   return ret;
+}
+
+static void bochs_plane_cleanup_fb(struct drm_plane *plane,
+  struct drm_plane_state *old_state)
+{
+   struct bochs_bo *bo;
+   int ret;
+
+   if (!old_state->fb)
+   return;
+   bo = gem_to_bochs_bo(old_state->fb->obj[0]);
+   ret = ttm_bo_reserve(>bo, true, false, NULL);
+   if (ret)
+   return;
+   bochs_bo_unpin(bo);
+   ttm_bo_unreserve(>bo);
+}
+
+static const struct drm_plane_helper_funcs bochs_plane_helper_funcs = {
+   .atomic_update = bochs_plane_atomic_update,
+   .prepare_fb = bochs_plane_prepare_fb,
+   .cleanup_fb = bochs_plane_cleanup_fb,
+};
+
+static const struct drm_plane_funcs bochs_plane_funcs = {
+   .update_plane   = drm_atomic_helper_update_plane,
+   .disable_plane  = drm_atomic_helper_disable_plane,
+   .destroy= drm_primary_helper_destroy,
+   .reset  = drm_atomic_helper_plane_reset,
+   .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
+};
+
 static struct drm_plane *bochs_primary_plane(struct drm_device *dev)
 {
struct drm_plane *primary;
@@ -181,16 +251,17 @@ static struct drm_plane *bochs_primary_plane(struct 
drm_device *dev)
}
 
ret = drm_universal_plane_init(dev, primary, 0,
-  _primary_helper_funcs,
+

[PATCH v4 13/16] drm/bochs: add basic prime support

Just enough to make the generic framebuffer emulation happy.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Oleksandr Andrushchenko 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs.h |  7 ++
 drivers/gpu/drm/bochs/bochs_drv.c | 11 -
 drivers/gpu/drm/bochs/bochs_mm.c  | 49 +++
 3 files changed, 66 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index d0d474e06f..ede22beb85 100644
--- a/drivers/gpu/drm/bochs/bochs.h
+++ b/drivers/gpu/drm/bochs/bochs.h
@@ -145,6 +145,13 @@ int bochs_dumb_mmap_offset(struct drm_file *file, struct 
drm_device *dev,
 int bochs_bo_pin(struct bochs_bo *bo, u32 pl_flag);
 int bochs_bo_unpin(struct bochs_bo *bo);
 
+int bochs_gem_prime_pin(struct drm_gem_object *obj);
+void bochs_gem_prime_unpin(struct drm_gem_object *obj);
+void *bochs_gem_prime_vmap(struct drm_gem_object *obj);
+void bochs_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
+int bochs_gem_prime_mmap(struct drm_gem_object *obj,
+struct vm_area_struct *vma);
+
 /* bochs_kms.c */
 int bochs_kms_init(struct bochs_device *bochs);
 void bochs_kms_fini(struct bochs_device *bochs);
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
b/drivers/gpu/drm/bochs/bochs_drv.c
index a8cb22cffe..a3f4e21078 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -81,7 +81,8 @@ static const struct file_operations bochs_fops = {
 };
 
 static struct drm_driver bochs_driver = {
-   .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
+   .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC |
+ DRIVER_PRIME,
.fops   = _fops,
.name   = "bochs-drm",
.desc   = "bochs dispi vga interface (qemu stdvga)",
@@ -91,6 +92,14 @@ static struct drm_driver bochs_driver = {
.gem_free_object_unlocked = bochs_gem_free_object,
.dumb_create= bochs_dumb_create,
.dumb_map_offset= bochs_dumb_mmap_offset,
+
+   .gem_prime_export = drm_gem_prime_export,
+   .gem_prime_import = drm_gem_prime_import,
+   .gem_prime_pin = bochs_gem_prime_pin,
+   .gem_prime_unpin = bochs_gem_prime_unpin,
+   .gem_prime_vmap = bochs_gem_prime_vmap,
+   .gem_prime_vunmap = bochs_gem_prime_vunmap,
+   .gem_prime_mmap = bochs_gem_prime_mmap,
 };
 
 /* -- */
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index fcbf35456d..641a33f134 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -395,3 +395,52 @@ int bochs_dumb_mmap_offset(struct drm_file *file, struct 
drm_device *dev,
drm_gem_object_put_unlocked(obj);
return 0;
 }
+
+/* -- */
+
+int bochs_gem_prime_pin(struct drm_gem_object *obj)
+{
+   struct bochs_bo *bo = gem_to_bochs_bo(obj);
+
+   return bochs_bo_pin(bo, TTM_PL_FLAG_VRAM);
+}
+
+void bochs_gem_prime_unpin(struct drm_gem_object *obj)
+{
+   struct bochs_bo *bo = gem_to_bochs_bo(obj);
+
+   bochs_bo_unpin(bo);
+}
+
+void *bochs_gem_prime_vmap(struct drm_gem_object *obj)
+{
+   struct bochs_bo *bo = gem_to_bochs_bo(obj);
+   bool is_iomem;
+   int ret;
+
+   ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM);
+   if (ret)
+   return NULL;
+   ret = ttm_bo_kmap(>bo, 0, bo->bo.num_pages, >kmap);
+   if (ret) {
+   bochs_bo_unpin(bo);
+   return NULL;
+   }
+   return ttm_kmap_obj_virtual(>kmap, _iomem);
+}
+
+void bochs_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
+{
+   struct bochs_bo *bo = gem_to_bochs_bo(obj);
+
+   ttm_bo_kunmap(>kmap);
+   bochs_bo_unpin(bo);
+}
+
+int bochs_gem_prime_mmap(struct drm_gem_object *obj,
+struct vm_area_struct *vma)
+{
+   struct bochs_bo *bo = gem_to_bochs_bo(obj);
+
+   return ttm_fbdev_mmap(vma, >bo);
+}
-- 
2.9.3

[PATCH v4 07/16] drm/bochs: atomic: use atomic page_flip helper

Conversion to atomic modesetting, step five.
Use atomic page_flip helper for crtc.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Oleksandr Andrushchenko 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs_kms.c | 23 +--
 1 file changed, 1 insertion(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index 646f897cb2..67c3674609 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -104,27 +104,6 @@ static void bochs_crtc_commit(struct drm_crtc *crtc)
 {
 }
 
-static int bochs_crtc_page_flip(struct drm_crtc *crtc,
-   struct drm_framebuffer *fb,
-   struct drm_pending_vblank_event *event,
-   uint32_t page_flip_flags,
-   struct drm_modeset_acquire_ctx *ctx)
-{
-   struct bochs_device *bochs =
-   container_of(crtc, struct bochs_device, crtc);
-   struct drm_framebuffer *old_fb = crtc->primary->fb;
-   unsigned long irqflags;
-
-   drm_atomic_set_fb_for_plane(crtc->primary->state, fb);
-   bochs_crtc_mode_set_base(crtc, 0, 0, old_fb);
-   if (event) {
-   spin_lock_irqsave(>dev->event_lock, irqflags);
-   drm_crtc_send_vblank_event(crtc, event);
-   spin_unlock_irqrestore(>dev->event_lock, irqflags);
-   }
-   return 0;
-}
-
 static void bochs_crtc_atomic_enable(struct drm_crtc *crtc,
 struct drm_crtc_state *old_crtc_state)
 {
@@ -152,7 +131,7 @@ static void bochs_crtc_atomic_flush(struct drm_crtc *crtc,
 static const struct drm_crtc_funcs bochs_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.destroy = drm_crtc_cleanup,
-   .page_flip = bochs_crtc_page_flip,
+   .page_flip = drm_atomic_helper_page_flip,
.reset = drm_atomic_helper_crtc_reset,
.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
-- 
2.9.3

[PATCH v4 10/16] drm/bochs: remove old bochs_crtc_* functions

Remove the old, now unused crtc callbacks.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Oleksandr Andrushchenko 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs_kms.c | 81 ---
 1 file changed, 81 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index 67c3674609..5b7e1a7c6b 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -20,74 +20,6 @@ MODULE_PARM_DESC(defy, "default y resolution");
 
 /* -- */
 
-static void bochs_crtc_dpms(struct drm_crtc *crtc, int mode)
-{
-   switch (mode) {
-   case DRM_MODE_DPMS_ON:
-   case DRM_MODE_DPMS_STANDBY:
-   case DRM_MODE_DPMS_SUSPEND:
-   case DRM_MODE_DPMS_OFF:
-   default:
-   return;
-   }
-}
-
-static int bochs_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
-   struct drm_framebuffer *old_fb)
-{
-   struct bochs_device *bochs =
-   container_of(crtc, struct bochs_device, crtc);
-   struct bochs_bo *bo;
-   u64 gpu_addr = 0;
-   int ret;
-
-   if (old_fb) {
-   bo = gem_to_bochs_bo(old_fb->obj[0]);
-   ret = ttm_bo_reserve(>bo, true, false, NULL);
-   if (ret) {
-   DRM_ERROR("failed to reserve old_fb bo\n");
-   } else {
-   bochs_bo_unpin(bo);
-   ttm_bo_unreserve(>bo);
-   }
-   }
-
-   if (WARN_ON(crtc->primary->fb == NULL))
-   return -EINVAL;
-
-   bo = gem_to_bochs_bo(crtc->primary->fb->obj[0]);
-   ret = ttm_bo_reserve(>bo, true, false, NULL);
-   if (ret)
-   return ret;
-
-   ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM, _addr);
-   if (ret) {
-   ttm_bo_unreserve(>bo);
-   return ret;
-   }
-
-   ttm_bo_unreserve(>bo);
-   bochs_hw_setbase(bochs, x, y, gpu_addr);
-   return 0;
-}
-
-static int bochs_crtc_mode_set(struct drm_crtc *crtc,
-  struct drm_display_mode *mode,
-  struct drm_display_mode *adjusted_mode,
-  int x, int y, struct drm_framebuffer *old_fb)
-{
-   struct bochs_device *bochs =
-   container_of(crtc, struct bochs_device, crtc);
-
-   if (WARN_ON(crtc->primary->fb == NULL))
-   return -EINVAL;
-
-   bochs_hw_setmode(bochs, mode);
-   bochs_hw_setformat(bochs, crtc->primary->fb->format);
-   bochs_crtc_mode_set_base(crtc, x, y, old_fb);
-   return 0;
-}
-
 static void bochs_crtc_mode_set_nofb(struct drm_crtc *crtc)
 {
struct bochs_device *bochs =
@@ -96,14 +28,6 @@ static void bochs_crtc_mode_set_nofb(struct drm_crtc *crtc)
bochs_hw_setmode(bochs, >mode);
 }
 
-static void bochs_crtc_prepare(struct drm_crtc *crtc)
-{
-}
-
-static void bochs_crtc_commit(struct drm_crtc *crtc)
-{
-}
-
 static void bochs_crtc_atomic_enable(struct drm_crtc *crtc,
 struct drm_crtc_state *old_crtc_state)
 {
@@ -138,12 +62,7 @@ static const struct drm_crtc_funcs bochs_crtc_funcs = {
 };
 
 static const struct drm_crtc_helper_funcs bochs_helper_funcs = {
-   .dpms = bochs_crtc_dpms,
-   .mode_set = bochs_crtc_mode_set,
-   .mode_set_base = bochs_crtc_mode_set_base,
.mode_set_nofb = bochs_crtc_mode_set_nofb,
-   .prepare = bochs_crtc_prepare,
-   .commit = bochs_crtc_commit,
.atomic_enable = bochs_crtc_atomic_enable,
.atomic_flush = bochs_crtc_atomic_flush,
 };
-- 
2.9.3

[PATCH v4 02/16] drm/bochs: split bochs_hw_setmode

Create a separate bochs_hw_setformat function to configure
the framebuffer format (actually just the byteorder).

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Oleksandr Andrushchenko 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs.h |  5 +++--
 drivers/gpu/drm/bochs/bochs_hw.c  | 19 ---
 drivers/gpu/drm/bochs/bochs_kms.c |  3 ++-
 3 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index fb38c8b857..4dc1b6384e 100644
--- a/drivers/gpu/drm/bochs/bochs.h
+++ b/drivers/gpu/drm/bochs/bochs.h
@@ -121,8 +121,9 @@ int bochs_hw_init(struct drm_device *dev);
 void bochs_hw_fini(struct drm_device *dev);
 
 void bochs_hw_setmode(struct bochs_device *bochs,
- struct drm_display_mode *mode,
- const struct drm_format_info *format);
+ struct drm_display_mode *mode);
+void bochs_hw_setformat(struct bochs_device *bochs,
+   const struct drm_format_info *format);
 void bochs_hw_setbase(struct bochs_device *bochs,
  int x, int y, u64 addr);
 int bochs_hw_load_edid(struct bochs_device *bochs);
diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
index d0b4e1cee8..3e04b2f0ec 100644
--- a/drivers/gpu/drm/bochs/bochs_hw.c
+++ b/drivers/gpu/drm/bochs/bochs_hw.c
@@ -204,8 +204,7 @@ void bochs_hw_fini(struct drm_device *dev)
 }
 
 void bochs_hw_setmode(struct bochs_device *bochs,
- struct drm_display_mode *mode,
- const struct drm_format_info *format)
+ struct drm_display_mode *mode)
 {
bochs->xres = mode->hdisplay;
bochs->yres = mode->vdisplay;
@@ -213,12 +212,8 @@ void bochs_hw_setmode(struct bochs_device *bochs,
bochs->stride = mode->hdisplay * (bochs->bpp / 8);
bochs->yres_virtual = bochs->fb_size / bochs->stride;
 
-   DRM_DEBUG_DRIVER("%dx%d @ %d bpp, format %c%c%c%c, vy %d\n",
+   DRM_DEBUG_DRIVER("%dx%d @ %d bpp, vy %d\n",
 bochs->xres, bochs->yres, bochs->bpp,
-(format->format >>  0) & 0xff,
-(format->format >>  8) & 0xff,
-(format->format >> 16) & 0xff,
-(format->format >> 24) & 0xff,
 bochs->yres_virtual);
 
bochs_vga_writeb(bochs, 0x3c0, 0x20); /* unblank */
@@ -236,6 +231,16 @@ void bochs_hw_setmode(struct bochs_device *bochs,
 
bochs_dispi_write(bochs, VBE_DISPI_INDEX_ENABLE,
  VBE_DISPI_ENABLED | VBE_DISPI_LFB_ENABLED);
+}
+
+void bochs_hw_setformat(struct bochs_device *bochs,
+   const struct drm_format_info *format)
+{
+   DRM_DEBUG_DRIVER("format %c%c%c%c\n",
+(format->format >>  0) & 0xff,
+(format->format >>  8) & 0xff,
+(format->format >> 16) & 0xff,
+(format->format >> 24) & 0xff);
 
switch (format->format) {
case DRM_FORMAT_XRGB:
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
b/drivers/gpu/drm/bochs/bochs_kms.c
index c8ce54498d..f7e6d1a9b3 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -80,7 +80,8 @@ static int bochs_crtc_mode_set(struct drm_crtc *crtc,
if (WARN_ON(crtc->primary->fb == NULL))
return -EINVAL;
 
-   bochs_hw_setmode(bochs, mode, crtc->primary->fb->format);
+   bochs_hw_setmode(bochs, mode);
+   bochs_hw_setformat(bochs, crtc->primary->fb->format);
bochs_crtc_mode_set_base(crtc, x, y, old_fb);
return 0;
 }
-- 
2.9.3

[PATCH v4 15/16] drm/bochs: drop old fbdev emulation code

Not needed any more, bochs uses the generic emulation now.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Oleksandr Andrushchenko 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/bochs/bochs.h   |   9 ---
 drivers/gpu/drm/bochs/bochs_fbdev.c | 129 
 2 files changed, 138 deletions(-)

diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index ede22beb85..03711394f1 100644
--- a/drivers/gpu/drm/bochs/bochs.h
+++ b/drivers/gpu/drm/bochs/bochs.h
@@ -80,12 +80,6 @@ struct bochs_device {
struct ttm_bo_device bdev;
bool initialized;
} ttm;
-
-   /* fbdev */
-   struct {
-   struct drm_framebuffer *fb;
-   struct drm_fb_helper helper;
-   } fb;
 };
 
 struct bochs_bo {
@@ -157,7 +151,4 @@ int bochs_kms_init(struct bochs_device *bochs);
 void bochs_kms_fini(struct bochs_device *bochs);
 
 /* bochs_fbdev.c */
-int bochs_fbdev_init(struct bochs_device *bochs);
-void bochs_fbdev_fini(struct bochs_device *bochs);
-
 extern const struct drm_mode_config_funcs bochs_mode_funcs;
diff --git a/drivers/gpu/drm/bochs/bochs_fbdev.c 
b/drivers/gpu/drm/bochs/bochs_fbdev.c
index ccf783b038..7cac3f5253 100644
--- a/drivers/gpu/drm/bochs/bochs_fbdev.c
+++ b/drivers/gpu/drm/bochs/bochs_fbdev.c
@@ -11,124 +11,6 @@
 
 /* -- */
 
-static int bochsfb_mmap(struct fb_info *info,
-   struct vm_area_struct *vma)
-{
-   struct drm_fb_helper *fb_helper = info->par;
-   struct bochs_bo *bo = gem_to_bochs_bo(fb_helper->fb->obj[0]);
-
-   return ttm_fbdev_mmap(vma, >bo);
-}
-
-static struct fb_ops bochsfb_ops = {
-   .owner = THIS_MODULE,
-   DRM_FB_HELPER_DEFAULT_OPS,
-   .fb_fillrect = drm_fb_helper_cfb_fillrect,
-   .fb_copyarea = drm_fb_helper_cfb_copyarea,
-   .fb_imageblit = drm_fb_helper_cfb_imageblit,
-   .fb_mmap = bochsfb_mmap,
-};
-
-static int bochsfb_create_object(struct bochs_device *bochs,
-const struct drm_mode_fb_cmd2 *mode_cmd,
-struct drm_gem_object **gobj_p)
-{
-   struct drm_device *dev = bochs->dev;
-   struct drm_gem_object *gobj;
-   u32 size;
-   int ret = 0;
-
-   size = mode_cmd->pitches[0] * mode_cmd->height;
-   ret = bochs_gem_create(dev, size, true, );
-   if (ret)
-   return ret;
-
-   *gobj_p = gobj;
-   return ret;
-}
-
-static int bochsfb_create(struct drm_fb_helper *helper,
- struct drm_fb_helper_surface_size *sizes)
-{
-   struct bochs_device *bochs =
-   container_of(helper, struct bochs_device, fb.helper);
-   struct fb_info *info;
-   struct drm_framebuffer *fb;
-   struct drm_mode_fb_cmd2 mode_cmd;
-   struct drm_gem_object *gobj = NULL;
-   struct bochs_bo *bo = NULL;
-   int size, ret;
-
-   if (sizes->surface_bpp != 32)
-   return -EINVAL;
-
-   mode_cmd.width = sizes->surface_width;
-   mode_cmd.height = sizes->surface_height;
-   mode_cmd.pitches[0] = sizes->surface_width * 4;
-   mode_cmd.pixel_format = DRM_FORMAT_HOST_XRGB;
-   size = mode_cmd.pitches[0] * mode_cmd.height;
-
-   /* alloc, pin & map bo */
-   ret = bochsfb_create_object(bochs, _cmd, );
-   if (ret) {
-   DRM_ERROR("failed to create fbcon backing object %d\n", ret);
-   return ret;
-   }
-
-   bo = gem_to_bochs_bo(gobj);
-
-   ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM);
-   if (ret) {
-   DRM_ERROR("failed to pin fbcon\n");
-   return ret;
-   }
-
-   ret = ttm_bo_kmap(>bo, 0, bo->bo.num_pages,
- >kmap);
-   if (ret) {
-   DRM_ERROR("failed to kmap fbcon\n");
-   return ret;
-   }
-
-   /* init fb device */
-   info = drm_fb_helper_alloc_fbi(helper);
-   if (IS_ERR(info)) {
-   DRM_ERROR("Failed to allocate fbi: %ld\n", PTR_ERR(info));
-   return PTR_ERR(info);
-   }
-
-   info->par = >fb.helper;
-
-   fb = drm_gem_fbdev_fb_create(bochs->dev, sizes, 0, gobj, NULL);
-   if (IS_ERR(fb)) {
-   DRM_ERROR("Failed to create framebuffer: %ld\n", PTR_ERR(fb));
-   return PTR_ERR(fb);
-   }
-
-   /* setup helper */
-   bochs->fb.helper.fb = fb;
-
-   strcpy(info->fix.id, "bochsdrmfb");
-
-   info->fbops = _ops;
-
-   drm_fb_helper_fill_fix(info, fb->pitches[0], fb->format->depth);
-   drm_fb_helper_fill_var(info, >fb.helper, sizes->fb_width,
-  sizes->fb_height);
-
-   info->screen_base = bo->kmap.virtual;
-   info->screen_size = size;
-
-   drm_vma_offset_remove(>bo.bdev->vma_manager, >bo.vma_node);
-   info->fix.smem_start = 0;
-   info->fix.smem_len = size;
-   return 0;
-}
-
-static

Re: Patch series for 4.19 to compile powerpc with Clang

On Thu, Jan 10, 2019 at 10:17:38AM -0700, Nathan Chancellor wrote:
> Hi Greg and Sasha,
> 
> Attached is an mbox with a series of patches to allow building the
> powerpc kernel with Clang. We have been running continuous integration
> that builds and boots the kernel in QEMU for almost two months now with
> no regressions. This is on top of 4.19.14, there should be no conflicts
> but let me know if I messed something up.
> 
> I will send a series for 4.14 in a little bit as well.

All now queued up for 4.19 as well.

thanks,

greg k-h

Re: [PATCH v2] usb: gadget: musb: fix short isoc packets with inventra dma

2019-01-10 Thread Paul Elder

Hi Bin,

On Wed, Jan 09, 2019 at 09:02:15AM -0600, Bin Liu wrote:
> Hi Paul,
> 
> On Wed, Jan 09, 2019 at 02:10:09AM -0500, Paul Elder wrote:
> > Handling short packets (length < max packet size) in the Inventra DMA
> > engine in the MUSB driver causes the MUSB DMA controller to hang. An
> > example of a problem that is caused by this problem is when streaming
> > video out of a UVC gadget, only the first video frame is transferred.
> > 
> > For short packets (mode-0 or mode-1 DMA), MUSB_TXCSR_TXPKTRDY must be
> > set manually by the driver. This was previously done in musb_g_tx
> > (musb_gadget.c), but incorrectly (all csr flags were cleared, and only
> > MUSB_TXCSR_MODE and MUSB_TXCSR_TXPKTRDY were set). Fixing that problem
> > allows some requests to be transferred correctly, but multiple requests
> > were often put together in one USB packet, and caused problems if the
> > packet size was not a multiple of 4. Instead, set MUSB_TXCSR_TXPKTRDY
> > in dma_controller_irq (musbhsdma.c), just like host mode transfers.
> > 
> > This topic was originally tackled by Nicolas Boichat [0] [1] and is
> > discussed further at [2] as part of his GSoC project [3].
> > 
> > [0] 
> > https://groups.google.com/forum/?hl=en#!topic/beagleboard-gsoc/k8Azwfp75CU
> > [1] 
> > https://gitorious.org/beagleboard-usbsniffer/beagleboard-usbsniffer-kernel/commit/b0be3b6cc195ba732189b04f1d43ec843c3e54c9?p=beagleboard-usbsniffer:beagleboard-usbsniffer-kernel.git;a=patch;h=b0be3b6cc195ba732189b04f1d43ec843c3e54c9
> > [2] 
> > http://beagleboard-usbsniffer.blogspot.com/2010/07/musb-isochronous-transfers-fixed.html
> > [3] http://elinux.org/BeagleBoard/GSoC/USBSniffer
> > 
> > Signed-off-by: Paul Elder 
> > ---
> > Changes in v2:
> > 
> > - no more flushing FIFO
> > - greatly simplified short packet if guard in musb_g_tx, and removed
> >   unnecessary variables
> > - minor indentation and wording changes
> > 
> >  drivers/usb/musb/musb_gadget.c | 19 +--
> >  drivers/usb/musb/musbhsdma.c   | 21 +++--
> >  2 files changed, 16 insertions(+), 24 deletions(-)
> > 
> > diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
> > index eae8b1b1b45b..496643f54faa 100644
> > --- a/drivers/usb/musb/musb_gadget.c
> > +++ b/drivers/usb/musb/musb_gadget.c
> > @@ -452,13 +452,10 @@ void musb_g_tx(struct musb *musb, u8 epnum)
> > }
> >  
> > if (request) {
> > -   u8  is_dma = 0;
> > -   boolshort_packet = false;
> >  
> > trace_musb_req_tx(req);
> >  
> > if (dma && (csr & MUSB_TXCSR_DMAENAB)) {
> > -   is_dma = 1;
> > csr |= MUSB_TXCSR_P_WZC_BITS;
> > csr &= ~(MUSB_TXCSR_DMAENAB | MUSB_TXCSR_P_UNDERRUN |
> >  MUSB_TXCSR_TXPKTRDY | MUSB_TXCSR_AUTOSET);
> > @@ -476,16 +473,8 @@ void musb_g_tx(struct musb *musb, u8 epnum)
> >  */
> > if ((request->zero && request->length)
> > && (request->length % musb_ep->packet_sz == 0)
> > -   && (request->actual == request->length))
> > -   short_packet = true;
> > +   && (request->actual == request->length)) {
> >  
> > -   if ((musb_dma_inventra(musb) || musb_dma_ux500(musb)) &&
> > -   (is_dma && (!dma->desired_mode ||
> > -   (request->actual &
> > -   (musb_ep->packet_sz - 1)
> > -   short_packet = true;
> > -
> > -   if (short_packet) {
> > /*
> >  * On DMA completion, FIFO may not be
> >  * available yet...
> > @@ -493,8 +482,10 @@ void musb_g_tx(struct musb *musb, u8 epnum)
> > if (csr & MUSB_TXCSR_TXPKTRDY)
> > return;
> >  
> > -   musb_writew(epio, MUSB_TXCSR, MUSB_TXCSR_MODE
> > -   | MUSB_TXCSR_TXPKTRDY);
> > +   musb_dbg(musb, "sending short pkt (zero=%d, length=%d, 
> > actual=%d, dma->desired_mode=%d)\n",
> > +request->zero, request->length, 
> > request->actual,
> > +dma->desired_mode);
> > +   musb_writew(epio, MUSB_TXCSR, csr | 
> > MUSB_TXCSR_TXPKTRDY);
> 
> Sorry I didn't catch this in the last review, but this change seems not
> required, isn't it? In the first version of the patch, the code is
> 'returned' in the 'if (musb_dma_inventra())' branch above, doesn't reach
> here.

Do you mean change compared to the last version of the patch, or this
last chunk of the diff?

I guess I did also remove the return when I removed the 'if
(musb_dma_inventra())' block that had the FLUSHFIFIO, but when I tested
it it still worked. In fact, I reverted this last diff chunk and it
still worked.


Paul

Re: [PATCHv2 2/7] acpi: change the topo of acpi_table_upgrade()

2019-01-10 Thread Chao Fan

On Fri, Jan 11, 2019 at 01:12:52PM +0800, Pingfan Liu wrote:
>The current acpi_table_upgrade() relies on initrd_start, but this var is
>only valid after relocate_initrd(). There is requirement to extract the
>acpi info from initrd before memblock-allocator can work(see [2/4]), hence
>acpi_table_upgrade() need to accept the input param directly.
>
>Signed-off-by: Pingfan Liu 
>Acked-by: "Rafael J. Wysocki" 
>Cc: Thomas Gleixner 
>Cc: Ingo Molnar 
>Cc: Borislav Petkov 
>Cc: "H. Peter Anvin" 
>Cc: Dave Hansen 
>Cc: Andy Lutomirski 
>Cc: Peter Zijlstra 
>Cc: "Rafael J. Wysocki" 
>Cc: Len Brown 
>Cc: Yinghai Lu 
>Cc: Tejun Heo 
>Cc: Chao Fan 
>Cc: Baoquan He 
>Cc: Juergen Gross 
>Cc: Andrew Morton 
>Cc: Mike Rapoport 
>Cc: Vlastimil Babka 
>Cc: Michal Hocko 
>Cc: x...@kernel.org
>Cc: linux-a...@vger.kernel.org
>Cc: linux...@kvack.org
>---
> arch/arm64/kernel/setup.c | 2 +-
> arch/x86/kernel/setup.c   | 2 +-
> drivers/acpi/tables.c | 4 +---
> include/linux/acpi.h  | 4 ++--
> 4 files changed, 5 insertions(+), 7 deletions(-)
>
>diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
>index f4fc1e0..bc4b47d 100644
>--- a/arch/arm64/kernel/setup.c
>+++ b/arch/arm64/kernel/setup.c
>@@ -315,7 +315,7 @@ void __init setup_arch(char **cmdline_p)
>   paging_init();
>   efi_apply_persistent_mem_reservations();
> 
>-  acpi_table_upgrade();
>+  acpi_table_upgrade((void *)initrd_start, initrd_end - initrd_start);
> 
>   /* Parse the ACPI tables for possible boot-time configuration */
>   acpi_boot_table_init();
>diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>index ac432ae..dc8fc5d 100644
>--- a/arch/x86/kernel/setup.c
>+++ b/arch/x86/kernel/setup.c
>@@ -1172,8 +1172,8 @@ void __init setup_arch(char **cmdline_p)
> 
>   reserve_initrd();
> 
>-  acpi_table_upgrade();
> 
I wonder whether this will cause two blank lines together.

Thanks,
Chao Fan

>+  acpi_table_upgrade((void *)initrd_start, initrd_end - initrd_start);
>   vsmp_init();
> 
>   io_delay_init();
>diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
>index 61203ee..84e0a79 100644
>--- a/drivers/acpi/tables.c
>+++ b/drivers/acpi/tables.c
>@@ -471,10 +471,8 @@ static DECLARE_BITMAP(acpi_initrd_installed, 
>NR_ACPI_INITRD_TABLES);
> 
> #define MAP_CHUNK_SIZE   (NR_FIX_BTMAPS << PAGE_SHIFT)
> 
>-void __init acpi_table_upgrade(void)
>+void __init acpi_table_upgrade(void *data, size_t size)
> {
>-  void *data = (void *)initrd_start;
>-  size_t size = initrd_end - initrd_start;
>   int sig, no, table_nr = 0, total_offset = 0;
>   long offset = 0;
>   struct acpi_table_header *table;
>diff --git a/include/linux/acpi.h b/include/linux/acpi.h
>index ed80f14..0b6e0b6 100644
>--- a/include/linux/acpi.h
>+++ b/include/linux/acpi.h
>@@ -1254,9 +1254,9 @@ acpi_graph_get_remote_endpoint(const struct 
>fwnode_handle *fwnode,
> #endif
> 
> #ifdef CONFIG_ACPI_TABLE_UPGRADE
>-void acpi_table_upgrade(void);
>+void acpi_table_upgrade(void *data, size_t size);
> #else
>-static inline void acpi_table_upgrade(void) { }
>+static inline void acpi_table_upgrade(void *data, size_t size) { }
> #endif
> 
> #if defined(CONFIG_ACPI) && defined(CONFIG_ACPI_WATCHDOG)
>-- 
>2.7.4
>
>
>

Discuss

2019-01-10 Thread J. Reimann

Hello, My Name is Johann Reimann and i have something important to discuss with 
you but only with your permission i will proceed.

 Regards
J. Reimann

Re: [RFC PATCH kernel] powerpc/stack_protector: Fix external modules building

2019-01-10 Thread Michael Ellerman

Masahiro Yamada  writes:
> On Thu, Jan 10, 2019 at 2:44 PM Alexey Kardashevskiy  wrote:
...
>> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
>> index 488c9ed..0492f62 100644
>> --- a/arch/powerpc/Makefile
>> +++ b/arch/powerpc/Makefile
>> @@ -419,7 +419,11 @@ archheaders:
>>  ifdef CONFIG_STACKPROTECTOR
>>  prepare: stack_protector_prepare
>>
>> +ifeq ($(KBUILD_EXTMOD),)
>>  stack_protector_prepare: prepare0
>> +else
>> +stack_protector_prepare:
>> +endif
>
>
> Honestly, I think this is ugly.

Yes I would call it a hack :)

> Do you want me to send an alternative solution?

I don't grok how external modules are built well enough to work out what
the right solution is. So if you can come up with something better that
would be awesome.

cheers

Re: [PATCH 4/4] usb: musb: Add support for MediaTek musb controller

2019-01-10 Thread Min Guo

Hi Bin,

I have some questions about
musbhs_dma_controller_destroy/create_noirq().
1,Because of controller->irq=0 in noirq case, destroy_noirq can reuse
musbhs_dma_controller_destroy. Is it necessary to write a destroy_noirq
function?
2, How about creating a common function for create musb dma controller
as following:
static struct musb_dma_controller *dma_controller_alloc(struct musb
*musb, void __iomem *base)
then musbhs_dma_controller_create() and
musbhs_dma_controller_create_noirq() call it to alloc common resource.


On Tue, 2019-01-08 at 09:44 -0600, Bin Liu wrote:
> Hi,
> 
> On Thu, Dec 27, 2018 at 03:34:26PM +0800, min@mediatek.com wrote:
> > From: Min Guo 
> > 
> > This adds support for MediaTek musb controller in
> > host, peripheral and otg mode
> > 

> > diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c
> > index 824adcb..c545475 100644
> > --- a/drivers/usb/musb/musbhsdma.c
> > +++ b/drivers/usb/musb/musbhsdma.c

> >  
> >  void musbhs_dma_controller_destroy(struct dma_controller *c)
> >  {
> > struct musb_dma_controller *controller = container_of(c,
> > struct musb_dma_controller, controller);
> > +   struct musb *musb = controller->private_data;
> >  
> > dma_controller_stop(controller);
> >  
> > -   if (controller->irq)
> > +   if (!(musb->ops->quirks & MUSB_MTK_QUIRKS) && controller->irq)
> > free_irq(controller->irq, c);
> >  
> > kfree(controller);
> > @@ -398,11 +402,15 @@ struct dma_controller 
> > *musbhs_dma_controller_create(struct musb *musb,
> > struct musb_dma_controller *controller;
> > struct device *dev = musb->controller;
> > struct platform_device *pdev = to_platform_device(dev);
> > -   int irq = platform_get_irq_byname(pdev, "dma");
> > +   int irq = -1;
> >  
> > -   if (irq <= 0) {
> > -   dev_err(dev, "No DMA interrupt line!\n");
> > -   return NULL;
> > +   if (!(musb->ops->quirks & MUSB_MTK_QUIRKS)) {
> > +   irq = platform_get_irq_byname(pdev, "dma");
> > +
> > +   if (irq < 0) {
> > +   dev_err(dev, "No DMA interrupt line!\n");
> > +   return NULL;
> > +   }
> > }
> 
> Please create musbhs_dma_controller_destroy_noirq() for your platform to
> not use the quirk.
> 
> >  
> > controller = kzalloc(sizeof(*controller), GFP_KERNEL);
> > @@ -418,15 +426,17 @@ struct dma_controller 
> > *musbhs_dma_controller_create(struct musb *musb,
> > controller->controller.channel_program = dma_channel_program;
> > controller->controller.channel_abort = dma_channel_abort;
> >  
> > -   if (request_irq(irq, dma_controller_irq, 0,
> > +   if (!(musb->ops->quirks & MUSB_MTK_QUIRKS)) {
> > +   if (request_irq(irq, dma_controller_irq, 0,
> > dev_name(musb->controller), >controller)) {
> > -   dev_err(dev, "request_irq %d failed!\n", irq);
> > -   musb_dma_controller_destroy(>controller);
> > +   dev_err(dev, "request_irq %d failed!\n", irq);
> > +   musb_dma_controller_destroy(>controller);
> >  
> > -   return NULL;
> > -   }
> > +   return NULL;
> > +   }
> >  
> > -   controller->irq = irq;
> > +   controller->irq = irq;
> > +   }
> >  
> > return >controller;
> >  }
> 
> Same here, create musbhs_dma_controller_create_noirq(). Then use both
> new API for the mtk glue driver.



> Regards,
> -Bin.

[PATCH 3/3] ARM: dts: cygnus: Change pwm compatible to new version

From: Praveen Kumar B 

Change pwm compatible to new version of pwm-kona
Add new compatible to check pwm configure status

Signed-off-by: Praveen Kumar B 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Signed-off-by: Sheetal Tigadoli 
---
 arch/arm/boot/dts/bcm-cygnus.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 253df71..2a433e7 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -595,7 +595,7 @@
};
 
pwm: pwm@180aa500 {
-   compatible = "brcm,kona-pwm";
+   compatible = "brcm,kona-pwm-v2";
reg = <0x180aa500 0xc4>;
#pwm-cells = <3>;
clocks = <_clks BCM_CYGNUS_ASIU_PWM_CLK>;
-- 
1.9.1

[PATCH 2/3] drivers: pwm: pwm-bcm-kona: Add pwm-kona-v2 support

From: Praveen Kumar B 

Add support for new version of pwm-kona.
Add support to make PWM changes configured and stable.

Signed-off-by: Praveen Kumar B 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Signed-off-by: Sheetal Tigadoli 
---
 drivers/pwm/pwm-bcm-kona.c | 128 ++---
 1 file changed, 98 insertions(+), 30 deletions(-)

diff --git a/drivers/pwm/pwm-bcm-kona.c b/drivers/pwm/pwm-bcm-kona.c
index 09a95ae..2b44ad8 100644
--- a/drivers/pwm/pwm-bcm-kona.c
+++ b/drivers/pwm/pwm-bcm-kona.c
@@ -45,30 +45,39 @@
  *high or low depending on its state at that exact instant.
  */
 
-#define PWM_CONTROL_OFFSET (0x)
+#define PWM_CONTROL_OFFSET 0x
 #define PWM_CONTROL_SMOOTH_SHIFT(chan) (24 + (chan))
 #define PWM_CONTROL_TYPE_SHIFT(chan)   (16 + (chan))
 #define PWM_CONTROL_POLARITY_SHIFT(chan)   (8 + (chan))
 #define PWM_CONTROL_TRIGGER_SHIFT(chan)(chan)
 
-#define PRESCALE_OFFSET(0x0004)
+#define PRESCALE_OFFSET0x0004
 #define PRESCALE_SHIFT(chan)   ((chan) << 2)
 #define PRESCALE_MASK(chan)(0x7 << PRESCALE_SHIFT(chan))
-#define PRESCALE_MIN   (0x)
-#define PRESCALE_MAX   (0x0007)
+#define PRESCALE_MIN   0x
+#define PRESCALE_MAX   0x0007
 
 #define PERIOD_COUNT_OFFSET(chan)  (0x0008 + ((chan) << 3))
-#define PERIOD_COUNT_MIN   (0x0002)
-#define PERIOD_COUNT_MAX   (0x00ff)
+#define PERIOD_COUNT_MIN   0x0002
+#define PERIOD_COUNT_MAX   0x00ff
 
 #define DUTY_CYCLE_HIGH_OFFSET(chan)   (0x000c + ((chan) << 3))
-#define DUTY_CYCLE_HIGH_MIN(0x)
-#define DUTY_CYCLE_HIGH_MAX(0x00ff)
+#define DUTY_CYCLE_HIGH_MIN0x
+#define DUTY_CYCLE_HIGH_MAX0x00ff
+
+#define PWM_MONITOR_OFFSET 0xb0
+#define PWM_MONITOR_TIMEOUT_US 5
+
+enum kona_pwmc_ver {
+   KONA_PWM_V1 = 1,
+   KONA_PWM_V2
+};
 
 struct kona_pwmc {
struct pwm_chip chip;
void __iomem *base;
struct clk *clk;
+   enum kona_pwmc_ver version;
 };
 
 static inline struct kona_pwmc *to_kona_pwmc(struct pwm_chip *_chip)
@@ -76,11 +85,40 @@ static inline struct kona_pwmc *to_kona_pwmc(struct 
pwm_chip *_chip)
return container_of(_chip, struct kona_pwmc, chip);
 }
 
+static int kona_pwmc_wait_stable(struct pwm_chip *chip, unsigned int chan,
+unsigned int kona_ver)
+{
+   struct kona_pwmc *kp = to_kona_pwmc(chip);
+   unsigned int value;
+   unsigned int count = PWM_MONITOR_TIMEOUT_US * 1000;
+
+   switch (kona_ver) {
+   case KONA_PWM_V1:
+   /*
+* There must be a min 400ns delay between clearing trigger and
+* settingit. Failing to do this may result in no PWM signal.
+*/
+   ndelay(400);
+   return 0;
+   case KONA_PWM_V2:
+   do {
+   value = readl(kp->base + PWM_MONITOR_OFFSET);
+   if (!(value & (BIT(chan
+   return 0;
+   ndelay(1);
+   } while (count--);
+
+   return -ETIMEDOUT;
+   default:
+   return -ENODEV;
+   }
+}
+
 /*
  * Clear trigger bit but set smooth bit to maintain old output.
  */
-static void kona_pwmc_prepare_for_settings(struct kona_pwmc *kp,
-   unsigned int chan)
+static int kona_pwmc_prepare_for_settings(struct kona_pwmc *kp,
+ unsigned int chan)
 {
unsigned int value = readl(kp->base + PWM_CONTROL_OFFSET);
 
@@ -88,14 +126,10 @@ static void kona_pwmc_prepare_for_settings(struct 
kona_pwmc *kp,
value &= ~(1 << PWM_CONTROL_TRIGGER_SHIFT(chan));
writel(value, kp->base + PWM_CONTROL_OFFSET);
 
-   /*
-* There must be a min 400ns delay between clearing trigger and setting
-* it. Failing to do this may result in no PWM signal.
-*/
-   ndelay(400);
+   return kona_pwmc_wait_stable(>chip, chan, kp->version);
 }
 
-static void kona_pwmc_apply_settings(struct kona_pwmc *kp, unsigned int chan)
+static int kona_pwmc_apply_settings(struct kona_pwmc *kp, unsigned int chan)
 {
unsigned int value = readl(kp->base + PWM_CONTROL_OFFSET);
 
@@ -104,8 +138,7 @@ static void kona_pwmc_apply_settings(struct kona_pwmc *kp, 
unsigned int chan)
value |= 1 << PWM_CONTROL_TRIGGER_SHIFT(chan);
writel(value, kp->base + PWM_CONTROL_OFFSET);
 
-   /* Trigger bit must be held high for at least 400 ns. */
-

[PATCH 1/3] dt-bindings: pwm: kona: Add new compatible for new version pwm-kona

From: Praveen Kumar B 

Add new compatible string for new version of pwm-kona

Signed-off-by: Praveen Kumar B 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Signed-off-by: Sheetal Tigadoli 
---
 Documentation/devicetree/bindings/pwm/brcm,kona-pwm.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.txt 
b/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.txt
index 8eae9fe..d37f697 100644
--- a/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/brcm,kona-pwm.txt
@@ -3,7 +3,7 @@ Broadcom Kona PWM controller device tree bindings
 This controller has 6 channels.
 
 Required Properties :
-- compatible: should contain "brcm,kona-pwm"
+- compatible: should contain "brcm,kona-pwm" or "brcm,kona-pwm-v2"
 - reg: physical base address and length of the controller's registers
 - clocks: phandle + clock specifier pair for the external clock
 - #pwm-cells: Should be 3. See pwm.txt in this directory for a
-- 
1.9.1

[PATCH 0/3] Add support for PWM Configure and stablize for PWM kona