Re: [PATCH 0/2] pinctrl: rockchip: fix handling of first pinbank

[Linus Walleij]

On Wed, Mar 26, 2014 at 12:56 AM, Heiko Stübner  wrote:

> Therefore I put together the following two patches to go on top of
> your patch and also make rockchip_set_mux honor this situation.

Both patches applied for fixes.

Yours,
Linus Walleij
--
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] rt2x00: BUG: remove double loop on REGISTER_BUSY_COUNT

[Richard Genoud]

rt2x00usb_register_read_lock() calls rt2x00usb_vendor_req_buff_lock()
that calls rt2x00usb_vendor_request() which is already looping up to
REGISTER_BUSY_COUNT times.

So this loop is not needed.

Signed-off-by: Richard Genoud 
---
 drivers/net/wireless/rt2x00/rt2x00usb.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/rt2x00/rt2x00usb.c 
b/drivers/net/wireless/rt2x00/rt2x00usb.c
index 10572452cc21..14142b099019 100644
--- a/drivers/net/wireless/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/rt2x00/rt2x00usb.c
@@ -148,12 +148,9 @@ int rt2x00usb_regbusy_read(struct rt2x00_dev *rt2x00dev,
if (!test_bit(DEVICE_STATE_PRESENT, >flags))
return -ENODEV;
 
-   for (i = 0; i < REGISTER_BUSY_COUNT; i++) {
-   rt2x00usb_register_read_lock(rt2x00dev, offset, reg);
-   if (!rt2x00_get_field32(*reg, field))
-   return 1;
-   udelay(REGISTER_BUSY_DELAY);
-   }
+   rt2x00usb_register_read_lock(rt2x00dev, offset, reg);
+   if (!rt2x00_get_field32(*reg, field))
+   return 1;
 
rt2x00_err(rt2x00dev, "Indirect register access failed: offset=0x%.08x, 
value=0x%.08x\n",
   offset, *reg);
-- 
1.8.5.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: [BUG] x86: reboot doesn't reboot

[H. Peter Anvin]

On 04/03/2014 06:41 AM, Steven Rostedt wrote:
> On Thu, 03 Apr 2014 14:30:50 +0800
> "Li, Aubrey"  wrote:
> 
> 
>> May I know if "reboot=t" make any difference on your system with the change?
> 
> Is this the future fix? Or do you have patches for me to test. I'll be
> happy to test any patches you have on this box. If you need to know
> anything about this box, let me know and I'll run any command that
> would help you.
> 

Could you tell which of these modes work on your box:

reboot=t
reboot=k
reboot=b(BIOS only)
reboot=a
reboot=e(EFI only)
reboot=p

-hpa


--
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] pinctrl: rockchip: fix offset of mux registers for rk3188

[Linus Walleij]

On Mon, Mar 24, 2014 at 11:36 PM, Beniamino Galvani  wrote:

> The correct value of .mux_offset for rk3188 seems to be 0x60
> instead of 0x68.
>
> Signed-off-by: Beniamino Galvani 

Patch applied to fixes with Heiko's Review tag and also
copied some info from the conversation into the commit message.

Yours,
Linus Walleij
--
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] ipc,shm: disable shmmax and shmall by default

[Kamezawa Hiroyuki]

(2014/04/03 9:20), Davidlohr Bueso wrote:

The default size for shmmax is, and always has been, 32Mb.
Today, in the XXI century, it seems that this value is rather small,
making users have to increase it via sysctl, which can cause
unnecessary work and userspace application workarounds[1].

Instead of choosing yet another arbitrary value, larger than 32Mb,
this patch disables the use of both shmmax and shmall by default,
allowing users to create segments of unlimited sizes. Users and
applications that already explicitly set these values through sysctl
are left untouched, and thus does not change any of the behavior.

So a value of 0 bytes or pages, for shmmax and shmall, respectively,
implies unlimited memory, as opposed to disabling sysv shared memory.
This is safe as 0 cannot possibly be used previously as SHMMIN is
hardcoded to 1 and cannot be modified.

This change allows Linux to treat shm just as regular anonymous memory.
One important difference between them, though, is handling out-of-memory
conditions: as opposed to regular anon memory, the OOM killer will not
kill processes that are hogging memory through shm, allowing users to
potentially abuse this. To overcome this situation, the shm_rmid_forced
option must be enabled.

Running this patch through LTP, everything passes, except the following,
which, due to the nature of this change, is quite expected:

shmget021  TFAIL  :  call succeeded unexpectedly

[1]: http://rhaas.blogspot.com/2012/06/absurd-shared-memory-limits.html

Signed-off-by: Davidlohr Bueso 


looks good to me
Acked-by: KAMEZAWA Hiroyuki 

When this goes mainline, updating a man page of ipcs may be required.

Thanks,
-Kame


---
  include/linux/shm.h  | 2 +-
  include/uapi/linux/shm.h | 8 
  ipc/shm.c| 6 --
  3 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/include/linux/shm.h b/include/linux/shm.h
index 1e2cd2e..0ca06a3 100644
--- a/include/linux/shm.h
+++ b/include/linux/shm.h
@@ -4,7 +4,7 @@
  #include 
  #include 

-#define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide (pages) */
+#define SHMALL 0 /* max shm system wide (pages) */
  #include 
  struct shmid_kernel /* private to the kernel */
  { 
diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h
index 78b6941..5f0ef28 100644
--- a/include/uapi/linux/shm.h
+++ b/include/uapi/linux/shm.h
@@ -9,14 +9,14 @@

  /*
   * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can
- * be increased by sysctl
+ * be increased by sysctl. By default, disable SHMMAX and SHMALL with
+ * 0 bytes, thus allowing processes to have unlimited shared memory.
   */
-
-#define SHMMAX 0x200/* max shared seg size (bytes) */
+#define SHMMAX 0/* max shared seg size (bytes) */
  #define SHMMIN 1   /* min shared seg size (bytes) */
  #define SHMMNI 4096/* max num of segs system wide */
  #ifndef __KERNEL__
-#define SHMALL (SHMMAX/getpagesize()*(SHMMNI/16))
+#define SHMALL 0
  #endif
  #define SHMSEG SHMMNI  /* max shared segs per process */

diff --git a/ipc/shm.c b/ipc/shm.c
index 7645961..ae01ffa 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -490,10 +490,12 @@ static int newseg(struct ipc_namespace *ns, struct 
ipc_params *params)
int id;
vm_flags_t acctflag = 0;

-   if (size < SHMMIN || size > ns->shm_ctlmax)
+   if (ns->shm_ctlmax &&
+   (size < SHMMIN || size > ns->shm_ctlmax))
return -EINVAL;

-   if (ns->shm_tot + numpages > ns->shm_ctlall)
+   if (ns->shm_ctlall &&
+   ns->shm_tot + numpages > ns->shm_ctlall)
return -ENOSPC;

shp = ipc_rcu_alloc(sizeof(*shp));




--
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: [Linaro-acpi] How to pass I2C platform_data under ACPI

[Pallala, Ramakrishna]

>> > > And initialize the platform data in either driver or in separate 
>> > > module which gets compiled along with driver?
>> > 
>> > Typically it has been done in the same driver but I don't see any 
>> > problems having a separate module as well.
>> > 
>> > > static const struct acpi_device_id my_acpi_match[] = {
>> > >   { "MYID0001", (kernel_ulong_t)_platform_data1 }
>> > >   { "MYID0002", (kernel_ulong_t)_platform_data2 }
>> > >   ...
>> > >   { },
>> 
>> We definitely don't want per-board match entries, that does not scale.
>> The driver should be reasonably generic and get all the necessary data 
>> out of well-defined tables. You can have different IDs when there are 
>> only a few cases that are actually relevant, but it has to be 
>> conceivable that the same driver get used on future hardware without 
>> changes.
>
>Yes, I meant that when the platform data information is not available in ACPI 
>namespace, then (and only then) pass the data by means of different IDs.
>
>Preferably this information is included in the ACPI namespace.

The idea is use the single platform_data struct  and initiaze it accordingly 
from the driver's __init call based on the board/platform.

Thanks for your inputs.
Ram.
--
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 3/3] nand: pl353: Add driver for arm pl353 smc nand interface

[Michal Simek]

Hi Brian,

On 03/27/2014 07:21 PM, Punnaiah Choudary Kalluri wrote:
> Add driver for arm pl353 static memory controller nand interface.
> This controller is used in xilinx zynq soc for interfacing the nand
> flash memory.
> 
> Signed-off-by: Punnaiah Choudary Kalluri 
> ---
>  drivers/mtd/nand/Kconfig  |8 +
>  drivers/mtd/nand/Makefile |1 +
>  drivers/mtd/nand/pl353_nand.c | 1122 
> +
>  3 files changed, 1131 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/mtd/nand/pl353_nand.c

Any comment regarding this nand driver?

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




signature.asc
Description: OpenPGP digital signature

/proc/kmalloc

[Pietro Paolini]

Hello everyone,

I have read here  - http://lwn.net/Articles/124374/ - a way to debug 
the kmalloc allocation() and free() which are performed in my system, 
that patch could really help me in solving a problem I am facing. By 
the way that patch does not work for my kernel and I can see that 
sources
are really different, I am using 2.6.33.5, is that patch provided for 
that version as well or do we have similar ways to achieve the same 
result  ?



Thanks in advance,
Pietro.


--
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] fuse update for 3.15

[Miklos Szeredi]

Hi Linus,

Please pull the following:

  git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git for-linus

This series adds cached writeback support to fuse, improving write throughput.

Thanks,
Miklos


Maxim Patlasov (3):
  fuse: Trust kernel i_mtime only
  fuse: restructure fuse_readpage()
  fuse: fuse_flush() should wait on writeback

Pavel Emelyanov (8):
  fuse: Linking file to inode helper
  fuse: Prepare to handle short reads
  fuse: Connection bit for enabling writeback
  fuse: Trust kernel i_size only
  fuse: Flush files on wb close
  fuse: Implement write_begin/write_end callbacks
  fuse: Fix O_DIRECT operations vs cached writeback misorder
  fuse: Turn writeback cache on

Rajat Jain (1):
  fuse: fix "uninitialized variable" warning

---
 fs/fuse/cuse.c|   5 +-
 fs/fuse/dir.c | 119 ---
 fs/fuse/file.c| 286 +-
 fs/fuse/fuse_i.h  |  22 +++-
 fs/fuse/inode.c   |  29 -
 include/uapi/linux/fuse.h |   7 +-
 6 files changed, 384 insertions(+), 84 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: [Linaro-acpi] How to pass I2C platform_data under ACPI

[mika.westerb...@linux.intel.com]

On Thu, Apr 03, 2014 at 03:34:30PM +0200, Arnd Bergmann wrote:
> On Thursday 03 April 2014 14:38:33 mika.westerb...@linux.intel.com wrote:
> > On Thu, Apr 03, 2014 at 11:25:34AM +, Pallala, Ramakrishna wrote:
> > > >> In non ACPI environment I used to initialize the platform_data under 
> > > >> board or platforms files. Under ACPI how do I do that?
> > > >
> > > >If you can't extract that information from ACPI namespace, then one 
> > > >option is to pass platform data along with the device ACPI ID:
> > > >
> > > >static const struct acpi_device_id my_acpi_match[] = {
> > > > { "MYID0001", (kernel_ulong_t)_platform_data }
> > > > ...
> > > > { },
> > > >};
> > > 
> > > Thanks for the Quick reply.
> > > 
> > > So If I  want to use different platform_data for different boards can I
> > > do something like below?
> > 
> > Exactly.
> > 
> > > And initialize the platform data in either driver or in separate module
> > > which gets compiled along with driver?
> > 
> > Typically it has been done in the same driver but I don't see any problems
> > having a separate module as well.
> > 
> > > static const struct acpi_device_id my_acpi_match[] = {
> > >   { "MYID0001", (kernel_ulong_t)_platform_data1 }
> > >   { "MYID0002", (kernel_ulong_t)_platform_data2 }
> > >   ...
> > >   { },
> 
> We definitely don't want per-board match entries, that does not scale.
> The driver should be reasonably generic and get all the necessary data
> out of well-defined tables. You can have different IDs when there
> are only a few cases that are actually relevant, but it has to be
> conceivable that the same driver get used on future hardware without
> changes.

Yes, I meant that when the platform data information is not available in
ACPI namespace, then (and only then) pass the data by means of different
IDs.

Preferably this information is included in the ACPI namespace.
--
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: 3.14 regression: huge latency in read/select on tun

[Eric Dumazet]

On Thu, 2014-04-03 at 06:19 -0700, Eric Dumazet wrote:

> It seems TSO support is broken.

If bug is in tun.c you have this list of changes  you could bisect
from :

# git log --oneline v3.13..v3.14 drivers/net/tun.c
6671b2240c54 tun: remove bogus hardware vlan acceleration flags from 
vlan_features
99932d4fc03a netdevice: add queue selection fallback handler for 
ndo_select_queue
93e14b6d776e tun: add device name(iff) field to proc fdinfo entry
fa35864e0bb7 tuntap: Fix for a race in accessing numqueues
0a379e21c503 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
fbe4d4565bad tun, rfs: fix the incorrect hash value
9bc8893937c8 tun: Add support for RFS on tun flows
143c90549494 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
3958afa1b272 net: Change skb_get_rxhash to skb_get_hash
42404c091510 Revert "tun: remove useless codes in tun_chr_aio_read() and 
tun_recvmsg()"
73713357ab58 tun: remove useless codes in tun_chr_aio_read() and tun_recvmsg()
34f9f437104b Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
f96eb74c84eb tun: remove unused parameter in tun_do_read()
92d4ea6e412a tun: spelling fixes


--
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] clk: Add driver for Palmas clk32kg and clk32kgaudio clocks

[Nishanth Menon]

On 04/03/2014 05:52 AM, Peter Ujfalusi wrote:
[...]
>  .../devicetree/bindings/clock/clk-palmas.txt   |  35 +++
>  drivers/clk/Kconfig|   7 +
>  drivers/clk/Makefile   |   1 +
>  drivers/clk/clk-palmas.c   | 307 
> +
>  include/dt-bindings/mfd/palmas.h   |  18 ++
>  5 files changed, 368 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/clk-palmas.txt
>  create mode 100644 drivers/clk/clk-palmas.c
>  create mode 100644 include/dt-bindings/mfd/palmas.h


Only complaint i have is based on :
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2a9330010bea5982a5c6593824bc036bf62d67b7

you may want to split the new binding off to a separate patch.
Otherwise, personally, I think it is an good evolution, thanks for
doing it.


-- 
Regards,
Nishanth Menon
--
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 syscall

[Miklos Szeredi]

Hi Linus,

I think I addressed all issues with this series:

 - i_mutex on non-directories being moved needed for NFS
 - split ext4_rename() into cross-rename/plain-rename functions
 - split i_op->rename(), it's certainly easier to maintain pre merge, then we'll
   see
 - xfstests validation added
 - whiteout patch added (but not in this pull)

Please pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git cross-rename

Thanks,
Miklos
---

This series adds a new syscall, renameat2(), which is the same as renameat() but
with a flags argument.

The purpose of extending rename is to add cross-rename, a symmetric variant of
rename, which exchanges the two files.  This allows interesting things, which
were not possible before, for example atomically replacing a directory tree with
a symlink, etc...  This also allows overlayfs and friends to operate on
whiteouts atomically.

Andy Lutomirski also suggested a "noreplace" flag, which disables the
overwriting behavior of rename.

These two flags, RENAME_EXCHANGE and RENAME_NOREPLACE are only implemented for
ext4 as an example and for testing.
---

J. Bruce Fields (1):
  vfs: lock_two_nondirectories: allow directory args

Miklos Szeredi (11):
  vfs: add d_is_dir()
  vfs: rename: move d_move() up
  vfs: rename: use common code for dir and non-dir
  vfs: add renameat2 syscall
  vfs: add RENAME_NOREPLACE flag
  security: add flags to rename hooks
  vfs: add cross-rename
  ext4: rename: create ext4_renament structure for local vars
  ext4: rename: move EMLINK check up
  ext4: rename: split out helper functions
  ext4: add cross rename support

---
 Documentation/filesystems/Locking  |   6 +-
 Documentation/filesystems/vfs.txt  |  16 +
 arch/x86/syscalls/syscall_64.tbl   |   1 +
 .../lustre/lustre/include/linux/lustre_compat25.h  |   4 +-
 drivers/staging/lustre/lustre/lvfs/lvfs_linux.c|   2 +-
 fs/cachefiles/namei.c  |   4 +-
 fs/dcache.c|  50 ++-
 fs/ecryptfs/inode.c|   2 +-
 fs/ext4/namei.c| 480 +++--
 fs/inode.c |  25 +-
 fs/namei.c | 315 +++---
 fs/nfsd/vfs.c  |   2 +-
 include/linux/dcache.h |   8 +-
 include/linux/fs.h |   4 +-
 include/linux/security.h   |  12 +-
 include/uapi/linux/fs.h|   3 +
 security/security.c|  22 +-
 17 files changed, 643 insertions(+), 313 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/

[PATCH] pinctrl: lantiq: Fix header file include guard

[Axel Lin]

Define __PINCTRL_LANTIQ_H to prevent multiple inclusion.

Signed-off-by: Axel Lin 
---
 drivers/pinctrl/pinctrl-lantiq.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/pinctrl-lantiq.h b/drivers/pinctrl/pinctrl-lantiq.h
index 6d07f02..c7cfad5 100644
--- a/drivers/pinctrl/pinctrl-lantiq.h
+++ b/drivers/pinctrl/pinctrl-lantiq.h
@@ -10,6 +10,7 @@
  */
 
 #ifndef __PINCTRL_LANTIQ_H
+#define __PINCTRL_LANTIQ_H
 
 #include 
 #include 
-- 
1.8.1.2



--
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] x86: clearing access bit don't flush tlb

[Shaohua Li]

