linux-next: manual merge of the dma-buf tree with the staging tree

[Stephen Rothwell]

Hi Sumit,

Today's linux-next merge of the dma-buf tree got a conflict in
drivers/staging/android/sync.c between commit 10f62861b4a2 ("staging:
android: fix missing a blank line after declarations") from the staging
tree and commit 85958aff6184 ("android: convert sync to fence api, v5")
from the dma-buf tree.

I fixed it up (I just used the dma-buf tree version of conflicting
sections) and can carry the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

Re: [PATCH 1/2] platform: x86: dell-smo8800: Dell Latitude freefall driver (ACPI SMO8800/SMO8810)

[Valdis . Kletnieks]

On Sat, 03 May 2014 12:47:56 +0200, Pali Rohár said:
> This acpi driver provide supports for freefall sensors SMO8800/SMO8810 which
> can be found on Dell Latitude laptops. Driver register /dev/freefall misc
> device which has same interface as driver hp_accel freefall driver. So any
> existing applications for HP freefall sensor /dev/freefall will work for with
> this new driver for Dell Latitude laptops too.

So just for grins, I tossed this patchset on top of next-20140519, and
it actually works on my Dell Latitude E6530. Tested with a controlled
drop of 3-4 inches, and I get the distinctive sound of a head park, and
the following in /var/log/messages:

May 20 02:46:22 turing-police kernel: [18839.158926] smo8800 SMO8810:00: 
detected free fall
May 20 02:46:22 turing-police FREE FALL[1337]: Parked /dev/sda disk head
May 20 02:46:24 turing-police FREE FALL[1337]: Unparked /dev/sda disk head

I did a quick read-through of the code, looks OK.  checkpatch complains about
missing blank lines after declarations in 3-4 places. Sparse and gcc have no
complaints. We've certainly merged much uglier code.  And it certainly makes
the world a better place for us Dell users.

So it's OK by me if Pali adds this to the signoffs after fixing the
checkpatch and the one serious nit below

Tested-By: Valdis Kletnieks 
Acked-By: Valdis Kletnieks 

One nit:

> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -127,6 +127,16 @@ config DELL_WMI_AIO
> To compile this driver as a module, choose M here: the module will
> be called dell-wmi-aio.
>  
> +config DELL_SMO8800
> + tristate "Dell Latitude freefall driver (ACPI SMO8800/SMO8810)"
> + depends ON ACPI

Lowercase ON.  Not sure how this escaped, Kbuild barfs on it.



pgppvsD60Q5Iv.pgp
Description: PGP signature

Re: [PATCH 2/5] dma-mapping: Add devm_ interface for dma_map_single()

[Eli Billauer]

Hello, Tejun.

On 19/05/14 23:17, Tejun Heo wrote:


What can't it just do the following?

if (dma_mapping_error(dev, dma_handle)) {
devres_free(dr);
return dma_handle;
}

The caller would have to invoke dma_mapping_error() again but is that
a problem?
   
That seems OK to me, but the problem I'm concerned with is this: In 
devm_get_free_pages() it says


devres = devres_alloc(devm_pages_release,
  sizeof(struct pages_devres), GFP_KERNEL);
if (unlikely(!devres)) {
free_pages(addr, order);
return 0;
}

What should I put instead of this "return 0" to conform with the current 
API?


And to make things even worse, on some architectures, 
dma_mapping_error() always returns success, regardless of dma_handle. So 
if we stick to the current API, the caller of devm_get_free_pages() will 
never know it failed on these architectures.


So my conclusion was that the caller must be aware that if 
devm_get_free_pages() returns zero it's an error, regardless of 
dma_mapping_error(). That breaks the API. Once it's broken, why not 
return zero on all possible errors?


Maybe I didn't understand what you suggested.

Regards,
   Eli



Thanks.

   



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] arm: dma-mapping: fallback allocation for cma failure

[Gioh Kim]

That case, device-specific coherent memory allocation, is handled at 
dma_alloc_coherent in arm_dma_alloc.
__dma_alloc handles only general coherent memory allocation.

I'm sorry missing mention about it.


2014-05-20 오후 3:52, Joonsoo Kim 쓴 글:

On Tue, May 20, 2014 at 02:57:47PM +0900, Gioh Kim wrote:


Thanks for your advise, Michal Nazarewicz.

Having discuss with Joonsoo, I'm adding fallback allocation after 
__alloc_from_contiguous().
The fallback allocation works if CMA kernel options is turned on but CMA size 
is zero.


Hello, Gioh.

I also mentioned the case where devices have their specific cma_area.
It means that this device needs memory with some contraint.
Although I'm not familiar with DMA infrastructure, I think that
we should handle this case.

How about below patch?

>8
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 6b00be1..4023434 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -379,7 +379,7 @@ static int __init atomic_pool_init(void)
unsigned long *bitmap;
struct page *page;
struct page **pages;
-   void *ptr;
+   void *ptr = NULL;
int bitmap_size = BITS_TO_LONGS(nr_pages) * sizeof(long);

bitmap = kzalloc(bitmap_size, GFP_KERNEL);
@@ -393,7 +393,8 @@ static int __init atomic_pool_init(void)
if (IS_ENABLED(CONFIG_DMA_CMA))
ptr = __alloc_from_contiguous(NULL, pool->size, prot, &page,
  atomic_pool_init);
-   else
+
+   if (!ptr)
ptr = __alloc_remap_buffer(NULL, pool->size, gfp, prot, &page,
   atomic_pool_init);
