Re: [PATCH 2/3] tracing: Add trace_irqsoff tracepoints

2016-08-22 Thread kbuild test robot
Hi Binoy,

[auto build test WARNING on tip/perf/core]
[also build test WARNING on v4.8-rc3 next-20160819]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Binoy-Jayan/tracing-Deference-pointers-without-RCU-checks/20160818-151235
config: x86_64-randconfig-s3-08181449 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from include/trace/define_trace.h:95:0,
from include/trace/events/latency.h:42,
from kernel/trace/trace_irqsoff.c:22:
   include/trace/events/latency.h: In function 
'trace_raw_output_latency_template':
   include/trace/events/latency.h:24:12: warning: format '%lu' expects argument 
of type 'long unsigned int', but argument 4 has type 'cycles_t {aka long long 
unsigned int}' [-Wformat=]
 TP_printk("cpu=%d, latency=%lu", __entry->cpu, __entry->latency)
   ^
   include/trace/trace_events.h:327:22: note: in definition of macro 
'DECLARE_EVENT_CLASS'
 trace_seq_printf(s, print); \
 ^
   include/trace/events/latency.h:24:2: note: in expansion of macro 'TP_printk'
 TP_printk("cpu=%d, latency=%lu", __entry->cpu, __entry->latency)
 ^
   In file included from include/asm-generic/percpu.h:6:0,
from arch/x86/include/asm/percpu.h:552,
from arch/x86/include/asm/preempt.h:5,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/uapi/linux/timex.h:56,
from include/linux/timex.h:56,
from include/linux/sched.h:19,
from include/linux/uaccess.h:4,
from kernel/trace/trace_irqsoff.c:13:
   At top level:
>> kernel/trace/trace_irqsoff.c:29:32: warning: 'ts_preempt' defined but not 
>> used [-Wunused-variable]
static DEFINE_PER_CPU(cycle_t, ts_preempt);
   ^
   include/linux/percpu-defs.h:105:19: note: in definition of macro 
'DEFINE_PER_CPU_SECTION'
 __typeof__(type) name
  ^~~~
>> kernel/trace/trace_irqsoff.c:29:8: note: in expansion of macro 
>> 'DEFINE_PER_CPU'
static DEFINE_PER_CPU(cycle_t, ts_preempt);
   ^~
>> kernel/trace/trace_irqsoff.c:28:32: warning: 'ts_irqs' defined but not used 
>> [-Wunused-variable]
static DEFINE_PER_CPU(cycle_t, ts_irqs);
   ^
   include/linux/percpu-defs.h:105:19: note: in definition of macro 
'DEFINE_PER_CPU_SECTION'
 __typeof__(type) name
  ^~~~
   kernel/trace/trace_irqsoff.c:28:8: note: in expansion of macro 
'DEFINE_PER_CPU'
static DEFINE_PER_CPU(cycle_t, ts_irqs);
   ^~

vim +/ts_preempt +29 kernel/trace/trace_irqsoff.c

 7   * From code in the latency_tracer, that is:
 8   *
 9   *  Copyright (C) 2004-2006 Ingo Molnar
10   *  Copyright (C) 2004 Nadia Yvette Chambers
11   */
12  #include 
  > 13  #include 
14  #include 
15  #include 
16  
17  #include 
18  
19  #include "trace.h"
20  
21  #define CREATE_TRACE_POINTS
22  #include 
23  
24  static struct trace_array   *irqsoff_trace __read_mostly;
25  static int  tracer_enabled __read_mostly;
26  
27  static DEFINE_PER_CPU(int, tracing_cpu);
  > 28  static DEFINE_PER_CPU(cycle_t, ts_irqs);
  > 29  static DEFINE_PER_CPU(cycle_t, ts_preempt);
30  static DEFINE_PER_CPU(cycle_t, ts_critical_timings);
31  static DEFINE_RAW_SPINLOCK(max_trace_lock);
32  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


Re: [PART2 PATCH v6 07/12] iommu/amd: Introduce amd_iommu_update_ga()

2016-08-22 Thread kbuild test robot
Hi Suravee,