On Thu, Apr 03, 2014 at 01:35:37PM +0200, Ingo Molnar wrote:
> 
> * Shaohua Li  wrote:
> 
> > Add a few acks and resend this patch.
> > 
> > We use access bit to age a page at page reclaim. When clearing pte access 
> > bit,
> > we could skip tlb flush in X86. The side effect is if the pte is in tlb and 
> > pte
> > access bit is unset in page table, when cpu access the page again, cpu will 
> > not
> > set page table pte's access bit. Next time page reclaim will think this hot
> > page is yong and reclaim it wrongly, but this doesn't corrupt data.
> > 
> > And according to intel manual, tlb has less than 1k entries, which covers < 
> > 4M
> > memory. In today's system, several giga byte memory is normal. After page
> > reclaim clears pte access bit and before cpu access the page again, it's 
> > quite
> > unlikely this page's pte is still in TLB. And context swich will flush tlb 
> > too.
> > The chance skiping tlb flush to impact page reclaim should be very rare.
> > 
> > Originally (in 2.5 kernel maybe), we didn't do tlb flush after clear access 
> > bit.
> > Hugh added it to fix some ARM and sparc issues. Since I only change this for
> > x86, there should be no risk.
> > 
> > And in some workloads, TLB flush overhead is very heavy. In my simple
> > multithread app with a lot of swap to several pcie SSD, removing the tlb 
> > flush
> > gives about 20% ~ 30% swapout speedup.
> > 
> > Signed-off-by: Shaohua Li 
> > Acked-by: Rik van Riel 
> > Acked-by: Mel Gorman 
> > Acked-by: Hugh Dickins 
> > ---
> >  arch/x86/mm/pgtable.c |   13 ++---
> >  1 file changed, 6 insertions(+), 7 deletions(-)
> > 
> > Index: linux/arch/x86/mm/pgtable.c
> > ===
> > --- linux.orig/arch/x86/mm/pgtable.c2014-03-27 05:22:08.572100549 
> > +0800
> > +++ linux/arch/x86/mm/pgtable.c 2014-03-27 05:46:12.456131121 +0800
> > @@ -399,13 +399,12 @@ int pmdp_test_and_clear_young(struct vm_
> >  int ptep_clear_flush_young(struct vm_area_struct *vma,
> >unsigned long address, pte_t *ptep)
> >  {
> > -   int young;
> > -
> > -   young = ptep_test_and_clear_young(vma, address, ptep);
> > -   if (young)
> > -   flush_tlb_page(vma, address);
> > -
> > -   return young;
> > +   /*
> > +* In X86, clearing access bit without TLB flush doesn't cause data
> > +* corruption. Doing this could cause wrong page aging and so hot pages
> > +* are reclaimed, but the chance should be very rare.
> 
> So, beyond the spelling mistakes, I guess this explanation should also 
> be a bit more explanatory - how about something like:
> 
>   /*
>* On x86 CPUs, clearing the accessed bit without a TLB flush 
>* doesn't cause data corruption. [ It could cause incorrect
>* page aging and the (mistaken) reclaim of hot pages, but the
>* chance of that should be relatively low. ]
>*
>* So as a performance optimization don't flush the TLB when 
>* clearing the accessed bit, it will eventually be flushed by 
>* a context switch or a VM operation anyway. [ In the rare 
>* event of it not getting flushed for a long time the delay 
>* shouldn't really matter because there's no real memory 
>* pressure for swapout to react to. ]
>*/
> 
> Agreed?

Sure, that's better, 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/

[PATCH] pinctrl: adi2: Statize adi_gpio_irq_domain_ops

[Axel Lin]

It's only referenced in this file, make it static.

Signed-off-by: Axel Lin 
---
 drivers/pinctrl/pinctrl-adi2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-adi2.c b/drivers/pinctrl/pinctrl-adi2.c
index 0cc0eec..5c44feb 100644
--- a/drivers/pinctrl/pinctrl-adi2.c
+++ b/drivers/pinctrl/pinctrl-adi2.c
@@ -927,7 +927,7 @@ static int adi_gpio_irq_map(struct irq_domain *d, unsigned 
int irq,
return 0;
 }
 
-const struct irq_domain_ops adi_gpio_irq_domain_ops = {
+static const struct irq_domain_ops adi_gpio_irq_domain_ops = {
.map = adi_gpio_irq_map,
.xlate = irq_domain_xlate_onecell,
 };
-- 
1.8.3.2



--
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: [BUG] x86: reboot doesn't reboot

[Matthew Garrett]

On Thu, Apr 03, 2014 at 09:41:55AM -0400, Steven Rostedt wrote:
> On Thu, 03 Apr 2014 14:30:50 +0800
> "Li, Aubrey"  wrote:
> 
> 
> > May I know if "reboot=t" make any difference on your system with the change?
> 
> Is this the future fix? Or do you have patches for me to test. I'll be
> happy to test any patches you have on this box. If you need to know
> anything about this box, let me know and I'll run any command that
> would help you.

I think what this tells us is we should revert the patch and never try 
0xcf9 by default.

-- 
Matthew Garrett | mj...@srcf.ucam.org
--
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/

[rfc]pwm: add BCM2835 PWM driver

[Bart Tanghe]

need some recommendation
the memory mapped io registers of the bcm2835 pwm hardware are spreaded 
over the memory mapped io 
gpio config 0x2024 - clk config 0x201010A0 - pwm configuration 0x2020C000
to handle this, I've used the base address of the memory mapped io 
so I can use positive offsets

this give some nasty stuff in for instance, /proc/iomem
Has anyone got a nice solution?

Signed-off-by: Bart Tanghe 
---
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 22f2f28..977e5f6 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -62,6 +62,17 @@ config PWM_ATMEL_TCB
  To compile this driver as a module, choose M here: the module
  will be called pwm-atmel-tcb.
 
+config PWM_BCM2835
+   tristate "BCM2835 PWM support"
+   depends on ARCH_BCM2835 || ARCH_BCM2708
+   help
+ PWM framework driver for BCM2835 controller (raspberry pi)
+
+ The pwm core frequency is set on 1Mhz, period above 1000 are accepted.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-bcm2835.
+
 config PWM_BFIN
tristate "Blackfin PWM support"
depends on BFIN_GPTIMERS
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index d8906ec..9863590 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_PWM_SYSFS) += sysfs.o
 obj-$(CONFIG_PWM_AB8500)   += pwm-ab8500.o
 obj-$(CONFIG_PWM_ATMEL)+= pwm-atmel.o
 obj-$(CONFIG_PWM_ATMEL_TCB)+= pwm-atmel-tcb.o
+obj-$(CONFIG_PWM_BCM2835)  += pwm-bcm2835.o
 obj-$(CONFIG_PWM_BFIN) += pwm-bfin.o
 obj-$(CONFIG_PWM_EP93XX)   += pwm-ep93xx.o
 obj-$(CONFIG_PWM_IMX)  += pwm-imx.o
diff --git a/drivers/pwm/pwm-bcm2835.c b/drivers/pwm/pwm-bcm2835.c
new file mode 100644
index 000..29d7108
--- /dev/null
+++ b/drivers/pwm/pwm-bcm2835.c
@@ -0,0 +1,300 @@
+/*
+ * pwm-bcm2835 driver
+ * Standard raspberry pi (gpio18 - pwm0)
+ *
+ * Copyright (C) 2014 Thomas more
+ *
+ */
+
+/*#define DEBUG*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*mmio regiser mapping*/
+#define OFFSET_PWM 0x0020C000
+#define DUTY   0x14
+#define PERIOD 0x10
+#define CHANNEL0x10
+
+#define OFFSET_CLK 0x001010A0
+#define DIV0x04
+
+#define OFFSET_ALT 0x0024
+
+/*Value defines*/
+/*pwm clock configuration*/
+#define PWMCLK_CNTL_OFF (0x5A00 | (1 << 5))
+#define PWMCLK_CNTL_ON (0x5A00 | 0x11)
+
+#define PWM_ENABLE 0x0001
+#define PWM_POLARITY   0x0010
+/*+-1MHz pwm clock*/
+#define PWMCLK_DIV (0x5A00 | (19 << 12))
+/*ALT5 mask gpio18*/
+#define ALTOR  0x0200
+#define ALTAND 0xFAFF
+/*pwm configuration*/
+#define MASK_CTL_PWM   0x00FF
+#define CTL_PWM0x0081
+
+#define DRIVER_AUTHOR "Bart Tanghe "
+#define DRIVER_DESC   "A bcm2835 pwm driver - raspberry pi development 
platform\
+- only gpio 18 channel0 available"
+
+unsigned long *ptrPWM;
+unsigned long *ptrPERIOD;
+unsigned long *ptrDUTY;
+unsigned long *ptrCLK;
+unsigned long *ptrALT;
+unsigned long *ptrDIV;
+
+struct bcm2835_pwm_chip {
+   struct pwm_chip chip;
+   struct device *dev;
+   int channel;
+   void __iomem *mmio;
+};
+
+static inline struct bcm2835_pwm_chip *to_bcm2835_pwm_chip(
+struct pwm_chip *chip){
+   return container_of(chip, struct bcm2835_pwm_chip, chip);
+}
+
+static int bcm2835_pwm_config(struct pwm_chip *chip,
+struct pwm_device *pwm, int duty_ns, int period_ns){
+
+   struct bcm2835_pwm_chip *pc;
+
+   pc = container_of(chip, struct bcm2835_pwm_chip, chip);
+
+   iowrite32(duty_ns/1000, ptrDUTY);
+   iowrite32(period_ns/1000, ptrPERIOD);
+
+   #ifdef DEBUG
+   printk(KERN_DEBUG "period %x\n", (unsigned int)ptrPERIOD);
+   printk(KERN_DEBUG "duty %x\n", (unsigned int)ptrDUTY);
+   #endif
+
+   return 0;
+}
+
+static int bcm2835_pwm_enable(struct pwm_chip *chip,
+struct pwm_device *pwm){
+   struct bcm2835_pwm_chip *pc;
+
+   pc = container_of(chip, struct bcm2835_pwm_chip, chip);
+
+   /*TODO: channel 1 enable*/
+   #ifdef DEBUG
+   printk(KERN_DEBUG "pwm label: %s\n", pwm->label);
+   printk(KERN_DEBUG "pwm hwpwm: %d\n", pwm->hwpwm);
+   printk(KERN_DEBUG "pwm pwm: %d\n", pwm->pwm);
+   #endif
+
+   iowrite32(ioread32(ptrPWM) | PWM_ENABLE, ptrPWM);
+   #ifdef DEBUG
+   printk(KERN_DEBUG "pwm: %x\n", ioread32(ptrPWM));
+   #endif
+   return 0;
+}
+
+static void bcm2835_pwm_disable(struct pwm_chip *chip,
+   struct pwm_device *pwm)
+{
+   struct bcm2835_pwm_chip *pc;
+
+   pc = to_bcm2835_pwm_chip(chip);
+
+   #ifdef DEBUG
+   printk(KERN_DEBUG "pwm label: %s\n", pwm->label);
+   printk(KERN_DEBUG "pwm hwpwm: %d\n", 

Re: [BUG] x86: reboot doesn't reboot

[Steven Rostedt]

On Thu, 03 Apr 2014 14:30:50 +0800
"Li, Aubrey"  wrote:


> May I know if "reboot=t" make any difference on your system with the change?

Is this the future fix? Or do you have patches for me to test. I'll be
happy to test any patches you have on this box. If you need to know
anything about this box, let me know and I'll run any command that
would help you.

Thanks,

-- Steve
--
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] blkdev: use an efficient way to check merge flags

[Jianyu Zhan]

Hi, Jan,

I've just renewed the patch as you suggusted. Actually it isn't quite 
performance sensitive, but the point is one less branch leads to
less penalty caused by branch prediction failure. Ok, this may be 
way too paranoid.:-)

A bitwise flag comparison could be done using a more efficient bit-ops
way, by mimicking GCC logic of optimizing such bitwise comparison.

Signed-off-by: Jianyu Zhan 
---
 include/linux/blkdev.h | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 1e1fa3f..f2b79fc 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -655,16 +655,18 @@ static inline bool rq_mergeable(struct request *rq)
 static inline bool blk_check_merge_flags(unsigned int flags1,
 unsigned int flags2)
 {
-   if ((flags1 & REQ_DISCARD) != (flags2 & REQ_DISCARD))
-   return false;
-
-   if ((flags1 & REQ_SECURE) != (flags2 & REQ_SECURE))
-   return false;
-
-   if ((flags1 & REQ_WRITE_SAME) != (flags2 & REQ_WRITE_SAME))
-   return false;
-
-   return true;
+   /*
+* Check whether all tree flags are the same in both
+* flags.
+*
+* Replace original three-if's comparision with a
+* more efficient method, by mimicking the GCC logic of
+* optimizing such bitwise comparion. This makes GCC
+* to spit out most compact and least brach code.
+*/
+   return ((flags1 ^ flags2) &
+   (REQ_DISCARD | REQ_SECURE | REQ_WRITE_SAME))
+   == 0;
 }
 
 static inline bool blk_write_same_mergeable(struct bio *a, struct bio *b)
-- 
1.9.0.GIT

--
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: [Linaro-acpi] How to pass I2C platform_data under ACPI

[Arnd Bergmann]

On Thursday 03 April 2014 14:38:33 mika.westerb...@linux.intel.com wrote:
> On Thu, Apr 03, 2014 at 11:25:34AM +, Pallala, Ramakrishna wrote:
> > >> In non ACPI environment I used to initialize the platform_data under 
> > >> board or platforms files. Under ACPI how do I do that?
> > >
> > >If you can't extract that information from ACPI namespace, then one option 
> > >is to pass platform data along with the device ACPI ID:
> > >
> > >static const struct acpi_device_id my_acpi_match[] = {
> > > { "MYID0001", (kernel_ulong_t)_platform_data }
> > > ...
> > > { },
> > >};
> > 
> > Thanks for the Quick reply.
> > 
> > So If I  want to use different platform_data for different boards can I
> > do something like below?
> 
> Exactly.
> 
> > And initialize the platform data in either driver or in separate module
> > which gets compiled along with driver?
> 
> Typically it has been done in the same driver but I don't see any problems
> having a separate module as well.
> 
> > static const struct acpi_device_id my_acpi_match[] = {
> >   { "MYID0001", (kernel_ulong_t)_platform_data1 }
> >   { "MYID0002", (kernel_ulong_t)_platform_data2 }
> >   ...
> >   { },

We definitely don't want per-board match entries, that does not scale.
The driver should be reasonably generic and get all the necessary data
out of well-defined tables. You can have different IDs when there
are only a few cases that are actually relevant, but it has to be
conceivable that the same driver get used on future hardware without
changes.

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 v2 01/11] base: power: Add generic OF-based power domain look-up

[Ulf Hansson]

On 3 April 2014 14:30, Tomasz Figa  wrote:
> Hi Ulf,
>
>
> On 03.04.2014 14:16, Ulf Hansson wrote:
>>
>> On 3 March 2014 17:02, Tomasz Figa  wrote:
>>>
>>> This patch introduces generic code to perform power domain look-up using
>>> device tree and automatically bind devices to their power domains.
>>> Generic device tree binding is introduced to specify power domains of
>>> devices in their device tree nodes.
>>>
>>> Backwards compatibility with legacy Samsung-specific power domain
>>> bindings is provided, but for now the new code is not compiled when
>>> CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
>>> will change as soon as Exynos power domain code gets converted to use
>>> the generic framework in further patch.
>>>
>>> Signed-off-by: Tomasz Figa 
>>> ---
>>>   .../devicetree/bindings/power/power_domain.txt |  51 
>>>   drivers/base/power/domain.c| 298
>>> +
>>>   include/linux/pm_domain.h  |  46 
>>>   kernel/power/Kconfig   |   4 +
>>>   4 files changed, 399 insertions(+)
>>>   create mode 100644
>>> Documentation/devicetree/bindings/power/power_domain.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt
>>> b/Documentation/devicetree/bindings/power/power_domain.txt
>>> new file mode 100644
>>> index 000..93be5d9
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
>>> @@ -0,0 +1,51 @@
>>> +* Generic power domains
>>> +
>>> +System on chip designs are often divided into multiple power domains
>>> that
>>> +can be used for power gating of selected IP blocks for power saving by
>>> +reduced leakage current.
>>> +
>>> +This device tree binding can be used to bind power domain consumer
>>> devices
>>> +with their power domains provided by power domain providers. A power
>>> domain
>>> +provider can be represented by any node in the device tree and can
>>> provide
>>> +one or more power domains. A consumer node can refer to the provider by
>>> +a phandle and a set of phandle arguments (so called power domain
>>> specifier)
>>> +of length specified by #power-domain-cells property in the power domain
>>> +provider node.
>>> +
>>> +==Power domain providers==
>>> +
>>> +Required properties:
>>> + - #power-domain-cells : Number of cells in a power domain specifier;
>>> +   Typically 0 for nodes representing a single power domain and 1 for
>>> nodes
>>> +   providing multiple power domains (e.g. power controllers), but can be
>>> +   any value as specified by device tree binding documentation of
>>> particular
>>> +   provider.
>>
>>
>> I am trying to understand if using a value > 1, ever would make sense.
>> Wouldn't that mean each consumer (device) would actually be a part of
>> more than one power domain? That won't work, right!?
>
>
> Not exactly. Each phandle + #power-domain-cells cells are used just for
> single power domain.
>
> The cells here are used merely as the identifier used by power domain driver
> to translate a power domain specifier from DT to a kernel pointer. It's up
> to driver bindings to select the number of cells to properly identify a
> power domain.
>
> As an example (from different world, but showing the same mechanism), let's
> see a common pattern of GPIO banks on some SoC:
>
> GPA0
> GPA1
> GPB0
> GPB1
> GPC0
> GPC1
>
> One might assign a single-cell ID to each bank ending with a namespace of
> integers from 0 to 5 that would be used as follows:
>
> #define GPA0 0
> #define GPA1 1
> #define GPB0 2
> #define GPB1 3
> #define GPC0 4
> #define GPC1 5
>
> reset-gpios = < GPA0 4>;
>
> However one might also consider assigning one cell to bank set (e.g. GPA)
> and one cell to identify the bank inside of a set, like on the following
> example:
>
> #define GPA 0
> #define GPB 1
> #define GPC 2
>
> reset-gpios = < GPA 0 4>;
>
> Good bindings should allow arbitrary identification schemes to let a driver
> developer use the one that suits the hardware he's working on.
>
>
>>
>> Additionally, there are no corresponding parsing method (like
>> of_genpd_xlate_onecell() ) that support more than one cell.
>
>
> There are two generic xlate helpers provided for the most common cases that
> are likely to be reused by most drivers. For more complex cases it's up to
> the driver to implement its own mapping function. It can be promoted to a
> generic one later if such need shows up.
>
> Best regards,
> Tomasz

Tomasz, thanks for the clarification! I still have more to learn about DT. :-)

Not sure if some additional comments would make this more clear though
- or if it's juts my untrained eye that had a few problems
understanding.

Kind regards
Ulf Hansson
--
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] ASoC: dapm: Add support for multi register mux

[Lars-Peter Clausen]

On 04/03/2014 11:53 AM, Mark Brown wrote:

On Thu, Apr 03, 2014 at 11:47:15AM +0200, Takashi Iwai wrote:


I'm a bit late in the game, but I feel a bit uneasy through looking
at the whole changes.  My primary question is, whether do we really
need to share the same struct soc_enum for the onehot type?  What
makes hard to use a struct soc_enum_onehot for them?  You need
different individual get/put for each type.  We may still need to
change soc_dapm_update stuff, but it's different from sharing
soc_enum.


Indeed, I had thought this was where the discussion was heading - not
looked at this version of the patch yet.



It would be nice, but it also requires some slight restructuring. The issue 
we have right now is that there is  strictly speaking a bit of a layering 
violation. The DAPM widgets should not need to know how the kcontrols that 
are attached to the widget do their IO. What we essentially do in 
dapm_connect_mux() (and also dapm_connect_mixer) is an open-coded version of 
the controls get handler. Replacing that by calling the get handler instead 
should allow us to use different structs for enums and onehot enums.


- Lars
--
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: 3.14 regression: huge latency in read/select on tun

[Eric Dumazet]

On Thu, 2014-04-03 at 09:52 +0200, Ortwin Glück wrote:
> On 02.04.2014 18:42, Eric Dumazet wrote:
> > You could post a tcpdump maybe ?
> 
> This is a dump from on the tun interface (traffic inside the tunnel).
> It's an scp upload of a 2MB file. I aborted after a while when not much
> progress was seen anymore, but you get the idea.
> 
> What I see:
> - Frame 28: long delay because I had to enter the key password
> - Frame 31: the packets seems to be out of order. It has a sequence
> number that is far ahead of previously sent sequence no's. Some
> duplicates and retransmissions follow. That pattern repeats randomly all
> over the trace.
> - from Frame 73 on: ping pong of ACKs and data, while the data is
> delayed by ~200ms caused by the select(). The ping pong also shows that
> there are virtually no packets in flight (see also Window size).

It seems TSO support is broken.

Your trace have no 'big' packets but holes like :

00:41:35.832695 IP 10.243.88.168.35846 > 10.185.85.69.22: Flags [.], ack 6093, 
win 310, options [nop,nop,TS val 78054 ecr 3191538976], length 0
00:41:35.855990 IP 10.243.88.168.35846 > 10.185.85.69.22: Flags [P.], seq 
6696:6776, ack 6093, win 310, options [nop,nop,TS val 78060 ecr 3191538976], 
length 80
00:41:36.047465 IP 10.185.85.69.22 > 10.243.88.168.35846: Flags [P.], seq 
6093:6141, ack 6776, win 218, options [nop,nop,TS val 3191539191 ecr 78060], 
length 48

missing 6776:14144 sequence (6 segments)

00:41:36.048766 IP 10.243.88.168.35846 > 10.185.85.69.22: Flags [.], seq 
14144:15372, ack 6141, win 310, options [nop,nop,TS val 78108 ecr 3191539191], 
length 1228
00:41:36.057995 IP 10.185.85.69.22 > 10.243.88.168.35846: Flags [.], ack 6776, 
win 218, options [nop,nop,TS val 3191539202 ecr 78060,nop,nop,sack 1 
{14144:15372}], length 0

You are 'saved' because retransmits do not use TSO :

00:41:36.058050 IP 10.243.88.168.35846 > 10.185.85.69.22: Flags [.], seq 
6776:8004, ack 6141, win 310, options [nop,nop,TS val 78110 ecr 3191539202], 
length 1228
00:41:36.058070 IP 10.243.88.168.35846 > 10.185.85.69.22: Flags [.], seq 
8004:9232, ack 6141, win 310, options [nop,nop,TS val 78110 ecr 3191539202], 
length 1228

Also receiver seems to be unable to open TCP window, but thats a secondary 
problem.



--
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 does not wake from S3 suspend

[Valerio Vanni]

"Valerio Vanni"  ha scritto nel messaggio
news:lg9etc$9fl$1...@ger.gmane.org

When resuming from S3 suspend, serial console starts sending garbage
on the serial port.
Not continuously, it sends garbage only when in local console prints a
text.
It stops only when the (sending) machine is shut down, or if some
text is sent manually (i.e. with "cat txtfile > /dev/ttyS0").

Full details are here:
https://bugzilla.kernel.org/show_bug.cgi?id=69751


The problem is still present in final 3.14 (and in linux-next).

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

cscope: issue with symlinks in tools/testing/selftests/powerpc/copyloops/

[Yann Droneaud]

Hi,

I'm using cscope to browse kernel sources, but I'm facing warnings from
the tool since following commit:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=22d651dcef536c75f75537290bf3da5038e68b6b

commit 22d651dcef536c75f75537290bf3da5038e68b6b
Author: Michael Ellerman 
Date:   Tue Jan 21 15:22:17 2014 +1100

selftests/powerpc: Import Anton's memcpy / copy_tofrom_user tests

Turn Anton's memcpy / copy_tofrom_user test into something that can
live in tools/testing/selftests.

It requires one turd in arch/powerpc/lib/memcpy_64.S, but it's 
pretty harmless IMHO.

We are sailing very close to the wind with the feature macros. We 
define them to nothing, which currently means we get a few extra 
nops and include the unaligned calls.

Signed-off-by: Anton Blanchard 
Signed-off-by: Michael Ellerman 
Signed-off-by: Benjamin Herrenschmidt 


cscope reports error when generating the cross-reference database:

$ make ALLSOURCE_ARCHS=all O=./obj-cscope/ cscope
  GEN cscope
cscope: cannot find
file 
/home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/copyuser_power7.S
cscope: cannot find
file 
/home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/memcpy_64.S
cscope: cannot find
file 
/home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/memcpy_power7.S
cscope: cannot find
file 
/home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/copyuser_64.S

And when calling cscope from ./obj-cscope/ directory, it reports errors
too.

Hopefully it doesn't stop it from working, so I'm still able to use
cscope to browse kernel sources.

It's a rather uncommon side effect of having (for the first time ?)
sources files as symlinks: looking for symlinks in the kernel sources
returns only:

$ find . -type l
./arch/mips/boot/dts/include/dt-bindings
./arch/microblaze/boot/dts/system.dts
./arch/powerpc/boot/dts/include/dt-bindings
./arch/metag/boot/dts/include/dt-bindings
./arch/arm/boot/dts/include/dt-bindings
./tools/testing/selftests/powerpc/copyloops/copyuser_power7.S
./tools/testing/selftests/powerpc/copyloops/memcpy_64.S
./tools/testing/selftests/powerpc/copyloops/memcpy_power7.S
./tools/testing/selftests/powerpc/copyloops/copyuser_64.S
./obj-cscope/source
./Documentation/DocBook/vidioc-g-sliced-vbi-cap.xml
./Documentation/DocBook/vidioc-decoder-cmd.xml
...
./Documentation/DocBook/media-func-ioctl.xml
./Documentation/DocBook/vidioc-enumoutput.xml


So one can wonder if having symlinked sources files is an expected
supported feature for kbuild and all the various kernel
tools/infrastructure ?

Regarding cscope specifically, it does not support symlink, and it's the
expected behavior according to the bug reports I was able to find:

#214 cscope ignores symlinks to files 
http://sourceforge.net/p/cscope/bugs/214/

#229 -I options doesn't handle symbolic link
http://sourceforge.net/p/cscope/bugs/229/

#247 cscope: cannot find file 
http://sourceforge.net/p/cscope/bugs/247/

#252 cscope: cannot find file *** 
http://sourceforge.net/p/cscope/bugs/252/

#261 Regression - version 15.7a does not follow symbolic links 
http://sourceforge.net/p/cscope/bugs/261/


Regards.

-- 
Yann Droneaud
OPTEYA


--
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: msync: require either MS_ASYNC or MS_SYNC

[Greg Troxel]

"Michael Kerrisk (man-pages)"  writes:

> I think the only reasonable solution is to better document existing
> behavior and what the programmer should do. With that in mind, I've
> drafted the following text for the msync(2) man page:
>
> NOTES
>According to POSIX, exactly one of MS_SYNC and MS_ASYNC  must  be
>specified  in  flags.   However,  Linux permits a call to msync()
>that specifies neither of these flags, with  semantics  that  are
>(currently)  equivalent  to  specifying  MS_ASYNC.   (Since Linux
>2.6.19, MS_ASYNC is in fact a no-op, since  the  kernel  properly
>tracks  dirty  pages  and  flushes them to storage as necessary.)
>Notwithstanding the Linux behavior, portable, future-proof appli‐
>cations  should  ensure  that they specify exactly one of MS_SYNC
>and MS_ASYNC in flags.
>
> Comments on this draft welcome.

I think it's a step backwards to document unspecified behavior.  If
anything, the man page should make it clear that providing neither flag
results in undefined behavior and will lead to failure on systems on
than Linux.  While I can see the point of not changing the previous
behavior to protect buggy code, there's no need to document it in the
man page and further enshrine it.

There's a larger point, which is that people write code for Linux when
they should be writing code for POSIX.  Therefore, Linux has an
obligation to the larger free software community to avoid encouraging
non-portable code.  This is somewhat similar (except for the key point
that it's unintentional) to bash's allowing "==" in test, which is a
gratuitous extension to the standard that has led to large amounts of
nonportable code.  To mitigate this, it would be reasonable to syslog a
warning the first time a process makes a call with flags that POSIX says
leads to undefined behavior.  That would meet the
portability-citizenzhip goals and not break existing systems.


pgpTIbf2O1ttb.pgp
Description: PGP signature

[PATCH V1] drivers/mfd: da9052: use multiwrite mode

[Opensource [Anthony Olech]]

Use the new regmap core API regmap_multi_reg_write(), to prevent a rare
problem with the Dialog DA9052/3 PMIC devices that causes the device to
fail.

Signed-off-by: Anthony Olech 
---

This patch is relative to linux-next repository tag next-20140403

Even though the probability of the problem occurring is exceedingly rare,
the consequences are a bricked device and so this workround is essential.

The patch has been tested using the RTC ALARM function in conjuctions with
an I2C logic analyser.

 drivers/mfd/da9052-i2c.c  |   34 +-
 include/linux/mfd/da9052/da9052.h |   24 
 2 files changed, 25 insertions(+), 33 deletions(-)

diff --git a/drivers/mfd/da9052-i2c.c b/drivers/mfd/da9052-i2c.c
index 6da8ec8..ca6b4f6 100644
--- a/drivers/mfd/da9052-i2c.c
+++ b/drivers/mfd/da9052-i2c.c
@@ -87,27 +87,11 @@ static int da9052_i2c_fix(struct da9052 *da9052, unsigned 
char reg)
return 0;
 }
 