if (ptr) {
@@ -701,10 +702,22 @@ static void *__dma_alloc(struct device *dev, size_t size, 
dma_addr_t *handle,
addr = __alloc_simple_buffer(dev, size, gfp, &page);
else if (!(gfp & __GFP_WAIT))
addr = __alloc_from_pool(size, &page);
-   else if (!IS_ENABLED(CONFIG_DMA_CMA))
-   addr = __alloc_remap_buffer(dev, size, gfp, prot, &page, 
caller);
-   else
-   addr = __alloc_from_contiguous(dev, size, prot, &page, caller);
+   else {
+   if (IS_ENABLED(CONFIG_DMA_CMA)) {
+   addr = __alloc_from_contiguous(dev, size, prot,
+   &page, caller);
+   /*
+* Device specific cma_area means that
+* this device needs memory with some contraint.
+* So, we can't fall through general remap allocation.
+*/
+   if (!addr && dev && dev->cma_area)
+   return NULL;
+   }
+
+   addr = __alloc_remap_buffer(dev, size, gfp, prot,
+   &page, caller);
+   }

if (addr)
*handle = pfn_to_dma(dev, page_to_pfn(page));


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the dma-buf tree with the staging tree

[Greg KH]

On Tue, May 20, 2014 at 05:00:31PM +1000, Stephen Rothwell wrote:
> Hi Sumit,
> 
> Today's linux-next merge of the dma-buf tree got a conflict in
> drivers/staging/android/sync.c between commit 10f62861b4a2 ("staging:
> android: fix missing a blank line after declarations") from the staging
> tree and commit 85958aff6184 ("android: convert sync to fence api, v5")
> from the dma-buf tree.
> 
> I fixed it up (I just used the dma-buf tree version of conflicting
> sections) and can carry the fix as necessary (no action is required).

Sounds good, thanks.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver

[Lee Jones]

> > > Not my call to make; depends on the mfd maintainer. I would not accept 
> > > it, as I see it
> > > as unnecessary, adding complexity, and pointless. Sure, you can always 
> > > find examples
> > > for everything somewhere in the kernel, but that doesn't make it better.
> > 
> > I'm inclined to agree with Guenter, this patch is just noise.
> 
> Ok no problem, i will fix it and resend the patch.
> For now I know it for the future :-)
> 
> Any other comments about the patch series?

If you submit a v2, I'll re-review the bits you leave in.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

I/O error, dev mmcblk0

[Christian Gmeiner]

Hi all.

I updated from a 3.14 kernel to 3.15-rc5 kernel and have from time to
time some problems.
With the 3.14 kernel kernel I have never seen this problem - I am
using this device to do some
vivante gpu driver development.

debian@arm:~$ dmesg (I removed drm.debug messages)
[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.15.0-rc5+ (debian@arm) (gcc version
4.6.3 (Debian 4.6.3-14) ) #6 SMP Thu May 15 20:05:36 UTC 2014
[0.00] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[0.00] Machine model: Freescale i.MX6 Quad SABRE Lite Board
[0.00] cma: CMA: reserved 16 MiB at 3e80
[0.00] Memory policy: Data cache writealloc
[0.00] On node 0 totalpages: 262144
[0.00] free_area_init_node: node 0, pgdat c0812d40,
node_mem_map edff1000
[0.00]   Normal zone: 1520 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 194560 pages, LIFO batch:31
[0.00]   HighMem zone: 528 pages used for memmap
[0.00]   HighMem zone: 67584 pages, LIFO batch:15
[0.00] PERCPU: Embedded 9 pages/cpu @edfaf000 s13760 r8192 d14912 u36864
[0.00] pcpu-alloc: s13760 r8192 d14912 u36864 alloc=9*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[0.00] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 260624
[0.00] Kernel command line: console=ttymxc1,115200n8
console=tty0 vivante.reglog=1 loglevel=7 drm.debug=7
root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc video=
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] allocated 2097152 bytes of page_cgroup
[0.00] please try 'cgroup_disable=memory' option if you don't
want memory cgroups
[0.00] Memory: 1011580K/1048576K available (5506K kernel code,
325K rwdata, 2072K rodata, 341K init, 970K bss, 36996K reserved,
270336K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
[0.00] vmalloc : 0xf000 - 0xff00   ( 240 MB)
[0.00] lowmem  : 0xc000 - 0xef80   ( 760 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0008000 - 0xc076ed1c   (7580 kB)
[0.00]   .init : 0xc076f000 - 0xc07c45c0   ( 342 kB)
[0.00]   .data : 0xc07c6000 - 0xc0817578   ( 326 kB)
[0.00].bss : 0xc0817578 - 0xc0909f28   ( 971 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[0.00] Hierarchical RCU implementation.
[0.00]  RCU dyntick-idle grace-period acceleration is enabled.
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] L310 cache controller enabled
[0.00] l2x0: 16 ways, CACHE_ID 0x41c7, AUX_CTRL
0x3207, Cache size: 1024 kB
[0.00] Switching to timer-based delay loop
[0.07] sched_clock: 32 bits at 66MHz, resolution 15ns, wraps
every 65075262448ns
[0.000642] Console: colour dummy device 80x30
[0.001015] console [tty0] enabled
[0.001041] Calibrating delay loop (skipped), value calculated
using timer frequency.. 132.00 BogoMIPS (lpj=66)
[0.001071] pid_max: default: 32768 minimum: 301
[0.001152] Security Framework initialized
[0.001172] Yama: becoming mindful.
[0.001327] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.001349] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[0.001969] Initializing cgroup subsys memory
[0.002000] Initializing cgroup subsys devices
[0.002019] Initializing cgroup subsys freezer
[0.002035] Initializing cgroup subsys net_cls
[0.002049] Initializing cgroup subsys blkio
[0.002064] Initializing cgroup subsys perf_event
[0.002123] CPU: Testing write buffer coherency: ok
[0.002419] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
[0.002487] Setting up static identity map for 0x10531df0 - 0x10531e48
[0.004313] CPU1: Booted secondary processor
[0.004337] CPU1: thread -1, cpu 1, socket 0, mpidr 8001
[0.005169] CPU2: Booted secondary processor
[0.005194] CPU2: thread -1, cpu 2, socket 0, mpidr 8002
[0.006049] CPU3: Booted secondary processor
[0.006074] CPU3: thread -1, cpu 3, socket 0, mpidr 8003
[0.006181] Brought up 4 CPUs
[0.006253] SMP: Total of 4 processors activated.
[0.006268] CPU: All CPU(s) started in SVC m

linux-next: build failure after merge of the dma-buf tree

[Stephen Rothwell]

Hi Sumit,

After merging the dma-buf tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/gpu/drm/tegra/gem.c: In function 'tegra_gem_prime_export':
drivers/gpu/drm/tegra/gem.c:423:15: error: macro "dma_buf_export" requires 5 
arguments, but only 4 given
drivers/gpu/drm/tegra/gem.c:422:9: error: 'dma_buf_export' undeclared (first 
use in this function)

Caused by commit 8dfb1f0f8103 ("dma-buf: use reservation objects").
Grep is your friend ...

I have use the dma-buf tree from next-20140519 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

Re: [PATCH V4 0/2] mm: FAULT_AROUND_ORDER patchset performance data for powerpc

[Rusty Russell]

"Kirill A. Shutemov"  writes:
> Andrew Morton wrote:
>> On Mon, 19 May 2014 16:23:07 -0700 (PDT) Hugh Dickins  
>> wrote:
>> 
>> > Shouldn't FAULT_AROUND_ORDER and fault_around_order be changed to be
>> > the order of the fault-around size in bytes, and fault_around_pages()
>> > use 1UL << (fault_around_order - PAGE_SHIFT)
>> 
>> Yes.  And shame on me for missing it (this time!) at review.
>> 
>> There's still time to fix this.  Patches, please.
>
> Here it is. Made at 3.30 AM, build tested only.

Prefer on top of Maddy's patch which makes it always a variable, rather
than CONFIG_DEBUG_FS.  It's got enough hair as it is.

Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [STLinux Kernel] [PATCH 3/4] ARM: DT: STi: Add DT node for MiPHY365x

[Maxime Coquelin]

On 05/19/2014 05:51 PM, Lee Jones wrote:

The MiPHY365x is a Generic PHY which can serve various SATA or PCIe
devices. It has 2 ports which it can use for either; both SATA, both
PCIe or one of each in any configuration.

Cc: Srinivas Kandagatla 
Acked-by: Mark Rutland 
Acked-by: Alexandre Torgue 
Signed-off-by: Lee Jones 
---
  arch/arm/boot/dts/stih416-b2020-revE.dts | 22 ++
  arch/arm/boot/dts/stih416-b2020.dts  |  6 ++
  arch/arm/boot/dts/stih416.dtsi   | 14 ++
  3 files changed, 42 insertions(+)
  create mode 100644 arch/arm/boot/dts/stih416-b2020-revE.dts

diff --git a/arch/arm/boot/dts/stih416-b2020-revE.dts 
b/arch/arm/boot/dts/stih416-b2020-revE.dts
new file mode 100644
index 000..23fdaf7
--- /dev/null
+++ b/arch/arm/boot/dts/stih416-b2020-revE.dts
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2014 STMicroelectronics Limited.
+ * Author: Lee Jones 
+ *
+ * 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
+ * publishhed by the Free Software Foundation.
+ */
+/dts-v1/;
+#include "stih416.dtsi"
+#include "stih41x-b2020.dtsi"
+/ {
+model = "STiH416 B2020 REV-E";
+   compatible = "st,stih416-b2020", "st,stih416";
+
+   soc {
+   miphy365x_phy: miphy365x@fe382000 {
+   st,pcie-tx-pol-inv;
+   st,sata-gen = <3>;
+   };
+   };
+};

Shouldn't this new board being added in a separate patch?


I certainly can do that, but I don't think that it's necessary?


I think it is, as you introduce a new board.
Moreover, the miphy description being the same as in stih416-b2020.dts, 
so I don't understand why you introduce this board for this feature.






diff --git a/arch/arm/boot/dts/stih416-b2020.dts 
b/arch/arm/boot/dts/stih416-b2020.dts
index 276f28d..172f222 100644
--- a/arch/arm/boot/dts/stih416-b2020.dts
+++ b/arch/arm/boot/dts/stih416-b2020.dts
@@ -13,4 +13,10 @@
model = "STiH416 B2020";
compatible = "st,stih416", "st,stih416-b2020";

+   soc {
+   miphy365x_phy: miphy365x@fe382000 {
+   st,pcie-tx-pol-inv;
+   st,sata-gen = <3>;
+   };
+   };
  };

...



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm/vmscan: Do not block forever at shrink_inactive_list().

[Christoph Hellwig]

On Mon, May 19, 2014 at 10:59:15PM -0700, Andrew Morton wrote:
> So current_is_kswapd() returns true for a thread which is not kswapd. 
> That's a bit smelly.
> 
> Should this thread really be incrementing KSWAPD_INODESTEAL instead of
> PGINODESTEAL, for example?  current_is_kswapd() does a range of things,
> only one(?) of which you actually want.

Actually we want all of them. The allocation workqueue is a workaround
for the incredible stack usage in the Linux I/O path.  If it is called
by kswapd it should act as if it were kswapd for all purposes.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 6/6] ARM: dts: STiH407: Add B2120 board support

[Lee Jones]

> > B2120 HDK is the reference board for STiH407 SoC.
> > It has the following characteristics:
> >  - 1GB DDR3
> >  - 8GB eMMC / SD-Card slot
> >  - 32MB NOR Flash
> >  - 1 x Gbit Ethernet
> >  - 1 x USB 3.0 port
> >  - 1 x Mini-PCIe
> >  - 1 x SATA
> >  - 1 x HDMI output
> >  - 1 x HDMI input
> >  - 1 x SPDIF
> >
> > This patch only introduces basic functionnalities, such as I2C and UART.
> >
> > Acked-by: Giuseppe Cavallaro 
> > Acked-by: Lee Jones 
> > Signed-off-by: Giuseppe Cavallaro 
> > Signed-off-by: Maxime Coquelin 
> > ---
> >  arch/arm/boot/dts/Makefile  |  3 +-
> >  arch/arm/boot/dts/stih407-b2120.dts | 78 
> > +
> >  2 files changed, 80 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/arm/boot/dts/stih407-b2120.dts

[...]

> > +/ {
> > +   model = "STiH407 B2120";
> > +   compatible = "st,stih407", "st,stih407-b2120";
> 
> This should go from specific to generic, so the order needs to be the other 
> way.

I did have a patch-set that changed all of these.  Wonder where that went!

[...]

> > +   soc {
> > +   sbc_serial0: serial@953 {
> > +   status = "okay";
> > +   };
> 
> You might want to consider reference-based syntax here instead, so you
> don't have to mimic the hierarchy. That'd be (at the root level of the
> file, below this secion:
> 
> &sbc_serial0: {
> status = "okay";
> };

I'm personally not keen on this scheme.  It's sometimes helpful to know
the hierarchy and I don't think it's a large overhead to format the
subordinate DTS files in this way.

Please consider not enforcing this.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 6/6] ARM: dts: STiH407: Add B2120 board support

[Olof Johansson]

On Tue, May 20, 2014 at 12:20 AM, Lee Jones  wrote:
>> > B2120 HDK is the reference board for STiH407 SoC.
>> > It has the following characteristics:
>> >  - 1GB DDR3
>> >  - 8GB eMMC / SD-Card slot
>> >  - 32MB NOR Flash
>> >  - 1 x Gbit Ethernet
>> >  - 1 x USB 3.0 port
>> >  - 1 x Mini-PCIe
>> >  - 1 x SATA
>> >  - 1 x HDMI output
>> >  - 1 x HDMI input
>> >  - 1 x SPDIF
>> >
>> > This patch only introduces basic functionnalities, such as I2C and UART.
>> >
>> > Acked-by: Giuseppe Cavallaro 
>> > Acked-by: Lee Jones 
>> > Signed-off-by: Giuseppe Cavallaro 
>> > Signed-off-by: Maxime Coquelin 
>> > ---
>> >  arch/arm/boot/dts/Makefile  |  3 +-
>> >  arch/arm/boot/dts/stih407-b2120.dts | 78 
>> > +
>> >  2 files changed, 80 insertions(+), 1 deletion(-)
>> >  create mode 100644 arch/arm/boot/dts/stih407-b2120.dts
>
> [...]
>
>> > +/ {
>> > +   model = "STiH407 B2120";
>> > +   compatible = "st,stih407", "st,stih407-b2120";
>>
>> This should go from specific to generic, so the order needs to be the other 
>> way.
>
> I did have a patch-set that changed all of these.  Wonder where that went!

Cool.

>
> [...]
>
>> > +   soc {
>> > +   sbc_serial0: serial@953 {
>> > +   status = "okay";
>> > +   };
>>
>> You might want to consider reference-based syntax here instead, so you
>> don't have to mimic the hierarchy. That'd be (at the root level of the
>> file, below this secion:
>>
>> &sbc_serial0: {
>> status = "okay";
>> };
>
> I'm personally not keen on this scheme.  It's sometimes helpful to know
> the hierarchy and I don't think it's a large overhead to format the
> subordinate DTS files in this way.
>
> Please consider not enforcing this.

Definitely not enforcing it, and I didn't use to like it either but it
has some real upsides.

In particular, it saves a lot of grief when you're changing something
like the unit-id of a node in .dtsi and forget to do the same update
in the dts.



-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V4 2/2] powerpc/pseries: init fault_around_order for pseries

[Andrew Morton]

On Thu,  8 May 2014 14:58:16 +0530 Madhavan Srinivasan 
 wrote:

> --- a/arch/powerpc/platforms/pseries/pseries.h
> +++ b/arch/powerpc/platforms/pseries/pseries.h
> @@ -17,6 +17,8 @@ struct device_node;
>  extern void request_event_sources_irqs(struct device_node *np,
>  irq_handler_t handler, const char *name);
>  
> +extern unsigned int fault_around_order;

This isn't an appropriate header file for exporting something from core
mm - what happens if arch/mn10300 wants it?.

I guess include/linux/mm.h is the place.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V4 0/2] mm: FAULT_AROUND_ORDER patchset performance data for powerpc

[Andrew Morton]

On Tue, 20 May 2014 15:52:07 +0930 Rusty Russell  wrote:

> "Kirill A. Shutemov"  writes:
> > Andrew Morton wrote:
> >> On Mon, 19 May 2014 16:23:07 -0700 (PDT) Hugh Dickins  
> >> wrote:
> >> 
> >> > Shouldn't FAULT_AROUND_ORDER and fault_around_order be changed to be
> >> > the order of the fault-around size in bytes, and fault_around_pages()
> >> > use 1UL << (fault_around_order - PAGE_SHIFT)
> >> 
> >> Yes.  And shame on me for missing it (this time!) at review.
> >> 
> >> There's still time to fix this.  Patches, please.
> >
> > Here it is. Made at 3.30 AM, build tested only.
> 
> Prefer on top of Maddy's patch which makes it always a variable, rather
> than CONFIG_DEBUG_FS.  It's got enough hair as it is.
> 

We're at 3.15-rc5 and this interface should be finalised for 3.16.  So
Kirrill's patch is pretty urgent and should come first.

Well.  It's only a debugfs interface at this stage so we are allowed to
change it later, but it's better not to.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 2/5] clk: Introduce 'clk_round_rate_nearest()'

[Uwe Kleine-König]

Hi Sören,

On Mon, May 19, 2014 at 09:41:32AM -0700, Sören Brinkmann wrote:
> On Mon, 2014-05-19 at 06:19PM +0200, Uwe Kleine-König wrote:
> > Hi Sören,
> > 
> > On Sun, May 18, 2014 at 05:51:05PM -0700, Sören Brinkmann wrote:
> > > --8<-8<-8<-8<---
> > > From: Soren Brinkmann 
> > > Date: Tue, 2 Apr 2013 10:08:13 -0700
> > > Subject: [PATCH] clk: Introduce 'clk_round_rate_nearest()'
> > > 
> > > Introduce a new API function to round a rate to the closest possible
> > > rate the HW clock can generate.
> > > In contrast to 'clk_round_rate()' which works similar, but always returns
> > > a frequency <= its input rate.
> > > 
> > > Cc: Uwe Kleine-König 
> > > Signed-off-by: Soren Brinkmann 
> > > ---
> > >  drivers/clk/clk.c   | 43 +--
> > >  include/linux/clk.h | 14 --
> > >  2 files changed, 53 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > > index dff0373f53c1..faf24d0569df 100644
> > > --- a/drivers/clk/clk.c
> > > +++ b/drivers/clk/clk.c
> > > @@ -1011,8 +1011,9 @@ unsigned long __clk_round_rate(struct clk *clk, 
> > > unsigned long rate)
> > >   * @rate: the rate which is to be rounded
> > >   *
> > >   * Takes in a rate as input and rounds it to a rate that the clk can 
> > > actually
> > > - * use which is then returned.  If clk doesn't support round_rate 
> > > operation
> > > - * then the parent rate is returned.
> > > + * use and does not exceed the requested frequency, which is then 
> > > returned.
> > > + * If clk doesn't support round_rate operation then the parent rate
> > > + * is returned.
> > >   */
> > >  long clk_round_rate(struct clk *clk, unsigned long rate)
> > >  {
> > > @@ -1027,6 +1028,44 @@ long clk_round_rate(struct clk *clk, unsigned long 
> > > rate)
> > >  EXPORT_SYMBOL_GPL(clk_round_rate);
> > >  
> > >  /**
> > > + * clk_round_rate_nearest - round the given rate for a clk
> > > + * @clk: the clk for which we are rounding a rate
> > > + * @rate: the rate which is to be rounded
> > > + *
> > > + * Takes in a rate as input and rounds it to the closest rate that the 
> > > clk
> > > + * can actually use which is then returned. If clk doesn't support
> > > + * round_rate operation then the parent rate is returned.
> > > + */
> > > +long clk_round_rate_nearest(struct clk *clk, unsigned long rate)
> > Why does this function doesn't return an unsigned long when it never
> > returns a negative value? Ditto for clk_round_rate?
> 
> I matched the definition of clk_round_rate(). But you're probably right,
> it may be the right thing to change clk_round_rate to return an
> unsigned, but with that being exposed API it would be a risky change.
Russell, what do you think?

> > > +{
> > > + unsigned long lower, upper, cur, lower_last, upper_last;
> > > +
> > > + lower = clk_round_rate(clk, rate);
> > > + if (lower >= rate)
> > > + return lower;
> > Is the >-case worth a warning?
> 
> No, it's correct behavior. If you request a rate that is way lower than what 
> the
> clock can generate, returning something larger is perfectly valid, IMHO.
> Which reveals one problem in this whole discussion. The API does not
> require clk_round_rate() to round down. It is actually an implementation
> choice that had been made for clk-divider.
I'm sure it's more than an implementation choice for clk-divider. But I
don't find any respective documentation (but I didn't try hard).


> > > +
> > > + upper = clk_round_rate(clk, rate + rate - lower);
> > This was parenthesized in my original patch on purpose. If rate is big
> > 
> > rate + rate - lower
> > 
> > might overflow when
> > 
> > rate + (rate - lower)
> > 
> > doesn't. Thinking again, there is no real problem, because this is
> > unsigned arithmetic. To be save we still need to check if rate + (rate -
> > lower) overflows.
> 
> Good point. I'll add the parentheses.
> 
> > 
> > > + if (upper == lower)
> > if (upper <= rate) is the better check here. (= would be a bug.)
> 
> I don't understand. Passing rate + x to round rate can never return
> something below 'lower'. Only something in the range [lower,lower+x].
> So, if upper == lower we found our closest frequency and return it.
> Otherwise we have to iterate over [lower+1,upper]. Or what did I miss?
Assuming a correct implementation of clk_round_rate there is no
difference. Checking for <= rate is just a bit more robust for broken
implementations.

> > > + return upper;
> > > +
> > > + lower = rate + 1;
> > ok, so your loop invariant is that the best freq is in [lower; upper].
> 
> right.
> 
> > 
> > > + do {
> > > + upper_last = upper;
> > > + lower_last = lower;
> > > +
> > > + cur = clk_round_rate(clk, lower + ((upper - lower) >> 1));
> > > + if (cur < lower)
> > > + lower += (upper - lower) >> 1;
> > You already know that lower + ((upper - lower) >> 1) is too small,

Re: [PATCH] staging: line6: toneport.c: Fix for possible null pointer dereference

[Stefan Hajnoczi]

On Mon, May 19, 2014 at 11:39 PM, Rickard Strandqvist
 wrote:
> There is otherwise a risk of a possible null pointer dereference.
>
> Was largely found by using a static code analysis program called cppcheck.
>
> Signed-off-by: Rickard Strandqvist 
> ---
>  drivers/staging/line6/toneport.c |   14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/line6/toneport.c 
> b/drivers/staging/line6/toneport.c
> index af2e7e5..36fe76d 100644
> --- a/drivers/staging/line6/toneport.c
> +++ b/drivers/staging/line6/toneport.c
> @@ -431,11 +431,15 @@ void line6_toneport_disconnect(struct usb_interface 
> *interface)
>  {
> struct usb_line6_toneport *toneport;
> u16 idProduct;
> +   struct snd_line6_pcm *line6pcm;
>
> if (interface == NULL)
> return;
>
> toneport = usb_get_intfdata(interface);
> +   if (toneport == NULL)
> +   return;
> +
> del_timer_sync(&toneport->timer);
> idProduct = le16_to_cpu(toneport->line6.usbdev->descriptor.idProduct);
>
> @@ -444,13 +448,11 @@ void line6_toneport_disconnect(struct usb_interface 
> *interface)
> device_remove_file(&interface->dev, &dev_attr_led_green);
> }
>
> -   if (toneport != NULL) {
> -   struct snd_line6_pcm *line6pcm = toneport->line6.line6pcm;

Didn't look into this but it's the traditional "use before NULL
check".  Can't hurt to fix it.

Reviewed-by: Stefan Hajnoczi 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHSET 00/21] perf tools: Add support to accumulate hist periods (v9)

[Jiri Olsa]

On Tue, May 20, 2014 at 04:06:43AM +0100, Rodrigo Campos wrote:
> On Tue, May 20, 2014 at 02:29:31AM +, Namhyung Kim wrote:
> > Hi Rodrigo,
> > 
> > On Mon, May 19, 2014 at 3:11 PM, Rodrigo Campos  wrote:
> > > Is there something I can help to have this merged ? As far as I tested, 
> > > this
> > > works fine here. Or is this ok, just waiting on the "perf report: Add -F 
> > > option for
> > > specifying output fields" patchset ?

I plan to do it today, can I use your Tested-by ?

thanks,
jirka

> > 
> > Thanks for testing!!  As I never got (negative) feedbacks or reviews
> > so far, I'd assume it's ok. :)  But as you said, it should wait for
> > the output field option merged which I hope to be done soon.  I'll
> > update and report this once it's done.
> 
> Great, thanks a lot! :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ACPI: Cleanup for acpi_os_map/unmap_memory() to eliminate __iomem.

[Lv Zheng]

ACPICA doesn't include protections around address space checking, Linux
build tests always complain increased sparse warnings around ACPICA
internal acpi_os_map/unmap_memory() invocations.  This patch tries to fix
this issue permanently.

There are 2 choices left for us to solve this issue:
1. Add __iomem address space awareness into ACPICA.
2. Remove sparse checker of __iomem from ACPICA source code.

This patch chooses solution 2, because:
1.  Most of the acpi_os_map/unmap_memory() invocations are used for ACPICA
table mappings, which in fact are not IO addresses.
2.  The only IO addresses usage is for "system memory space" mapping code:
 drivers/acpi/acpica/exregion.c:
mem_info->mapped_logical_address = acpi_os_map_memory((acpi_physical_address) 
address, map_length);
 drivers/acpi/acpica/evrgnini.c:
acpi_os_unmap_memory(local_region_context->
 drivers/acpi/acpica/exregion.c:
acpi_os_unmap_memory(mem_info->mapped_logical_address,
The mapped address is accessed in the handler of "system memory space"
- acpi_ex_system_memory_space_handler().  This function in fact can be
changed to invoke acpi_os_read/write_memory() so that __iomem can
always be type-casted in the OSL layer.
According to the above investigation, we drew the following conclusion:
It is not a good idea to introduce __iomem address space awareness into
ACPICA mostly in order to protect non-IO addresses.

We can simply remove __iomem for acpi_os_map/unmap_memory() to remove
__iomem checker for ACPICA code. Then we need to enforces external usages
to invoke other APIs that are aware of __iomem address space.
The external usages are:
 drivers/acpi/apei/einj.c:  v = acpi_os_map_memory(paddr + offset, 
sizeof(*v));
 drivers/acpi/apei/einj.c:  v5param = acpi_os_map_memory(pa_v5, 
sizeof(*v5param));
 drivers/acpi/apei/einj.c:  v4param = acpi_os_map_memory(pa_v4, 
sizeof(*v4param));
 drivers/acpi/acpi_extlog.c:extlog_l1_hdr = acpi_os_map_memory(l1_dirbase, 
l1_hdr_size);
 drivers/acpi/acpi_extlog.c:extlog_l1_addr = acpi_os_map_memory(l1_dirbase, 
l1_size);
 drivers/acpi/acpi_extlog.c:elog_addr = acpi_os_map_memory(elog_base, 
elog_size);
 drivers/char/tpm/tpm_acpi.c:   virt = acpi_os_map_memory(start, len);
 drivers/acpi/nvs.c:
acpi_os_unmap_memory(entry->kaddr,

This patch thus performs cleanups in this way:
1. Add acpi_os_map/unmap_iomem() to be invoked by non-ACPICA code.
2. Remove __iomem from acpi_os_map/unmap_memory().
Note that, further cleanups might be done to move early table mapping code
from acpi_os_map/unmap_iomem() to acpi_os_map/unmap_memory(), but this
patch doesn't go that far in order not to introduce regressions.

After applying this patch, following sparse warnings are eliminated from
ACPICA internal usages:
 drivers/acpi/acpica/tbutils.c:279:15: warning: incorrect type in assignment 
(different address spaces)
 drivers/acpi/acpica/tbutils.c:286:30: warning: incorrect type in argument 1 
(different address spaces)
 drivers/acpi/acpica/tbutils.c:298:15: warning: incorrect type in assignment 
(different address spaces)
 drivers/acpi/acpica/tbutils.c:329:30: warning: incorrect type in argument 1 
(different address spaces)
 drivers/acpi/acpica/tbutils.c:367:14: warning: incorrect type in assignment 
(different address spaces)
 drivers/acpi/acpica/tbutils.c:398:30: warning: incorrect type in argument 1 
(different address spaces)
 drivers/acpi/acpica/tbutils.c:421:15: warning: incorrect type in assignment 
(different address spaces)
 drivers/acpi/acpica/tbutils.c:433:30: warning: incorrect type in argument 1 
(different address spaces)
 drivers/acpi/acpica/tbutils.c:442:15: warning: incorrect type in assignment 
(different address spaces)
 drivers/acpi/acpica/tbutils.c:451:38: warning: incorrect type in argument 1 
(different address spaces)
 drivers/acpi/acpica/tbutils.c:495:30: warning: incorrect type in argument 1 
(different address spaces)
 drivers/acpi/acpica/evrgnini.c:89:74: warning: incorrect type in argument 1 
(different address spaces)
 drivers/acpi/acpica/exregion.c:145:54: warning: incorrect type in argument 1 
(different address spaces)
 drivers/acpi/acpica/exregion.c:180:50: warning: incorrect type in assignment 
(different address spaces)
 drivers/acpi/acpica/tbdata.c:109:23: warning: incorrect type in assignment 
(different address spaces)
 drivers/acpi/acpica/tbdata.c:162:38: warning: incorrect type in argument 1 
(different address spaces)
 drivers/acpi/acpica/tbdata.c:201:30: warning: incorrect type in assignment 
(different address spaces)
 drivers/acpi/acpica/tbdata.c:210:38: warning: incorrect type in argument 1 
(different address spaces)
 drivers/acpi/acpica/tbfadt.c:312:15: warning: incorrect type in assignment 
(different address spaces)
 drivers/acpi/acpica/tbfadt.c:331:30: warning: incorrect type in argument 1 
(different address spaces)
 

Re: [PATCH v4 2/8] OF: Introduce DT overlay support.

[Geert Uytterhoeven]

Hi Grant,

On Tue, May 20, 2014 at 7:50 AM, Grant Likely  wrote:
>> Why has the overlay system been designed for plugging and unpluging whole
>> overlays?
>> That means the kernel has to remember the full stack, causing issues with
>> e.g. kexec.
>
> Mostly so that drivers don't see any difference in the livetree data
> structure. It also means that userspace sees a single representation of
> the hardware at any given time.

Sorry, I don't follow the argument about the "single representation of the
hardware".

>> Why not allowing the addition of removal of subtrees of the full device
>> tree?
>
> Overlays is more than just a subtree. A single overlay can make
> manipulations of multiple subtrees that should be handled as logically
> atomic.

Sure, it's more complicated due to the atomicity of multiple changes.

>> This is similar to other hotpluggable subsystems (which are not necessarily
>> DT-based), like PCI Express. That way the kernel can pass a
>> DT-representation of the actual current device tree to a kexec'ed kernel.
>
> I'm not following you argument. Hardware hotplug systems like PCIe don't
> manipulate the firmware data. The kernel detects the new device and
> populates the Linux device model directly. Firmware provided data (ACPI
> or FDT) isn't involved.

I mean the kernel doesn't remember the exact order in a stack, to reverse
operations. E.g. I can add hotplug a PCIe bridge with multiple devices
behind it, and unplug a single device later. It's still one subtree, though.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] spi: atmel: fix typo in dev_err

[Raphaël Poggi]

Fix typo in dev_err.

Signed-off-by: Raphaël Poggi 
---
 drivers/spi/spi-atmel.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
index 079e6b1..7a1788b 100644
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1122,7 +1122,7 @@ static int atmel_spi_one_transfer(struct spi_master 
*master,
atmel_spi_lock(as);
if (WARN_ON(ret == 0)) {
dev_err(&spi->dev,
-   "spi trasfer timeout, err %d\n", ret);
+   "spi transfer timeout, err %d\n", ret);
as->done_status = -EIO;
} else {
ret = 0;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] dm: check era->md is non-NULL before closing it

[Joe Thornber]

On Tue, May 20, 2014 at 12:53:56PM +0900, na...@elisp.net wrote:
> In era_ctr(), era->md remain NULL until it's set after metadata_open().
> On the other hand, era_destroy() assume era->md is non-NULL and it is
> called by era_ctr() before initializing the value.

Thanks.  This change went into my tree on the 11th March, I'll chase
and see why it's not upstream yet.

- Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 6/6] ARM: dts: STiH407: Add B2120 board support

[Lee Jones]

> >> > +   soc {
> >> > +   sbc_serial0: serial@953 {
> >> > +   status = "okay";
> >> > +   };
> >>
> >> You might want to consider reference-based syntax here instead, so you
> >> don't have to mimic the hierarchy. That'd be (at the root level of the
> >> file, below this secion:
> >>
> >> &sbc_serial0: {
> >> status = "okay";
> >> };
> >
> > I'm personally not keen on this scheme.  It's sometimes helpful to know
> > the hierarchy and I don't think it's a large overhead to format the
> > subordinate DTS files in this way.
> >
> > Please consider not enforcing this.
> 
> Definitely not enforcing it, and I didn't use to like it either but it
> has some real upsides.
> 
> In particular, it saves a lot of grief when you're changing something
> like the unit-id of a node in .dtsi and forget to do the same update
> in the dts.

I'm not entirely sure what a unit-id is, but I can see that there
would be benefits to using the referenced-based syntax as you call
it.  If any of those benefits hold true here I won't push back, but I
would personally like to see us default to the hierarchical scheme.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4] i2c: add driver for Rockchip RK3xxx SoC I2C adapter

[Maxime Ripard]

On Mon, May 19, 2014 at 11:32:55AM +0200, Max Schwarz wrote:
> Driver for the native I2C adapter found in Rockchip RK3xxx SoCs.
> 
> Configuration is only possible through devicetree. The driver is
> interrupt driven and supports the I2C_M_IGNORE_NAK mangling bit.
> 
> Signed-off-by: Max Schwarz 

Reviewed-by: Maxime Ripard 

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


signature.asc
Description: Digital signature

linux-next: build warnings after merge of the input tree

[Stephen Rothwell]

Hi Dmitry,

After merging the input tree, today's linux-next build (powerpc
allyesconfig) produced these warnings:

drivers/input/touchscreen/atmel_mxt_ts.c: In function 'mxt_read_t9_resolution':
drivers/input/touchscreen/atmel_mxt_ts.c:1043:2: warning: passing argument 1 of 
'__swab16s' makes pointer from integer without a cast [enabled by default]
  le16_to_cpus(range.x);
  ^
In file included from include/linux/swab.h:4:0,
 from include/uapi/linux/byteorder/big_endian.h:12,
 from include/linux/byteorder/big_endian.h:4,
 from arch/powerpc/include/uapi/asm/byteorder.h:13,
 from include/asm-generic/bitops/le.h:5,
 from arch/powerpc/include/asm/bitops.h:279,
 from include/linux/bitops.h:33,
 from include/linux/kernel.h:10,
 from include/asm-generic/bug.h:13,
 from arch/powerpc/include/asm/bug.h:127,
 from include/linux/bug.h:4,
 from include/linux/thread_info.h:11,
 from include/asm-generic/preempt.h:4,
 from arch/powerpc/include/generated/asm/preempt.h:1,
 from include/linux/preempt.h:18,
 from include/linux/spinlock.h:50,
 from include/linux/seqlock.h:35,
 from include/linux/time.h:5,
 from include/linux/stat.h:18,
 from include/linux/module.h:10,
 from drivers/input/touchscreen/atmel_mxt_ts.c:16:
include/uapi/linux/swab.h:223:20: note: expected '__u16 *' but argument is of 
type 'u16'
 static inline void __swab16s(__u16 *p)
^
drivers/input/touchscreen/atmel_mxt_ts.c:1044:2: warning: passing argument 1 of 
'__swab16s' makes pointer from integer without a cast [enabled by default]
  le16_to_cpus(range.y);
  ^
In file included from include/linux/swab.h:4:0,
 from include/uapi/linux/byteorder/big_endian.h:12,
 from include/linux/byteorder/big_endian.h:4,
 from arch/powerpc/include/uapi/asm/byteorder.h:13,
 from include/asm-generic/bitops/le.h:5,
 from arch/powerpc/include/asm/bitops.h:279,
 from include/linux/bitops.h:33,
 from include/linux/kernel.h:10,
 from include/asm-generic/bug.h:13,
 from arch/powerpc/include/asm/bug.h:127,
 from include/linux/bug.h:4,
 from include/linux/thread_info.h:11,
 from include/asm-generic/preempt.h:4,
 from arch/powerpc/include/generated/asm/preempt.h:1,
 from include/linux/preempt.h:18,
 from include/linux/spinlock.h:50,
 from include/linux/seqlock.h:35,
 from include/linux/time.h:5,
 from include/linux/stat.h:18,
 from include/linux/module.h:10,
 from drivers/input/touchscreen/atmel_mxt_ts.c:16:
include/uapi/linux/swab.h:223:20: note: expected '__u16 *' but argument is of 
type 'u16'
 static inline void __swab16s(__u16 *p)
^
Introduced by commit de22385758fa ("Input: atmel_mxt_ts - read screen
config from chip").
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

Re: [PATCH 06/20] perf tools: Consolidate output field handling to hpp format routines

[Jiri Olsa]

On Tue, May 20, 2014 at 02:22:21AM +, Namhyung Kim wrote:
> Jiri,
> 
> I updated my -v6 branch to fix the breakage - move the hunk to 15/20.
> Do you want me to resend or would you review with this thread
> directly?  Either way would be find to me.

np, I can take it from branch

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 1/3] mfd: AXP22x: add support for APX221 PMIC

[Lee Jones]

> >>> This patch introduces preliminary support for the X-Powers AXP221 PMIC.
> >>> The AXP221 is typically used on boards using Allwinner's A31 SoC.
> >>>
> >>> At the moment, this driver only exposes regulator devices, but other
> >>> subdevices.
> >>>
> >>> Signed-off-by: Boris BREZILLON 
> >>> ---
> >>>  drivers/mfd/Kconfig|  12 +++
> >>>  drivers/mfd/Makefile   |   1 +
> >>>  drivers/mfd/axp22x.c   | 237 
> >>> +
> >>>  include/linux/mfd/axp22x.h | 149 
> >>>  4 files changed, 399 insertions(+)
> >>>  create mode 100644 drivers/mfd/axp22x.c
> >>>  create mode 100644 include/linux/mfd/axp22x.h
> >> Not a chance.
> >>
> >> Fa, too much common code with axp20x.c - please merge into one file.
> >>
> > 
> > This was one of the questions I asked in my cover letter (could you take
> > a look at it and tell me what's your prefered solution ?) ;-).
> > 
> > I first tried to reuse the axp20x drivers, but ended up copying almost
> > all definitions, hence I decided to first do a different driver and ask
> > for advices.
> 
> I've just taken a good look at this (I'm planning on doing an axp152 driver
> myself), and it seems that using a single mfd driver for the 20x and 221 
> should
> be quite feasible:
> 
> - axp20x.h would get some new register defines for registers which are
>   different (or unique) to the 221 prefixed with aXP221
> - An axp20x_writeable_ranges would need
>   to be extended with a third range going from AXP221_BAT_CAP1 (0xe0)
>   to AXP221_BAT_LOW_THRESH (0xe6)
> - axp20x_writeable_table would get .n_yes_ranges set to 2, and a new
>   apx22x_writeable_table would be introduced with n_yes_ranges set to 3.
> - add a new axp221_supplies array
> - add a new axp221_cells array
> - and finally use the proper structs in axp20x_i2c_probe depending on the type
> 
> Note that this means sharing ie the interrupt table, which is ok since they
> are the same, except that the 221 has a couple of interrupts missing, but
> the ones which are shared are all at the same place.

Exactly.  As .probe() is identical, you only require some device
matching and some extra structs where the data actually differs
between devices.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] i2c: add driver for Rockchip RK3xxx SoC I2C adapter

[Heiko Stübner]

Am Montag, 19. Mai 2014, 02:37:57 schrieb Max Schwarz:
> Driver for the native I2C adapter found in Rockchip RK3xxx SoCs.
> 
> Configuration is only possible through devicetree. The driver is
> interrupt driven and supports the I2C_M_IGNORE_NAK mangling bit.
> 
> Signed-off-by: Max Schwarz 

Acked-by: Heiko Stuebner 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 2/5] clk: Introduce 'clk_round_rate_nearest()'

[Uwe Kleine-König]

Hello,

On Mon, May 19, 2014 at 10:29:05AM -0700, Sören Brinkmann wrote:
> With the improvements suggested by you I have this now:
> 
> long clk_round_rate_nearest(struct clk *clk, unsigned long rate)
> {
>   unsigned long lower, upper;
> 
>   lower = clk_round_rate(clk, rate);
>   if (lower >= rate)
>   return lower;
> 
>   upper = clk_round_rate(clk, rate + (rate - lower) - 1);
>   if (upper == lower)
>   return upper;
> 
>   lower = rate + 1;
>   while (lower < upper) {
>   unsigned long rounded, mid;
> 
>   mid = lower + ((upper - lower) >> 1);
>   rounded = clk_round_rate(clk, mid);
>   if (rounded < lower)
>   lower = mid + 1;
>   else
>   upper = rounded;
>   }
> 
>   return upper;
> }
This is nearly my version now. I just lacks the overflow check when
calculating upper and I skipped the early return if (upper == lower).
(Instead the while condition evaluates to false on the first hit and
returns with the same result.)

Other than that I added a few comments. :-)

Something we still should resolve is the return type. It should match
clk_round_rate, but should both be signed or unsigned? 

Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sched/dl: Fix race between dl_task_timer() and sched_setaffinity()

[Peter Zijlstra]

On Tue, May 20, 2014 at 09:08:53AM +0400, Kirill Tkhai wrote:
> 
> 
> 20.05.2014, 04:00, "Peter Zijlstra" :
> > On Mon, May 19, 2014 at 11:31:19PM +0400, Kirill Tkhai wrote:
> >
> >>  @@ -513,9 +513,17 @@ static enum hrtimer_restart dl_task_timer(struct 
> >> hrtimer *timer)
> >>    struct 
> >> sched_dl_entity,
> >>    dl_timer);
> >>   struct task_struct *p = dl_task_of(dl_se);
> >>  - struct rq *rq = task_rq(p);
> >>  + struct rq *rq;
> >>  +again:
> >>  + rq = task_rq(p);
> >>   raw_spin_lock(&rq->lock);
> >>
> >>  + if (unlikely(rq != task_rq(p))) {
> >>  + /* Task was moved, retrying. */
> >>  + raw_spin_unlock(&rq->lock);
> >>  + goto again;
> >>  + }
> >>  +
> >
> > That thing is called: rq = __task_rq_lock(p);
> 
> But p->pi_lock is not held. The problem is __task_rq_lock() has lockdep 
> assert.
> Should we change it?

Ok, so now that I'm awake ;-)

So the trivial problem as described by your initial changelog isn't
right, because we cannot call sched_setaffinity() on deadline tasks, or
rather we can, but we can't actually change the affinity mask.

Now I suppose the problem can still actually happen when you change the
root domain and trigger a effective affinity change that way.

That said, no leave it as you proposed, adding a *task_rq_lock() variant
without lockdep assert in will only confuse things, as normally we
really should be also taking ->pi_lock.

The only reason we don't strictly need ->pi_lock now is because we're
guaranteed to have p->state == TASK_RUNNING here and are thus free of
ttwu races.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V4 0/2] mm: FAULT_AROUND_ORDER patchset performance data for powerpc

[Madhavan Srinivasan]

On Tuesday 20 May 2014 01:02 PM, Andrew Morton wrote:
> On Tue, 20 May 2014 15:52:07 +0930 Rusty Russell  
> wrote:
> 
>> "Kirill A. Shutemov"  writes:
>>> Andrew Morton wrote:
 On Mon, 19 May 2014 16:23:07 -0700 (PDT) Hugh Dickins  
 wrote:

> Shouldn't FAULT_AROUND_ORDER and fault_around_order be changed to be
> the order of the fault-around size in bytes, and fault_around_pages()
> use 1UL << (fault_around_order - PAGE_SHIFT)

 Yes.  And shame on me for missing it (this time!) at review.

 There's still time to fix this.  Patches, please.
>>>
>>> Here it is. Made at 3.30 AM, build tested only.
>>
>> Prefer on top of Maddy's patch which makes it always a variable, rather
>> than CONFIG_DEBUG_FS.  It's got enough hair as it is.
>>
> 
> We're at 3.15-rc5 and this interface should be finalised for 3.16.  So
> Kirrill's patch is pretty urgent and should come first.
> 
> Well.  It's only a debugfs interface at this stage so we are allowed to
> change it later, but it's better not to.
>
My patchset does not change the interface, but uses the current fault
around order variable from CONFIG_DEBUG_FS block to allow changes at
runtime, instead of having a constant and some cleanup.

Thanks for review
Regards
--Maddy



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PM / runtime: Update documentation to reflect the current code flow

[Ulf Hansson]

On 16 May 2014 13:44, Rafael J. Wysocki  wrote:
> From: Rafael J. Wysocki 
>
> The runtime PM documentation in runtime_pm.txt has not been updated
> after some changes to the system suspend and resume core code, so
> update it to reflect the current code flow.
>
> Signed-off-by: Rafael J. Wysocki 

Looks good!

Reviewed-by: Ulf Hansson 

> ---
>
> This is independent of the "do not resume runtime-suspended devices" series.
>
> Thanks!
>
> ---
>  Documentation/power/runtime_pm.txt |   18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
>
> Index: linux-pm/Documentation/power/runtime_pm.txt
> ===
> --- linux-pm.orig/Documentation/power/runtime_pm.txt
> +++ linux-pm/Documentation/power/runtime_pm.txt
> @@ -665,15 +665,17 @@ The PM core does its best to reduce the
>  the runtime PM and system suspend/resume (and hibernation) callbacks by 
> carrying
>  out the following operations:
>
> -  * During system suspend it calls pm_runtime_get_noresume() and
> -pm_runtime_barrier() for every device right before executing the
> -subsystem-level .suspend() callback for it.  In addition to that it calls
> -__pm_runtime_disable() with 'false' as the second argument for every 
> device
> -right before executing the subsystem-level .suspend_late() callback for 
> it.
> +  * During system suspend pm_runtime_get_noresume() is called for every 
> device
> +right before executing the subsystem-level .prepare() callback for it and
> +pm_runtime_barrier() is called for every device right before executing 
> the
> +subsystem-level .suspend() callback for it.  In addition to that the PM 
> core
> +calls  __pm_runtime_disable() with 'false' as the second argument for 
> every
> +device right before executing the subsystem-level .suspend_late() 
> callback
> +for it.
>
> -  * During system resume it calls pm_runtime_enable() and pm_runtime_put()
> -for every device right after executing the subsystem-level 
> .resume_early()
> -callback and right after executing the subsystem-level .resume() callback
> +  * During system resume pm_runtime_enable() and pm_runtime_put() are called 
> for
> +every device right after executing the subsystem-level .resume_early()
> +callback and right after executing the subsystem-level .complete() 
> callback
>  for it, respectively.
>
>  7. Generic subsystem callbacks
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 6/6] ARM: dts: STiH407: Add B2120 board support

[Maxime Coquelin]

On 05/20/2014 09:43 AM, Lee Jones wrote:

+   soc {
+   sbc_serial0: serial@953 {
+   status = "okay";
+   };


You might want to consider reference-based syntax here instead, so you
don't have to mimic the hierarchy. That'd be (at the root level of the
file, below this secion:

&sbc_serial0: {
 status = "okay";
};


I'm personally not keen on this scheme.  It's sometimes helpful to know
the hierarchy and I don't think it's a large overhead to format the
subordinate DTS files in this way.

Please consider not enforcing this.


Definitely not enforcing it, and I didn't use to like it either but it
has some real upsides.

In particular, it saves a lot of grief when you're changing something
like the unit-id of a node in .dtsi and forget to do the same update
in the dts.


I'm not entirely sure what a unit-id is, but I can see that there
would be benefits to using the referenced-based syntax as you call
it.  If any of those benefits hold true here I won't push back, but I
would personally like to see us default to the hierarchical scheme.



+1, I would prefer to keep the hierarchical scheme.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] m68k: remove check for CONFIG_BSEIP

[Paul Bolle]

There used to be a Kconfig symbol BSEIP. It was PPC specific and was
removed in v2.6.27. So the check for CONFIG_BSEIP can be removed. This
means a few defines will be removed. None of the macros involved are
used, so no one should care.

Signed-off-by: Paul Bolle 
---
Untested.

 arch/m68k/include/asm/commproc.h | 22 --
 1 file changed, 22 deletions(-)

diff --git a/arch/m68k/include/asm/commproc.h b/arch/m68k/include/asm/commproc.h
index 66a36bd51aa1..c67e09279ea9 100644
--- a/arch/m68k/include/asm/commproc.h
+++ b/arch/m68k/include/asm/commproc.h
@@ -480,28 +480,6 @@ typedef struct scc_enet {
 #define SICR_ENET_CLKRT((uint)0x003d)
 #endif
 
-#ifdef CONFIG_BSEIP
-/* This ENET stuff is for the MPC823 with ethernet on SCC2.
- * This is unique to the BSE ip-Engine board.
- */
-#define PA_ENET_RXD((ushort)0x0004)
-#define PA_ENET_TXD((ushort)0x0008)
-#define PA_ENET_TCLK   ((ushort)0x0100)
-#define PA_ENET_RCLK   ((ushort)0x0200)
-#define PB_ENET_TENA   ((uint)0x2000)
-#define PC_ENET_CLSN   ((ushort)0x0040)
-#define PC_ENET_RENA   ((ushort)0x0080)
-
-/* BSE uses port B and C bits for PHY control also.
-*/
-#define PB_BSE_POWERUP ((uint)0x0004)
-#define PB_BSE_FDXDIS  ((uint)0x8000)
-#define PC_BSE_LOOPBACK((ushort)0x0800)
-
-#define SICR_ENET_MASK ((uint)0xff00)
-#define SICR_ENET_CLKRT((uint)0x2c00)
-#endif
-
 /* SCC Event register as used by Ethernet.
 */
 #define SCCE_ENET_GRA  ((ushort)0x0080)/* Graceful stop complete */
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v1 5/5] pci: keystone: add pcie driver based on designware core driver

[Arnd Bergmann]

On Monday 19 May 2014 17:10:50 Murali Karicheri wrote:
> On 5/19/2014 8:06 AM, Arnd Bergmann wrote:
> > On Friday 16 May 2014 16:26:51 Murali Karicheri wrote:
> >> On 5/15/2014 2:20 PM, Arnd Bergmann wrote:
> >>> On Thursday 15 May 2014 13:45:08 Murali Karicheri wrote:
> >> +#ifdef CONFIG_PCI_KEYSTONE
> >> +/*
> >> + * The KeyStone PCIe controller has maximum read request size of 256 
> >> bytes.
> >> + */
> >> +static void quirk_limit_readrequest(struct pci_dev *dev)
> >> +{
> >> +int readrq = pcie_get_readrq(dev);
> >> +
> >> +if (readrq > 256)
> >> +pcie_set_readrq(dev, 256);
> >> +}
> >> +DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, 
> >> quirk_limit_readrequest);
> >> +#endif /* CONFIG_PCI_KEYSTONE */
> > This doesn't work: you can't just limit do this for all devices just 
> > based
> > on PCI_KEYSTONE being enabled, you have to check if you are actually 
> > using
> > this controller.
> >
> > Arnd
>  I assume, I need to check if PCI controller's vendor ID/ device ID
>  match with the keystone
>  PCI controller's ID and call pcie_set_readrq() for all of the slave
>  PCI devices and do this fixup.
>  Is this correct understanding?  If you can point me to an example code
>  for this that will be
>  really helpful so that I can avoid re-inventing the wheel.
> >>> I think it would be best to move the quirk into the keystone pci driver
> >>> and compare compare the dev->driver pointer of the PCI controller device.
> >>>
> >>>Arnd
> >> Arnd,
> >>
> >> I will move this quirk to keystone pci driver. So in that case, I guess
> >> your original comment
> >> is not applicable as  this quirk gets enabled only with PCI keystone
> >> driver enabled. Right?
> > Of course you still have to fix the bug, not just move the code into
> > the driver. Otherwise it's still broken for every machine after the keystone
> > driver is enabled.
> 
> Agree. I have tried following to get this work so that the quirk gets 
> applied only for
> keystone pci controller.
> 
> #define KS_K2HK_PCI_DEVICE_ID0xb008
> #define KS_K2E_PCI_DEVICE_ID0xb009
> #define KS_K2L_PCI_DEVICE_ID0xb00a
> 
> static u16 root_pci_ids[] =
>  {KS_K2HK_PCI_DEVICE_ID, KS_K2E_PCI_DEVICE_ID, KS_K2L_PCI_DEVICE_ID, 
> 0 };
> /*
>   * The KeyStone PCIe controller has maximum read request size of 256 bytes.
>   */
> static void quirk_limit_readrequest(struct pci_dev *dev)
> {
>  struct pci_dev *root_dev;
>  int i = 0;
> 
>  /* Apply quirk only if this bridge device is keystone */
>  while (root_pci_ids[i]) {
>  root_dev = pci_get_device(PCI_VENDOR_ID_TI, root_pci_ids[i], NULL);
>  if ((root_dev->class >> 8) == PCI_CLASS_BRIDGE_PCI) {
>  int readrq;
> 
>  readrq = pcie_get_readrq(dev);
>  if (pcie_get_readrq(dev) > 256) {
>  pcie_set_readrq(dev, 256);
>  printk("Applied quirk\n");
>  }
>  break;
>  };
>  }
> }
> DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, quirk_limit_readrequest);