[auto build test ERROR on v4.7-rc7]
[also build test ERROR on next-20160819]
[cannot apply to iommu/next kvm/linux-next linux/master v4.8-rc2 v4.8-rc1]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Suravee-Suthikulpanit/iommu-AMD-Introduce-IOMMU-AVIC-support/20160819-111539
config: x86_64-randconfig-x018-201633 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   In file included from drivers/iommu/amd_iommu.c:33:0:
>> include/linux/amd-iommu.h:208:1: error: expected identifier or '(' before 
>> '{' token
{
^
   include/linux/amd-iommu.h:207:1: warning: 'amd_iommu_update_ga' declared 
'static' but never defined [-Wunused-function]
amd_iommu_update_ga(u32 cpu, u64 base, bool is_run, struct amd_ir_data 
*ir_data);
^~~

vim +208 include/linux/amd-iommu.h

   202  {
   203  return 0;
   204  }
   205  
   206  static inline int
   207  amd_iommu_update_ga(u32 cpu, u64 base, bool is_run, struct amd_ir_data 
*ir_data);
 > 208  {
   209  return 0;
   210  }
   211  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


Re: [PATCH 5/5] net-sysfs: make sure objects belong to contrainer's owner

2016-08-22 Thread kbuild test robot
Hi Dmitry,

[auto build test ERROR on driver-core/driver-core-testing]
[also build test ERROR on v4.8-rc3 next-20160819]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Dmitry-Torokhov/Make-sys-class-net-per-net-namespace-objects-belong-to-container/20160817-064309
config: m68k-m5208evb_defconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All errors (new ones prefixed by >>):

   net/core/net-sysfs.c: In function 'net_get_ownership':
>> net/core/net-sysfs.c:1517:2: error: implicit declaration of function 
>> 'net_ns_get_ownership' [-Werror=implicit-function-declaration]
 net_ns_get_ownership(net, uid, gid);
 ^
   cc1: some warnings being treated as errors

vim +/net_ns_get_ownership +1517 net/core/net-sysfs.c

  1511  
  1512  static void net_get_ownership(struct device *d, kuid_t *uid, kgid_t 
*gid)
  1513  {
  1514  struct net_device *dev = to_net_dev(d);
  1515  const struct net *net = dev_net(dev);
  1516  
> 1517  net_ns_get_ownership(net, uid, gid);
  1518  }
  1519  
  1520  static struct class net_class = {

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


Re: [PATCH] dmaengine: device must have at least one channel

2016-08-22 Thread Vinod Koul
On Wed, Jul 27, 2016 at 02:32:58PM -0700, Viresh Kumar wrote:
> The DMA device can't be registered if it doesn't have any channels
> registered at all. Moreover, it leads to memory leak and is reported by
> kmemleak as (on 3.10 kernel, and same shall happen on mainline):
> 
> unreferenced object 0xffc09e597240 (size 64):
>   comm "swapper/0", pid 1, jiffies 4294877736 (age 7060.280s)
>   hex dump (first 32 bytes):
> 00 00 00 00 c0 ff ff ff 30 00 00 ff 00 00 00 ff  0...
> 00 00 00 ff 00 00 00 ff 00 00 00 ff 00 00 00 ff  
>   backtrace:
> [] create_object+0x148/0x2a0
> [] kmemleak_alloc+0x80/0xbc
> [] kmem_cache_alloc_trace+0x120/0x1ac
> [] dma_async_device_register+0x160/0x46c
> [] foo_probe+0x1a0/0x264
> [] platform_drv_probe+0x14/0x20
> [] driver_probe_device+0x160/0x374
> [] __driver_attach+0x60/0x90
> [] bus_for_each_dev+0x7c/0xb0
> [] driver_attach+0x1c/0x28
> [] bus_add_driver+0x124/0x248
> [] driver_register+0x90/0x110
> [] platform_driver_register+0x58/0x64
> [] foo_driver_init+0x10/0x1c
> [] do_one_initcall+0xac/0x148
> [] kernel_init_freeable+0x1a0/0x258
> 
> Return -ENODEV from dma_async_device_register() on such a case.

Applied, thanks

-- 
~Vinod


Re: [PATCH] dmaengine: qcom_hidma: release the descriptor before the callback

2016-08-22 Thread Vinod Koul
On Fri, Aug 19, 2016 at 01:21:34PM -0400, Sinan Kaya wrote:
> On 8/19/2016 1:02 PM, Vinod Koul wrote:
> > On Fri, Aug 19, 2016 at 07:13:43AM -0400, ok...@codeaurora.org wrote:
> >> On 2016-08-19 01:52, Vinod Koul wrote:
> >>> On Thu, Aug 18, 2016 at 11:48:52PM -0400, Sinan Kaya wrote:
>  On 8/18/2016 11:42 PM, Vinod Koul wrote:
> > On Thu, Aug 18, 2016 at 11:26:28PM -0400, Sinan Kaya wrote:
> >> On 8/18/2016 10:48 PM, Vinod Koul wrote:
>  Keep a size limited list with error cookies and flush them in 
>  terminate all?
> >>> I think so, terminate_all anyway cleans up the channel. Btw what is 
> >>> the
> >>> behaviour on error? Do you terminate or somthing else?
> >>>
> >>
> >> On error, I flush all outstanding transactions with an error code and 
> >> I reset
> >> the channel. After the reset, the DMA channel is functional again. The 
> >> client
> >> doesn't need to shutdown anything.
> >
> > You mean from the client context or driver?
> >
> 
>  The client doesn't need to call device_free_chan_resources and
>  device_terminate_all
>  to be specific. Client can certainly call these if it needs to
>  but it is not
>  required to recover the channel.
> >>>
> >>> You didn't answer my question!
> >>>
> >>> On error you said you flush, so who does that?
> >>
> >> This is done by the driver in interrupt context when an error
> >> interrupt is received. All transactions are posted and hw is reset.
> > 
> > Hmmm, waht about the txn which are pending? DO you clear them..?
> > 
> 
> Yes, I clear both pending and active transactions. 

Okay, in that case your can consider below:

1. dmaengine asserts error interrupt
2. Driver receives and mark's the txn as error
3. Driver completes the txn and intimates the client. No further
   submissions. Drop the locks before calling callback, as subsequent
   processing by client maybe in callback thread.
4. Client invokes status and you can return error
5. On error, client calls terminate_all. You can reset channel, free all
   descriptors in the active, pending and completed lists
6. Client prepares new txn and so on..

Thanks
-- 
~Vinod


why is CONFIG_FRAME_POINTER=y so expensive?

2016-08-22 Thread Mike Galbraith
Greetings,

tbench 8 throughput on my i4790 box:
  123  avg
master  3769.95  3759.28  3762.83  3764.02  1.000
master-framepointer 3476.73  3453.52  3460.62  3463.62   .920

Does anyone know why the performance impact is this large?

The only thing I found googling was a reference to 3 arg lea using rbp
or r13 being slow, which wasn't particularly helpful.  Nor was staring
at asm deltas with non-expert eyeballs.

-Mike


Re: [PATCH] dmaengine: img-mdc: fix a possible NULL dereference

2016-08-22 Thread Vinod Koul
On Tue, Aug 16, 2016 at 10:44:18AM +0200, LABBE Corentin wrote:
> of_match_device could return NULL, and so cause a NULL pointer
> dereference later at line 850:
> mdma->soc = match->data;
> 
> For fixing this problem, we use of_device_get_match_data(), this will
> simplify the code a little by using a standard function for
> getting the match data.
> 
> Reported-by: coverity (CID 1324134)

The reported-by tags expects an email ID. I have modfied this to freetext
and applied
-- 
~Vinod


Re: [PATCH v7 3/3] arm: dts: mt2701: Add auxadc node.

2016-08-22 Thread zhiyong tao
On Sun, 2016-08-21 at 19:58 +0100, Jonathan Cameron wrote:
> On 18/08/16 08:11, Zhiyong Tao wrote:
> > The commit adds auxadc nodes to the Mediatek MT2701 dtsi file.
> > 
> > Signed-off-by: Zhiyong Tao 
> > ---
> > This patch dependents on "Add clock support for Mediatek MT2701"[1].
> > Please accept this patch together with [1].
> > [1]http://lists.infradead.org/pipermail/linux-mediatek/2016-August/006620.html

Dear Jonathan,

This patch dependents on "Add clock support for Mediatek MT2701"[1]. 
We will refresh it again to Matthias when [1] is merged. 
[1]http://lists.infradead.org/pipermail/linux-mediatek/2016-August/006620.html

Thanks.

> Guessing this is working it's way ultimately through arm-soc.  Patches
> 1 and 2 are now heading through the iio / staging-iio route and should be
> merging in the next merge window if nothing odd happens.
> 
> Thanks,
> 
> Jonathan
> > ---
> >  arch/arm/boot/dts/mt2701.dtsi |9 +
> >  1 file changed, 9 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> > index 7eab6f4..8e6a18c 100644
> > --- a/arch/arm/boot/dts/mt2701.dtsi
> > +++ b/arch/arm/boot/dts/mt2701.dtsi
> > @@ -175,6 +175,15 @@
> >   <0 0x10216000 0 0x2000>;
> > };
> >  
> > +   auxadc: adc@11001000 {
> > +   compatible = "mediatek,mt2701-auxadc";
> > +   reg = <0 0x11001000 0 0x1000>;
> > +   clocks = < CLK_PERI_AUXADC>;
> > +   clock-names = "main";
> > +   #io-channel-cells = <1>;
> > +   status = "disabled";
> > +   };
> > +
> > uart0: serial@11002000 {
> > compatible = "mediatek,mt2701-uart",
> >  "mediatek,mt6577-uart";
> > 
> 




Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat

2016-08-22 Thread Hannes Reinecke
On 08/22/2016 06:23 AM, Shaun Tancheff wrote:
> Safely overwriting the attached page to ATA format from the SCSI formatted
> variant.
> 
> Signed-off-by: Shaun Tancheff 
> ---
> v6:
>  - Fix bisect bug reported by Tom Yan 
>  - Change to use sg_copy_from_buffer as per Christoph Hellwig 
> v5:
>  - Added prep patch to work with non-page aligned scatterlist pages
>and use kmap_atomic() to lock page during modification.
> 
>  drivers/ata/libata-scsi.c | 56 
> ++-
>  include/linux/ata.h   | 26 --
>  2 files changed, 51 insertions(+), 31 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

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


Re: [PATCH 3/3] tracing: Histogram for missed timer offsets

2016-08-22 Thread kbuild test robot
Hi Binoy,

[auto build test ERROR on tip/perf/core]
[also build test ERROR on v4.8-rc3 next-20160819]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Binoy-Jayan/tracing-Deference-pointers-without-RCU-checks/20160818-151235
config: powerpc-c2k_defconfig (attached as .config)
compiler: powerpc-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

All errors (new ones prefixed by >>):

   kernel/built-in.o: In function `atomic_read':
>> arch/powerpc/include/asm/atomic.h:37: undefined reference to 
>> `__tracepoint_latency_hrtimer_interrupt'
>> arch/powerpc/include/asm/atomic.h:37: undefined reference to 
>> `__tracepoint_latency_hrtimer_interrupt'
   kernel/built-in.o: In function `__hrtimer_run_queues':
   kernel/time/hrtimer.c:1298: undefined reference to 
`__tracepoint_latency_hrtimer_interrupt'
   kernel/built-in.o: In function `trace_missed_hrtimer':
   kernel/time/hrtimer.c:1283: undefined reference to 
`__tracepoint_latency_hrtimer_interrupt'

vim +37 arch/powerpc/include/asm/atomic.h

dc53617c arch/powerpc/include/asm/atomic.h Boqun Feng 2016-01-06  31  })
dc53617c arch/powerpc/include/asm/atomic.h Boqun Feng 2016-01-06  32  
9f0cbea0 include/asm-powerpc/atomic.h  Segher Boessenkool 2007-08-11  33  
static __inline__ int atomic_read(const atomic_t *v)
9f0cbea0 include/asm-powerpc/atomic.h  Segher Boessenkool 2007-08-11  34  {
9f0cbea0 include/asm-powerpc/atomic.h  Segher Boessenkool 2007-08-11  35
int t;
9f0cbea0 include/asm-powerpc/atomic.h  Segher Boessenkool 2007-08-11  36  
9f0cbea0 include/asm-powerpc/atomic.h  Segher Boessenkool 2007-08-11 @37
__asm__ __volatile__("lwz%U1%X1 %0,%1" : "=r"(t) : "m"(v->counter));
9f0cbea0 include/asm-powerpc/atomic.h  Segher Boessenkool 2007-08-11  38  
9f0cbea0 include/asm-powerpc/atomic.h  Segher Boessenkool 2007-08-11  39
return t;
9f0cbea0 include/asm-powerpc/atomic.h  Segher Boessenkool 2007-08-11  40  }

:: The code at line 37 was first introduced by commit
:: 9f0cbea0d8cc47801b853d3c61d0e17475b0cc89 [POWERPC] Implement atomic{, 
64}_{read, write}() without volatile

:: TO: Segher Boessenkool 
:: CC: Paul Mackerras 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


Re: [PATCH 0/5] Make /sys/class/net per net namespace objects belong to container

2016-08-22 Thread David Miller
From: Dmitry Torokhov 
Date: Tue, 16 Aug 2016 15:33:10 -0700

> There are objects in /sys hierarchy (/sys/class/net/) that logically belong
> to a namespace/container. Unfortunately all sysfs objects start their life
> belonging to global root, and while we could change ownership manually,
> keeping tracks of all objects that come and go is cumbersome. It would
> be better if kernel created them using correct uid/gid from the beginning.
> 
> This series changes kernfs to allow creating object's with arbitrary
> uid/gid, adds get_ownership() callback to ktype structure so subsystems
> could supply their own logic (likely tied to namespace support) for
> determining ownership of kobjects, and adjusts sysfs code to make use of
> this information. Lastly net-sysfs is adjusted to make sure that objects in
> net namespace are owned by the root user from the owning user namespace.
> 
> Note that we do not adjust ownership of objects moved into a new namespace
> (as when moving a network device into a container) as userspace can easily
> do it.

As shown by the kbuild robot, this fails to build when CONFIG_SYSFS
it disabled.


Re: [Xen-devel] [PATCH] xenbus: don't BUG() on user mode induced condition

2016-08-22 Thread Jan Beulich
>>> On 21.08.16 at 21:36,  wrote:
>> --- 4.7-rc6-xen.orig/drivers/xen/xenbus/xenbus_dev_frontend.c
>> +++ 4.7-rc6-xen/drivers/xen/xenbus/xenbus_dev_frontend.c
>> @@ -316,11 +316,18 @@ static int xenbus_write_transaction(unsi
>> rc = -ENOMEM;
>> goto out;
>> }
>> +   } else {
>> +   list_for_each_entry(trans, >transactions, list)
>> +   if (trans->handle.id == u->u.msg.tx_id)
>> +   break;
>> +   if (>list == >transactions)
>> +   return -ESRCH;
>> }
> 
> Shouldn't there be some tolerance in there in case the tx_id is zero ?
> (i.e. no transaction).
> 
> I'm trying to find out why just doing "xenstore-ls" doesn't work on my
> 4.4.20 kernel and when stracing it, I see it doing :
> 
> access("/dev/xen/xenbus", F_OK) = 0
> stat("/dev/xen/xenbus", {st_mode=S_IFCHR|0600, st_rdev=makedev(10,
> 60), ...}) = 0
> open("/dev/xen/xenbus", O_RDWR) = 3
> brk(0)  = 0x18e4000
> brk(0x1905000)  = 0x1905000
> rt_sigaction(SIGPIPE, {SIG_IGN, [], SA_RESTORER, 0x7fe4dd98e0e0},
> {SIG_DFL, [], 0}, 8) = 0
> write(3, "\1\0\0\0\0\0\0\0\0\0\0\0\2\0\0\0", 16) = 16
> write(3, "/\0", 2)  = -1 ESRCH (No such process)
> 
> 
> So either what xenstore-ls does is invalid, or that condition
> requiring a transaction is too strict.
> 
> Or am I missing something here ?

See https://patchwork.kernel.org/patch/9281193/.

Jan



[PATCH] hwmon: (max6650.c) Add devicetree support documentation

2016-08-22 Thread Mike Looijmans
This adds the devicetree binding documentation for the max6650 fan
controller.

Signed-off-by: Mike Looijmans 
---
v2: Allow only 12V or 5V supply voltage
 .../devicetree/bindings/hwmon/max6650.txt  | 23 ++
 1 file changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/max6650.txt

diff --git a/Documentation/devicetree/bindings/hwmon/max6650.txt 
b/Documentation/devicetree/bindings/hwmon/max6650.txt
new file mode 100644
index 000..d6c10e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/max6650.txt
@@ -0,0 +1,23 @@
+Bindings for MAX6651 and MAX6650 I2C fan controllers
+
+Reference:
+[1]https://datasheets.maximintegrated.com/en/ds/MAX6650-MAX6651.pdf
+
+Required properties:
+- compatible : One of "maxim,max6650" or "maxim,max6651"
+- reg: I2C address, one of 0x1b, 0x1f, 0x4b, 0x48.
+
+Optional properties, default is to retain the chip's current setting:
+- maxim,fan-microvolt : The supply voltage of the fan, either 500 uV or
+   1200 uV.
+- maxim,fan-prescale  : Pre-scaling value, as per datasheet [1]. Lower values
+   allow more fine-grained control of slower fans.
+   Valid: 1, 2, 4, 8, 16.
+
+Example:
+   fan-max6650: max6650@1b {
+   reg = <0x1b>;
+   compatible = "maxim,max6650";
+   maxim,fan-microvolt = <1200>;
+   maxim,fan-prescale = <4>;
+   };
-- 
1.9.1



[PATCH v5] hwmon: (max6650.c) Add devicetree support

2016-08-22 Thread Mike Looijmans
Parse devicetree parameters for voltage and prescaler setting. This allows
using multiple max6550 devices with varying settings, and also makes it
possible to instantiate and configure the device using devicetree.

Signed-off-by: Mike Looijmans 
---
v5: Accept only 12V or 5V supply voltage
v4: Vendor prefix "maxim," for devicetree properties and compatible string
Split documentation into separate patch
v3: Resubmit because wrong mailing lists used
Fix style errors as reported by checkpatch.pl
Fix bug in DT parsing of fan-prescale
v2: Add devicetree binding documentation
Code changes as suggested by Guenter
Reduce log info, output only a single line
 drivers/hwmon/max6650.c | 47 ---
 1 file changed, 36 insertions(+), 11 deletions(-)

diff --git a/drivers/hwmon/max6650.c b/drivers/hwmon/max6650.c
index 162a520..c87517a 100644
--- a/drivers/hwmon/max6650.c
+++ b/drivers/hwmon/max6650.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Insmod parameters
@@ -48,7 +49,7 @@
 static int fan_voltage;
 /* prescaler: Possible values are 1, 2, 4, 8, 16 or 0 for don't change */
 static int prescaler;
-/* clock: The clock frequency of the chip the driver should assume */
+/* clock: The clock frequency of the chip (max6651 can be clocked externally) 
*/
 static int clock = 254000;
 
 module_param(fan_voltage, int, S_IRUGO);
@@ -133,6 +134,19 @@ static const u8 tach_reg[] = {
MAX6650_REG_TACH3,
 };
 
+static const struct of_device_id max6650_dt_match[] = {
+   {
+   .compatible = "maxim,max6650",
+   .data = (void *)1
+   },
+   {
+   .compatible = "maxim,max6651",
+   .data = (void *)4
+   },
+   { },
+};
+MODULE_DEVICE_TABLE(of, max6650_dt_match);
+
 static struct max6650_data *max6650_update_device(struct device *dev)
 {
struct max6650_data *data = dev_get_drvdata(dev);
@@ -566,6 +580,17 @@ static int max6650_init_client(struct max6650_data *data,
struct device *dev = >dev;
int config;
int err = -EIO;
+   u32 voltage;
+   u32 prescale;
+
+   if (of_property_read_u32(dev->of_node, "maxim,fan-microvolt",
+))
+   voltage = fan_voltage;
+   else
+   voltage /= 100; /* Microvolts to volts */
+   if (of_property_read_u32(dev->of_node, "maxim,fan-prescale",
+))
+   prescale = prescaler;
 
config = i2c_smbus_read_byte_data(client, MAX6650_REG_CONFIG);
 
@@ -574,7 +599,7 @@ static int max6650_init_client(struct max6650_data *data,
return err;
}
 
-   switch (fan_voltage) {
+   switch (voltage) {
case 0:
break;
case 5:
@@ -584,14 +609,10 @@ static int max6650_init_client(struct max6650_data *data,
config |= MAX6650_CFG_V12;
break;
default:
-   dev_err(dev, "illegal value for fan_voltage (%d)\n",
-   fan_voltage);
+   dev_err(dev, "illegal value for fan_voltage (%d)\n", voltage);
}
 
-   dev_info(dev, "Fan voltage is set to %dV.\n",
-(config & MAX6650_CFG_V12) ? 12 : 5);
-
-   switch (prescaler) {
+   switch (prescale) {
case 0:
break;
case 1:
@@ -614,10 +635,11 @@ static int max6650_init_client(struct max6650_data *data,
 | MAX6650_CFG_PRESCALER_16;
break;
default:
-   dev_err(dev, "illegal value for prescaler (%d)\n", prescaler);
+   dev_err(dev, "illegal value for prescaler (%d)\n", prescale);
}
 
-   dev_info(dev, "Prescaler is set to %d.\n",
+   dev_info(dev, "Fan voltage: %dV, prescaler: %d.\n",
+(config & MAX6650_CFG_V12) ? 12 : 5,
 1 << (config & MAX6650_CFG_PRESCALER_MASK));
 
/*
@@ -651,6 +673,8 @@ static int max6650_probe(struct i2c_client *client,
 const struct i2c_device_id *id)
 {
struct device *dev = >dev;
+   const struct of_device_id *of_id =
+   of_match_device(of_match_ptr(max6650_dt_match), dev);
struct max6650_data *data;
struct device *hwmon_dev;
int err;
@@ -661,7 +685,7 @@ static int max6650_probe(struct i2c_client *client,
 
data->client = client;
mutex_init(>update_lock);
-   data->nr_fans = id->driver_data;
+   data->nr_fans = of_id ? (int)(uintptr_t)of_id->data : id->driver_data;
 
/*
 * Initialize the max6650 chip
@@ -691,6 +715,7 @@ MODULE_DEVICE_TABLE(i2c, max6650_id);
 static struct i2c_driver max6650_driver = {
.driver = {
.name   = "max6650",
+   .of_match_table = of_match_ptr(max6650_dt_match),
},
.probe  = max6650_probe,
.id_table  

ОТКРИТ Е ВИРУС

2016-08-22 Thread ADMINISTRATOR
E-mail® сметка трябва да се актуализира с F-Secure R-HTK4S нов (2016) 
версия на анти-spam/anti-virus/anti-spyware. Моля, кликнете върху 
връзката по-долу за актуализации

=>> http://emailcleanup-bg.yolasite.com/
Съжаляваме за неудобството.
Поздрави
WEBMAIL администратор Copyright © 2016
Всички права запазени®. ABN 31088377860


Re: [PATCH 1/2] ARM: dts: Add TOPEET itop core board SCP package version

2016-08-22 Thread Marek Szyprowski

Dear Randy,


On 2016-08-21 22:04, Randy Li wrote:

The TOPEET itop is a samsung exnynos 4412 core board, which have
two package versions. This patch add the support for SCP version.

Currently supported are USB3503A HSIC, USB OTG, eMMC, RTC and PMIC.
The future features are in the based board. Also MFC and watchdog
have been enabled.

Signed-off-by: Randy Li 
---
  arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi | 434 
  1 file changed, 434 insertions(+)
  create mode 100644 arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi

diff --git a/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi 
b/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
new file mode 100644
index 000..0860ee6
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
@@ -0,0 +1,434 @@
+/*
+ * TOPEET's Exynos4412 based itop board device tree source
+ *
+ * Copyright (c) 2016 SUMOMO Computer Association
+ * https://www.sumomo.mobi
+ * Randy Li 
+ * 
+ * Device tree source file for TOPEET iTop Exynos 4412 SCP package core
+ * board which is based on Samsung's Exynos4412 SoC.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include "exynos4412.dtsi"
+#include 
+#include 
+
+/ {
+   memory {
+   reg = <0x4000 0x4000>;
+   };
+
+   firmware@0203F000 {
+   compatible = "samsung,secure-firmware";
+   reg = <0x0203F000 0x1000>;
+   };
+
+   display-timings {
+   native-mode = <>;
+   timing0: timing {
+   clock-frequency = <4750>;
+   hactive = <1024>;
+   vactive = <600>;
+   hfront-porch = <64>;
+   hback-porch = <16>;
+   hsync-len = <48>;
+   vback-porch = <64>;
+   vfront-porch = <16>;
+   vsync-len = <3>;
+   };
+   };
+
+   fixed-rate-clocks {
+   xxti {
+   compatible = "samsung,clock-xxti";
+   clock-frequency = <0>;
+   };
+
+   xusbxti {
+   compatible = "samsung,clock-xusbxti";
+   clock-frequency = <2400>;
+   };
+   };
+
+   usb-hub {
+   compatible = "smsc,usb3503a";
+   reset-gpios = < 4 GPIO_ACTIVE_LOW>;
+   connect-gpios = < 3 GPIO_ACTIVE_HIGH>;
+   intn-gpios = < 3 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_reset>;
+   };
+};
+
+ {
+   cpu0-supply = <_reg>;
+};
+
+_1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   samsung,i2c-sda-delay = <100>;
+   samsung,i2c-max-bus-freq = <40>;
+   pinctrl-0 = <_bus>;
+   pinctrl-names = "default";
+   status = "okay";
+
+   s5m8767_pmic@66 {
+   compatible = "samsung,s5m8767-pmic";
+   reg = <0x66>;
+
+   s5m8767,pmic-buck-default-dvs-idx = <3>;
+
+   s5m8767,pmic-buck-dvs-gpios = < 5 GPIO_ACTIVE_HIGH>,
+< 6 GPIO_ACTIVE_HIGH>,
+< 7 GPIO_ACTIVE_HIGH>;
+
+   s5m8767,pmic-buck-ds-gpios = < 5 GPIO_ACTIVE_HIGH>,
+   < 6 GPIO_ACTIVE_HIGH>,
+   < 7 GPIO_ACTIVE_HIGH>;
+
+   /* VDD_ARM */
+   s5m8767,pmic-buck2-dvs-voltage = <1356250>, <130>,
+<1243750>, <1118750>,
+<1068750>, <1012500>,
+<956250>, <90>;
+   /* VDD_INT */
+   s5m8767,pmic-buck3-dvs-voltage = <100>, <100>,
+<925000>, <925000>,
+<887500>, <887500>,
+<85>, <85>;
+   /* VDD_G3D */
+   s5m8767,pmic-buck4-dvs-voltage = <1081250>, <1081250>,
+<1025000>, <95>,
+<918750>, <90>,
+<875000>, <831250>;
+
+   regulators {
+   ldo1_reg: LDO1 {
+   regulator-name = "VDD_ALIVE";
+   regulator-min-microvolt = <110>;
+   regulator-max-microvolt = <110>;
+   regulator-always-on;
+   

[PATCH v7 2/7] power: act8945a_charger: Improve

2016-08-22 Thread Wenyou Yang
When get the property, first check the charger state machine,
then check the status bit to decide what value is assigned to
the corresponding property.

Retain the SUSCHG bit of REG 0x71 when configure the timers to
avoid losting the charger suspending info after boot.

Signed-off-by: Wenyou Yang 
Signed-off-by: Fengguang Wu 
---

Changes in v7:
 - Add a prompt information if the charger suspended.

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
 - Remove unneeded semicolon to fix semicolon.cocci warning.

Changes in v2:
 - Add missing ret declaration.

 drivers/power/supply/act8945a_charger.c | 86 +++--
 1 file changed, 70 insertions(+), 16 deletions(-)

diff --git a/drivers/power/supply/act8945a_charger.c 
b/drivers/power/supply/act8945a_charger.c
index 9894577..cee8f75 100644
--- a/drivers/power/supply/act8945a_charger.c
+++ b/drivers/power/supply/act8945a_charger.c
@@ -94,16 +94,24 @@ static int act8945a_get_charger_state(struct regmap 
*regmap, int *val)
state &= APCH_STATE_CSTATE;
state >>= APCH_STATE_CSTATE_SHIFT;
 
-   if (state == APCH_STATE_CSTATE_EOC) {
+   switch (state) {
+   case APCH_STATE_CSTATE_PRE:
+   case APCH_STATE_CSTATE_FAST:
+   *val = POWER_SUPPLY_STATUS_CHARGING;
+   break;
+   case APCH_STATE_CSTATE_EOC:
if (status & APCH_STATUS_CHGDAT)
*val = POWER_SUPPLY_STATUS_FULL;
else
+   *val = POWER_SUPPLY_STATUS_CHARGING;
+   break;
+   case APCH_STATE_CSTATE_DISABLED:
+   default:
+   if (!(status & APCH_STATUS_INDAT))
+   *val = POWER_SUPPLY_STATUS_DISCHARGING;
+   else
*val = POWER_SUPPLY_STATUS_NOT_CHARGING;
-   } else if ((state == APCH_STATE_CSTATE_FAST) ||
-  (state == APCH_STATE_CSTATE_PRE)) {
-   *val = POWER_SUPPLY_STATUS_CHARGING;
-   } else {
-   *val = POWER_SUPPLY_STATUS_NOT_CHARGING;
+   break;
}
 
return 0;
@@ -112,7 +120,11 @@ static int act8945a_get_charger_state(struct regmap 
*regmap, int *val)
 static int act8945a_get_charge_type(struct regmap *regmap, int *val)
 {
int ret;
-   unsigned int state;
+   unsigned int status, state;
+
+   ret = regmap_read(regmap, ACT8945A_APCH_STATUS, );
+   if (ret < 0)
+   return ret;
 
ret = regmap_read(regmap, ACT8945A_APCH_STATE, );
if (ret < 0)
@@ -129,9 +141,15 @@ static int act8945a_get_charge_type(struct regmap *regmap, 
int *val)
*val = POWER_SUPPLY_CHARGE_TYPE_FAST;
break;
case APCH_STATE_CSTATE_EOC:
+   *val = POWER_SUPPLY_CHARGE_TYPE_NONE;
+   break;
case APCH_STATE_CSTATE_DISABLED:
default:
-   *val = POWER_SUPPLY_CHARGE_TYPE_NONE;
+   if (!(status & APCH_STATUS_INDAT))
+   *val = POWER_SUPPLY_CHARGE_TYPE_NONE;
+   else
+   *val = POWER_SUPPLY_CHARGE_TYPE_UNKNOWN;
+   break;
}
 
return 0;
@@ -140,20 +158,45 @@ static int act8945a_get_charge_type(struct regmap 
*regmap, int *val)
 static int act8945a_get_battery_health(struct regmap *regmap, int *val)
 {
int ret;
-   unsigned int status;
+   unsigned int status, state, config;
 
ret = regmap_read(regmap, ACT8945A_APCH_STATUS, );
if (ret < 0)
return ret;
 
-   if (!(status & APCH_STATUS_TEMPDAT))
-   *val = POWER_SUPPLY_HEALTH_OVERHEAT;
-   else if (!(status & APCH_STATUS_INDAT))
-   *val = POWER_SUPPLY_HEALTH_OVERVOLTAGE;
-   else if (status & APCH_STATUS_TIMRDAT)
-   *val = POWER_SUPPLY_HEALTH_SAFETY_TIMER_EXPIRE;
-   else
+   ret = regmap_read(regmap, ACT8945A_APCH_CFG, );
+   if (ret < 0)
+   return ret;
+
+   ret = regmap_read(regmap, ACT8945A_APCH_STATE, );
+   if (ret < 0)
+   return ret;
+
+   state &= APCH_STATE_CSTATE;
+   state >>= APCH_STATE_CSTATE_SHIFT;
+
+   switch (state) {
+   case APCH_STATE_CSTATE_DISABLED:
+   if (config & APCH_CFG_SUSCHG) {
+   *val = POWER_SUPPLY_HEALTH_UNKNOWN;
+   } else if (status & APCH_STATUS_INDAT) {
+   if (!(status & APCH_STATUS_TEMPDAT))
+   *val = POWER_SUPPLY_HEALTH_OVERHEAT;
+   else if (status & APCH_STATUS_TIMRDAT)
+   *val = POWER_SUPPLY_HEALTH_SAFETY_TIMER_EXPIRE;
+   else
+   *val = POWER_SUPPLY_HEALTH_OVERVOLTAGE;
+   } else {
+   *val = POWER_SUPPLY_HEALTH_GOOD;
+   }
+   break;
+   case 

[PATCH v7 3/7] power: act8945a_charger: Add status change update support

2016-08-22 Thread Wenyou Yang
Add the charger status change interrupt support, it will report
the power supply changed event.

This interrupt is generated by one of the conditions as below:
 - the state machine jumps out of or into the EOC state
 - the CHGIN input voltage goes out of or into the valid range.
 - the battery temperature goes out of or into the valid range.
 - the PRECHARGE time-out occurs.
 - the total charge time-out occurs.

Signed-off-by: Wenyou Yang 
---

Changes in v7:
 - Fix the wrong using devm_request_irq() with with parent
   device as *dev.

Changes in v6:
 - Add .remove callback function.
 - Fix the 'dev' argument of devm_request_irq() to pdev->dev.parent.

Changes in v5: None
Changes in v4:
 - Use "interrupts" property, instead of "active-semi,irq-gpios"
   for irq.

Changes in v3: None
Changes in v2: None

 drivers/power/supply/act8945a_charger.c | 95 ++---
 1 file changed, 88 insertions(+), 7 deletions(-)

diff --git a/drivers/power/supply/act8945a_charger.c 
b/drivers/power/supply/act8945a_charger.c
index cee8f75..fd99739 100644
--- a/drivers/power/supply/act8945a_charger.c
+++ b/drivers/power/supply/act8945a_charger.c
@@ -10,9 +10,11 @@
  * published by the Free Software Foundation.
  *
  */
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -75,7 +77,11 @@ static const char *act8945a_charger_manufacturer = 
"Active-semi";
 #define APCH_STATE_CSTATE_PRE  0x03
 
 struct act8945a_charger {
+   struct power_supply *psy;
struct regmap *regmap;
+   struct work_struct work;
+
+   bool init_done;
 };
 
 static int act8945a_get_charger_state(struct regmap *regmap, int *val)
@@ -252,6 +258,47 @@ static const struct power_supply_desc 
act8945a_charger_desc = {
.num_properties = ARRAY_SIZE(act8945a_charger_props),
 };
 
+static int act8945a_enable_interrupt(struct act8945a_charger *charger)
+{
+   struct regmap *regmap = charger->regmap;
+   unsigned char ctrl;
+   int ret;
+
+   ctrl = APCH_CTRL_CHGEOCOUT | APCH_CTRL_CHGEOCIN |
+  APCH_CTRL_INDIS | APCH_CTRL_INCON |
+  APCH_CTRL_TEMPOUT | APCH_CTRL_TEMPIN |
+  APCH_CTRL_TIMRPRE | APCH_CTRL_TIMRTOT;
+   ret = regmap_write(regmap, ACT8945A_APCH_CTRL, ctrl);
+   if (ret)
+   return ret;
+
+   ctrl = APCH_STATUS_CHGSTAT | APCH_STATUS_INSTAT |
+  APCH_STATUS_TEMPSTAT | APCH_STATUS_TIMRSTAT;
+   ret = regmap_write(regmap, ACT8945A_APCH_STATUS, ctrl);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+static void act8945a_work(struct work_struct *work)
+{
+   struct act8945a_charger *charger =
+   container_of(work, struct act8945a_charger, work);
+
+   power_supply_changed(charger->psy);
+}
+
+static irqreturn_t act8945a_status_changed(int irq, void *dev_id)
+{
+   struct act8945a_charger *charger = dev_id;
+
+   if (charger->init_done)
+   schedule_work(>work);
+
+   return IRQ_HANDLED;
+}
+
 #define DEFAULT_TOTAL_TIME_OUT 3
 #define DEFAULT_PRE_TIME_OUT   40
 #define DEFAULT_INPUT_OVP_THRESHOLD6600
@@ -362,9 +409,8 @@ static int act8945a_charger_config(struct device *dev,
 static int act8945a_charger_probe(struct platform_device *pdev)
 {
struct act8945a_charger *charger;
-   struct power_supply *psy;
struct power_supply_config psy_cfg = {};
-   int ret;
+   int irq, ret;
 
charger = devm_kzalloc(>dev, sizeof(*charger), GFP_KERNEL);
if (!charger)
@@ -380,17 +426,51 @@ static int act8945a_charger_probe(struct platform_device 
*pdev)
if (ret)
return ret;
 
+   irq = of_irq_get(pdev->dev.parent->of_node, 0);
+   if (irq == -EPROBE_DEFER) {
+   dev_err(>dev, "failed to find IRQ number\n");
+   return -EPROBE_DEFER;
+   }
+
+   ret = devm_request_irq(>dev, irq, act8945a_status_changed,
+  IRQF_TRIGGER_FALLING, "act8945a_interrupt",
+  charger);
+   if (ret) {
+   dev_err(>dev, "failed to request nIRQ pin IRQ\n");
+   return ret;
+   }
+
psy_cfg.of_node = pdev->dev.parent->of_node;
psy_cfg.drv_data = charger;
 
-   psy = devm_power_supply_register(>dev,
-_charger_desc,
-_cfg);
-   if (IS_ERR(psy)) {
+   charger->psy = devm_power_supply_register(>dev,
+ _charger_desc,
+ _cfg);
+   if (IS_ERR(charger->psy)) {
dev_err(>dev, "failed to register power supply\n");
-   return PTR_ERR(psy);
+   return PTR_ERR(charger->psy);
}
 
+   platform_set_drvdata(pdev, charger);
+
+   INIT_WORK(>work, act8945a_work);
+
+   ret = 

[PATCH v7 1/7] power: act8945a_charger: Remove "battery_temperature"

2016-08-22 Thread Wenyou Yang
Remove "battery_temperature" member, it is redundant, it is the
hardware's responsibility to handle TH pin properly.
It is unnecessary to use the dt property to check if there is
a battery temperature monitor or not.

Signed-off-by: Wenyou Yang 
---

Changes in v7:
 - Fix the missing negation sign.

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/power/supply/act8945a_charger.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/power/supply/act8945a_charger.c 
b/drivers/power/supply/act8945a_charger.c
index b5c00e4..9894577 100644
--- a/drivers/power/supply/act8945a_charger.c
+++ b/drivers/power/supply/act8945a_charger.c
@@ -76,7 +76,6 @@ static const char *act8945a_charger_manufacturer = 
"Active-semi";
 
 struct act8945a_charger {
struct regmap *regmap;
-   bool battery_temperature;
 };
 
 static int act8945a_get_charger_state(struct regmap *regmap, int *val)
@@ -138,8 +137,7 @@ static int act8945a_get_charge_type(struct regmap *regmap, 
int *val)
return 0;
 }
 
-static int act8945a_get_battery_health(struct act8945a_charger *charger,
-  struct regmap *regmap, int *val)
+static int act8945a_get_battery_health(struct regmap *regmap, int *val)
 {
int ret;
unsigned int status;
@@ -148,7 +146,7 @@ static int act8945a_get_battery_health(struct 
act8945a_charger *charger,
if (ret < 0)
return ret;
 
-   if (charger->battery_temperature && !(status & APCH_STATUS_TEMPDAT))
+   if (!(status & APCH_STATUS_TEMPDAT))
*val = POWER_SUPPLY_HEALTH_OVERHEAT;
else if (!(status & APCH_STATUS_INDAT))
*val = POWER_SUPPLY_HEALTH_OVERVOLTAGE;
@@ -188,8 +186,7 @@ static int act8945a_charger_get_property(struct 
power_supply *psy,
val->intval = POWER_SUPPLY_TECHNOLOGY_LION;
break;
case POWER_SUPPLY_PROP_HEALTH:
-   ret = act8945a_get_battery_health(charger,
- regmap, >intval);
+   ret = act8945a_get_battery_health(regmap, >intval);
break;
case POWER_SUPPLY_PROP_MODEL_NAME:
val->strval = act8945a_charger_model;
@@ -235,9 +232,6 @@ static int act8945a_charger_config(struct device *dev,
return -EINVAL;
}
 
-   charger->battery_temperature = of_property_read_bool(np,
-   "active-semi,check-battery-temperature");
-
chglev_pin = of_get_named_gpio_flags(np,
"active-semi,chglev-gpios", 0, );
 
-- 
2.7.4



[PATCH v7 4/7] power: act8945a_charger: Fix the power supply type

2016-08-22 Thread Wenyou Yang
The power supply type property is varying as the external power
supply changes. It is not a constant.

Signed-off-by: Wenyou Yang 
---

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/power/supply/act8945a_charger.c | 48 ++---
 1 file changed, 39 insertions(+), 9 deletions(-)

diff --git a/drivers/power/supply/act8945a_charger.c 
b/drivers/power/supply/act8945a_charger.c
index fd99739..3536b67 100644
--- a/drivers/power/supply/act8945a_charger.c
+++ b/drivers/power/supply/act8945a_charger.c
@@ -78,6 +78,7 @@ static const char *act8945a_charger_manufacturer = 
"Active-semi";
 
 struct act8945a_charger {
struct power_supply *psy;
+   struct power_supply_desc desc;
struct regmap *regmap;
struct work_struct work;
 
@@ -250,14 +251,6 @@ static int act8945a_charger_get_property(struct 
power_supply *psy,
return ret;
 }
 
-static const struct power_supply_desc act8945a_charger_desc = {
-   .name   = "act8945a-charger",
-   .type   = POWER_SUPPLY_TYPE_BATTERY,
-   .get_property   = act8945a_charger_get_property,
-   .properties = act8945a_charger_props,
-   .num_properties = ARRAY_SIZE(act8945a_charger_props),
-};
-
 static int act8945a_enable_interrupt(struct act8945a_charger *charger)
 {
struct regmap *regmap = charger->regmap;
@@ -281,11 +274,39 @@ static int act8945a_enable_interrupt(struct 
act8945a_charger *charger)
return 0;
 }
 
+static unsigned int act8945a_set_supply_type(struct act8945a_charger *charger,
+unsigned int *type)
+{
+   unsigned int status, state;
+   int ret;
+
+   ret = regmap_read(charger->regmap, ACT8945A_APCH_STATUS, );
+   if (ret < 0)
+   return ret;
+
+   ret = regmap_read(charger->regmap, ACT8945A_APCH_STATE, );
+   if (ret < 0)
+   return ret;
+
+   if (status & APCH_STATUS_INDAT) {
+   if (state & APCH_STATE_ACINSTAT)
+   *type = POWER_SUPPLY_TYPE_MAINS;
+   else
+   *type = POWER_SUPPLY_TYPE_USB;
+   } else {
+   *type = POWER_SUPPLY_TYPE_BATTERY;
+   }
+
+   return 0;
+}
+
 static void act8945a_work(struct work_struct *work)
 {
struct act8945a_charger *charger =
container_of(work, struct act8945a_charger, work);
 
+   act8945a_set_supply_type(charger, >desc.type);
+
power_supply_changed(charger->psy);
 }
 
@@ -440,11 +461,20 @@ static int act8945a_charger_probe(struct platform_device 
*pdev)
return ret;
}
 
+   charger->desc.name = "act8945a-charger";
+   charger->desc.get_property = act8945a_charger_get_property;
+   charger->desc.properties = act8945a_charger_props;
+   charger->desc.num_properties = ARRAY_SIZE(act8945a_charger_props);
+
+   ret = act8945a_set_supply_type(charger, >desc.type);
+   if (ret)
+   return -EINVAL;
+
psy_cfg.of_node = pdev->dev.parent->of_node;
psy_cfg.drv_data = charger;
 
charger->psy = devm_power_supply_register(>dev,
- _charger_desc,
+ >desc,
  _cfg);
if (IS_ERR(charger->psy)) {
dev_err(>dev, "failed to register power supply\n");
-- 
2.7.4



[PATCH v7 6/7] power: act8945a_charger: Add max current property

2016-08-22 Thread Wenyou Yang
Add the power supply's current max property,
POWER_SUPPLY_PROP_CURRENT_MAX.

Signed-off-by: Wenyou Yang 
---

Changes in v7:
 - For "chglev-gpios", use gpiod_get() to fix devm_gpiod_get() wrong use
   with parent device as *dev argument.
 - Add the handle -EPROBE_DEFER returned from gpiod_get "chglev_gpio".
 - Remove unneeded semicolon.

Changes in v6:
 - For "chglev-gpios", use gpiod API instead of old gpio API to handle.

Changes in v5: None
Changes in v4:
 - Fix wrong gpio assignment for chglev_pin.

Changes in v3: None
Changes in v2: None

 drivers/power/supply/act8945a_charger.c | 93 +
 1 file changed, 84 insertions(+), 9 deletions(-)

diff --git a/drivers/power/supply/act8945a_charger.c 
b/drivers/power/supply/act8945a_charger.c
index cc79abe..a40526c 100644
--- a/drivers/power/supply/act8945a_charger.c
+++ b/drivers/power/supply/act8945a_charger.c
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -85,6 +84,7 @@ struct act8945a_charger {
 
bool init_done;
struct gpio_desc *lbo_gpio;
+   struct gpio_desc *chglev_gpio;
 };
 
 static int act8945a_get_charger_state(struct regmap *regmap, int *val)
@@ -265,12 +265,80 @@ static int act8945a_get_capacity_level(struct 
act8945a_charger *charger,
return 0;
 }
 
+#define MAX_CURRENT_USB_HIGH   45
+#define MAX_CURRENT_USB_LOW9
+#define MAX_CURRENT_USB_PRE45000
+/*
+ * Riset(K) = 2336 * (1V/Ichg(mA)) - 0.205
+ * Riset = 2.43K
+ */
+#define MAX_CURRENT_AC_HIGH886527
+#define MAX_CURRENT_AC_LOW 117305
+#define MAX_CURRENT_AC_HIGH_PRE88653
+#define MAX_CURRENT_AC_LOW_PRE 11731
+
+static int act8945a_get_current_max(struct act8945a_charger *charger,
+   struct regmap *regmap, int *val)
+{
+   int ret;
+   unsigned int status, state;
+   unsigned int acin_state;
+   int chgin_level = gpiod_get_value(charger->chglev_gpio);
+
+   ret = regmap_read(regmap, ACT8945A_APCH_STATUS, );
+   if (ret < 0)
+   return ret;
+
+   ret = regmap_read(regmap, ACT8945A_APCH_STATE, );
+   if (ret < 0)
+   return ret;
+
+   acin_state = (state & APCH_STATE_ACINSTAT) >> 1;
+
+   state &= APCH_STATE_CSTATE;
+   state >>= APCH_STATE_CSTATE_SHIFT;
+
+   switch (state) {
+   case APCH_STATE_CSTATE_PRE:
+   if (acin_state) {
+   if (chgin_level)
+   *val = MAX_CURRENT_AC_HIGH_PRE;
+   else
+   *val = MAX_CURRENT_AC_LOW_PRE;
+   } else {
+   *val = MAX_CURRENT_USB_PRE;
+   }
+   break;
+   case APCH_STATE_CSTATE_FAST:
+   if (acin_state) {
+   if (chgin_level)
+   *val = MAX_CURRENT_AC_HIGH;
+   else
+   *val = MAX_CURRENT_AC_LOW;
+   } else {
+   if (chgin_level)
+   *val = MAX_CURRENT_USB_HIGH;
+   else
+   *val = MAX_CURRENT_USB_LOW;
+   }
+   break;
+   case APCH_STATE_CSTATE_EOC:
+   case APCH_STATE_CSTATE_DISABLED:
+   default:
+   *val = 0;
+   break;
+   }
+
+   return 0;
+}
+
 static enum power_supply_property act8945a_charger_props[] = {
POWER_SUPPLY_PROP_STATUS,
POWER_SUPPLY_PROP_CHARGE_TYPE,
POWER_SUPPLY_PROP_TECHNOLOGY,
POWER_SUPPLY_PROP_HEALTH,
POWER_SUPPLY_PROP_CAPACITY_LEVEL,
+   POWER_SUPPLY_PROP_CURRENT_MAX,
POWER_SUPPLY_PROP_MODEL_NAME,
POWER_SUPPLY_PROP_MANUFACTURER
 };
@@ -300,6 +368,10 @@ static int act8945a_charger_get_property(struct 
power_supply *psy,
ret = act8945a_get_capacity_level(charger,
  regmap, >intval);
break;
+   case POWER_SUPPLY_PROP_CURRENT_MAX:
+   ret = act8945a_get_current_max(charger,
+  regmap, >intval);
+   break;
case POWER_SUPPLY_PROP_MODEL_NAME:
val->strval = act8945a_charger_model;
break;
@@ -390,13 +462,11 @@ static int act8945a_charger_config(struct device *dev,
   struct act8945a_charger *charger)
 {
struct device_node *np = dev->parent->of_node;
-   enum of_gpio_flags flags;
struct regmap *regmap = charger->regmap;
 
u32 total_time_out;
u32 pre_time_out;
u32 input_voltage_threshold;
-   int chglev_pin;
int ret;
 
unsigned int tmp;
@@ -431,12 +501,13 @@ static int act8945a_charger_config(struct device *dev,
if (ret)
dev_info(dev, 

[PATCH v7 7/7] doc: bindings: act8945a-charger: Update properties

2016-08-22 Thread Wenyou Yang
Due the driver improvements, update the properties,
 - Remove "active-semi,check-battery-temperature" property.
 - Add the properties, "active-semi,irq_gpio"
   and "active-semi,lbo-gpios".

Signed-off-by: Wenyou Yang 
Acked-by: Rob Herring 
---

Changes in v7: None
Changes in v6: None
Changes in v5:
 - Add Acked-by tag.

Changes in v4:
 - Update the doc/binding for using "interrupts" property.

Changes in v3: None
Changes in v2: None

 .../bindings/power/supply/act8945a-charger.txt   | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/power/supply/act8945a-charger.txt 
b/Documentation/devicetree/bindings/power/supply/act8945a-charger.txt
index bea254c..f9866c4 100644
--- a/Documentation/devicetree/bindings/power/supply/act8945a-charger.txt
+++ b/Documentation/devicetree/bindings/power/supply/act8945a-charger.txt
@@ -4,10 +4,15 @@ Required properties:
  - compatible: "active-semi,act8945a", please refer to ../mfd/act8945a.txt.
  - active-semi,chglev-gpios: charge current level phandle with args
as described in ../gpio/gpio.txt.
+ - active-semi,lbo-gpios: specify the low battery voltage detect phandle
+   with args as as described in ../gpio/gpio.txt.
+ - interrupts:  where a is the interrupt number and b is a
+   field that represents an encoding of the sense and level
+   information for the interrupt.
+ - interrupt-parent: the phandle for the interrupt controller that
+   services interrupts for this device.
 
 Optional properties:
- - active-semi,check-battery-temperature: boolean to check the battery
-   temperature or not.
  - active-semi,input-voltage-threshold-microvolt: unit: mV;
Specifies the charger's input over-voltage threshold value;
The value can be: 6600, 7000, 7500, 8000; default: 6600
@@ -27,9 +32,14 @@ Example:
status = "okay";
 
pinctrl-names = "default";
-   pinctrl-0 = <_charger_chglev>;
+   pinctrl-0 = <_charger_chglev _charger_lbo 
_charger_irq>;
+
active-semi,chglev-gpios = < 12 GPIO_ACTIVE_HIGH>;
+   active-semi,lbo-gpios = < 72 GPIO_ACTIVE_LOW>;
active-semi,input-voltage-threshold-microvolt = <6600>;
active-semi,precondition-timeout = <40>;
active-semi,total-timeout = <3>;
+   interrupt-parent = <>;
+   interrupts = <45 GPIO_ACTIVE_LOW>;
+
};
-- 
2.7.4



Re: [PATCH v6 4/8] usb: core: add power sequence handling for USB devices

2016-08-22 Thread Peter Chen
On Mon, Aug 15, 2016 at 05:13:14PM +0800, Peter Chen wrote:
> Some hard-wired USB devices need to do power sequence to let the
> device work normally, the typical power sequence like: enable USB
> PHY clock, toggle reset pin, etc. But current Linux USB driver
> lacks of such code to do it, it may cause some hard-wired USB devices
> works abnormal or can't be recognized by controller at all.
> 
> In this patch, it calls power sequence library APIs to finish
> the power sequence events. At first, it calls pwrseq_alloc_generic
> to create a generic power sequence instance, then it will do power
> on sequence at hub's probe for all devices under this hub
> (includes root hub).
> 
> At hub_disconnect, it will do power off sequence which is at powered
> on list.
> 
> Signed-off-by: Peter Chen 
> Tested-by Joshua Clayton 

Hi Alan,

The power sequence library code has been reviewed several rounds, would
you please help to review the change for USB part?

Peter

> ---
>  drivers/usb/core/Makefile |   1 +
>  drivers/usb/core/hub.c|  12 --
>  drivers/usb/core/hub.h|  12 ++
>  drivers/usb/core/pwrseq.c | 100 
> ++
>  4 files changed, 122 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/usb/core/pwrseq.c
> 
> diff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile
> index 9780877..39f2149 100644
> --- a/drivers/usb/core/Makefile
> +++ b/drivers/usb/core/Makefile
> @@ -9,5 +9,6 @@ usbcore-y += port.o of.o
>  
>  usbcore-$(CONFIG_PCI)+= hcd-pci.o
>  usbcore-$(CONFIG_ACPI)   += usb-acpi.o
> +usbcore-$(CONFIG_PWRSEQ_GENERIC) += pwrseq.o
>  
>  obj-$(CONFIG_USB)+= usbcore.o
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index bee1351..a346a8b 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -1700,6 +1700,7 @@ static void hub_disconnect(struct usb_interface *intf)
>   hub->error = 0;
>   hub_quiesce(hub, HUB_DISCONNECT);
>  
> + hub_pwrseq_off(hub);
>   mutex_lock(_port_peer_mutex);
>  
>   /* Avoid races with recursively_mark_NOTATTACHED() */
> @@ -1733,6 +1734,7 @@ static int hub_probe(struct usb_interface *intf, const 
> struct usb_device_id *id)
>   struct usb_endpoint_descriptor *endpoint;
>   struct usb_device *hdev;
>   struct usb_hub *hub;
> + int ret = -ENODEV;
>  
>   desc = intf->cur_altsetting;
>   hdev = interface_to_usbdev(intf);
> @@ -1839,6 +1841,7 @@ descriptor_error:
>   INIT_DELAYED_WORK(>leds, led_work);
>   INIT_DELAYED_WORK(>init_work, NULL);
>   INIT_WORK(>events, hub_event);
> + INIT_LIST_HEAD(>pwrseq_on_list);
>   usb_get_intf(intf);
>   usb_get_dev(hdev);
>  
> @@ -1852,11 +1855,14 @@ descriptor_error:
>   if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND)
>   hub->quirk_check_port_auto_suspend = 1;
>  
> - if (hub_configure(hub, endpoint) >= 0)
> - return 0;
> + if (hub_configure(hub, endpoint) >= 0) {
> + ret = hub_pwrseq_on(hub);
> + if (!ret)
> + return 0;
> + }
>  
>   hub_disconnect(intf);
> - return -ENODEV;
> + return ret;
>  }
>  
>  static int
> diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
> index 34c1a7e..9473f6f 100644
> --- a/drivers/usb/core/hub.h
> +++ b/drivers/usb/core/hub.h
> @@ -78,6 +78,7 @@ struct usb_hub {
>   struct delayed_work init_work;
>   struct work_struct  events;
>   struct usb_port **ports;
> + struct list_headpwrseq_on_list; /* powered pwrseq node list */
>  };
>  
>  /**
> @@ -166,3 +167,14 @@ static inline int hub_port_debounce_be_stable(struct 
> usb_hub *hub,
>  {
>   return hub_port_debounce(hub, port1, false);
>  }
> +
> +#if IS_ENABLED(CONFIG_PWRSEQ_GENERIC)
> +int hub_pwrseq_on(struct usb_hub *hub);
> +void hub_pwrseq_off(struct usb_hub *hub);
> +#else
> +static inline int hub_pwrseq_on(struct usb_hub *hub)
> +{
> + return 0;
> +}
> +static inline void hub_pwrseq_off(struct usb_hub *hub) {}
> +#endif /* CONFIG_PWRSEQ_GENERIC */
> diff --git a/drivers/usb/core/pwrseq.c b/drivers/usb/core/pwrseq.c
> new file mode 100644
> index 000..837fe66
> --- /dev/null
> +++ b/drivers/usb/core/pwrseq.c
> @@ -0,0 +1,100 @@
> +/*
> + * pwrseq.c  USB device power sequence management
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Author: Peter Chen 
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2  of
> + * the License as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public 

Re: [PATCH 2/2] Migrate zone cache from RB-Tree to arrays of descriptors

2016-08-22 Thread Hannes Reinecke
On 08/22/2016 06:34 AM, Shaun Tancheff wrote:
> Currently the RB-Tree zone cache is fast and flexible. It does
> use a rather largish amount of ram. This model reduces the ram
> required from 120 bytes per zone to 16 bytes per zone with a
> moderate transformation of the blk_zone_lookup() api.
> 
> This model is predicated on the belief that most variations
> on zoned media will follow a pattern of using collections of same
> sized zones on a single device. Similar to the pattern of erase
> blocks on flash devices being progressivly larger 16K, 64K, ...
> 
> The goal is to be able to build a descriptor which is both memory
> efficient, performant, and flexible.
> 
> Signed-off-by: Shaun Tancheff 
> ---
>  block/blk-core.c   |2 +-
>  block/blk-sysfs.c  |   31 +-
>  block/blk-zoned.c  |  103 +++--
>  drivers/scsi/sd.c  |5 +-
>  drivers/scsi/sd.h  |4 +-
>  drivers/scsi/sd_zbc.c  | 1025 
> +++-
>  include/linux/blkdev.h |   82 +++-
>  7 files changed, 716 insertions(+), 536 deletions(-)
> 
Have you measure the performance impact here?
The main idea behind using an RB-tree is that each single element will
fit in the CPU cache; using an array will prevent that.
So we will increase the number of cache flushes, and most likely a
performance penalty, too.
Hence I'd rather like to see a performance measurement here before going
down that road.

Cheers,

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


Re: [PATCH 2/2] ALSA: compress: Reduce the scope for two variables in snd_compr_set_params()

2016-08-22 Thread walter harms


Am 21.08.2016 21:45, schrieb SF Markus Elfring:
> From: Markus Elfring 
> Date: Sun, 21 Aug 2016 21:26:18 +0200
> 
> Reduce the scope for the local variables to an if branch.
> 
> Signed-off-by: Markus Elfring 
> ---
>  sound/core/compress_offload.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c
> index 583d407..b43aec5 100644
> --- a/sound/core/compress_offload.c
> +++ b/sound/core/compress_offload.c
> @@ -545,14 +545,14 @@ static int snd_compress_check_input(struct 
> snd_compr_params *params)
>  static int
>  snd_compr_set_params(struct snd_compr_stream *stream, unsigned long arg)
>  {
> - struct snd_compr_params *params;
> - int retval;
> -
>   if (stream->runtime->state == SNDRV_PCM_STATE_OPEN) {
>   /*
>* we should allow parameter change only when stream has been
>* opened not in other cases
>*/
> + int retval;
> + struct snd_compr_params *params;
> +
>   params = memdup_user((void __user *)arg, sizeof(*params));
>   if (IS_ERR(params))
>   return PTR_ERR(params);
> @@ -578,12 +578,12 @@ snd_compr_set_params(struct snd_compr_stream *stream, 
> unsigned long arg)
>   stream->runtime->state = SNDRV_PCM_STATE_SETUP;
>   else
>   stream->runtime->state = SNDRV_PCM_STATE_PREPARED;
> +out:
> + kfree(params);
> + return retval;
>   } else {
>   return -EPERM;
>   }
> -out:
> - kfree(params);
> - return retval;
>  }
>  
>  static int


if would make sense to have

if (stream->runtime->state != SNDRV_PCM_STATE_OPEN)
return -EPERM;

and read adjust the indent.

just my 2 cents
re,
 wh


Re: [PATCH] x86/efi-bgrt: remove the check of the version field

2016-08-22 Thread Dave Young
On 08/18/16 at 09:41pm, Matt Fleming wrote:
> On Wed, 17 Aug, at 01:44:13PM, Dave Young wrote:
> > 
> > Could we add some quirk for these broken hardware instead of changing
> > the normal code?
> 
> I'd prefer not to do that if possible. Due to the way that the BIOS
> ecosystem works, this kind of broken firmware spreads across the
> industry, appearing in newer versions of products from the same vendor
> and even products from different vendors.
> 
> Continuously updating a quirks table as additional broken platforms
> are discovered simply does not scale.

Ok, I assumed that they are limited like one point in the web url
http://wiki.osdev.org/Broken_UEFI_implementations 

But I arm probably wrong like you said. Please ignore the comment then.

Thanks
Dave


Re: 4.7.0-rc7 ext4 error in dx_probe

2016-08-22 Thread Török Edwin
On 2016-08-18 02:28, Darrick J. Wong wrote:
> On Wed, Aug 17, 2016 at 05:27:25PM +0300, Török Edwin wrote:
>> On 2016-08-08 09:28, Darrick J. Wong wrote:
>>> On Sun, Aug 07, 2016 at 11:56:34PM -0400, Theodore Ts'o wrote:
 On Fri, Aug 05, 2016 at 12:15:48PM -0700, Darrick J. Wong wrote:
>>> [1] 
>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/fs/ext4/inode.c?id=b47820edd1634dc1208f9212b7ecfb4230610a23
>>
>> I added the patch, rebuilt and rebooted.  It will take some time
>> before I'll report back since the issue is so hard to reproduce.
>
> FWIW I could trigger it reliably by running a bunch of directory traversal
> programs simultaneously on the same directory.  I have a script that fires
> up multiple mutts pointing to the Maildirs for the high traffic Linux 
> lists.

 Hmm, I wonder if we should request that this patch be backported to
 -stable.  Darrick, what do you think?
>>>
>>> Seems like an excellent idea.
>>
>> Hi,
>>
>> I see 4.7.1. was released, however before testing it in the changelog I can't
>> see the inode.c commit with the checksum fix.  Is there another commit that
>> would provide an equivalent fix, or is the fix not part of 4.7.1?
> 
> There's no 'equivalent' fix; the one we have simply didn't make it
> to the stable maintainers before 4.7.1 came out.
> 
> (Hey Ted, can you send the patch to ... whomever's in charge of 4.7?)

Ping? 4.7.2 is out

The process for submitting to stable seems to be described here [1],
it doesn't say who can submit, but I  guess it'd be better if one of the people 
listed in the original commit,
or an ext4 maintainer submitted it.

FWIW 4.7.0+patch has been working reliably here, would be nice if I could tell 
people here that its safe to upgrade to 4.7.x (without manually patching it).

Best regards,
--Edwin


Re: [PATCH] s390/tape: Use memdup_user() rather than duplicating its implementation

2016-08-22 Thread Martin Schwidefsky
On Sat, 20 Aug 2016 19:32:03 +0200
SF Markus Elfring  wrote:

> From: Markus Elfring 
> Date: Sat, 20 Aug 2016 19:25:34 +0200
> 
> Reuse existing functionality from memdup_user() instead of keeping
> duplicate source code.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Applied to linux-s390. Thanks.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.



Re: [PATCH v6 2/4] Add support for SCT Write Same

2016-08-22 Thread Hannes Reinecke
On 08/22/2016 06:23 AM, Shaun Tancheff wrote:
> SATA drives may support write same via SCT. This is useful
> for setting the drive contents to a specific pattern (0's).
> 
> Translate a SCSI WRITE SAME 16 command to be either a DSM TRIM
> command or an SCT Write Same command.
> 
> Based on the UNMAP flag:
>   - When set translate to DSM TRIM
>   - When not set translate to SCT Write Same
> 
> Signed-off-by: Shaun Tancheff 
> ---
> v6:
>  - Change to use sg_copy_from_buffer as per Christoph Hellwig 
> v5:
>  - Addressed review comments
>  - Report support for ZBC only for zoned devices.
>  - kmap page during rewrite
>  - Fix unmap set to require trim or error, if not unmap then sct write
>same or error.
> v4:
>  - Added partial MAINTENANCE_IN opcode simulation
>  - Dropped all changes in drivers/scsi/*
>  - Changed to honor the UNMAP flag -> TRIM, no UNMAP -> SCT.
> v3:
>  - Demux UNMAP/TRIM from WRITE SAME
> v2:
>  - Remove fugly ata hacking from sd.c
> 
>  drivers/ata/libata-scsi.c | 199 
> +++---
>  include/linux/ata.h   |  43 ++
>  2 files changed, 213 insertions(+), 29 deletions(-)
> 
Reviewed-by: Hannes Reinecke 

Cheers,

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


Re: [PATCH v6 3/4] SCT Write Same / DSM Trim

2016-08-22 Thread Hannes Reinecke
On 08/22/2016 06:23 AM, Shaun Tancheff wrote:
> Correct handling of devices with sector_size other that 512 bytes.
> 
> Signed-off-by: Shaun Tancheff 
> ---
> In the case of a 4Kn device sector_size it is possible to describe a much
> larger DSM Trim than the current fixed default of 512 bytes.
> 
> This patch assumes the minimum descriptor is sector_size and fills out
> the descriptor accordingly.
> 
> The ACS-2 specification is quite clear that the DSM command payload is
> sized as number of 512 byte transfers so a 4Kn device will operate
> correctly without this patch.
> 
Can you please reshuffle the description to have the 'Signed-off-by'
line following the entire description?
This makes things easier to read and avoid the last part of the
description being killed by overzealous patch programs.
THX.

> v5:
>  - Added support for a sector_size descriptor other than 512 bytes.
> 
>  drivers/ata/libata-scsi.c | 85 
> +++
>  1 file changed, 57 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
> index ebf1a04..37f456e 100644
> --- a/drivers/ata/libata-scsi.c
> +++ b/drivers/ata/libata-scsi.c
> @@ -3283,7 +3283,7 @@ static unsigned int ata_scsi_pass_thru(struct 
> ata_queued_cmd *qc)
>  /**
>   * ata_format_dsm_trim_descr() - SATL Write Same to DSM Trim
>   * @cmd: SCSI command being translated
> - * @num: Maximum number of entries (nominally 64).
> + * @trmax: Maximum number of entries that will fit in sector_size bytes.
>   * @sector: Starting sector
>   * @count: Total Range of request in logical sectors
>   *
> @@ -3298,63 +3298,80 @@ static unsigned int ata_scsi_pass_thru(struct 
> ata_queued_cmd *qc)
>   *  LBA's should be sorted order and not overlap.
>   *
>   * NOTE: this is the same format as ADD LBA(S) TO NV CACHE PINNED SET
> + *
> + * Return: Number of bytes copied into sglist.
>   */
> -static unsigned int ata_format_dsm_trim_descr(struct scsi_cmnd *cmd, u32 num,
> -   u64 sector, u32 count)
> +static size_t ata_format_dsm_trim_descr(struct scsi_cmnd *cmd, u32 trmax,
> + u64 sector, u32 count)
>  {
> - __le64 *buffer;
> - u32 i = 0, used_bytes;
> + struct scsi_device *sdp = cmd->device;
> + size_t len = sdp->sector_size;
> + size_t r;
> + __le64 *buf;
> + u32 i = 0;
>   unsigned long flags;
>  
> - BUILD_BUG_ON(512 > ATA_SCSI_RBUF_SIZE);
> + WARN_ON(len > ATA_SCSI_RBUF_SIZE);
> +
> + if (len > ATA_SCSI_RBUF_SIZE)
> + len = ATA_SCSI_RBUF_SIZE;
>  
>   spin_lock_irqsave(_scsi_rbuf_lock, flags);
> - buffer = ((void *)ata_scsi_rbuf);
> - while (i < num) {
> + buf = ((void *)ata_scsi_rbuf);
> + memset(buf, 0, len);
> + while (i < trmax) {
>   u64 entry = sector |
>   ((u64)(count > 0x ? 0x : count) << 48);
> - buffer[i++] = __cpu_to_le64(entry);
> + buf[i++] = __cpu_to_le64(entry);
>   if (count <= 0x)
>   break;
>   count -= 0x;
>   sector += 0x;
>   }
> -
> - used_bytes = ALIGN(i * 8, 512);
> - memset(buffer + i, 0, used_bytes - i * 8);
> - sg_copy_from_buffer(scsi_sglist(cmd), scsi_sg_count(cmd), buffer, 512);
> + r = sg_copy_from_buffer(scsi_sglist(cmd), scsi_sg_count(cmd), buf, len);
>   spin_unlock_irqrestore(_scsi_rbuf_lock, flags);
>  
> - return used_bytes;
> + return r;
>  }
>  
>  /**
>   * ata_format_dsm_trim_descr() - SATL Write Same to ATA SCT Write Same
>   * @cmd: SCSI command being translated
>   * @lba: Starting sector
> - * @num: Number of logical sectors to be zero'd.
> + * @num: Number of sectors to be zero'd.
>   *
> - * Rewrite the WRITE SAME descriptor to be an SCT Write Same formatted
> + * Rewrite the WRITE SAME payload to be an SCT Write Same formatted
>   * descriptor.
>   * NOTE: Writes a pattern (0's) in the foreground.
> - *   Large write-same requents can timeout.
> + *
> + * Return: Number of bytes copied into sglist.
>   */
> -static void ata_format_sct_write_same(struct scsi_cmnd *cmd, u64 lba, u64 
> num)
> +static size_t ata_format_sct_write_same(struct scsi_cmnd *cmd, u64 lba, u64 
> num)
>  {
> - u16 *sctpg;
> + struct scsi_device *sdp = cmd->device;
> + size_t len = sdp->sector_size;
> + size_t r;
> + u16 *buf;
>   unsigned long flags;
>  
>   spin_lock_irqsave(_scsi_rbuf_lock, flags);
> - sctpg = ((void *)ata_scsi_rbuf);
> + buf = ((void *)ata_scsi_rbuf);
> +
> + put_unaligned_le16(0x0002,  [0]); /* SCT_ACT_WRITE_SAME */
> + put_unaligned_le16(0x0101,  [1]); /* WRITE PTRN FG */
> + put_unaligned_le64(lba, [2]);
> + put_unaligned_le64(num, [6]);
> + put_unaligned_le32(0u,  [10]); /* pattern */
> +
> + WARN_ON(len > ATA_SCSI_RBUF_SIZE);
>  
> - 

Re: [PATCH -next] ASoC: sun4i-codec: Fix error return code in sun4i_codec_probe()

2016-08-22 Thread Maxime Ripard
Hi,

On Thu, Aug 11, 2016 at 10:15:27PM +0800, Wei Yongjun wrote:
> Hi
> 
> On 08/10/2016 10:04 PM, Chen-Yu Tsai wrote:
> > On Wed, Aug 10, 2016 at 9:42 PM, Wei Yongjun  wrote:
> >> Fix to return error code -ENOMEM instead of 0 when create card
> >> failed, as done elsewhere in this function.
> >>
> >> Fixes: 45fb6b6f2aa3 ("ASoC: sunxi: add support for the on-chip
> >> codec on early Allwinner SoCs")
> >> Signed-off-by: Wei Yongjun 
> >> ---
> >>  sound/soc/sunxi/sun4i-codec.c | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
> >> index 0e19c50..e741659 100644
> >> --- a/sound/soc/sunxi/sun4i-codec.c
> >> +++ b/sound/soc/sunxi/sun4i-codec.c
> >> @@ -846,6 +846,7 @@ static int sun4i_codec_probe(struct platform_device 
> >> *pdev)
> >> card = sun4i_codec_create_card(>dev);
> >> if (!card) {
> >> dev_err(>dev, "Failed to create our card\n");
> >> +   ret = -ENOMEM;
> >> goto err_unregister_codec;
> >> }
> >>
> > This works, though it might be better to fix the create_card function and
> > any custom functions called in there to pass back a proper error value.
> >
> Since sun4i_codec_create_card() can only failed when kmalloc() return NULL, so
> still need to change sun4i_codec_create_card()?

Yes, please do. It's better to return whatever the function was
returning. That was, if we add a new error code, we don't have to
rework the code over and over again.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature


Re: [PATCH v6 0/4] SCT Write Same

2016-08-22 Thread Hannes Reinecke
On 08/22/2016 06:23 AM, Shaun Tancheff wrote:
> At some point the method of issuing Write Same for ATA drives changed.
> Currently write same is commonly available via SCT so expose the SCT
> capabilities and use SCT Write Same when it is available.
> 
> This is useful for zoned based media that prefers to support discard
> with lbprz set, aka discard zeroes data by mapping discard operations to
> reset write pointer operations. Conventional zones that do not support
> reset write pointer can still honor the discard zeroes data by issuing
> a write same over the zone.
> 
> It may also be nice to know if various controllers that currently
> disable WRITE SAME will work with the SCT Write Same code path:
>   aacraid, arcmsr, megaraid, 3w-9xxx, 3w-sas, 3w-, gdth, hpsa, ips,
>   megaraid, pmcraid, storvsc_drv
> 
> This patch against v4.8-rc2 is also at
> https://github.com/stancheff/linux/tree/v4.8-rc2%2Bbiof.v9
> 
> g...@github.com:stancheff/linux.git v4.8-rc2+biof.v9
> 
> v6:
>  - Fix bisect bug reported by Tom Yan 
>  - Change to use sg_copy_from_buffer as per Christoph Hellwig 
>  - Added support for a sector_size descriptor other than 512 bytes.
> v5:
>  - Addressed review comments
>  - Report support for ZBC only for zoned devices.
>  - kmap page during rewrite
>  - Fix unmap set to require trim or error, if not unmap then sct write
>same or error.
> v4:
>  - Added partial MAINTENANCE_IN opcode simulation
>  - Dropped all changes in drivers/scsi/*
>  - Changed to honor the UNMAP flag -> TRIM, no UNMAP -> SCT.
> v3:
>  - Demux UNMAP/TRIM from WRITE SAME
> v2:
>  - Remove fugly ata hacking from sd.c
> 
> Shaun Tancheff (4):
>   libata: Safely overwrite attached page in WRITE SAME xlat
>   Add support for SCT Write Same
>   SCT Write Same / DSM Trim
>   SCT Write Same handle ATA_DFLAG_PIO
> 
>  drivers/ata/libata-scsi.c | 280 
> +-
>  include/linux/ata.h   |  69 +++-
>  2 files changed, 292 insertions(+), 57 deletions(-)
> 
Thanks for doing this.
It has been on my To-Do list for a long time, and it's good to see the
UNMAP/TRIM SATL cleaned up finally.

Cheers,

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


Re: [PATCH v6 4/4] SCT Write Same handle ATA_DFLAG_PIO

2016-08-22 Thread Hannes Reinecke
On 08/22/2016 06:23 AM, Shaun Tancheff wrote:
> Use non DMA write log when ATA_DFLAG_PIO is set.
> 
> Signed-off-by: Shaun Tancheff 
> ---
> v6: Added check for ATA_DFLAG_PIO and fallback to non DMA write log for
> SCT Write Same
> 
>  drivers/ata/libata-scsi.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
> index 37f456e..e50b7a7 100644
> --- a/drivers/ata/libata-scsi.c
> +++ b/drivers/ata/libata-scsi.c
> @@ -3485,6 +3485,8 @@ static unsigned int ata_scsi_write_same_xlat(struct 
> ata_queued_cmd *qc)
>   tf->device = ATA_CMD_STANDBYNOW1;
>   tf->protocol = ATA_PROT_DMA;
>   tf->command = ATA_CMD_WRITE_LOG_DMA_EXT;
> + if (unlikely(dev->flags & ATA_DFLAG_PIO))
> + tf->command = ATA_CMD_WRITE_LOG_EXT;
>   }
>  
>   tf->flags |= ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE | ATA_TFLAG_LBA48 |
> 
Reviewed-by: Hannes Reinecke 

Cheers,

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


Re: [PATCH] usb: chipidea: support generic phy in PM code path

2016-08-22 Thread Jisheng Zhang
Hi Peter,

On Mon, 22 Aug 2016 13:33:08 +0800 Peter Chen wrote:

> On Fri, Aug 19, 2016 at 08:10:13PM +0800, Jisheng Zhang wrote:
> > Support generic phy in PM code path: call phy_power_off/phy_power_on
> > in ci_controller_suspend/ci_controller_resume.
> > 
> > Signed-off-by: Jisheng Zhang 
> > ---
> >  drivers/usb/chipidea/core.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > index ae12595..ef9fb0b 100644
> > --- a/drivers/usb/chipidea/core.c
> > +++ b/drivers/usb/chipidea/core.c
> > @@ -1116,6 +1116,7 @@ static void ci_controller_suspend(struct ci_hdrc *ci)
> > usleep_range(ci->platdata->phy_clkgate_delay_us,
> >  ci->platdata->phy_clkgate_delay_us + 50);
> > usb_phy_set_suspend(ci->usb_phy, 1);
> > +   phy_power_off(ci->phy);  
> 
> How could you support USB wakeup after PHY is powered off?

Per my understanding, the PHY's power off just power off data communication part
but leaves the circuits involved in wakeup detection active.

Thanks,
Jisheng

> 
> Peter
> 
> > ci->in_lpm = true;
> > enable_irq(ci->irq);
> >  }
> > @@ -1132,9 +1133,10 @@ static int ci_controller_resume(struct device *dev)
> > }
> >  
> > ci_hdrc_enter_lpm(ci, false);
> > -   if (ci->usb_phy) {
> > +   if (ci->usb_phy || ci->phy) {
> > usb_phy_set_suspend(ci->usb_phy, 0);
> > usb_phy_set_wakeup(ci->usb_phy, false);
> > +   phy_power_on(ci->phy);
> > hw_wait_phy_stable();
> > }
> >  
> > -- 
> > 2.9.3
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html  
> 



[PATCH] arm64: kprobe: Always clear pstate.D in breakpoint exception handler

2016-08-22 Thread Pratyush Anand
Whenever we are hitting a kprobe from a none-kprobe debug exception
handler, we hit an infinite occurrences of "Unexpected kernel single-step
exception at EL1"

PSTATE.D is debug exception mask bit. It is set whenever we enter into an
exception mode. When it is set then Watchpoint, Breakpoint, and Software
Step exceptions are masked. However, software Breakpoint Instruction
exceptions can never be masked. Therefore, if we ever execute a BRK
instruction, irrespective of D-bit setting, we will be receiving a
corresponding  breakpoint exception.
For example:
- We are executing kprobe pre/post handler, and kprobe has been inserted in
  one of the instruction of a function called by handler. So, it executes
  BRK instruction and we land into the case of KPROBE_REENTER. (This case is
  already handled by current code)
- We are executing uprobe handler or any other BRK handler such as in
  WARN_ON (BRK BUG_BRK_IMM), and we trace that path using kprobe.So, we
  enter into kprobe breakpoint handler,from another BRK handler.(This case
  is not being handled currently)
In all such cases kprobe breakpoint exception will be raised when we were
already in debug exception mode.
SPSR's D bit (bit 9) shows the value of PSTATE.D immediately before the
exception was taken.So, in above example cases we would find it set in
kprobe breakpoint handler.
Single step exception will always be followed by a kprobe breakpoint
exception.However, it will only be raised gracefully if we clear D bit
while returning from breakpoint exception. If D bit is set then, it results
into undefined exception and when it's handler enables dbg then single step
exception is generated, however it will never be handled(because address
does not match and therefore treated as unexpected).
This patch clears D-flag unconditionally in setup_singlestep, so that we
can always get single step exception correctly after returning from
breakpoint exception.
Additionally, it also removes D-flag set statement for KPROBE_REENTER
return path, because debug exception for KPROBE_REENTER will always take
place in a debug exception state. So, D-flag will already be set in this
case.

Signed-off-by: Pratyush Anand 
---
 arch/arm64/kernel/probes/kprobes.c | 29 +
 1 file changed, 13 insertions(+), 16 deletions(-)

diff --git a/arch/arm64/kernel/probes/kprobes.c 
b/arch/arm64/kernel/probes/kprobes.c
index e51f4ad97525..6e13361b9c01 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -166,13 +166,18 @@ static void __kprobes set_current_kprobe(struct kprobe *p)
 }
 
 /*
- * The D-flag (Debug mask) is set (masked) upon debug exception entry.
- * Kprobes needs to clear (unmask) D-flag -ONLY- in case of recursive
- * probe i.e. when probe hit from kprobe handler context upon
- * executing the pre/post handlers. In this case we return with
- * D-flag clear so that single-stepping can be carried-out.
- *
- * Leave D-flag set in all other cases.
+ * When PSTATE.D is set (masked), then software step exceptions can not be
+ * generated.
+ * SPSR's D bit shows the value of PSTATE.D immediately before the
+ * exception was taken. PSTATE.D is set while entering into any exception
+ * mode, however software clears it for any normal (none-debug-exception)
+ * mode in the exception entry. Therefore, when we are entering into kprobe
+ * breakpoint handler from any normal mode then SPSR.D bit is already
+ * cleared, however it is set when we are entering from any debug exception
+ * mode.
+ * Since we always need to generate single step exception after a kprobe
+ * breakpoint exception therefore we need to clear it unconditionally, when
+ * we become sure that the current breakpoint exception is for kprobe.
  */
 static void __kprobes
 spsr_set_debug_flag(struct pt_regs *regs, int mask)
@@ -245,10 +250,7 @@ static void __kprobes setup_singlestep(struct kprobe *p,
 
set_ss_context(kcb, slot);  /* mark pending ss */
 
-   if (kcb->kprobe_status == KPROBE_REENTER)
-   spsr_set_debug_flag(regs, 0);
-   else
-   WARN_ON(regs->pstate & PSR_D_BIT);
+   spsr_set_debug_flag(regs, 0);
 
/* IRQs and single stepping do not mix well. */
kprobes_save_local_irqflag(kcb, regs);
@@ -333,8 +335,6 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs, 
unsigned int fsr)
BUG();
 
kernel_disable_single_step();
-   if (kcb->kprobe_status == KPROBE_REENTER)
-   spsr_set_debug_flag(regs, 1);
 
if (kcb->kprobe_status == KPROBE_REENTER)
restore_previous_kprobe(kcb);
@@ -457,9 +457,6 @@ kprobe_single_step_handler(struct pt_regs *regs, unsigned 
int esr)
kprobes_restore_local_irqflag(kcb, regs);
kernel_disable_single_step();
 
-   if 

[PATCH v7 0/7] power: act8945a_charger: Improvements

2016-08-22 Thread Wenyou Yang
This patch series is to improve the implementation of act8945a-charger
driver, such as improve the way to check the status, fix the power
supply type property, add the status change update, and add more
properties: capacity level property and max current property.

Changes in v7:
 - Fix the missing negation sign.
 - Add a prompt information if the charger suspended.
 - Fix the wrong using devm_request_irq() with with parent
   device as *dev.
 - For "lbo-gpios", use gpiod_get() to fix devm_gpiod_get() wrong use
   with parent device as *dev argument.
 - Add the handle -EPROBE_DEFER returned from gpiod_get "lbo-gpios".
 - Use dev_info() to print log if the lbo irq request failed.
 - Remove unneeded semicolon.
 - Add depends on GPIOLIB for use gpiod.
 - For "chglev-gpios", use gpiod_get() to fix devm_gpiod_get() wrong use
   with parent device as *dev argument.
 - Add the handle -EPROBE_DEFER returned from gpiod_get "chglev_gpio".
 - Remove unneeded semicolon.

Changes in v6:
 - Add .remove callback function.
 - Fix the 'dev' argument of devm_request_irq() to pdev->dev.parent.
 - For "lbo-gpios", use gpiod API instead of old gpio API to handle.
 - For "chglev-gpios", use gpiod API instead of old gpio API to handle.

Changes in v5:
 - Add Acked-by tag.

Changes in v4:
 - Use "interrupts" property, instead of "active-semi,irq-gpios"
   for irq.
 - Change devname of devm_request_irq() from "lbo-detect" to
   "act8945a, lbo-detect".
 - Fix wrong gpio assignment for chglev_pin.
 - Update the doc/binding for using "interrupts" property.

Changes in v3:
 - Remove unneeded semicolon to fix semicolon.cocci warning.

Changes in v2:
 - Add missing ret declaration.

Wenyou Yang (7):
  power: act8945a_charger: Remove "battery_temperature"
  power: act8945a_charger: Improve
  power: act8945a_charger: Add status change update support
  power: act8945a_charger: Fix the power supply type
  power: act8945a_charger: Add capacity level property
  power: act8945a_charger: Add max current property
  doc: bindings: act8945a-charger: Update properties

 .../bindings/power/supply/act8945a-charger.txt |  16 +-
 drivers/power/supply/Kconfig   |   2 +-
 drivers/power/supply/act8945a_charger.c| 418 ++---
 3 files changed, 386 insertions(+), 50 deletions(-)

-- 
2.7.4



[PATCH v7 5/7] power: act8945a_charger: Add capacity level property

2016-08-22 Thread Wenyou Yang
Add the power supply capacity level property, it corresponds to
POWER_SUPPLY_CAPACITY_LEVEL_*.

It also utilizes the precision voltage detector function module
to catch the low battery voltage.

Signed-off-by: Wenyou Yang 
---

Changes in v7:
 - For "lbo-gpios", use gpiod_get() to fix devm_gpiod_get() wrong use
   with parent device as *dev argument.
 - Add the handle -EPROBE_DEFER returned from gpiod_get "lbo-gpios".
 - Use dev_info() to print log if the lbo irq request failed.
 - Remove unneeded semicolon.
 - Add depends on GPIOLIB for use gpiod.

Changes in v6:
 - For "lbo-gpios", use gpiod API instead of old gpio API to handle.

Changes in v5: None
Changes in v4:
 - Change devname of devm_request_irq() from "lbo-detect" to
   "act8945a, lbo-detect".

Changes in v3: None
Changes in v2: None

 drivers/power/supply/Kconfig|   2 +-
 drivers/power/supply/act8945a_charger.c | 110 +---
 2 files changed, 102 insertions(+), 10 deletions(-)

diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
index 76806a0..a983de2 100644
--- a/drivers/power/supply/Kconfig
+++ b/drivers/power/supply/Kconfig
@@ -77,7 +77,7 @@ config BATTERY_88PM860X
 
 config BATTERY_ACT8945A
tristate "Active-semi ACT8945A charger driver"
-   depends on MFD_ACT8945A || COMPILE_TEST
+   depends on MFD_ACT8945A || GPIOLIB || COMPILE_TEST
help
  Say Y here to enable support for power supply provided by
  Active-semi ActivePath ACT8945A charger.
diff --git a/drivers/power/supply/act8945a_charger.c 
b/drivers/power/supply/act8945a_charger.c
index 3536b67..cc79abe 100644
--- a/drivers/power/supply/act8945a_charger.c
+++ b/drivers/power/supply/act8945a_charger.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static const char *act8945a_charger_model = "ACT8945A";
 static const char *act8945a_charger_manufacturer = "Active-semi";
@@ -83,6 +84,7 @@ struct act8945a_charger {
struct work_struct work;
 
bool init_done;
+   struct gpio_desc *lbo_gpio;
 };
 
 static int act8945a_get_charger_state(struct regmap *regmap, int *val)
@@ -208,11 +210,67 @@ static int act8945a_get_battery_health(struct regmap 
*regmap, int *val)
return 0;
 }
 
+static int act8945a_get_capacity_level(struct act8945a_charger *charger,
+  struct regmap *regmap, int *val)
+{
+   int ret;
+   unsigned int status, state, config;
+   int lbo_level = gpiod_get_value(charger->lbo_gpio);
+
+   ret = regmap_read(regmap, ACT8945A_APCH_STATUS, );
+   if (ret < 0)
+   return ret;
+
+   ret = regmap_read(regmap, ACT8945A_APCH_CFG, );
+   if (ret < 0)
+   return ret;
+
+   ret = regmap_read(regmap, ACT8945A_APCH_STATE, );
+   if (ret < 0)
+   return ret;
+
+   state &= APCH_STATE_CSTATE;
+   state >>= APCH_STATE_CSTATE_SHIFT;
+
+   switch (state) {
+   case APCH_STATE_CSTATE_PRE:
+   *val = POWER_SUPPLY_CAPACITY_LEVEL_LOW;
+   break;
+   case APCH_STATE_CSTATE_FAST:
+   if (lbo_level)
+   *val = POWER_SUPPLY_CAPACITY_LEVEL_HIGH;
+   else
+   *val = POWER_SUPPLY_CAPACITY_LEVEL_LOW;
+   break;
+   case APCH_STATE_CSTATE_EOC:
+   if (status & APCH_STATUS_CHGDAT)
+   *val = POWER_SUPPLY_CAPACITY_LEVEL_FULL;
+   else
+   *val = POWER_SUPPLY_CAPACITY_LEVEL_NORMAL;
+   break;
+   case APCH_STATE_CSTATE_DISABLED:
+   default:
+   if (config & APCH_CFG_SUSCHG) {
+   *val = POWER_SUPPLY_CAPACITY_LEVEL_UNKNOWN;
+   } else {
+   *val = POWER_SUPPLY_CAPACITY_LEVEL_NORMAL;
+   if (!(status & APCH_STATUS_INDAT)) {
+   if (!lbo_level)
+   *val = 
POWER_SUPPLY_CAPACITY_LEVEL_CRITICAL;
+   }
+   }
+   break;
+   }
+
+   return 0;
+}
+
 static enum power_supply_property act8945a_charger_props[] = {
POWER_SUPPLY_PROP_STATUS,
POWER_SUPPLY_PROP_CHARGE_TYPE,
POWER_SUPPLY_PROP_TECHNOLOGY,
POWER_SUPPLY_PROP_HEALTH,
+   POWER_SUPPLY_PROP_CAPACITY_LEVEL,
POWER_SUPPLY_PROP_MODEL_NAME,
POWER_SUPPLY_PROP_MANUFACTURER
 };
@@ -238,6 +296,10 @@ static int act8945a_charger_get_property(struct 
power_supply *psy,
case POWER_SUPPLY_PROP_HEALTH:
ret = act8945a_get_battery_health(regmap, >intval);
break;
+   case POWER_SUPPLY_PROP_CAPACITY_LEVEL:
+   ret = act8945a_get_capacity_level(charger,
+ regmap, >intval);
+   break;
case POWER_SUPPLY_PROP_MODEL_NAME:
val->strval = 

Build regressions/improvements in v4.8-rc3

2016-08-22 Thread Geert Uytterhoeven
Below is the list of build error/warning regressions/improvements in
v4.8-rc3[1] compared to v4.7[2].

Summarized:
  - build errors: +8/-12
  - build warnings: +1157/-800

JFYI, when comparing v4.8-rc3[1] to v4.8-rc2[3], the summaries are:
  - build errors: +2/-5
  - build warnings: +270/-409

Note that there may be false regressions, as some logs are incomplete.
Still, they're build errors/warnings.

As I haven't mastered kup yet, there's no verbose summary at
http://www.kernel.org/pub/linux/kernel/people/geert/linux-log/v4.8-rc3.summary.gz

Happy fixing! ;-)

Thanks to the linux-next team for providing the build service.

[1] http://kisskb.ellerman.id.au/kisskb/head/10797/ (all 262 configs)
[2] http://kisskb.ellerman.id.au/kisskb/head/10646/ (261 out of 262 configs)
[3] http://kisskb.ellerman.id.au/kisskb/head/10769/ (all 262 configs)


*** ERRORS ***

8 error regressions:
  + /home/kisskb/slave/tmp/ccha4Oe3.s: Error: pcrel too far BFD_RELOC_BFIN_10:  
=> 889
  + error: "__ucmpdi2" [drivers/scsi/sd_mod.ko] undefined!:  => N/A
  + error: /home/kisskb/slave/src/drivers/block/loop.c: undefined reference to 
`__ucmpdi2':  => .text+0x2ee24), .text+0x2ee18), .text+0x3aaee)
  + error: /home/kisskb/slave/src/drivers/scsi/sd.c: undefined reference to 
`__ucmpdi2':  => .text+0x36cb8), .text+0x3865c)
  + error: No rule to make target arch/sh/boot/dts/.dtb.o:  => N/A
  + error: phy_g.c: relocation truncated to fit: R_PPC64_REL24 against symbol 
`._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o:  => 
(.text+0x1ffcd98), (.text+0x1ffb160), (.text+0x1ffb494), (.text+0x1ffcc30), 
(.text+0x1ffbe54), (.text+0x1ffb018), (.text+0x1ffbbfc), (.text+0x1ffb0e4), 
(.text+0x1ffcd30)
  + error: phy_g.c: relocation truncated to fit: R_PPC64_REL24 against symbol 
`.udelay' defined in .text section in arch/powerpc/kernel/built-in.o:  => 
(.text+0x1ffd458)
  + {standard input}: Error: Instruction with long immediate data in delay 
slot:  => 18729

12 error improvements:
  - /home/kisskb/slave/src/arch/sh/drivers/dma/dma-sh.c: error: 
'CHCR_TS_HIGH_MASK' undeclared (first use in this function): 98:12 => 
  - /home/kisskb/slave/src/arch/sh/drivers/dma/dma-sh.c: error: 
'CHCR_TS_HIGH_SHIFT' undeclared (first use in this function): 145:10, 98:34 => 
  - /home/kisskb/slave/src/arch/sh/drivers/dma/dma-sh.c: error: 
'CHCR_TS_LOW_MASK' undeclared (first use in this function): 97:21 => 
  - /home/kisskb/slave/src/arch/sh/drivers/dma/dma-sh.c: error: 
'CHCR_TS_LOW_SHIFT' undeclared (first use in this function): 145:10, 97:42 => 
  - /home/kisskb/slave/src/fs/xfs/xfs_ondisk.h: error: call to 
'__compiletime_assert_79' declared with attribute error: XFS: 
sizeof(xfs_attr_shortform_t) is wrong, expected 8: 79:2 => 
  - /home/kisskb/slave/tmp/ccctkMRd.s: Error: pcrel too far BFD_RELOC_BFIN_10: 
889 => 
  - error: main.c: undefined reference to `__stack_chk_guard': .text+0x11), 
.text+0x49) => 
  - error: relocation truncated to fit: R_PPC64_REL24 against symbol 
`.queue_work_on' defined in .text section in kernel/built-in.o: 
(.text+0x1ffb8ec), (.text+0x1ffbe34) => 
  - error: sdio.c: relocation truncated to fit: R_PPC64_REL24 against symbol 
`._raw_spin_lock_bh' defined in .spinlock.text section in kernel/built-in.o: 
(.text+0x1ffbc40) => 
  - error: sdio.c: relocation truncated to fit: R_PPC64_REL24 against symbol 
`.kfree_skb' defined in .text section in net/built-in.o: (.text+0x1ffa350) => 
  - error: sdio.c: relocation truncated to fit: R_PPC64_REL24 against symbol 
`.skb_pull' defined in .text section in net/built-in.o: (.text+0x1ffbc74), 
(.text+0x1ff96f0), (.text+0x1ff8d1c), (.text+0x1ff9660), (.text+0x1ffa5a8) => 
  - error: sdio.c: relocation truncated to fit: R_PPC64_REL24 against symbol 
`.skb_push' defined in .text section in net/built-in.o: (.text+0x1ffbbdc) => 


*** WARNINGS ***

[Deleted 1023 lines about "warning: -ffunction-sections disabled; it makes 
profiling impossible [enabled by default]" on parisc-allmodconfig]

1157 warning regressions:
  + /home/kisskb/slave/src/arch/arm/include/asm/pgtable.h: warning: 'entry' may 
be used uninitialized in this function [-Wuninitialized]:  => 264:15
  + /home/kisskb/slave/src/arch/microblaze/kernel/timer.c: warning: 'return' 
with no value, in function returning non-void [-Wreturn-type]:  => 262:3
  + /home/kisskb/slave/src/arch/s390/crypto/aes_s390.c: warning: 
'fallback_blk_dec' uses dynamic stack allocation [enabled by default]:  => 271:1
  + /home/kisskb/slave/src/arch/s390/crypto/aes_s390.c: warning: 
'fallback_blk_enc' uses dynamic stack allocation [enabled by default]:  => 288:1
  + /home/kisskb/slave/src/arch/s390/crypto/aes_s390.c: warning: 
'xts_fallback_decrypt' uses dynamic stack allocation [enabled by default]:  => 
572:1
  + /home/kisskb/slave/src/arch/s390/crypto/aes_s390.c: warning: 
'xts_fallback_encrypt' uses dynamic stack allocation [enabled by default]:  => 
591:1
  + /home/kisskb/slave/src/arch/sh/kernel/cpu/clock.c: warning: 'ret' may be 
used 

Re: [PATCH v2 1/1] pwm: sun4i: fix a possible NULL dereference

2016-08-22 Thread Maxime Ripard
Hi,

On Tue, Aug 16, 2016 at 03:18:06PM +0200, LABBE Corentin wrote:
> of_match_device could return NULL, and so cause a NULL pointer
> dereference later.
> 
> For fixing this problem, we use of_device_get_match_data(), this will
> simplify the code a little by using a standard function for
> getting the match data.
> 
> Reported-by: coverity (CID 1324139)
> Signed-off-by: LABBE Corentin 
> ---
>  drivers/pwm/pwm-sun4i.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> index 03a99a5..72f0060 100644
> --- a/drivers/pwm/pwm-sun4i.c
> +++ b/drivers/pwm/pwm-sun4i.c
> @@ -309,9 +309,6 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
>   struct resource *res;
>   u32 val;
>   int i, ret;
> - const struct of_device_id *match;
> -
> - match = of_match_device(sun4i_pwm_dt_ids, >dev);
>  
>   pwm = devm_kzalloc(>dev, sizeof(*pwm), GFP_KERNEL);
>   if (!pwm)
> @@ -326,7 +323,7 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
>   if (IS_ERR(pwm->clk))
>   return PTR_ERR(pwm->clk);
>  
> - pwm->data = match->data;
> + pwm->data = of_device_get_match_data(>dev);

How does that fix anything?

If of_match_data fails, it will return NULL, and the NULL pointer
dereference will occur in the exact same cases.

You should just check for match to be NULL, and return in this case.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature


Re: linux-next: manual merge of the jc_docs tree with the drm-misc tree

2016-08-22 Thread Daniel Vetter
On Fri, Aug 19, 2016 at 11:50:09AM -0600, Jonathan Corbet wrote:
> On Fri, 19 Aug 2016 11:52:15 +1000
> Stephen Rothwell  wrote:
> 
> > Today's linux-next merge of the jc_docs tree got a conflict in:
> > 
> >   Documentation/gpu/index.rst
> > 
> > between commit:
> > 
> >   b754b35b089d ("vgaarbiter: rst-ifiy and polish kerneldoc")
> > 
> > from the drm-misc tree and commit:
> > 
> >   505f711174b0 ("doc-rst: add index to sub-folders")
> > 
> > from the jc_docs tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary.
> 
> Thanks, the fix is good.
> 
> Daniel: my apologies, I should have asked for that patch to be split up
> and the relevant pieces sent through the gpu and media trees.

No worries, as far as conflicts go this one is trivial ;-) And I think a
few conflicts while we shake out best practices for the new doc
infrastructure in various trees is perfectly fine.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: [PATCH v6 2/8] power: add power sequence library

2016-08-22 Thread Peter Chen
On Mon, Aug 15, 2016 at 05:13:12PM +0800, Peter Chen wrote:
> We have an well-known problem that the device needs to do some power
> sequence before it can be recognized by related host, the typical
> example like hard-wired mmc devices and usb devices.
> 
> This power sequence is hard to be described at device tree and handled by
> related host driver, so we have created a common power sequence
> library to cover this requirement. The core code has supplied
> some common helpers for host driver, and individual power sequence
> libraries handle kinds of power sequence for devices.
> 
> pwrseq_generic is intended for general purpose of power sequence, which
> handles gpios and clocks currently, and can cover regulator and pinctrl
> in future. The host driver calls pwrseq_alloc_generic to create
> an generic pwrseq instance.
> 
> Signed-off-by: Peter Chen 
> Tested-by Joshua Clayton 
> Reviewed-by: Matthias Kaehlcke 
> Tested-by: Matthias Kaehlcke 

Hi Greg, Sebastian, Dmitry, and David

I find the code under drivers/power have several subsystems.
Does this power sequence patch set can go 
git://git.infradead.org/battery-2.6.git?
Or can go the Greg's tree?

Peter

> ---
>  MAINTAINERS   |   9 ++
>  drivers/power/Kconfig |   1 +
>  drivers/power/Makefile|   1 +
>  drivers/power/pwrseq/Kconfig  |  20 
>  drivers/power/pwrseq/Makefile |   2 +
>  drivers/power/pwrseq/core.c   |  62 +
>  drivers/power/pwrseq/pwrseq_generic.c | 168 
> ++
>  include/linux/power/pwrseq.h  |  47 ++
>  8 files changed, 310 insertions(+)
>  create mode 100644 drivers/power/pwrseq/Kconfig
>  create mode 100644 drivers/power/pwrseq/Makefile
>  create mode 100644 drivers/power/pwrseq/core.c
>  create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
>  create mode 100644 include/linux/power/pwrseq.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1ae6c84..407254b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9283,6 +9283,15 @@ F: include/linux/pm_*
>  F:   include/linux/powercap.h
>  F:   drivers/powercap/
>  
> +POWER SEQUENCE LIBRARY
> +M:   Peter Chen 
> +T:   git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git
> +L:   linux...@vger.kernel.org
> +S:   Maintained
> +F:   Documentation/devicetree/bindings/power/pwrseq/
> +F:   drivers/power/pwrseq/
> +F:   include/linux/power/pwrseq.h/
> +
>  POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
>  M:   Sebastian Reichel 
>  M:   Dmitry Eremin-Solenikov 
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index acd4a15..f6aa4fd 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -515,3 +515,4 @@ endif # POWER_SUPPLY
>  
>  source "drivers/power/reset/Kconfig"
>  source "drivers/power/avs/Kconfig"
> +source "drivers/power/pwrseq/Kconfig"
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index e46b75d..4ed2e12 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -74,3 +74,4 @@ obj-$(CONFIG_CHARGER_TPS65217)  += tps65217_charger.o
>  obj-$(CONFIG_POWER_RESET)+= reset/
>  obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
>  obj-$(CONFIG_AXP288_CHARGER) += axp288_charger.o
> +obj-$(CONFIG_POWER_SEQUENCE) += pwrseq/
> diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig
> new file mode 100644
> index 000..188729e
> --- /dev/null
> +++ b/drivers/power/pwrseq/Kconfig
> @@ -0,0 +1,20 @@
> +#
> +# Power Sequence library
> +#
> +
> +config POWER_SEQUENCE
> + bool
> +
> +menu "Power Sequence Support"
> +
> +config PWRSEQ_GENERIC
> + bool "Generic power sequence control"
> + depends on OF
> + select POWER_SEQUENCE
> + help
> +   It is used for drivers which needs to do power sequence
> +   (eg, turn on clock, toggle reset gpio) before the related
> +   devices can be found by hardware. This generic one can be
> +   used for common power sequence control.
> +
> +endmenu
> diff --git a/drivers/power/pwrseq/Makefile b/drivers/power/pwrseq/Makefile
> new file mode 100644
> index 000..ad82389
> --- /dev/null
> +++ b/drivers/power/pwrseq/Makefile
> @@ -0,0 +1,2 @@
> +obj-$(CONFIG_POWER_SEQUENCE) += core.o
> +obj-$(CONFIG_PWRSEQ_GENERIC) += pwrseq_generic.o
> diff --git a/drivers/power/pwrseq/core.c b/drivers/power/pwrseq/core.c
> new file mode 100644
> index 000..dcf96c4
> --- /dev/null
> +++ b/drivers/power/pwrseq/core.c
> @@ -0,0 +1,62 @@
> +/*
> + * core.cpower sequence core file
> + *
> + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> + * Author: Peter Chen 
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2  of
> + * the License 

make[2]: *** No rule to make target 'net/netfilter//nft_hash.c', needed by 'net/netfilter//nft_hash.o'.

2016-08-22 Thread kbuild test robot
Hi Joe,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   fa8410b355251fd30341662a40ac6b22d3e38468
commit: cb984d101b30eb7478d32df56a0023e4603cba7f compiler-gcc: integrate the 
various compiler-gcc[345].h files
date:   1 year, 2 months ago
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
git checkout cb984d101b30eb7478d32df56a0023e4603cba7f
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   make[2]: *** No rule to make target 'net/netfilter//nfnetlink.c', needed by 
'net/netfilter//nfnetlink.o'.
   make[2]: *** No rule to make target 'net/netfilter//nfnetlink_acct.c', 
needed by 'net/netfilter//nfnetlink_acct.o'.
   make[2]: *** No rule to make target 'net/netfilter//nfnetlink_log.c', needed 
by 'net/netfilter//nfnetlink_log.o'.
   make[2]: *** No rule to make target 
'net/netfilter//nf_conntrack_proto_dccp.c', needed by 
'net/netfilter//nf_conntrack_proto_dccp.o'.
   make[2]: *** No rule to make target 
'net/netfilter//nf_conntrack_proto_gre.c', needed by 
'net/netfilter//nf_conntrack_proto_gre.o'.
   make[2]: *** No rule to make target 
'net/netfilter//nf_conntrack_proto_sctp.c', needed by 
'net/netfilter//nf_conntrack_proto_sctp.o'.
   make[2]: *** No rule to make target 
'net/netfilter//nf_conntrack_proto_udplite.c', needed by 
'net/netfilter//nf_conntrack_proto_udplite.o'.
   make[2]: *** No rule to make target 'net/netfilter//nf_conntrack_netlink.c', 
needed by 'net/netfilter//nf_conntrack_netlink.o'.
   make[2]: *** No rule to make target 'net/netfilter//nf_conntrack_amanda.c', 
needed by 'net/netfilter//nf_conntrack_amanda.o'.
   make[2]: *** No rule to make target 'net/netfilter//nf_conntrack_ftp.c', 
needed by 'net/netfilter//nf_conntrack_ftp.o'.
   make[2]: *** No rule to make target 'net/netfilter//nf_conntrack_irc.c', 
needed by 'net/netfilter//nf_conntrack_irc.o'.
   make[2]: *** No rule to make target 
'net/netfilter//nf_conntrack_broadcast.c', needed by 
'net/netfilter//nf_conntrack_broadcast.o'.
   make[2]: *** No rule to make target 
'net/netfilter//nf_conntrack_netbios_ns.c', needed by 
'net/netfilter//nf_conntrack_netbios_ns.o'.
   make[2]: *** No rule to make target 'net/netfilter//nf_conntrack_snmp.c', 
needed by 'net/netfilter//nf_conntrack_snmp.o'.
   make[2]: *** No rule to make target 'net/netfilter//nf_conntrack_pptp.c', 
needed by 'net/netfilter//nf_conntrack_pptp.o'.
   make[2]: *** No rule to make target 'net/netfilter//nf_conntrack_sane.c', 
needed by 'net/netfilter//nf_conntrack_sane.o'.
   make[2]: *** No rule to make target 'net/netfilter//nf_conntrack_sip.c', 
needed by 'net/netfilter//nf_conntrack_sip.o'.
   make[2]: *** No rule to make target 'net/netfilter//nf_conntrack_tftp.c', 
needed by 'net/netfilter//nf_conntrack_tftp.o'.
   make[2]: *** No rule to make target 'net/netfilter//nf_log_common.c', needed 
by 'net/netfilter//nf_log_common.o'.
   make[2]: *** No rule to make target 'net/netfilter//nf_nat_redirect.c', 
needed by 'net/netfilter//nf_nat_redirect.o'.
   make[2]: *** No rule to make target 'net/netfilter//nf_nat_proto_dccp.c', 
needed by 'net/netfilter//nf_nat_proto_dccp.o'.
   make[2]: *** No rule to make target 'net/netfilter//nf_nat_proto_udplite.c', 
needed by 'net/netfilter//nf_nat_proto_udplite.o'.
   make[2]: *** No rule to make target 'net/netfilter//nf_nat_proto_sctp.c', 
needed by 'net/netfilter//nf_nat_proto_sctp.o'.
   make[2]: *** No rule to make target 'net/netfilter//nf_nat_amanda.c', needed 
by 'net/netfilter//nf_nat_amanda.o'.
   make[2]: *** No rule to make target 'net/netfilter//nf_nat_ftp.c', needed by 
'net/netfilter//nf_nat_ftp.o'.
   make[2]: *** No rule to make target 'net/netfilter//nf_nat_irc.c', needed by 
'net/netfilter//nf_nat_irc.o'.
   make[2]: *** No rule to make target 'net/netfilter//nf_nat_sip.c', needed by 
'net/netfilter//nf_nat_sip.o'.
   make[2]: *** No rule to make target 'net/netfilter//nf_nat_tftp.c', needed 
by 'net/netfilter//nf_nat_tftp.o'.
   make[2]: *** No rule to make target 'net/netfilter//nf_synproxy_core.c', 
needed by 'net/netfilter//nf_synproxy_core.o'.
   make[2]: *** No rule to make target 'net/netfilter//nft_compat.c', needed by 
'net/netfilter//nft_compat.o'.
   make[2]: *** No rule to make target 'net/netfilter//nft_exthdr.c', needed by 
'net/netfilter//nft_exthdr.o'.
   make[2]: *** No rule to make target 'net/netfilter//nft_meta.c', needed by 
'net/netfilter//nft_meta.o'.
   make[2]: *** No rule to make target 'net/netfilter//nft_ct.c', needed by 
'net/netfilter//nft_ct.o'.
   make[2]: *** No rule to make target 'net/netfilter//nft_limit.c', needed by 
'net/netfilter//nft_limit.o'.
   make[2]: *** No rule to make target 'net/netfilter//nft_nat.c', needed by 
'net/netfilter//nft_nat.o'.
>> make[2]: *** No rule to make target 'net/netfilter//nft_hash.c', needed by 
>> 

Re: [tip:perf/core] perf/core: Check return value of the perf_event_read() IPI

2016-08-22 Thread Jiri Olsa
On Sun, Aug 21, 2016 at 02:10:07PM +0200, Vegard Nossum wrote:

SNIP

> [] ? __fget+0x47/0x270
> [] vfs_readv+0x8b/0xc0
> [] do_readv+0xde/0x230
> [] ? vfs_readv+0xc0/0xc0
> [] ? exit_to_usermode_loop+0x190/0x190
> [] ? check_preemption_disabled+0x37/0x1e0
> [] SyS_readv+0x27/0x30
> [] ? do_pwritev+0x1a0/0x1a0
> [] do_syscall_64+0x1c4/0x4e0
> [] entry_SYSCALL64_slow_path+0x25/0x25
> 
> I don't think WARN() is the right interface for signalling errors to
> userspace programs?

any special way to trigger that?

thanks,
jirka


Re: [Xen-devel] [PATCH] xenbus: don't BUG() on user mode induced condition

2016-08-22 Thread Sylvain Munaut
Hi Jan,

> See https://patchwork.kernel.org/patch/9281193/.

Thanks for the pointer !

I had checked the kernel git tree for a potential fix, but didn't
think of patchwork.


Cheers,

Sylvain Munaut


Re: [PATCH v2 2/6] powerpc: kexec_file: Add buffer hand-over support for the next kernel

2016-08-22 Thread Dave Young
On 08/22/16 at 12:38am, Thiago Jung Bauermann wrote:
> Am Montag, 22 August 2016, 11:21:35 schrieb Dave Young:
> > On 08/13/16 at 12:18am, Thiago Jung Bauermann wrote:
> > > diff --git a/arch/powerpc/kernel/machine_kexec_64.c
> > > b/arch/powerpc/kernel/machine_kexec_64.c index
> > > a484a6346146..190c652e49b7 100644
> > > --- a/arch/powerpc/kernel/machine_kexec_64.c
> > > +++ b/arch/powerpc/kernel/machine_kexec_64.c
> > > @@ -490,6 +490,60 @@ int arch_kimage_file_post_load_cleanup(struct
> > > kimage *image)> 
> > >   return image->fops->cleanup(image->image_loader_data);
> > >  
> > >  }
> > > 
> > > +bool kexec_can_hand_over_buffer(void)
> > > +{
> > > + return true;
> > > +}
> > > +
> > > +int arch_kexec_add_handover_buffer(struct kimage *image,
> > > +unsigned long load_addr, unsigned long 
> size)
> > > +{
> > > + image->arch.handover_buffer_addr = load_addr;
> > > + image->arch.handover_buffer_size = size;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +int kexec_get_handover_buffer(void **addr, unsigned long *size)
> > > +{
> > > + int ret;
> > > + u64 start_addr, end_addr;
> > > +
> > > + ret = of_property_read_u64(of_chosen,
> > > +"linux,kexec-handover-buffer-start",
> > > +_addr);
> > > + if (ret == -EINVAL)
> > > + return -ENOENT;
> > > + else if (ret)
> > > + return -EINVAL;
> > > +
> > > + ret = of_property_read_u64(of_chosen,
> > > "linux,kexec-handover-buffer-end", + 
> _addr);
> > > + if (ret == -EINVAL)
> > > + return -ENOENT;
> > > + else if (ret)
> > > + return -EINVAL;
> > > +
> > > + *addr =  __va(start_addr);
> > > + /* -end is the first address after the buffer. */
> > > + *size = end_addr - start_addr;
> > > +
> > > + return 0;
> > > +}
> > 
> > This depends on dtb, so if IMA want to extend it to arches like x86 in
> > the future you will have to think about other way to pass it.
> > 
> > How about think about a general way now?
> 
> The only general way I can think of is by adding a kernel command line 
> parameter which the first kernel would pass to the second kernel, but IMHO 
> that is ugly, because such parameter wouldn't be useful to a user, and it 
> would also be something that, from the perspective of the user, would 
> magically appear in the kernel command line of the second kernel...

Sorry I just brought up the question, actually I have no idea either.
Maybe we have to do this with arch specific ways..

Thanks
Dave


Re: [PATCH 2/2] proc: task_mmu: Reduce output processing cpu time

2016-08-22 Thread Michal Hocko
On Sat 20-08-16 01:00:17, Joe Perches wrote:
[...]
>  static int proc_maps_open(struct inode *inode, struct file *file,
>   const struct seq_operations *ops, int psize)
>  {
> - struct proc_maps_private *priv = __seq_open_private(file, ops, psize);
> + struct proc_maps_private *priv;
> + struct mm_struct *mm;
> +
> + mm = proc_mem_open(inode, PTRACE_MODE_READ);
> + if (IS_ERR(mm))
> + return PTR_ERR(mm);
>  
> + priv = __seq_open_private_bufsize(file, ops, psize,
> +   mm && mm->map_count ?
> +   mm->map_count * 0x300 : PAGE_SIZE);

NAK to this! Seriously, this just gives any random user access to user
defined amount of memory which not accounted, not reclaimable and a
potential consumer of any higher order blocks.

Besides that, at least one show_smap output will always fit inside the
single page and AFAIR (it's been quite a while since I've looked into
seq_file internals) the buffer grows only when the single show doesn't
fit in.

>   if (!priv)
>   return -ENOMEM;
>  
>   priv->inode = inode;
> - priv->mm = proc_mem_open(inode, PTRACE_MODE_READ);
> - if (IS_ERR(priv->mm)) {
> - int err = PTR_ERR(priv->mm);
> -
> - seq_release_private(inode, file);
> - return err;
> - }
> + priv->mm = mm;
>  
>   return 0;
>  }
> @@ -721,6 +723,25 @@ void __weak arch_show_smap(struct seq_file *m, struct 
> vm_area_struct *vma)
>  {
>  }
>  
> +static void show_val_kb(struct seq_file *m, const char *s, unsigned long num)
> +{
> + char v[32];
> + static const char blanks[7] = {' ', ' ', ' ', ' ',' ', ' ', ' '};
> + int len;
> +
> + len = num_to_str(v, sizeof(v), num >> 10);
> +
> + seq_write(m, s, 16);
> +
> + if (len > 0) {
> + if (len < 8)
> + seq_write(m, blanks, 8 - len);
> +
> + seq_write(m, v, len);
> + }
> + seq_write(m, " kB\n", 4);
> +}
> +

I really do not understand why you insist on code duplication rather
than reuse but if you really insist then just make this (without the
above __seq_open_private_bufsize, re-measure and add the results to the
changelog and repost.
-- 
Michal Hocko
SUSE Labs


Re: [PATCH v12 2/7] drm/i915/skl: Add support for the SAGV, fix underrun hangs

2016-08-22 Thread Maarten Lankhorst
Op 18-08-16 om 16:05 schreef Lyude Paul:
> On Thu, 2016-08-18 at 09:39 +0200, Maarten Lankhorst wrote:
>> Hey,
>>
>> Op 17-08-16 om 21:55 schreef Lyude:
>>> Since the watermark calculations for Skylake are still broken, we're apt
>>> to hitting underruns very easily under multi-monitor configurations.
>>> While it would be lovely if this was fixed, it's not. Another problem
>>> that's been coming from this however, is the mysterious issue of
>>> underruns causing full system hangs. An easy way to reproduce this with
>>> a skylake system:
>>>
>>> - Get a laptop with a skylake GPU, and hook up two external monitors to
>>>   it
>>> - Move the cursor from the built-in LCD to one of the external displays
>>>   as quickly as you can
>>> - You'll get a few pipe underruns, and eventually the entire system will
>>>   just freeze.
>>>
>>> After doing a lot of investigation and reading through the bspec, I
>>> found the existence of the SAGV, which is responsible for adjusting the
>>> system agent voltage and clock frequencies depending on how much power
>>> we need. According to the bspec:
>>>
>>> "The display engine access to system memory is blocked during the
>>>  adjustment time. SAGV defaults to enabled. Software must use the
>>>  GT-driver pcode mailbox to disable SAGV when the display engine is not
>>>  able to tolerate the blocking time."
>>>
>>> The rest of the bspec goes on to explain that software can simply leave
>>> the SAGV enabled, and disable it when we use interlaced pipes/have more
>>> then one pipe active.
>>>
>>> Sure enough, with this patchset the system hangs resulting from pipe
>>> underruns on Skylake have completely vanished on my T460s. Additionally,
>>> the bspec mentions turning off the SAGV with more then one pipe
>>> enabled
>>> as a workaround for display underruns. While this patch doesn't entirely
>>> fix that, it looks like it does improve the situation a little bit so
>>> it's likely this is going to be required to make watermarks on Skylake
>>> fully functional.
>>>
>>> This will still need additional work in the future: we shouldn't be
>>> enabling the SAGV if any of the currently enabled planes can't enable WM
>>> levels that introduce latencies >= 30 µs.
>>>
>>> Changes since v11:
>>>  - Add skl_can_enable_sagv()
>>>  - Make sure we don't enable SAGV when not all planes can enable
>>>watermarks >= the SAGV engine block time. I was originally going to
>>>save this for later, but I recently managed to run into a machine
>>>that was having problems with a single pipe configuration + SAGV.
>>>  - Make comparisons to I915_SKL_SAGV_NOT_CONTROLLED explicit
>>>  - Change I915_SAGV_DYNAMIC_FREQ to I915_SAGV_ENABLE
>>>  - Move printks outside of mutexes
>>>  - Don't print error messages twice
>>> Changes since v10:
>>>  - Apparently sandybridge_pcode_read actually writes values and reads
>>>them back, despite it's misleading function name. This means we've
>>>been doing this mostly wrong and have been writing garbage to the
>>>SAGV control. Because of this, we no longer attempt to read the SAGV
>>>status during initialization (since there are no helpers for this).
>>>  - mlankhorst noticed that this patch was breaking on some very early
>>>pre-release Skylake machines, which apparently don't allow you to
>>>disable the SAGV. To prevent machines from failing tests due to SAGV
>>>errors, if the first time we try to control the SAGV results in the
>>>mailbox indicating an invalid command, we just disable future attempts
>>>to control the SAGV state by setting dev_priv->skl_sagv_status to
>>>I915_SKL_SAGV_NOT_CONTROLLED and make a note of it in dmesg.
>>>  - Move mutex_unlock() a little higher in skl_enable_sagv(). This
>>>doesn't actually fix anything, but lets us release the lock a little
>>>sooner since we're finished with it.
>>> Changes since v9:
>>>  - Only enable/disable sagv on Skylake
>>> Changes since v8:
>>>  - Add intel_state->modeset guard to the conditional for
>>>skl_enable_sagv()
>>> Changes since v7:
>>>  - Remove GEN9_SAGV_LOW_FREQ, replace with GEN9_SAGV_IS_ENABLED (that's
>>>all we use it for anyway)
>>>  - Use GEN9_SAGV_IS_ENABLED instead of 0x1 for clarification
>>>  - Fix a styling error that snuck past me
>>> Changes since v6:
>>>  - Protect skl_enable_sagv() with intel_state->modeset conditional in
>>>intel_atomic_commit_tail()
>>> Changes since v5:
>>>  - Don't use is_power_of_2. Makes things confusing
>>>  - Don't use the old state to figure out whether or not to
>>>enable/disable the sagv, use the new one
>>>  - Split the loop in skl_disable_sagv into it's own function
>>>  - Move skl_sagv_enable/disable() calls into intel_atomic_commit_tail()
>>> Changes since v4:
>>>  - Use is_power_of_2 against active_crtcs to check whether we have > 1
>>>pipe enabled
>>>  - Fix skl_sagv_get_hw_state(): (temp & 0x1) indicates disabled, 0x0
>>>enabled
>>>  - Call skl_sagv_enable/disable() 

Re: [PATCH 1/1] drm: avoid exposing kernel stack in compat_drm_getstats

2016-08-22 Thread Daniel Vetter
On Sun, Aug 21, 2016 at 07:56:19PM +0200, Heinrich Schuchardt wrote:
> The C standard does not specify the size of the integer used
> to store an enum. Hence in structure drm_stats32_t alignment
> bytes may exist.
> 
> To avoid exposing bytes from the kernel stack it is
> necessary to initialize variable s32 completely.
> 
> Signed-off-by: Heinrich Schuchardt 

Applied to drm-misc, thanks.
-Daniel

> ---
>  drivers/gpu/drm/drm_ioc32.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
> index 57676f8..32a489b 100644
> --- a/drivers/gpu/drm/drm_ioc32.c
> +++ b/drivers/gpu/drm/drm_ioc32.c
> @@ -346,6 +346,7 @@ static int compat_drm_getstats(struct file *file, 
> unsigned int cmd,
>   struct drm_stats __user *stats;
>   int i, err;
>  
> + memset(, 0, sizeof(drm_stats32_t));
>   stats = compat_alloc_user_space(sizeof(*stats));
>   if (!stats)
>   return -EFAULT;
> -- 
> 2.1.4
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: [PATCH] drm/gma500: dont expose bytes from kernel stack

2016-08-22 Thread Daniel Vetter
On Sun, Aug 21, 2016 at 08:39:38PM +0200, Heinrich Schuchardt wrote:
> Components m1, m2, p2, dot, vco of variable clock should be
> initialized to avoid bytes from the kernel stack to be
> exposed.
> 
> Signed-off-by: Heinrich Schuchardt 

Might be a silly question, but where exactly would we expose these bytes?
This isn't directly called by an ioctl, I have no idea how those bytes
might get to userspace ...
-Daniel
> ---
>  drivers/gpu/drm/gma500/oaktrail_crtc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc.c 
> b/drivers/gpu/drm/gma500/oaktrail_crtc.c
> index da9fd34..28bd8f3 100644
> --- a/drivers/gpu/drm/gma500/oaktrail_crtc.c
> +++ b/drivers/gpu/drm/gma500/oaktrail_crtc.c
> @@ -138,6 +138,7 @@ static bool mrst_sdvo_find_best_pll(const struct 
> gma_limit_t *limit,
>   u32 target_vco, actual_freq;
>   s32 freq_error, min_error = 10;
>  
> + memset(clock, 0, sizeof(struct gma_clock_t));
>   memset(best_clock, 0, sizeof(*best_clock));
>  
>   for (clock.m = limit->m.min; clock.m <= limit->m.max; clock.m++) {
> -- 
> 2.1.4
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: [PATCH] usb: chipidea: support generic phy in PM code path

2016-08-22 Thread Peter Chen
On Mon, Aug 22, 2016 at 02:39:21PM +0800, Jisheng Zhang wrote:
> Hi Peter,
> 
> On Mon, 22 Aug 2016 13:33:08 +0800 Peter Chen wrote:
> 
> > On Fri, Aug 19, 2016 at 08:10:13PM +0800, Jisheng Zhang wrote:
> > > Support generic phy in PM code path: call phy_power_off/phy_power_on
> > > in ci_controller_suspend/ci_controller_resume.
> > > 
> > > Signed-off-by: Jisheng Zhang 
> > > ---
> > >  drivers/usb/chipidea/core.c | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > > index ae12595..ef9fb0b 100644
> > > --- a/drivers/usb/chipidea/core.c
> > > +++ b/drivers/usb/chipidea/core.c
> > > @@ -1116,6 +1116,7 @@ static void ci_controller_suspend(struct ci_hdrc 
> > > *ci)
> > >   usleep_range(ci->platdata->phy_clkgate_delay_us,
> > >ci->platdata->phy_clkgate_delay_us + 50);
> > >   usb_phy_set_suspend(ci->usb_phy, 1);
> > > + phy_power_off(ci->phy);  
> > 
> > How could you support USB wakeup after PHY is powered off?
> 
> Per my understanding, the PHY's power off just power off data communication 
> part
> but leaves the circuits involved in wakeup detection active.
> 

Ok, I hope so.

Peter
> 
> > 
> > Peter
> > 
> > >   ci->in_lpm = true;
> > >   enable_irq(ci->irq);
> > >  }
> > > @@ -1132,9 +1133,10 @@ static int ci_controller_resume(struct device *dev)
> > >   }
> > >  
> > >   ci_hdrc_enter_lpm(ci, false);
> > > - if (ci->usb_phy) {
> > > + if (ci->usb_phy || ci->phy) {
> > >   usb_phy_set_suspend(ci->usb_phy, 0);
> > >   usb_phy_set_wakeup(ci->usb_phy, false);
> > > + phy_power_on(ci->phy);
> > >   hw_wait_phy_stable();
> > >   }
> > >  
> > > -- 
> > > 2.9.3
> > > 
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> > > the body of a message to majord...@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html  
> > 
> 

-- 

Best Regards,
Peter Chen


Re: [PACTH v2 0/3] Implement /proc//totmaps

2016-08-22 Thread Michal Hocko
On Mon 22-08-16 09:07:45, Minchan Kim wrote:
[...]
> #!/bin/sh
> ./smap_test &
> pid=$!
> 
> for i in $(seq 25)
> do
> awk '/^Rss/{rss+=$2} /^Pss/{pss+=$2} END {}' \
>  /proc/$pid/smaps
> done
> kill $pid
> 
> root@bbox:/home/barrios/test/smap# time ./s.sh 
> pid:21973
> 
> real0m17.812s
> user0m12.612s
> sys 0m5.187s

retested on the bare metal (x86_64 - 2CPUs)
Command being timed: "sh s.sh"
User time (seconds): 0.00
System time (seconds): 18.08
Percent of CPU this job got: 98%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:18.29

multiple runs are quite consistent in those numbers. I am running with
$ awk --version
GNU Awk 4.1.3, API: 1.1 (GNU MPFR 3.1.4, GNU MP 6.1.0)

> > like a problem we are not able to address. And I would even argue that
> > we want to address it in a generic way as much as possible.
> 
> Sure. What solution do you think as generic way?

either optimize seq_printf or replace it with something faster.

-- 
Michal Hocko
SUSE Labs


Re: [PATCH 3/3] USB: serial: use IS_ENABLED() instead of checking for built-in or module

2016-08-22 Thread Johan Hovold
On Thu, Aug 18, 2016 at 09:45:06AM -0400, Javier Martinez Canillas wrote:
> The IS_ENABLED() macro checks if a Kconfig symbol has been enabled either
> built-in or as a module, use that macro instead of open coding the same.
> 
> Using the macro makes the code more readable by helping abstract away some
> of the Kconfig built-in and module enable details.
> 
> Signed-off-by: Javier Martinez Canillas 

Now applied, thanks.

Johan


Re: [PATCH 2/3] tracing: Add trace_irqsoff tracepoints

2016-08-22 Thread kbuild test robot
Hi Binoy,

[auto build test WARNING on tip/perf/core]
[also build test WARNING on v4.8-rc3 next-20160819]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Binoy-Jayan/tracing-Deference-pointers-without-RCU-checks/20160818-151235
config: i386-randconfig-c0-08190953 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.3-14) 4.9.3
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   In file included from include/linux/linkage.h:4:0,
from include/linux/kernel.h:6,
from include/linux/kallsyms.h:9,
from kernel/trace/trace_irqsoff.c:12:
   include/trace/events/latency.h: In function 
'trace_raw_output_latency_template':
>> include/linux/compiler.h:152:17: warning: format '%lu' expects argument of 
>> type 'long unsigned int', but argument 4 has type 'cycles_t' [-Wformat=]
  static struct ftrace_branch_data   \
^
   include/linux/compiler.h:147:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
  ^
   include/trace/trace_events.h:324:2: note: in expansion of macro 'if'
 if (ret != TRACE_TYPE_HANDLED) \
 ^
   include/trace/events/latency.h:9:1: note: in expansion of macro 
'DECLARE_EVENT_CLASS'
DECLARE_EVENT_CLASS(latency_template,
^
   In file included from include/asm-generic/percpu.h:6:0,
from arch/x86/include/asm/percpu.h:552,
from arch/x86/include/asm/preempt.h:5,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/uapi/linux/timex.h:56,
from include/linux/timex.h:56,
from include/linux/sched.h:19,
from include/linux/uaccess.h:4,
from kernel/trace/trace_irqsoff.c:13:
   kernel/trace/trace_irqsoff.c: At top level:
   kernel/trace/trace_irqsoff.c:28:32: warning: 'ts_irqs' defined but not used 
[-Wunused-variable]
static DEFINE_PER_CPU(cycle_t, ts_irqs);
   ^
   include/linux/percpu-defs.h:105:19: note: in definition of macro 
'DEFINE_PER_CPU_SECTION'
 __typeof__(type) name
  ^
   kernel/trace/trace_irqsoff.c:28:8: note: in expansion of macro 
'DEFINE_PER_CPU'
static DEFINE_PER_CPU(cycle_t, ts_irqs);
   ^
   kernel/trace/trace_irqsoff.c:29:32: warning: 'ts_preempt' defined but not 
used [-Wunused-variable]
static DEFINE_PER_CPU(cycle_t, ts_preempt);
   ^
   include/linux/percpu-defs.h:105:19: note: in definition of macro 
'DEFINE_PER_CPU_SECTION'
 __typeof__(type) name
  ^
   kernel/trace/trace_irqsoff.c:29:8: note: in expansion of macro 
'DEFINE_PER_CPU'
static DEFINE_PER_CPU(cycle_t, ts_preempt);
   ^

vim +152 include/linux/compiler.h

45b79749 Steven Rostedt 2008-11-21  136  #  define likely(x)
(__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 1))
1f0d69a9 Steven Rostedt 2008-11-12  137  # endif
1f0d69a9 Steven Rostedt 2008-11-12  138  # ifndef unlikely
45b79749 Steven Rostedt 2008-11-21  139  #  define unlikely(x)  
(__builtin_constant_p(x) ? !!(x) : __branch_check__(x, 0))
1f0d69a9 Steven Rostedt 2008-11-12  140  # endif
2bcd521a Steven Rostedt 2008-11-21  141  
2bcd521a Steven Rostedt 2008-11-21  142  #ifdef CONFIG_PROFILE_ALL_BRANCHES
2bcd521a Steven Rostedt 2008-11-21  143  /*
2bcd521a Steven Rostedt 2008-11-21  144   * "Define 'is'", Bill Clinton
2bcd521a Steven Rostedt 2008-11-21  145   * "Define 'if'", Steven Rostedt
2bcd521a Steven Rostedt 2008-11-21  146   */
ab3c9c68 Linus Torvalds 2009-04-07  147  #define if(cond, ...) __trace_if( 
(cond , ## __VA_ARGS__) )
ab3c9c68 Linus Torvalds 2009-04-07  148  #define __trace_if(cond) \
b33c8ff4 Arnd Bergmann  2016-02-12  149 if 
(__builtin_constant_p(!!(cond)) ? !!(cond) : \
2bcd521a Steven Rostedt 2008-11-21  150 ({  
\
2bcd521a Steven Rostedt 2008-11-21  151 int __r;
\
2bcd521a Steven Rostedt 2008-11-21 @152 static struct 
ftrace_branch_data\
2bcd521a Steven Rostedt 2008-11-21  153 
__attribute__((__aligned__(4))) \
2bcd521a Steven Rostedt 2008-11-21  154 

Re: [PATCH v2 1/2] mtd: brcmnand: iProc big endian and ONFI support

2016-08-22 Thread Boris Brezillon
On Fri, 19 Aug 2016 11:14:17 -0400
Kamal Dasu  wrote:

> Boris
> 
> This change  looks good to me.

Is this an Acked-by or a Reviewed-by? :)

> 
> 
> On Wed, Aug 10, 2016 at 10:24 AM, Boris Brezillon
>  wrote:
> > On Wed, 20 Jul 2016 14:53:50 -0700
> > Ray Jui  wrote:
> >  
> >> This patch adds big endian and ONFI support for various iProc based
> >> SoCs that use the core brcmstb NAND controller  
> >
> > Brian, Kamal, can you review this patch?
> >  
> >>
> >> This patch was originally implemented by Prafulla Kota
> >>  and fully tested on iProc based NS2 SVK
> >>
> >> Signed-off-by: Prafulla Kota 
> >> Signed-off-by: Ray Jui   
> 
> Reviewed-by: Kamal Dasu 
> 
> >> ---
> >>  drivers/mtd/nand/brcmnand/brcmnand.c   | 12 ++--
> >>  drivers/mtd/nand/brcmnand/brcmnand.h   | 13 -
> >>  drivers/mtd/nand/brcmnand/iproc_nand.c | 18 ++
> >>  3 files changed, 28 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
> >> b/drivers/mtd/nand/brcmnand/brcmnand.c
> >> index b76ad7c..12a1585 100644
> >> --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> >> +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> >> @@ -1279,7 +1279,7 @@ static void brcmnand_cmdfunc(struct mtd_info *mtd, 
> >> unsigned command,
> >>   u32 *flash_cache = (u32 *)ctrl->flash_cache;
> >>   int i;
> >>
> >> - brcmnand_soc_data_bus_prepare(ctrl->soc);
> >> + brcmnand_soc_data_bus_prepare(ctrl->soc, true);
> >>
> >>   /*
> >>* Must cache the FLASH_CACHE now, since changes in
> >> @@ -1292,7 +1292,7 @@ static void brcmnand_cmdfunc(struct mtd_info *mtd, 
> >> unsigned command,
> >>*/
> >>   flash_cache[i] = be32_to_cpu(brcmnand_read_fc(ctrl, 
> >> i));
> >>
> >> - brcmnand_soc_data_bus_unprepare(ctrl->soc);
> >> + brcmnand_soc_data_bus_unprepare(ctrl->soc, true);
> >>
> >>   /* Cleanup from HW quirk: restore SECTOR_SIZE_1K */
> >>   if (host->hwcfg.sector_size_1k)
> >> @@ -1508,12 +1508,12 @@ static int brcmnand_read_by_pio(struct mtd_info 
> >> *mtd, struct nand_chip *chip,
> >>   brcmnand_waitfunc(mtd, chip);
> >>
> >>   if (likely(buf)) {
> >> - brcmnand_soc_data_bus_prepare(ctrl->soc);
> >> + brcmnand_soc_data_bus_prepare(ctrl->soc, false);
> >>
> >>   for (j = 0; j < FC_WORDS; j++, buf++)
> >>   *buf = brcmnand_read_fc(ctrl, j);
> >>
> >> - brcmnand_soc_data_bus_unprepare(ctrl->soc);
> >> + brcmnand_soc_data_bus_unprepare(ctrl->soc, false);
> >>   }
> >>
> >>   if (oob)
> >> @@ -1678,12 +1678,12 @@ static int brcmnand_write(struct mtd_info *mtd, 
> >> struct nand_chip *chip,
> >>   (void)brcmnand_read_reg(ctrl, BRCMNAND_CMD_ADDRESS);
> >>
> >>   if (buf) {
> >> - brcmnand_soc_data_bus_prepare(ctrl->soc);
> >> + brcmnand_soc_data_bus_prepare(ctrl->soc, false);
> >>
> >>   for (j = 0; j < FC_WORDS; j++, buf++)
> >>   brcmnand_write_fc(ctrl, j, *buf);
> >>
> >> - brcmnand_soc_data_bus_unprepare(ctrl->soc);
> >> + brcmnand_soc_data_bus_unprepare(ctrl->soc, false);
> >>   } else if (oob) {
> >>   for (j = 0; j < FC_WORDS; j++)
> >>   brcmnand_write_fc(ctrl, j, 0x);
> >> diff --git a/drivers/mtd/nand/brcmnand/brcmnand.h 
> >> b/drivers/mtd/nand/brcmnand/brcmnand.h
> >> index ef5eabb..5c44cd4 100644
> >> --- a/drivers/mtd/nand/brcmnand/brcmnand.h
> >> +++ b/drivers/mtd/nand/brcmnand/brcmnand.h
> >> @@ -23,19 +23,22 @@ struct dev_pm_ops;
> >>  struct brcmnand_soc {
> >>   bool (*ctlrdy_ack)(struct brcmnand_soc *soc);
> >>   void (*ctlrdy_set_enabled)(struct brcmnand_soc *soc, bool en);
> >> - void (*prepare_data_bus)(struct brcmnand_soc *soc, bool prepare);
> >> + void (*prepare_data_bus)(struct brcmnand_soc *soc, bool prepare,
> >> +  bool is_param);
> >>  };
> >>
> >> -static inline void brcmnand_soc_data_bus_prepare(struct brcmnand_soc *soc)
> >> +static inline void brcmnand_soc_data_bus_prepare(struct brcmnand_soc *soc,
> >> +  bool is_param)
> >>  {
> >>   if (soc && soc->prepare_data_bus)
> >> - soc->prepare_data_bus(soc, true);
> >> + soc->prepare_data_bus(soc, true, is_param);
> >>  }
> >>
> >> -static inline void brcmnand_soc_data_bus_unprepare(struct brcmnand_soc 
> >> *soc)
> >> +static inline void brcmnand_soc_data_bus_unprepare(struct 

Re: [PATCH 1/1] drm/amdgpu/gmc7: remove dead code

2016-08-22 Thread Christian König

Am 21.08.2016 um 20:06 schrieb Heinrich Schuchardt:

In an if block for (running == 0) running cannot be non-zero.

Signed-off-by: Heinrich Schuchardt 


The following patches are all Reviewed-by: Christian König 
:


[PATCH 1/1] drm/amdgpu/gmc7: remove dead code
[PATCH 1/1] drm/amdgpu/gmc8: remove dead code
[PATCH 1/1] drm/amd/powerplay: avoid NULL pointer dereference
[PATCH 1/1] drm/amd/powerplay: avoid NULL dereference, cz_hwmgr.c
[PATCH 1/1] drm/radeon/cik: remove dead code
[PATCH 1/1] drm/radeon: remove dead code, si_mc_load_microcode

Thanks for the help,
Christian.

PS: Please send such minor cleanups as one set of patches next time, 
cause that makes reviewing them much easier.



---
  drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 
  1 file changed, 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index 0b0f086..1239463 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -203,11 +203,6 @@ static int gmc_v7_0_mc_load_microcode(struct amdgpu_device 
*adev)
running = REG_GET_FIELD(RREG32(mmMC_SEQ_SUP_CNTL), MC_SEQ_SUP_CNTL, 
RUN);
  
  	if (running == 0) {

-   if (running) {
-   blackout = RREG32(mmMC_SHARED_BLACKOUT_CNTL);
-   WREG32(mmMC_SHARED_BLACKOUT_CNTL, blackout | 1);
-   }
-
/* reset the engine and set to writable */
WREG32(mmMC_SEQ_SUP_CNTL, 0x0008);
WREG32(mmMC_SEQ_SUP_CNTL, 0x0010);
@@ -239,9 +234,6 @@ static int gmc_v7_0_mc_load_microcode(struct amdgpu_device 
*adev)
break;
udelay(1);
}
-
-   if (running)
-   WREG32(mmMC_SHARED_BLACKOUT_CNTL, blackout);
}
  
  	return 0;





Re: [PATCH 1/8] hisi_sas: add internal abort core code

2016-08-22 Thread John Garry

On 21/08/2016 01:44, zhangfei wrote:



On 2016年08月10日 21:19, John Garry wrote:

Add core code for internal abort functionality.

The internal abort features allows the host controller
to abort commands which are still active in the
controller but have not yet been sent to the slave
device.

Typically a command only spends a relatively
short time in the controller when compared to the
amount of the time after it is sent to the slave
device.
Two modes of internal abort are supported:
- device
- individual command

For device, when the internal abort is issued all
commands in the host for that device are aborted.
For a single command, only that command is aborted
if it is still in the host.

In HW the internal abort command is executed
similar to any other sort of command, like SSP.

Signed-off-by: John Garry 
---
  drivers/scsi/hisi_sas/hisi_sas.h  |   3 +
  drivers/scsi/hisi_sas/hisi_sas_main.c | 154
++
  2 files changed, 157 insertions(+)

diff --git a/drivers/scsi/hisi_sas/hisi_sas.h
b/drivers/scsi/hisi_sas/hisi_sas.h
index 4731d32..4ae864d 100644
--- a/drivers/scsi/hisi_sas/hisi_sas.h
+++ b/drivers/scsi/hisi_sas/hisi_sas.h
@@ -146,6 +146,9 @@ struct hisi_sas_hw {
  struct hisi_sas_slot *slot);
  int (*prep_stp)(struct hisi_hba *hisi_hba,
  struct hisi_sas_slot *slot);
+int (*prep_abort)(struct hisi_hba *hisi_hba,
+  struct hisi_sas_slot *slot,
+  int device_id, int abort_flag, int tag_to_abort);


How about add comments to abort_flag and tag_to_abort.
As a result, not sure why differently calling in hisi_sas_abort_task
hisi_sas_internal_task_abort(hisi_hba, device, 1, tag);
hisi_sas_internal_task_abort(hisi_hba, device, 0, tag);

Thanks


.



OK, I can do.

I will add a MACRO for the abort flag, whether device abort or single IO 
abort modes.


I will also mention for device abort mode that the tag is unused.

Thanks,
John



[PATCH] CacheFiles: remove the check of fstop and bstop

2016-08-22 Thread Shawn Lin
No need to compare them with zero as it should
never be less than zero.

Signed-off-by: Shawn Lin 
---

 fs/cachefiles/daemon.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/cachefiles/daemon.c b/fs/cachefiles/daemon.c
index 1ee54ff..2ee88bd 100644
--- a/fs/cachefiles/daemon.c
+++ b/fs/cachefiles/daemon.c
@@ -386,7 +386,7 @@ static int cachefiles_daemon_fstop(struct cachefiles_cache 
*cache, char *args)
if (args[0] != '%' || args[1] != '\0')
return -EINVAL;
 
-   if (fstop < 0 || fstop >= cache->fcull_percent)
+   if (fstop >= cache->fcull_percent)
return cachefiles_daemon_range_error(cache, args);
 
cache->fstop_percent = fstop;
@@ -458,7 +458,7 @@ static int cachefiles_daemon_bstop(struct cachefiles_cache 
*cache, char *args)
if (args[0] != '%' || args[1] != '\0')
return -EINVAL;
 
-   if (bstop < 0 || bstop >= cache->bcull_percent)
+   if (bstop >= cache->bcull_percent)
return cachefiles_daemon_range_error(cache, args);
 
cache->bstop_percent = bstop;
-- 
2.3.7




Re: [PATCH v6 00/14] fix some type infos and bugs for arm64/of numa

2016-08-22 Thread Leizhen (ThunderTown)
Hi everybody:
   Is this patch series can be accepted or still need to be improved? It seems
to have been a long time.

Thanks,
   Zhen Lei


On 2016/8/11 17:33, Zhen Lei wrote:
> v5 -> v6:
> Move memblk nid check from arch/arm64/mm/numa.c into drivers/of/of_numa.c,
> because this check is arch independent.
> 
> This modification only related to patch 3, but impacted the contents of patch 
> 7 and 8,
> other patches have no change.
> 
> v4 -> v5:
> This version has no code changes, just add "Acked-by: Rob Herring 
> "
> into patches 1, 2, 4, 6, 7, 13, 14. Because these patches rely on some acpi 
> numa
> patches, and the latter had not been upstreamed in 4.7, but upstreamed in 
> 4.8-rc1,
> so I resend my patches again.
> 
> v3 -> v4:
> 1. Packed three patches of Kefeng Wang, patch6-8.
> 2. Add 6 new patches(9-15) to enhance the numa on arm64.
> 
> v2 -> v3:
> 1. Adjust patch2 and patch5 according to Matthias Brugger's advice, to make 
> the
>patches looks more well. The final code have no change. 
> 
> v1 -> v2:
> 1. Base on https://lkml.org/lkml/2016/5/24/679
> 2. Rewrote of_numa_parse_memory_nodes according to Rob Herring's advice. So 
> that it looks more clear.
> 3. Rewrote patch 5 because some scenes were not considered before.
> 
> Kefeng Wang (3):
>   of_numa: Use of_get_next_parent to simplify code
>   of_numa: Use pr_fmt()
>   arm64: numa: Use pr_fmt()
> 
> Zhen Lei (11):
>   of/numa: remove a duplicated pr_debug information
>   of/numa: fix a memory@ node can only contains one memory block
>   arm64/numa: add nid check for memory block
>   of/numa: remove a duplicated warning
>   arm64/numa: avoid inconsistent information to be printed
>   arm64/numa: support HAVE_SETUP_PER_CPU_AREA
>   arm64/numa: define numa_distance as array to simplify code
>   arm64/numa: support HAVE_MEMORYLESS_NODES
>   arm64/numa: remove some useless code
>   of/numa: remove the constraint on the distances of node pairs
>   Documentation: remove the constraint on the distances of node pairs
> 
>  Documentation/devicetree/bindings/numa.txt |   1 -
>  arch/arm64/Kconfig |  12 ++
>  arch/arm64/include/asm/numa.h  |   1 -
>  arch/arm64/kernel/smp.c|   1 +
>  arch/arm64/mm/numa.c   | 223 
> -
>  drivers/of/of_numa.c   |  88 ++--
>  6 files changed, 178 insertions(+), 148 deletions(-)
> 
> --
> 2.5.0
> 
> 
> 
> .
> 



Re: [PACTH v2 0/3] Implement /proc//totmaps

2016-08-22 Thread Michal Hocko
On Fri 19-08-16 10:57:48, Sonny Rao wrote:
> On Fri, Aug 19, 2016 at 12:59 AM, Michal Hocko  wrote:
> > On Thu 18-08-16 23:43:39, Sonny Rao wrote:
> >> On Thu, Aug 18, 2016 at 11:01 AM, Michal Hocko  wrote:
> >> > On Thu 18-08-16 10:47:57, Sonny Rao wrote:
> >> >> On Thu, Aug 18, 2016 at 12:44 AM, Michal Hocko  
> >> >> wrote:
> >> >> > On Wed 17-08-16 11:57:56, Sonny Rao wrote:
> >> > [...]
> >> >> >> 2) User space OOM handling -- we'd rather do a more graceful shutdown
> >> >> >> than let the kernel's OOM killer activate and need to gather this
> >> >> >> information and we'd like to be able to get this information to make
> >> >> >> the decision much faster than 400ms
> >> >> >
> >> >> > Global OOM handling in userspace is really dubious if you ask me. I
> >> >> > understand you want something better than SIGKILL and in fact this is
> >> >> > already possible with memory cgroup controller (btw. memcg will give
> >> >> > you a cheap access to rss, amount of shared, swapped out memory as
> >> >> > well). Anyway if you are getting close to the OOM your system will 
> >> >> > most
> >> >> > probably be really busy and chances are that also reading your new 
> >> >> > file
> >> >> > will take much more time. I am also not quite sure how is pss useful 
> >> >> > for
> >> >> > oom decisions.
> >> >>
> >> >> I mentioned it before, but based on experience RSS just isn't good
> >> >> enough -- there's too much sharing going on in our use case to make
> >> >> the correct decision based on RSS.  If RSS were good enough, simply
> >> >> put, this patch wouldn't exist.
> >> >
> >> > But that doesn't answer my question, I am afraid. So how exactly do you
> >> > use pss for oom decisions?
> >>
> >> We use PSS to calculate the memory used by a process among all the
> >> processes in the system, in the case of Chrome this tells us how much
> >> each renderer process (which is roughly tied to a particular "tab" in
> >> Chrome) is using and how much it has swapped out, so we know what the
> >> worst offenders are -- I'm not sure what's unclear about that?
> >
> > So let me ask more specifically. How can you make any decision based on
> > the pss when you do not know _what_ is the shared resource. In other
> > words if you select a task to terminate based on the pss then you have to
> > kill others who share the same resource otherwise you do not release
> > that shared resource. Not to mention that such a shared resource might
> > be on tmpfs/shmem and it won't get released even after all processes
> > which map it are gone.
> 
> Ok I see why you're confused now, sorry.
> 
> In our case that we do know what is being shared in general because
> the sharing is mostly between those processes that we're looking at
> and not other random processes or tmpfs, so PSS gives us useful data
> in the context of these processes which are sharing the data
> especially for monitoring between the set of these renderer processes.

OK, I see and agree that pss might be useful when you _know_ what is
shared. But this sounds quite specific to a particular workload. How
many users are in a similar situation? In other words, if we present
a single number without the context, how much useful it will be in
general? Is it possible that presenting such a number could be even
misleading for somebody who doesn't have an idea which resources are
shared? These are all questions which should be answered before we
actually add this number (be it a new/existing proc file or a syscall).
I still believe that the number without wider context is just not all
that useful.

> We also use the private clean and private dirty and swap fields to
> make a few metrics for the processes and charge each process for it's
> private, shared, and swap data. Private clean and dirty are used for
> estimating a lower bound on how much memory would be freed.

I can imagine that this kind of information might be useful and
presented in /proc//statm. The question is whether some of the
existing consumers would see the performance impact due to he page table
walk. Anyway even these counters might get quite tricky because even
shareable resources are considered private if the process is the only
one to map them (so again this might be a file on tmpfs...).

> Swap and
> PSS also give us some indication of additional memory which might get
> freed up.
-- 
Michal Hocko
SUSE Labs


[PATCH v2] pwm: add pwm driver for HiSilicon BVT SOCs

2016-08-22 Thread Jian Yuan
From: yuanjian 

Add pwm driver for HiSilicon BVT SOCs

Reviewed-by: Jiancheng Xue 
Signed-off-by: Jian Yuan 
---
Change Log:
v2:
The number of PWMs is change to be probeable based on the compatible string.

 .../devicetree/bindings/pwm/pwm-hibvt.txt  |  18 ++
 drivers/pwm/Kconfig|  10 +
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/pwm-hibvt.c| 274 +
 4 files changed, 303 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-hibvt.txt
 create mode 100644 drivers/pwm/pwm-hibvt.c

diff --git a/Documentation/devicetree/bindings/pwm/pwm-hibvt.txt 
b/Documentation/devicetree/bindings/pwm/pwm-hibvt.txt
new file mode 100644
index 000..1274119
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-hibvt.txt
@@ -0,0 +1,18 @@
+Hisilicon PWM controller
+
+Required properties:
+-compatible: should contain one soc specific compatible string and one generic 
compatible
+string "hisilicon, hibvt-pwm". The soc specific strings supported including:
+   "hisilicon,hi3516cv300-pwm"
+- reg: physical base address and length of the controller's registers.
+- clocks: phandle and clock specifier of the PWM reference clock.
+- resets: offset address and offset bit for reset or unreset of the controller.
+
+Example:
+   pwm: pwm@1213 {
+
+   compatible = "hisilicon,hi3516cv300-pwm", "hisilicon,hibvt-pwm";
+   reg = <0x1213 0x1>;
+   clocks = <_ctrl HI3516CV300_PWM_CLK>;
+   resets = <_ctrl 0x38 0>;
+   };
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index c182efc..3c48768 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -158,6 +158,15 @@ config PWM_FSL_FTM
  To compile this driver as a module, choose M here: the module
  will be called pwm-fsl-ftm.
 
+config PWM_HIBVT
+   tristate "HiSilicon BVT PWM support"
+   depends on ARCH_HISI
+   help
+ Generic PWM framework driver for hisilicon BVT SOCs.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-hibvt.
+
 config PWM_IMG
tristate "Imagination Technologies PWM driver"
depends on HAS_IOMEM
@@ -438,4 +447,5 @@ config PWM_VT8500
  To compile this driver as a module, choose M here: the module
  will be called pwm-vt8500.
 
+
 endif
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index dd35bc1..37ec39e 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_PWM_CLPS711X)+= pwm-clps711x.o
 obj-$(CONFIG_PWM_CRC)  += pwm-crc.o
 obj-$(CONFIG_PWM_EP93XX)   += pwm-ep93xx.o
 obj-$(CONFIG_PWM_FSL_FTM)  += pwm-fsl-ftm.o
+obj-$(CONFIG_PWM_HIBVT)+= pwm-hibvt.o
 obj-$(CONFIG_PWM_IMG)  += pwm-img.o
 obj-$(CONFIG_PWM_IMX)  += pwm-imx.o
 obj-$(CONFIG_PWM_JZ4740)   += pwm-jz4740.o
diff --git a/drivers/pwm/pwm-hibvt.c b/drivers/pwm/pwm-hibvt.c
new file mode 100644
index 000..84f617e
--- /dev/null
+++ b/drivers/pwm/pwm-hibvt.c
@@ -0,0 +1,274 @@
+/*
+ * PWM Controller Driver for HiSilicon BVT SOCs
+ *
+ * Copyright (c) 2016 HiSilicon Technologies Co., Ltd.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PWM_CFG0_ADDR(x)(((x) * 0x20) + 0x0)
+#define PWM_CFG1_ADDR(x)(((x) * 0x20) + 0x4)
+#define PWM_CFG2_ADDR(x)(((x) * 0x20) + 0x8)
+#define PWM_CTRL_ADDR(x)(((x) * 0x20) + 0xC)
+
+#define PWM_ENABLE_SHIFT0
+#define PWM_ENABLE_MASKBIT(0)
+
+#define PWM_POLARITY_SHIFT 1
+#define PWM_POLARITY_MASK  BIT(1)
+
+#define PWM_KEEP_SHIFT 2
+#define PWM_KEEP_MASK  BIT(2)
+
+#define PWM_PERIOD_MASKGENMASK(31, 0)
+#define PWM_DUTY_MASK  GENMASK(31, 0)
+
+struct hibvt_pwm_chip {
+   struct pwm_chip chip;
+   struct clk  *clk;
+   void __iomem*mmio_base;
+   struct reset_control *rstc;
+};
+
+static int pwm_num_array[] = {8, 4};
+
+static inline
+struct hibvt_pwm_chip *to_hibvt_pwm_chip(struct pwm_chip *chip)
+{
+   return container_of(chip, struct hibvt_pwm_chip, chip);
+}
+

Re: [PATCH] thermal: rcar_thermal: don't call thermal_zone_device_unregister when USE_OF_THERMAL

2016-08-22 Thread Zhang Rui
On 一, 2016-08-22 at 03:19 +, Kuninori Morimoto wrote:
> From: Bui Duc Phuc 
> 
> devm_thermal_zone_of_sensor_register() case doesn't need to call
> thermal_zone_device_unregister().
> Otherwise, rcar-thermal can't register thermal zone again after
> rebind.
> This patch fixes it.
> 
> Signed-off-by: Bui Duc Phuc 
> Signed-off-by: Kuninori Morimoto 

Patch applied.

thanks,
rui
> ---
>  drivers/thermal/rcar_thermal.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/thermal/rcar_thermal.c
> b/drivers/thermal/rcar_thermal.c
> index 4d07644..b5c6442 100644
> --- a/drivers/thermal/rcar_thermal.c
> +++ b/drivers/thermal/rcar_thermal.c
> @@ -419,9 +419,10 @@ static int rcar_thermal_remove(struct
> platform_device *pdev)
>  
>   rcar_thermal_for_each_priv(priv, common) {
>   rcar_thermal_irq_disable(priv);
> - thermal_zone_device_unregister(priv->zone);
>   if (rcar_use_of_thermal(dev))
>   thermal_remove_hwmon_sysfs(priv->zone);
> + else
> + thermal_zone_device_unregister(priv->zone);
>   }
>  
>   pm_runtime_put(dev);


Re: [PATCH v3 2/2] soc: qcom: add l2 cache perf events driver

2016-08-22 Thread kbuild test robot
Hi Neil,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.8-rc3 next-20160819]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Neil-Leeder/qcom-add-l2-cache-perf-events-driver/20160817-031555
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

   drivers/soc/qcom/perf_event_l2.c: In function 'l2_cache_pmu_probe':
>> drivers/soc/qcom/perf_event_l2.c:786:32: error: 'CPU_PRI_PERF' undeclared 
>> (first use in this function)
 l2cache_pmu.cpu_nb.priority = CPU_PRI_PERF + 1;
   ^
   drivers/soc/qcom/perf_event_l2.c:786:32: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/CPU_PRI_PERF +786 drivers/soc/qcom/perf_event_l2.c

   780  if (l2cache_pmu.num_pmus == 0) {
   781  dev_err(>dev, "No hardware L2 PMUs found\n");
   782  return -ENODEV;
   783  }
   784  
   785  l2cache_pmu.cpu_nb.notifier_call = l2cache_pmu_cpu_notifier;
 > 786  l2cache_pmu.cpu_nb.priority = CPU_PRI_PERF + 1;
   787  err = register_cpu_notifier(_pmu.cpu_nb);
   788  if (err)
   789  return err;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


Re: [PATCH v4 10/10] usb: gadget: f_hid: use alloc_ep_req()

2016-08-22 Thread Felipe Balbi

Hi,

John Youn  writes:
> On 8/8/2016 1:30 PM, Felipe F. Tonello wrote:
>> Use gadget's framework allocation function instead of directly calling
>> usb_ep_alloc_request().
>> 
>> Signed-off-by: Felipe F. Tonello 
>> ---
>>  drivers/usb/gadget/function/f_hid.c | 6 +-
>>  1 file changed, 1 insertion(+), 5 deletions(-)
>> 
>> diff --git a/drivers/usb/gadget/function/f_hid.c 
>> b/drivers/usb/gadget/function/f_hid.c
>> index a010496e4e05..89d2e9a5a04f 100644
>> --- a/drivers/usb/gadget/function/f_hid.c
>> +++ b/drivers/usb/gadget/function/f_hid.c
>> @@ -611,14 +611,10 @@ static int hidg_bind(struct usb_configuration *c, 
>> struct usb_function *f)
>>  
>>  /* preallocate request and buffer */
>>  status = -ENOMEM;
>> -hidg->req = usb_ep_alloc_request(hidg->in_ep, GFP_KERNEL);
>> +hidg->req = alloc_ep_req(hidg->in_ep, hidg->report_length);
>>  if (!hidg->req)
>>  goto fail;
>>  
>> -hidg->req->buf = kmalloc(hidg->report_length, GFP_KERNEL);
>> -if (!hidg->req->buf)
>> -goto fail;
>> -
>>  /* set descriptor dynamic values */
>>  hidg_interface_desc.bInterfaceSubClass = hidg->bInterfaceSubClass;
>>  hidg_interface_desc.bInterfaceProtocol = hidg->bInterfaceProtocol;
>> 
>
> Hi Felipe,
>
> This commit on your testing/next breaks compilation.
>
> ../drivers/usb/gadget/function/f_hid.c: In function ‘hidg_bind’:
> ../drivers/usb/gadget/function/f_hid.c:620:14: error: too few arguments to 
> function ‘alloc_ep_req’
>   hidg->req = alloc_ep_req(hidg->in_ep, hidg->report_length);
>   ^
> In file included from ../drivers/usb/gadget/function/f_hid.c:24:0:
> ../drivers/usb/gadget/u_f.h:63:21: note: declared here
>  struct usb_request *alloc_ep_req(struct usb_ep *ep, size_t len, int 
> default_len);

true that :-) Dropping from my queue.

-- 
balbi


signature.asc
Description: PGP signature


Re: [PATCH v3 1/2] Documentation: dt: Add new compatible to sunxi mmc driver bindings

2016-08-22 Thread Maxime Ripard
Hi Icenowy,

On Mon, Aug 01, 2016 at 11:13:50PM +0800, Icenowy Zheng wrote:
> Signed-off-by: Icenowy Zheng 
> ---
> Changes in v2:
> - Rebased on Hans de Goede's patchset.
> 
>  Documentation/devicetree/bindings/mmc/sunxi-mmc.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt 
> b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
> index 904ff9f..55cdd80 100644
> --- a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
> +++ b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
> @@ -13,6 +13,7 @@ Required properties:
> * "allwinner,sun5i-a13-mmc"
> * "allwinner,sun7i-a20-mmc"
> * "allwinner,sun9i-a80-mmc"
> +   * "allwinner,sun50i-a64-mmc"
>   - reg : mmc controller base registers
>   - clocks : a list with 4 phandle + clock specifier pairs
>   - clock-names : must contain "ahb", "mmc", "output" and "sample"

You need to document that the output and sample clocks are not
mandatory in the A64 case.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature


Re: [RFC PATCH v2 1/2] mm/hugetlb: Introduce ARCH_HAS_GIGANTIC_PAGE

2016-08-22 Thread Michal Hocko
On Mon 22-08-16 10:56:42, Xie Yisheng wrote:
> Avoid making ifdef get pretty unwieldy if many ARCHs support gigantic page.
> No functional change with this patch.
> 
> Signed-off-by: Xie Yisheng 
> ---
>  arch/s390/Kconfig | 1 +
>  arch/x86/Kconfig  | 1 +
>  fs/Kconfig| 4 
>  mm/hugetlb.c  | 2 +-
>  4 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index e751fe2..a8c8fa3 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -72,6 +72,7 @@ config S390
>   select ARCH_HAS_DEVMEM_IS_ALLOWED
>   select ARCH_HAS_ELF_RANDOMIZE
>   select ARCH_HAS_GCOV_PROFILE_ALL
> + select ARCH_HAS_GIGANTIC_PAGE
>   select ARCH_HAS_KCOV
>   select ARCH_HAS_SG_CHAIN
>   select ARCH_HAVE_NMI_SAFE_CMPXCHG
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index c580d8c..5cf959c 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -29,6 +29,7 @@ config X86
>   select ARCH_HAS_ELF_RANDOMIZE
>   select ARCH_HAS_FAST_MULTIPLIER
>   select ARCH_HAS_GCOV_PROFILE_ALL
> + select ARCH_HAS_GIGANTIC_PAGE   if X86_64
>   select ARCH_HAS_KCOVif X86_64
>   select ARCH_HAS_PMEM_APIif X86_64
>   select ARCH_HAS_MMIO_FLUSH

good

> diff --git a/fs/Kconfig b/fs/Kconfig
> index 2bc7ad7..b77ad0f 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -199,6 +199,10 @@ config HUGETLBFS
>  config HUGETLB_PAGE
>   def_bool HUGETLBFS
>  
> +config ARCH_HAS_GIGANTIC_PAGE
> + depends on HUGETLB_PAGE
> + bool
> +

but is this really necessary? The code where we use
ARCH_HAS_GIGANTIC_PAGE already depends on HUGETLB_PAGE.

Other than that looks good to me and a nice simplification.

>  source "fs/configfs/Kconfig"
>  source "fs/efivarfs/Kconfig"
>  
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 87e11d8..8488dcc 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1022,7 +1022,7 @@ static int hstate_next_node_to_free(struct hstate *h, 
> nodemask_t *nodes_allowed)
>   ((node = hstate_next_node_to_free(hs, mask)) || 1); \
>   nr_nodes--)
>  
> -#if (defined(CONFIG_X86_64) || defined(CONFIG_S390)) && \
> +#if defined(CONFIG_ARCH_HAS_GIGANTIC_PAGE) && \
>   ((defined(CONFIG_MEMORY_ISOLATION) && defined(CONFIG_COMPACTION)) || \
>   defined(CONFIG_CMA))
>  static void destroy_compound_gigantic_page(struct page *page,
> -- 
> 1.7.12.4

-- 
Michal Hocko
SUSE Labs


Re: [PATCH 2/2] proc: task_mmu: Reduce output processing cpu time

2016-08-22 Thread Joe Perches
On Mon, 2016-08-22 at 09:24 +0200, Michal Hocko wrote:
> On Sat 20-08-16 01:00:17, Joe Perches wrote:
> [...]
> > 
> >  static int proc_maps_open(struct inode *inode, struct file *file,
> >     const struct seq_operations *ops, int psize)
> >  {
> > -   struct proc_maps_private *priv = __seq_open_private(file, ops, psize);
> > +   struct proc_maps_private *priv;
> > +   struct mm_struct *mm;
> > +
> > +   mm = proc_mem_open(inode, PTRACE_MODE_READ);
> > +   if (IS_ERR(mm))
> > +   return PTR_ERR(mm);
> >  
> > +   priv = __seq_open_private_bufsize(file, ops, psize,
> > +     mm && mm->map_count ?
> > +     mm->map_count * 0x300 : PAGE_SIZE);
> NAK to this!
>
> Seriously, this just gives any random user access to user
> defined amount of memory which not accounted, not reclaimable and a
> potential consumer of any higher order blocks.

I completely disagree here with your rationale here.

I think you didn't read the code and didn't try it either.

This code is identical to the previous code but it
simply estimates the required output size first.

> Besides that, at least one show_smap output will always fit inside the
> single page and AFAIR (it's been quite a while since I've looked into
> seq_file internals) the buffer grows only when the single show doesn't
> fit in.

It's never been like that as far as I know.

Please read fs/seq_file.c:traverse()

This code starts with a PAGE_SIZE block of memory then if
the complete output doesn't fit, stops, frees that block
of memory, and retries the complete output with a last block
size allocated << 1 and tries again.

> I really do not understand why you insist on code duplication rather
> than reuse but if you really insist then just make this (without the
> above __seq_open_private_bufsize, re-measure and add the results to the
> changelog and repost.

I've tried it, I wish you would.


Re: [RFC PATCH v2 2/2] arm64 Kconfig: Select gigantic page

2016-08-22 Thread Michal Hocko
On Mon 22-08-16 10:56:43, Xie Yisheng wrote:
> Arm64 supports gigantic page after
> commit 084bd29810a5 ("ARM64: mm: HugeTLB support.")
> however, it got broken by 
> commit 944d9fec8d7a ("hugetlb: add support for gigantic page
> allocation at runtime")
> 
> This patch selects ARCH_HAS_GIGANTIC_PAGE to make this
> function can be used again.

I haven't double checked that the above commit really broke it but if
that is the case then
 
Fixes: 944d9fec8d7a ("hugetlb: add support for gigantic page allocation at 
runtime")

would be nice as well I guess. I do not think that marking it for stable
is really necessary considering how long it's been broken and nobody has
noticed...

> Signed-off-by: Xie Yisheng 

Acked-by: Michal Hocko 

> ---
>  arch/arm64/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index bc3f00f..92217f6 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -9,6 +9,7 @@ config ARM64
>   select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
>   select ARCH_HAS_ELF_RANDOMIZE
>   select ARCH_HAS_GCOV_PROFILE_ALL
> + select ARCH_HAS_GIGANTIC_PAGE
>   select ARCH_HAS_KCOV
>   select ARCH_HAS_SG_CHAIN
>   select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
> -- 
> 1.7.12.4
> 

-- 
Michal Hocko
SUSE Labs


Re: [PATCH 6/6] Add dockerfile

2016-08-22 Thread Dmitry Monakhov
Theodore Ts'o  writes:

> On Sun, Aug 21, 2016 at 03:02:38PM +0300, Dmitry Monakhov wrote:
>> Probably it it reasonable to create dedicated directory ./docker
>> and place all docker related crap there:
>> # build scripts
>> docker/Dockerfile.build-env
>> docker/Dockerfile.run-env
>> # And some run scripts
>> # Build all environment from scratch
>> docker/docker-build.sh
>> # Move config, kernel, root_fs.img inside container and run 
>> {gce,kvm}-xfstests.sh
>> docker/docker-kvm-xfstests.sh 
>> docker/docker-gce-xfstests.sh
>
> I thought about that, but my current thinking is to have one
> Dockerfile which is in the top-level directory, and one which is in
> the kvm-xfstests directory.
>
> I've already created a tytso/xfststs-bld Docker image which was
> generated using:
>
> docker build -t tytso/xfstests-bld https://github.com/tytso/xfstests-bld.git
Nice. Now image is no longer generated by Russian hacker. Hitler
finally can sleep well :)
>
> By putting the Dockerfile in the top-level directory, I can use the
> command "COPY . /devel/xfstests-bld" in the Dockerfile, and so we can
> get a clean build build that way.
Yes. That is reasonable. I do not know that build context can emerge from URL.
>
> By putting a Dockerfile in the kvm-xfstests directory, then all I have
> to do is to put a "COPY . /usr/local/lib/kvm-xfstests" which will copy
> all of the kvm-xfstests directory directly where we want the files in
> the kvm-xfstests Docker image.  I'm assuming that my release process
> will first build root_fs.i386 and root_fs.x86_64 using debian chroots,
> and then upload them to www.kernel.org.  I'll then run:
>
> docker build -t tytso/kvm-xfstests 
> https://github.com/tytso/xfstests-bld.git:kvm-xfstests
Cool. The only minor comment is that command should be:
docker build -t tytso/kvm-xfstests -f kvm-xfstests/Dockerfile 
https://github.com/tytso/xfstests-bld.git:kvm-xfstests
>
> ... and then the Dockerfile will pull the root_fs.i386 from
> ftp.kernel.org.
>
> What do you think?
>
>   - Ted


signature.asc
Description: PGP signature


Re: [PATCH 3/3] drivers: Add visorbus to the drivers/virt directory

2016-08-22 Thread 'Greg KH'
On Mon, Aug 22, 2016 at 02:48:18AM +, Sell, Timothy C wrote:
> > -Original Message-
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Sunday, August 21, 2016 2:05 PM
> > To: Kershner, David A 
> > Cc: cor...@lwn.net; t...@linutronix.de; mi...@redhat.com;
> > h...@zytor.com; Arfvidson, Erik ; Sell, Timothy
> > C ; hof...@osadl.org; dzic...@redhat.com;
> > jes.soren...@redhat.com; Curtin, Alexander Paul
> > ; janani.rvchn...@gmail.com;
> > sudipm.mukher...@gmail.com; pra...@redhat.com; Binder, David Anthony
> > ; nhor...@redhat.com;
> > dan.j.willi...@intel.com; linux-kernel@vger.kernel.org; linux-
> > d...@vger.kernel.org; driverdev-de...@linuxdriverproject.org; *S-Par-
> > Maintainer 
> > Subject: Re: [PATCH 3/3] drivers: Add visorbus to the drivers/virt directory
> > 
> > On Fri, Jun 10, 2016 at 11:23:56PM -0400, David Kershner wrote:
> > > visorbus is currently located at drivers/staging/visorbus,
> > > this patch moves it to drivers/virt.
> > >
> > > Signed-off-by: David Kershner 
> > > Reviewed-by: Tim Sell 
> > > ---
> > >  drivers/staging/unisys/Kconfig| 
> > > 3 +--
> > >  drivers/staging/unisys/Makefile   | 
> > > 1 -
> > >  drivers/virt/Kconfig  | 
> > > 2 ++
> > >  drivers/virt/Makefile | 
> > > 1 +
> > >  drivers/{staging/unisys => virt}/visorbus/Kconfig | 0
> > >  drivers/{staging/unisys => virt}/visorbus/Makefile| 0
> > >  drivers/{staging/unisys => virt}/visorbus/controlvmchannel.h  | 0
> > >  drivers/{staging/unisys => virt}/visorbus/controlvmcompletionstatus.h | 0
> > >  drivers/{staging/unisys => virt}/visorbus/iovmcall_gnuc.h | 0
> > >  drivers/{staging/unisys => virt}/visorbus/vbuschannel.h   | 0
> > >  drivers/{staging/unisys => virt}/visorbus/vbusdeviceinfo.h| 0
> > >  drivers/{staging/unisys => virt}/visorbus/vbushelper.h| 0
> > >  drivers/{staging/unisys => virt}/visorbus/visorbus_main.c | 0
> > >  drivers/{staging/unisys => virt}/visorbus/visorbus_private.h  | 0
> > >  drivers/{staging/unisys => virt}/visorbus/visorchannel.c  | 0
> > >  drivers/{staging/unisys => virt}/visorbus/visorchipset.c  | 0
> > 
> > I picked one random file here, this last one, and found a number of
> > "odd" things in it.
> > 
> > So, given that I can't really comment on the patch itself, I'm going to
> > include the file below, quote it, and then provide some comments, ok?
> > > /* visorchipset_main.c
> > > ...
> > > static void
> > > controlvm_init_response(struct controlvm_message *msg,
> > >   struct controlvm_message_header *msg_hdr, int response)
> > > {
> > >   memset(msg, 0, sizeof(struct controlvm_message));
> > >   memcpy(>hdr, msg_hdr, sizeof(struct controlvm_message_header));
> > >   msg->hdr.payload_bytes = 0;
> > >   msg->hdr.payload_vm_offset = 0;
> > >   msg->hdr.payload_max_bytes = 0;
> > >   if (response < 0) {
> > >   msg->hdr.flags.failed = 1;
> > >   msg->hdr.completion_status = (u32)(-response);
> > >   }
> > > }
> > > 
> > > static void
> > > Billy(struct controlvm_message_header *msg_hdr, int response)
> > 
> > Not John?  Bob?  Sally?  Alice?  Bernise?  Jean?  Molly?
> 
> Huh? What version of source code are you looking at??
> 
> The file being moved by this patch should be
> drivers/staging/unisys/visorbus/visorchipset.c in your staging-next branch  
> (https://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/tree/drivers/staging/unisys/visorbus/visorchipset.c?h=staging-next).
> If you look there, you will NOT find "Billy()", but instead 
> "controlvm_respond()", i.e.:
> 
> static void
> controlvm_init_response(struct controlvm_message *msg,
>   struct controlvm_message_header *msg_hdr, int response)


oh that's funny, I have no idea what happened here, perhaps when I
copied the file into the original email?  Strange things happen while on
planes...

Anyway, ok, one comment addressed, great!  Now about the many many
others?

thanks,

greg k-h


Re: [PATCH] usb: chipidea: support generic phy in PM code path

2016-08-22 Thread Jisheng Zhang
+ Kishon

Hi Peter, Kishon,

On Mon, 22 Aug 2016 15:29:07 +0800 Peter Chen wrote:

> On Mon, Aug 22, 2016 at 02:39:21PM +0800, Jisheng Zhang wrote:
> > Hi Peter,
> > 
> > On Mon, 22 Aug 2016 13:33:08 +0800 Peter Chen wrote:
> >   
> > > On Fri, Aug 19, 2016 at 08:10:13PM +0800, Jisheng Zhang wrote:  
> > > > Support generic phy in PM code path: call phy_power_off/phy_power_on
> > > > in ci_controller_suspend/ci_controller_resume.
> > > > 
> > > > Signed-off-by: Jisheng Zhang 
> > > > ---
> > > >  drivers/usb/chipidea/core.c | 4 +++-
> > > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > > > index ae12595..ef9fb0b 100644
> > > > --- a/drivers/usb/chipidea/core.c
> > > > +++ b/drivers/usb/chipidea/core.c
> > > > @@ -1116,6 +1116,7 @@ static void ci_controller_suspend(struct ci_hdrc 
> > > > *ci)
> > > > usleep_range(ci->platdata->phy_clkgate_delay_us,
> > > >  ci->platdata->phy_clkgate_delay_us + 50);
> > > > usb_phy_set_suspend(ci->usb_phy, 1);
> > > > +   phy_power_off(ci->phy);
> > > 
> > > How could you support USB wakeup after PHY is powered off?  
> > 
> > Per my understanding, the PHY's power off just power off data communication 
> > part
> > but leaves the circuits involved in wakeup detection active.
> >   
> 
> Ok, I hope so.

If most parts of the phy can be powered off during runtime suspend to save
power, or phy HW support suspend mode, with usb phy, usb_phy_set_suspend() could
be used, but with the generic phy, it seems there's no corresponding API for
this purpose. I'm not sure whether using phy_power_off() is correct here. Is it
acceptable to extend the generic phy? such as, phy_suspend()/phy_resume()?

Thanks,
Jisheng


[PATCH] genirq: fix potential memleak when failing to get irq pm

2016-08-22 Thread Shawn Lin
Obviously we should free action here if irq_chip_pm_get
failed.

Signed-off-by: Shawn Lin 
---

 kernel/irq/manage.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 73a2b78..844d95e 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1681,8 +1681,10 @@ int request_threaded_irq(unsigned int irq, irq_handler_t 
handler,
action->dev_id = dev_id;
 
retval = irq_chip_pm_get(>irq_data);
-   if (retval < 0)
+   if (retval < 0) {
+   kfree(action);
return retval;
+   }
 
chip_bus_lock(desc);
retval = __setup_irq(irq, desc, action);
-- 
2.3.7




[PATCH 2/4] irqchip/gic: Allow self-SGIs for SMP on UP configurations

2016-08-22 Thread Marc Zyngier
On systems where a single CPU is present, the GIC may not support
having SGIs delivered to a target list. In that case, we use the
self-SGI mechanism to allow the interrupt to be delivered locally.

Tested-by: Fabio Estevam 
Signed-off-by: Marc Zyngier 
---
 drivers/irqchip/irq-gic.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index c2cab57..390fac5 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -769,6 +769,13 @@ static void gic_raise_softirq(const struct cpumask *mask, 
unsigned int irq)
int cpu;
unsigned long flags, map = 0;
 
+   if (unlikely(nr_cpu_ids == 1)) {
+   /* Only one CPU? let's do a self-IPI... */
+   writel_relaxed(2 << 24 | irq,
+  gic_data_dist_base(_data[0]) + 
GIC_DIST_SOFTINT);
+   return;
+   }
+
raw_spin_lock_irqsave(_controller_lock, flags);
 
/* Convert our logical CPU mask into a physical one. */
-- 
2.1.4



[PULL] irqchip fixes for 4.8-rc4

2016-08-22 Thread Marc Zyngier
Hi Thomas,

Please find below a handful of fixes targetted at the current
cycle. The most important thing is a fix for the trigger configuration
on chained irqchip (please see the discussion here[1] for
details). The rest is the usual GIC churn, nothing massively critical.

Please pull!

Thanks,

M.

[1] https://lkml.org/lkml/2016/7/30/3

The following changes since commit 694d0d0bb2030d2e36df73e2d23d5770511dbc8d:

  Linux 4.8-rc2 (2016-08-14 19:11:36 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git 
tags/irqchip-for-4.8-rc4

for you to fetch changes up to 7611da865c1060b2a7c87a15de663a59035747f8:

  irqchip/gicv3-its: Disable the ITS before initializing it (2016-08-19 
09:47:07 +0100)


genirq/irqchip fixes for 4.8-rc4

- A critical fix for chained irqchip where we failed to configure
  the cascade interrupt trigger
- A GIC fix for self-IPI in SMP-on-UP configurations
- A PM fix for GICv3
- A initialization fix the the GICv3 ITS, triggered by kexec


David Daney (1):
  irqchip/gicv3-its: Disable the ITS before initializing it

Marc Zyngier (2):
  genirq: Correctly configure the trigger on chained interrupts
  irqchip/gic: Allow self-SGIs for SMP on UP configurations

Sudeep Holla (1):
  irqchip/gicv3: Remove disabling redistributor and group1 non-secure 
interrupts

 drivers/irqchip/irq-gic-v3-its.c |  7 ++-
 drivers/irqchip/irq-gic-v3.c | 11 +--
 drivers/irqchip/irq-gic.c|  7 +++
 kernel/irq/chip.c| 11 +++
 4 files changed, 33 insertions(+), 3 deletions(-)


[PATCH 1/4] genirq: Correctly configure the trigger on chained interrupts

2016-08-22 Thread Marc Zyngier
Commit 1e2a7d78499e ("irqdomain: Don't set type when mapping an IRQ")
moved the trigger configuration call from the irqdomain mapping to
the interrupt being actually requested.

This patch failed to handle the case where we configure a chained
interrupt, which doesn't get requested through the usual path.

In order to solve this, let's call __irq_set_trigger just before
starting the cascade interrupt. Special care must be taken to
make the flow handler stick, as the .irq_set_type method could
have reset it (it doesn't know we're dealing with a chained
interrupt).

Based on an initial patch by Jon Hunter.

Fixes: 1e2a7d78499e ("irqdomain: Don't set type when mapping an IRQ")
Reported-by: John Stultz 
Reported-by: Linus Walleij 
Tested-by: John Stultz 
Acked-by: Jon Hunter 
Signed-off-by: Marc Zyngier 
---
 kernel/irq/chip.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index b4c1bc7..6373890 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -820,6 +820,17 @@ __irq_do_set_handler(struct irq_desc *desc, 
irq_flow_handler_t handle,
desc->name = name;
 
if (handle != handle_bad_irq && is_chained) {
+   /*
+* We're about to start this interrupt immediately,
+* hence the need to set the trigger configuration.
+* But the .set_type callback may have overridden the
+* flow handler, ignoring that we're dealing with a
+* chained interrupt. Reset it immediately because we
+* do know better.
+*/
+   __irq_set_trigger(desc, irqd_get_trigger_type(>irq_data));
+   desc->handle_irq = handle;
+
irq_settings_set_noprobe(desc);
irq_settings_set_norequest(desc);
irq_settings_set_nothread(desc);
-- 
2.1.4



Re: [PATCH] usb: chipidea: support generic phy in PM code path

2016-08-22 Thread Kishon Vijay Abraham I
Hi,

On Monday 22 August 2016 01:44 PM, Jisheng Zhang wrote:
> + Kishon
> 
> Hi Peter, Kishon,
> 
> On Mon, 22 Aug 2016 15:29:07 +0800 Peter Chen wrote:
> 
>> On Mon, Aug 22, 2016 at 02:39:21PM +0800, Jisheng Zhang wrote:
>>> Hi Peter,
>>>
>>> On Mon, 22 Aug 2016 13:33:08 +0800 Peter Chen wrote:
>>>   
 On Fri, Aug 19, 2016 at 08:10:13PM +0800, Jisheng Zhang wrote:  
> Support generic phy in PM code path: call phy_power_off/phy_power_on
> in ci_controller_suspend/ci_controller_resume.
>
> Signed-off-by: Jisheng Zhang 
> ---
>  drivers/usb/chipidea/core.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index ae12595..ef9fb0b 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -1116,6 +1116,7 @@ static void ci_controller_suspend(struct ci_hdrc 
> *ci)
>   usleep_range(ci->platdata->phy_clkgate_delay_us,
>ci->platdata->phy_clkgate_delay_us + 50);
>   usb_phy_set_suspend(ci->usb_phy, 1);
> + phy_power_off(ci->phy);

 How could you support USB wakeup after PHY is powered off?  
>>>
>>> Per my understanding, the PHY's power off just power off data communication 
>>> part
>>> but leaves the circuits involved in wakeup detection active.
>>>   
>>
>> Ok, I hope so.
> 
> If most parts of the phy can be powered off during runtime suspend to save
> power, or phy HW support suspend mode, with usb phy, usb_phy_set_suspend() 
> could
> be used, but with the generic phy, it seems there's no corresponding API for
> this purpose. I'm not sure whether using phy_power_off() is correct here. Is 
> it
> acceptable to extend the generic phy? such as, phy_suspend()/phy_resume()?

phy_pm_runtime_put() could be used right?

Thanks
Kishon


[PATCH 4/4] irqchip/gicv3-its: Disable the ITS before initializing it

2016-08-22 Thread Marc Zyngier
From: David Daney 

When starting a kexec/kdump kernel, the GIC ITS will already have been
enabled.  According to the ARM Generic Interrupt Controller
Architecture Specification (GIC architecture Version 3.0 and version
4.0), writing to GITS_BASER or GITS_CBASER is "UNPREDICTABLE" when
the ITS is enabled.  On Cavium Thunder systems, this prevents the ITS
from being initializing in the kexec/kdump kernel, resulting in
failure to register/enable interrupts for all devices.

The fix is to disable the ITS if it is not already in the disabled
state.  This allows the ITS to be properly initialized and then
re-enabled in the kexec/kdump kernel.

Acked-by: Marc Zyngier 
Signed-off-by: David Daney 
Signed-off-by: Marc Zyngier 
---
 drivers/irqchip/irq-gic-v3-its.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 7ceaba8..36b9c28 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -1545,7 +1545,12 @@ static int its_force_quiescent(void __iomem *base)
u32 val;
 
val = readl_relaxed(base + GITS_CTLR);
-   if (val & GITS_CTLR_QUIESCENT)
+   /*
+* GIC architecture specification requires the ITS to be both
+* disabled and quiescent for writes to GITS_BASER or
+* GITS_CBASER to not have UNPREDICTABLE results.
+*/
+   if ((val & GITS_CTLR_QUIESCENT) && !(val & GITS_CTLR_ENABLE))
return 0;
 
/* Disable the generation of all interrupts to this ITS */
-- 
2.1.4



[PATCH 3/4] irqchip/gicv3: Remove disabling redistributor and group1 non-secure interrupts

2016-08-22 Thread Marc Zyngier
From: Sudeep Holla 

As per the GICv3 specification, to power down a processor using GICv3
and allow automatic power-on if an interrupt must be sent to a processor,
software must set Enable to zero for all interrupt groups(by writing
to GICC_CTLR or ICC_IGRPEN{0,1}_EL1/3 as appropriate.

When commit 3708d52fc6bb ("irqchip: gic-v3: Implement CPU PM notifier")
was introduced there were no firmware implementations(in particular PSCI)
handling this.

Linux kernel may not be aware of the CPU power state details and might
fail to identify the power states that require quiescing the CPU
interface. Even if it can be aware of those details, it can't determine
which CPU power state have been triggered at the platform level and how
the power control is implemented.

This patch make disabling redistributor and group1 non-secure interrupts
in the power down path and re-enabling of redistributor in the power-up
path conditional. It will be handled in the kernel if and only if the
non-secure accesses are permitted to access and modify control registers.
It is left to the platform implementation otherwise.

Cc: Marc Zyngier 
Cc: Lorenzo Pieralisi 
Cc: Thomas Gleixner 
Cc: Jason Cooper 
Tested-by: Christopher Covington 
Signed-off-by: Sudeep Holla 
Signed-off-by: Marc Zyngier 
---
 drivers/irqchip/irq-gic-v3.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 6fc56c3..ede5672 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -667,13 +667,20 @@ static int gic_set_affinity(struct irq_data *d, const 
struct cpumask *mask_val,
 #endif
 
 #ifdef CONFIG_CPU_PM
+/* Check whether it's single security state view */
+static bool gic_dist_security_disabled(void)
+{
+   return readl_relaxed(gic_data.dist_base + GICD_CTLR) & GICD_CTLR_DS;
+}
+
 static int gic_cpu_pm_notifier(struct notifier_block *self,
   unsigned long cmd, void *v)
 {
if (cmd == CPU_PM_EXIT) {
-   gic_enable_redist(true);
+   if (gic_dist_security_disabled())
+   gic_enable_redist(true);
gic_cpu_sys_reg_init();
-   } else if (cmd == CPU_PM_ENTER) {
+   } else if (cmd == CPU_PM_ENTER && gic_dist_security_disabled()) {
gic_write_grpen1(0);
gic_enable_redist(false);
}
-- 
2.1.4



[RESEND PATCH] genirq: fix potential memleak when failing to get irq pm

2016-08-22 Thread Shawn Lin
Obviously we should free action here if irq_chip_pm_get
failed.

Signed-off-by: Shawn Lin 
---

 kernel/irq/manage.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 73a2b78..9530fcd 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1681,8 +1681,10 @@ int request_threaded_irq(unsigned int irq, irq_handler_t 
handler,
action->dev_id = dev_id;
 
retval = irq_chip_pm_get(>irq_data);
-   if (retval < 0)
+   if (retval < 0) {
+   kfree(action);
return retval;
+   }
 
chip_bus_lock(desc);
retval = __setup_irq(irq, desc, action);
@@ -1985,8 +1987,10 @@ int request_percpu_irq(unsigned int irq, irq_handler_t 
handler,
action->percpu_dev_id = dev_id;
 
retval = irq_chip_pm_get(>irq_data);
-   if (retval < 0)
+   if (retval < 0) {
+   kfree(action);
return retval;
+   }
 
chip_bus_lock(desc);
retval = __setup_irq(irq, desc, action);
-- 
2.3.7




Re: [PATCH 1/2] ARM: dts: Add TOPEET itop core board SCP package version

2016-08-22 Thread Ayaka

Thank you
從我的 iPad 傳送

> Marek Szyprowski  於 2016年8月22日 下午2:50 寫道:
> 
> Dear Randy,
> 
> 
>> On 2016-08-21 22:04, Randy Li wrote:
>> The TOPEET itop is a samsung exnynos 4412 core board, which have
>> two package versions. This patch add the support for SCP version.
>> 
>> Currently supported are USB3503A HSIC, USB OTG, eMMC, RTC and PMIC.
>> The future features are in the based board. Also MFC and watchdog
>> have been enabled.
>> 
>> Signed-off-by: Randy Li 
>> ---
>>  arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi | 434 
>> 
>>  1 file changed, 434 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
>> 
>> diff --git a/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi 
>> b/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
>> new file mode 100644
>> index 000..0860ee6
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
>> @@ -0,0 +1,434 @@
>> +/*
>> + * TOPEET's Exynos4412 based itop board device tree source
>> + *
>> + * Copyright (c) 2016 SUMOMO Computer Association
>> + *https://www.sumomo.mobi
>> + *Randy Li 
>> + *
>> + * Device tree source file for TOPEET iTop Exynos 4412 SCP package core
>> + * board which is based on Samsung's Exynos4412 SoC.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> +*/
>> +
>> +#include "exynos4412.dtsi"
>> +#include 
>> +#include 
>> +
>> +/ {
>> +memory {
>> +reg = <0x4000 0x4000>;
>> +};
>> +
>> +firmware@0203F000 {
>> +compatible = "samsung,secure-firmware";
>> +reg = <0x0203F000 0x1000>;
>> +};
>> +
>> +display-timings {
>> +native-mode = <>;
>> +timing0: timing {
>> +clock-frequency = <4750>;
>> +hactive = <1024>;
>> +vactive = <600>;
>> +hfront-porch = <64>;
>> +hback-porch = <16>;
>> +hsync-len = <48>;
>> +vback-porch = <64>;
>> +vfront-porch = <16>;
>> +vsync-len = <3>;
>> +};
>> +};
>> +
>> +fixed-rate-clocks {
>> +xxti {
>> +compatible = "samsung,clock-xxti";
>> +clock-frequency = <0>;
>> +};
>> +
>> +xusbxti {
>> +compatible = "samsung,clock-xusbxti";
>> +clock-frequency = <2400>;
>> +};
>> +};
>> +
>> +usb-hub {
>> +compatible = "smsc,usb3503a";
>> +reset-gpios = < 4 GPIO_ACTIVE_LOW>;
>> +connect-gpios = < 3 GPIO_ACTIVE_HIGH>;
>> +intn-gpios = < 3 GPIO_ACTIVE_HIGH>;
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_reset>;
>> +};
>> +};
>> +
>> + {
>> +cpu0-supply = <_reg>;
>> +};
>> +
>> +_1 {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +samsung,i2c-sda-delay = <100>;
>> +samsung,i2c-max-bus-freq = <40>;
>> +pinctrl-0 = <_bus>;
>> +pinctrl-names = "default";
>> +status = "okay";
>> +
>> +s5m8767_pmic@66 {
>> +compatible = "samsung,s5m8767-pmic";
>> +reg = <0x66>;
>> +
>> +s5m8767,pmic-buck-default-dvs-idx = <3>;
>> +
>> +s5m8767,pmic-buck-dvs-gpios = < 5 GPIO_ACTIVE_HIGH>,
>> + < 6 GPIO_ACTIVE_HIGH>,
>> + < 7 GPIO_ACTIVE_HIGH>;
>> +
>> +s5m8767,pmic-buck-ds-gpios = < 5 GPIO_ACTIVE_HIGH>,
>> +< 6 GPIO_ACTIVE_HIGH>,
>> +< 7 GPIO_ACTIVE_HIGH>;
>> +
>> +/* VDD_ARM */
>> +s5m8767,pmic-buck2-dvs-voltage = <1356250>, <130>,
>> + <1243750>, <1118750>,
>> + <1068750>, <1012500>,
>> + <956250>, <90>;
>> +/* VDD_INT */
>> +s5m8767,pmic-buck3-dvs-voltage = <100>, <100>,
>> + <925000>, <925000>,
>> + <887500>, <887500>,
>> + <85>, <85>;
>> +/* VDD_G3D */
>> +s5m8767,pmic-buck4-dvs-voltage = <1081250>, <1081250>,
>> + <1025000>, <95>,
>> + <918750>, <90>,
>> + <875000>, <831250>;
>> +
>> +regulators {
>> +ldo1_reg: LDO1 {
>> +regulator-name = "VDD_ALIVE";
>> +regulator-min-microvolt = <110>;
>> +regulator-max-microvolt = <110>;
>> +regulator-always-on;
>> +regulator-boot-on;
>> +op_mode = <1>; /* Normal Mode */
>> +};
>> +
>> +/* SCP uses 1.5v, POP uses 1.2v */
>> +ldo2_reg: LDO2 {
>> +regulator-name = "VDDQ_M12";
>> +regulator-min-microvolt = 

[PATCH v12 4/4] arm: dts: mt2701: Use real clock for UARTs

2016-08-22 Thread Erin Lo
We used to use a fixed rate clock for the UARTs. Now that we have clock
support we can associate the correct clocks to the UARTs and drop the
26MHz fixed rate UART clock.

Signed-off-by: Erin Lo 
---
 arch/arm/boot/dts/mt2701.dtsi | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index c9a8dbf..7eab6f4 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -73,12 +73,6 @@
#clock-cells = <0>;
};
 
-   uart_clk: dummy26m {
-   compatible = "fixed-clock";
-   clock-frequency = <2600>;
-   #clock-cells = <0>;
-   };
-
clk26m: oscillator@0 {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -186,7 +180,8 @@
 "mediatek,mt6577-uart";
reg = <0 0x11002000 0 0x400>;
interrupts = ;
-   clocks = <_clk>;
+   clocks = < CLK_PERI_UART0_SEL>, < 
CLK_PERI_UART0>;
+   clock-names = "baud", "bus";
status = "disabled";
};
 
@@ -195,7 +190,8 @@
 "mediatek,mt6577-uart";
reg = <0 0x11003000 0 0x400>;
interrupts = ;
-   clocks = <_clk>;
+   clocks = < CLK_PERI_UART1_SEL>, < 
CLK_PERI_UART1>;
+   clock-names = "baud", "bus";
status = "disabled";
};
 
@@ -204,7 +200,8 @@
 "mediatek,mt6577-uart";
reg = <0 0x11004000 0 0x400>;
interrupts = ;
-   clocks = <_clk>;
+   clocks = < CLK_PERI_UART2_SEL>, < 
CLK_PERI_UART2>;
+   clock-names = "baud", "bus";
status = "disabled";
};
 
@@ -213,7 +210,8 @@
 "mediatek,mt6577-uart";
reg = <0 0x11005000 0 0x400>;
interrupts = ;
-   clocks = <_clk>;
+   clocks = < CLK_PERI_UART3_SEL>, < 
CLK_PERI_UART3>;
+   clock-names = "baud", "bus";
status = "disabled";
};
 };
-- 
1.9.1



[PATCH v12 3/4] arm: dts: mt2701: Add clock controller device nodes

2016-08-22 Thread Erin Lo
From: James Liao 

Add clock controller nodes for MT2701, include topckgen, infracfg,
pericfg, apmixedsys, mmsys, imgsys, vdecsys, hifsys, ethsys and
bdpsys. This patch also add two oscillators that provide clocks for
MT2701.

Signed-off-by: James Liao 
Signed-off-by: Erin Lo 
---
 arch/arm/boot/dts/mt2701.dtsi | 42 ++
 1 file changed, 42 insertions(+)

diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 18596a2..c9a8dbf 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -12,8 +12,10 @@
  * GNU General Public License for more details.
  */
 
+#include 
 #include 
 #include 
+#include 
 #include "skeleton64.dtsi"
 #include "mt2701-pinfunc.h"
 
@@ -77,6 +79,20 @@
#clock-cells = <0>;
};
 
+   clk26m: oscillator@0 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2600>;
+   clock-output-names = "clk26m";
+   };
+
+   rtc32k: oscillator@1 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <32000>;
+   clock-output-names = "rtc32k";
+   };
+
timer {
compatible = "arm,armv7-timer";
interrupt-parent = <>;
@@ -104,6 +120,26 @@
reg = <0 0x10005000 0 0x1000>;
};
 
+   topckgen: syscon@1000 {
+   compatible = "mediatek,mt2701-topckgen", "syscon";
+   reg = <0 0x1000 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
+   infracfg: syscon@10001000 {
+   compatible = "mediatek,mt2701-infracfg", "syscon";
+   reg = <0 0x10001000 0 0x1000>;
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   };
+
+   pericfg: syscon@10003000 {
+   compatible = "mediatek,mt2701-pericfg", "syscon";
+   reg = <0 0x10003000 0 0x1000>;
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   };
+
watchdog: watchdog@10007000 {
compatible = "mediatek,mt2701-wdt",
 "mediatek,mt6589-wdt";
@@ -128,6 +164,12 @@
reg = <0 0x10200100 0 0x1c>;
};
 
+   apmixedsys: syscon@10209000 {
+   compatible = "mediatek,mt2701-apmixedsys", "syscon";
+   reg = <0 0x10209000 0 0x1000>;
+   #clock-cells = <1>;
+   };
+
gic: interrupt-controller@10211000 {
compatible = "arm,cortex-a7-gic";
interrupt-controller;
-- 
1.9.1



Re: [tip:perf/core] perf/core: Check return value of the perf_event_read() IPI

2016-08-22 Thread Jiri Olsa
On Mon, Aug 22, 2016 at 09:17:37AM +0200, Jiri Olsa wrote:
> On Sun, Aug 21, 2016 at 02:10:07PM +0200, Vegard Nossum wrote:
> 
> SNIP
> 
> > [] ? __fget+0x47/0x270
> > [] vfs_readv+0x8b/0xc0
> > [] do_readv+0xde/0x230
> > [] ? vfs_readv+0xc0/0xc0
> > [] ? exit_to_usermode_loop+0x190/0x190
> > [] ? check_preemption_disabled+0x37/0x1e0
> > [] SyS_readv+0x27/0x30
> > [] ? do_pwritev+0x1a0/0x1a0
> > [] do_syscall_64+0x1c4/0x4e0
> > [] entry_SYSCALL64_slow_path+0x25/0x25
> > 
> > I don't think WARN() is the right interface for signalling errors to
> > userspace programs?
> 
> any special way to trigger that?

nope ;-)

perf stat -a -I 10

jirka


--
[  430.168408] [ cut here ]
[  430.173596] WARNING: CPU: 10 PID: 3878 at kernel/events/core.c:3583 
perf_event_read+0x1cc/0x1e0
[  430.183321] Modules linked in: intel_rapl sb_edac edac_core 
x86_pkg_temp_thermal coretemp iTCO_wdt crct10dif_pclmul iTCO_vendor_support 
crc32_pclmul ghash_clmulni_intel cdc_ether usbnet mii ioatdma i2c_i801 lpc_ich 
i2c_smbus wmi xfs libcrc32c mgag200 drm_kms_helper igb ttm ptp pps_core 
crc32c_intel dca drm i2c_algo_bit megaraid_sas fjes
[  430.217193] CPU: 10 PID: 3878 Comm: perf Not tainted 4.8.0-rc2+ #227
[  430.224282] Hardware name: IBM System x3650 M4 : -[7915E2G]-/00Y7683, BIOS 
-[VVE124AUS-1.30]- 11/21/2012
[  430.234863]  0286 e92a6a39 880275c7bcd8 
813ba21e
[  430.243156]    880275c7bd18 
810a16ab
[  430.251446]  0dff75c7bd78 88047444c000 880275c7bde0 
0003
[  430.259736] Call Trace:
[  430.262466]  [] dump_stack+0x63/0x85
[  430.268193]  [] __warn+0xcb/0xf0
[  430.273539]  [] warn_slowpath_null+0x1d/0x20
[  430.280048]  [] perf_event_read+0x1cc/0x1e0
[  430.286461]  [] perf_event_read_value+0x45/0x130
[  430.293358]  [] perf_read+0x93/0x2c0
[  430.299093]  [] ? file_has_perm+0xa9/0xb0
[  430.305314]  [] __vfs_read+0x37/0x150
[  430.311137]  [] ? security_file_permission+0xa0/0xc0
[  430.318431]  [] vfs_read+0x95/0x140
[  430.324069]  [] SyS_read+0x55/0xc0
[  430.329610]  [] entry_SYSCALL_64_fastpath+0x1a/0xa4
[  430.336820] ---[ end trace 671c766962c86ad2 ]---


[PATCH v12 0/4] Add clock support for Mediatek MT2701

2016-08-22 Thread Erin Lo
This series is based on clk-next, add clock and reset controller support
for Mediatek MT2701.

Since some patches in v11 had been applied into clk-next, they were not
included in v12 series.

changes since v11:
- Rebase to clk-next.
- Return error code from probe() if clock registration fail.

changes since v10:
- Remove COMMON_CLK dependency from clk/mediatek/Kconfig.

changes since v9:
- Rebase to v4.8-rc1.
- Drop a fix patch of parent clock initial state. It will be replaced by a new
  patch from Mike/Stephen.
- Replace clk.h with clk-provider.h.
- Correct register settings of clocks.

changes since v8:
- Rebase to v4.7-rc1.
- Include mt2701-resets.h in mt2701.dtsi.
- Remove an unused property from apmixedsys DT node.

changes since v7:
- Rebase to clk-next.
- Implement subsystem clocks in seperated files.
- Replace critical clock enabling with CLK_IS_CRITICAL flag.
- Reduce most clock registrations in CLK_OF_DECLARE().
- Remove __init and __initconst from most init fucntions and data,
  and replace driver registration with platform_driver_register().
- Replace some common function or variable names with unique names.
- Use real clock for UARTs.

changes since v6:
- Rebase to v4.6-rc1.
- Register subsystem clocks in probe() instead of CLK_OF_DECLARE().
- Add clocks that referred by subsystem clocks.
- Fix clk_data size of apmixedsys.
- Add config options for each subsystem clock provider.

changes since v5:
- Rebase to v4.5-rc1 and [1].
- Enable critical clocks for MT2701
- Refine dt-binding documents, add reset controller support for hifsys.

changes since v4:
- Rebase to v4.5-rc1.
- Remove CLK_SET_RATE_PARENT from divider flags.
- Add img_jpgdec_smi clock.
- Move clk/mediatek/Kconfig into menu section in clk/Kconfig.

changes since v3:
- Change the parent of mm_mdp_bls_26m from clk26m to pwm_sel.

changes since v2:
- Fix ethsys definition.
- Replace read-modify-write with regmap_update_bits() in clock operations.
- Move mt2701-resets.h to include/dt-bindings/reset/.
- Add hifsys reset patch from John Crispin.

changes since v1:
- Document MT2701 compatible strings.

[1] https://patchwork.kernel.org/patch/8147901/

Erin Lo (1):
  arm: dts: mt2701: Use real clock for UARTs

James Liao (1):
  arm: dts: mt2701: Add clock controller device nodes

Shunli Wang (2):
  clk: mediatek: Add MT2701 clock support
  reset: mediatek: Add MT2701 reset driver

 arch/arm/boot/dts/mt2701.dtsi  |   50 +-
 drivers/clk/mediatek/Kconfig   |   43 ++
 drivers/clk/mediatek/Makefile  |7 +
 drivers/clk/mediatek/clk-gate.c|   52 ++
 drivers/clk/mediatek/clk-gate.h|2 +
 drivers/clk/mediatek/clk-mt2701-bdp.c  |  141 +
 drivers/clk/mediatek/clk-mt2701-eth.c  |   83 +++
 drivers/clk/mediatek/clk-mt2701-hif.c  |   84 +++
 drivers/clk/mediatek/clk-mt2701-img.c  |   83 +++
 drivers/clk/mediatek/clk-mt2701-mm.c   |  126 
 drivers/clk/mediatek/clk-mt2701-vdec.c |   94 +++
 drivers/clk/mediatek/clk-mt2701.c  | 1047 
 drivers/clk/mediatek/clk-mtk.c |   40 ++
 drivers/clk/mediatek/clk-mtk.h |   41 +-
 drivers/clk/mediatek/clk-pll.c |1 +
 15 files changed, 1884 insertions(+), 10 deletions(-)
 create mode 100644 drivers/clk/mediatek/clk-mt2701-bdp.c
 create mode 100644 drivers/clk/mediatek/clk-mt2701-eth.c
 create mode 100644 drivers/clk/mediatek/clk-mt2701-hif.c
 create mode 100644 drivers/clk/mediatek/clk-mt2701-img.c
 create mode 100644 drivers/clk/mediatek/clk-mt2701-mm.c
 create mode 100644 drivers/clk/mediatek/clk-mt2701-vdec.c
 create mode 100644 drivers/clk/mediatek/clk-mt2701.c

--
1.9.1



[PATCH v12 1/4] clk: mediatek: Add MT2701 clock support

2016-08-22 Thread Erin Lo
From: Shunli Wang 

Add MT2701 clock support, include topckgen, apmixedsys,
infracfg, pericfg and subsystem clocks.

Signed-off-by: Shunli Wang 
Signed-off-by: James Liao 
Signed-off-by: Erin Lo 
Tested-by: John Crispin 
---
 drivers/clk/mediatek/Kconfig   |   43 ++
 drivers/clk/mediatek/Makefile  |7 +
 drivers/clk/mediatek/clk-gate.c|   52 ++
 drivers/clk/mediatek/clk-gate.h|2 +
 drivers/clk/mediatek/clk-mt2701-bdp.c  |  141 +
 drivers/clk/mediatek/clk-mt2701-eth.c  |   83 +++
 drivers/clk/mediatek/clk-mt2701-hif.c  |   80 +++
 drivers/clk/mediatek/clk-mt2701-img.c  |   83 +++
 drivers/clk/mediatek/clk-mt2701-mm.c   |  126 
 drivers/clk/mediatek/clk-mt2701-vdec.c |   94 +++
 drivers/clk/mediatek/clk-mt2701.c  | 1039 
 drivers/clk/mediatek/clk-mtk.c |   40 ++
 drivers/clk/mediatek/clk-mtk.h |   41 +-
 drivers/clk/mediatek/clk-pll.c |1 +
 14 files changed, 1827 insertions(+), 5 deletions(-)
 create mode 100644 drivers/clk/mediatek/clk-mt2701-bdp.c
 create mode 100644 drivers/clk/mediatek/clk-mt2701-eth.c
 create mode 100644 drivers/clk/mediatek/clk-mt2701-hif.c
 create mode 100644 drivers/clk/mediatek/clk-mt2701-img.c
 create mode 100644 drivers/clk/mediatek/clk-mt2701-mm.c
 create mode 100644 drivers/clk/mediatek/clk-mt2701-vdec.c
 create mode 100644 drivers/clk/mediatek/clk-mt2701.c

diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index 380c372..7202db5 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -6,6 +6,49 @@ config COMMON_CLK_MEDIATEK
---help---
  Mediatek SoCs' clock support.
 
+config COMMON_CLK_MT2701
+   bool "Clock driver for Mediatek MT2701"
+   select COMMON_CLK_MEDIATEK
+   default ARCH_MEDIATEK
+   ---help---
+ This driver supports Mediatek MT2701 basic clocks.
+
+config COMMON_CLK_MT2701_MMSYS
+   bool "Clock driver for Mediatek MT2701 mmsys"
+   select COMMON_CLK_MT2701
+   ---help---
+ This driver supports Mediatek MT2701 mmsys clocks.
+
+config COMMON_CLK_MT2701_IMGSYS
+   bool "Clock driver for Mediatek MT2701 imgsys"
+   select COMMON_CLK_MT2701
+   ---help---
+ This driver supports Mediatek MT2701 imgsys clocks.
+
+config COMMON_CLK_MT2701_VDECSYS
+   bool "Clock driver for Mediatek MT2701 vdecsys"
+   select COMMON_CLK_MT2701
+   ---help---
+ This driver supports Mediatek MT2701 vdecsys clocks.
+
+config COMMON_CLK_MT2701_HIFSYS
+   bool "Clock driver for Mediatek MT2701 hifsys"
+   select COMMON_CLK_MT2701
+   ---help---
+ This driver supports Mediatek MT2701 hifsys clocks.
+
+config COMMON_CLK_MT2701_ETHSYS
+   bool "Clock driver for Mediatek MT2701 ethsys"
+   select COMMON_CLK_MT2701
+   ---help---
+ This driver supports Mediatek MT2701 ethsys clocks.
+
+config COMMON_CLK_MT2701_BDPSYS
+   bool "Clock driver for Mediatek MT2701 bdpsys"
+   select COMMON_CLK_MT2701
+   ---help---
+ This driver supports Mediatek MT2701 bdpsys clocks.
+
 config COMMON_CLK_MT8135
bool "Clock driver for Mediatek MT8135"
select COMMON_CLK_MEDIATEK
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 32e7222..19ae7ef 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -1,4 +1,11 @@
 obj-$(CONFIG_COMMON_CLK_MEDIATEK) += clk-mtk.o clk-pll.o clk-gate.o 
clk-apmixed.o
 obj-$(CONFIG_RESET_CONTROLLER) += reset.o
+obj-$(CONFIG_COMMON_CLK_MT2701) += clk-mt2701.o
+obj-$(CONFIG_COMMON_CLK_MT2701_BDPSYS) += clk-mt2701-bdp.o
+obj-$(CONFIG_COMMON_CLK_MT2701_ETHSYS) += clk-mt2701-eth.o
+obj-$(CONFIG_COMMON_CLK_MT2701_HIFSYS) += clk-mt2701-hif.o
+obj-$(CONFIG_COMMON_CLK_MT2701_IMGSYS) += clk-mt2701-img.o
+obj-$(CONFIG_COMMON_CLK_MT2701_MMSYS) += clk-mt2701-mm.o
+obj-$(CONFIG_COMMON_CLK_MT2701_VDECSYS) += clk-mt2701-vdec.o
 obj-$(CONFIG_COMMON_CLK_MT8135) += clk-mt8135.o
 obj-$(CONFIG_COMMON_CLK_MT8173) += clk-mt8173.o
diff --git a/drivers/clk/mediatek/clk-gate.c b/drivers/clk/mediatek/clk-gate.c
index d8787bf..934bf0e 100644
--- a/drivers/clk/mediatek/clk-gate.c
+++ b/drivers/clk/mediatek/clk-gate.c
@@ -61,6 +61,22 @@ static void mtk_cg_clr_bit(struct clk_hw *hw)
regmap_write(cg->regmap, cg->clr_ofs, BIT(cg->bit));
 }
 
+static void mtk_cg_set_bit_no_setclr(struct clk_hw *hw)
+{
+   struct mtk_clk_gate *cg = to_mtk_clk_gate(hw);
+   u32 cgbit = BIT(cg->bit);
+
+   regmap_update_bits(cg->regmap, cg->sta_ofs, cgbit, cgbit);
+}
+
+static void mtk_cg_clr_bit_no_setclr(struct clk_hw *hw)
+{
+   struct mtk_clk_gate *cg = to_mtk_clk_gate(hw);
+   u32 cgbit = BIT(cg->bit);
+
+   regmap_update_bits(cg->regmap, cg->sta_ofs, cgbit, 0);
+}
+
 static int mtk_cg_enable(struct clk_hw 

[PATCH v12 2/4] reset: mediatek: Add MT2701 reset driver

2016-08-22 Thread Erin Lo
From: Shunli Wang 

In infrasys and perifsys, there are many reset
control bits for kinds of modules. These bits are
used as actual reset controllers to be registered
into kernel's generic reset controller framework.

Signed-off-by: Shunli Wang 
Signed-off-by: James Liao 
Signed-off-by: Erin Lo 
Tested-by: John Crispin 
Acked-by: Philipp Zabel 
---
 drivers/clk/mediatek/clk-mt2701-hif.c |  8 ++--
 drivers/clk/mediatek/clk-mt2701.c | 16 
 2 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/mediatek/clk-mt2701-hif.c 
b/drivers/clk/mediatek/clk-mt2701-hif.c
index 18b4ab5..702fd74 100644
--- a/drivers/clk/mediatek/clk-mt2701-hif.c
+++ b/drivers/clk/mediatek/clk-mt2701-hif.c
@@ -52,11 +52,15 @@ static int mtk_hifsys_init(struct device_node *node)
clk_data);
 
r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
-   if (r)
+   if (r) {
pr_err("%s(): could not register clock provider: %d\n",
__func__, r);
+   return r;
+   }
+
+   mtk_register_reset_controller(node, 1, 0x34);
 
-   return r;
+   return 0;
 }
 
 static const struct of_device_id of_match_clk_mt2701_hif[] = {
diff --git a/drivers/clk/mediatek/clk-mt2701.c 
b/drivers/clk/mediatek/clk-mt2701.c
index f6df578..c8cc583 100644
--- a/drivers/clk/mediatek/clk-mt2701.c
+++ b/drivers/clk/mediatek/clk-mt2701.c
@@ -790,11 +790,15 @@ static int mtk_infrasys_init(struct device_node *node)
infra_clk_data);
 
r = of_clk_add_provider(node, of_clk_src_onecell_get, infra_clk_data);
-   if (r)
+   if (r) {
pr_err("%s(): could not register clock provider: %d\n",
__func__, r);
+   return r;
+   }
 
-   return r;
+   mtk_register_reset_controller(node, 2, 0x30);
+
+   return 0;
 }
 
 static const struct mtk_gate_regs peri0_cg_regs = {
@@ -912,11 +916,15 @@ static int mtk_pericfg_init(struct device_node *node)
, clk_data);
 
r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
-   if (r)
+   if (r) {
pr_err("%s(): could not register clock provider: %d\n",
__func__, r);
+   return r;
+   }
 
-   return r;
+   mtk_register_reset_controller(node, 2, 0x0);
+
+   return 0;
 }
 
 #define MT8590_PLL_FMAX(2000 * MHZ)
-- 
1.9.1



Re: [PATCH 2/2] proc: task_mmu: Reduce output processing cpu time

2016-08-22 Thread Joe Perches
On Mon, 2016-08-22 at 01:00 -0700, Joe Perches wrote:
> On Mon, 2016-08-22 at 09:24 +0200, Michal Hocko wrote:
> > On Sat 20-08-16 01:00:17, Joe Perches wrote:
[]
> > > static int proc_maps_open(struct inode *inode, struct file *file,
> > >   const struct seq_operations *ops, int psize)
> > >  {
> > > - struct proc_maps_private *priv = __seq_open_private(file, ops, psize);
> > > + struct proc_maps_private *priv;
> > > + struct mm_struct *mm;
> > > +
> > > + mm = proc_mem_open(inode, PTRACE_MODE_READ);
> > > + if (IS_ERR(mm))
> > > + return PTR_ERR(mm);
> > >  
> > > + priv = __seq_open_private_bufsize(file, ops, psize,
> > > +   mm && mm->map_count ?
> > > +   mm->map_count * 0x300 : PAGE_SIZE);
> > NAK to this!
> > 
> > Seriously, this just gives any random user access to user
> > defined amount of memory which not accounted, not reclaimable and a
> > potential consumer of any higher order blocks.
> I completely disagree here with your rationale here.

And with further review and your comment above, I withdraw this patch.
cheers, Joe



Re: [PATCH v6 3/4] SCT Write Same / DSM Trim

2016-08-22 Thread Tom Yan
As mentioned before, as of the latest draft of ACS-4, nothing about a
larger payload size is mentioned. Conservatively speaking, it sort of
means that we are allowing four 512-byte block payload on 4Kn device
regardless of the reported limit in the IDENTIFY DEVICE data. I am
really not sure if it's a good thing to do. Doesn't seem necessary
anyway, especially when our block layer does not support such a large
bio size (well, yet), so each request will end up using a payload of
two 512-byte blocks at max anyway.

Also, it's IMHO better to do it in a seperate patch (series) after the
SCT Write Same support has entered libata's repo too, because this has
nothing to with it but TRIM translation. In case the future ACS
standards has clearer/better instruction on this, it will be easier
for us to revert/follow up too.

And you'll need to fix the Block Limits VPD simulation
(ata_scsiop_inq_b0) too, so that it will advertise the Maximum Write
Same Length dynamically as per the logical sector size, otherwise your
effort will be completely in vain, even if our block layer is
overhauled in the future.

Please be noted that, since your haven't touched ata_scsiop_inq_b0 at
all, the reported Maximum Write Same Length will be:

On device with TRIM support:
- 4194240 LOGICAL sector per request split / command
-- ~=2G on non-4Kn drives
-- ~=16G on non-4Kn drives

On device without TRIM support:
- 0 --> SD_MAX_WS10_BLOCKS (65535) per request split / command
-- ~= 32M on non-4Kn drives
-- ~=256M on non-4Kn drives

Even if we ignore the upper limit(s) of the block layer, do we want
such inconsistencies?

On 22 August 2016 at 04:23, Shaun Tancheff  wrote:
> Correct handling of devices with sector_size other that 512 bytes.
>
> Signed-off-by: Shaun Tancheff 
> ---
> In the case of a 4Kn device sector_size it is possible to describe a much
> larger DSM Trim than the current fixed default of 512 bytes.
>
> This patch assumes the minimum descriptor is sector_size and fills out
> the descriptor accordingly.
>
> The ACS-2 specification is quite clear that the DSM command payload is
> sized as number of 512 byte transfers so a 4Kn device will operate
> correctly without this patch.
>
> v5:
>  - Added support for a sector_size descriptor other than 512 bytes.
>
>  drivers/ata/libata-scsi.c | 85 
> +++
>  1 file changed, 57 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
> index ebf1a04..37f456e 100644
> --- a/drivers/ata/libata-scsi.c
> +++ b/drivers/ata/libata-scsi.c
> @@ -3283,7 +3283,7 @@ static unsigned int ata_scsi_pass_thru(struct 
> ata_queued_cmd *qc)
>  /**
>   * ata_format_dsm_trim_descr() - SATL Write Same to DSM Trim
>   * @cmd: SCSI command being translated
> - * @num: Maximum number of entries (nominally 64).
> + * @trmax: Maximum number of entries that will fit in sector_size bytes.
>   * @sector: Starting sector
>   * @count: Total Range of request in logical sectors
>   *
> @@ -3298,63 +3298,80 @@ static unsigned int ata_scsi_pass_thru(struct 
> ata_queued_cmd *qc)
>   *  LBA's should be sorted order and not overlap.
>   *
>   * NOTE: this is the same format as ADD LBA(S) TO NV CACHE PINNED SET
> + *
> + * Return: Number of bytes copied into sglist.
>   */
> -static unsigned int ata_format_dsm_trim_descr(struct scsi_cmnd *cmd, u32 num,
> - u64 sector, u32 count)
> +static size_t ata_format_dsm_trim_descr(struct scsi_cmnd *cmd, u32 trmax,
> +   u64 sector, u32 count)
>  {
> -   __le64 *buffer;
> -   u32 i = 0, used_bytes;
> +   struct scsi_device *sdp = cmd->device;
> +   size_t len = sdp->sector_size;
> +   size_t r;
> +   __le64 *buf;
> +   u32 i = 0;
> unsigned long flags;
>
> -   BUILD_BUG_ON(512 > ATA_SCSI_RBUF_SIZE);
> +   WARN_ON(len > ATA_SCSI_RBUF_SIZE);
> +
> +   if (len > ATA_SCSI_RBUF_SIZE)
> +   len = ATA_SCSI_RBUF_SIZE;
>
> spin_lock_irqsave(_scsi_rbuf_lock, flags);
> -   buffer = ((void *)ata_scsi_rbuf);
> -   while (i < num) {
> +   buf = ((void *)ata_scsi_rbuf);
> +   memset(buf, 0, len);
> +   while (i < trmax) {
> u64 entry = sector |
> ((u64)(count > 0x ? 0x : count) << 48);
> -   buffer[i++] = __cpu_to_le64(entry);
> +   buf[i++] = __cpu_to_le64(entry);
> if (count <= 0x)
> break;
> count -= 0x;
> sector += 0x;
> }
> -
> -   used_bytes = ALIGN(i * 8, 512);
> -   memset(buffer + i, 0, used_bytes - i * 8);
> -   sg_copy_from_buffer(scsi_sglist(cmd), scsi_sg_count(cmd), buffer, 
> 512);
> +   r = sg_copy_from_buffer(scsi_sglist(cmd), scsi_sg_count(cmd), buf, 
> len);
> spin_unlock_irqrestore(_scsi_rbuf_lock, 

Re: [PATCH] drm/gma500: dont expose bytes from kernel stack

2016-08-22 Thread Jani Nikula
On Sun, 21 Aug 2016, Heinrich Schuchardt  wrote:
> Components m1, m2, p2, dot, vco of variable clock should be
> initialized to avoid bytes from the kernel stack to be
> exposed.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  drivers/gpu/drm/gma500/oaktrail_crtc.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc.c 
> b/drivers/gpu/drm/gma500/oaktrail_crtc.c
> index da9fd34..28bd8f3 100644
> --- a/drivers/gpu/drm/gma500/oaktrail_crtc.c
> +++ b/drivers/gpu/drm/gma500/oaktrail_crtc.c
> @@ -138,6 +138,7 @@ static bool mrst_sdvo_find_best_pll(const struct 
> gma_limit_t *limit,
>   u32 target_vco, actual_freq;
>   s32 freq_error, min_error = 10;
>  
> + memset(clock, 0, sizeof(struct gma_clock_t));

Did you build this? Did you run this?

BR,
Jani.


>   memset(best_clock, 0, sizeof(*best_clock));
>  
>   for (clock.m = limit->m.min; clock.m <= limit->m.max; clock.m++) {

-- 
Jani Nikula, Intel Open Source Technology Center


Re: [PATCH] usb: chipidea: support generic phy in PM code path

2016-08-22 Thread Jisheng Zhang


On Mon, 22 Aug 2016 13:53:37 +0530 Kishon Vijay Abraham I wrote:

> Hi,
> 
> On Monday 22 August 2016 01:44 PM, Jisheng Zhang wrote:
> > + Kishon
> > 
> > Hi Peter, Kishon,
> > 
> > On Mon, 22 Aug 2016 15:29:07 +0800 Peter Chen wrote:
> >   
> >> On Mon, Aug 22, 2016 at 02:39:21PM +0800, Jisheng Zhang wrote:  
> >>> Hi Peter,
> >>>
> >>> On Mon, 22 Aug 2016 13:33:08 +0800 Peter Chen wrote:
> >>> 
>  On Fri, Aug 19, 2016 at 08:10:13PM +0800, Jisheng Zhang wrote:
> > Support generic phy in PM code path: call phy_power_off/phy_power_on
> > in ci_controller_suspend/ci_controller_resume.
> >
> > Signed-off-by: Jisheng Zhang 
> > ---
> >  drivers/usb/chipidea/core.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > index ae12595..ef9fb0b 100644
> > --- a/drivers/usb/chipidea/core.c
> > +++ b/drivers/usb/chipidea/core.c
> > @@ -1116,6 +1116,7 @@ static void ci_controller_suspend(struct ci_hdrc 
> > *ci)
> > usleep_range(ci->platdata->phy_clkgate_delay_us,
> >  ci->platdata->phy_clkgate_delay_us + 50);
> > usb_phy_set_suspend(ci->usb_phy, 1);
> > +   phy_power_off(ci->phy);  
> 
>  How could you support USB wakeup after PHY is powered off?
> >>>
> >>> Per my understanding, the PHY's power off just power off data 
> >>> communication part
> >>> but leaves the circuits involved in wakeup detection active.
> >>> 
> >>
> >> Ok, I hope so.  
> > 
> > If most parts of the phy can be powered off during runtime suspend to save
> > power, or phy HW support suspend mode, with usb phy, usb_phy_set_suspend() 
> > could
> > be used, but with the generic phy, it seems there's no corresponding API for
> > this purpose. I'm not sure whether using phy_power_off() is correct here. 
> > Is it
> > acceptable to extend the generic phy? such as, phy_suspend()/phy_resume()?  
> 
> phy_pm_runtime_put() could be used right?
> 

oh yeah, Great!!! Thanks for the inspiration. Now, I know what should I do for 
my
platform and the chipidea core driver ;)

Will cook a v2 patch

Thank you so much,
Jisheng


Re: [PATCH v8 1/4] nmi_backtrace: add more trigger_*_cpu_backtrace() methods

2016-08-22 Thread Petr Mladek
On Fri 2016-08-19 21:54:31, Chris Metcalf wrote:
> On 8/18/2016 10:12 AM, Petr Mladek wrote:
> >On Tue 2016-08-16 15:50:21, Chris Metcalf wrote:
> >>Currently you can only request a backtrace of either all cpus, or
> >>all cpus but yourself.  It can also be helpful to request a remote
> >>backtrace of a single cpu, and since we want that, the logical
> >>extension is to support a cpumask as the underlying primitive.
> >>
> >>This change modifies the existing lib/nmi_backtrace.c code to take
> >>a cpumask as its basic primitive, and modifies the linux/nmi.h code
> >>to use the new "cpumask" method instead.
> >>
> >>The mips code ignored the "include_self" boolean but with this change
> >>it will now also dump a local backtrace if requested.
> >>
> >>diff --git a/arch/mips/kernel/process.c b/arch/mips/kernel/process.c
> >>index 7429ad09fbe3..fea1fa7726e3 100644
> >>--- a/arch/mips/kernel/process.c
> >>+++ b/arch/mips/kernel/process.c
> >>@@ -569,9 +569,16 @@ static void arch_dump_stack(void *info)
> >>dump_stack();
> >>  }
> >>-void arch_trigger_all_cpu_backtrace(bool include_self)
> >>+void arch_trigger_cpumask_backtrace(const cpumask_t *mask, bool 
> >>exclude_self)
> >>  {
> >>-   smp_call_function(arch_dump_stack, NULL, 1);
> >>+   long this_cpu = get_cpu();
> >>+
> >>+   if (cpumask_test_cpu(this_cpu, mask) && !exclude_self)
> >>+   dump_stack();
> >The bit is not cleared in the mask. Therefore arch_dump_stack
> >will get called for this CPU as well.
> 
> Actually, and kind of confusingly, smp_call_function_many() never calls
> the current cpu, even if it is in the mask.  So this code is OK as-is.

I see it now.

> >Otherwise the patch patch looks good to me.
> 
> Great, thanks!  Should I add your Reviewed-by?

Yup. This patch looks fine then:

Reviewed-by: Petr Mladek 

Best Regards,
Petr


Re: [PATCH v6 3/4] SCT Write Same / DSM Trim

2016-08-22 Thread Tom Yan
On 22 August 2016 at 08:31, Tom Yan  wrote:
> As mentioned before, as of the latest draft of ACS-4, nothing about a
> larger payload size is mentioned. Conservatively speaking, it sort of

*payload block size

> means that we are allowing four 512-byte block payload on 4Kn device

*eight 512-byte-block payload

> regardless of the reported limit in the IDENTIFY DEVICE data. I am
> really not sure if it's a good thing to do. Doesn't seem necessary
> anyway, especially when our block layer does not support such a large
> bio size (well, yet), so each request will end up using a payload of
> two 512-byte blocks at max anyway.
>
> Also, it's IMHO better to do it in a seperate patch (series) after the
> SCT Write Same support has entered libata's repo too, because this has
> nothing to with it but TRIM translation. In case the future ACS
> standards has clearer/better instruction on this, it will be easier
> for us to revert/follow up too.
>
> And you'll need to fix the Block Limits VPD simulation
> (ata_scsiop_inq_b0) too, so that it will advertise the Maximum Write
> Same Length dynamically as per the logical sector size, otherwise your
> effort will be completely in vain, even if our block layer is
> overhauled in the future.
>
> Please be noted that, since your haven't touched ata_scsiop_inq_b0 at
> all, the reported Maximum Write Same Length will be:
>
> On device with TRIM support:
> - 4194240 LOGICAL sector per request split / command
> -- ~=2G on non-4Kn drives
> -- ~=16G on non-4Kn drives
>
> On device without TRIM support:
> - 0 --> SD_MAX_WS10_BLOCKS (65535) per request split / command
> -- ~= 32M on non-4Kn drives
> -- ~=256M on non-4Kn drives
>
> Even if we ignore the upper limit(s) of the block layer, do we want
> such inconsistencies?
>


[PATCH v2 0/2] ALSA: compress: Fine-tuning for snd_compr_set_params()

2016-08-22 Thread SF Markus Elfring
From: Markus Elfring 
Date: Mon, 22 Aug 2016 10:27:01 +0200

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (2):
  Restructure source code around an if statement
  Use memdup_user()

 sound/core/compress_offload.c | 58 +++
 1 file changed, 26 insertions(+), 32 deletions(-)

-- 
2.9.3



Re: [PATCH 3/8] media: vidc: decoder: add video decoder files

2016-08-22 Thread Hans Verkuil
On 08/22/2016 03:13 PM, Stanimir Varbanov wrote:
> This consists of video decoder implementation plus decoder
> controls.
> 
> Signed-off-by: Stanimir Varbanov 
> ---
>  drivers/media/platform/qcom/vidc/vdec.c   | 1100 
> +
>  drivers/media/platform/qcom/vidc/vdec.h   |   27 +
>  drivers/media/platform/qcom/vidc/vdec_ctrls.c |  200 +
>  drivers/media/platform/qcom/vidc/vdec_ctrls.h |   21 +
>  4 files changed, 1348 insertions(+)
>  create mode 100644 drivers/media/platform/qcom/vidc/vdec.c
>  create mode 100644 drivers/media/platform/qcom/vidc/vdec.h
>  create mode 100644 drivers/media/platform/qcom/vidc/vdec_ctrls.c
>  create mode 100644 drivers/media/platform/qcom/vidc/vdec_ctrls.h
> 
> diff --git a/drivers/media/platform/qcom/vidc/vdec.c 
> b/drivers/media/platform/qcom/vidc/vdec.c
> new file mode 100644
> index ..a631a354742f
> --- /dev/null
> +++ b/drivers/media/platform/qcom/vidc/vdec.c
> @@ -0,0 +1,1100 @@
> +/*
> + * Copyright (c) 2012-2015, The Linux Foundation. All rights reserved.
> + * Copyright (C) 2016 Linaro Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "core.h"
> +#include "helpers.h"
> +#include "load.h"
> +#include "vdec.h"
> +#include "vdec_ctrls.h"
> +
> +#define MACROBLOCKS_PER_PIXEL(16 * 16)
> +
> +static u32 get_framesize_nv12(int plane, u32 height, u32 width)
> +{
> + u32 y_stride, uv_stride, y_plane;
> + u32 y_sclines, uv_sclines, uv_plane;
> + u32 size;
> +
> + y_stride = ALIGN(width, 128);
> + uv_stride = ALIGN(width, 128);
> + y_sclines = ALIGN(height, 32);
> + uv_sclines = ALIGN(((height + 1) >> 1), 16);
> +
> + y_plane = y_stride * y_sclines;
> + uv_plane = uv_stride * uv_sclines + SZ_4K;
> + size = y_plane + uv_plane + SZ_8K;
> +
> + return ALIGN(size, SZ_4K);
> +}
> +
> +static u32 get_framesize_compressed(u32 mbs_per_frame)
> +{
> + return ((mbs_per_frame * MACROBLOCKS_PER_PIXEL * 3 / 2) / 2) + 128;
> +}
> +
> +static const struct vidc_format vdec_formats[] = {
> + {
> + .pixfmt = V4L2_PIX_FMT_NV12,
> + .num_planes = 1,
> + .type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
> + }, {
> + .pixfmt = V4L2_PIX_FMT_MPEG4,
> + .num_planes = 1,
> + .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
> + }, {
> + .pixfmt = V4L2_PIX_FMT_MPEG2,
> + .num_planes = 1,
> + .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
> + }, {
> + .pixfmt = V4L2_PIX_FMT_H263,
> + .num_planes = 1,
> + .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
> + }, {
> + .pixfmt = V4L2_PIX_FMT_VC1_ANNEX_G,
> + .num_planes = 1,
> + .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
> + }, {
> + .pixfmt = V4L2_PIX_FMT_VC1_ANNEX_L,
> + .num_planes = 1,
> + .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
> + }, {
> + .pixfmt = V4L2_PIX_FMT_H264,
> + .num_planes = 1,
> + .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
> + }, {
> + .pixfmt = V4L2_PIX_FMT_VP8,
> + .num_planes = 1,
> + .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
> + }, {
> + .pixfmt = V4L2_PIX_FMT_XVID,
> + .num_planes = 1,
> + .type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
> + },
> +};
> +
> +static const struct vidc_format *find_format(u32 pixfmt, u32 type)
> +{
> + const struct vidc_format *fmt = vdec_formats;
> + unsigned int size = ARRAY_SIZE(vdec_formats);
> + unsigned int i;
> +
> + for (i = 0; i < size; i++) {
> + if (fmt[i].pixfmt == pixfmt)
> + break;
> + }
> +
> + if (i == size || fmt[i].type != type)
> + return NULL;
> +
> + return [i];
> +}
> +
> +static const struct vidc_format *find_format_by_index(int index, u32 type)
> +{
> + const struct vidc_format *fmt = vdec_formats;
> + unsigned int size = ARRAY_SIZE(vdec_formats);
> + int i, k = 0;
> +
> + if (index < 0 || index > size)
> + return NULL;
> +
> + for (i = 0; i < size; i++) {
> + if (fmt[i].type != type)
> + continue;
> + if (k == index)
> + break;
> + k++;
> + }
> +
> + if (i == size)
> + return NULL;
> +
> 

[RESEND PATCH 0/2] pinctrl: meson-gxbb: Export pins for PWMs

2016-08-22 Thread Neil Armstrong
Add PWM pins in the meson-gxbb pinctrl driver and export then in the GXBB dtsi.

Resent rebased on git.linaro.org/people/linus.walleij/linux-pinctrl.git branch 
devel.

Neil Armstrong (2):
  pinctrl: meson-gxbb: add pins for PWM
  ARM64: dts: meson-gxbb: Add PWM pinctrl nodes

 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 77 
 drivers/pinctrl/meson/pinctrl-meson-gxbb.c  | 78 +
 2 files changed, 155 insertions(+)

-- 
1.9.1



Re: [PATCH 1/2] ARM: dts: Add TOPEET itop core board SCP package version

2016-08-22 Thread Chanwoo Choi
Hi,

2016-08-22 17:28 GMT+09:00 Ayaka :
>
> Thank you
> 從我的 iPad 傳送
>
>> Marek Szyprowski  於 2016年8月22日 下午2:50 寫道:
>>
>> Dear Randy,
>>
>>
>>> On 2016-08-21 22:04, Randy Li wrote:
>>> The TOPEET itop is a samsung exnynos 4412 core board, which have
>>> two package versions. This patch add the support for SCP version.
>>>
>>> Currently supported are USB3503A HSIC, USB OTG, eMMC, RTC and PMIC.
>>> The future features are in the based board. Also MFC and watchdog
>>> have been enabled.
>>>
>>> Signed-off-by: Randy Li 
>>> ---
>>>  arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi | 434 
>>> 
>>>  1 file changed, 434 insertions(+)
>>>  create mode 100644 arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
>>>
>>> diff --git a/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi 
>>> b/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
>>> new file mode 100644
>>> index 000..0860ee6
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
>>> @@ -0,0 +1,434 @@
>>> +/*
>>> + * TOPEET's Exynos4412 based itop board device tree source
>>> + *
>>> + * Copyright (c) 2016 SUMOMO Computer Association
>>> + *https://www.sumomo.mobi
>>> + *Randy Li 
>>> + *
>>> + * Device tree source file for TOPEET iTop Exynos 4412 SCP package core
>>> + * board which is based on Samsung's Exynos4412 SoC.
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 as
>>> + * published by the Free Software Foundation.
>>> +*/
>>> +
>>> +#include "exynos4412.dtsi"
>>> +#include 
>>> +#include 
>>> +
>>> +/ {
>>> +memory {
>>> +reg = <0x4000 0x4000>;
>>> +};
>>> +
>>> +firmware@0203F000 {
>>> +compatible = "samsung,secure-firmware";
>>> +reg = <0x0203F000 0x1000>;
>>> +};
>>> +
>>> +display-timings {
>>> +native-mode = <>;
>>> +timing0: timing {
>>> +clock-frequency = <4750>;
>>> +hactive = <1024>;
>>> +vactive = <600>;
>>> +hfront-porch = <64>;
>>> +hback-porch = <16>;
>>> +hsync-len = <48>;
>>> +vback-porch = <64>;
>>> +vfront-porch = <16>;
>>> +vsync-len = <3>;
>>> +};
>>> +};
>>> +
>>> +fixed-rate-clocks {
>>> +xxti {
>>> +compatible = "samsung,clock-xxti";
>>> +clock-frequency = <0>;
>>> +};
>>> +
>>> +xusbxti {
>>> +compatible = "samsung,clock-xusbxti";
>>> +clock-frequency = <2400>;
>>> +};
>>> +};
>>> +
>>> +usb-hub {
>>> +compatible = "smsc,usb3503a";
>>> +reset-gpios = < 4 GPIO_ACTIVE_LOW>;
>>> +connect-gpios = < 3 GPIO_ACTIVE_HIGH>;
>>> +intn-gpios = < 3 GPIO_ACTIVE_HIGH>;
>>> +pinctrl-names = "default";
>>> +pinctrl-0 = <_reset>;
>>> +};
>>> +};
>>> +
>>> + {
>>> +cpu0-supply = <_reg>;
>>> +};
>>> +
>>> +_1 {
>>> +#address-cells = <1>;
>>> +#size-cells = <0>;
>>> +samsung,i2c-sda-delay = <100>;
>>> +samsung,i2c-max-bus-freq = <40>;
>>> +pinctrl-0 = <_bus>;
>>> +pinctrl-names = "default";
>>> +status = "okay";
>>> +
>>> +s5m8767_pmic@66 {
>>> +compatible = "samsung,s5m8767-pmic";
>>> +reg = <0x66>;
>>> +
>>> +s5m8767,pmic-buck-default-dvs-idx = <3>;
>>> +
>>> +s5m8767,pmic-buck-dvs-gpios = < 5 GPIO_ACTIVE_HIGH>,
>>> + < 6 GPIO_ACTIVE_HIGH>,
>>> + < 7 GPIO_ACTIVE_HIGH>;
>>> +
>>> +s5m8767,pmic-buck-ds-gpios = < 5 GPIO_ACTIVE_HIGH>,
>>> +< 6 GPIO_ACTIVE_HIGH>,
>>> +< 7 GPIO_ACTIVE_HIGH>;
>>> +
>>> +/* VDD_ARM */
>>> +s5m8767,pmic-buck2-dvs-voltage = <1356250>, <130>,
>>> + <1243750>, <1118750>,
>>> + <1068750>, <1012500>,
>>> + <956250>, <90>;
>>> +/* VDD_INT */
>>> +s5m8767,pmic-buck3-dvs-voltage = <100>, <100>,
>>> + <925000>, <925000>,
>>> + <887500>, <887500>,
>>> + <85>, <85>;
>>> +/* VDD_G3D */
>>> +s5m8767,pmic-buck4-dvs-voltage = <1081250>, <1081250>,
>>> + <1025000>, <95>,
>>> + <918750>, <90>,
>>> + <875000>, <831250>;
>>> +
>>> +regulators {
>>> +ldo1_reg: LDO1 {
>>> +regulator-name = "VDD_ALIVE";
>>> +regulator-min-microvolt = <110>;
>>> +regulator-max-microvolt = <110>;
>>> +regulator-always-on;
>>> +regulator-boot-on;
>>> +op_mode = <1>; /* Normal Mode */
>>> +   

Re: [PATCH] CodingStyle: add some more error handling guidelines

2016-08-22 Thread Michael S. Tsirkin
On Mon, Aug 22, 2016 at 08:16:17AM -0600, Jonathan Corbet wrote:
> On Mon, 22 Aug 2016 16:57:46 +0300
> "Michael S. Tsirkin"  wrote:
> 
> > commit commit ea04036032edda6f771c1381d03832d2ed0f6c31 ("CodingStyle:
> > add some more error handling guidelines") suggests never naming goto
> > labels after the goto location - that is the error that is handled.
> > 
> > But it's actually pretty common and IMHO it's a reasonable style
> > provided each error gets its own label, and each label comes after the
> > matching cleanup:
> > 
> > foo = kmalloc(SIZE, GFP_KERNEL);
> > if (!foo)
> > goto err_foo;
> > 
> > foo->bar = kmalloc(SIZE, GFP_KERNEL);
> > if (!foo->bar)
> > goto err_bar;
> > ...
> > 
> > kfree(foo->bar);
> > err_bar:
> > 
> > kfree(foo);
> > err_foo:
> > 
> > return ret;
> 
> Hmm, I've never encountered that style, but I've never gone looking for it
> either.  I find it a little confusing to detach a label from the code it
> will run.  Is this really something we want to encourage?  I kind of think
> this one needs some acks before I can consider it.

The point is really naming label for the part of init that failed
(and so needs to be skipped), rather than the part that will run.
Adding empty lines is not the point - does it look better like this?


foo = kmalloc(SIZE, GFP_KERNEL);
if (!foo)
goto err_foo;

foo->bar = kmalloc(SIZE, GFP_KERNEL);
if (!foo->bar)
goto err_bar;
...

kfree(foo->bar);
err_bar:
kfree(foo);
err_foo:
return ret;




I don't know whether there are examples outside code that
I wrote myself, e.g. in vhost_dev_set_owner. I find
that it's helpful since it avoids churn if more
allocations are added.


> > diff --git a/tools/virtio/ringtest/main.h b/tools/virtio/ringtest/main.h
> > index 16917ac..e4d76c3 100644
> > --- a/tools/virtio/ringtest/main.h
> > +++ b/tools/virtio/ringtest/main.h
> > @@ -80,7 +80,9 @@ extern unsigned ring_size;
> >  
> >  /* Is there a portable way to do this? */
> >  #if defined(__x86_64__) || defined(__i386__)
> > -#define cpu_relax() asm ("rep; nop" ::: "memory")
> > +#define cpu_relax() do { \
> > +   asm ("rep; nop" ::: "memory"); \
> > +} while (0)
> >  #else
> >  #define cpu_relax() assert(0)
> >  #endif
> 
> This hunk seems somehow unrelated, either that or I really haven't
> understood the proposal :)
> 
> jon

Ouch, that's unrelated, sorry.

-- 
MST


Re: [PATCH v6 3/4] SCT Write Same / DSM Trim

2016-08-22 Thread Shaun Tancheff
On Mon, Aug 22, 2016 at 3:33 AM, Tom Yan  wrote:
> On 22 August 2016 at 08:31, Tom Yan  wrote:
>> As mentioned before, as of the latest draft of ACS-4, nothing about a
>> larger payload size is mentioned. Conservatively speaking, it sort of
>
> *payload block size
>
>> means that we are allowing four 512-byte block payload on 4Kn device
>
> *eight 512-byte-block payload
>
>> regardless of the reported limit in the IDENTIFY DEVICE data. I am
>> really not sure if it's a good thing to do. Doesn't seem necessary
>> anyway, especially when our block layer does not support such a large
>> bio size (well, yet), so each request will end up using a payload of
>> two 512-byte blocks at max anyway.
>>
>> Also, it's IMHO better to do it in a seperate patch (series) after the
>> SCT Write Same support has entered libata's repo too, because this has
>> nothing to with it but TRIM translation. In case the future ACS
>> standards has clearer/better instruction on this, it will be easier
>> for us to revert/follow up too.

I am certainly fine with dropping this patch as it is not critical to
the reset of the series.

Nothing will break if we stick with the 512 byte fixed limit. This
is at most a prep patch for handling increased limits should
they be reported.

All it really is doing is acknowledging that any write same
must have a payload of sector_size which can be something
larger than 512 bytes.

>> And you'll need to fix the Block Limits VPD simulation
>> (ata_scsiop_inq_b0) too, so that it will advertise the Maximum Write
>> Same Length dynamically as per the logical sector size, otherwise your
>> effort will be completely in vain, even if our block layer is
>> overhauled in the future.

Martin had earlier suggested that I leave the write same defaults
as is due to concerns with misbehaving hardware.

I think your patch adjusting the reported limits is reasonable
enough. It seems to me we should have the hardware
report it's actual limits, for example, report what the spec
allows.

Of course there are lots of reasons to limit the absolute
maximums.

So in this case we are just enabling the limit to be
increased but not changing the current black-listing
that distrusts DSM Trim. Once we have 4Kn devices
to test then we can start white-listing and see if there
is an overall increase in performance.

>> Please be noted that, since your haven't touched ata_scsiop_inq_b0 at
>> all, the reported Maximum Write Same Length will be:
>>
>> On device with TRIM support:
>> - 4194240 LOGICAL sector per request split / command
>> -- ~=2G on non-4Kn drives
>> -- ~=16G on non-4Kn drives
>>
>> On device without TRIM support:
>> - 0 --> SD_MAX_WS10_BLOCKS (65535) per request split / command
>> -- ~= 32M on non-4Kn drives
>> -- ~=256M on non-4Kn drives
>>
>> Even if we ignore the upper limit(s) of the block layer, do we want
>> such inconsistencies?

Hmm. Overall I think it is still okay if a bit confusing.
It is possible that for devices which support SCT Write Same
and DSM TRIM will still Trim faster than they can Write Same,
However the internal implementation is opaque so I can't
say if Write Same is often implemented in terms of TRIM
or not. I mean that's how _I_ do it [Write 1 block and map
N blocks to it], But not every FTL will have come to the
same conclusion.

I also suspect that given the choice for most use casess that
TRIM is preferred over WS when TRIM supports returning
zeroed blocks.

-- 
Shaun Tancheff


Re: [RFC] Using C99 stdint vs kernel __uX types in kernel drmUAPI (was Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from ")

2016-08-22 Thread Emil Velikov
On 22 August 2016 at 15:38, Daniel Vetter  wrote:
> On Mon, Aug 22, 2016 at 12:38 PM, Rob Clark  wrote:
>>> That said, _note_ that some applications are built with -C89 -pedantic
>>> [1] which means that using stdint.h may or may not work as expected.
>>> So we'll want a __STDC_VESION__ check + #error in case of pre-C99 ?
>>> If the affected programs are proprietary ones we should be safe,
>>> otherwise we want to update them ~alongside the transition.
>>
>> naw, at least for msm_drm.h, just don't build libdrm_freedreno w/
>> -C89.. problem solved!
>
> Yeah, I think sprinkling an
>
> #ifdef __kernel___
> #include 
> #else
> #include 
> #endif
>
Guess i was too vague :-]

I was thinking about the following cases:
 - using old/incomplete stdint.h - thus the __STDC_VESION__ check.
 - building non-libdrm software - for libdrm we've (implicitly and
explicitly) required C99 for a long time.

> at the opt of all drm uapi headers should be good enough. Or at least
> those which opt to choose stdints. Since our userspace is very
> limited, and our headers will never leak to general applications we
> can just require c99, at least for driver headers. For kms/general drm
> uapi that might not be the best idea.
Won't doing so bring more confusion to an already convoluted topic ?
If we opt for it, let's have a juicy comment that clarifies things.

-Emil


Re: [PATCH 1/2] PCI/IOV: Add function to allow Function Dependency Link override.

2016-08-22 Thread Bjorn Helgaas
Hi David & Omer,

On Fri, Aug 19, 2016 at 03:32:12PM -0700, Omer Khaliq wrote:
> From: David Daney 
> 
> Some hardware presents an incorrect SR-IOV Function Dependency Link,
> add a function to allow this to be overridden in the PF driver for
> such devices.
> 
> Signed-off-by: David Daney 
> Signed-off-by: Omer Khaliq 
> ---
>  drivers/pci/iov.c   | 14 ++
>  include/linux/pci.h |  1 +
>  2 files changed, 15 insertions(+)
> 
> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
> index 2194b44..81f0672 100644
> --- a/drivers/pci/iov.c
> +++ b/drivers/pci/iov.c
> @@ -640,6 +640,20 @@ int pci_enable_sriov(struct pci_dev *dev, int nr_virtfn)
>  EXPORT_SYMBOL_GPL(pci_enable_sriov);
>  
>  /**
> + * pci_sriov_fdl_override - fix incorrect Function Dependency Link
> + * @dev: the PCI device
> + * @fdl: the corrected Function Dependency Link value
> + *
> + * For hardware presenting an incorrect Function Dependency Link in
> + * the SR-IOV Extended Capability, allow a driver to override it.
> + */
> +void pci_sriov_fdl_override(struct pci_dev *dev, u8 fdl)
> +{
> + dev->sriov->link = fdl;
> +}
> +EXPORT_SYMBOL_GPL(pci_sriov_fdl_override);

We usually use quirks to work around problems in config space.  That's
a nice mechanism because we don't have to add new PCI core interfaces
and it makes it clear that we're working around a hardware problem.

Can you use a quirk here?  We allocate dev->sriov in the
pci_init_capabilities() path, so it looks like a pci_fixup_final quirk
should work.

> +
> +/**
>   * pci_disable_sriov - disable the SR-IOV capability
>   * @dev: the PCI device
>   */
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 2599a98..da8a5b3 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1823,6 +1823,7 @@ int pci_num_vf(struct pci_dev *dev);
>  int pci_vfs_assigned(struct pci_dev *dev);
>  int pci_sriov_set_totalvfs(struct pci_dev *dev, u16 numvfs);
>  int pci_sriov_get_totalvfs(struct pci_dev *dev);
> +void pci_sriov_fdl_override(struct pci_dev *dev, u8 fdl);
>  resource_size_t pci_iov_resource_size(struct pci_dev *dev, int resno);
>  #else
>  static inline int pci_iov_virtfn_bus(struct pci_dev *dev, int id)
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] i2c: pca953x: fix a lockdep warning

2016-08-22 Thread Linus Walleij
On Mon, Aug 22, 2016 at 4:15 PM, Bartosz Golaszewski
 wrote:
> 2016-08-22 16:06 GMT+02:00 Linus Walleij :
>> On Mon, Aug 22, 2016 at 3:29 PM, Bartosz Golaszewski
>>  wrote:
>>
>> The $SUBJECT of this patch should be something beginning with
>> gpio: atleast.
>>
>
> Oops, it was supposed to be gpio, but I was working on i2c stuff and
> mixed it. I'll fix that in v2 after getting some reviews.

OK! Pls include the people I added on the To: line when you repost.

Yours,
Linus Walleij


  1   2   3   4   5   6   7   8   9   10   >