-/*
- * According to errata item 24, multiwrite mode should be avoided
- * in order to prevent register data corruption after power-down.
- */
-static int da9052_i2c_disable_multiwrite(struct da9052 *da9052)
+static int da9052_i2c_config_multiwrite(struct da9052 *da9052, bool enable)
 {
-   int reg_val, ret;
-
-   ret = regmap_read(da9052->regmap, DA9052_CONTROL_B_REG, _val);
-   if (ret < 0)
-   return ret;
-
-   if (!(reg_val & DA9052_CONTROL_B_WRITEMODE)) {
-   reg_val |= DA9052_CONTROL_B_WRITEMODE;
-   ret = regmap_write(da9052->regmap, DA9052_CONTROL_B_REG,
-  reg_val);
-   if (ret < 0)
-   return ret;
-   }
-
-   return 0;
+   return regmap_update_bits(da9052->regmap, DA9052_CONTROL_B_REG,
+   DA9052_CONTROL_B_WRITEMODE,
+   enable ? 0xFF : 0);
 }
 
 static const struct i2c_device_id da9052_i2c_id[] = {
@@ -153,6 +137,8 @@ static int da9052_i2c_probe(struct i2c_client *client,
 
i2c_set_clientdata(client, da9052);
 
+   da9052_regmap_config.can_multi_write = true;
+
da9052->regmap = devm_regmap_init_i2c(client, _regmap_config);
if (IS_ERR(da9052->regmap)) {
ret = PTR_ERR(da9052->regmap);
@@ -161,7 +147,8 @@ static int da9052_i2c_probe(struct i2c_client *client,
return ret;
}
 
-   ret = da9052_i2c_disable_multiwrite(da9052);
+   ret = da9052_i2c_config_multiwrite(da9052,
+   da9052_regmap_config.can_multi_write);
if (ret < 0)
return ret;
 
@@ -182,10 +169,7 @@ static int da9052_i2c_probe(struct i2c_client *client,
}
 
ret = da9052_device_init(da9052, id->driver_data);
-   if (ret != 0)
-   return ret;
-
-   return 0;
+   return ret;
 }
 
 static int da9052_i2c_remove(struct i2c_client *client)
diff --git a/include/linux/mfd/da9052/da9052.h 
b/include/linux/mfd/da9052/da9052.h
index bba65f5..967c802 100644
--- a/include/linux/mfd/da9052/da9052.h
+++ b/include/linux/mfd/da9052/da9052.h
@@ -172,20 +172,28 @@ static inline int da9052_group_write(struct da9052 
*da9052, unsigned char reg,
  unsigned reg_cnt, unsigned char *val)
 {
int ret;
+   unsigned char r = reg;
+   struct reg_default *regs;
int i;
 
+   regs = kmalloc(sizeof(struct reg_default)*reg_cnt, GFP_KERNEL);
+   if (!regs)
+   return -ENOMEM;
+
for (i = 0; i < reg_cnt; i++) {
-   ret = regmap_write(da9052->regmap, reg + i, val[i]);
-   if (ret < 0)
-   return ret;
+   regs[i].reg = r++;
+   regs[i].def = val[i];
}
 
-   if (da9052->fix_io) {
-   ret = da9052->fix_io(da9052, reg);
-   if (ret < 0)
-   return ret;
-   }
+   ret = regmap_multi_reg_write(da9052->regmap, regs, reg_cnt);
+
+   kfree(regs);
+
+   if (ret < 0)
+   return ret;
 
+   if (da9052->fix_io)
+   ret = da9052->fix_io(da9052, reg+reg_cnt-1);
return ret;
 }
 
-- 
end-of-patch 1/1 for drivers/mfd: da9052: use multiwrite mode V1

--
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] stable: Spelling s/than/then

[Julien Pivotto]

Signed-off-by: Julien Pivotto 
---
 Documentation/stable_kernel_rules.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/stable_kernel_rules.txt 
b/Documentation/stable_kernel_rules.txt
index b0714d8..33e1b2c 100644
--- a/Documentation/stable_kernel_rules.txt
+++ b/Documentation/stable_kernel_rules.txt
@@ -39,7 +39,7 @@ Procedure for submitting patches to the -stable tree:
the stable tree without anything else needing to be done by the author
or subsystem maintainer.
  - If the patch requires other patches as prerequisites which can be
-   cherry-picked than this can be specified in the following format in
+   cherry-picked then this can be specified in the following format in
the sign-off area:
 
  Cc:  # 3.3.x: a1f84a3: sched: Check for idle
-- 
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] cpufreq: loongson2_cpufreq: don't declare local variable as static

[Alexandre Oliva]

On Apr  2, 2014, Viresh Kumar  wrote:

> did some changes to driver and by mistake made cpuclk as a 'static' local
> variable, which wasn't actually required. Fix it.

FWIW, the same mistake is present in at32.

I've just finished bisecting the cpufreq regression on loongson2.
Indeed, this s/static// patch does not fix it, but it was 652ed95d5fa,
the patch that moved cpuclk into loongson2_cpufreq_cpu_init, that caused
the regression.

Reverting all the changes to loongson2_cpufreq.c in 652ed95d5fa makes
cpufreq work again, as opposed to printing nan% in all cpufreq stats in
cpufreq-info's output, and freezing shortly thereafter.

> - static struct clk *cpuclk;
> + struct clk *cpuclk;

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
--
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] blkdev: use an efficient way to check merge flags

[Jan Kara]

On Thu 03-04-14 16:00:44, Zhan Jianyu wrote:
> On Thu, Apr 3, 2014 at 2:13 AM, Jan Kara  wrote:
> >   OK, but have you checked the generated code is actually any better? This
> > is something I'd expect a compiler might be able to optimize anyway. And the
> > original code looks more readable to me.
> 
> Hi, Jan,
> 
> I've disassemble the code on my x86_64 box
> (it's inline though, I just look at its call site),
> and found that this patch DOES make it more efficient.
> 
> Orig asm snippt   with
> patch asm snippt
>   
> 
> mov%edx,%ecx  mov%rdx,%r9
> xor%r8d,%ecx xor%r8d,%r8d
> test   $0x80,%cl  and
> $0x380,%r9d
> jne14c5 test   $0x380,%ecx
> and$0x3,%ch  sete   %r8b
> jne14c5 cmp%r8,%r9
> 
> je 14b5 
> 
> This saves a branch.
> 
> Furthermore,  I found that gcc is smart enough to try to optimize the
> code, so if we do
> like this, it will generate the most optimal and smallest code :
> 
> 
> static inline bool blk_check_merge_flags(unsigned int flags1,
> ¦unsigned int flags2)
> {
> return ((flags1 ^ flags2) &
> (REQ_DISCARD | REQ_SECURE | REQ_WRITE_SAME))
> == 0;
> }
> 
> this gives out  :
> 
> mov%edx,%r8d
> xor%ecx,%r8d
> and$0x380,%r8d
> jne14a5 
> 
> But yes, it compromises readibility.
  OK, I'd expect gcc is more clever ;). Thanks for the comparison. Anyway
if that function is performance sensitive, we can use your optimization.
Just add a comment there that we want to check whether the three flags are
the same in both flags and that checking your way generates better code.

Honza
-- 
Jan Kara 
SUSE Labs, CR
--
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: Update the ownership and developers for ACPI in Kconfig

[Hanjun Guo]

The UEFI Forum included the ACPI spec in its portfolio in October 2013
and will host future spec iterations, following the ACPI v5.0a release.

A UEFI Forum working group named ACPI Specification Working Group (ASWG)
has been established to handle future ACPI developments, any UEFI member
can join the group and contribute to ACPI specification.

So update the ownership and developers for ACPI in Kconfig accordingly,
and update the website link to ACPI specification too.

Signed-off-by: Hanjun Guo 
---
 drivers/acpi/Kconfig |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index c205653..831e541 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -32,9 +32,10 @@ menuconfig ACPI
  
 
  ACPI is an open industry specification co-developed by
- Hewlett-Packard, Intel, Microsoft, Phoenix, and Toshiba.
+ ACPI Specification Working Group (ASWG) under UEFI Forum, any
+ UEFI member can join ASWG and contribute to ACPI specification.
  The specification is available at:
- 
+ 
 
 if ACPI
 
-- 
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 v2 01/11] base: power: Add generic OF-based power domain look-up

[Tomasz Figa]

Hi Ulf,

On 03.04.2014 14:16, Ulf Hansson wrote:

On 3 March 2014 17:02, Tomasz Figa  wrote:

This patch introduces generic code to perform power domain look-up using
device tree and automatically bind devices to their power domains.
Generic device tree binding is introduced to specify power domains of
devices in their device tree nodes.

Backwards compatibility with legacy Samsung-specific power domain
bindings is provided, but for now the new code is not compiled when
CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
will change as soon as Exynos power domain code gets converted to use
the generic framework in further patch.

Signed-off-by: Tomasz Figa 
---
  .../devicetree/bindings/power/power_domain.txt |  51 
  drivers/base/power/domain.c| 298 +
  include/linux/pm_domain.h  |  46 
  kernel/power/Kconfig   |   4 +
  4 files changed, 399 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt

diff --git a/Documentation/devicetree/bindings/power/power_domain.txt 
b/Documentation/devicetree/bindings/power/power_domain.txt
new file mode 100644
index 000..93be5d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -0,0 +1,51 @@
+* Generic power domains
+
+System on chip designs are often divided into multiple power domains that
+can be used for power gating of selected IP blocks for power saving by
+reduced leakage current.
+
+This device tree binding can be used to bind power domain consumer devices
+with their power domains provided by power domain providers. A power domain
+provider can be represented by any node in the device tree and can provide
+one or more power domains. A consumer node can refer to the provider by
+a phandle and a set of phandle arguments (so called power domain specifier)
+of length specified by #power-domain-cells property in the power domain
+provider node.
+
+==Power domain providers==
+
+Required properties:
+ - #power-domain-cells : Number of cells in a power domain specifier;
+   Typically 0 for nodes representing a single power domain and 1 for nodes
+   providing multiple power domains (e.g. power controllers), but can be
+   any value as specified by device tree binding documentation of particular
+   provider.


I am trying to understand if using a value > 1, ever would make sense.
Wouldn't that mean each consumer (device) would actually be a part of
more than one power domain? That won't work, right!?


Not exactly. Each phandle + #power-domain-cells cells are used just for 
single power domain.


The cells here are used merely as the identifier used by power domain 
driver to translate a power domain specifier from DT to a kernel 
pointer. It's up to driver bindings to select the number of cells to 
properly identify a power domain.


As an example (from different world, but showing the same mechanism), 
let's see a common pattern of GPIO banks on some SoC:


GPA0
GPA1
GPB0
GPB1
GPC0
GPC1

One might assign a single-cell ID to each bank ending with a namespace 
of integers from 0 to 5 that would be used as follows:


#define GPA0 0
#define GPA1 1
#define GPB0 2
#define GPB1 3
#define GPC0 4
#define GPC1 5

reset-gpios = < GPA0 4>;

However one might also consider assigning one cell to bank set (e.g. 
GPA) and one cell to identify the bank inside of a set, like on the 
following example:


#define GPA 0
#define GPB 1
#define GPC 2

reset-gpios = < GPA 0 4>;

Good bindings should allow arbitrary identification schemes to let a 
driver developer use the one that suits the hardware he's working on.




Additionally, there are no corresponding parsing method (like
of_genpd_xlate_onecell() ) that support more than one cell.


There are two generic xlate helpers provided for the most common cases 
that are likely to be reused by most drivers. For more complex cases 
it's up to the driver to implement its own mapping function. It can be 
promoted to a generic one later if such need shows up.


Best regards,
Tomasz
--
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] perf tools: Fix feature check for libdw dwarf unwind

[Josh Boyer]

When the feature check for libdw dwarf unwind support was added with commit
45757895c7, it required LIBDW_DIR to be set before it would work.  However,
commit 0a4f2b6a3ba implies that the libdw unwinder should be auto-detected
from the installed libraries and not require LIBDW_DIR to be set.

The feature check is failing because FEATURE_CHECK_LDFLAGS-libdw-dwarf-unwind
is only being set when LIBDW_DIR is specified.  This causes the feature test
to be built without -ldw, which causes it to fail.  Fix this by moving the
endif for the LIBDW_DIR check up.

Signed-off-by: Josh Boyer 
---
 tools/perf/config/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index c23418225c2c..d3e3b7a7d979 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -65,10 +65,10 @@ ifndef NO_LIBELF
   ifdef LIBDW_DIR
 LIBDW_CFLAGS  := -I$(LIBDW_DIR)/include
 LIBDW_LDFLAGS := -L$(LIBDW_DIR)/lib
+  endif
 
 FEATURE_CHECK_CFLAGS-libdw-dwarf-unwind := $(LIBDW_CFLAGS)
 FEATURE_CHECK_LDFLAGS-libdw-dwarf-unwind := $(LIBDW_LDFLAGS) -ldw
-  endif
 endif
 
 # include ARCH specific config
-- 
1.8.5.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 v2 01/11] base: power: Add generic OF-based power domain look-up

[Ulf Hansson]

On 3 March 2014 17:02, Tomasz Figa  wrote:
> This patch introduces generic code to perform power domain look-up using
> device tree and automatically bind devices to their power domains.
> Generic device tree binding is introduced to specify power domains of
> devices in their device tree nodes.
>
> Backwards compatibility with legacy Samsung-specific power domain
> bindings is provided, but for now the new code is not compiled when
> CONFIG_ARCH_EXYNOS is selected to avoid collision with legacy code. This
> will change as soon as Exynos power domain code gets converted to use
> the generic framework in further patch.
>
> Signed-off-by: Tomasz Figa 
> ---
>  .../devicetree/bindings/power/power_domain.txt |  51 
>  drivers/base/power/domain.c| 298 
> +
>  include/linux/pm_domain.h  |  46 
>  kernel/power/Kconfig   |   4 +
>  4 files changed, 399 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power/power_domain.txt
>
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt 
> b/Documentation/devicetree/bindings/power/power_domain.txt
> new file mode 100644
> index 000..93be5d9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -0,0 +1,51 @@
> +* Generic power domains
> +
> +System on chip designs are often divided into multiple power domains that
> +can be used for power gating of selected IP blocks for power saving by
> +reduced leakage current.
> +
> +This device tree binding can be used to bind power domain consumer devices
> +with their power domains provided by power domain providers. A power domain
> +provider can be represented by any node in the device tree and can provide
> +one or more power domains. A consumer node can refer to the provider by
> +a phandle and a set of phandle arguments (so called power domain specifier)
> +of length specified by #power-domain-cells property in the power domain
> +provider node.
> +
> +==Power domain providers==
> +
> +Required properties:
> + - #power-domain-cells : Number of cells in a power domain specifier;
> +   Typically 0 for nodes representing a single power domain and 1 for nodes
> +   providing multiple power domains (e.g. power controllers), but can be
> +   any value as specified by device tree binding documentation of particular
> +   provider.

I am trying to understand if using a value > 1, ever would make sense.
Wouldn't that mean each consumer (device) would actually be a part of
more than one power domain? That won't work, right!?

Additionally, there are no corresponding parsing method (like
of_genpd_xlate_onecell() ) that support more than one cell.

Kind regards
Ulf Hansson

> +
> +Example:
> +
> +   power: power-controller@1234 {
> +   compatible = "foo,power-controller";
> +   reg = <0x1234 0x1000>;
> +   #power-domain-cells = <1>;
> +   };
> +
> +The node above defines a power controller that is a power domain provider
> +and expects one cell as its phandle argument.
> +
> +==Power domain consumers==
> +
> +Required properties:
> + - power-domain : A phandle and power domain specifier as defined by bindings
> +  of power controller specified by phandle.
> +
> +Example:
> +
> +   leaky-device@1235 {
> +   compatible = "foo,i-leak-current";
> +   reg = <0x1235 0x1000>;
> +   power-domain = < 0>;
> +   };
> +
> +The node above defines a typical power domain consumer device, which is 
> located
> +inside power domain with index 0 of power controller represented by node with
> +label "power".
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index dc127e5..006b455 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -3,12 +3,16 @@
>   *
>   * Copyright (C) 2011 Rafael J. Wysocki , Renesas Electronics 
> Corp.
>   *
> + * Support for Device Tree based power domain providers:
> + * Copyright (C) 2014 Tomasz Figa 
> + *
>   * This file is released under the GPLv2.
>   */
>
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -2177,3 +2181,297 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
> list_add(>gpd_list_node, _list);
> mutex_unlock(_list_lock);
>  }
> +
> +#ifdef CONFIG_PM_GENERIC_DOMAINS_OF
> +/*
> + * DEVICE TREE BASED POWER DOMAIN PROVIDERS
> + *
> + * The code below implements generic device tree based power domain providers
> + * that bind device tree nodes with generic power domains registered in the
> + * system.
> + *
> + * Any driver that registers generic power domains and need to support 
> binding
> + * of devices to these domains is supposed to register a power domain 
> provider,
> + * which maps a power domain specifier retrieved from device tree to a power
> + * domain.
> + *
> + * Two simple mapping 

[PATCH] sched: fix tracepoint in scheduler.

[Dongsheng Yang]

In function set_task_cpu(), if cpu == new_cpu,
there is no migration happen. But current trace point
will raise a migration trace event.

This patch change trace point to right place,
only when migration really happen, an event will
be threw out.

Signed-off-by: Dongsheng Yang 
---
 kernel/sched/core.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 9cae286..6708aff 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -998,9 +998,8 @@ void set_task_cpu(struct task_struct *p, unsigned int 
new_cpu)
 #endif
 #endif
 
-   trace_sched_migrate_task(p, new_cpu);
-
if (task_cpu(p) != new_cpu) {
+   trace_sched_migrate_task(p, new_cpu);
if (p->sched_class->migrate_task_rq)
p->sched_class->migrate_task_rq(p, new_cpu);
p->se.nr_migrations++;
-- 
1.8.2.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: [BUG] x86: reboot doesn't reboot

[Steven Rostedt]

On Thu, 03 Apr 2014 14:30:50 +0800
"Li, Aubrey"  wrote:


> May I know if "reboot=t" make any difference on your system with the change?

It appears it does. Yes, it boots with "reboot=t" with the patches
applied, and does not reboot without it.

-- Steve
--
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] Fixes to Linux v3.13 - bugs.xenproject.org ones. (v1).

[David Vrabel]

On 08/11/13 17:38, Konrad Rzeszutek Wilk wrote:
> Hey,
> 
> Two of these:
>  [PATCH 2/4] xen/manage: Poweroff forcefully if user-space is not yet
>  [PATCH 4/4] xen/xenbus: Avoid synchronous wait on XenBus stalling
> 
> fix the bugs.xenproject.org outstanding bugs.
> 
> The other ones are that were discovered on xen-devel and discussed.
> They should go in v3.13 and as the merge window is next week I am
> hoping they can be squeezed in then.
> 
> 
>  drivers/xen/manage.c| 64 
> ++---
>  drivers/xen/pci.c   | 47 ++
>  drivers/xen/xenbus/xenbus_xs.c  | 24 ++--
>  include/xen/interface/physdev.h | 11 +++
>  
> Konrad Rzeszutek Wilk (4):
>   xen/mcfg: Call PHYSDEVOP_pci_mmcfg_reserved for MCFG areas.
>   xen/manage: Poweroff forcefully if user-space is not yet up.
>   xen/manage: Guard against user-space initiated poweroff and XenBus.
>   xen/xenbus: Avoid synchronous wait on XenBus stalling shutdown/restart.

Konrad, can you repost a final series please?  I'm not 100% which
patches should be applied.

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: [RFC PATCH 1/2] drivers: mfd: Add support of exynos-pmu driver

[Bartlomiej Zolnierkiewicz]

Hi,

On Wednesday, April 02, 2014 05:24:44 PM Pankaj Dubey wrote:
> From: Younggun Jang 
> 
> This driver is mainly used for setting misc bits of register from PMU IP
> of Exynos SoC which will be required to configure before Suspend/Resume.
> Currently all these settings are done in "arch/arm/mach-exynos/pmu.c" but
> moving ahead for ARM64 based SoC support, there is a need of DT based
> implementation of PMU driver.

PMU support for ARM32 EXYNOS SoCs is heavily SoC dependent and there
is very little code shared between diffirent SoCs.  Unless PMU setup
for Samsung ARM64 SoCs is similar to some existing ARM32 EXYNOS SoCs
it may be better to just add a separate PMU driver for Samsung ARM64
SoCs. IOW it would be best to show that this patch series is really
useful before merging it.

When it comes to the current patches it would be better to do changes
converting PMU support to be a platform driver first for the existing
arch/arm/mach-exynos/pmu.c file and then move+rename this file in
the separate patch.  Currently the code changes are done at the same
time as the code movement which makes them difficult to review/verify.

There are also some minor issues with the new code:

[...]

> diff --git a/drivers/mfd/exynos-pmu.c b/drivers/mfd/exynos-pmu.c
> new file mode 100644
> index 000..24abd9b
> --- /dev/null
> +++ b/drivers/mfd/exynos-pmu.c
> @@ -0,0 +1,534 @@
> +/*
> + * Copyright (c) 2014-2015 Samsung Electronics Co., Ltd.
> + *   http://www.samsung.com/

2015?

[...]

> +static int __init exynos4210_pmu_init(void)
> +{
> + exynos_pmu_config = exynos4210_pmu_config;
> + pmu_data->pmu_id = PMU_EXYNOS4210;
> + pr_info("EXYNOS4210 PMU Initialize\n");
> +
> + return 0;
> +}
> +
> +static int __init exynos4212_pmu_init(void)
> +{
> + exynos_pmu_config = exynos4x12_pmu_config;
> + pmu_data->pmu_id = PMU_EXYNOS4212;
> + pr_info("EXYNOS4x12 PMU Initialize\n");
> +
> + return 0;
> +}
> +
> +static int __init exynos4412_pmu_init(void)
> +{
> + exynos_pmu_config = exynos4x12_pmu_config;
> + pmu_data->pmu_id = PMU_EXYNOS4412;
> + pr_info("EXYNOS4412 PMU Initialize\n");
> +
> + return 0;
> +}
> +
> +static int __init exynos5250_pmu_init(void)
> +{
> + unsigned int value;
> +
> + /*
> +  * When SYS_WDTRESET is set, watchdog timer reset request
> +  * is ignored by power management unit.
> +  */
> + value = __raw_readl(pmu_data->regs + EXYNOS5_AUTO_WDTRESET_DISABLE);
> + value &= ~EXYNOS5_SYS_WDTRESET;
> + __raw_writel(value, pmu_data->regs + EXYNOS5_AUTO_WDTRESET_DISABLE);
> +
> + value = __raw_readl(pmu_data->regs + EXYNOS5_MASK_WDTRESET_REQUEST);
> + value &= ~EXYNOS5_SYS_WDTRESET;
> + __raw_writel(value, pmu_data->regs + EXYNOS5_MASK_WDTRESET_REQUEST);
> +
> + exynos_pmu_config = exynos5250_pmu_config;
> + pmu_data->pmu_id = PMU_EXYNOS5250;
> + pr_info("EXYNOS5250 PMU Initialize\n");
> +
> + return 0;
> +}
> +
> +/*
> + * PMU platform driver and devicetree bindings.
> + */
> +static struct of_device_id exynos_pmu_of_device_ids[] = {
> + {
> + .compatible = "samsung,exynos4210-pmu",
> + .data = (void *)exynos4210_pmu_init
> + },
> + {
> + .compatible = "samsung,exynos4212-pmu",
> + .data = (void *)exynos4212_pmu_init
> + },
> + {
> + .compatible = "samsung,exynos4412-pmu",
> + .data = (void *)exynos4412_pmu_init
> + },
> + {
> + .compatible = "samsung,exynos5250-pmu",
> + .data = (void *)exynos5250_pmu_init
> + },
> + {},
> +};
> +
> +static int exynos_pmu_probe(struct platform_device *pdev)
> +{
> + const struct of_device_id *match;
> + exynos_pmu_init_t exynos_pmu_init;
> + struct resource *res;
> +
> + pmu_data = devm_kzalloc(>dev,
> + sizeof(struct exynos_pmu_data), GFP_KERNEL);
> + if (!pmu_data) {
> + dev_err(>dev, "exynos_pmu driver probe failed\n");
> + return -ENOMEM;
> + }
> +
> + pmu_data->dev = >dev;
> +
> + match = of_match_node(exynos_pmu_of_device_ids, pdev->dev.of_node);
> + exynos_pmu_init = match->data;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + pmu_data->regs = devm_ioremap_resource(>dev, res);

devm_ioremap_resouce() return value should be checked for errors with

if (IS_ERR(pmu_data->regs))
return PTR_ERR(pmu_data->regs);

> +
> + exynos_pmu_init();

exynos*_pmu_init() methods should be void as they always return 0 and
the return value is ignored anyway.

Also they cannot be marked with __init as the driver probe function
itself is not marked with __init (it cannot be beacuse of possibility
of doing unbind/bind through sysfs).

> +
> + return 0;
> +};
> +
> +static int exynos_pmu_remove(struct platform_device *pdev)
> +{
> + exynos_pmu_config = NULL;
> +
> + return 0;
> +}
> +
> +static struct platform_driver 