Why not compare the driver pointer as I suggested?

> > I also agree with Jason that changing the PCI core to call
> > pcie_bus_configure_settings() would be a better way of dealing with this
> > if it solves the problem.
> 
> I tried following piece of code added to bios32.c
> 
> void pci_common_init_dev(struct device *parent, struct hw_pci *hw)
> {
>  struct pci_sys_data *sys;
>  LIST_HEAD(head);
> 
>  pci_add_flags(PCI_REASSIGN_ALL_RSRC);
>  if (hw->preinit)
>  hw->preinit();
> 
>   
>   
> 
>   list_for_each_entry(sys, &head, node) {
>  struct pci_bus *bus = sys->bus;
> 
>  if (!pci_has_flag(PCI_PROBE_ONLY)) {
>  /*
>   * Size the bridge windows.
>   */
>  pci_bus_size_bridges(bus);
> 
>  /*
>   * Assign resources.
>   */
>  pci_bus_assign_resources(bus);
>  }
>  /*
>   * Tell drivers about devices found.
>   */
>  pci_bus_add_devices(bus);
>  }
> 
> // New code starts here
>  list_for_each_entry(sys, &head, node) {
>  struct pci_bus *bus = sys->bus;
> 
>  /* Configure PCI Express settings */
>  if (bus && !pci_has_flag(PCI_PROBE_ONLY)) {
>  struct pci_bus *child;
> 
>  list_for_each_entry(child, &bus->children, node)
>  pcie_bus_configure_settings(child);
>  }
>  }
> // New code ends.

This is the ARM specific part of the PCI code. I t

linux-next: build failure after merge of the mfd-lj tree

[Stephen Rothwell]

Hi Lee,

After merging the mfd-lj tree, today's linux-next build (powerpc
allyesconfig) failed like this:

drivers/mfd/stmpe.c: In function 'stmpe_irq_init':
drivers/mfd/stmpe.c:1000:15: error: 'struct stmpe' has no member named 
'irq_base'
   base = stmpe->irq_base;
   ^

Caused by commit 3ba1d516d5fe ("mfd: stmpe: root out static GPIO and
IRQ assignments").

This is exactly the same error and commit I reported against the gpio
tree on Friday.  Why has it come back?

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

[PATCH] m32r: remove check for CONFIG_IDC_AK4524

[Paul Bolle]

There's been a check for CONFIG_IDC_AK4524 and its MODULE variant in
m32r's code ever since it was added in v2.6.9. But there has never been
a Kconfig symbol IDC_AK4524. Remove this check.

Signed-off-by: Paul Bolle 
---
Untested.

 arch/m32r/platforms/usrv/setup.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/arch/m32r/platforms/usrv/setup.c b/arch/m32r/platforms/usrv/setup.c
index dcde0ec777f6..04af9c2a83d9 100644
--- a/arch/m32r/platforms/usrv/setup.c
+++ b/arch/m32r/platforms/usrv/setup.c
@@ -194,15 +194,6 @@ void __init init_IRQ(void)
disable_m32700ut_pld_irq(PLD_IRQ_UART1);
 #endif /* CONFIG_SERIAL_8250 || CONFIG_SERIAL_8250_MODULE */
 
-#if defined(CONFIG_IDC_AK4524) || defined(CONFIG_IDC_AK4524_MODULE)
-   /* INT#80: AK4524 IREQ on PLD */
-   irq_set_chip_and_handler(PLD_IRQ_SNDINT, &m32700ut_pld_irq_type,
-handle_level_irq);
-   pld_icu_data[irq2pldirq(PLD_IRQ_SNDINT)].icucr
-   = PLD_ICUCR_ISMOD01;/* 'L' level sense */
-   disable_m32700ut_pld_irq(PLD_IRQ_SNDINT);
-#endif /* CONFIG_IDC_AK4524 || CONFIG_IDC_AK4524_MODULE */
-
/*
 * INT1# is used for UART, MMC, CF Controller in FPGA.
 * We enable it here.
-- 
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V4 2/2] powerpc/pseries: init fault_around_order for pseries

[Madhavan Srinivasan]

On Tuesday 20 May 2014 12:58 PM, Andrew Morton wrote:
> On Thu,  8 May 2014 14:58:16 +0530 Madhavan Srinivasan 
>  wrote:
> 
>> --- a/arch/powerpc/platforms/pseries/pseries.h
>> +++ b/arch/powerpc/platforms/pseries/pseries.h
>> @@ -17,6 +17,8 @@ struct device_node;
>>  extern void request_event_sources_irqs(struct device_node *np,
>> irq_handler_t handler, const char *name);
>>  
>> +extern unsigned int fault_around_order;
> 
> This isn't an appropriate header file for exporting something from core
> mm - what happens if arch/mn10300 wants it?.
>
> I guess include/linux/mm.h is the place.
> 

Rusty already suggested this. My bad.  Reason for adding it here was
that, I did the performance test for this platform. Will change and send
it out.

Thanks for review
Regards
Maddy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the dma-buf tree with the staging tree

[Sumit Semwal]

On 20 May 2014 12:36, Greg KH  wrote:
> On Tue, May 20, 2014 at 05:00:31PM +1000, Stephen Rothwell wrote:
>> Hi Sumit,
>>
>> Today's linux-next merge of the dma-buf tree got a conflict in
>> drivers/staging/android/sync.c between commit 10f62861b4a2 ("staging:
>> android: fix missing a blank line after declarations") from the staging
>> tree and commit 85958aff6184 ("android: convert sync to fence api, v5")
>> from the dma-buf tree.
>>
>> I fixed it up (I just used the dma-buf tree version of conflicting
>> sections) and can carry the fix as necessary (no action is required).
>
> Sounds good, thanks.
>
> greg k-h

Sure Stephen,

Sounds good! Thanks.

Sumit
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: manual merge of the dma-buf tree with the drm-intel tree

[Sumit Semwal]

On 20 May 2014 12:25, Stephen Rothwell  wrote:
> Hi Sumit,
>
> Today's linux-next merge of the dma-buf tree got a conflict in
> drivers/gpu/drm/i915/i915_gem_dmabuf.c between commit 5cc9ed4b9a7a
> ("drm/i915: Introduce mapping of user pages into video memory (userptr)
> ioctl") from the drm-intel tree and commit 8dfb1f0f8103 ("dma-buf: use
> reservation objects") from the dma-buf tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
>
Hi Stephen!

This seems good, thanks!

Best regards,
~Sumit.
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc drivers/gpu/drm/i915/i915_gem_dmabuf.c
> index 580aa42443ed,817ec444c976..
> --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
> @@@ -229,15 -233,8 +229,16 @@@ static const struct dma_buf_ops i915_dm
>   struct dma_buf *i915_gem_prime_export(struct drm_device *dev,
>   struct drm_gem_object *gem_obj, int 
> flags)
>   {
>  +  struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
>  +
>  +  if (obj->ops->dmabuf_export) {
>  +  int ret = obj->ops->dmabuf_export(obj);
>  +  if (ret)
>  +  return ERR_PTR(ret);
>  +  }
>  +
> -   return dma_buf_export(gem_obj, &i915_dmabuf_ops, gem_obj->size, 
> flags);
> +   return dma_buf_export(gem_obj, &i915_dmabuf_ops, gem_obj->size, flags,
> +   NULL);
>   }
>
>   static int i915_gem_object_get_pages_dmabuf(struct drm_i915_gem_object *obj)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: hanging aio process

[Sebastian Ott]

On Mon, 19 May 2014, Benjamin LaHaise wrote:
> On Mon, May 19, 2014 at 07:38:51PM +0200, Sebastian Ott wrote:
> > Hello,
> > 
> > on the latest kernel a fio job with 4 workers using libaio hangs.
> 
> Is more than one process stuck in state D when the hang occurs?  If so, 
> what does a backtrace show for the stuck processes (or are there any 
> hung process warnings issued)?

I've seen both - just one or multiple processes in D state. Here it are 2:

./fio ../../test.job 
file1: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=32
file2: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=32
file3: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=32
file4: (g=0): rw=randrw, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=32
fio-2.1.8
Starting 4 processes
Jobs: 2 (f=0): [m__m] [100.0% done] [0KB/0KB/0KB /s] [0/0/0 iops] [eta 00m:00s]



[   58.125227] fio D 006a2dfe 0   804800 0x0001
[   58.125229]7b52fb88 00ab3800 00ab3800 
009e60b0 
[   58.125229]00ab3800 789284d8 02e0f800 
78928000 
[   58.125229]797aec00 00ab3800 00ab3800 
009e60b0 
[   58.125229]00ab3800  02e0f800 
78928000 
[   58.125229]006b39b0 006a377a 7b52fbc8 
7b52fd20 
[   58.125238] Call Trace:
[   58.125240] ([<006a377a>] __schedule+0x562/0xcc8)
[   58.125241]  [<006a2dfe>] schedule_timeout+0x1ee/0x270
[   58.125243]  [<006a4acc>] wait_for_common+0x100/0x1d0
[   58.125246]  [<002ca3fe>] SyS_io_destroy+0x9a/0xdc
[   58.125247]  [<006a80f8>] sysc_nr_ok+0x22/0x28
[   58.125248]  [<03fffd21c6d2>] 0x3fffd21c6d2
[   58.125250] fio D 006a2dfe 0   811800 0x0001
[   58.125252]7d82bb88 00ab3800 00ab3800 
009e60b0 
[   58.125252]00ab3800 7b0869f8 02e0f800 
7b086520 
[   58.125252]7ea0f600 00ab3800 00ab3800 
009e60b0 
[   58.125252]00ab3800  02e0f800 
7b086520 
[   58.125252]006b39b0 006a377a 7d82bbc8 
7d82bd20 
[   58.125261] Call Trace:
[   58.125263] ([<006a377a>] __schedule+0x562/0xcc8)
[   58.125264]  [<006a2dfe>] schedule_timeout+0x1ee/0x270
[   58.125266]  [<006a4acc>] wait_for_common+0x100/0x1d0
[   58.125267]  [<002ca3fe>] SyS_io_destroy+0x9a/0xdc
[   58.125269]  [<006a80f8>] sysc_nr_ok+0x22/0x28
[   58.125270]  [<03fffd21c6d2>] 0x3fffd21c6d2


> It is entirely possible the bug isn't 
> caused by the referenced commit, as the commit you're pointing to merely 
> makes io_destroy() syscall wait for all aio outstanding to complete 
> before returning.

I cannot reproduce this when I revert said commit (on top of 14186fe). If
that matters - the arch is s390.

Regards,
Sebastian
> 
>   -ben
> 
> > git bisect points to:
> > commit e02ba72aabfade4c9cd6e3263e9b57bf890ad25c
> > Author: Anatol Pomozov 
> > Date:   Tue Apr 15 11:31:33 2014 -0700
> > 
> > aio: block io_destroy() until all context requests are completed
> > 
> > 
> > The fio workers are on the wait_for_completion in sys_io_destroy.
> > 
> > Regards,
> > Sebastian
> > [global]
> > blocksize=4K
> > size=256M
> > rw=randrw
> > verify=md5
> > iodepth=32
> > ioengine=libaio
> > direct=1
> > end_fsync=1
> > 
> > [file1]
> > filename=/dev/scma
> > 
> > [file2]
> > filename=/dev/scmbw
> > 
> > [file3]
> > filename=/dev/scmc
> > 
> > [file4]
> > filename=/dev/scmx
> 
> 
> -- 
> "Thought is the essence of where you are now."
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC 00/12] Add Qualcomm SD Card Controller support.

[Srinivas Kandagatla]

Thanks Bjorn for testing this series.

On 19/05/14 23:08, Bjorn Andersson wrote:

On Mon, Apr 21, 2014 at 2:43 PM,  wrote:

>From: Srinivas Kandagatla

[snip]

>
>This patches are tested in PIO mode on IFC8064 board with both eMMC and
>external SD card. I would appreciate any feedback/suggestions on the overall
>approach.

Hi Srini,

I finally got around to give this series a spin on our APQ8064 based
devices as well. I had a few reported CRC issues on our msm8960 based
devices, but thinks seems functionally "ok".

On APQ8064, the kernel finds the onboard eMMC and when mounting it I
get the following:

[1.624118] mmc0: new high speed MMC card at address 0001
[1.627521] mmcblk0: mmc0:0001 MAG2GA 14.5 GiB
[1.632714] mmcblk0boot0: mmc0:0001 MAG2GA partition 1 2.00 MiB
[1.636989] mmcblk0boot1: mmc0:0001 MAG2GA partition 2 2.00 MiB
[1.637393] Freeing unused kernel memory: 332K (c09c6000 - c0a19000)
[1.663379] mmcblk0: response CRC error sending r/w cmd command,

[2.292914] mmcblk0: response CRC error sending r/w cmd command,
card status 0xb00
[2.300985] mmcblk0: response CRC error sending r/w cmd command,


Any suggestions of what I could do to help you debug this?



There might be couple of reasons why this might happen,

First is the regluators. currently the upstream kernel does not have 
support for regulators. So, does the eMMC on your board work perfectly 
fine with the default 2.7v?


secondly it could be eMMC vendor specific quirks.

I stress tested eMMC on IFC6410 and I did not hit any issues as you 
mentioned.


Are you aware of any such quirks specific to the eMMC on your board?

thanks,
srini


Regards,
Bjorn

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 2/3] powerpc, ptrace: Enable support for transactional memory register sets

[Anshuman Khandual]

On 05/19/2014 08:13 PM, Pedro Alves wrote:
> On 05/19/2014 12:46 PM, Anshuman Khandual wrote:
> 
 I couldn't actually find any arch that currently returns -ENODEV in
 the "active" hook.  I see that binfmt_elf.c doesn't handle
 regset->active() returning < 0.  Guess that may be why.  Looks like
 something that could be cleaned up, to me.

>> Also it does not consider the return value of regset->active(t->task, regset)
>> (whose objective is to figure out whether we need to request regset->n number
>> of elements or less than that) in the subsequent call to regset->get 
>> function.
> 
> Indeed.
> 
> TBC, do you plan on fixing this?  Otherwise ...

Sure, thinking something like this as mentioned below. But still not sure how 
to use
the return type of -ENODEV from the function regset->active(). Right now if any
regset does have the active hook and it returns anything but positive value, it 
will
be ignored and the control moves to the next regset in view. This prevents the 
thread
core note type being written to the core dump.

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index aa3cb62..80672fb 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1553,7 +1553,15 @@ static int fill_thread_core_info(struct 
elf_thread_core_info *t,
if (regset->core_note_type && regset->get &&
(!regset->active || regset->active(t->task, regset))) {
int ret;
-   size_t size = regset->n * regset->size;
+   size_t size;
+
+   /* Request only the active elements in the regset */
+   if (!regset->active)
+   size = regset->n * regset->size;
+   else
+   size = regset->active(t->task, regset)
+   * regset->size;
+
void *data = kmalloc(size, GFP_KERNEL);
if (unlikely(!data))
return 0;

> 
>> Now coming to the installation of the .active hooks part for all the new 
>> regsets, it
>> should be pretty straight forward as well. Though its optional and used for 
>> elf_core_dump
>> purpose only, its worth adding them here. Example of an active function 
>> should be something
>> like this. The function is inexpensive as required.
>>
>> +static int tm_spr_active(struct task_struct *target,
>> +   const struct user_regset *regset)
>> +{
>> +   if (!cpu_has_feature(CPU_FTR_TM))
>> +   return -ENODEV;
> 
> ... unfortunately this will do the wrong thing.

I am not sure whether I understand this correctly. Are you saying that its 
wrong to return
-ENODEV in this case as above ?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sched/dl: Fix race between dl_task_timer() and sched_setaffinity()

[Juri Lelli]

Hi,

On Tue, 20 May 2014 09:53:15 +0200
Peter Zijlstra  wrote:

> On Tue, May 20, 2014 at 09:08:53AM +0400, Kirill Tkhai wrote:
> > 
> > 
> > 20.05.2014, 04:00, "Peter Zijlstra" :
> > > On Mon, May 19, 2014 at 11:31:19PM +0400, Kirill Tkhai wrote:
> > >
> > >>  @@ -513,9 +513,17 @@ static enum hrtimer_restart dl_task_timer(struct 
> > >> hrtimer *timer)
> > >>    struct 
> > >> sched_dl_entity,
> > >>    dl_timer);
> > >>   struct task_struct *p = dl_task_of(dl_se);
> > >>  - struct rq *rq = task_rq(p);
> > >>  + struct rq *rq;
> > >>  +again:
> > >>  + rq = task_rq(p);
> > >>   raw_spin_lock(&rq->lock);
> > >>
> > >>  + if (unlikely(rq != task_rq(p))) {
> > >>  + /* Task was moved, retrying. */
> > >>  + raw_spin_unlock(&rq->lock);
> > >>  + goto again;
> > >>  + }
> > >>  +
> > >
> > > That thing is called: rq = __task_rq_lock(p);
> > 
> > But p->pi_lock is not held. The problem is __task_rq_lock() has lockdep 
> > assert.
> > Should we change it?
> 
> Ok, so now that I'm awake ;-)
> 
> So the trivial problem as described by your initial changelog isn't
> right, because we cannot call sched_setaffinity() on deadline tasks, or
> rather we can, but we can't actually change the affinity mask.
> 

Well, if we disable AC we can. And I was able to recreate that race in
that case.

> Now I suppose the problem can still actually happen when you change the
> root domain and trigger a effective affinity change that way.
> 

Yeah, I think here too.

> That said, no leave it as you proposed, adding a *task_rq_lock() variant
> without lockdep assert in will only confuse things, as normally we
> really should be also taking ->pi_lock.
> 
> The only reason we don't strictly need ->pi_lock now is because we're
> guaranteed to have p->state == TASK_RUNNING here and are thus free of
> ttwu races.

Maybe we could add this as part of the comment.

Thanks,

- Juri
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 1/3] mfd: AXP22x: add support for APX221 PMIC