Re: [PATCH v2] xen: fix memory leak in __xen_pcibk_add_pci_dev()

[David Vrabel]

On 01/04/14 11:15, Daeseok Youn wrote:
> 
> It need to free dev_entry when it failed to assign to a new
> slot on the virtual PCI bus.
> 
> smatch says:
>  drivers/xen/xen-pciback/vpci.c:142 __xen_pcibk_add_pci_dev() warn:
> possible memory leak of 'dev_entry'

Applied to devel/for-linus-3.15.

Thanks.

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] mm: msync: require either MS_ASYNC or MS_SYNC

[Christopher Covington]

On 04/03/2014 04:25 AM, Michael Kerrisk (man-pages) wrote:

> I think the only reasonable solution is to better document existing
> behavior and what the programmer should do. With that in mind, I've
> drafted the following text for the msync(2) man page:
> 
> NOTES
>According to POSIX, exactly one of MS_SYNC and MS_ASYNC  must  be
>specified  in  flags.   However,  Linux permits a call to msync()
>that specifies neither of these flags, with  semantics  that  are
>(currently)  equivalent  to  specifying  MS_ASYNC.   (Since Linux
>2.6.19, MS_ASYNC is in fact a no-op, since  the  kernel  properly
>tracks  dirty  pages  and  flushes them to storage as necessary.)
>Notwithstanding the Linux behavior, portable, future-proof appli‐
>cations  should  ensure  that they specify exactly one of MS_SYNC
>and MS_ASYNC in flags.

Nit: MS_SYNC or MS_ASYNC

Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
--
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 1/1] SMACK: Fix handling value==NULL in post setxattr

[José Bollo]

The function `smack_inode_post_setxattr` is called each
time that a setxattr is done, for any value of name.
The kernel allow to put value==NULL when size==0
to set an empty attribute value. The systematic
call to smk_import_entry was causing the dereference
of a NULL pointer hence a KERNEL PANIC!

The problem can be produced easily by issuing the
command `setfattr -n user.data file` under bash prompt
when SMACK is active.

Moving the call to smk_import_entry as proposed by this
patch is correcting the behaviour because the function
smack_inode_post_setxattr is called for the SMACK's
attributes only if the function smack_inode_setxattr validated
the value and its size (what will not be the case when size==0).

It also has a benefical effect to not fill the smack hash
with garbage values coming from any extended attribute
write.

Change-Id: Iaf0039c2be9bccb6cee11c24a3b44d209101fe47
Signed-off-by: José Bollo 
---
 security/smack/smack_lsm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 3f01cf5..28d482c 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -893,18 +893,20 @@ static void smack_inode_post_setxattr(struct dentry 
*dentry, const char *name,
return;
}
 
-   skp = smk_import_entry(value, size);
if (strcmp(name, XATTR_NAME_SMACK) == 0) {
+   skp = smk_import_entry(value, size);
if (skp != NULL)
isp->smk_inode = skp->smk_known;
else
isp->smk_inode = smack_known_invalid.smk_known;
} else if (strcmp(name, XATTR_NAME_SMACKEXEC) == 0) {
+   skp = smk_import_entry(value, size);
if (skp != NULL)
isp->smk_task = skp;
else
isp->smk_task = _known_invalid;
} else if (strcmp(name, XATTR_NAME_SMACKMMAP) == 0) {
+   skp = smk_import_entry(value, size);
if (skp != NULL)
isp->smk_mmap = skp;
else
-- 
1.8.1.4

--
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] regulator: core: Get and put regulator of_node

[Charles Keepax]

On Thu, Apr 03, 2014 at 12:14:31PM +0100, Mark Brown wrote:
> On Thu, Apr 03, 2014 at 11:58:04AM +0100, Charles Keepax wrote:
> > The main issue I have is that devm_regualtor_register is a bit
> > awkward. With regulator_register you will always be calling
> > regulator_unregister so you can put the of_node there but with
> > devm there isn't really a good place to put the of_node.
> 
> That's why I suggested it might be OK to take a reference in the core -
> this would allow the device probe to safely drop its reference before it
> returns.
> 
> > Would perhaps a sensible thing here be to add an of_node_get to
> > of_regulator_match, since we seem to be expecting that to
> > increase the ref count. And then just add an of_node_put to
> > regulator_unregister. And for anything directly using
> > regulator_register/devm_regulator_register they should add a
> > manual of_node_get?
> 
> That seems very ugly.

Agreed, it is not exactly made of clean interface success. So I
guess the sensible thing is to add a helper to clean up the
of_regulator_match results and add the node get in the regulator
core as per my original patch. I will fix up the commit message
for it and do patches for the other bits.

Thanks,
Charles
--
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] cmdline: Hide "debug" from /proc/cmdline

[Ingo Molnar]

* Borislav Petkov  wrote:

> On Wed, Apr 02, 2014 at 06:47:57PM -0700, Linus Torvalds wrote:
> > Whether it actually fixes the problem that Borislav had is
> > questionable, of course. For all I know, systemd debug mode generates
> > so much data in *other* ways and then causes feedback loops with
> > the kernel debugging that this patch is totally immaterial, and
> > dmesg was never the main issue. But unlike the "hide 'debug' from
> > /proc/cmdline", I think this patch at least _conceptually_ makes a lot
> > of sense, even if systemd gets fixed, so ...
> >
> > Borislav?
> 
> Yes, ratelimiting makes the box actually boot all the way. Here's how it
> looks like:
> 
> ^MLoading Linux 3.12.16-boris-00441-g60dc93e99a75-dirty ...
> ^MLoading initial ramdisk ...
> ^M[0.00] Initializing cgroup subsys cpuset
> [0.00] Initializing cgroup subsys cpu
> [0.00] Initializing cgroup subsys cpuacct
> [0.00] Linux version 3.12.16-boris-00441-g60dc93e99a75-dirty (gcc 
> version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #11 SMP Thu Apr 
> 3 10:19:49 CEST 2014
> [0.00] Command line: 
> BOOT_IMAGE=/@/boot/vmlinuz-3.12.16-boris-00441-g60dc93e99a75-dirty 
> root=UUID=5f1a28cf-d910-
> 4ed0-85ac-0113d43e553f rootflags=subvol=@ 
> resume=/dev/disk/by-uuid/45671aef-cef3-4fcd-9087-7d4f3f81aa70 splash=off showo
> pts crashkernel=256M-:128M pci=hpiosize=0 pci=hpmemsize=4m 
> pciehp.pciehp_force=1 notsc mem=0x400 loop.max_loop=6
> 4 log_buf_len=16M console=tty0 console=ttyS0,38400n8 ignore_loglevel debug
>^
> 
> We haz the "debug" thing on.
> 
> ...
> 
> Here we go:
> 
> [   50.636000] be2net :db:00.0: irq 102 for MSI/MSI-X
> [   50.636000] be2net :db:00.0: irq 103 for MSI/MSI-X
> [   50.636000] be2net :db:00.0: irq 104 for MSI/MSI-X
> [   50.636000] be2net :db:00.0: enabled 4 MSI-x vector(s) for NIC
> [   50.896000] systemd: 1008 callbacks suppressed
>   
> 
> [   50.896000] systemd[1]: Started Show Plymouth Boot Screen.
> [   50.896000] systemd[1]: Got SIGCHLD for process 1192 (swapon)
> [   50.896000] systemd[1]: Child 1192 died (code=exited, status=0/SUCCESS)
> [   50.896000] systemd[1]: Child 1192 belongs to 
> dev-disk-by\x2duuid-45671aef\x2dcef3\x2d4fcd\x2d9087\x2d7d4f3f81aa70.swap
> [   50.896000] systemd[1]: 
> dev-disk-by\x2duuid-45671aef\x2dcef3\x2d4fcd\x2d9087\x2d7d4f3f81aa70.swap 
> swap process exited, code=exited status=0
> [   50.896000] systemd[1]: 
> dev-disk-by\x2duuid-45671aef\x2dcef3\x2d4fcd\x2d9087\x2d7d4f3f81aa70.swap 
> changed activating -> active
> [   50.896000] systemd[1]: Job 
> dev-disk-by\x2duuid-45671aef\x2dcef3\x2d4fcd\x2d9087\x2d7d4f3f81aa70.swap/start
>  finished, result=done
> 
> ...
> 
> [   57.988000] scsi2 : Emulex 10Gbe open-iscsi Initiator Driver
> [   63.028000] be2iscsi :db:00.3: irq 117 for MSI/MSI-X
> [   63.044000] be2iscsi :db:00.3: irq 118 for MSI/MSI-X
> [   63.064000] be2iscsi :db:00.3: irq 119 for MSI/MSI-X
> [   63.08] be2iscsi :db:00.3: irq 120 for MSI/MSI-X
> [   63.10] be2iscsi :db:00.3: irq 121 for MSI/MSI-X
> [   63.116000] be2iscsi :db:00.3: irq 122 for MSI/MSI-X
> [   63.132000] be2iscsi :db:00.3: irq 123 for MSI/MSI-X
> [   63.152000] be2iscsi :db:00.3: irq 124 for MSI/MSI-X
> [   63.572000] scsi host2: BC_373 : Link Down on Port 1
> [   63.588000] scsi host2: BM_4336 : No boot session
> [   63.656000] systemd: 11828 callbacks suppressed
>   ^
> 
> We luvz to talk a lot of crap, don't we.

When I suggested that systemd should reuse the tracing and perf ring 
buffer infrastructure instead of cluttering the syslog it was 
handwaved away...

But at least there's an upside for me: I don't have to deal with the 
systemd maintainers' excessively passive-aggressive behavior ;-)

Thanks,

Ingo
--
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] x86: clearing access bit don't flush tlb

[Ingo Molnar]

* Shaohua Li  wrote:

> Add a few acks and resend this patch.
> 
> We use access bit to age a page at page reclaim. When clearing pte access bit,
> we could skip tlb flush in X86. The side effect is if the pte is in tlb and 
> pte
> access bit is unset in page table, when cpu access the page again, cpu will 
> not
> set page table pte's access bit. Next time page reclaim will think this hot
> page is yong and reclaim it wrongly, but this doesn't corrupt data.
> 
> And according to intel manual, tlb has less than 1k entries, which covers < 4M
> memory. In today's system, several giga byte memory is normal. After page
> reclaim clears pte access bit and before cpu access the page again, it's quite
> unlikely this page's pte is still in TLB. And context swich will flush tlb 
> too.
> The chance skiping tlb flush to impact page reclaim should be very rare.
> 
> Originally (in 2.5 kernel maybe), we didn't do tlb flush after clear access 
> bit.
> Hugh added it to fix some ARM and sparc issues. Since I only change this for
> x86, there should be no risk.
> 
> And in some workloads, TLB flush overhead is very heavy. In my simple
> multithread app with a lot of swap to several pcie SSD, removing the tlb flush
> gives about 20% ~ 30% swapout speedup.
> 
> Signed-off-by: Shaohua Li 
> Acked-by: Rik van Riel 
> Acked-by: Mel Gorman 
> Acked-by: Hugh Dickins 
> ---
>  arch/x86/mm/pgtable.c |   13 ++---
>  1 file changed, 6 insertions(+), 7 deletions(-)
> 
> Index: linux/arch/x86/mm/pgtable.c
> ===
> --- linux.orig/arch/x86/mm/pgtable.c  2014-03-27 05:22:08.572100549 +0800
> +++ linux/arch/x86/mm/pgtable.c   2014-03-27 05:46:12.456131121 +0800
> @@ -399,13 +399,12 @@ int pmdp_test_and_clear_young(struct vm_
>  int ptep_clear_flush_young(struct vm_area_struct *vma,
>  unsigned long address, pte_t *ptep)
>  {
> - int young;
> -
> - young = ptep_test_and_clear_young(vma, address, ptep);
> - if (young)
> - flush_tlb_page(vma, address);
> -
> - return young;
> + /*
> +  * In X86, clearing access bit without TLB flush doesn't cause data
> +  * corruption. Doing this could cause wrong page aging and so hot pages
> +  * are reclaimed, but the chance should be very rare.

So, beyond the spelling mistakes, I guess this explanation should also 
be a bit more explanatory - how about something like:

/*
 * On x86 CPUs, clearing the accessed bit without a TLB flush 
 * doesn't cause data corruption. [ It could cause incorrect
 * page aging and the (mistaken) reclaim of hot pages, but the
 * chance of that should be relatively low. ]
 *
 * So as a performance optimization don't flush the TLB when 
 * clearing the accessed bit, it will eventually be flushed by 
 * a context switch or a VM operation anyway. [ In the rare 
 * event of it not getting flushed for a long time the delay 
 * shouldn't really matter because there's no real memory 
 * pressure for swapout to react to. ]
 */

Agreed?

Thanks,

Ingo
--
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: How to pass I2C platform_data under ACPI

[mika.westerb...@linux.intel.com]

On Thu, Apr 03, 2014 at 11:25:34AM +, Pallala, Ramakrishna wrote:
> >> In non ACPI environment I used to initialize the platform_data under 
> >> board or platforms files. Under ACPI how do I do that?
> >
> >If you can't extract that information from ACPI namespace, then one option 
> >is to pass platform data along with the device ACPI ID:
> >
> >static const struct acpi_device_id my_acpi_match[] = {
> > { "MYID0001", (kernel_ulong_t)_platform_data }
> > ...
> > { },
> >};
> 
> Thanks for the Quick reply.
> 
> So If I  want to use different platform_data for different boards can I
> do something like below?

Exactly.

> And initialize the platform data in either driver or in separate module
> which gets compiled along with driver?

Typically it has been done in the same driver but I don't see any problems
having a separate module as well.

> static const struct acpi_device_id my_acpi_match[] = {
>   { "MYID0001", (kernel_ulong_t)_platform_data1 }
>   { "MYID0002", (kernel_ulong_t)_platform_data2 }
>   ...
>   { },
> 
> Thanks,
> Ram
--
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: How to pass I2C platform_data under ACPI

[Pallala, Ramakrishna]

>> In non ACPI environment I used to initialize the platform_data under 
>> board or platforms files. Under ACPI how do I do that?
>
>If you can't extract that information from ACPI namespace, then one option is 
>to pass platform data along with the device ACPI ID:
>
>static const struct acpi_device_id my_acpi_match[] = {
>   { "MYID0001", (kernel_ulong_t)_platform_data }
>   ...
>   { },
>};

Thanks for the Quick reply.

So If I  want to use different platform_data for different boards can I do 
something like below?
And initialize the platform data in either driver or in separate module which 
gets compiled along with driver?

static const struct acpi_device_id my_acpi_match[] = {
{ "MYID0001", (kernel_ulong_t)_platform_data1 }
{ "MYID0002", (kernel_ulong_t)_platform_data2 }
...
{ },

Thanks,
Ram
--
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] cmdline: Hide "debug" from /proc/cmdline

[Måns Rullgård]

Jiri Kosina  writes:

> On Wed, 2 Apr 2014, Linus Torvalds wrote:
>
>> Steven, Borislav, one thing that strikes me might be a good idea is to 
>> limit the amount of non-kernel noise in dmesg. We already have the 
>> concept of rate-limiting various spammy internal kernel messages for 
>> when device drivers misbehave etc. Maybe we can just add rate-limiting 
>> to the interfaces that add messages to the kernel buffers, and work 
>> around this problem that way instead while waiting for Gregs fix to 
>> percolate? Or are the systemd debug messages going to so many other 
>> places too that that wouldn't really help?
>
> I think that it's in principle a good idea, however ... the in-kernel 
> ratelimiting always happens per sourcecode location, but this will be 
> rather hard to achieve with interface such as /dev/kmsg.
>
> If /dev/kmsg is going to be ratelimited as a whole, it might potentially 
> create a severely unfair situation between individual userspace programs 
> trying to do logging (although there is apparently only one userspace 
> service doing any logging through this interface whatsoever, right?).

The point is that /dev/kmsg is *not* intended as a syslog replacement.

-- 
Måns Rullgård
m...@mansr.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: [RFC PATCH] cmdline: Hide "debug" from /proc/cmdline

[Borislav Petkov]

On Wed, Apr 02, 2014 at 06:47:57PM -0700, Linus Torvalds wrote:
> Whether it actually fixes the problem that Borislav had is
> questionable, of course. For all I know, systemd debug mode generates
> so much data in *other* ways and then causes feedback loops with
> the kernel debugging that this patch is totally immaterial, and
> dmesg was never the main issue. But unlike the "hide 'debug' from
> /proc/cmdline", I think this patch at least _conceptually_ makes a lot
> of sense, even if systemd gets fixed, so ...
>
> Borislav?

Yes, ratelimiting makes the box actually boot all the way. Here's how it
looks like:

^MLoading Linux 3.12.16-boris-00441-g60dc93e99a75-dirty ...
^MLoading initial ramdisk ...
^M[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.12.16-boris-00441-g60dc93e99a75-dirty (gcc 
version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #11 SMP Thu Apr 3 
10:19:49 CEST 2014
[0.00] Command line: 
BOOT_IMAGE=/@/boot/vmlinuz-3.12.16-boris-00441-g60dc93e99a75-dirty 
root=UUID=5f1a28cf-d910-
4ed0-85ac-0113d43e553f rootflags=subvol=@ 
resume=/dev/disk/by-uuid/45671aef-cef3-4fcd-9087-7d4f3f81aa70 splash=off showo
pts crashkernel=256M-:128M pci=hpiosize=0 pci=hpmemsize=4m 
pciehp.pciehp_force=1 notsc mem=0x400 loop.max_loop=6
4 log_buf_len=16M console=tty0 console=ttyS0,38400n8 ignore_loglevel debug
 ^

We haz the "debug" thing on.

...

Here we go:

[   50.636000] be2net :db:00.0: irq 102 for MSI/MSI-X
[   50.636000] be2net :db:00.0: irq 103 for MSI/MSI-X
[   50.636000] be2net :db:00.0: irq 104 for MSI/MSI-X
[   50.636000] be2net :db:00.0: enabled 4 MSI-x vector(s) for NIC
[   50.896000] systemd: 1008 callbacks suppressed


[   50.896000] systemd[1]: Started Show Plymouth Boot Screen.
[   50.896000] systemd[1]: Got SIGCHLD for process 1192 (swapon)
[   50.896000] systemd[1]: Child 1192 died (code=exited, status=0/SUCCESS)
[   50.896000] systemd[1]: Child 1192 belongs to 
dev-disk-by\x2duuid-45671aef\x2dcef3\x2d4fcd\x2d9087\x2d7d4f3f81aa70.swap
[   50.896000] systemd[1]: 
dev-disk-by\x2duuid-45671aef\x2dcef3\x2d4fcd\x2d9087\x2d7d4f3f81aa70.swap swap 
process exited, code=exited status=0
[   50.896000] systemd[1]: 
dev-disk-by\x2duuid-45671aef\x2dcef3\x2d4fcd\x2d9087\x2d7d4f3f81aa70.swap 
changed activating -> active
[   50.896000] systemd[1]: Job 
dev-disk-by\x2duuid-45671aef\x2dcef3\x2d4fcd\x2d9087\x2d7d4f3f81aa70.swap/start 
finished, result=done

...

[   57.988000] scsi2 : Emulex 10Gbe open-iscsi Initiator Driver
[   63.028000] be2iscsi :db:00.3: irq 117 for MSI/MSI-X
[   63.044000] be2iscsi :db:00.3: irq 118 for MSI/MSI-X
[   63.064000] be2iscsi :db:00.3: irq 119 for MSI/MSI-X
[   63.08] be2iscsi :db:00.3: irq 120 for MSI/MSI-X
[   63.10] be2iscsi :db:00.3: irq 121 for MSI/MSI-X
[   63.116000] be2iscsi :db:00.3: irq 122 for MSI/MSI-X
[   63.132000] be2iscsi :db:00.3: irq 123 for MSI/MSI-X
[   63.152000] be2iscsi :db:00.3: irq 124 for MSI/MSI-X
[   63.572000] scsi host2: BC_373 : Link Down on Port 1
[   63.588000] scsi host2: BM_4336 : No boot session
[   63.656000] systemd: 11828 callbacks suppressed
^

We luvz to talk a lot of crap, don't we.

[   63.672000] systemd[1]: Received SIGCHLD from PID 833 (udevadm).
[   63.692000] systemd[1]: Got SIGCHLD for process 833 (udevadm)
[   63.712000] systemd[1]: Child 833 died (code=exited, status=0/SUCCESS)
[   63.732000] systemd[1]: Child 833 belongs to systemd-udev-settle.service
[   63.756000] systemd[1]: systemd-udev-settle.service: main process exited, 
code=exited, status=0/SUCCESS
[   63.788000] systemd[1]: systemd-udev-settle.service changed start -> exited
[   63.812000] systemd[1]: Job systemd-udev-settle.service/start finished, 
result=done
[   63.836000] systemd[1]: Started udev Wait for Complete Device Initialization.

and so on until we get to the boot prompt:

[  186.828000] systemd[3512]: Executing: /etc/postfix/system/wait_qmgr 60
[  186.856000] systemd[3514]: Executing: /etc/postfix/system/cond_slp register
[  186.892000] systemd[3524]: Executing: /usr/sbin/cron -n
[  186.892000] systemd[3525]: Executing: /usr/lib/systemd/systemd-update-utmp 
runlevel
[  186.896000] systemd[3418]: Executing: /etc/init.d/after.local
[  186.956000] systemd[3416]: Execung: /sbin/agetty --noclear tty1
[  186.956000] systemd[3415]: Executing: /sbin/agetty --keep-baud ttyS0 
115200,38400,9600
^M

Welcome to SUSE Linux Enterprise Server 12 Beta1 (x86_64) - Kernel 
3.12.16-boris-00441-g60dc93e99a75-dirty (ttyS0).

...

Then it keeps spitting out crap off and on but it is much more
manageable. As it should be.

So thanks for that fix:

Acked-and-tested-by: Borislav Petkov 

I'll pick it up for SLE12 once it sees a bit more upstream time.

[PATCH] ARM64: Remove duplicated Kconfig entry for "kernel/power/Kconfig"

[Hanjun Guo]

There is a duplicated Kconfig entry for "kernel/power/Kconfig"
in menu "Power management options" and "CPU Power Management",
remove the one from menu "CPU Power Management" suggested by
Viresh.

Signed-off-by: Hanjun Guo 
---
 arch/arm64/Kconfig |2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e6e4d37..e759af5 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -323,8 +323,6 @@ menu "CPU Power Management"
 
 source "drivers/cpuidle/Kconfig"
 
-source "kernel/power/Kconfig"
-
 source "drivers/cpufreq/Kconfig"
 
 endmenu
-- 
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] regulator: core: Get and put regulator of_node

[Mark Brown]

On Thu, Apr 03, 2014 at 11:58:04AM +0100, Charles Keepax wrote:
> On Wed, Apr 02, 2014 at 05:53:54PM +0100, Mark Brown wrote:

> > To make this correct we need to at least ensure that the node passed
> > into the regulator API is valid and referenced at that time so there
> > should only be an issue for the core if the reference is dropped after
> > that.  In the above case the device model is holding a reference since
> > this is the of_node for the device itself so taking the reference won't
> > hurt but is redundant.  In cases where we have more than one regulator
> > and are using of_regulator_match() then things are more tricky.
> > Something needs to drop the references it returns (which isn't happening
> > at all at the minute).

> From what I can see of_regulator_match isn't taking any
> references at the minute? for_each_child_of_node will get a
> reference but it will also put that when we process the next
> child. We copy the pointer to the child into match->of_node
> but don't manually increment the reference at all. So
> of_regulator_match has no effect on the reference count of the
> of_node.

Right, so that needs fixing - like I say if there's no reference being
taken we already have a problem and taking another reference later on
isn't going to fix it.

> >  Doing it while doing the match and register
> > seems simple and neat from an error handling point of view so having the
> > core take an additional reference during the registration would join up
> > with that.

> The main issue I have is that devm_regualtor_register is a bit
> awkward. With regulator_register you will always be calling
> regulator_unregister so you can put the of_node there but with
> devm there isn't really a good place to put the of_node.

That's why I suggested it might be OK to take a reference in the core -
this would allow the device probe to safely drop its reference before it
returns.

> Would perhaps a sensible thing here be to add an of_node_get to
> of_regulator_match, since we seem to be expecting that to
> increase the ref count. And then just add an of_node_put to
> regulator_unregister. And for anything directly using
> regulator_register/devm_regulator_register they should add a
> manual of_node_get?

That seems very ugly.


signature.asc
Description: Digital signature

Q: setting the process name for ps

[Ulrich Windl]

Hi!

Currently one has to fiddle with argv[] in-place when trying to change the 
process name "cmd") in Linux. However if you want to change the thread name 
("comm"), there is a syscall (prctl(PR_SET_NAME, ...)) for it.

For comparison, in HP-UX there is also a syscall to change the process name for 
ps:
---
#include

union pstun psu;

psu.pst_command = "foobar";
pstat(PSTAT_SETCMD, psu, strlen("foobar") - 1, 0, 0);
---

To be fair, HP-XU also has syscalls to get processes, threads and arguments:
pstat_getlwp()
pstat_getproc()
pstat_getcommandline()

As Linux is different, I wonder whether there are any plans to provide a 
syscall to change the process name.

For those who aren't afraid of ugly code, here's a quick-and-dirty example how 
to change the process name in Linux (apologies, you guys know, but those who 
Google may not:
---
#include
#include
#include
#include
#include

static  int delay(void)
{
struct timespec ts;

ts.tv_sec = 10;
ts.tv_nsec = 0;
return nanosleep(, NULL);
}

int main(int argc, char *argv[])
{
int l = strlen(argv[0]);

if ( argc > 1 )
l += 1 + strlen(argv[1]);
if (l  < 20 ) {
printf("provide a long argument\n");
return 1;
}
printf("look: unchanged\n"); delay();
sprintf(argv[0], "proc %d", getpid());
printf("look: process title\n"); delay();
return 0;
}
---

As I'm not subscribed to LKML, please keep me CC'd on you replies!

Thanks & regards,
Ulrich Windl


--
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/2] devicetree: Add devicetree bindings documentation for Cadence SPI

[Harini Katakam]

Add spi-cadence bindings documentation.

Signed-off-by: Harini Katakam 
---

v2 changes:
- Separate patch for bindings.
- Add xilinx compatible string; Make compatible string first in the node.
- Use property name num-cs. Make this property optional.

---
 .../devicetree/bindings/spi/spi-cadence.txt|   27 
 1 file changed, 27 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/spi/spi-cadence.txt

diff --git a/Documentation/devicetree/bindings/spi/spi-cadence.txt 
b/Documentation/devicetree/bindings/spi/spi-cadence.txt
new file mode 100644
index 000..ccb7599
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-cadence.txt
@@ -0,0 +1,27 @@
+Cadence SPI controller Device Tree Bindings
+---
+
+Required properties:
+- compatible   : Should be "cdns,spi-r1p6" or "xlnx,zynq-spi-r1p6".
+- reg  : Physical base address and size of SPI registers map.
+- interrupts   : Property with a value describing the interrupt
+ number.
+- interrupt-parent : Must be core interrupt controller
+- clock-names  : List of input clock names - "ref_clk", "pclk"
+ (See clock bindings for details).
+- clocks   : Clock phandles (see clock bindings for details).
+
+Optional properties:
+- num-cs   : Number of chip selects used.
+
+Example:
+
+   spi@e0007000 {
+   compatible = "xlnx,zynq-spi-r1p6";
+   clock-names = "ref_clk", "pclk";
+   clocks = < 26>, < 35>;
+   interrupt-parent = <>;
+   interrupts = <0 49 4>;
+   num-cs = /bits/ 16 <4>;
+   reg = <0xe0007000 0x1000>;
+   } ;
-- 
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 1/2] SPI: Add driver for Cadence SPI controller

[Harini Katakam]

Add driver for Cadence SPI controller. This is used in Xilinx Zynq.

Signed-off-by: Harini Katakam 
---

v2 changes:
- Use xilinx compatible string too.
- Changes read register and write register functions to static inline.
- Removed unecessary dev_info and dev_dbg prints.
- Return IRQ_HANDLED only when interrupt is handled.
- Use a default num-cs value.
- Do init_hardware before requesting irq.
- Remove unecessary master_put()
- Set master->max_speed_hz
- Check for busy in cdns_setup().
  Retained this function with this check as opposed to removing.
  The reason for this is clock configuration needs to be done for
  the first time before enable is done in prepare_hardware;
  prepare_hardware however, doesn't receive spi_device structure.
- Implememnt transfer_one instead of transfer_one_message.
  Remove wait_for_completion as this is done by core.
- Implement set_cs.
- Clock enable/disable in prepare/unprepare respectively.
- In suspend, remove reset of hardware; simply call unprepare_hardware.
- In suspend/resume call master_suspend/resume respectively.
- Check for irq<=0 in probe.
- Remove MODULE_ALIAS.

---
 drivers/spi/Kconfig   |7 +
 drivers/spi/Makefile  |1 +
 drivers/spi/spi-cadence.c |  677 +
 3 files changed, 685 insertions(+)
 create mode 100644 drivers/spi/spi-cadence.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 581ee2a..aeae44a 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -148,6 +148,13 @@ config SPI_BUTTERFLY
  inexpensive battery powered microcontroller evaluation board.
  This same cable can be used to flash new firmware.
 
+config SPI_CADENCE
+   tristate "Cadence SPI controller"
+   depends on SPI_MASTER
+   help
+ This selects the Cadence SPI controller master driver
+ used by Xilinx Zynq.
+
 config SPI_CLPS711X
tristate "CLPS711X host SPI controller"
depends on ARCH_CLPS711X
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 95af48d..1be2ed7 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_SPI_BFIN_V3)   += spi-bfin-v3.o
 obj-$(CONFIG_SPI_BFIN_SPORT)   += spi-bfin-sport.o
 obj-$(CONFIG_SPI_BITBANG)  += spi-bitbang.o
 obj-$(CONFIG_SPI_BUTTERFLY)+= spi-butterfly.o
+obj-$(CONFIG_SPI_CADENCE)  += spi-cadence.o
 obj-$(CONFIG_SPI_CLPS711X) += spi-clps711x.o
 obj-$(CONFIG_SPI_COLDFIRE_QSPI)+= spi-coldfire-qspi.o
 obj-$(CONFIG_SPI_DAVINCI)  += spi-davinci.o
diff --git a/drivers/spi/spi-cadence.c b/drivers/spi/spi-cadence.c
new file mode 100644
index 000..071642d
--- /dev/null
+++ b/drivers/spi/spi-cadence.c
@@ -0,0 +1,677 @@
+/*
+ * Cadence SPI controller driver (master mode only)
+ *
+ * Copyright (C) 2008 - 2014 Xilinx, Inc.
+ *
+ * based on Blackfin On-Chip SPI Driver (spi_bfin5xx.c)
+ *
+ * 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; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Name of this driver */
+#define CDNS_SPI_NAME  "cdns-spi"
+
+/* Register offset definitions */
+#define CDNS_SPI_CR_OFFSET 0x00 /* Configuration  Register, RW */
+#define CDNS_SPI_ISR_OFFSET0x04 /* Interrupt Status Register, RO */
+#define CDNS_SPI_IER_OFFSET0x08 /* Interrupt Enable Register, WO */
+#define CDNS_SPI_IDR_OFFSET0x0c /* Interrupt Disable Register, WO */
+#define CDNS_SPI_IMR_OFFSET0x10 /* Interrupt Enabled Mask Register, RO */
+#define CDNS_SPI_ER_OFFSET 0x14 /* Enable/Disable Register, RW */
+#define CDNS_SPI_DR_OFFSET 0x18 /* Delay Register, RW */
+#define CDNS_SPI_TXD_OFFSET0x1C /* Data Transmit Register, WO */
+#define CDNS_SPI_RXD_OFFSET0x20 /* Data Receive Register, RO */
+#define CDNS_SPI_SICR_OFFSET   0x24 /* Slave Idle Count Register, RW */
+#define CDNS_SPI_THLD_OFFSET   0x28 /* Transmit FIFO Watermark Register,RW */
+
+/*
+ * SPI Configuration Register bit Masks
+ *
+ * This register contains various control bits that affect the operation
+ * of the SPI controller
+ */
+#define CDNS_SPI_CR_MANSTRT_MASK   0x0001 /* Manual TX Start */
+#define CDNS_SPI_CR_CPHA_MASK  0x0004 /* Clock Phase Control */
+#define CDNS_SPI_CR_CPOL_MASK  0x0002 /* Clock Polarity Control */
+#define CDNS_SPI_CR_SSCTRL_MASK0x3C00 /* Slave Select Mask 
*/
+#define CDNS_SPI_CR_BAUD_DIV_MASK  0x0038 /* Baud Rate Divisor Mask */
+#define CDNS_SPI_CR_MSTREN_MASK0x0001 /* Master Enable 
Mask */
+#define CDNS_SPI_CR_MANSTRTEN_MASK 0x8000 /* Manual TX Enable Mask */
+#define CDNS_SPI_CR_SSFORCE_MASK   

Re: How to pass I2C platform_data under ACPI

[mika.westerb...@linux.intel.com]

On Thu, Apr 03, 2014 at 08:10:40AM +, Pallala, Ramakrishna wrote:
> Hi All,
> 
> I am trying to enable a i2c client driver under ACPI. The device is being 
> enumerated behind adapter device and I am getting IRQ resource as well.
> 
> The problem I have now is, how do I pass the platform data to driver?
> 
> struct i2c_board_info {
> chartype[I2C_NAME_SIZE];
> unsigned short  flags;
> unsigned short  addr;
> void*platform_data; ===> how can I initialize 
> this filed.
> struct dev_archdata *archdata;
> struct device_node *of_node;
> struct acpi_dev_node acpi_node;
> int irq;
> };
>  
> In non ACPI environment I used to initialize the platform_data under
> board or platforms files. Under ACPI how do I do that?

If you can't extract that information from ACPI namespace, then one option
is to pass platform data along with the device ACPI ID:

static const struct acpi_device_id my_acpi_match[] = {
{ "MYID0001", (kernel_ulong_t)_platform_data }
...
{ },
};

static struct i2c_driver i2c_hid_driver = {
.driver = {
...
.acpi_match_table = ACPI_PTR(my_acpi_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/

Re: [RFC PATCH] cmdline: Hide "debug" from /proc/cmdline

[Borislav Petkov]

On Thu, Apr 03, 2014 at 11:34:15AM +0100, Måns Rullgård wrote:
> Once is an accident.  Twice is incompetence.  Three times is malice.

Yeah, maybe it is time Linus started his own init daemon project, like
that other thing, git, he did start a while ago. We can put it in
tools/. I'm sure it can get off the ground pretty quickly, judging by
other projects kernel people have jumped on in the past.

:-) :-)

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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] arm64: Fix duplicated Kconfig entries again

[Hanjun Guo]

On 2014-4-3 17:38, Viresh Kumar wrote:
> On 3 April 2014 14:57, Hanjun Guo  wrote:
>> Great, thanks Viresh to let me know this.
>> Actually I also sent a patch named "arm64: Fix duplicated Kconfig entries
>> again" about one week ago :)
>>
>> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg612363.html
>>
>> And I think there is still a problem after commit 62d1a3ba - multi-entries
>> for source "kernel/power/Kconfig", so how about the following fix?
> 
> I didn't notice that :)
> 
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index e6e4d37..6085dca 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -317,14 +317,8 @@ config ARCH_SUSPEND_POSSIBLE
>>  config ARM64_CPU_SUSPEND
>> def_bool PM_SLEEP
>>
>> -endmenu
>> -
>> -menu "CPU Power Management"
>> -
>>  source "drivers/cpuidle/Kconfig"
>>
>> -source "kernel/power/Kconfig"
>> -
>>  source "drivers/cpufreq/Kconfig"
>>
>>  endmenu
>>
>> If it makes sense, I will send out a patch for it.
> 
> We actually need to menu options here,
> menu "Power management options"
> menu "CPU Power Management"
> 
> And so probably you just need to do this:
>> -source "kernel/power/Kconfig"
>> -
> 
> from CPU Power Management options..

Ok, will send out a patch later.

Thanks
Hanjun

--
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] regulator: core: Get and put regulator of_node

[Charles Keepax]

On Wed, Apr 02, 2014 at 05:53:54PM +0100, Mark Brown wrote:
> To make this correct we need to at least ensure that the node passed
> into the regulator API is valid and referenced at that time so there
> should only be an issue for the core if the reference is dropped after
> that.  In the above case the device model is holding a reference since
> this is the of_node for the device itself so taking the reference won't
> hurt but is redundant.  In cases where we have more than one regulator
> and are using of_regulator_match() then things are more tricky.
> Something needs to drop the references it returns (which isn't happening
> at all at the minute).

>From what I can see of_regulator_match isn't taking any
references at the minute? for_each_child_of_node will get a
reference but it will also put that when we process the next
child. We copy the pointer to the child into match->of_node
but don't manually increment the reference at all. So
of_regulator_match has no effect on the reference count of the
of_node.

>  Doing it while doing the match and register
> seems simple and neat from an error handling point of view so having the
> core take an additional reference during the registration would join up
> with that.

The main issue I have is that devm_regualtor_register is a bit
awkward. With regulator_register you will always be calling
regulator_unregister so you can put the of_node there but with
devm there isn't really a good place to put the of_node.

Would perhaps a sensible thing here be to add an of_node_get to
of_regulator_match, since we seem to be expecting that to
increase the ref count. And then just add an of_node_put to
regulator_unregister. And for anything directly using
regulator_register/devm_regulator_register they should add a
manual of_node_get?

Thanks,
Charles
--
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] mfd: twl6040: Optional clk32k clock handling

[Peter Ujfalusi]

In certain boards the source for the clk32k clock can be gated. In these
boards the clk32k clock can be provided to the driver and it is going to be
enabled/disabled when it is needed.
If the clk32k clock is not provided the driver will assume that it is always
running.

Signed-off-by: Peter Ujfalusi 
---
 Documentation/devicetree/bindings/mfd/twl6040.txt |  2 ++
 drivers/mfd/twl6040.c | 10 ++
 include/linux/mfd/twl6040.h   |  2 ++
 3 files changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/twl6040.txt 
b/Documentation/devicetree/bindings/mfd/twl6040.txt
index 0f5dd709d752..a41157b5d930 100644
--- a/Documentation/devicetree/bindings/mfd/twl6040.txt
+++ b/Documentation/devicetree/bindings/mfd/twl6040.txt
@@ -19,6 +19,8 @@ Required properties:
 
 Optional properties, nodes:
 - enable-active-high: To power on the twl6040 during boot.
+- clocks: phandle to the clk32k clock provider
+- clock-names: Must be "clk32k"
 
 Vibra functionality
 Required properties:
diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c
index 2e6504a8e1e3..12b314ea48dc 100644
--- a/drivers/mfd/twl6040.c
+++ b/drivers/mfd/twl6040.c
@@ -291,6 +291,8 @@ int twl6040_power(struct twl6040 *twl6040, int on)
if (twl6040->power_count++)
goto out;
 
+   clk_prepare_enable(twl6040->clk32k);
+
/* Allow writes to the chip */
regcache_cache_only(twl6040->regmap, false);
 
@@ -346,6 +348,8 @@ int twl6040_power(struct twl6040 *twl6040, int on)
 
twl6040->sysclk = 0;
twl6040->mclk = 0;
+
+   clk_disable_unprepare(twl6040->clk32k);
}
 
 out:
@@ -644,6 +648,12 @@ static int twl6040_probe(struct i2c_client *client,
 
i2c_set_clientdata(client, twl6040);
 
+   twl6040->clk32k = devm_clk_get(>dev, "clk32k");
+   if (IS_ERR(twl6040->clk32k)) {
+   dev_info(>dev, "clk32k is not handled\n");
+   twl6040->clk32k = NULL;
+   }
+
twl6040->supplies[0].supply = "vio";
twl6040->supplies[1].supply = "v2v1";
ret = devm_regulator_bulk_get(>dev, TWL6040_NUM_SUPPLIES,
diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h
index a69d16b30c18..8f9fc3d26e6d 100644
--- a/include/linux/mfd/twl6040.h
+++ b/include/linux/mfd/twl6040.h
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define TWL6040_REG_ASICID 0x01
 #define TWL6040_REG_ASICREV0x02
@@ -223,6 +224,7 @@ struct twl6040 {
struct regmap *regmap;
struct regmap_irq_chip_data *irq_data;
struct regulator_bulk_data supplies[2]; /* supplies for vio, v2v1 */
+   struct clk *clk32k;
struct mutex mutex;
struct mutex irq_mutex;
struct mfd_cell cells[TWL6040_CELLS];
-- 
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] mfd: twl6040: Optional clk32k clock handling

[Peter Ujfalusi]

In certain boards the source for the clk32k clock can be gated. In these
boards the clk32k clock can be provided to the driver and it is going to be
enabled/disabled when it is needed.
If the clk32k clock is not provided the driver will assume that it is always
running.

Signed-off-by: Peter Ujfalusi 
---
 Documentation/devicetree/bindings/mfd/twl6040.txt |  2 ++
 drivers/mfd/twl6040.c | 10 ++
 include/linux/mfd/twl6040.h   |  2 ++
 3 files changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/twl6040.txt 
b/Documentation/devicetree/bindings/mfd/twl6040.txt
index 0f5dd709d752..a41157b5d930 100644
--- a/Documentation/devicetree/bindings/mfd/twl6040.txt
+++ b/Documentation/devicetree/bindings/mfd/twl6040.txt
@@ -19,6 +19,8 @@ Required properties:
 
 Optional properties, nodes:
 - enable-active-high: To power on the twl6040 during boot.
+- clocks: phandle to the clk32k clock provider
+- clock-names: Must be "clk32k"
 
 Vibra functionality
 Required properties:
diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c
index 2e6504a8e1e3..12b314ea48dc 100644
--- a/drivers/mfd/twl6040.c
+++ b/drivers/mfd/twl6040.c
@@ -291,6 +291,8 @@ int twl6040_power(struct twl6040 *twl6040, int on)
if (twl6040->power_count++)
goto out;
 
+   clk_prepare_enable(twl6040->clk32k);
+
/* Allow writes to the chip */
regcache_cache_only(twl6040->regmap, false);
 
@@ -346,6 +348,8 @@ int twl6040_power(struct twl6040 *twl6040, int on)
 
twl6040->sysclk = 0;
twl6040->mclk = 0;
+
+   clk_disable_unprepare(twl6040->clk32k);
}
 
 out:
@@ -644,6 +648,12 @@ static int twl6040_probe(struct i2c_client *client,
 
i2c_set_clientdata(client, twl6040);
 
+   twl6040->clk32k = devm_clk_get(>dev, "clk32k");
+   if (IS_ERR(twl6040->clk32k)) {
+   dev_info(>dev, "clk32k is not handled\n");
+   twl6040->clk32k = NULL;
+   }
+
twl6040->supplies[0].supply = "vio";
twl6040->supplies[1].supply = "v2v1";
ret = devm_regulator_bulk_get(>dev, TWL6040_NUM_SUPPLIES,
diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h
index a69d16b30c18..8f9fc3d26e6d 100644
--- a/include/linux/mfd/twl6040.h
+++ b/include/linux/mfd/twl6040.h
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define TWL6040_REG_ASICID 0x01
 #define TWL6040_REG_ASICREV0x02
@@ -223,6 +224,7 @@ struct twl6040 {
struct regmap *regmap;
struct regmap_irq_chip_data *irq_data;
struct regulator_bulk_data supplies[2]; /* supplies for vio, v2v1 */
+   struct clk *clk32k;
struct mutex mutex;
struct mutex irq_mutex;
struct mfd_cell cells[TWL6040_CELLS];
-- 
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] clk: Add driver for Palmas clk32kg and clk32kgaudio clocks

[Peter Ujfalusi]

Palmas class of devices have either twl 32K clock outputs:
CLK32K_KG and CLK32K_KGAUDIO
or only one:
CLK32K_KG (TPS659039 for example)

Use separate compatible flags for the two 32K clock.
A system which needs or have only one of the 32k clock from
Palmas will need to add node(s) for each clock as separate section
in the dts file.
The two compatible property is:
"ti,palmas-clk32kg" for clk32kg clock
"ti,palmas-clk32kgaudio" for clk32kgaudio clock

Apart from the register control of the clocks - which is done via
the clock API there is a posibility to enable the external sleep
control.

See the documentation for more details.

Signed-off-by: Peter Ujfalusi 
---
Hi,

Part of the driver is based on the v4 of palmas clock driver from
Laxman Dewangan, which can be found here:
https://lkml.org/lkml/2013/10/9/146

Since no updates followed after the comments and patches I have squashed my
updates to rewrite the original driver to be able to support more devices from
the Palmas family.

Regards,
Peter

 .../devicetree/bindings/clock/clk-palmas.txt   |  35 +++
 drivers/clk/Kconfig|   7 +
 drivers/clk/Makefile   |   1 +
 drivers/clk/clk-palmas.c   | 307 +
 include/dt-bindings/mfd/palmas.h   |  18 ++
 5 files changed, 368 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/clk-palmas.txt
 create mode 100644 drivers/clk/clk-palmas.c
 create mode 100644 include/dt-bindings/mfd/palmas.h

diff --git a/Documentation/devicetree/bindings/clock/clk-palmas.txt 
b/Documentation/devicetree/bindings/clock/clk-palmas.txt
new file mode 100644
index ..4208886d834a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/clk-palmas.txt
@@ -0,0 +1,35 @@
+* Palmas 32KHz clocks *
+
+Palmas device has two clock output pins for 32KHz, KG and KG_AUDIO.
+
+This binding uses the common clock binding ./clock-bindings.txt.
+
+Required properties:
+- compatible : "ti,palmas-clk32kg" for clk32kg clock
+   "ti,palmas-clk32kgaudio" for clk32kgaudio clock
+- #clock-cells : shall be set to 0.
+
+Optional property:
+- ti,external-sleep-control: The external enable input pins controlled the
+   enable/disable of clocks.  The external enable input pins ENABLE1,
+   ENABLE2 and NSLEEP. The valid values for the external pins are:
+   PALMAS_EXT_CONTROL_PIN_ENABLE1 for ENABLE1 pin
+   PALMAS_EXT_CONTROL_PIN_ENABLE2 for ENABLE2 pin
+   PALMAS_EXT_CONTROL_PIN_NSLEEP for NSLEEP pin
+   Option 0 or missing this property means the clock is enabled/disabled
+   via register access and these pins do not have any control.
+   The macros of external control pins for DTS is defined at
+   dt-bindings/mfd/palmas.h
+
+Example:
+   #include 
+   ...
+   palmas: tps65913@58 {
+   ...
+   clk32kg: palmas_clk32k@0 {
+   compatible = "ti,palmas-clk32kg";
+   #clock-cells = <0>;
+   ti,external-sleep-control = 
;
+   };
+   ...
+   };
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 6f56d3a4f010..a070b77a1e17 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -109,6 +109,13 @@ config COMMON_CLK_KEYSTONE
   Supports clock drivers for Keystone based SOCs. These SOCs have local
  a power sleep control module that gate the clock to the IPs and PLLs.
 
+config COMMON_CLK_PALMAS
+   tristate "Clock driver for TI Palmas devices"
+   depends on MFD_PALMAS
+   ---help---
+ This driver supports TI Palmas devices 32KHz output KG and KG_AUDIO
+ using common clock framework.
+
 source "drivers/clk/qcom/Kconfig"
 
 endmenu
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 5f8a28735c96..d67214debc12 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_COMMON_CLK_MAX77686) += clk-max77686.o
 obj-$(CONFIG_ARCH_MOXART)  += clk-moxart.o
 obj-$(CONFIG_ARCH_NOMADIK) += clk-nomadik.o
 obj-$(CONFIG_ARCH_NSPIRE)  += clk-nspire.o
+obj-$(CONFIG_COMMON_CLK_PALMAS)+= clk-palmas.o
 obj-$(CONFIG_CLK_PPC_CORENET)  += clk-ppc-corenet.o
 obj-$(CONFIG_COMMON_CLK_S2MPS11)   += clk-s2mps11.o
 obj-$(CONFIG_COMMON_CLK_SI5351)+= clk-si5351.o
diff --git a/drivers/clk/clk-palmas.c b/drivers/clk/clk-palmas.c
new file mode 100644
index ..e2b7d3cade26
--- /dev/null
+++ b/drivers/clk/clk-palmas.c
@@ -0,0 +1,307 @@
+/*
+ * Clock driver for Palmas device.
+ *
+ * Copyright (c) 2013, NVIDIA Corporation.
+ * Copyright (c) 2013-2014 Texas Instruments, Inc.
+ *
+ * Author: Laxman Dewangan 
+ * Peter Ujfalusi 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as

linux-next: no tree tomorrow

[Stephen Rothwell]

Hi all,

Sorry, but there will be no linux-next release tomorrow.  Normal service
will resume on Monday.

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


pgpf_3sThB9yC.pgp
Description: PGP signature

Re: [RFC 1/4] sched: extend the usage of cpu_power_orig

[Preeti U Murthy]

On 04/01/2014 04:50 PM, Vincent Guittot wrote:
> On 1 April 2014 12:39, Preeti U Murthy  wrote:
>> Hi Vincent,
>>
>> On 03/28/2014 06:52 PM, Vincent Guittot wrote:
>>> cpu_power_orig is only changed for SMT system in order to reflect the lower
>>> capacity of CPUs. Heterogenous system also have to reflect an original
>>> capacity that is different from the default value.
>>
>> There is no parameter 'cpu_power_orig' till your fourth patch right?
>> Why is this term being used in this patch?
> 
> It looks like that i have mixed power_orig and cpu_power_orig in my
> commit messages
> 
>>
>> Besides, both parameters power and power_orig are changed for SMT
>> systems to reflect the lower capacity of the CPUs.Why is there a mention
>> of only power_orig?
> 
> Only SMT system is able to change power_orig from default value
> whereas all systems can already change power field with
> arch_scale_freq_power function. The goal of this patch is to change

I am unable to understand this. arch_scale_freq_power() is not doing the
same job as arch_scale_smt_power() right? While the former allows the
arch to set a power value per cpu different from the default value, the
latter allows arch to adjust the power for hyper threads.

For example in big.LITTLE, the big cores would be required to have a
higher cpu power than what is currently being used as default. This is
done by arch_scale_freq_power(). Whereas for an SMT system, the power of
a core could perhaps be the same as default value, but needs to be
divided among the hyper threads. This is done by arch_scale_smt_power().
They have different purposes right?

So I do not understand why you mention "all systems can already change
power field with arch_scale_freq_power()."

Actually I was assuming this patch would introduce
arch_scale_smt_power() and arch_scale_freq_power(), two functions that
would *enable all archs and not just ARCH_POWER* as is found today, to
adjust their smt power and non-smt power respectively.

For the same reasons, I am also unclear as to why power_orig is not
initialized *after* default/arch_scale_freq_power(). For big cores for
instance you would want the power_orig to be set not to a default value
but to what the arch says as the frequency of a core scaled over the
default value.

> the function name that is used to set power_orig value to a more
> generic one and to extend the possibility of setting power_orig for
> any kind of system. The behavior of the power field is not changed
> with this patchset.
> 
>>
>> IMO, the subject of the patch is not clearly reflecting the main
>> intention of the patch. There is nothing done to change the way
>> cpu_power is used; rather you are changing the way the cpu_power is
>> being set to be flexible, thus allowing for the right power value to be
>> set on heterogeneous systems.
>>
>> 'Allow archs to set the cpu_power instead of falling to default value'
>> or something similar would be more appropriate. What do you think?
> 
> I can change with : "Allow all archs to set the power_orig"

Ok, but for the reasons mentioned above I was thinking the power_orig
should be avoided since archs should be able to scale both power and
power_orig per thread and not just ARCH_POWER.

Regards
Preeti U Murthy


> 
> Thanks
> 
>>
>> Regards
>> Preeti U Murthy

--
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] cmdline: Hide "debug" from /proc/cmdline

[Joerg Roedel]

On Wed, Apr 02, 2014 at 06:47:57PM -0700, Linus Torvalds wrote:
> Whether it actually fixes the problem that Borislav had is
> questionable, of course. For all I know, systemd debug mode generates
> so much data in *other* ways and then causes feedback loops with the
> kernel debugging that this patch is totally immaterial, and dmesg was
> never the main issue. But unlike the "hide 'debug' from
> /proc/cmdline", I think this patch at least _conceptually_ makes a lot
> of sense, even if systemd gets fixed, so ...

How about just ignoring writes to /dev/kmsg altogether by default
(unless explicitly enabled in Kconfig or on the kernel cmdline)? Maybe I
am missing something but what are the legitimate use-cases for generally
allowing user-space to write into the kernel-log?


Joerg


--
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] cmdline: Hide "debug" from /proc/cmdline

[Måns Rullgård]

Linus Torvalds  writes:

> On Wed, Apr 2, 2014 at 4:47 PM, Jiri Kosina  wrote:
>>
>> Which doesn't really protect you from tasks that do open()/write()/close()
>> cycle for /dev/kmsg write every 2ms though.
>
> I don't think we should try to protect against wilful bad behavior
> unless that is shown to be necessary. Yeah, if it turns out that
> systemd really does that just to mess with us, we'd need to extend it,
> but in the absence of proof to the contrary, maybe this simple
> attached patch works?

Once is an accident.  Twice is incompetence.  Three times is malice.

-- 
Måns Rullgård
m...@mansr.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 00/22] atmel_mxt_ts patches, already signed-off

[Nick Dyer]

Hi Dmitry-

Nick Dyer  wrote:
> Here is a set of patches for atmel_mxt_ts that you've already
> signed-off. I've rebased them against the most recent mainline and made
> some very minor changes such as INIT_COMPLETION->reinit_completion.

It would be useful to have some feedback about this patchset if you have time.

Nick
--
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.14-7247-gcd6362b drivers/staging/lustre/lustre/libcfs/workitem.c Fix sparse warning.

[Dan Carpenter]

On Thu, Apr 03, 2014 at 08:43:28PM +1100, Mike Sampson wrote:
> Signed-off-by: Mike Sampson 
> 
> This fixes a sparse warning:
> warning: symbol 'cfs_wi_data' was not declared. Should it be static?
> 

Patch is ok.  Signed off should go at the end instead of at the start of
the commit message.  The subject should be:

[PATCH] Staging: lustre: mark a variable static in workitem.c

Espcially notice how I removed the "v3.14-7247-gcd6362b" and chose a
better prefix.  Btw, for these kinds of changes, then you should be
working against -next.

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/

500,000,00 Eur

[Western Union]

Confirm your 500,000,00 Euros. Contact payment/claims officer:   
onu_clai...@qq.com

-- 
Esta mensagem foi verificada pelo sistema de antivirus e
 acredita-se estar livre de perigo.

--
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: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

[Willy Tarreau]

On Thu, Apr 03, 2014 at 06:15:25PM +0800, zhuyj wrote:
> Hi, Willy
> 
> I made a new patch. In long commit message, I inserted the equivalent 
> mainline commit
> about this feature. Maybe it is better. Now this patch is in the 
> attachment. Please check
> and merge it into kernel 2.6.32.62.

Sure, it's much better this way.

Thanks!
Willy

--
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: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

[zhuyj]

On 04/03/2014 06:01 PM, Willy Tarreau wrote:

Hi Zhu,

On Thu, Apr 03, 2014 at 05:57:53PM +0800, zhuyj wrote:

I reference the following 2 mainline commits. These 2 commits are based
on the current kernel 3.x and ethtool.
If we only backport these 2 commits on kernel 2.6.x, this problem will
not be fixed yet.

OK fine, I just wanted that we keep the reference of these equivalent
patches in the commit message so that if later a newer patch changes
anything they did, at least we have some indications that the commit
might also have to be revisited.

I'll merge your patch and put these references there.

Thanks,
Willy

OK. Thanks a lot.

Zhu Yanjun

.



--
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: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

[zhuyj]

On 04/03/2014 05:27 PM, Willy Tarreau wrote:

Hi Zhu,

On Thu, Apr 03, 2014 at 05:11:48PM +0800, zhuyj wrote:

Hi, Claudiu

Please help to review this patch. This patch is for kernel 2.6.x. Thanks
a lot.

Hi, Willy

Please help to merge this patch to longterm: 2.6.32.61 since this
problem also occurs on this kernel. Thanks a lot.

Could you please send the reference to the equivalent mainline commit (the one
which disables the tx vlan feature I'm assuming) ? I'll happily queue it for
2.6.32.62.

Thanks,
Willy



Hi, Willy

I made a new patch. In long commit message, I inserted the equivalent 
mainline commit
about this feature. Maybe it is better. Now this patch is in the 
attachment. Please check

and merge it into kernel 2.6.32.62.

Thanks a lot.
Zhu Yanjun

>From 3b74ad6134f8eccce9ee391fb02ff15863630c1b Mon Sep 17 00:00:00 2001
From: Zhu Yanjun 
Date: Thu, 3 Apr 2014 16:41:13 +0800
Subject: [PATCH 1/1] gianfar: disable TX vlan based on kernel 2.6.x

2.6.x kernels require a similar logic change as commit e1653c3e
[gianfar: do vlan cleanup] and commit 51b8cbfc
[gianfar: fix bug caused by e1653c3e] introduces for newer kernels.

Since there is something wrong with tx vlan of gianfar nic driver,
in kernel(3.1+), tx vlan is disabled. But in kernel 2.6.x, tx vlan
is still enabled. Thus,gianfar nic driver can not support vlan
packets and non-vlan packets at the same time.

Signed-off-by: Zhu Yanjun 
---
 drivers/net/gianfar.c |8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 934a28f..8aa2cf6 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -365,7 +365,7 @@ static int gfar_probe(struct of_device *ofdev,
 	priv->vlgrp = NULL;
 
 	if (priv->device_flags & FSL_GIANFAR_DEV_HAS_VLAN)
-		dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
+		dev->features |= NETIF_F_HW_VLAN_RX;
 
 	if (priv->device_flags & FSL_GIANFAR_DEV_HAS_EXTENDED_HASH) {
 		priv->extended_hash = 1;
@@ -1451,12 +1451,6 @@ static void gfar_vlan_rx_register(struct net_device *dev,
 	priv->vlgrp = grp;
 
 	if (grp) {
-		/* Enable VLAN tag insertion */
-		tempval = gfar_read(>regs->tctrl);
-		tempval |= TCTRL_VLINS;
-
-		gfar_write(>regs->tctrl, tempval);
-
 		/* Enable VLAN tag extraction */
 		tempval = gfar_read(>regs->rctrl);
 		tempval |= (RCTRL_VLEX | RCTRL_PRSDEP_INIT);
-- 
1.7.9.5

Re: [PATCH v2] f2fs: introduce f2fs_issue_flush to avoid redundant flush issue

[Jaegeuk Kim]

change log from v1:
 o do not create a flush thread, if the option is not set

>From deb512157c4bcae079197eb55590e3e764cedc7f Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim 
Date: Wed, 2 Apr 2014 15:34:36 +0900
Subject: [PATCH] f2fs: introduce f2fs_issue_flush to avoid redundant
flush
 issue
Cc: linux-fsde...@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-f2fs-de...@lists.sourceforge.net

Some storage devices show relatively high latencies to complete
cache_flush
commands, even though their normal IO speed is prettry much high. In
such
the case, it needs to merge cache_flush commands as much as possible to
avoid
issuing them redundantly.
So, this patch introduces a mount option, "-o flush_merge", to mitigate
such
the overhead.

If this option is enabled by user, F2FS merges the cache_flush commands
and then
issues just one cache_flush on behalf of them. Once the single command
is
finished, F2FS sends a completion signal to all the pending threads.

Note that, this option can be used under a workload consisting of very
intensive
concurrent fsync calls, while the storage handles cache_flush commands
slowly.

Signed-off-by: Jaegeuk Kim 
---
 Documentation/filesystems/f2fs.txt |  4 ++
 fs/f2fs/f2fs.h | 16 +++
 fs/f2fs/file.c |  2 +-
 fs/f2fs/segment.c  | 89
++
 fs/f2fs/super.c|  7 +++
 5 files changed, 117 insertions(+), 1 deletion(-)

diff --git a/Documentation/filesystems/f2fs.txt
b/Documentation/filesystems/f2fs.txt
index 2f6d021..25311e11 100644
--- a/Documentation/filesystems/f2fs.txt
+++ b/Documentation/filesystems/f2fs.txt
@@ -122,6 +122,10 @@ disable_ext_identify   Disable the extension list
configured by mkfs, so f2fs
 inline_xattr   Enable the inline xattrs feature.
 inline_dataEnable the inline data feature: New created
small(<~3.4k)
files can be written into inode block.
+flush_merge   Merge concurrent cache_flush commands as much as
possible
+   to eliminate redundant command issues. If the
underlying
+  device handles the cache_flush command relatively slowly,
+  recommend to enable this option.
 


 DEBUGFS ENTRIES
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 1e3d869..2ecac83 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -40,6 +40,7 @@
 #define F2FS_MOUNT_DISABLE_EXT_IDENTIFY0x0040
 #define F2FS_MOUNT_INLINE_XATTR0x0080
 #define F2FS_MOUNT_INLINE_DATA 0x0100
+#define F2FS_MOUNT_FLUSH_MERGE 0x0200
 
 #define clear_opt(sbi, option) (sbi->mount_opt.opt &=
~F2FS_MOUNT_##option)
 #define set_opt(sbi, option)   (sbi->mount_opt.opt |=
F2FS_MOUNT_##option)
@@ -316,6 +317,12 @@ enum {
NO_CHECK_TYPE
 };
 
+struct flush_cmd {
+   struct flush_cmd *next;
+   struct completion wait;
+   int ret;
+};
+
 struct f2fs_sm_info {
struct sit_info *sit_info;  /* whole segment information */
struct free_segmap_info *free_info; /* free segment information */
@@ -344,6 +351,14 @@ struct f2fs_sm_info {
 
unsigned int ipu_policy;/* in-place-update policy */
unsigned int min_ipu_util;  /* in-place-update threshold */
+
+   /* for flush command control */
+   struct task_struct *f2fs_issue_flush;   /* flush thread */
+   wait_queue_head_t flush_wait_queue; /* waiting queue for wake-up */
+   struct flush_cmd *issue_list;   /* list for command issue */
+   struct flush_cmd *dispatch_list;/* list for command dispatch */
+   spinlock_t issue_lock;  /* for issue list lock */
+   struct flush_cmd *issue_tail;   /* list tail of issue list */
 };
 
 /*
@@ -1160,6 +1175,7 @@ void destroy_node_manager_caches(void);
  */
 void f2fs_balance_fs(struct f2fs_sb_info *);
 void f2fs_balance_fs_bg(struct f2fs_sb_info *);
+int f2fs_issue_flush(struct f2fs_sb_info *);
 void invalidate_blocks(struct f2fs_sb_info *, block_t);
 void refresh_sit_entry(struct f2fs_sb_info *, block_t, block_t);
 void clear_prefree_segments(struct f2fs_sb_info *);
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 6ba2668..302d552 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -186,7 +186,7 @@ int f2fs_sync_file(struct file *file, loff_t start,
loff_t end, int datasync)
ret = wait_on_node_pages_writeback(sbi, inode->i_ino);
if (ret)
goto out;
-   ret = blkdev_issue_flush(inode->i_sb->s_bdev, GFP_KERNEL, NULL);
+   ret = f2fs_issue_flush(F2FS_SB(inode->i_sb));
}
 out:
trace_f2fs_sync_file_exit(inode, need_cp, datasync, ret);
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index f799c6a..4ad3431 100644
--- a/fs/f2fs/segment.c
+++ 

[PATCH] v3.14-7247-gcd6362b drivers/staging/lustre/lustre/libcfs/workitem.c Fix sparse warning.

[Mike Sampson]

Signed-off-by: Mike Sampson 

This fixes a sparse warning:
warning: symbol 'cfs_wi_data' was not declared. Should it be static?

---
 drivers/staging/lustre/lustre/libcfs/workitem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/libcfs/workitem.c 
b/drivers/staging/lustre/lustre/libcfs/workitem.c
index ba16fd5..0a03bf7 100644
--- a/drivers/staging/lustre/lustre/libcfs/workitem.c
+++ b/drivers/staging/lustre/lustre/libcfs/workitem.c
@@ -75,7 +75,7 @@ typedef struct cfs_wi_sched {
charws_name[CFS_WS_NAME_LEN];
 } cfs_wi_sched_t;
 
-struct cfs_workitem_data {
+static struct cfs_workitem_data {
/** serialize */
spinlock_t  wi_glock;
/** list of all schedulers */
-- 
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: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

[Willy Tarreau]

Hi Zhu,

On Thu, Apr 03, 2014 at 05:57:53PM +0800, zhuyj wrote:
> I reference the following 2 mainline commits. These 2 commits are based 
> on the current kernel 3.x and ethtool.
> If we only backport these 2 commits on kernel 2.6.x, this problem will 
> not be fixed yet.

OK fine, I just wanted that we keep the reference of these equivalent
patches in the commit message so that if later a newer patch changes
anything they did, at least we have some indications that the commit
might also have to be revisited.

I'll merge your patch and put these references there.

Thanks,
Willy

--
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: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

[zhuyj]

On 04/03/2014 05:27 PM, Willy Tarreau wrote:

Hi Zhu,

On Thu, Apr 03, 2014 at 05:11:48PM +0800, zhuyj wrote:

Hi, Claudiu

Please help to review this patch. This patch is for kernel 2.6.x. Thanks
a lot.

Hi, Willy

Please help to merge this patch to longterm: 2.6.32.61 since this
problem also occurs on this kernel. Thanks a lot.

Could you please send the reference to the equivalent mainline commit (the one
which disables the tx vlan feature I'm assuming) ? I'll happily queue it for
2.6.32.62.

Thanks,
Willy



Hi, Willy

I reference the following 2 mainline commits. These 2 commits are based 
on the current kernel 3.x and ethtool.
If we only backport these 2 commits on kernel 2.6.x, this problem will 
not be fixed yet.


Best Regards!
Zhu Yanjun

1. commit 87c288c6e9aa31720b72e2bc2d665e24e1653c3e
Author: Jiri Pirko 
Date:   Wed Jul 20 04:54:19 2011 +

gianfar: do vlan cleanup

- unify vlan and nonvlan rx path
- kill priv->vlgrp and gfar_vlan_rx_register
- allow to turn on/off rx/tx vlan accel via ethtool

Signed-off-by: Jiri Pirko 
Signed-off-by: David S. Miller 

 drivers/net/gianfar.c |   55 
++---

 1 file changed, 29 insertions(+), 26 deletions(-)

2.commit b852b720877e6b8e12b95a7cb4e00ea351b8cbfc
Author: Sebastian Pöhn 
Date:   Tue Jul 26 00:03:13 2011 +

gianfar: fix bug caused by 87c288c6e9aa31720b72e2bc2d665e24e1653c3e

commit 87c288c6e9aa31720b72e2bc2d665e24e1653c3e "gianfar: do vlan 
cleanup" has two issues:

# permutation of rx and tx flags
# enabling vlan tag insertion by default (this leads to unusable 
connections on some configurations)


If VLAN insertion is requested (via ethtool) it will be set at an 
other point ...


Signed-off-by: Sebastian Poehn 
Signed-off-by: David S. Miller 

 drivers/net/gianfar.c |6 +-
 1 file changed, 1 insertion(+), 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] ASoC: dapm: Add support for multi register mux

[Mark Brown]

On Thu, Apr 03, 2014 at 11:47:15AM +0200, Takashi Iwai wrote:

> I'm a bit late in the game, but I feel a bit uneasy through looking
> at the whole changes.  My primary question is, whether do we really
> need to share the same struct soc_enum for the onehot type?  What
> makes hard to use a struct soc_enum_onehot for them?  You need
> different individual get/put for each type.  We may still need to
> change soc_dapm_update stuff, but it's different from sharing
> soc_enum.

Indeed, I had thought this was where the discussion was heading - not
looked at this version of the patch yet.


signature.asc
Description: Digital signature

Re: [PATCH 1/2] nohz: use seqlock to avoid race on idle time stats v2

[Denys Vlasenko]

On Thu, Apr 3, 2014 at 9:02 AM, Hidetoshi Seto
 wrote:
>>> [PROBLEM 2]: broken iowait accounting.
>>>
>>> As historical nature, cpu's idle time was accounted as either
>>> idle or iowait depending on the presence of tasks blocked by
>>> I/O. No one complain about it for a long time. However:
>>>
>>>   > Still trying to wrap my head around it, but conceptually
>>>   > get_cpu_iowait_time_us() doesn't make any kind of sense.
>>>   > iowait isn't per cpu since effectively tasks that aren't
>>>   > running aren't assigned a cpu (as Oleg already pointed out).
>>>   -- Peter Zijlstra
>>>
>>> Now some kernel folks realized that accounting iowait as per-cpu
>>> does not make sense in SMP world. When we were in traditional
>>> UP era, cpu is considered to be waiting I/O if it is idle while
>>> nr_iowait > 0. But in these days with SMP systems, tasks easily
>>> migrate from a cpu where they issued an I/O to another cpu where
>>> they are queued after I/O completion.
>>
>> However, if we would put ourselves into admin's seat, iowait
>> immediately starts to make sense: for admin, the system state
>> where a lot of CPU time is genuinely idle is qualitatively different
>> form the state where a lot of CPU time is "idle" because
>> we are I/O bound.
>>
>> Admins probably wouldn't insist that iowait accounting must be
>> very accurate. I would hazard to guess that admins would settle
>> for the following rules:
>>
>> * (idle + iowait) should accurately represent amount of time
>> CPUs were idle.
>> * both idle and iowait should never go backwards
>> * when system is truly idle, only idle should increase
>> * when system is truly I/O bound on all CPUs, only iowait should increase
>> * when the situation is in between of the above two cases,
>> both iowait and idle counters should grow. It's ok if they
>> represent idle/IO-bound ratio only approximately
>
> Yep. Admins are at the mercy of iowait value, though they know it
> is not accurate.
>
> Assume there are task X,Y,Z (X issues io, Y sleeps moderately,
> and Z has low priority):
>
> Case 1:
>   cpu A: <--run X--><--iowait--><--run X--><--iowait--><--run X ...
>   cpu B: <---run Y--><--run Z--><--run Y--><--run Z--><--run Y ...
>   io:   <-- io X -->   <-- io X -->
>
> Case 2:
>   cpu A: <--run X--><--run Z---><--run X--><--run Z---><--run X ...
>   cpu B: <---run Y---><--idle--><---run Y---><--idle--><--run Y ...
>   io:   <-- io X -->   <-- io X -->
>
> So case 1 tend to be iowait while case 2 is idle, despite
> almost same workloads. Then what should admins do...?

This happens with current code too, right?
No regression then.

>>> Back to NO_HZ mechanism. Totally terrible thing here is that
>>> observer need to handle duration "delta" without knowing that
>>> nr_iowait of sleeping cpu can be changed easily by migration
>>> even if cpu is sleeping.
>>
>> How about the following: when CPU enters idle, it remembers
>> in struct tick_sched->idle_active whether it was "truly" idle
>> or I/O bound: something like
>>
>> ts->idle_active = nr_iowait_cpu(smp_processor_id()) ? 2 : 1;
>>
>> Then, when we exit idle, we account entire idle period as
>> "true" idle or as iowait depending on ts->idle_active value,
>> regardless of what happened to I/O bound task (whether
>> it migrated or not).
>
> It will not be acceptable. CPU can sleep significantly long
> time after all I/O bound tasks are migrated. e.g.:
>
> cpu A: <-run X-><-- iowait ---... (few days) ...--><-run Z ..
> cpu B: <-run X->..
> io: <-io X->

Does task migrate from an *idle* CPU? If yes, why?
Since its CPU is idle (i.e. immediately available
for it to be scheduled on),
I would imagine normally IO-blocked task stays
on its CPU's rq if it is idle.

> I agree on removing get_cpu_{idle,iowait}_time_us() (or marking
> it as obsolete) with some conditions.

Er?
My proposal does not eliminate or change
get_cpu_{idle,iowait}_time_us() API.
--
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: [Xen-devel] [PATCH] grant-table, xen-netback: Introduce helper functions for grant copy operations

[David Vrabel]

On 03/04/14 09:12, Paul Durrant wrote:
> Zoltan Kiss wrote:
>>
>> Create helper functions for grant copy operations and use them in netback.
>>
[...]
>> --- a/drivers/net/xen-netback/netback.c
>> +++ b/drivers/net/xen-netback/netback.c
>> @@ -275,23 +275,29 @@ static void xenvif_gop_frag_copy(struct xenvif *vif,
>> struct sk_buff *skb,
>>  bytes = MAX_BUFFER_OFFSET - npo->copy_off;
>>
>>  copy_gop = npo->copy + npo->copy_prod++;
>> -copy_gop->flags = GNTCOPY_dest_gref;
>> -copy_gop->len = bytes;
>>
>>  if (foreign_vif) {
>> -copy_gop->source.domid = foreign_vif->domid;
>> -copy_gop->source.u.ref = foreign_gref;
>> -copy_gop->flags |= GNTCOPY_source_gref;
>> +gnttab_set_copy_op_ref_to_ref(copy_gop,
>> +  foreign_gref,
>> +  npo->copy_gref,
>> +  foreign_vif->domid,
>> +  offset,
>> +  vif->domid,
>> +  npo->copy_off,
>> +  bytes,
>> +  GNTCOPY_dest_gref |
>> +  GNTCOPY_source_gref);
> 
> Can't you lose the flags here (and in the other variants)? Since
> they are implied by the variant of the function they could just be hardcoded
> there, couldn't they?

Even with that change these are still functions with 7 or 8 parameters
with no obvious order.  That's just awful.  The open-coded struct
initialization is better.

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 7/9] driver: staging: wlan-ng: Fixed white spaces issues

[Dan Carpenter]

On Thu, Apr 03, 2014 at 11:42:47AM +0200, Sherif wrote:
> Yes I enabled it:
> $ grep PRISM2_USB .config
> CONFIG_PRISM2_USB=m
> 
> But still getting the same output:
> $ make M=drivers/staging/wlan-ng/
>   Building modules, stage 2.
>   MODPOST 0 modules
> 

That's very odd.  It works for me.  I don't know what to tell you.

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] ASoC: dapm: Add support for multi register mux

[Takashi Iwai]

At Wed, 2 Apr 2014 20:11:50 -0700,
Arun Shamanna Lakshmi wrote:
> 
> - Modify soc_enum struct to handle pointers for reg and mask
> - Add dapm get and put APIs for multi register mux with one hot encoding
> - Update snd_soc_dapm_update struct to support multiple reg update
> 
> Signed-off-by: Arun Shamanna Lakshmi 
> Signed-off-by: Songhee Baek 

I'm a bit late in the game, but I feel a bit uneasy through looking
at the whole changes.  My primary question is, whether do we really
need to share the same struct soc_enum for the onehot type?  What
makes hard to use a struct soc_enum_onehot for them?  You need
different individual get/put for each type.  We may still need to
change soc_dapm_update stuff, but it's different from sharing
soc_enum.


thanks,

Takashi

> ---
>  include/sound/soc-dapm.h |   17 -
>  include/sound/soc.h  |   34 +++--
>  sound/soc/soc-core.c |   12 ++--
>  sound/soc/soc-dapm.c |  174 
> +++---
>  4 files changed, 197 insertions(+), 40 deletions(-)
> 
> diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h
> index ef78f56..ded46732 100644
> --- a/include/sound/soc-dapm.h
> +++ b/include/sound/soc-dapm.h
> @@ -305,6 +305,12 @@ struct device;
>   .get = snd_soc_dapm_get_enum_double, \
>   .put = snd_soc_dapm_put_enum_double, \
>   .private_value = (unsigned long) }
> +#define SOC_DAPM_ENUM_ONEHOT(xname, xenum) \
> +{.iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = xname, \
> + .info = snd_soc_info_enum_double, \
> + .get = snd_soc_dapm_get_enum_onehot, \
> + .put = snd_soc_dapm_put_enum_onehot, \
> + .private_value = (unsigned long) }
>  #define SOC_DAPM_ENUM_VIRT(xname, xenum) \
>   SOC_DAPM_ENUM(xname, xenum)
>  #define SOC_DAPM_ENUM_EXT(xname, xenum, xget, xput) \
> @@ -378,6 +384,10 @@ int snd_soc_dapm_get_enum_double(struct snd_kcontrol 
> *kcontrol,
>   struct snd_ctl_elem_value *ucontrol);
>  int snd_soc_dapm_put_enum_double(struct snd_kcontrol *kcontrol,
>   struct snd_ctl_elem_value *ucontrol);
> +int snd_soc_dapm_get_enum_onehot(struct snd_kcontrol *kcontrol,
> + struct snd_ctl_elem_value *ucontrol);
> +int snd_soc_dapm_put_enum_onehot(struct snd_kcontrol *kcontrol,
> + struct snd_ctl_elem_value *ucontrol);
>  int snd_soc_dapm_info_pin_switch(struct snd_kcontrol *kcontrol,
>   struct snd_ctl_elem_info *uinfo);
>  int snd_soc_dapm_get_pin_switch(struct snd_kcontrol *kcontrol,
> @@ -590,9 +600,10 @@ struct snd_soc_dapm_widget {
>  
>  struct snd_soc_dapm_update {
>   struct snd_kcontrol *kcontrol;
> - int reg;
> - int mask;
> - int val;
> + int reg[3];
> + int mask[3];
> + int val[3];
> + int num_regs;
>  };
>  
>  /* DAPM context */
> diff --git a/include/sound/soc.h b/include/sound/soc.h
> index 0b83168..add326a 100644
> --- a/include/sound/soc.h
> +++ b/include/sound/soc.h
> @@ -177,18 +177,24 @@
>   {.reg = xreg, .min = xmin, .max = xmax, \
>.platform_max = xmax} }
>  #define SOC_ENUM_DOUBLE(xreg, xshift_l, xshift_r, xitems, xtexts) \
> -{.reg = xreg, .shift_l = xshift_l, .shift_r = xshift_r, \
> +{.reg = &(int){(xreg)}, .shift_l = xshift_l, .shift_r = xshift_r, \
>   .items = xitems, .texts = xtexts, \
> - .mask = xitems ? roundup_pow_of_two(xitems) - 1 : 0}
> + .mask = &(unsigned int){(xitems ? roundup_pow_of_two(xitems) - 1 : 0)}, 
> \
> + .num_regs = 1, .type = SND_SOC_ENUM_NONE }
>  #define SOC_ENUM_SINGLE(xreg, xshift, xitems, xtexts) \
>   SOC_ENUM_DOUBLE(xreg, xshift, xshift, xitems, xtexts)
>  #define SOC_ENUM_SINGLE_EXT(xitems, xtexts) \
>  {.items = xitems, .texts = xtexts }
>  #define SOC_VALUE_ENUM_DOUBLE(xreg, xshift_l, xshift_r, xmask, xitems, 
> xtexts, xvalues) \
> -{.reg = xreg, .shift_l = xshift_l, .shift_r = xshift_r, \
> - .mask = xmask, .items = xitems, .texts = xtexts, .values = xvalues}
> +{.reg = &(int){(xreg)}, .shift_l = xshift_l, .shift_r = xshift_r, \
> + .mask = &(unsigned int){(xmask)}, .items = xitems, .texts = xtexts, \
> + .values = xvalues, .num_regs = 1, .type = SND_SOC_ENUM_NONE }
>  #define SOC_VALUE_ENUM_SINGLE(xreg, xshift, xmask, xnitmes, xtexts, xvalues) 
> \
>   SOC_VALUE_ENUM_DOUBLE(xreg, xshift, xshift, xmask, xnitmes, xtexts, 
> xvalues)
> +#define SOC_VALUE_ENUM_ONEHOT(xregs, xmasks, xnum_regs, xitems, xtexts, 
> xvalues) \
> +{.reg = xregs, .mask = xmasks, .num_regs = xnum_regs, \
> + .items = xitems, .texts = xtexts, .values = xvalues, \
> + .type = SND_SOC_ENUM_ONEHOT }
>  #define SOC_ENUM_SINGLE_VIRT(xitems, xtexts) \
>   SOC_ENUM_SINGLE(SND_SOC_NOPM, 0, xitems, xtexts)
>  #define SOC_ENUM(xname, xenum) \
> @@ -293,6 +299,9 @@
>  #define SOC_VALUE_ENUM_DOUBLE_DECL(name, xreg, xshift_l, xshift_r, xmask, 
> xtexts, xvalues) \
>   const struct soc_enum name = SOC_VALUE_ENUM_DOUBLE(xreg, xshift_l, 
> xshift_r, xmask, \
>   

Re: [PATCH] Provide additional sample information to Python scripts

[Joseph Schuchart]

On 07.03.2014 15:18, Arnaldo Carvalho de Melo wrote:
> Can you please resend, against the perf/core branch in
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git, and as an
> attachement or making sure that the patch is not mangled?

Arnaldo,

Please find attached our changes. I am sending you two patches since I
came across possible memory leaks while working on the original patch.
The first patch (perf_python_retval_decref.patch) adds calls to
Py_DECREF for the references returned by PyObject_CallObject().

The second patch (perf_python_add_sample.patch) contains our changes to
hand down the sample information for generic events. In addition, the
call-chain of the samples are constructed into a list and passed on. In
the case of generic events, this is just another entry in the dictionary
that is passed to the script as sole argument. For tracepoint events,
this adds another argument and hence changes the scripting interface.
Please feel free to remove these lines in python_process_tracepoint() if
you think that this is problematic.

I hope it is no problem that I am sending you two patches in one mail.
The patches are based on the git repository you pointed out, last
updated on April 2nd (commit 675b44bdf5f2a245f4479c5a8c40abf591007f36).

Please let me know if you have any questions.

Thanks,
Joseph
Perf: Provide sample information and call-chain to Python script

Provide additional sample information on generic events to Python
scripts, including pid, tid, and cpu for which the event was recorded.
Additionally, provide the call-chain recorded at each event with
resolved symbols (for both generic and tracepoint events). 
At the moment, the pointer to the sample struct is passed to scripts, 
which seems to be of little use. The patch puts this information in 
dictionaries for easy access by Python scripts.

Signed-off-by: Joseph Schuchart 
Acked-by: Thomas Ilsche 

diff --git a/tools/perf/util/scripting-engines/trace-event-python.c b/tools/perf/util/scripting-engines/trace-event-python.c
index a7c8932..255d451 100644
--- a/tools/perf/util/scripting-engines/trace-event-python.c
+++ b/tools/perf/util/scripting-engines/trace-event-python.c
@@ -32,6 +32,7 @@
 #include "../event.h"
 #include "../thread.h"
 #include "../trace-event.h"
+#include "../machine.h"
 
 PyMODINIT_FUNC initperf_trace_context(void);
 
@@ -234,12 +235,90 @@ static inline struct event_format *find_cache_event(struct perf_evsel *evsel)
 	return event;
 }
 