[Hans de Goede]

Hi,

On 05/19/2014 07:45 PM, Boris BREZILLON wrote:
> Hello Lee,
> 
> On 19/05/2014 19:28, Lee Jones wrote:
>>> This patch introduces preliminary support for the X-Powers AXP221 PMIC.
>>> The AXP221 is typically used on boards using Allwinner's A31 SoC.
>>>
>>> At the moment, this driver only exposes regulator devices, but other
>>> subdevices.
>>>
>>> Signed-off-by: Boris BREZILLON 
>>> ---
>>>  drivers/mfd/Kconfig|  12 +++
>>>  drivers/mfd/Makefile   |   1 +
>>>  drivers/mfd/axp22x.c   | 237 
>>> +
>>>  include/linux/mfd/axp22x.h | 149 
>>>  4 files changed, 399 insertions(+)
>>>  create mode 100644 drivers/mfd/axp22x.c
>>>  create mode 100644 include/linux/mfd/axp22x.h
>> Not a chance.
>>
>> Fa, too much common code with axp20x.c - please merge into one file.
>>
> 
> This was one of the questions I asked in my cover letter (could you take
> a look at it and tell me what's your prefered solution ?) ;-).
> 
> I first tried to reuse the axp20x drivers, but ended up copying almost
> all definitions, hence I decided to first do a different driver and ask
> for advices.

I've just taken a good look at this (I'm planning on doing an axp152 driver
myself), and it seems that using a single mfd driver for the 20x and 221 should
be quite feasible:

- axp20x.h would get some new register defines for registers which are
  different (or unique) to the 221 prefixed with aXP221
- An axp20x_writeable_ranges would need
  to be extended with a third range going from AXP221_BAT_CAP1 (0xe0)
  to AXP221_BAT_LOW_THRESH (0xe6)
- axp20x_writeable_table would get .n_yes_ranges set to 2, and a new
  apx22x_writeable_table would be introduced with n_yes_ranges set to 3.
- add a new axp221_supplies array
- add a new axp221_cells array
- and finally use the proper structs in axp20x_i2c_probe depending on the type

Note that this means sharing ie the interrupt table, which is ok since they
are the same, except that the 221 has a couple of interrupts missing, but
the ones which are shared are all at the same place.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] module: static checker complains about negative values

[Dan Carpenter]

On Tue, May 20, 2014 at 11:16:04AM +0930, Rusty Russell wrote:
> Dan Carpenter  writes:
> 
> > We cap "stat.size" at INT_MAX but we don't check for negative values so
> > my static checker complains.  At this point, you already have control of
> > the kernel and if you start passing negative values here then you
> > deserve what happens next.
> >
> > On 64 bit systems the vmalloc() will definitely fail.  On 32 bit systems
> > we truncate the upper 32 bits away so that could succeed.  I haven't
> > followed it further than that.
> >
> > Signed-off-by: Dan Carpenter 
> 
> If vfs_getattr() returns a negative stat.size, we have worse problems.
> 
> I'd rather see you sprinkle assertions like that into the code, so we
> can make sure that can't happen for any fs's getattr().

Yeah.  I was lazy.  Sorry.  I can just hand edit my database to say that
i_size_read() returns a reasonable number...

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: serial console on rb532 disabled on boot (linux 3.15rc5)

[Waldemar Brodkorb]

Hi Geert,
Geert Uytterhoeven wrote,

> Hi Waldemar,
> 
> On Fri, May 16, 2014 at 3:49 PM, Waldemar Brodkorb  wrote:
> > I am trying to bootup my Mikrotik RB532 board with the latest
> > kernel, but my serial console is disabled after boot:
> > ..
> > Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> > serial8250: ttyS0 at MMIO 0x0 (irq = 104, base_baud = 12499875) is a
> > 16550A
> > console [ttyS0] enabled
> > console [ttyS0] disabled
> >
> > I used git bisect to find the problematic commit:
> > commit 5f5c9ae56c38942623f69c3e6dc6ec78e4da2076
> > Author: Geert Uytterhoeven 
> > Date:   Fri Feb 28 14:21:32 2014 +0100
> >
> > serial_core: Unregister console in uart_remove_one_port()
> >
> > If the serial port being removed is used as a console, it must
> > also be
> > unregistered from the console subsystem using
> > unregister_console().
> >
> > uart_ops.release_port() will release resources (e.g. iounmap()
> > the serial
> > port registers), causing a crash on subsequent kernel output if
> > the console
> > is still registered.
> >
> > Signed-off-by: Geert Uytterhoeven 
> > Signed-off-by: Greg Kroah-Hartman 
> >
> > After reverting the change, everything is fine.
> 
> Does this patch help? https://lkml.org/lkml/2014/5/10/9

The second change in printk.c didn't help.
 
> I guess you're not using of_serial?

No, I am not.

> Your serial driver may need to set port.type too, if it doesn't already do so
> and the type is PORT_UNKNOWN on re-registration.

Tried following patch, but it didn't work:

diff -Nur linux-3.15-rc5.orig/arch/mips/rb532/serial.c
linux-3.15-rc5/arch/mips/rb532/serial.c
--- linux-3.15-rc5.orig/arch/mips/rb532/serial.c2014-05-09
22:10:52.0 +0200
+++ linux-3.15-rc5/arch/mips/rb532/serial.c 2014-05-19
20:35:08.0 +0200
@@ -37,7 +37,7 @@
 extern unsigned int idt_cpu_freq;
 
 static struct uart_port rb532_uart = {
-   .flags = UPF_BOOT_AUTOCONF,
+   .type = PORT_16550A,
.line = 0,
.irq = UART0_IRQ,
.iotype = UPIO_MEM,
diff -Nur linux-3.15-rc5.orig/kernel/printk/printk.c
linux-3.15-rc5/kernel/printk/printk.c
--- linux-3.15-rc5.orig/kernel/printk/printk.c  2014-05-09
22:10:52.0 +0200
+++ linux-3.15-rc5/kernel/printk/printk.c   2014-05-20
09:39:54.0 +0200
@@ -2413,6 +2413,7 @@
if (console_drivers != NULL && console->flags & CON_CONSDEV)
console_drivers->flags |= CON_CONSDEV;
 
+   console->flags &= ~CON_ENABLED;
console_unlock();
console_sysfs_notify();
return res;


best regards
Waldemar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drm/qxl: return IRQ_NONE if it was not our irq

[Amos Kong]

On Mon, May 12, 2014 at 04:35:39PM +0800, Jason Wang wrote:
> Return IRQ_NONE if it was not our irq. This is necessary for the case
> when qxl is sharing irq line with a device A in a crash kernel. If qxl
> is initialized before A and A's irq was raised during this gap,
> returning IRQ_HANDLED in this case will cause this irq to be raised
> again after EOI since kernel think it was handled but in fact it was
> not.
> 
> Cc: Gerd Hoffmann 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jason Wang 
> ---
>  drivers/gpu/drm/qxl/qxl_irq.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/qxl/qxl_irq.c b/drivers/gpu/drm/qxl/qxl_irq.c
> index 28f84b4..3485bdc 100644
> --- a/drivers/gpu/drm/qxl/qxl_irq.c
> +++ b/drivers/gpu/drm/qxl/qxl_irq.c
> @@ -33,6 +33,9 @@ irqreturn_t qxl_irq_handler(int irq, void *arg)
>  
>   pending = xchg(&qdev->ram_header->int_pending, 0);
>  
> + if (!pending)
> + return IRQ_NONE;
> +

Looks correct.

Revewed-by: Amos Kong 

>   atomic_inc(&qdev->irq_received);
>  
>   if (pending & QXL_INTERRUPT_DISPLAY) {
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Amos.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] spi: atmel: fix typo in dev_err

[Nicolas Ferre]

On 20/05/2014 09:41, Raphaël Poggi :
> Fix typo in dev_err.
> 
> Signed-off-by: Raphaël Poggi 

Acked-by: Nicolas Ferre 

> ---
>  drivers/spi/spi-atmel.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
> index 079e6b1..7a1788b 100644
> --- a/drivers/spi/spi-atmel.c
> +++ b/drivers/spi/spi-atmel.c
> @@ -1122,7 +1122,7 @@ static int atmel_spi_one_transfer(struct spi_master 
> *master,
>   atmel_spi_lock(as);
>   if (WARN_ON(ret == 0)) {
>   dev_err(&spi->dev,
> - "spi trasfer timeout, err %d\n", ret);
> + "spi transfer timeout, err %d\n", ret);
>   as->done_status = -EIO;
>   } else {
>   ret = 0;
> 


-- 
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] ptrace: Clarify PTRACE_GETREGSET/PTRACE_SETREGSET, documentation in uapi header

[Anshuman Khandual]

On 05/14/2014 04:24 PM, Pedro Alves wrote:
> On 05/14/14 08:10, Anshuman Khandual wrote:
>> On 05/13/2014 11:39 PM, Pedro Alves wrote:
>>> On 05/05/14 05:10, Anshuman Khandual wrote:
 On 05/01/2014 07:43 PM, Pedro Alves wrote:
>>> OK, then this is what I suggest instead:
> ...
 Shall I resend the patch with the your proposed changes and your 
 "Signed-off-by" and
 moving myself as "Reported-by" ?
>>>
>>> No idea of the actual policy to follow.  Feel free to do that if that's the
>>> standard procedure.
>>
>> Even I am not sure about this, so to preserve the correct authorship, would 
>> you
>> mind sending this patch ?
> 
> Here you go.  This is against current Linus'.  Please take it from
> here if necessary.

Thanks Pedro for the patch. I would assume that the ptrace maintainer (Roland 
or Oleg as
mentioned in the MAINTAINERS file) will pick it from here and merge mainline. 
Please do
let me know if the process is otherwise different. Thanks.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the dma-buf tree

[Maarten Lankhorst]

Hey,

op 20-05-14 09:13, Stephen Rothwell schreef:

Hi Sumit,

After merging the dma-buf tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/gpu/drm/tegra/gem.c: In function 'tegra_gem_prime_export':
drivers/gpu/drm/tegra/gem.c:423:15: error: macro "dma_buf_export" requires 5 
arguments, but only 4 given
drivers/gpu/drm/tegra/gem.c:422:9: error: 'dma_buf_export' undeclared (first 
use in this function)

Caused by commit 8dfb1f0f8103 ("dma-buf: use reservation objects").
Grep is your friend ...

I have use the dma-buf tree from next-20140519 for today.


sumits can you amend the commit?
---

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index bcf9895cef9f..1e9de41a14ea 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -419,7 +419,7 @@ struct dma_buf *tegra_gem_prime_export(struct drm_device 
*drm,
   int flags)
 {
return dma_buf_export(gem, &tegra_gem_prime_dmabuf_ops, gem->size,
- flags);
+ flags, NULL);
 }
 
 struct drm_gem_object *tegra_gem_prime_import(struct drm_device *drm,


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 2/2] staging: slicoss: fail on corrupt eeprom

[Dan Carpenter]

Now, those are some beautiful changelogs.  ;)  Thanks so much.

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 6/6] ARM: dts: STiH407: Add B2120 board support

[Maxime Coquelin]

Hi Olof,

On 05/20/2014 08:18 AM, Olof Johansson wrote:

Hi,

Just a quick drive-by review since I was looking at these patches in
the pull request you sent.





Thanks for the review.
I will send a new series taking your comments into account, except the 
one about reference-based syntax.


[...]



diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 12455cf..f760a88 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -317,7 +317,8 @@ dtb-$(CONFIG_ARCH_SPEAR6XX)+= spear600-evb.dtb
  dtb-$(CONFIG_ARCH_STI)+= stih415-b2000.dtb \
 stih416-b2000.dtb \
 stih415-b2020.dtb \
-   stih416-b2020.dtb
+   stih416-b2020.dtb \
+   stih407-b2120.dtb


These should be in alphanumerical order. 407 comes before 415. You've
been out of order with others as well.


Ok, it will be re-ordered in the next series.




  dtb-$(CONFIG_ARCH_SUNXI) += \
 sun4i-a10-a1000.dtb \
 sun4i-a10-cubieboard.dtb \
diff --git a/arch/arm/boot/dts/stih407-b2120.dts 
b/arch/arm/boot/dts/stih407-b2120.dts
new file mode 100644
index 000..9c97da4
--- /dev/null
+++ b/arch/arm/boot/dts/stih407-b2120.dts
@@ -0,0 +1,78 @@
+/*
+ * Copyright (C) 2014 STMicroelectronics (R&D) Limited.
+ * Author: Giuseppe Cavallaro 
+ *
+ * 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.
+ */
+/dts-v1/;
+#include "stih407.dtsi"
+/ {
+   model = "STiH407 B2120";
+   compatible = "st,stih407", "st,stih407-b2120";


This should go from specific to generic, so the order needs to be the other way.

Please check other dts files for the same (I didn't).



Ok, I will change that for this dts and also the other ones.
Thanks,
Maxime


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [STLinux Kernel] [PATCH 3/4] ARM: DT: STi: Add DT node for MiPHY365x

[Lee Jones]

> >>>The MiPHY365x is a Generic PHY which can serve various SATA or PCIe
> >>>devices. It has 2 ports which it can use for either; both SATA, both
> >>>PCIe or one of each in any configuration.
> >>>
> >>>Cc: Srinivas Kandagatla 
> >>>Acked-by: Mark Rutland 
> >>>Acked-by: Alexandre Torgue 
> >>>Signed-off-by: Lee Jones 
> >>>---
> >>>  arch/arm/boot/dts/stih416-b2020-revE.dts | 22 ++
> >>>  arch/arm/boot/dts/stih416-b2020.dts  |  6 ++
> >>>  arch/arm/boot/dts/stih416.dtsi   | 14 ++
> >>>  3 files changed, 42 insertions(+)
> >>>  create mode 100644 arch/arm/boot/dts/stih416-b2020-revE.dts
> >>>
> >>>diff --git a/arch/arm/boot/dts/stih416-b2020-revE.dts 
> >>>b/arch/arm/boot/dts/stih416-b2020-revE.dts
> >>>new file mode 100644
> >>>index 000..23fdaf7
> >>>--- /dev/null
> >>>+++ b/arch/arm/boot/dts/stih416-b2020-revE.dts
> >>>@@ -0,0 +1,22 @@
> >>>+/*
> >>>+ * Copyright (C) 2014 STMicroelectronics Limited.
> >>>+ * Author: Lee Jones 
> >>>+ *
> >>>+ * 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
> >>>+ * publishhed by the Free Software Foundation.
> >>>+ */
> >>>+/dts-v1/;
> >>>+#include "stih416.dtsi"
> >>>+#include "stih41x-b2020.dtsi"
> >>>+/ {
> >>>+model = "STiH416 B2020 REV-E";
> >>>+  compatible = "st,stih416-b2020", "st,stih416";
> >>>+
> >>>+  soc {
> >>>+  miphy365x_phy: miphy365x@fe382000 {
> >>>+  st,pcie-tx-pol-inv;
> >>>+  st,sata-gen = <3>;
> >>>+  };
> >>>+  };
> >>>+};
> >>Shouldn't this new board being added in a separate patch?
> >
> >I certainly can do that, but I don't think that it's necessary?
> 
> I think it is, as you introduce a new board.

Introducing an empty dts file just so you can say "this is a new
board" seems odd to me, but I'll go with whatever you feel it right.

> Moreover, the miphy description being the same as in
> stih416-b2020.dts, so I don't understand why you introduce this
> board for this feature.

It's historical.  There are other differences between rev-E and the
other reversions, such as; gpio-leds (red, green) and the reset GPIO
for ethernet.  As these are dts files (rather than dtsi) files, you
can only use one at a time.

> >>>diff --git a/arch/arm/boot/dts/stih416-b2020.dts 
> >>>b/arch/arm/boot/dts/stih416-b2020.dts
> >>>index 276f28d..172f222 100644
> >>>--- a/arch/arm/boot/dts/stih416-b2020.dts
> >>>+++ b/arch/arm/boot/dts/stih416-b2020.dts
> >>>@@ -13,4 +13,10 @@
> >>>   model = "STiH416 B2020";
> >>>   compatible = "st,stih416", "st,stih416-b2020";
> >>>
> >>>+  soc {
> >>>+  miphy365x_phy: miphy365x@fe382000 {
> >>>+  st,pcie-tx-pol-inv;
> >>>+  st,sata-gen = <3>;
> >>>+  };
> >>>+  };
> >>>  };
> >>...
> >

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] arm: dma-mapping: fallback allocation for cma failure

[Joonsoo Kim]

On Tue, May 20, 2014 at 04:05:52PM +0900, Gioh Kim wrote:
> That case, device-specific coherent memory allocation, is handled at 
> dma_alloc_coherent in arm_dma_alloc.
> __dma_alloc handles only general coherent memory allocation.
> 
> I'm sorry missing mention about it.
> 

Hello,

AFAIK, *coherent* memory allocation is different with *contiguous* memory
allocation(CMA). So we need to handle the case I mentioned.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] gpio: Add support for Intel SoC PMIC (Crystal Cove)

[Mika Westerberg]

On Mon, May 19, 2014 at 01:39:33PM +0300, Mika Westerberg wrote:
> On Wed, May 14, 2014 at 11:44:07PM +0800, Zhu, Lejun wrote:
> > Devices based on Intel SoC products such as Baytrail have a Power
> > Management IC. In the PMIC there are subsystems for voltage regulation,
> > A/D conversion, GPIO and PWMs. The PMIC in Baytrail-T platform is called
> > Crystal Cove.
> > 
> > This patch adds support for the GPIO function in Crystal Cove.
> 
> I have few comments as well in addition to comments from Linus and
> Alexandre.

One more thing, I just remembered. The crystal cove GPIO driver is
supposed to provide ACPI Operation Regions to the ASL code so you need
to make sure you have ACPI handle associated with the device before you
register your driver to the GPIO core.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] staging: ozwpan: Change Maintainer

[Tateno, Tateno]

Hi Greg,

Please accept this as the acknowledgment to your reply.
I will take over ozwpan maintainer role from Rupesh.

Thanks

Tateno

From: Greg KH [gre...@linuxfoundation.org]
Sent: 20 May 2014 02:29
To: Gujare, Rupesh
Cc: de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org; Tateno, Tateno
Subject: Re: [PATCH] staging: ozwpan: Change Maintainer

On Mon, May 19, 2014 at 03:17:30PM +0100, Rupesh Gujare wrote:
> I will be not able to work on ozwpan driver anymore.
> Remove my name & add Tateno as maintainer.
>
> Signed-off-by: Rupesh Gujare 
> ---
>  MAINTAINERS |2 +-
>  drivers/staging/ozwpan/TODO |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0de64a5..3a9e4d83 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8466,7 +8466,7 @@ S:  Maintained
>  F:   drivers/staging/olpc_dcon/
>
>  STAGING - OZMO DEVICES USB OVER WIFI DRIVER
> -M:   Rupesh Gujare 
> +M:   Shigekatsu Tateno 

Can I get an "ack" from Shigekatsu?  I don't like adding someone as a
maintainer if they don't know about it...

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] mtd: delete unneeded call to platform_get_drvdata

[Brian Norris]

+ Mike

On Sat, May 17, 2014 at 03:12:02PM +0800, Julia Lawall wrote:
> On Sat, 17 May 2014, Fabio Estevam wrote:
> > On Sat, May 17, 2014 at 3:32 AM, Julia Lawall  wrote:
> > > From: Julia Lawall 
> > >
> > > Platform_get_drvdata is an accessor function, and has no purpose if its
> > > result is not used.
> > >
> > > The semantic patch that fixes this problem is as follows:
> > > (http://coccinelle.lip6.fr/)
> > >
> > > // 
> > > @@
> > > identifier x;
> > > type T;
> > > @@
> > > - T x = platform_get_drvdata(...);
> > > ... when != x
> > > // 
> > >
> > > Signed-off-by: Julia Lawall 
> > >
> > > ---
> > >  drivers/mtd/nand/bf5xx_nand.c |4 
> > >  1 file changed, 4 deletions(-)
> > >
> > > diff --git a/drivers/mtd/nand/bf5xx_nand.c b/drivers/mtd/nand/bf5xx_nand.c
> > > index b7a2494..b5fbd48 100644
> > > --- a/drivers/mtd/nand/bf5xx_nand.c
> > > +++ b/drivers/mtd/nand/bf5xx_nand.c
> > > @@ -840,15 +840,11 @@ out_err_kzalloc:
> > >
> > >  static int bf5xx_nand_suspend(struct platform_device *dev, pm_message_t 
> > > pm)
> > >  {
> > > -   struct bf5xx_nand_info *info = platform_get_drvdata(dev);
> > > -
> > > return 0;
> > >  }
> > >
> > >  static int bf5xx_nand_resume(struct platform_device *dev)
> > >  {
> > > -   struct bf5xx_nand_info *info = platform_get_drvdata(dev);
> > > -
> > > return 0;
> >
> > In this case bf5xx_nand_suspend/resume could be removed?
> 
> I don't know.  It looks like it is intentional to have a definition that
> returns an indication of success?  The complete set of definitions is:

I'm not so sure. I believe suspend/resume works just fine without the
hooks, if those hooks would otherwise be doing nothing. It is notable
that this driver is not using the modern dev_pm_ops form of the
suspend/resume callbacks, so maybe it just hasn't aged gracefully--and
possibly was never supported properly in the first place.

I'll either take this patch as-is, or look to killing off the
suspend/resume callbacks entirely here, depending on Mike's feedback.

> #ifdef CONFIG_PM
> 
> static int bf5xx_nand_suspend(struct platform_device *dev, pm_message_t
> pm)
> {
> struct bf5xx_nand_info *info = platform_get_drvdata(dev);
> 
>   return 0;
> }
> 
> static int bf5xx_nand_resume(struct platform_device *dev)
> {
> struct bf5xx_nand_info *info = platform_get_drvdata(dev);
> 
> return 0;
> }
> 
> #else
> #define bf5xx_nand_suspend NULL
> #define bf5xx_nand_resume NULL
> #endif

Thanks,
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: serial console on rb532 disabled on boot (linux 3.15rc5)

[Geert Uytterhoeven]

Hi Waldemar,

On Tue, May 20, 2014 at 10:21 AM, Waldemar Brodkorb  wrote:
> Geert Uytterhoeven wrote,
>> On Fri, May 16, 2014 at 3:49 PM, Waldemar Brodkorb  wrote:
>> > I am trying to bootup my Mikrotik RB532 board with the latest
>> > kernel, but my serial console is disabled after boot:
>> > ..
>> > Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
>> > serial8250: ttyS0 at MMIO 0x0 (irq = 104, base_baud = 12499875) is a
>> > 16550A
>> > console [ttyS0] enabled
>> > console [ttyS0] disabled
>> >
>> > I used git bisect to find the problematic commit:
>> > commit 5f5c9ae56c38942623f69c3e6dc6ec78e4da2076
>> > Author: Geert Uytterhoeven 
>> > Date:   Fri Feb 28 14:21:32 2014 +0100
>> >
>> > serial_core: Unregister console in uart_remove_one_port()
>> >
>> > If the serial port being removed is used as a console, it must
>> > also be
>> > unregistered from the console subsystem using
>> > unregister_console().
>> >
>> > uart_ops.release_port() will release resources (e.g. iounmap()
>> > the serial
>> > port registers), causing a crash on subsequent kernel output if
>> > the console
>> > is still registered.
>> >
>> > Signed-off-by: Geert Uytterhoeven 
>> > Signed-off-by: Greg Kroah-Hartman 
>> >
>> > After reverting the change, everything is fine.
>>
>> Does this patch help? https://lkml.org/lkml/2014/5/10/9
>
> The second change in printk.c didn't help.

>> Your serial driver may need to set port.type too, if it doesn't already do so
>> and the type is PORT_UNKNOWN on re-registration.
>
> Tried following patch, but it didn't work:
>
> diff -Nur linux-3.15-rc5.orig/arch/mips/rb532/serial.c
> linux-3.15-rc5/arch/mips/rb532/serial.c
> --- linux-3.15-rc5.orig/arch/mips/rb532/serial.c2014-05-09
> 22:10:52.0 +0200
> +++ linux-3.15-rc5/arch/mips/rb532/serial.c 2014-05-19
> 20:35:08.0 +0200
> @@ -37,7 +37,7 @@
>  extern unsigned int idt_cpu_freq;
>
>  static struct uart_port rb532_uart = {
> -   .flags = UPF_BOOT_AUTOCONF,
> +   .type = PORT_16550A,

I'm afraid this is not gonna help. When the port is unregistered, its
type will be reset to PORT_UNKNOWN.
So before registering it again, its type must be set againin the actual
serial driver, cfr. the change to of_serial.c.

> .line = 0,
> .irq = UART0_IRQ,
> .iotype = UPIO_MEM,
> diff -Nur linux-3.15-rc5.orig/kernel/printk/printk.c
> linux-3.15-rc5/kernel/printk/printk.c
> --- linux-3.15-rc5.orig/kernel/printk/printk.c  2014-05-09
> 22:10:52.0 +0200
> +++ linux-3.15-rc5/kernel/printk/printk.c   2014-05-20
> 09:39:54.0 +0200
> @@ -2413,6 +2413,7 @@
> if (console_drivers != NULL && console->flags & CON_CONSDEV)
> console_drivers->flags |= CON_CONSDEV;
>
> +   console->flags &= ~CON_ENABLED;
> console_unlock();
> console_sysfs_notify();
> return res;

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [STLinux Kernel] [PATCH 3/4] ARM: DT: STi: Add DT node for MiPHY365x

[Maxime Coquelin]

On 05/20/2014 10:28 AM, Lee Jones wrote:

The MiPHY365x is a Generic PHY which can serve various SATA or PCIe
devices. It has 2 ports which it can use for either; both SATA, both
PCIe or one of each in any configuration.

Cc: Srinivas Kandagatla 
Acked-by: Mark Rutland 
Acked-by: Alexandre Torgue 
Signed-off-by: Lee Jones 
---
  arch/arm/boot/dts/stih416-b2020-revE.dts | 22 ++
  arch/arm/boot/dts/stih416-b2020.dts  |  6 ++
  arch/arm/boot/dts/stih416.dtsi   | 14 ++
  3 files changed, 42 insertions(+)
  create mode 100644 arch/arm/boot/dts/stih416-b2020-revE.dts

diff --git a/arch/arm/boot/dts/stih416-b2020-revE.dts 
b/arch/arm/boot/dts/stih416-b2020-revE.dts
new file mode 100644
index 000..23fdaf7
--- /dev/null
+++ b/arch/arm/boot/dts/stih416-b2020-revE.dts
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2014 STMicroelectronics Limited.
+ * Author: Lee Jones 
+ *
+ * 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
+ * publishhed by the Free Software Foundation.
+ */
+/dts-v1/;
+#include "stih416.dtsi"
+#include "stih41x-b2020.dtsi"
+/ {
+model = "STiH416 B2020 REV-E";
+   compatible = "st,stih416-b2020", "st,stih416";
+
+   soc {
+   miphy365x_phy: miphy365x@fe382000 {
+   st,pcie-tx-pol-inv;
+   st,sata-gen = <3>;
+   };
+   };
+};

Shouldn't this new board being added in a separate patch?


I certainly can do that, but I don't think that it's necessary?


I think it is, as you introduce a new board.


Introducing an empty dts file just so you can say "this is a new
board" seems odd to me, but I'll go with whatever you feel it right.


Moreover, the miphy description being the same as in
stih416-b2020.dts, so I don't understand why you introduce this
board for this feature.


It's historical.  There are other differences between rev-E and the
other reversions, such as; gpio-leds (red, green) and the reset GPIO
for ethernet.  As these are dts files (rather than dtsi) files, you
can only use one at a time.


My point was to create a new patch that would also introduce the 
differences (Ethernet, leds...). The commit message would explain the 
differences versus stih416-b2020.


From your patch, if I didn't know the differences, I would ask why you 
don't use stih416-b2020.dts.


If you have another pending patch that make Ethernet to work on revE 
board, you can keep this one as it is.





diff --git a/arch/arm/boot/dts/stih416-b2020.dts 
b/arch/arm/boot/dts/stih416-b2020.dts
index 276f28d..172f222 100644
--- a/arch/arm/boot/dts/stih416-b2020.dts
+++ b/arch/arm/boot/dts/stih416-b2020.dts
@@ -13,4 +13,10 @@
model = "STiH416 B2020";
compatible = "st,stih416", "st,stih416-b2020";

+   soc {
+   miphy365x_phy: miphy365x@fe382000 {
+   st,pcie-tx-pol-inv;
+   st,sata-gen = <3>;
+   };
+   };
  };

...





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] m32r: remove checks for a few processor family macros

[Paul Bolle]

Ever since m32r got added in v2.6.9 there have been checks for
CONFIG_CHIP_M32310
CONFIG_CHIP_MP
CONFIG_CHIP_XNUX2
CONFIG_CHIP_XNUX2_MP
CONFIG_CHIP_XNUX_MP

But the Kconfig symbols for these processor families have never been
added. Remove these checks. Also remove a header that now is not
mentioned anymore (the #include involved wasn't used anyway).

Signed-off-by: Paul Bolle 
---
Eyeball tested only!

 arch/m32r/boot/compressed/head.S |   2 -
 arch/m32r/boot/setup.S   |   7 +-
 arch/m32r/include/asm/m32r.h |   4 +-
 arch/m32r/include/asm/m32r_mp_fpga.h | 313 ---
 arch/m32r/kernel/head.S  |   2 -
 arch/m32r/kernel/setup.c |   5 +-
 arch/m32r/kernel/time.c  |   8 +-
 arch/m32r/mm/cache.c |   2 +-
 8 files changed, 6 insertions(+), 337 deletions(-)
 delete mode 100644 arch/m32r/include/asm/m32r_mp_fpga.h

diff --git a/arch/m32r/boot/compressed/head.S b/arch/m32r/boot/compressed/head.S
index 95a0563ff076..e2ecab840aeb 100644
--- a/arch/m32r/boot/compressed/head.S
+++ b/arch/m32r/boot/compressed/head.S
@@ -73,10 +73,8 @@ startup:
srlir4, #4  ||  addir2, #-4
beqzr4, .Lendloop1
 .Lloop1:
-#ifndef CONFIG_CHIP_M32310
; Touch memory for the no-write-allocating cache.
ld  r0, @(4,r2)
-#endif
st  r1, @+r2||  addir4, #-1
st  r1, @+r2
st  r1, @+r2
diff --git a/arch/m32r/boot/setup.S b/arch/m32r/boot/setup.S
index ef843d63083d..ce5049babecc 100644
--- a/arch/m32r/boot/setup.S
+++ b/arch/m32r/boot/setup.S
@@ -62,12 +62,7 @@
 ENTRY(boot)
 
 /* Set cache mode */
-#if defined(CONFIG_CHIP_XNUX2)
-   ldi r0, #-2  ;LDIMM (r0, M32R_MCCR)
-   ldi r1, #0x0101 ; cache on (with invalidation)
-;  ldi r1, #0x00   ; cache off
-   sth r1, @r0
-#elif defined(CONFIG_CHIP_M32700) || defined(CONFIG_CHIP_VDEC2) \
+#if defined(CONFIG_CHIP_M32700) || defined(CONFIG_CHIP_VDEC2) \
 || defined(CONFIG_CHIP_OPSP)
ldi r0, #-4  ;LDIMM (r0, M32R_MCCR)
ldi r1, #0x73   ; cache on (with invalidation)
diff --git a/arch/m32r/include/asm/m32r.h b/arch/m32r/include/asm/m32r.h
index 38fa946d1ebf..b12766cf2976 100644
--- a/arch/m32r/include/asm/m32r.h
+++ b/arch/m32r/include/asm/m32r.h
@@ -9,9 +9,7 @@
 

 /* Chip type */
-#if defined(CONFIG_CHIP_XNUX_MP) || defined(CONFIG_CHIP_XNUX2_MP)
-#include 
-#elif defined(CONFIG_CHIP_VDEC2) || defined(CONFIG_CHIP_XNUX2) \
+#if defined(CONFIG_CHIP_VDEC2) \
|| defined(CONFIG_CHIP_M32700) || defined(CONFIG_CHIP_M32102) \
 || defined(CONFIG_CHIP_OPSP) || defined(CONFIG_CHIP_M32104)
 #include 
diff --git a/arch/m32r/include/asm/m32r_mp_fpga.h 
b/arch/m32r/include/asm/m32r_mp_fpga.h
deleted file mode 100644
index 976d2b995919..
--- a/arch/m32r/include/asm/m32r_mp_fpga.h
+++ /dev/null
@@ -1,313 +0,0 @@
-#ifndef _ASM_M32R_M32R_MP_FPGA_
-#define _ASM_M32R_M32R_MP_FPGA_
-
-/*
- * Renesas M32R-MP-FPGA
- *
- * Copyright (c) 2002  Hitoshi Yamamoto
- * Copyright (c) 2003, 2004  Renesas Technology Corp.
- */
-
-/*
- * 
- * M32R-MP-FPGA Memory Map
- * 
- * 0x : Block#0 : 64[MB]
- *  0x03E0 : SFR
- *   0x03E0 : reserved
- *   0x03EF : FPGA
- *   0x03EF1000 : reserved
- *   0x03EF4000 : CKM
- *   0x03EF4000 : BSELC
- *   0x03EF5000 : reserved
- *   0x03EFC000 : MFT
- *   0x03EFD000 : SIO
- *   0x03EFE000 : reserved
- *   0x03EFF000 : ICU
- *  0x03F0 : Internal SRAM 64[KB]
- *  0x03F1 : reserved
- * 
- * 0x0400 : Block#1 : 64[MB]
- *  0x0400 : Debug board SRAM 4[MB]
- *  0x0440 : reserved
- * 
- * 0x0800 : Block#2 : 64[MB]
- * 
- * 0x0C00 : Block#3 : 64[MB]
- * 
- * 0x1000 : Block#4 : 64[MB]
- * 
- * 0x1400 : Block#5 : 64[MB]
- * 
- * 0x1800 : Block#6 : 64[MB]
- * 
- * 0x1C00 : Block#7 : 64[MB]
- * 
- * 0xFE00 : TLB
- *  0xFE00 : ITLB
- *  0xFE80 : reserved
- *  0xFE000800 : DTLB
- *

Re: [PATCH v3 6/7] i2c: ChromeOS EC tunnel driver

[Lee Jones]

> > > Code looks good, so
> > > 
> > > Reviewed-by: Wolfram Sang 
> > > 
> > > I don't mind how it gets upstream. I can take it, but you can also keep
> > > it in this series.
> > 
> > Let's keep the series together.  Are you happy with me just merging it
> > through MFD, or would you like a pull-request, so you can take it in
> > too?
> 
> Just merge it...

Thanks dude.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/7] mfd: cros_ec: spi: calculate delay between transfers correctly

[Lee Jones]

> From: David Hendricks 
> 
> To avoid spamming the EC we calculate the time between the previous
> transfer and the current transfer and force a delay if the time delta
> is too small.
> 
> However, a small miscalculation causes the delay period to be
> far too short. Most noticably this impacts commands with a long
> turnaround time such as EC firmware reads and writes.
> 
> Signed-off-by: David Hendricks 
> Signed-off-by: Doug Anderson 
> Acked-by: Lee Jones 
> Reviewed-by: Simon Glass 
> Tested-by: Andrew Bresticker 
> Tested-by: Stephen Warren 
> ---
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/mfd/cros_ec_spi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

> diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
> index 84af8d7..c185eb6 100644
> --- a/drivers/mfd/cros_ec_spi.c
> +++ b/drivers/mfd/cros_ec_spi.c
> @@ -219,7 +219,7 @@ static int cros_ec_command_spi_xfer(struct cros_ec_device 
> *ec_dev,
>   ktime_get_ts(&ts);
>   delay = timespec_to_ns(&ts) - ec_spi->last_transfer_ns;
>   if (delay < EC_SPI_RECOVERY_TIME_NS)
> - ndelay(delay);
> + ndelay(EC_SPI_RECOVERY_TIME_NS - delay);
>   }
>  
>   /* Transmit phase - send our message */

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 2/7] mfd: cros_ec: spi: Add mutex to cros_ec_spi

[Lee Jones]

On Wed, 30 Apr 2014, Doug Anderson wrote:

> The main transfer function for cros_ec_spi can be called by more than
> one client at a time.  Make sure that those clients don't stomp on
> each other by locking the bus for the duration of the transfer
> function.
> 
> Signed-off-by: Doug Anderson 
> Acked-by: Lee Jones 
> Reviewed-by: Simon Glass 
> Tested-by: Andrew Bresticker 
> Tested-by: Stephen Warren 
> ---
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/mfd/cros_ec_spi.c | 26 +-
>  1 file changed, 21 insertions(+), 5 deletions(-)

Applied, thanks.
 
> diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
> index c185eb6..a2a605d 100644
> --- a/drivers/mfd/cros_ec_spi.c
> +++ b/drivers/mfd/cros_ec_spi.c
> @@ -65,11 +65,13 @@
>   *   if no record
>   * @end_of_msg_delay: used to set the delay_usecs on the spi_transfer that
>   *  is sent when we want to turn off CS at the end of a transaction.
> + * @lock: mutex to ensure only one user of cros_ec_command_spi_xfer at a time
>   */
>  struct cros_ec_spi {
>   struct spi_device *spi;
>   s64 last_transfer_ns;
>   unsigned int end_of_msg_delay;
> + struct mutex lock;
>  };
>  
>  static void debug_packet(struct device *dev, const char *name, u8 *ptr,
> @@ -208,6 +210,13 @@ static int cros_ec_command_spi_xfer(struct 
> cros_ec_device *ec_dev,
>   int ret = 0, final_ret;
>   struct timespec ts;
>  
> + /*
> +  * We have the shared ec_dev buffer plus we do lots of separate spi_sync
> +  * calls, so we need to make sure only one person is using this at a
> +  * time.
> +  */
> + mutex_lock(&ec_spi->lock);
> +
>   len = cros_ec_prepare_tx(ec_dev, ec_msg);
>   dev_dbg(ec_dev->dev, "prepared, len=%d\n", len);
>  
> @@ -260,7 +269,7 @@ static int cros_ec_command_spi_xfer(struct cros_ec_device 
> *ec_dev,
>   ret = final_ret;
>   if (ret < 0) {
>   dev_err(ec_dev->dev, "spi transfer failed: %d\n", ret);
> - return ret;
> + goto exit;
>   }
>  
>   /* check response error code */
> @@ -269,14 +278,16 @@ static int cros_ec_command_spi_xfer(struct 
> cros_ec_device *ec_dev,
>   dev_warn(ec_dev->dev, "command 0x%02x returned an error %d\n",
>ec_msg->cmd, ptr[0]);
>   debug_packet(ec_dev->dev, "in_err", ptr, len);
> - return -EINVAL;
> + ret = -EINVAL;
> + goto exit;
>   }
>   len = ptr[1];
>   sum = ptr[0] + ptr[1];
>   if (len > ec_msg->in_len) {
>   dev_err(ec_dev->dev, "packet too long (%d bytes, expected %d)",
>   len, ec_msg->in_len);
> - return -ENOSPC;
> + ret = -ENOSPC;
> + goto exit;
>   }
>  
>   /* copy response packet payload and compute checksum */
> @@ -293,10 +304,14 @@ static int cros_ec_command_spi_xfer(struct 
> cros_ec_device *ec_dev,
>   dev_err(ec_dev->dev,
>   "bad packet checksum, expected %02x, got %02x\n",
>   sum, ptr[len + 2]);
> - return -EBADMSG;
> + ret = -EBADMSG;
> + goto exit;
>   }
>  
> - return 0;
> + ret = 0;
> +exit:
> + mutex_unlock(&ec_spi->lock);
> + return ret;
>  }
>  
>  static void cros_ec_spi_dt_probe(struct cros_ec_spi *ec_spi, struct device 
> *dev)
> @@ -327,6 +342,7 @@ static int cros_ec_spi_probe(struct spi_device *spi)
>   if (ec_spi == NULL)
>   return -ENOMEM;
>   ec_spi->spi = spi;
> + mutex_init(&ec_spi->lock);
>   ec_dev = devm_kzalloc(dev, sizeof(*ec_dev), GFP_KERNEL);
>   if (!ec_dev)
>   return -ENOMEM;

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 0/3] Add support for PCI in AArch64

[Arnd Bergmann]

On Tuesday 20 May 2014 09:52:33 Sunil Kovvuri wrote:
> >> In sriov_enable() (drivers/pci/iov.c)
> >>
> >>  296for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
> >>  297 bars |= (1 << (i + PCI_IOV_RESOURCES));
> >>  298 res = dev->resource + PCI_IOV_RESOURCES + i;
> >>  299 if (res->parent)
> >>  300 nres++;
> >>  301 }
> >>  302 if (nres != iov->nres) {
> >>  303 dev_err(&dev->dev, "not enough MMIO resources for
> >>  SR-IOV\n");
> >>  304 return -ENOMEM;
> >>  305 }
> >>
> >> Here its checking if physical function's IOV resource has a parent or not.
> >> Which is pci-pci bridge in this case. Otherwise it doesn't consider
> >> that resource.
> >>
> >> Added below api to your patch.
> >> This will try to claim a resource while creating a PCI device which
> >> inturn sets 'res->parent'.
> >
> > This looks like the wrong approach. The PCI host controller should
> > really have been registered with the root 'iomem_resource' during
> > the probe of the host controller.
> >
> I didn't get this, if a SR-IOV device is connected to a PCI-PCI bridge
> and inturn bridge connected to root port. Then the parent bus is not root,
> but the bridge.  The issue is either hierarchy should not be checked for
> SR-IOV resources or someone should set the hierarchy (i.e parent resources).

Ah, I misunderstood the problem, I thought the PCI core was complaining
about lack of space in the resources, not about a lack of BARs.

It seems there is code like yours in a couple of architectures, but they
only claim the resources of bridges, not the actual devices as you
seem to be doing. Can you check if the x86 version of
pcibios_allocate_bus_resources() does the trick for you? Maybe we can
turn that into a generic helper.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 3/7] mfd: cros_ec: spi: Make the cros_ec_spi timeout more reliable

[Lee Jones]

On Wed, 30 Apr 2014, Doug Anderson wrote:

> The cros_ec_spi transfer had two problems with its timeout code:
> 
> 1. It looked at the timeout even in the case that it found valid data.
> 2. If the cros_ec_spi code got switched out for a while, it's possible
>it could get a timeout after a single loop.  Let's be paranoid and
>make sure we do one last transfer after the timeout expires.
> 
> Signed-off-by: Doug Anderson 
> Acked-by: Lee Jones 
> Reviewed-by: Simon Glass 
> Tested-by: Andrew Bresticker 
> Tested-by: Stephen Warren 
> ---
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/mfd/cros_ec_spi.c | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
> index a2a605d..4f863c3 100644
> --- a/drivers/mfd/cros_ec_spi.c
> +++ b/drivers/mfd/cros_ec_spi.c
> @@ -113,7 +113,9 @@ static int cros_ec_spi_receive_response(struct 
> cros_ec_device *ec_dev,
>  
>   /* Receive data until we see the header byte */
>   deadline = jiffies + msecs_to_jiffies(EC_MSG_DEADLINE_MS);
> - do {
> + while (true) {
> + unsigned long start_jiffies = jiffies;
> +
>   memset(&trans, 0, sizeof(trans));
>   trans.cs_change = 1;
>   trans.rx_buf = ptr = ec_dev->din;
> @@ -134,12 +136,19 @@ static int cros_ec_spi_receive_response(struct 
> cros_ec_device *ec_dev,
>   break;
>   }
>   }
> + if (ptr != end)
> + break;
>  
> - if (time_after(jiffies, deadline)) {
> + /*
> +  * Use the time at the start of the loop as a timeout.  This
> +  * gives us one last shot at getting the transfer and is useful
> +  * in case we got context switched out for a while.
> +  */
> + if (time_after(start_jiffies, deadline)) {
>   dev_warn(ec_dev->dev, "EC failed to respond in time\n");
>   return -ETIMEDOUT;
>   }
> - } while (ptr == end);
> + }
>  
>   /*
>* ptr now points to the header byte. Copy any valid data to the

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 4/7] mfd: cros_ec: spi: Increase cros_ec_spi deadline from 5ms to 100ms

[Lee Jones]

On Wed, 30 Apr 2014, Doug Anderson wrote:

> We're adding i2c tunneling to the list of things that goes over
> cros_ec.  i2c tunneling can be slooow, so increase our deadline to
> 100ms to account for that.
> 
> Signed-off-by: Doug Anderson 
> Acked-by: Lee Jones 
> Reviewed-by: Simon Glass 
> Tested-by: Andrew Bresticker 
> Tested-by: Stephen Warren 
> ---
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/mfd/cros_ec_spi.c | 24 
>  1 file changed, 16 insertions(+), 8 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
> index 4f863c3..0b8d328 100644
> --- a/drivers/mfd/cros_ec_spi.c
> +++ b/drivers/mfd/cros_ec_spi.c
> @@ -39,14 +39,22 @@
>  #define EC_MSG_PREAMBLE_COUNT32
>  
>  /*
> -  * We must get a response from the EC in 5ms. This is a very long
> -  * time, but the flash write command can take 2-3ms. The EC command
> -  * processing is currently not very fast (about 500us). We could
> -  * look at speeding this up and making the flash write command a
> -  * 'slow' command, requiring a GET_STATUS wait loop, like flash
> -  * erase.
> -  */
> -#define EC_MSG_DEADLINE_MS   5
> + * Allow for a long time for the EC to respond.  We support i2c
> + * tunneling and support fairly long messages for the tunnel (249
> + * bytes long at the moment).  If we're talking to a 100 kHz device
> + * on the other end and need to transfer ~256 bytes, then we need:
> + *  10 us/bit * ~10 bits/byte * ~256 bytes = ~25ms
> + *
> + * We'll wait 4 times that to handle clock stretching and other
> + * paranoia.
> + *
> + * It's pretty unlikely that we'll really see a 249 byte tunnel in
> + * anything other than testing.  If this was more common we might
> + * consider having slow commands like this require a GET_STATUS
> + * wait loop.  The 'flash write' command would be another candidate
> + * for this, clocking in at 2-3ms.
> + */
> +#define EC_MSG_DEADLINE_MS   100
>  
>  /*
>* Time between raising the SPI chip select (for the end of a

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 5/7] mfd: cros_ec: Sync to the latest cros_ec_commands.h from EC sources

[Lee Jones]

On Wed, 30 Apr 2014, Doug Anderson wrote:

> From: Bill Richardson 
> 
> This just updates include/linux/mfd/cros_ec_commands.h to match the
> latest EC version (which is the One True Source for such things).  See
> 
> 
> [dianders: took today's ToT version from the Chromium OS EC; deleted
> references to cros_ec_dev and cros_ec_lpc since those aren't upstream
> yet]
> 
> Signed-off-by: Bill Richardson 
> Signed-off-by: Doug Anderson 
> Acked-by: Lee Jones 
> Reviewed-by: Simon Glass 
> Tested-by: Andrew Bresticker 
> Tested-by: Stephen Warren 
> ---
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/mfd/cros_ec.c|2 +-
>  include/linux/mfd/cros_ec.h  |4 +-
>  include/linux/mfd/cros_ec_commands.h | 1128 
> +++---
>  3 files changed, 1059 insertions(+), 75 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index 783fe2e..c58ab96 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -30,7 +30,7 @@ int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
>   uint8_t *out;
>   int csum, i;
>  
> - BUG_ON(msg->out_len > EC_HOST_PARAM_SIZE);
> + BUG_ON(msg->out_len > EC_PROTO2_MAX_PARAM_SIZE);
>   out = ec_dev->dout;
>   out[0] = EC_CMD_VERSION0 + msg->version;
>   out[1] = msg->cmd;
> diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> index 032af7f..887ef4f 100644
> --- a/include/linux/mfd/cros_ec.h
> +++ b/include/linux/mfd/cros_ec.h
> @@ -29,8 +29,8 @@ enum {
>   EC_MSG_RX_PROTO_BYTES   = 3,
>  
>   /* Max length of messages */
> - EC_MSG_BYTES= EC_HOST_PARAM_SIZE + EC_MSG_TX_PROTO_BYTES,
> -
> + EC_MSG_BYTES= EC_PROTO2_MAX_PARAM_SIZE +
> + EC_MSG_TX_PROTO_BYTES,
>  };
>  
>  /**
> diff --git a/include/linux/mfd/cros_ec_commands.h 
> b/include/linux/mfd/cros_ec_commands.h
> index 86fd069..7853a64 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -24,25 +24,12 @@
>  #define __CROS_EC_COMMANDS_H
>  
>  /*
> - * Protocol overview
> + * Current version of this protocol
>   *
> - * request:  CMD [ P0 P1 P2 ... Pn S ]
> - * response: ERR [ P0 P1 P2 ... Pn S ]
> - *
> - * where the bytes are defined as follow :
> - *  - CMD is the command code. (defined by EC_CMD_ constants)
> - *  - ERR is the error code. (defined by EC_RES_ constants)
> - *  - Px is the optional payload.
> - *it is not sent if the error code is not success.
> - *(defined by ec_params_ and ec_response_ structures)
> - *  - S is the checksum which is the sum of all payload bytes.
> - *
> - * On LPC, CMD and ERR are sent/received at EC_LPC_ADDR_KERNEL|USER_CMD
> - * and the payloads are sent/received at EC_LPC_ADDR_KERNEL|USER_PARAM.
> - * On I2C, all bytes are sent serially in the same message.
> + * TODO(crosbug.com/p/11223): This is effectively useless; protocol is
> + * determined in other ways.  Remove this once the kernel code no longer
> + * depends on it.
>   */
> -
> -/* Current version of this protocol */
>  #define EC_PROTO_VERSION  0x0002
>  
>  /* Command version mask */
> @@ -57,13 +44,19 @@
>  #define EC_LPC_ADDR_HOST_CMD   0x204
>  
>  /* I/O addresses for host command args and params */
> -#define EC_LPC_ADDR_HOST_ARGS  0x800
> -#define EC_LPC_ADDR_HOST_PARAM 0x804
> -#define EC_HOST_PARAM_SIZE 0x0fc  /* Size of param area in bytes */
> -
> -/* I/O addresses for host command params, old interface */
> -#define EC_LPC_ADDR_OLD_PARAM  0x880
> -#define EC_OLD_PARAM_SIZE  0x080  /* Size of param area in bytes */
> +/* Protocol version 2 */
> +#define EC_LPC_ADDR_HOST_ARGS0x800  /* And 0x801, 0x802, 0x803 */
> +#define EC_LPC_ADDR_HOST_PARAM   0x804  /* For version 2 params; size is
> +  * EC_PROTO2_MAX_PARAM_SIZE */
> +/* Protocol version 3 */
> +#define EC_LPC_ADDR_HOST_PACKET  0x800  /* Offset of version 3 packet */
> +#define EC_LPC_HOST_PACKET_SIZE  0x100  /* Max size of version 3 packet */
> +
> +/* The actual block is 0x800-0x8ff, but some BIOSes think it's 0x880-0x8ff
> + * and they tell the kernel that so we have to think of it as two parts. */
> +#define EC_HOST_CMD_REGION00x800
> +#define EC_HOST_CMD_REGION10x880
> +#define EC_HOST_CMD_REGION_SIZE 0x80
>  
>  /* EC command register bit functions */
>  #define EC_LPC_CMDR_DATA (1 << 0)  /* Data ready for host to read */
> @@ -79,18 +72,22 @@
>  #define EC_MEMMAP_TEXT_MAX 8   /* Size of a string in the memory map */
>  
>  /* The offset address of each type of data in mapped memory. */
> -#define EC_MEMMAP_TEMP_SENSOR  0x00 /* Temp sensors */
> -#define EC_MEMMAP_FAN  0x10 /* Fan speeds */
> -#define EC_MEMMAP_TEMP_SENSOR_B0x18 /* Temp sensors (second set) */
> -#define EC_MEMMAP_ID   0x2

Re: [PATCH v3 6/7] i2c: ChromeOS EC tunnel driver

[Lee Jones]

On Wed, 30 Apr 2014, Doug Anderson wrote:

> On ARM Chromebooks we have a few devices that are accessed by both the
> AP (the main "Application Processor") and the EC (the Embedded
> Controller).  These are:
> * The battery (sbs-battery).
> * The power management unit tps65090.
> 
> On the original Samsung ARM Chromebook these devices were on an I2C
> bus that was shared between the AP and the EC and arbitrated using
> some extranal GPIOs (see i2c-arb-gpio-challenge).
> 
> The original arbitration scheme worked well enough but had some
> downsides:
> * It was nonstandard (not using standard I2C multimaster)
> * It only worked if the EC-AP communication was I2C
> * It was relatively hard to debug problems (hard to tell if i2c issues
>   were caused by the EC, the AP, or some device on the bus).
> 
> On the HP Chromebook 11 the design was changed to:
> * The AP/EC comms were still i2c, but the battery/tps65090 were no
>   longer on the bus used for AP/EC communication.  The battery was
>   exposed to the AP through a limited i2c tunnel and tps65090 was
>   exposed to the AP through a custom Linux driver.
> 
> On the Samsung ARM Chromebook 2 the scheme is changed yet again, now:
> * The AP/EC comms are now using SPI for faster speeds.
> * The EC's i2c bus is exposed to the AP through a full i2c tunnel.
> 
> The upstream "tegra124-venice2" uses the same scheme as the Samsung
> ARM Chromebook 2, though it has a different set of components on the
> other side of the bus.
> 
> This driver supports the scheme used by the Samsung ARM Chromebook 2.
> Future patches to this driver could add support for the battery tunnel
> on the HP Chromebook 11 (and perhaps could even be used to access
> tps65090 on the HP Chromebook 11 instead of using a special driver,
> but I haven't researched that enough).
> 
> Signed-off-by: Vincent Palatin 
> Signed-off-by: Simon Glass 
> Signed-off-by: Doug Anderson 
> ---
> Changes in v3:
> - Separate out packet sizing from packet stuffing.
> - Get rid of useless dev_dbg.
> - Check command_sendrecv against NULL.
> - Don't check np against NULL.
> - Get rid of useless error on memory alloc fail.
> - Get rid of useless platform_set_drvdata(dev, NULL);
> 
> Changes in v2:
> - Update tunnel binding as per swarren
> 
>  .../devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt |  39 +++
>  drivers/i2c/busses/Kconfig |   9 +
>  drivers/i2c/busses/Makefile|   1 +
>  drivers/i2c/busses/i2c-cros-ec-tunnel.c| 318 
> +
>  drivers/mfd/cros_ec.c  |   5 +
>  5 files changed, 372 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
>  create mode 100644 drivers/i2c/busses/i2c-cros-ec-tunnel.c

Applied, thanks.

> diff --git a/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt 
> b/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
> new file mode 100644
> index 000..898f030
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
> @@ -0,0 +1,39 @@
> +I2C bus that tunnels through the ChromeOS EC (cros-ec)
> +==
> +On some ChromeOS board designs we've got a connection to the EC (embedded
> +controller) but no direct connection to some devices on the other side of
> +the EC (like a battery and PMIC).  To get access to those devices we need
> +to tunnel our i2c commands through the EC.
> +
> +The node for this device should be under a cros-ec node like 
> google,cros-ec-spi
> +or google,cros-ec-i2c.
> +
> +
> +Required properties:
> +- compatible: google,cros-ec-i2c-tunnel
> +- google,remote-bus: The EC bus we'd like to talk to.
> +
> +Optional child nodes:
> +- One node per I2C device connected to the tunnelled I2C bus.
> +
> +
> +Example:
> + cros-ec@0 {
> + compatible = "google,cros-ec-spi";
> +
> + ...
> +
> + i2c-tunnel {
> + compatible = "google,cros-ec-i2c-tunnel";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + google,remote-bus = <0>;
> +
> + battery: sbs-battery@b {
> + compatible = "sbs,sbs-battery";
> + reg = <0xb>;
> + sbs,poll-retry-count = <1>;
> + };
> + };
> + }
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index c94db1c..9a0a6cc 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -993,6 +993,15 @@ config I2C_SIBYTE
>   help
> Supports the SiByte SOC on-chip I2C interfaces (2 channels).
>  
> +config I2C_CROS_EC_TUNNEL
> + tristate "ChromeOS EC tunnel I2C bus"
> + depends on MFD_CROS_EC
> + help
> +   If you say yes here you get an I2C bus that will tunnel i2c commands
> +   through to the ot

Re: [PATCH v3 7/7] ARM: tegra: Add the EC i2c tunnel to tegra124-venice2

[Lee Jones]

> > This adds the EC i2c tunnel (and devices under it) to the
> > tegra124-venice2 device tree.
> 
> I'll happily take this into the Tegra tree once the patch containing the
> binding it uses is applied.

All other patches applied.  Take this when ready.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/5] staging: lustre: lnet: socklnd: Clean up memset(...)