+
+static PyObject *python_process_callchain(struct perf_sample *sample,
+	 struct perf_evsel *evsel,
+	 struct addr_location *al)
+{
+	PyObject *pylist;
+
+	pylist = PyList_New(0);
+	if (!pylist)
+		Py_FatalError("couldn't create Python list");
+
+	if (!symbol_conf.use_callchain || !sample->callchain)
+		goto exit;
+
+	if (machine__resolve_callchain(al->machine, evsel, al->thread,
+	   sample, NULL, NULL,
+	   PERF_MAX_STACK_DEPTH) != 0) {
+		pr_err("Failed to resolve callchain. Skipping\n");
+		goto exit;
+	}
+	callchain_cursor_commit(_cursor);
+
+
+	while (1) {
+		PyObject *pyelem;
+		struct callchain_cursor_node *node;
+		node = callchain_cursor_current(_cursor);
+		if (!node)
+			break;
+
+		pyelem = PyDict_New();
+		if (!pyelem)
+			Py_FatalError("couldn't create Python dictionary");
+
+
+		pydict_set_item_string_decref(pyelem, "ip",
+PyLong_FromUnsignedLongLong(node->ip));
+
+		if (node->sym) {
+			PyObject *pysym  = PyDict_New();
+			if (!pysym)
+Py_FatalError("couldn't create Python dictionary");
+			pydict_set_item_string_decref(pysym, "start",
+	PyLong_FromUnsignedLongLong(node->sym->start));
+			pydict_set_item_string_decref(pysym, "end",
+	PyLong_FromUnsignedLongLong(node->sym->end));
+			pydict_set_item_string_decref(pysym, "binding",
+	PyInt_FromLong(node->sym->binding));
+			pydict_set_item_string_decref(pysym, "name",
+	PyString_FromStringAndSize(node->sym->name,
+			node->sym->namelen));
+			pydict_set_item_string_decref(pyelem, "sym", pysym);
+		}
+
+		if (node->map) {
+			struct map *map = node->map;
+			const char *dsoname = "[unknown]";
+			if (map && map->dso && (map->dso->name || map->dso->long_name)) {
+if (symbol_conf.show_kernel_path && map->dso->long_name)
+	dsoname = map->dso->long_name;
+else if (map->dso->name)
+	dsoname = map->dso->name;
+			}
+			pydict_set_item_string_decref(pyelem, "dso",
+	PyString_FromString(dsoname));
+		}
+
+		callchain_cursor_advance(_cursor);
+		PyList_Append(pylist, pyelem);
+		Py_DECREF(pyelem);
+	}
+
+exit:
+	return pylist;
+}
+
+
 static void python_process_tracepoint(struct perf_sample *sample,
   struct perf_evsel *evsel,
   struct thread *thread,
   struct addr_location *al)
 {
-	PyObject *handler, *retval, *context, *t, *obj, *dict = NULL;
+	PyObject *handler, *retval, *context, *t, *obj, *callchain;
+	PyObject *dict = NULL;
 	static char handler_name[256];
 	struct format_field *field;
 	unsigned long long val;
@@ -327,6 

Re: [PATCH 1/3] staging: vt6655: removed incorrect casting in wpactl.c

[Dan Carpenter]

On Tue, Mar 25, 2014 at 09:30:18PM +0100, sil...@port1024.net wrote:
> From: Silvio F 

Don't use this header for your own patches.

> 
> This patch fixes the following type of sparse warnings:
> 
> drivers/staging/vt6655/wpactl.c:596:47: warning: cast from restricted gfp_t
> drivers/staging/vt6655/wpactl.c:638:68: warning: cast from restricted gfp_t
> drivers/staging/vt6655/wpactl.c:860:42: warning: cast from restricted gfp_t
> 
> Signed-off-by: Silvio F 

We can't verify this is you if you don't send from the same email you
sign off by.  We can't really verify perfectly anyway, of course, but
at least we try do the minimum.

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 0/2] Backport to 3.10 stable (Fix CPU0 stall after CPU1 hotplug)

[Luís Henriques]

On Wed, Apr 02, 2014 at 04:19:36PM +0200, Krzysztof Kozlowski wrote:
> Hi,
> 
> These two patches are good candidates for backporting to stable 3.10. They fix
> a CPU0 stall due to timer list corruption after hotplugging CPU1.
> 
> 1. Commit: 95731ebb114c
>cpufreq: Fix governor start/stop race condition
> 2. Commit: 3617f2ca6d0e
>cpufreq: Fix timer/workqueue corruption due to double queueing
> 

Thank you Krzysztof, I'll queue this 2nd patch for the 3.11 kernel as well
(the 1st one is already there).

Cheers,
--
Luís

> Stall:
> [  130.127262] INFO: rcu_preempt detected stalls on CPUs/tasks: { 0} 
> (detected by 1, t=12003 jiffies, g=172, c=171, q=0)
> [  130.132285] Task dump for CPU 0:
> [  130.135496] swapper/0   R running  0 0  0 0x1000
> [  130.141983] [] (__schedule+0x3bc/0x80c) from [] 
> (cpu_idle_force_poll+0x0/0x4)
> 
> List corruption:
> [ 4244.528166] [ cut here ]
> [ 4244.528507] WARNING: at lib/list_debug.c:33 __list_add+0xa8/0xbc()
> [ 4244.533418] list_add corruption. prev->next should be next (c08864b0), but 
> was   (null). (prev=c1105454).
> [ 4244.542938] Modules linked in:
> [ 4244.546024] CPU: 0 PID: 1 Comm: sh Tainted: GW
> 3.10.14-03857-g20b26f7e0c59-dirty #1354
> [ 4244.554956] [] (unwind_backtrace+0x0/0x138) from [] 
> (show_stack+0x10/0x14)
> [ 4244.563518] [] (show_stack+0x10/0x14) from [] 
> (warn_slowpath_common+0x4c/0x68)
> [ 4244.572452] [] (warn_slowpath_common+0x4c/0x68) from 
> [] (warn_slowpath_fmt+0x30/0x40)
> [ 4244.582008] [] (warn_slowpath_fmt+0x30/0x40) from [] 
> (__list_add+0xa8/0xbc)
> [ 4244.590696] [] (__list_add+0xa8/0xbc) from [] 
> (internal_add_timer+0x10/0x40)
> [ 4244.599462] [] (internal_add_timer+0x10/0x40) from [] 
> (add_timer_on+0x74/0x124)
> [ 4244.608493] [] (add_timer_on+0x74/0x124) from [] 
> (mod_delayed_work_on+0x50/0x68)
> [ 4244.617622] [] (mod_delayed_work_on+0x50/0x68) from [] 
> (gov_queue_work+0x48/0xa4)
> [ 4244.626805] [] (gov_queue_work+0x48/0xa4) from [] 
> (cpufreq_governor_dbs+0x29c/0x668)
> [ 4244.636261] [] (cpufreq_governor_dbs+0x29c/0x668) from 
> [] (__cpufreq_governor.part.9+0x30/0xd4)
> [ 4244.646689] [] (__cpufreq_governor.part.9+0x30/0xd4) from 
> [] (__cpufreq_remove_dev.isra.12+0x130/0x484)
> [ 4244.657798] [] (__cpufreq_remove_dev.isra.12+0x130/0x484) from 
> [] (cpufreq_cpu_callback+0x70/0x80)
> [ 4244.668466] [] (cpufreq_cpu_callback+0x70/0x80) from 
> [] (notifier_call_chain+0x44/0x84)
> [ 4244.678184] [] (notifier_call_chain+0x44/0x84) from [] 
> (__cpu_notify+0x2c/0x48)
> [ 4244.687200] [] (__cpu_notify+0x2c/0x48) from [] 
> (_cpu_down+0x80/0x268)
> [ 4244.695436] [] (_cpu_down+0x80/0x268) from [] 
> (cpu_down+0x28/0x3c)
> [ 4244.703334] [] (cpu_down+0x28/0x3c) from [] 
> (store_online+0x30/0x74)
> [ 4244.711426] [] (store_online+0x30/0x74) from [] 
> (dev_attr_store+0x18/0x24)
> [ 4244.720027] [] (dev_attr_store+0x18/0x24) from [] 
> (sysfs_write_file+0x80/0xb4)
> [ 4244.728960] [] (sysfs_write_file+0x80/0xb4) from [] 
> (vfs_write+0xbc/0x1bc)
> [ 4244.737551] [] (vfs_write+0xbc/0x1bc) from [] 
> (SyS_write+0x40/0x68)
> [ 4244.745541] [] (SyS_write+0x40/0x68) from [] 
> (ret_fast_syscall+0x0/0x3c)
> [ 4244.753881] ---[ end trace 6c85e0f7596a61f2 ]---
> [ 4244.758467] [ cut here ]
> [ 4244.763115] WARNING: at lib/list_debug.c:36 __list_add+0x88/0xbc()
> [ 4244.769247] list_add double add: new=c1105454, prev=c1105454, 
> next=c08864b0.
> [ 4244.776254] Modules linked in:
> [ 4244.779337] CPU: 0 PID: 1 Comm: sh Tainted: GW
> 3.10.14-03857-g20b26f7e0c59-dirty #1354
> [ 4244.788247] [] (unwind_backtrace+0x0/0x138) from [] 
> (show_stack+0x10/0x14)
> [ 4244.796830] [] (show_stack+0x10/0x14) from [] 
> (warn_slowpath_common+0x4c/0x68)
> [ 4244.805766] [] (warn_slowpath_common+0x4c/0x68) from 
> [] (warn_slowpath_fmt+0x30/0x40)
> [ 4244.815325] [] (warn_slowpath_fmt+0x30/0x40) from [] 
> (__list_add+0x88/0xbc)
> [ 4244.824009] [] (__list_add+0x88/0xbc) from [] 
> (internal_add_timer+0x10/0x40)
> [ 4244.832777] [] (internal_add_timer+0x10/0x40) from [] 
> (add_timer_on+0x74/0x124)
> [ 4244.841811] [] (add_timer_on+0x74/0x124) from [] 
> (mod_delayed_work_on+0x50/0x68)
> [ 4244.850935] [] (mod_delayed_work_on+0x50/0x68) from [] 
> (gov_queue_work+0x48/0xa4)
> [ 4244.860120] [] (gov_queue_work+0x48/0xa4) from [] 
> (cpufreq_governor_dbs+0x29c/0x668)
> [ 4244.869577] [] (cpufreq_governor_dbs+0x29c/0x668) from 
> [] (__cpufreq_governor.part.9+0x30/0xd4)
> [ 4244.880007] [] (__cpufreq_governor.part.9+0x30/0xd4) from 
> [] (__cpufreq_remove_dev.isra.12+0x130/0x484)
> [ 4244.891112] [] (__cpufreq_remove_dev.isra.12+0x130/0x484) from 
> [] (cpufreq_cpu_callback+0x70/0x80)
> [ 4244.901780] [] (cpufreq_cpu_callback+0x70/0x80) from 
> [] (notifier_call_chain+0x44/0x84)
> [ 4244.911499] [] (notifier_call_chain+0x44/0x84) from [] 
> (__cpu_notify+0x2c/0x48)
> [ 4244.920515] [] (__cpu_notify+0x2c/0x48) from [] 
> (_cpu_down+0x80/0x268)
> 

Re: [PATCH 7/9] driver: staging: wlan-ng: Fixed white spaces issues

[Sherif]

Yes I enabled it:
$ grep PRISM2_USB .config
CONFIG_PRISM2_USB=m

But still getting the same output:
$ make M=drivers/staging/wlan-ng/
  Building modules, stage 2.
  MODPOST 0 modules

On 04/03/2014 11:38 AM, Dan Carpenter wrote:

On Thu, Apr 03, 2014 at 10:21:21AM +0200, Sherif wrote:

Yes I see the error. I have tried to build the wlan-ng driver using
make M=drivers/staging/wlan-ng/ but it built nothing, so I went one
step up and built make M=drivers/staging/ as a whole and it built
fine, I think I am missing something here, how do I specify this
module for the build to test my changes?



Is it enabled in your .config?

grep PRISM2_USB .config

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: on kernel 2.6.34.15, vlan and raw packets can not be received with gfar-enet nic

[Willy Tarreau]

Hi Zhu,

On Thu, Apr 03, 2014 at 05:11:48PM +0800, zhuyj wrote:
> Hi, Claudiu
> 
> Please help to review this patch. This patch is for kernel 2.6.x. Thanks 
> a lot.
> 
> Hi, Willy
> 
> Please help to merge this patch to longterm: 2.6.32.61 since this 
> problem also occurs on this kernel. Thanks a lot.

Could you please send the reference to the equivalent mainline commit (the one
which disables the tx vlan feature I'm assuming) ? I'll happily queue it for
2.6.32.62.

Thanks,
Willy

--
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: [RESEND] drivercore: deferral race condition fix

[Mark Brown]

On Thu, Apr 03, 2014 at 10:12:07AM +0300, Peter Ujfalusi wrote:
> When the kernel is built with CONFIG_PREEMPT it is possible to reach a state
> when all modules loaded but some driver still stuck in the deferred list
> and there is a need for external event to kick the deferred queue to probe
> these drivers.

Acked-by: Mark Brown 


signature.asc
Description: Digital signature

Re: [PATCH] ASoC: dapm: Add support for multi register mux

[Mark Brown]

On Thu, Apr 03, 2014 at 10:27:17AM +0200, Lars-Peter Clausen wrote:
> On 04/03/2014 05:11 AM, Arun Shamanna Lakshmi wrote:

> >+enum snd_soc_enum_type {
> >+SND_SOC_ENUM_NONE = 0,

> I'm not sure if NONE is the right term. Maybe BINARY is better.

Yes, it's definitely not none.


signature.asc
Description: Digital signature

Re: [PATCH 2/3] ARM: dts: document the berlin enable-method property

[Sebastian Hesselbarth]

On 04/03/2014 09:14 AM, Antoine Ténart wrote:

On 03/04/2014 10:54, Antoine Ténart wrote:

On 03/04/2014 10:22, Jisheng Zhang wrote:

On Thu, 3 Apr 2014 01:08:15 -0700
Antoine Ténart  wrote:


Signed-off-by: Antoine Ténart 
---
  Documentation/devicetree/bindings/arm/cpus.txt | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
b/Documentation/devicetree/bindings/arm/cpus.txt index
333f4aea3029..a9e42a2dbc99 100644 ---
a/Documentation/devicetree/bindings/arm/cpus.txt +++
b/Documentation/devicetree/bindings/arm/cpus.txt @@ -185,6 +185,8 @@
nodes
to be present and contain the properties described below.
"qcom,gcc-msm8660"
  "qcom,kpss-acc-v1"
  "qcom,kpss-acc-v2"
+"marvell,88de31-smp" - cpu-core handling for


why not "marvell,berlin-smp"?


We have SMP on the BG2 and the BG2Q currently. Future boards may not be
compatible with this method (BG3 ?), I think "marvell,berlin-smp" is too
generic.

We could use "marvell,88de31xx-smp" as Alexandre suggested.


"marvell,88de31xx-smp" is not a good choice too, since futur SoC may
match the "xx" and not use this method. A better way should be to use
the first SoC implementing the feature, so "marvell,88de3100".


Never introduce the SoC numbers, we have chosen to stick with
berlin2{,cd,q} so use that.

Given the comment from Mark Rutland and Russell King here[1], I'd rather
concentrate on a proper SMP implementation. Unfortunately, I haven't
found a good documentation about the requirements nor call sequence -
but I haven't looked hard.

Having said that, can we postpone the DT enable method patches until
we agreed on a better SMP implementation?

Sebastian

[1] http://www.spinics.net/lists/arm-kernel/msg318585.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 7/9] driver: staging: wlan-ng: Fixed white spaces issues

[Dan Carpenter]

On Thu, Apr 03, 2014 at 10:21:21AM +0200, Sherif wrote:
> Yes I see the error. I have tried to build the wlan-ng driver using
> make M=drivers/staging/wlan-ng/ but it built nothing, so I went one
> step up and built make M=drivers/staging/ as a whole and it built
> fine, I think I am missing something here, how do I specify this
> module for the build to test my changes?
> 

Is it enabled in your .config?

grep PRISM2_USB .config

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] arm64: Fix duplicated Kconfig entries again

[Viresh Kumar]

On 3 April 2014 14:57, Hanjun Guo  wrote:
> Great, thanks Viresh to let me know this.
> Actually I also sent a patch named "arm64: Fix duplicated Kconfig entries
> again" about one week ago :)
>
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg612363.html
>
> And I think there is still a problem after commit 62d1a3ba - multi-entries
> for source "kernel/power/Kconfig", so how about the following fix?

I didn't notice that :)

> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index e6e4d37..6085dca 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -317,14 +317,8 @@ config ARCH_SUSPEND_POSSIBLE
>  config ARM64_CPU_SUSPEND
> def_bool PM_SLEEP
>
> -endmenu
> -
> -menu "CPU Power Management"
> -
>  source "drivers/cpuidle/Kconfig"
>
> -source "kernel/power/Kconfig"
> -
>  source "drivers/cpufreq/Kconfig"
>
>  endmenu
>
> If it makes sense, I will send out a patch for it.

We actually need to menu options here,
menu "Power management options"
menu "CPU Power Management"

And so probably you just need to do this:
> -source "kernel/power/Kconfig"
> -

from CPU Power Management options..
--
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/

Attn

[Charitable goal]

Attn

I got your details after an extensive on-line search Via (Network
Power Charitable Trust) for a reliable person. 
I am 57 years old and was diagnosed for cancer about 4 years ago,
kindly Contact my lawyer through this email address or you can call is
private Line :(+855-070-769-519)(barristermao_robin...@aol.com)

He Is A God fearing Person work with Him, if you are interested in
carrying out this task, so that He can arrange the release of the funds
(10,5M)USD to you.

Mrs.Samantha Fu
--
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] mfd: timberdale: Depend on X86_32

[Jean Delvare]

As far as I know the Timberdale chip was only used as a companion for
Intel Atom E600 series processors. As such, its drivers are only
useful on X86_32.

Signed-off-by: Jean Delvare 
Cc: Samuel Ortiz 
Cc: Lee Jones 
---
 drivers/mfd/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-3.14.orig/drivers/mfd/Kconfig 2014-04-03 09:16:01.741554631 +0200
+++ linux-3.14/drivers/mfd/Kconfig  2014-04-03 09:57:44.438396779 +0200
@@ -1014,7 +1014,7 @@ config MFD_LM3533
 config MFD_TIMBERDALE
tristate "Timberdale FPGA"
select MFD_CORE
-   depends on PCI && GPIOLIB
+   depends on PCI && GPIOLIB && (X86_32 || COMPILE_TEST)
---help---
This is the core driver for the timberdale FPGA. This device is a
multifunction device which exposes numerous platform devices.


-- 
Jean Delvare
SUSE L3 Support
--
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] mmc: Add SDIO function devicetree subnode parsing

[Sascha Hauer]

This adds SDIO devicetree subnode parsing to the mmc core. While
SDIO devices are runtime probable they sometimes need nonprobable
additional information on embedded systems, like an additional gpio
interrupt or a clock. This patch makes it possible to supply this
information from the devicetree. SDIO drivers will find a pointer
to the devicenode in their devices of_node pointer.

Signed-off-by: Sascha Hauer 
Cc: linux-...@vger.kernel.org
Cc: Chris Ball 
Cc: linux-kernel@vger.kernel.org
Cc: Luciano Coelho 
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---

Motivation for this comes from the TI wilink WLAN driver which
needs platform_data and currently specifies this via an awkward
global data pointer, see drivers/net/wireless/ti/wilink_platform_data.c

 Documentation/devicetree/bindings/mmc/mmc.txt | 30 +++
 drivers/mmc/core/bus.c| 14 +
 drivers/mmc/core/core.c   | 25 ++
 drivers/mmc/core/core.h   |  3 +++
 drivers/mmc/core/sdio_bus.c   | 16 ++
 5 files changed, 88 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt 
b/Documentation/devicetree/bindings/mmc/mmc.txt
index 458b57f..6ccfae8 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -51,6 +51,15 @@ Optional SDIO properties:
 - keep-power-in-suspend: Preserves card power during a suspend/resume cycle
 - enable-sdio-wakeup: Enables wake up of host system on SDIO IRQ assertion
 
+Function subnodes:
+On embedded systems the cards connected to a host may need additional 
properties.
+These can be specified in subnodes to the host controller node. The subnodes 
are
+identified by the standard 'reg' property.
+Required properties:
+- reg: Must contain the SDIO function number of the function this subnode 
describes.
+   A value of 0 denotes the memory SD function, values from 1 to 7 denote 
the
+   SDIO functions.
+
 Example:
 
 sdhci@ab00 {
@@ -65,3 +74,24 @@ sdhci@ab00 {
keep-power-in-suspend;
enable-sdio-wakeup;
 }
+
+Example with SDIO subnode:
+
+sdhci@ab00 {
+   compatible = "sdhci";
+   reg = <0xab00 0x200>;
+   interrupts = <23>;
+   bus-width = <4>;
+   cd-gpios = < 69 0>;
+   cd-inverted;
+   wp-gpios = < 70 0>;
+   max-frequency = <5000>;
+   keep-power-in-suspend;
+   enable-sdio-wakeup;
+
+   func@2 {
+   reg = <2>;
+   reset-gpios = < 69 0>;
+   clock-frequency = <2600>;
+   };
+}
diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
index 64145a3..b63c9b9 100644
--- a/drivers/mmc/core/bus.c
+++ b/drivers/mmc/core/bus.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -297,6 +298,16 @@ struct mmc_card *mmc_alloc_card(struct mmc_host *host, 
struct device_type *type)
return card;
 }
 
+static void mmc_set_of_node(struct mmc_card *card)
+{
+   struct mmc_host *host = card->host;
+
+   if (!host->parent->of_node)
+   return;
+
+   card->dev.of_node = mmc_of_find_child_device(host->parent->of_node, 0);
+}
+
 /*
  * Register a new MMC card with the driver model.
  */
@@ -367,6 +378,8 @@ int mmc_add_card(struct mmc_card *card)
 #endif
mmc_init_context_info(card->host);
 
+   mmc_set_of_node(card);
+
ret = device_add(>dev);
if (ret)
return ret;
@@ -395,6 +408,7 @@ void mmc_remove_card(struct mmc_card *card)
mmc_hostname(card->host), card->rca);
}
device_del(>dev);
+   of_node_put(card->dev.of_node);
}
 
put_device(>dev);
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 098374b..9ca0ad2 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1216,6 +1216,31 @@ EXPORT_SYMBOL(mmc_of_parse_voltage);
 
 #endif /* CONFIG_OF */
 
+static int mmc_of_get_func_num(struct device_node *node)
+{
+   u32 reg;
+   int ret;
+
+   ret = of_property_read_u32(node, "reg", );
+   if (ret < 0)
+   return ret;
+
+   return reg;
+}
+
+struct device_node *mmc_of_find_child_device(struct device_node *parent,
+   unsigned func_num)
+{
+   struct device_node *node;
+
+   for_each_child_of_node(parent, node) {
+   if (mmc_of_get_func_num(node) == func_num)
+   return node;
+   }
+
+   return NULL;
+}
+
 #ifdef CONFIG_REGULATOR
 
 /**
diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
index 443a584..65615f3 100644
--- a/drivers/mmc/core/core.h
+++ b/drivers/mmc/core/core.h
@@ -32,6 +32,9 @@ struct mmc_bus_ops {
 void mmc_attach_bus(struct mmc_host *host, const struct mmc_bus_ops *ops);
 void mmc_detach_bus(struct mmc_host *host);
 
+struct 

Re: [Intel-gfx] [PATCH] drm/i915: fix command parser debug print format mismatches

[Daniel Vetter]

On Wed, Apr 02, 2014 at 08:26:23AM -0700, Randy Dunlap wrote:
> On 04/02/2014 01:24 AM, Jani Nikula wrote:
> > Drop the cast from the pointer diff to fix:
> > 
> > drivers/gpu/drm/i915/i915_cmd_parser.c:405:4: warning: format '%td' expects
> > argument of type 'ptrdiff_t', but argument 5 has type 'long unsigned int'
> > [-Wformat]
> > 
> > While at it, use %u for u32.
> > 
> > Reported-by: Randy Dunlap 
> > Signed-off-by: Jani Nikula 
> > 
> > ---
> > 
> > Randy, try as I might, I wasn't able to coerce gcc to spit out that
> > warning. Please enlighten me! (Does this fix the warn?)
> 
> Yes, it does.  Thanks.
> 
> Acked-by: Randy Dunlap 

Maybe I'm blind, but I think the recent refactoring patch fixed this. Can
someone please double-check? I always get confused with printf formats ;-)

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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] arm64: Fix duplicated Kconfig entries again

[Hanjun Guo]

On 2014-4-3 17:27, Hanjun Guo wrote:
> On 2014-4-3 16:51, Catalin Marinas wrote:
>> On Thu, Apr 03, 2014 at 09:41:57AM +0100, Viresh Kumar wrote:
>>> On Thu, Apr 3, 2014 at 2:05 PM, Hanjun Guo  wrote:
 How about the following patch? if it is ok, I will resend it.
>>>
>>> http://www.spinics.net/lists/arm-kernel/msg319545.html
>>
>> I can see commit 62d1a3ba5adc5653d43f6cd3a90758bb6ad5d5bd (arm64: Fix
>> duplicated Kconfig entries again) already in mainline, so problem
>> solved.
>>
>> Thanks Josh ;)

I just noticed Josh's patch half a hour ago, that's why I didn't review it...

--
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] net: Micrel KSZ8864RMN 4-port managed switch support

[Philipp Zabel]

This patch adds support for the Micrel KSZ8864RMN switch to the spi_ks8995
driver. The KSZ8864RMN switch has a wider 256-byte register space.

Signed-off-by: Philipp Zabel 
---
Changes since v1:
 - Store a copy of ks8995_registers_attr in the struct ks8995_switch to
   avoid problems in the theoretical case of a board with both KS8995MA
   and KSZ8864RMN switches.
 - Make ks8995_registers_attr const.
 - Use %x instead of %01x in dev_info.
---
 drivers/net/phy/spi_ks8995.c | 52 ++--
 1 file changed, 40 insertions(+), 12 deletions(-)

diff --git a/drivers/net/phy/spi_ks8995.c b/drivers/net/phy/spi_ks8995.c
index 4cf5fb9..22b047f 100644
--- a/drivers/net/phy/spi_ks8995.c
+++ b/drivers/net/phy/spi_ks8995.c
@@ -1,5 +1,5 @@
 /*
- * SPI driver for Micrel/Kendin KS8995M ethernet switch
+ * SPI driver for Micrel/Kendin KS8995M and KSZ8864RMN ethernet switches
  *
  * Copyright (C) 2008 Gabor Juhos 
  *
@@ -70,7 +70,10 @@
 #define KS8995_REG_IAD10x76/* Indirect Access Data 1 */
 #define KS8995_REG_IAD00x77/* Indirect Access Data 0 */
 
+#define KSZ8864_REG_ID10xfe/* Chip ID in bit 7 */
+
 #define KS8995_REGS_SIZE   0x80
+#define KSZ8864_REGS_SIZE  0x100
 
 #define ID1_CHIPID_M   0xf
 #define ID1_CHIPID_S   4
@@ -94,6 +97,7 @@ struct ks8995_switch {
struct spi_device   *spi;
struct mutexlock;
struct ks8995_pdata *pdata;
+   struct bin_attributeregs_attr;
 };
 
 static inline u8 get_chip_id(u8 val)
@@ -216,11 +220,11 @@ static ssize_t ks8995_registers_read(struct file *filp, 
struct kobject *kobj,
dev = container_of(kobj, struct device, kobj);
ks8995 = dev_get_drvdata(dev);
 
-   if (unlikely(off > KS8995_REGS_SIZE))
+   if (unlikely(off > ks8995->regs_attr.size))
return 0;
 
-   if ((off + count) > KS8995_REGS_SIZE)
-   count = KS8995_REGS_SIZE - off;
+   if ((off + count) > ks8995->regs_attr.size)
+   count = ks8995->regs_attr.size - off;
 
if (unlikely(!count))
return count;
@@ -238,11 +242,11 @@ static ssize_t ks8995_registers_write(struct file *filp, 
struct kobject *kobj,
dev = container_of(kobj, struct device, kobj);
ks8995 = dev_get_drvdata(dev);
 
-   if (unlikely(off >= KS8995_REGS_SIZE))
+   if (unlikely(off >= ks8995->regs_attr.size))
return -EFBIG;
 
-   if ((off + count) > KS8995_REGS_SIZE)
-   count = KS8995_REGS_SIZE - off;
+   if ((off + count) > ks8995->regs_attr.size)
+   count = ks8995->regs_attr.size - off;
 
if (unlikely(!count))
return count;
@@ -251,7 +255,7 @@ static ssize_t ks8995_registers_write(struct file *filp, 
struct kobject *kobj,
 }
 
 
-static struct bin_attribute ks8995_registers_attr = {
+static const struct bin_attribute ks8995_registers_attr = {
.attr = {
.name   = "registers",
.mode   = S_IRUSR | S_IWUSR,
@@ -306,20 +310,44 @@ static int ks8995_probe(struct spi_device *spi)
goto err_drvdata;
}
 
+   memcpy(>regs_attr, _registers_attr, sizeof(ks->regs_attr));
+   if (get_chip_id(ids[1]) != CHIPID_M) {
+   u8 val;
+
+   /* Check if this is a KSZ8864RMN */
+   err = ks8995_read(ks, , KSZ8864_REG_ID1, sizeof(val));
+   if (err < 0) {
+   dev_err(>dev,
+   "unable to read chip id register, err=%d\n",
+   err);
+   goto err_drvdata;
+   }
+   if ((val & 0x80) == 0) {
+   dev_err(>dev, "unknown chip:%02x,0\n", ids[1]);
+   goto err_drvdata;
+   }
+   ks->regs_attr.size = KSZ8864_REGS_SIZE;
+   }
+
err = ks8995_reset(ks);
if (err)
goto err_drvdata;
 
-   err = sysfs_create_bin_file(>dev.kobj, _registers_attr);
+   err = sysfs_create_bin_file(>dev.kobj, >regs_attr);
if (err) {
dev_err(>dev, "unable to create sysfs file, err=%d\n",
err);
goto err_drvdata;
}
 
-   dev_info(>dev, "KS89%02X device found, Chip ID:%01x, "
-   "Revision:%01x\n", ids[0],
-   get_chip_id(ids[1]), get_chip_rev(ids[1]));
+   if (get_chip_id(ids[1]) == CHIPID_M) {
+   dev_info(>dev,
+"KS8995 device found, Chip ID:%x, Revision:%x\n",
+get_chip_id(ids[1]), get_chip_rev(ids[1]));
+   } else {
+   dev_info(>dev, "KSZ8864 device found, Revision:%x\n",
+get_chip_rev(ids[1]));
+   }
 
return 0;
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" 

Re: [PATCH] arm64: Fix duplicated Kconfig entries again

[Hanjun Guo]

On 2014-4-3 16:51, Catalin Marinas wrote:
> On Thu, Apr 03, 2014 at 09:41:57AM +0100, Viresh Kumar wrote:
>> On Thu, Apr 3, 2014 at 2:05 PM, Hanjun Guo  wrote:
>>> How about the following patch? if it is ok, I will resend it.
>>
>> http://www.spinics.net/lists/arm-kernel/msg319545.html
> 
> I can see commit 62d1a3ba5adc5653d43f6cd3a90758bb6ad5d5bd (arm64: Fix
> duplicated Kconfig entries again) already in mainline, so problem
> solved.
> 
> Thanks Josh ;)

Great, thanks Viresh to let me know this.
Actually I also sent a patch named "arm64: Fix duplicated Kconfig entries
again" about one week ago :)

https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg612363.html

And I think there is still a problem after commit 62d1a3ba - multi-entries
for source "kernel/power/Kconfig", so how about the following fix?

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e6e4d37..6085dca 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -317,14 +317,8 @@ config ARCH_SUSPEND_POSSIBLE
 config ARM64_CPU_SUSPEND
def_bool PM_SLEEP

-endmenu
-
-menu "CPU Power Management"
-
 source "drivers/cpuidle/Kconfig"

-source "kernel/power/Kconfig"
-
 source "drivers/cpufreq/Kconfig"

 endmenu

If it makes sense, I will send out a patch for it.

Thanks
Hanjun
--
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] ARM: dts: document the berlin enable-method property

[Jisheng Zhang]

Hi Antoine,

On Thu, 3 Apr 2014 01:54:07 -0700
Antoine Ténart  wrote:

> Jisheng,
> 
> On 03/04/2014 10:22, Jisheng Zhang wrote:
> > Hi,
> >
> > On Thu, 3 Apr 2014 01:08:15 -0700
> > Antoine Ténart  wrote:
> >
> >> Signed-off-by: Antoine Ténart 
> >> ---
> >>   Documentation/devicetree/bindings/arm/cpus.txt | 2 ++
> >>   1 file changed, 2 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
> >> b/Documentation/devicetree/bindings/arm/cpus.txt index
> >> 333f4aea3029..a9e42a2dbc99 100644 ---
> >> a/Documentation/devicetree/bindings/arm/cpus.txt +++
> >> b/Documentation/devicetree/bindings/arm/cpus.txt @@ -185,6 +185,8 @@
> >> nodes to be present and contain the properties described below.
> >> "qcom,gcc-msm8660" "qcom,kpss-acc-v1"
> >>"qcom,kpss-acc-v2"
> >> +  "marvell,88de31-smp" - cpu-core handling for
> >
> > why not "marvell,berlin-smp"?
> 
> We have SMP on the BG2 and the BG2Q currently. Future boards may not be 
> compatible with this method (BG3 ?), I think "marvell,berlin-smp" is too 

Yes. It's not compatible. But it will be PSCI. FWICT, current smp method
would be only used for BG2/BG2CT.

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/3] ARM: dts: document the berlin enable-method property

[Antoine Ténart]

On 03/04/2014 10:54, Antoine Ténart wrote:

Jisheng,

On 03/04/2014 10:22, Jisheng Zhang wrote:

Hi,

On Thu, 3 Apr 2014 01:08:15 -0700
Antoine Ténart  wrote:


Signed-off-by: Antoine Ténart 
---
  Documentation/devicetree/bindings/arm/cpus.txt | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
b/Documentation/devicetree/bindings/arm/cpus.txt index
333f4aea3029..a9e42a2dbc99 100644 ---
a/Documentation/devicetree/bindings/arm/cpus.txt +++
b/Documentation/devicetree/bindings/arm/cpus.txt @@ -185,6 +185,8 @@
nodes
to be present and contain the properties described below.
"qcom,gcc-msm8660"
  "qcom,kpss-acc-v1"
  "qcom,kpss-acc-v2"
+"marvell,88de31-smp" - cpu-core handling for


why not "marvell,berlin-smp"?


We have SMP on the BG2 and the BG2Q currently. Future boards may not be
compatible with this method (BG3 ?), I think "marvell,berlin-smp" is too
generic.

We could use "marvell,88de31xx-smp" as Alexandre suggested.


"marvell,88de31xx-smp" is not a good choice too, since futur SoC may 
match the "xx" and not use this method. A better way should be to use 
the first SoC implementing the feature, so "marvell,88de3100".


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: [RFC PATCH] cmdline: Hide "debug" from /proc/cmdline

[Borislav Petkov]

On Wed, Apr 02, 2014 at 06:47:57PM -0700, Linus Torvalds wrote:
> Borislav?

We're trying to reproduce the original issue with the assertion firing
and drowning dmesg but it is a huuge box and a bit flaky so it'll take
some time.

I'll let you know as soon as I have something.

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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/