[walter harms]

Am 18.05.2014 19:27, schrieb Joe Perches:
> On Sun, 2014-05-18 at 18:19 +0100, Masaru Nomura wrote:
>> Remove prohibited space and fix line over 80 characters of
>> memset(...) to meet kernel coding style.
> []
>> diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c 
>> b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
> []
>> @@ -113,7 +113,7 @@ ksocknal_create_peer(ksock_peer_t **peerp, lnet_ni_t 
>> *ni, lnet_process_id_t id)
>>  if (peer == NULL)
>>  return -ENOMEM;
>>  
>> -memset (peer, 0, sizeof (*peer));   /* NULL pointers/clear flags 
>> etc */
>> +memset(peer, 0, sizeof(*peer)); /* NULL pointers/clear flags etc */
> 
> It looks like this memset is unnecessary
> as it's already zeroed by LIBCFS_ALLOC->
> LIBCFS_ALLOC_GFP->LIBCFS_ALLOC_POST->memset.
> 
> It seems as if all these ALLOC macros could
> use quite a bit of cleaning/sorting out.
> 

for a start,
some kind soul could replace the malloc()/memset() with zalloc().

re,
 wh





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: Tree for May 20

[Stephen Rothwell]

Hi all,

Changes since 20140519:

My fixes tree contains:
powerpc/ppc64: Allow allmodconfig to build (finally !)

The net tree gained a build failure so I used the version from
next-20140519.

The sparc-next tree gained a conflict against Linus' tree.

The net-next tree still had its build failure so I used the version from
next-20140516.

The mfd-lj tree gained a build failure for which I reverted a commit.

The dma-buf tree gained conflicts against the drm-intel and staging
trees and a build failure so I used the version from next-20140519.

The akpm tree still had lots of build warnings for which I reverted 2
commits.

Non-merge commits (relative to Linus' tree): 6311
 5641 files changed, 224429 insertions(+), 131147 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 218 trees (counting Linus' and 29 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (14186fea0cb0 Merge tag 'locks-v3.15-4' of 
git://git.samba.org/jlayton/linux)
Merging fixes/master (0be9d8b61c0c powerpc/ppc64: Allow allmodconfig to build 
(finally !))
Merging kbuild-current/rc-fixes (38dbfb59d117 Linus 3.14-rc1)
Merging arc-current/for-curr (a798c10faf62 Linux 3.15-rc2)
Merging arm-current/fixes (d93003e8e4e1 ARM: 8042/1: iwmmxt: allow to build 
iWMMXt on Marvell PJ4B)
Merging m68k-current/for-linus (50be9eba831d m68k: Update defconfigs for 
v3.14-rc1)
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging powerpc-merge/merge (8050936caf12 powerpc: irq work racing with timer 
interrupt can result in timer interrupt hang)
Merging sparc/master (5aa4ecfd0ddb sparc64: Add membar to Niagara2 memcpy code.)
Merging net/master (4f337ed5c014 MAINTAINERS: Pravin Shelar is Open vSwitch 
maintainer.)
$ git reset --hard HEAD^
Merging next-20140519 version of net
Merging ipsec/master (6d004d6cc739 vti: Use the tunnel mark for lookup in the 
error handlers.)
Merging sound-current/for-linus (02fb05a598e9 ALSA: pcm_dmaengine: Add check 
during device suspend)
Merging pci-current/for-linus (d0b4cc4e3270 PCI: Wrong register used to check 
pending traffic)
Merging wireless/master (20b4f9c73ff4 Merge branch 'master' of 
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth)
Merging driver-core.current/driver-core-linus (555724a831b4 kernfs, sysfs, 
cgroup: restrict extra perm check on open to sysfs)
Merging tty.current/tty-linus (62a0d8d7c2b2 tty: Fix lockless tty buffer race)
Merging usb.current/usb-linus (6ed07d45d09b USB: Nokia 5300 should be treated 
as unusual dev)
Merging usb-gadget-fixes/fixes (886c7c426d46 usb: gadget: at91-udc: fix irq and 
iomem resource retrieval)
Merging staging.current/staging-linus (bb4e506565cf staging: rtl8723au: Do not 
reset wdev->iftype in netdev_close())
Merging char-misc.current/char-misc-linus (d1db0eea8524 Linux 3.15-rc3)
Merging input-current/for-linus (0b5fe736fe92 Input: synaptics - add min/max 
quirk for the ThinkPad W540)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (3901c1124ec5 crypto: s390 - fix aes,des ctr mode 
concurrency finding.)
Merging ide/master (5b40dd30bbfa ide: Fix SC1200 dependencies)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (e7a23fea64f1 mips: dts: Fix 
missing device_type="memory" property in memory nodes)
Merging rr-fixes/fixes (79465d2fd48e module: remove warning about waiti

RE: [PATCH 3/5] usb: gadget: net2280: Pass checkpacth.pl test

[David Laight]

From: Alan Stern
...
> > -static struct usb_request *
> > -net2280_alloc_request (struct usb_ep *_ep, gfp_t gfp_flags)
> > +static struct usb_request *net2280_alloc_request(struct usb_ep *_ep,
> > +   gfp_t gfp_flags)
> 
> What's with the extreme indentation on the continuation line?  The
> style used here is for continuation lines to be indented by two stops
> relative to the first line.

Also why move the line break?
The Linux kernel has both styles, and the original one (with the
function name starting in column 1) makes it much easier to search
to the definition.

David



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 0/3] Add support for PCI in AArch64

[Sunil Kovvuri]

On Tue, May 20, 2014 at 2:14 PM, Arnd Bergmann  wrote:
> On Tuesday 20 May 2014 09:52:33 Sunil Kovvuri wrote:
>> >> In sriov_enable() (drivers/pci/iov.c)
>> >>
>> >>  296for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
>> >>  297 bars |= (1 << (i + PCI_IOV_RESOURCES));
>> >>  298 res = dev->resource + PCI_IOV_RESOURCES + i;
>> >>  299 if (res->parent)
>> >>  300 nres++;
>> >>  301 }
>> >>  302 if (nres != iov->nres) {
>> >>  303 dev_err(&dev->dev, "not enough MMIO resources for
>> >>  SR-IOV\n");
>> >>  304 return -ENOMEM;
>> >>  305 }
>> >>
>> >> Here its checking if physical function's IOV resource has a parent or not.
>> >> Which is pci-pci bridge in this case. Otherwise it doesn't consider
>> >> that resource.
>> >>
>> >> Added below api to your patch.
>> >> This will try to claim a resource while creating a PCI device which
>> >> inturn sets 'res->parent'.
>> >
>> > This looks like the wrong approach. The PCI host controller should
>> > really have been registered with the root 'iomem_resource' during
>> > the probe of the host controller.
>> >
>> I didn't get this, if a SR-IOV device is connected to a PCI-PCI bridge
>> and inturn bridge connected to root port. Then the parent bus is not root,
>> but the bridge.  The issue is either hierarchy should not be checked for
>> SR-IOV resources or someone should set the hierarchy (i.e parent resources).
>
> Ah, I misunderstood the problem, I thought the PCI core was complaining
> about lack of space in the resources, not about a lack of BARs.
>
> It seems there is code like yours in a couple of architectures, but they
> only claim the resources of bridges, not the actual devices as you
> seem to be doing. Can you check if the x86 version of
> pcibios_allocate_bus_resources() does the trick for you? Maybe we can
> turn that into a generic helper.
>
Thanks for the suggestion. Will try that once.
FYI, IA64 architecture does claim resources for devices as well.
arch/ia64/pci/pci.c  'pcibios_fixup_device_resources()'

Thanks,
Sunil.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/5] usb: gadget: net2280: Pass checkpacth.pl test

[Ricardo Ribalda Delgado]

Not for grep...

But if this is an issue I have no problem going back to the original.
We can spend a whole year just talking about codestyle.



On Tue, May 20, 2014 at 10:52 AM, David Laight  wrote:
> From: Alan Stern
> ...
>> > -static struct usb_request *
>> > -net2280_alloc_request (struct usb_ep *_ep, gfp_t gfp_flags)
>> > +static struct usb_request *net2280_alloc_request(struct usb_ep *_ep,
>> > +   gfp_t gfp_flags)
>>
>> What's with the extreme indentation on the continuation line?  The
>> style used here is for continuation lines to be indented by two stops
>> relative to the first line.
>
> Also why move the line break?
> The Linux kernel has both styles, and the original one (with the
> function name starting in column 1) makes it much easier to search
> to the definition.
>
> David
>
>
>



-- 
Ricardo Ribalda
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] platform: x86: dell-smo8800: Dell Latitude freefall driver (ACPI SMO8800/SMO8810)

[Pali Rohár]

On Tuesday 20 May 2014 09:00:05 valdis.kletni...@vt.edu wrote:
> On Sat, 03 May 2014 12:47:56 +0200, Pali Rohár said:
> > This acpi driver provide supports for freefall sensors
> > SMO8800/SMO8810 which can be found on Dell Latitude
> > laptops. Driver register /dev/freefall misc device which
> > has same interface as driver hp_accel freefall driver. So
> > any existing applications for HP freefall sensor
> > /dev/freefall will work for with this new driver for Dell
> > Latitude laptops too.
> 
> So just for grins, I tossed this patchset on top of
> next-20140519, and it actually works on my Dell Latitude
> E6530. Tested with a controlled drop of 3-4 inches, and I get
> the distinctive sound of a head park, and the following in
> /var/log/messages:
> 
> May 20 02:46:22 turing-police kernel: [18839.158926] smo8800
> SMO8810:00: detected free fall May 20 02:46:22 turing-police
> FREE FALL[1337]: Parked /dev/sda disk head May 20 02:46:24
> turing-police FREE FALL[1337]: Unparked /dev/sda disk head
> 
> I did a quick read-through of the code, looks OK.  checkpatch
> complains about missing blank lines after declarations in 3-4
> places. Sparse and gcc have no complaints. We've certainly
> merged much uglier code.  And it certainly makes the world a
> better place for us Dell users.
> 

Hm? Which errors? Here is output from checkpacth:

total: 0 errors, 0 warnings, 276 lines checked

0001-platform-x86-dell-smo8800-Dell-Latitude-freefall-dri.patch 
has no obvious style problems and is ready for submission.

total: 0 errors, 0 warnings, 181 lines checked

0002-Documentation-Rename-hpfall.c-freefall.c-fixes-for-D.patch 
has no obvious style problems and is ready for submission.

> So it's OK by me if Pali adds this to the signoffs after
> fixing the checkpatch and the one serious nit below
> 
> Tested-By: Valdis Kletnieks 
> Acked-By: Valdis Kletnieks 
> 
> One nit:
> > --- a/drivers/platform/x86/Kconfig
> > +++ b/drivers/platform/x86/Kconfig
> > @@ -127,6 +127,16 @@ config DELL_WMI_AIO
> > 
> >   To compile this driver as a module, choose M here: the
> >   module will be called dell-wmi-aio.
> > 
> > +config DELL_SMO8800
> > +   tristate "Dell Latitude freefall driver (ACPI
> > SMO8800/SMO8810)" + depends ON ACPI
> 
> Lowercase ON.  Not sure how this escaped, Kbuild barfs on it.

I will send new version with some changes from Sonal.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

[PATCH] perf: Fix mux_interval hrtimer wreckage

[Peter Zijlstra]

Subject: perf: Fix mux_interval hrtimer wreckage
From: Peter Zijlstra 
Date: Tue May 20 10:09:32 CEST 2014

Thomas stumbled over the hrtimer_forward_now() in
perf_event_mux_interval_ms_store() and noticed its broken-ness.

You cannot just change the expiry time of an active timer, it will
destroy the red-black tree order and cause havoc.

Change it to (re)start the timer instead, (re)starting a timer will
dequeue and enqueue a timer and therefore preserve rb-tree order.

Since we cannot enqueue remotely, wrap the thing in
cpu_function_call(), this however mandates that we restrict ourselves
to online cpus. Also serialize the entire setting so we don't get
multiple concurrent threads trying to update to different values.

Also fix a problem in perf_mux_hrtimer_restart(), checking against
hrtimer_active() can actually loose us the timer when timer->state ==
HRTIMER_STATE_CALLBACK and the callback has already decided NORESTART.

Furthermore it doesn't make any sense to test
hrtimer_callback_running() when we already tested hrtimer_active(),
but with the above change, we explicitly must call it when
callback_running.

Lastly, rename a few functions:

  s/perf_cpu_hrtimer_/perf_mux_hrtimer_/ -- because I could not find
the mux timer function

  s/\/timer/ -- because that's the normal way of calling things.

Fixes: 62b856397927 ("perf: Add sysfs entry to adjust multiplexing interval per 
PMU")
Cc: Stephane Eranian 
Reported-by: Thomas Gleixner 
Signed-off-by: Peter Zijlstra 
Link: http://lkml.kernel.org/n/tip-ife5kqgnt7mviatc9fakz...@git.kernel.org
---
 kernel/events/core.c |   67 ---
 1 file changed, 38 insertions(+), 29 deletions(-)

--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -45,9 +45,11 @@
 
 #include 
 
+typedef int (*remote_function_f)(void *);
+
 struct remote_function_call {
struct task_struct  *p;
-   int (*func)(void *info);
+   remote_function_f   func;
void*info;
int ret;
 };
@@ -80,7 +82,7 @@ static void remote_function(void *data)
  * -EAGAIN - when the process moved away
  */
 static int
-task_function_call(struct task_struct *p, int (*func) (void *info), void *info)
+task_function_call(struct task_struct *p, remote_function_f func, void *info)
 {
struct remote_function_call data = {
.p  = p,
@@ -104,7 +106,7 @@ task_function_call(struct task_struct *p
  *
  * returns: @func return value or -ENXIO when the cpu is offline
  */
-static int cpu_function_call(int cpu, int (*func) (void *info), void *info)
+static int cpu_function_call(int cpu, remote_function_f func, void *info)
 {
struct remote_function_call data = {
.p  = NULL,
@@ -759,7 +761,7 @@ perf_cgroup_mark_enabled(struct perf_eve
 /*
  * function must be called with interrupts disbled
  */
-static enum hrtimer_restart perf_cpu_hrtimer_handler(struct hrtimer *hr)
+static enum hrtimer_restart perf_mux_hrtimer_handler(struct hrtimer *hr)
 {
struct perf_cpu_context *cpuctx;
enum hrtimer_restart ret = HRTIMER_NORESTART;
@@ -783,7 +785,7 @@ static enum hrtimer_restart perf_cpu_hrt
 }
 
 /* CPU is going down */
-void perf_cpu_hrtimer_cancel(int cpu)
+void perf_mux_hrtimer_cancel(int cpu)
 {
struct perf_cpu_context *cpuctx;
struct pmu *pmu;
@@ -810,11 +812,11 @@ void perf_cpu_hrtimer_cancel(int cpu)
local_irq_restore(flags);
 }
 
-static void __perf_cpu_hrtimer_init(struct perf_cpu_context *cpuctx, int cpu)
+static void __perf_mux_hrtimer_init(struct perf_cpu_context *cpuctx, int cpu)
 {
-   struct hrtimer *hr = &cpuctx->hrtimer;
+   struct hrtimer *timer = &cpuctx->hrtimer;
struct pmu *pmu = cpuctx->ctx.pmu;
-   int timer;
+   u64 interval;
 
/* no multiplexing needed for SW PMU */
if (pmu->task_ctx_nr == perf_sw_context)
@@ -824,31 +826,32 @@ static void __perf_cpu_hrtimer_init(stru
 * check default is sane, if not set then force to
 * default interval (1/tick)
 */
-   timer = pmu->hrtimer_interval_ms;
-   if (timer < 1)
-   timer = pmu->hrtimer_interval_ms = PERF_CPU_HRTIMER;
+   interval = pmu->hrtimer_interval_ms;
+   if (interval < 1)
+   interval = pmu->hrtimer_interval_ms = PERF_CPU_HRTIMER;
 
-   cpuctx->hrtimer_interval = ns_to_ktime(NSEC_PER_MSEC * timer);
+   cpuctx->hrtimer_interval = ns_to_ktime(NSEC_PER_MSEC * interval);
 
-   hrtimer_init(hr, CLOCK_MONOTONIC, HRTIMER_MODE_REL_PINNED);
-   hr->function = perf_cpu_hrtimer_handler;
+   hrtimer_init(timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL_PINNED);
+   timer->function = perf_mux_hrtimer_handler;
 }
 
-static void perf_cpu_hrtimer_restart(struct perf_cpu_context *cpuctx)
+static int perf_mux_hrtimer_restart(struct perf_cpu_context *cpuctx)
 {
-   struct h

[PATCH v4 7/7] ARM: berlin: enable the eSATA interface on the BG2Q DMP

[Antoine Ténart]

The BG2Q has an AHCI SATA controller with an eSATA interface. Enable it.
Only enable the first port, the BG2Q DMP does not support the second one.

Signed-off-by: Antoine Ténart 
---
 arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts 
b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
index 2da9c41e29d8..899b4e04fe12 100644
--- a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
+++ b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
@@ -26,3 +26,11 @@
 &uart0 {
status = "okay";
 };
+
+&sata0 {
+   status = "okay";
+};
+
+&sata_phy {
+   status = "okay";
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 5/7] Documentation: bindings: document the sub-nodes AHCI bindings

[Antoine Ténart]

The libahci now allows to use multiple PHYs and to represent each port
as a sub-node. Add these bindings to the documentation.

Signed-off-by: Antoine Ténart 
---
 .../devicetree/bindings/ata/ahci-platform.txt  | 38 +-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt 
b/Documentation/devicetree/bindings/ata/ahci-platform.txt
index 48b285ffa3a6..5e4f006a018d 100644
--- a/Documentation/devicetree/bindings/ata/ahci-platform.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt
@@ -3,11 +3,16 @@
 SATA nodes are defined to describe on-chip Serial ATA controllers.
 Each SATA controller should have its own node.
 
+It is possible, but not required, to represent each port as a sub-node.
+It allows to enable each port independently when dealing with multiple
+PHYs.
+
 Required properties:
 - compatible: compatible list, one of "snps,spear-ahci",
   "snps,exynos5440-ahci", "ibm,476gtr-ahci",
   "allwinner,sun4i-a10-ahci", "fsl,imx53-ahci"
-  "fsl,imx6q-ahci" or "snps,dwc-ahci"
+  "fsl,imx6q-ahci", "snps,dwc-ahci" or
+  "marvell,berlin-ahci"
 - interrupts: 
 - reg   : 
 
@@ -15,11 +20,23 @@ Optional properties:
 - dma-coherent  : Present if dma operations are coherent
 - clocks: a list of phandle + clock specifier pairs
 - target-supply : regulator for SATA target power
+- phys  : reference to the SATA PHY node
+- phy-names : must be "sata-phy"
 
 "fsl,imx53-ahci", "fsl,imx6q-ahci" required properties:
 - clocks: must contain the sata, sata_ref and ahb clocks
 - clock-names   : must contain "ahb" for the ahb clock
 
+Required properties when using sub-nodes:
+- #address-cells: number of cells to encode an address
+- #size-cells   : number of cells representing the size of an address
+
+
+Sub-nodes required properties:
+- reg   : the port number
+- phys  : reference to the SATA PHY node
+
+
 Examples:
 sata@ffe08000 {
compatible = "snps,spear-ahci";
@@ -34,3 +51,22 @@ Examples:
clocks = <&pll6 0>, <&ahb_gates 25>;
target-supply = <®_ahci_5v>;
};
+
+With sub-nodes:
+   sata@f7e9 {
+   compatible = "marvell,berlin-ahci";
+   reg = <0xe9 0x1000>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   sata0: sata-port@0 {
+   reg = <0>;
+   phys = <&sata_phy 0>;
+   };
+
+   sata1: sata-port@1 {
+   reg = <1>;
+   phys = <&sata_phy 1>;
+   };
+   };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 6/7] ARM: berlin: add the AHCI node for the BG2Q

[Antoine Ténart]

The BG2Q has an AHCI SATA controller. Add the corresponding nodes
(AHCI, PHY) into its device tree.

Signed-off-by: Antoine Ténart 
---
 arch/arm/boot/dts/berlin2q.dtsi | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index 07452a7483fa..18825b54b170 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -183,6 +183,33 @@
};
};
 
+   ahci: sata@e9 {
+   compatible = "marvell,berlin-ahci";
+   reg = <0xe9 0x1000>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   sata0: sata-port@0 {
+   reg = <0>;
+   phys = <&sata_phy 0>;
+   status = "disabled";
+   };
+
+   sata1: sata-port@1 {
+   reg = <1>;
+   phys = <&sata_phy 1>;
+   status = "disabled";
+   };
+   };
+
+   sata_phy: phy@e900a0 {
+   compatible = "marvell,berlin-sata-phy";
+   reg = <0xe900a0 0x200>;
+   #phy-cells = <1>;
+   status = "disabled";
+   };
+
apb@fc {
compatible = "simple-bus";
#address-cells = <1>;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 3/7] ata: libahci: allow to use multiple PHYs

[Antoine Ténart]

The current implementation of the libahci does not allow to use multiple
PHYs. This patch adds the support of multiple PHYs by the libahci while
keeping the old bindings valid for device tree compatibility.

This introduce a new way of defining SATA ports in the device tree, with
one port per sub-node. This as the advantage of allowing a per port
configuration. Because some ports may be accessible but disabled in the
device tree, the default port_map is computed automatically when using
this.

Signed-off-by: Antoine Ténart 
---
 drivers/ata/Kconfig|   1 +
 drivers/ata/ahci.h |   3 +-
 drivers/ata/libahci.c  |   7 ++
 drivers/ata/libahci_platform.c | 165 -
 4 files changed, 140 insertions(+), 36 deletions(-)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index c2706047337f..385c455e0aeb 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -91,6 +91,7 @@ config SATA_AHCI
 
 config SATA_AHCI_PLATFORM
tristate "Platform AHCI SATA support"
+   select PHY_BERLIN_SATA if ARCH_BERLIN
help
  This option enables support for Platform AHCI Serial ATA
  controllers.
diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
index b5eb886da226..0c80feb84d17 100644
--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
@@ -328,7 +328,8 @@ struct ahci_host_priv {
boolgot_runtime_pm; /* Did we do pm_runtime_get? */
struct clk  *clks[AHCI_MAX_CLKS]; /* Optional */
struct regulator*target_pwr;/* Optional */
-   struct phy  *phy;   /* If platform uses phy */
+   struct phy  **phys; /* If platform uses phys */
+   unsignednphys;  /* Number of phys */
void*plat_data; /* Other platform data */
/*
 * Optional ahci_start_engine override, if not set this gets set to the
diff --git a/drivers/ata/libahci.c b/drivers/ata/libahci.c
index 6bd4f660b4e1..9a41fd16ecc7 100644
--- a/drivers/ata/libahci.c
+++ b/drivers/ata/libahci.c
@@ -470,6 +470,13 @@ void ahci_save_initial_config(struct device *dev,
port_map &= mask_port_map;
}
 
+   /*
+* If port_map was filled automatically when finding port sub-nodes,
+* make sure we get the right set here.
+*/
+   if (hpriv->port_map)
+   port_map &= hpriv->port_map;
+
/* cross check port_map and cap.n_ports */
if (port_map) {
int map_ports = 0;
diff --git a/drivers/ata/libahci_platform.c b/drivers/ata/libahci_platform.c
index 7cb3a85719c0..0651a902b889 100644
--- a/drivers/ata/libahci_platform.c
+++ b/drivers/ata/libahci_platform.c
@@ -39,6 +39,61 @@ static struct scsi_host_template ahci_platform_sht = {
 };
 
 /**
+ * ahci_platform_enable_phys - Enable PHYs
+ * @hpriv: host private area to store config values
+ *
+ * This function enables all the PHYs found in hpriv->phys, if any.
+ * If a PHY fails to be enabled, it disables all the PHYs already
+ * enabled in reverse order and returns an error.
+ *
+ * RETURNS:
+ * 0 on success otherwise a negative error code
+ */
+int ahci_platform_enable_phys(struct ahci_host_priv *hpriv)
+{
+   int i, rc = 0;
+
+   for (i = 0; i < hpriv->nphys; i++) {
+   rc = phy_init(hpriv->phys[i]);
+   if (rc)
+   goto disable_phys;
+
+   rc = phy_power_on(hpriv->phys[i]);
+   if (rc) {
+   phy_exit(hpriv->phys[i]);
+   goto disable_phys;
+   }
+   }
+
+   return 0;
+
+disable_phys:
+   while (--i >= 0) {
+   phy_power_off(hpriv->phys[i]);
+   phy_exit(hpriv->phys[i]);
+   }
+   return rc;
+}
+EXPORT_SYMBOL_GPL(ahci_platform_enable_phys);
+
+/**
+ * ahci_platform_disable_phys - Enable PHYs
+ * @hpriv: host private area to store config values
+ *
+ * This function disables all PHYs found in hpriv->phys.
+ */
+void ahci_platform_disable_phys(struct ahci_host_priv *hpriv)
+{
+   int i;
+
+   for (i = 0; i < hpriv->nphys; i++) {
+   phy_power_off(hpriv->phys[i]);
+   phy_exit(hpriv->phys[i]);
+   }
+}
+EXPORT_SYMBOL_GPL(ahci_platform_disable_phys);
+
+/**
  * ahci_platform_enable_clks - Enable platform clocks
  * @hpriv: host private area to store config values
  *
@@ -92,7 +147,7 @@ EXPORT_SYMBOL_GPL(ahci_platform_disable_clks);
  * following order:
  * 1) Regulator
  * 2) Clocks (through ahci_platform_enable_clks)
- * 3) Phy
+ * 3) Phys
  *
  * If resource enabling fails at any point the previous enabled resources
  * are disabled in reverse order.
@@ -114,17 +169,9 @@ int ahci_platform_enable_resources(struct ahci_host_priv 
*hpriv)
if (rc)
goto disable_regulator;
 
-   if (hpriv->phy) {
-   rc = phy_init(hpriv->phy);
-  

[PATCH v4 4/7] ata: ahci_platform: add the Marvell Berlin AHCI compatible

[Antoine Ténart]

The Marvell Berlin AHCI has all his specific in the PHY driver. It then
only need to use the libahci functions to work properly.

Add its compatible into the libahci_platform driver.

Signed-off-by: Antoine Ténart 
---
 drivers/ata/ahci_platform.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index ef67e79944f9..bc050aabf206 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -76,6 +76,7 @@ static const struct of_device_id ahci_of_match[] = {
{ .compatible = "snps,exynos5440-ahci", },
{ .compatible = "ibm,476gtr-ahci", },
{ .compatible = "snps,dwc-ahci", },
+   { .compatible = "marvell,berlin-ahci", },
{},
 };
 MODULE_DEVICE_TABLE(of, ahci_of_match);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 0/7] ARM: berlin: add AHCI support

[Antoine Ténart]

This series adds the support for Berlin SoC AHCI controller. The
controller allows to use the SATA host interface and, for example, the
eSATA port on the BG2Q.

The series adds a PHY driver to control the two SATA ports available,
and uses the existing ahci_platform driver.

Also enable the eSATA interface on the BG2Q DMP.

Changes since v3:
- moved all PHY operations to the PHY driver
- removed PHY sub-nodes
- removed the custom Berlin AHCI driver and switched to
  ahci_platform
- added multiple PHYs support to the libahci_platform

Changes since v2:
- modeled each PHY as a sub-node
- cosmetic fixups

Changes since v1:
- added a PHY driver, allowing to enable each port
  individually and removed the 'force-port-map' property
- made the drivers a bit less magic :)
- wrote a function to select and configure registers in the
  AHCI driver
- removed BG2 / BG2CD nodes

Antoine Ténart (7):
  phy: add a driver for the Berlin SATA PHY
  Documentation: bindings: add the Berlin SATA PHY
  ata: libahci: allow to use multiple PHYs
  ata: ahci_platform: add the Marvell Berlin AHCI compatible
  Documentation: bindings: document the sub-nodes AHCI bindings
  ARM: berlin: add the AHCI node for the BG2Q
  ARM: berlin: enable the eSATA interface on the BG2Q DMP

 .../devicetree/bindings/ata/ahci-platform.txt  |  38 +++-
 .../devicetree/bindings/phy/berlin-sata-phy.txt|  14 ++
 arch/arm/boot/dts/berlin2q-marvell-dmp.dts |   8 +
 arch/arm/boot/dts/berlin2q.dtsi|  27 +++
 drivers/ata/Kconfig|   1 +
 drivers/ata/ahci.h |   3 +-
 drivers/ata/ahci_platform.c|   1 +
 drivers/ata/libahci.c  |   7 +
 drivers/ata/libahci_platform.c | 165 +++
 drivers/phy/Kconfig|   5 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-berlin-sata.c  | 230 +
 12 files changed, 463 insertions(+), 37 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/phy/berlin-sata-phy.txt
 create mode 100644 drivers/phy/phy-berlin-sata.c

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 1/7] phy: add a driver for the Berlin SATA PHY

[Antoine Ténart]

The Berlin SoC has a two SATA ports. Add a PHY driver to handle them.

The mode selection can let us think this PHY can be configured to fit
other purposes. But there are reasons to think the SATA mode will be
the only one usable: the PHY registers are only accessible indirectly
through two registers in the SATA range, the PHY seems to be integrated
and no information tells us the contrary. For these reasons, make the
driver a SATA PHY driver.

Signed-off-by: Antoine Ténart 
---
 drivers/phy/Kconfig   |   5 +
 drivers/phy/Makefile  |   1 +
 drivers/phy/phy-berlin-sata.c | 230 ++
 3 files changed, 236 insertions(+)
 create mode 100644 drivers/phy/phy-berlin-sata.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 4906c27fa3bd..b31b1986fda4 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -15,6 +15,11 @@ config GENERIC_PHY
  phy users can obtain reference to the PHY. All the users of this
  framework should select this config.
 
+config PHY_BERLIN_SATA
+   bool
+   depends on ARCH_BERLIN && OF
+   select GENERIC_PHY
+
 config PHY_EXYNOS_MIPI_VIDEO
tristate "S5P/EXYNOS SoC series MIPI CSI-2/DSI PHY driver"
depends on HAS_IOMEM
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 7728518572a4..40278706ac1b 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -3,6 +3,7 @@
 #
 
 obj-$(CONFIG_GENERIC_PHY)  += phy-core.o
+obj-$(CONFIG_PHY_BERLIN_SATA)  += phy-berlin-sata.o
 obj-$(CONFIG_BCM_KONA_USB2_PHY)+= phy-bcm-kona-usb2.o
 obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO)  += phy-exynos-dp-video.o
 obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)+= phy-exynos-mipi-video.o
diff --git a/drivers/phy/phy-berlin-sata.c b/drivers/phy/phy-berlin-sata.c
new file mode 100644
index ..597f008cae32
--- /dev/null
+++ b/drivers/phy/phy-berlin-sata.c
@@ -0,0 +1,230 @@
+/*
+ * Marvell Berlin SATA PHY driver
+ *
+ * Copyright (C) 2014 Marvell Technology Group Ltd.
+ *
+ * Antoine Ténart 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define HOST_VSA_ADDR  0x0
+#define HOST_VSA_DATA  0x4
+#define PORT_VSR_ADDR   0x78
+#define PORT_VSR_DATA   0x7c
+#define PORT_SCR_CTL   0x2c
+
+#define CONTROL_REGISTER   0x0
+#define MBUS_SIZE_CONTROL  0x4
+
+#define POWER_DOWN_PHY0BIT(6)
+#define POWER_DOWN_PHY1BIT(14)
+#define MBUS_WRITE_REQUEST_SIZE_128(BIT(2) << 16)
+#define MBUS_READ_REQUEST_SIZE_128 (BIT(2) << 19)
+
+#define PHY_BASE0x200
+
+/* register 0x01 */
+#define REF_FREF_SEL_25 BIT(0)
+#define PHY_MODE_SATA   (0x0 << 5)
+
+/* register 0x02 */
+#define USE_MAX_PLL_RATEBIT(12)
+
+/* register 0x23 */
+#define DATA_BIT_WIDTH_10   (0x0 << 10)
+#define DATA_BIT_WIDTH_20   (0x1 << 10)
+#define DATA_BIT_WIDTH_40   (0x2 << 10)
+
+/* register 0x25 */
+#define PHY_GEN_MAX_1_5 (0x0 << 10)
+#define PHY_GEN_MAX_3_0 (0x1 << 10)
+#define PHY_GEN_MAX_6_0 (0x2 << 10)
+
+#define BERLIN_SATA_PHY_NB 2
+
+#define to_berlin_sata_phy_priv(desc)  \
+   container_of((desc), struct phy_berlin_priv, phys[(desc)->index])
+
+struct phy_berlin_desc {
+   struct phy  *phy;
+   u32 val;
+   unsignedindex;
+};
+
+struct phy_berlin_priv {
+   void __iomem*base;
+   spinlock_t  lock;
+   struct phy_berlin_desc  phys[BERLIN_SATA_PHY_NB];
+};
+
+static inline void phy_berlin_sata_reg_setbits(void __iomem *ctrl_reg, u32 reg,
+  u32 mask, u32 val)
+{
+   u32 regval;
+
+   /* select register */
+   writel(PHY_BASE + reg, ctrl_reg + PORT_VSR_ADDR);
+
+   /* set bits */
+   regval = readl(ctrl_reg + PORT_VSR_DATA);
+   regval &= ~mask;
+   regval |= val;
+   writel(regval, ctrl_reg + PORT_VSR_DATA);
+}
+
+static int phy_berlin_sata_power_on(struct phy *phy)
+{
+   struct phy_berlin_desc *desc = phy_get_drvdata(phy);
+   struct phy_berlin_priv *priv = to_berlin_sata_phy_priv(desc);
+   void __iomem *ctrl_reg = priv->base + 0x60 + (desc->index * 0x80);
+   int ret = 0;
+   u32 regval;
+
+   spin_lock(&priv->lock);
+
+   /* Power on PHY */
+   writel(CONTROL_REGISTER, priv->base + HOST_VSA_ADDR);
+   regval = readl(priv->base + HOST_VSA_DATA);
+   regval &= ~(desc->val);
+   writel(regval, priv->base + HOST_VSA_DATA);
+
+   /* Configure MBus */
+   writel(MBUS_SIZE_CONTROL, priv->base + HOST_VSA_ADDR);
+   regval = readl(priv->base + HOST_VSA_DATA);
+   regval |= MBUS_WRITE_REQUEST_SIZE_128 | MBUS_READ_REQUEST_SIZE_128

Re: [PATCH 1/1] mm/kmemleak-test.c: use pr_fmt for logging

[Catalin Marinas]

On Mon, May 19, 2014 at 08:25:13PM +0100, Fabian Frederick wrote:
> 
> Cc: Catalin Marinas 
> Cc: Andrew Morton 
> Signed-off-by: Fabian Frederick 
> ---
>  mm/kmemleak-test.c | 36 +++-
>  1 file changed, 19 insertions(+), 17 deletions(-)

Acked-by: Catalin Marinas 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 2/7] Documentation: bindings: add the Berlin SATA PHY

[Antoine Ténart]

The Berlin SATA PHY drives the PHY related to the SATA interface. Add
the corresponding documentation.

Signed-off-by: Antoine Ténart 
---
 Documentation/devicetree/bindings/phy/berlin-sata-phy.txt | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/berlin-sata-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/berlin-sata-phy.txt 
b/Documentation/devicetree/bindings/phy/berlin-sata-phy.txt
new file mode 100644
index ..72646db2f5fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/berlin-sata-phy.txt
@@ -0,0 +1,14 @@
+Berlin SATA PHY
+---
+
+Required properties:
+- compatible: "marvell,berlin-sata-phy"
+- phy-cells: from the generic PHY bindings, must be 1
+- reg: address and length of the register
+
+Example:
+   sata_phy: phy@f7e900a0 {
+   compatible = "marvell,berlin-sata-phy";
+   reg = <0xf7e900a0 0x200>;
+   #phy-cells = <1>;
+   };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the dma-buf tree

[Sumit Semwal]

On 20 May 2014 13:56, Maarten Lankhorst  wrote:
> Hey,
>
> op 20-05-14 09:13, Stephen Rothwell schreef:
>
>> Hi Sumit,
>>
>> After merging the dma-buf tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/gpu/drm/tegra/gem.c: In function 'tegra_gem_prime_export':
>> drivers/gpu/drm/tegra/gem.c:423:15: error: macro "dma_buf_export" requires
>> 5 arguments, but only 4 given
>> drivers/gpu/drm/tegra/gem.c:422:9: error: 'dma_buf_export' undeclared
>> (first use in this function)
>>
>> Caused by commit 8dfb1f0f8103 ("dma-buf: use reservation objects").
>> Grep is your friend ...
>>
>> I have use the dma-buf tree from next-20140519 for today.
>
>
> sumits can you amend the commit?
Hey Maarten,
Yes, I'll amend it and push.
> ---
>
> diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
> index bcf9895cef9f..1e9de41a14ea 100644
> --- a/drivers/gpu/drm/tegra/gem.c
> +++ b/drivers/gpu/drm/tegra/gem.c
> @@ -419,7 +419,7 @@ struct dma_buf *tegra_gem_prime_export(struct drm_device
> *drm,
>int flags)
>  {
> return dma_buf_export(gem, &tegra_gem_prime_dmabuf_ops, gem->size,
> - flags);
> + flags, NULL);
>  }
>   struct drm_gem_object *tegra_gem_prime_import(struct drm_device *drm,
>



-- 
Thanks and regards,

Sumit Semwal
Graphics Engineer - Graphics working group
Linaro.org │ Open source software for ARM SoCs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/7] phy: add a driver for the Berlin SATA PHY

[Sebastian Hesselbarth]

On 05/20/2014 11:04 AM, Antoine Ténart wrote:

The Berlin SoC has a two SATA ports. Add a PHY driver to handle them.

The mode selection can let us think this PHY can be configured to fit
other purposes. But there are reasons to think the SATA mode will be
the only one usable: the PHY registers are only accessible indirectly
through two registers in the SATA range, the PHY seems to be integrated
and no information tells us the contrary. For these reasons, make the
driver a SATA PHY driver.

Signed-off-by: Antoine Ténart 
---

[...]

diff --git a/drivers/phy/phy-berlin-sata.c b/drivers/phy/phy-berlin-sata.c
new file mode 100644
index ..597f008cae32
--- /dev/null
+++ b/drivers/phy/phy-berlin-sata.c
@@ -0,0 +1,230 @@
+/*
+ * Marvell Berlin SATA PHY driver
+ *
+ * Copyright (C) 2014 Marvell Technology Group Ltd.
+ *
+ * Antoine Ténart 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define HOST_VSA_ADDR  0x0
+#define HOST_VSA_DATA  0x4
+#define PORT_VSR_ADDR   0x78
+#define PORT_VSR_DATA   0x7c


Above two lines are indented with spaces.


+#define PORT_SCR_CTL   0x2c
+
+#define CONTROL_REGISTER   0x0
+#define MBUS_SIZE_CONTROL  0x4
+
+#define POWER_DOWN_PHY0BIT(6)
+#define POWER_DOWN_PHY1BIT(14)
+#define MBUS_WRITE_REQUEST_SIZE_128(BIT(2) << 16)
+#define MBUS_READ_REQUEST_SIZE_128 (BIT(2) << 19)
+
+#define PHY_BASE0x200


ditto.


+
+/* register 0x01 */
+#define REF_FREF_SEL_25 BIT(0)
+#define PHY_MODE_SATA   (0x0 << 5)


ditto.


+
+/* register 0x02 */
+#define USE_MAX_PLL_RATEBIT(12)


ditto.


+
+/* register 0x23 */
+#define DATA_BIT_WIDTH_10   (0x0 << 10)
+#define DATA_BIT_WIDTH_20   (0x1 << 10)
+#define DATA_BIT_WIDTH_40   (0x2 << 10)


ditto.


+
+/* register 0x25 */
+#define PHY_GEN_MAX_1_5 (0x0 << 10)
+#define PHY_GEN_MAX_3_0 (0x1 << 10)
+#define PHY_GEN_MAX_6_0 (0x2 << 10)


ditto.

FWIW,

Acked-by: Sebastian Hesselbarth 


+
+#define BERLIN_SATA_PHY_NB 2
+
+#define to_berlin_sata_phy_priv(desc)  \
+   container_of((desc), struct phy_berlin_priv, phys[(desc)->index])
+
+struct phy_berlin_desc {
+   struct phy  *phy;
+   u32 val;
+   unsignedindex;
+};
+
+struct phy_berlin_priv {
+   void __iomem*base;
+   spinlock_t  lock;
+   struct phy_berlin_desc  phys[BERLIN_SATA_PHY_NB];
+};
+
+static inline void phy_berlin_sata_reg_setbits(void __iomem *ctrl_reg, u32 reg,
+  u32 mask, u32 val)
+{
+   u32 regval;
+
+   /* select register */
+   writel(PHY_BASE + reg, ctrl_reg + PORT_VSR_ADDR);
+
+   /* set bits */
+   regval = readl(ctrl_reg + PORT_VSR_DATA);
+   regval &= ~mask;
+   regval |= val;
+   writel(regval, ctrl_reg + PORT_VSR_DATA);
+}
+
+static int phy_berlin_sata_power_on(struct phy *phy)
+{
+   struct phy_berlin_desc *desc = phy_get_drvdata(phy);
+   struct phy_berlin_priv *priv = to_berlin_sata_phy_priv(desc);
+   void __iomem *ctrl_reg = priv->base + 0x60 + (desc->index * 0x80);
+   int ret = 0;
+   u32 regval;
+
+   spin_lock(&priv->lock);
+
+   /* Power on PHY */
+   writel(CONTROL_REGISTER, priv->base + HOST_VSA_ADDR);
+   regval = readl(priv->base + HOST_VSA_DATA);
+   regval &= ~(desc->val);
+   writel(regval, priv->base + HOST_VSA_DATA);
+
+   /* Configure MBus */
+   writel(MBUS_SIZE_CONTROL, priv->base + HOST_VSA_ADDR);
+   regval = readl(priv->base + HOST_VSA_DATA);
+   regval |= MBUS_WRITE_REQUEST_SIZE_128 | MBUS_READ_REQUEST_SIZE_128;
+   writel(regval, priv->base + HOST_VSA_DATA);
+
+   /* set PHY mode and ref freq to 25 MHz */
+   phy_berlin_sata_reg_setbits(ctrl_reg, 0x1, 0xff,
+   REF_FREF_SEL_25 | PHY_MODE_SATA);
+
+   /* set PHY up to 6 Gbps */
+   phy_berlin_sata_reg_setbits(ctrl_reg, 0x25, 0xc00, PHY_GEN_MAX_6_0);
+
+   /* set 40 bits width */
+   phy_berlin_sata_reg_setbits(ctrl_reg, 0x23,  0xc00, DATA_BIT_WIDTH_40);
+
+   /* use max pll rate */
+   phy_berlin_sata_reg_setbits(ctrl_reg, 0x2, 0x0, USE_MAX_PLL_RATE);
+
+   /* set the controller speed */
+   writel(0x31, ctrl_reg + PORT_SCR_CTL);
+
+   spin_unlock(&priv->lock);
+
+   return ret;
+}
+
+static int phy_berlin_sata_power_off(struct phy *phy)
+{
+   struct phy_berlin_desc *desc = phy_get_drvdata(phy);
+   struct phy_berlin_priv *priv = to_berlin_sata_phy_priv(desc);
+   u32 regval;
+
+   spin_lock(&priv->lock);
+
+   /* Power down PHY */
+   writel(CONTROL_REGISTER, priv->base + HOST_VSA_ADDR);
+   regval = re

Re: [PATCH 1/3] perf: disable sampled events if no PMU interrupt

[Peter Zijlstra]

On Fri, May 16, 2014 at 05:12:12PM -0400, Vince Weaver wrote:
> 
> Add common code to generate ENOTSUPP at event creation time if an 
> architecture attempts to create a sampled event and PERF_PMU_NO_INTERRUPT
> is set.
> 
> This adds a new pmu->capabilities flag.  
> Initially we only support PERF_PMU_NO_INTERRUPT (to indicate a PMU
> has no support for generating hardware interrupts) but there are 
> other capabilities that can be added later.
> 
> Signed-off-by: Vince Weaver 
> 
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 3356abc..2164763 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -251,9 +251,20 @@ struct pmu {
>* flush branch stack on context-switches (needed in cpu-wide mode)
>*/
>   void (*flush_branch_stack)  (void);
> +
> + /*
> +  * various common per-pmu feature flags
> +  */
> + int capabilities;

As suggested by Will, I've put it in a 4 byte hole earlier in the
structure.

>  };
>  
>  /**
> + * struct pmu->capabilites flags

Due to braindamage from years of C++ coding, many other comments refer
to members using the C++ :: notation, so I've changed that to be
consistent and read: pmu::capabilities.

> + */
> +#define PERF_PMU_NO_INTERRUPT1

Are you ok with me making that:

#define PERF_PMU_CAP_NO_INTERRUPT   0x01


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] perf, ARM: use common PMU interrupt disabled code

[Peter Zijlstra]

On Mon, May 19, 2014 at 04:57:10PM +0100, Will Deacon wrote:
> On Fri, May 16, 2014 at 10:15:49PM +0100, Vince Weaver wrote:
> > 
> > Make the ARM perf code use the new common PMU interrupt disabled code.
> > 
> > This allows perf to work on ARM machines without a working PMU
> > interrupt (for example, raspberry pi).
> > 
> > Signed-off-by: Vince Weaver 
> > 
> > diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
> > index a6bc431..4238bcb 100644
> > --- a/arch/arm/kernel/perf_event.c
> > +++ b/arch/arm/kernel/perf_event.c
> > @@ -410,7 +410,7 @@ __hw_perf_event_init(struct perf_event *event)
> >  */
> > hwc->config_base|= (unsigned long)mapping;
> >  
> > -   if (!hwc->sample_period) {
> > +   if (!is_sampling_event(event)) {
> > /*
> >  * For non-sampling runs, limit the sample_period to half
> >  * of the counter width. That way, the new counter value
> > diff --git a/arch/arm/kernel/perf_event_cpu.c 
> > b/arch/arm/kernel/perf_event_cpu.c
> > index 51798d7..63d95fa 100644
> > --- a/arch/arm/kernel/perf_event_cpu.c
> > +++ b/arch/arm/kernel/perf_event_cpu.c
> > @@ -126,8 +126,8 @@ static int cpu_pmu_request_irq(struct arm_pmu *cpu_pmu, 
> > irq_handler_t handler)
> >  
> > irqs = min(pmu_device->num_resources, num_possible_cpus());
> > if (irqs < 1) {
> > -   pr_err("no irqs for PMUs defined\n");
> > -   return -ENODEV;
> > +   printk_once("no irqs for PMU defined, sampled events not 
> > supported\n");
> 
> s/sampled/sampling/
> 
> > +   return 0;
> > }
> >  
> > irq = platform_get_irq(pmu_device, 0);
> > @@ -191,6 +191,11 @@ static void cpu_pmu_init(struct arm_pmu *cpu_pmu)
> > /* Ensure the PMU has sane values out of reset. */
> > if (cpu_pmu->reset)
> > on_each_cpu(cpu_pmu->reset, cpu_pmu, 1);
> > +
> > +   /* If no interrupts available, set the corresponding capability flag */
> > +   if (platform_get_irq(cpu_pmu->plat_device, 0) <= 0) {
> 
> I think you can just do if (!platform_get_irq(cpu_pmu->plat_device, 0))
> here (I appreciate the ARM perf code isn't consistent here).
> 
> Anyway, with those minor changes:
> 
>   Acked-by: Will Deacon 

I did those two changes (and one of my own), thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] irqchip: gic: preserve gic V2 bypass bits in cpu ctrl register

[Marc Zyngier]

On Tue, May 20 2014 at  2:26:33 am BST, Feng Kan  wrote:
>>>  #ifdef CONFIG_CPU_PM
>>> @@ -613,7 +636,7 @@ static void gic_cpu_restore(unsigned int gic_nr)
>>>   dist_base + GIC_DIST_PRI + i * 4);
>>>
>>>   writel_relaxed(GIC_INT_PRI_THRESHOLD, cpu_base + GIC_CPU_PRIMASK);
>>> - writel_relaxed(GIC_CPU_ENABLE, cpu_base + GIC_CPU_CTRL);
>>> + gic_cpu_if_up();
>>
>> Have you tested the save/restore path? It seems that we dont save
>> GICC_CTLR, so it may not do what you think it will...
>
> We are debating which is the better method. Currently we are only
> disabling the GIC distributor so it is not a problem. Later on, with
> more aggressive PM we could have the helper core to setup the GIC CTLR
> prior to releasing out of the PM state. However, it seems it would be
> more cleaner if we save off the GIC_CTLR bits in the
> gic_cpu_save. This would add additional items in to the
> gic_chip_data. Would you be open to that?

I'm open to anything that looks reasonable and doesn't introduce
regressions. Saving/restoring the CPU interface state should be fine.

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] gpio: Add support for Intel SoC PMIC (Crystal Cove)

[Zhu, Lejun]

On 5/20/2014 4:30 PM, Mika Westerberg wrote:
> On Mon, May 19, 2014 at 01:39:33PM +0300, Mika Westerberg wrote:
>> On Wed, May 14, 2014 at 11:44:07PM +0800, Zhu, Lejun wrote:
>>> Devices based on Intel SoC products such as Baytrail have a Power
>>> Management IC. In the PMIC there are subsystems for voltage regulation,
>>> A/D conversion, GPIO and PWMs. The PMIC in Baytrail-T platform is called
>>> Crystal Cove.
>>>
>>> This patch adds support for the GPIO function in Crystal Cove.
>>
>> I have few comments as well in addition to comments from Linus and
>> Alexandre.
> 
> One more thing, I just remembered. The crystal cove GPIO driver is
> supposed to provide ACPI Operation Regions to the ASL code so you need
> to make sure you have ACPI handle associated with the device before you
> register your driver to the GPIO core.
> 

ACPI OpRegions is still under work, and will be submitted separately.
I'll fix the rest in v2. Thank you.

Best Regards
Lejun

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] renameat2 arch support

[Miklos Szeredi]

Hi Linus,

I've collected architecture patches for the renameat2 syscall that maintainers
acked and/or asked me to queue.

Please pull:

  git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git renameat2

This adds architecture support for the renameat2 syscall to m68k, parisc, ia64
and through asm-generic to arc, arm64, c6x, hexagon, metag, openrisc, score,
tile, unicore32.

Thanks,
Miklos


James Hogan (2):
  asm-generic: Add renameat2 syscall
  scripts/checksyscalls.sh: Make renameat optional

Miklos Szeredi (3):
  m68k: add renameat2 syscall
  parisc: add renameat2 syscall
  ia64: add renameat2 syscall

---
 arch/ia64/include/asm/unistd.h| 2 +-
 arch/ia64/include/uapi/asm/unistd.h   | 1 +
 arch/ia64/kernel/entry.S  | 1 +
 arch/m68k/include/asm/unistd.h| 2 +-
 arch/m68k/include/uapi/asm/unistd.h   | 1 +
 arch/m68k/kernel/syscalltable.S   | 1 +
 arch/parisc/include/uapi/asm/unistd.h | 3 ++-
 arch/parisc/kernel/syscall_table.S| 1 +
 include/uapi/asm-generic/unistd.h | 4 +++-
 scripts/checksyscalls.sh  | 5 -
 10 files changed, 16 insertions(+), 5 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/7] phy: add a driver for the Berlin SATA PHY

[Antoine Ténart]

On Tue, May 20, 2014 at 11:11:17AM +0200, Sebastian Hesselbarth wrote:
> On 05/20/2014 11:04 AM, Antoine Ténart wrote:
> >+#define HOST_VSA_ADDR   0x0
> >+#define HOST_VSA_DATA   0x4
> >+#define PORT_VSR_ADDR   0x78
> >+#define PORT_VSR_DATA   0x7c
> 
> Above two lines are indented with spaces.

Indeed ... sorry for that.

> >+#define PORT_SCR_CTL0x2c
> >+
> >+#define CONTROL_REGISTER0x0
> >+#define MBUS_SIZE_CONTROL   0x4
> >+
> >+#define POWER_DOWN_PHY0 BIT(6)
> >+#define POWER_DOWN_PHY1 BIT(14)
> >+#define MBUS_WRITE_REQUEST_SIZE_128 (BIT(2) << 16)
> >+#define MBUS_READ_REQUEST_SIZE_128  (BIT(2) << 19)
> >+
> >+#define PHY_BASE0x200
> 
> ditto.
> 
> >+
> >+/* register 0x01 */
> >+#define REF_FREF_SEL_25 BIT(0)
> >+#define PHY_MODE_SATA   (0x0 << 5)
> 
> ditto.
> 
> >+
> >+/* register 0x02 */
> >+#define USE_MAX_PLL_RATEBIT(12)
> 
> ditto.
> 
> >+
> >+/* register 0x23 */
> >+#define DATA_BIT_WIDTH_10   (0x0 << 10)
> >+#define DATA_BIT_WIDTH_20   (0x1 << 10)
> >+#define DATA_BIT_WIDTH_40   (0x2 << 10)
> 
> ditto.
> 
> >+
> >+/* register 0x25 */
> >+#define PHY_GEN_MAX_1_5 (0x0 << 10)
> >+#define PHY_GEN_MAX_3_0 (0x1 << 10)
> >+#define PHY_GEN_MAX_6_0 (0x2 << 10)
> 
> ditto.

Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] mtd: delete unneeded call to platform_get_drvdata

[Dan Carpenter]

On Tue, May 20, 2014 at 01:35:31AM -0700, Brian Norris wrote:
> > > >  static int bf5xx_nand_resume(struct platform_device *dev)
> > > >  {
> > > > -   struct bf5xx_nand_info *info = platform_get_drvdata(dev);
> > > > -
> > > > return 0;
> > >
> > > In this case bf5xx_nand_suspend/resume could be removed?
> > 
> > I don't know.  It looks like it is intentional to have a definition that
> > returns an indication of success?  The complete set of definitions is:
> 
> I'm not so sure. I believe suspend/resume works just fine without the
> hooks, if those hooks would otherwise be doing nothing. It is notable
> that this driver is not using the modern dev_pm_ops form of the
> suspend/resume callbacks, so maybe it just hasn't aged gracefully--and
> possibly was never supported properly in the first place.
> 

These are called from platform_legacy_suspend/platform_legacy_resume.
It looks like the functions are not needed.

(I am not an expert on pm, I just querried my Smatch Cross Function
Database which is awesome).

regards,
dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] gpio: Add support for Intel SoC PMIC (Crystal Cove)

[Zhu, Lejun]

On 5/19/2014 10:13 PM, Mathias Nyman wrote:
> On 05/19/2014 03:27 AM, Zhu, Lejun wrote:
>>
>>
>> On 5/17/2014 1:33 AM, Linus Walleij wrote:
>>> On Wed, May 14, 2014 at 5:44 PM, Zhu, Lejun  
>>> wrote:
>>>
 Devices based on Intel SoC products such as Baytrail have a Power
 Management IC. In the PMIC there are subsystems for voltage regulation,
 A/D conversion, GPIO and PWMs. The PMIC in Baytrail-T platform is called
 Crystal Cove.

 This patch adds support for the GPIO function in Crystal Cove.

 Signed-off-by: Yang, Bin 
 Signed-off-by: Zhu, Lejun 
>>>
>>> (...)
>>>
 +config GPIO_INTEL_SOC_PMIC
 +   bool "GPIO on Intel SoC PMIC"
 +   depends on INTEL_SOC_PMIC
>>
>> Thank you. That's a long list and all of them indeed need to be fixed.
>> I'll work on them and submit v2 when ready.
>>
> 
> Shouldn't there be a .remove function undoing everything probe did?
> Freeing interrupts, removing irq domains, calling gpiochip_remove etc.
> 
> Or is there something I'm missing?
> I see there's no option to compile this as module, but It might be added 
> later so
> proper remove function would still be nice.
> 
> -Mathias
> 

Good suggestion. I'll fix it. Thanks.

Best Regards
Lejun

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/4] regulator: Add TPS65917 Bindings

[Keerthy]

Add TPS65917 Regulator Bindings.

Signed-off-by: Keerthy 
---
 .../bindings/regulator/tps65917-pmic.txt   |   67 
 1 file changed, 67 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/tps65917-pmic.txt

diff --git a/Documentation/devicetree/bindings/regulator/tps65917-pmic.txt 
b/Documentation/devicetree/bindings/regulator/tps65917-pmic.txt
new file mode 100644
index 000..96d1fb7
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps65917-pmic.txt
@@ -0,0 +1,67 @@
+* tps65917 regulator IP block devicetree bindings
+
+Required properties:
+- compatible : Should be
+  ti,tps65917-pmic
+
+- interrupt-parent : The parent interrupt controller which is tps65917.
+- interrupts : The interrupt number and the type which can be looked up here:
+  arch/arm/boot/dts/include/dt-bindings/interrupt-controller/irq.h
+- interrupts-name: The names of the individual interrupts.
+
+Optional nodes:
+- regulators : Must contain a sub-node per regulator from the list below.
+  Each sub-node should contain the constraints and initialization
+  information for that regulator. See regulator.txt for a
+  description of standard properties for these sub-nodes.
+  Additional custom properties  are listed below.
+
+  Optional sub-node properties:
+  ti,warm-reset - maintain voltage during warm reset(boolean)
+  ti,roof-floor - This takes as optional argument on platform 
supporting
+  the rail from desired external control. If there is no argument 
then
+  it will be assume that it is controlled by NSLEEP pin.
+  The valid value for external pins are:
+   ENABLE1 then 1,
+   ENABLE2 then 2 or
+   NSLEEP then 3.
+  ti,mode-sleep - mode to adopt in pmic sleep 0 - off, 1 - auto,
+  2 - eco, 3 - forced pwm
+  ti,smps-range - OTP has the wrong range set for the hardware so 
override
+  0 - low range, 1 - high range.
+
+- ti,system-power-controller: Telling whether or not this pmic is controlling
+ the system power.
+
+Example:
+
+#include 
+
+pmic {
+   compatible = "ti,tps65917-pmic";
+   interrupt-parent = <&tps65917>;
+   interrupts = <14 IRQ_TYPE_NONE>;
+   interrupts-name = "short-irq";
+
+   ti,system-power-controller;
+
+   regulators {
+   smps1_reg : smps1 {
+   regulator-name = "smps1";
+   regulator-min-microvolt = < 60>;
+   regulator-max-microvolt = <150>;
+   regulator-always-on;
+   regulator-boot-on;
+   ti,warm-reset;
+   ti,roof-floor = <1>; /* ENABLE1 control */
+   ti,mode-sleep = <0>;
+   ti,smps-range = <1>;
+   };
+
+   ldo1_reg: ldo1 {
+   regulator-name = "ldo1";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   };
+   };
+};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/4] tps65917: Drivers for TPS65917 PMIC

[Keerthy]

The TPS65917 chip is a power management IC for Portable Navigation Systems
and Tablet Computing devices. It contains the following components:

 - Regulators.
 - GPADC.
 - Over Temperature warning and Shut down.

This patch series adds support for TPS65917 mfd device. At this time only
the regulator functionality is made available.

The closest drivers are PALMAS series drivers.
The register set is changed. Bit-field defenitions are changed.
Hence based on the PALMAS drivers and created a new set of drivers
with code changes as required.

The patches are boot tested on DRA72-EVM.

Keerthy (4):
  MFD: DT bindings for the TPS65917 family MFD
  Regulators: Add TPS65917 Bindings
  mfd: tps65917: Add driver for the TPS65917 PMIC
  regulator: tps65917: Add Regulator driver for TPS65917 PMIC

 Documentation/devicetree/bindings/mfd/tps65917.txt |   35 +
 .../bindings/regulator/tps65917-pmic.txt   |   67 +
 drivers/mfd/Kconfig|   12 +
 drivers/mfd/Makefile   |1 +
 drivers/mfd/tps65917.c |  573 
 drivers/regulator/Kconfig  |   12 +
 drivers/regulator/Makefile |1 +
 drivers/regulator/tps65917-regulator.c |  810 +++
 include/linux/mfd/tps65917.h   | 1509 
 9 files changed, 3020 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/tps65917.txt
 create mode 100644 
Documentation/devicetree/bindings/regulator/tps65917-pmic.txt
 create mode 100644 drivers/mfd/tps65917.c
 create mode 100644 drivers/regulator/tps65917-regulator.c
 create mode 100644 include/linux/mfd/tps65917.h

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 4/7] ata: ahci_platform: add the Marvell Berlin AHCI compatible

[Sebastian Hesselbarth]

On 05/20/2014 11:04 AM, Antoine Ténart wrote:

The Marvell Berlin AHCI has all his specific in the PHY driver. It then
only need to use the libahci functions to work properly.


If it is that generic, ..


Add its compatible into the libahci_platform driver.

Signed-off-by: Antoine Ténart 
---
  drivers/ata/ahci_platform.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index ef67e79944f9..bc050aabf206 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -76,6 +76,7 @@ static const struct of_device_id ahci_of_match[] = {
{ .compatible = "snps,exynos5440-ahci", },
{ .compatible = "ibm,476gtr-ahci", },
{ .compatible = "snps,dwc-ahci", },
+   { .compatible = "marvell,berlin-ahci", },


.. why have a Marvell-specific compatible?

How about "generic-ahci" instead, like we have for other fooHCIs
already?

Sebastian


{},
  };
  MODULE_DEVICE_TABLE(of, ahci_of_match);



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 4/4] regulator: tps65917: Add Regulator driver for TPS65917 PMIC

[Keerthy]

This patch adds support for TPS65917 PMIC regulators.

The regulators set consists of 5 SMPSs and 5 LDOs. The output
voltages are configurable and are meant to supply power to the
main processor and other components.

Signed-off-by: Keerthy 
---
Comments fixed in V2:

  Used the standard functions in helpers.c
  Added a NULL entry in of_tps65917_match_tbl table.
  Used linear ranges instead of open coded function.

 drivers/regulator/Kconfig  |   12 +
 drivers/regulator/Makefile |1 +
 drivers/regulator/tps65917-regulator.c |  810 
 3 files changed, 823 insertions(+)
 create mode 100644 drivers/regulator/tps65917-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 903eb37..6455a6e 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -581,6 +581,18 @@ config REGULATOR_TPS65912
help
This driver supports TPS65912 voltage regulator chip.
 
+config REGULATOR_TPS65917
+   tristate "TI TPS65917 PMIC Regulators"
+   depends on MFD_TPS65917
+   help
+ If you wish to control the regulators on the TPS65917 series of
+ chips say Y here. This will enable support for all the software
+ controllable SMPS/LDO regulators.
+
+ The regulators available on TPS65917 series chips vary depending
+ on the muxing. This is handled automatically in the driver by
+ reading the mux info from OTP.
+
 config REGULATOR_TPS80031
tristate "TI TPS80031/TPS80032 power regualtor driver"
depends on MFD_TPS80031
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 12ef277..115ee53 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_REGULATOR_TPS6524X) += tps6524x-regulator.o
 obj-$(CONFIG_REGULATOR_TPS6586X) += tps6586x-regulator.o
 obj-$(CONFIG_REGULATOR_TPS65910) += tps65910-regulator.o
 obj-$(CONFIG_REGULATOR_TPS65912) += tps65912-regulator.o
+obj-$(CONFIG_REGULATOR_TPS65917) += tps65917-regulator.o
 obj-$(CONFIG_REGULATOR_TPS80031) += tps80031-regulator.o
 obj-$(CONFIG_REGULATOR_TWL4030) += twl-regulator.o
 obj-$(CONFIG_REGULATOR_VEXPRESS) += vexpress.o
diff --git a/drivers/regulator/tps65917-regulator.c 
b/drivers/regulator/tps65917-regulator.c
new file mode 100644
index 000..929bd50
--- /dev/null
+++ b/drivers/regulator/tps65917-regulator.c
@@ -0,0 +1,810 @@
+/*
+ * Driver for Regulator part of TPS65917 PMIC
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * 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.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License version 2 for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct regs_info {
+   char*name;
+   char*sname;
+   u8  vsel_addr;
+   u8  ctrl_addr;
+   int sleep_id;
+};
+
+static const struct regulator_linear_range smps_low_ranges[] = {
+   REGULATOR_LINEAR_RANGE(50, 0x1, 0x6, 0),
+   REGULATOR_LINEAR_RANGE(51, 0x7, 0x79, 1),
+   REGULATOR_LINEAR_RANGE(165, 0x7A, 0x7f, 0),
+};
+
+static const struct regulator_linear_range smps_high_ranges[] = {
+   REGULATOR_LINEAR_RANGE(100, 0x1, 0x6, 0),
+   REGULATOR_LINEAR_RANGE(102, 0x7, 0x79, 2),
+   REGULATOR_LINEAR_RANGE(330, 0x7A, 0x7f, 0),
+};
+
+static const struct regs_info tps65917_regs_info[] = {
+   {
+   .name   = "SMPS1",
+   .sname  = "smps1-in",
+   .vsel_addr  = TPS65917_SMPS1_VOLTAGE,
+   .ctrl_addr  = TPS65917_SMPS1_CTRL,
+   .sleep_id   = TPS65917_EXTERNAL_REQSTR_ID_SMPS1,
+   },
+   {
+   .name   = "SMPS2",
+   .sname  = "smps2-in",
+   .vsel_addr  = TPS65917_SMPS2_VOLTAGE,
+   .ctrl_addr  = TPS65917_SMPS2_CTRL,
+   .sleep_id   = TPS65917_EXTERNAL_REQSTR_ID_SMPS2,
+   },
+   {
+   .name   = "SMPS3",
+   .sname  = "smps3-in",
+   .vsel_addr  = TPS65917_SMPS3_VOLTAGE,
+   .ctrl_addr  = TPS65917_SMPS3_CTRL,
+   .sleep_id   = TPS65917_EXTERNAL_REQSTR_ID_SMPS3,
+   },
+   {
+   .name   = "SMPS4",
+   .sname  = "smps4-in",
+   .vsel_addr  = TPS65917_SMPS4_VOLTAGE,
+   .ctrl_addr  = TPS65917_SMPS4_CTRL,
+   .sl