Re: [BISECTED] Xen HVM guest hangs since 3.12-rc5

[Steven Noonan]

On Fri, Feb 21, 2014 at 12:07 PM, Konrad Rzeszutek Wilk
 wrote:
> On Thu, Feb 20, 2014 at 12:44:15PM -0800, Steven Noonan wrote:
>> On Wed, Feb 19, 2014 at 1:01 PM, Steven Noonan  wrote:
>> > On Wed, Feb 19, 2014 at 9:41 AM, Konrad Rzeszutek Wilk
>> >  wrote:
>> >> On Tue, Feb 18, 2014 at 11:16:05PM -0800, Steven Noonan wrote:
>> >>> I've been running into problems on an Xen HVM domU. I've got a guest 
>> >>> with NUMA
>> >>> enabled, 60GB of RAM, and 3 disks attached (including root volume). 2 of 
>> >>> the
>> >>> disks are in an MD RAID0 in the guest, with an ext4 filesystem on top of 
>> >>> that.
>> >>> I was running the fio 'iometer-file-access-server.fio' example config 
>> >>> against
>> >>> that fs. During this workload, it would eventually cause a soft lockup, 
>> >>> like
>> >>> the below:
>> >>
>> >> I presume since you mention NUMA and Mel is CC-ed that if you boot without
>> >> NUMA enabled (either via the toolstack or via Linux command line) - the 
>> >> issue
>> >> is not present?
>> >
>> > I mentioned NUMA because the bisected commit is sched/numa, and the
>> > guest is NUMA-enabled. I hadn't attempted booting with NUMA off. I
>> > just tried with numa=off, and the workload has run in a loop for 20
>> > minutes so far with no issues (normally the issue would repro in less
>> > than 5).
>>
>> The subject line is actually incorrect -- I did a 'git describe' on
>> the result of the bisection when writing the subject line, but the
>> '3.12-rc5' tag was just the base on which the code was originally
>> developed. As far as what tags actually contain the commit:
>>
>> $ git tag --contains b795854b1fa70f6aee923ae5df74ff7afeaddcaa
>> v3.13
>> v3.13-rc1
>> v3.13-rc2
>> v3.13-rc3
>> v3.13-rc4
>> v3.13-rc5
>> v3.13-rc6
>> v3.13-rc7
>> v3.13-rc8
>> v3.13.1
>> v3.13.2
>> v3.13.3
>> v3.14-rc1
>> v3.14-rc2
>>
>> So it's more accurate to say it was introduced in the v3.13 merge window.
>>
>> In any case, does anyone have any ideas?
>
> There is nothing in that git commit that gives that 'AHA' feeling.
>
> If you revert that patch on top of the latest Linux kernel does the problem
> go away? This is more of a double-check to see if the commit
> is really the fault or if it exposed some latent issue.

I just tried out 3.13.5 and the problem went away. Looking through the
commit logs, it appears this commit (added as part of 3.13.4) resolved
the issue:

commit 27b4328e523b3de854229e6b505f94aa9708dde6
Author: KOSAKI Motohiro 
Date:   Thu Feb 6 12:04:24 2014 -0800

mm: __set_page_dirty_nobuffers() uses spin_lock_irqsave() instead
of spin_lock_irq()

commit a85d9df1ea1d23682a0ed1e100e6965006595d06 upstream.

During aio stress test, we observed the following lockdep warning.  This
mean AIO+numa_balancing is currently deadlockable.

The problem is, aio_migratepage disable interrupt, but
__set_page_dirty_nobuffers unintentionally enable it again.

Generally, all helper function should use spin_lock_irqsave() instead of
spin_lock_irq() because they don't know caller at all.

   other info that might help us debug this:
Possible unsafe locking scenario:

  CPU0
  
 lock(&(>completion_lock)->rlock);
 
   lock(&(>completion_lock)->rlock);

*** DEADLOCK ***

  dump_stack+0x19/0x1b
  print_usage_bug+0x1f7/0x208
  mark_lock+0x21d/0x2a0
  mark_held_locks+0xb9/0x140
  trace_hardirqs_on_caller+0x105/0x1d0
  trace_hardirqs_on+0xd/0x10
  _raw_spin_unlock_irq+0x2c/0x50
  __set_page_dirty_nobuffers+0x8c/0xf0
  migrate_page_copy+0x434/0x540
  aio_migratepage+0xb1/0x140
  move_to_new_page+0x7d/0x230
  migrate_pages+0x5e5/0x700
  migrate_misplaced_page+0xbc/0xf0
  do_numa_page+0x102/0x190
  handle_pte_fault+0x241/0x970
  handle_mm_fault+0x265/0x370
  __do_page_fault+0x172/0x5a0
  do_page_fault+0x1a/0x70
  page_fault+0x28/0x30

Signed-off-by: KOSAKI Motohiro 
Cc: Larry Woodman 
Cc: Rik van Riel 
Cc: Johannes Weiner 
Acked-by: David Rientjes 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 

>>
>> >>>
>> >>> [ 2536.250054] BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u257:0:7]
>> >>> [ 2536.250054] Modules linked in: isofs crct10dif_pclmul 
>> >>> crct10dif_common crc32_pclmul crc32c_intel ghash_clmulni_intel 
>> >>> aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd raid0 
>> >>> md_mod acpi_cpufreq psmouse i2c_piix4 intel_agp intel_gtt i2c_core 
>> >>> processor serio_raw evdev microcode ext4 crc16 mbcache jbd2 ata_generic 
>> >>> pata_acpi ata_piix libata scsi_mod floppy ixgbevf xen_privcmd 
>> >>> xen_netfront xen_kbdfront syscopyarea sysfillrect sysimgblt fb_sys_fops 
>> >>> xen_blkfront virtio_pci virtio_net virtio_blk virtio_ring virtio 
>> >>> ipmi_poweroff ipmi_msghandler 

Re: Update of file offset on write() etc. is non-atomic with I/O

[Michael Kerrisk (man-pages)]

On Sun, Feb 23, 2014 at 2:18 AM, Kevin Easton  wrote:
> On Fri, Feb 21, 2014 at 07:01:31AM +0100, Michael Kerrisk (man-pages) wrote:
>> Here's the fulll list from POSIX.1-2008/SUSv4 Section XSI 2.9.7:
>>
>> [[
>> 2.9.7 Thread Interactions with Regular File Operations
>>
>> All of the following functions shall be atomic with respect to each
>> other in the effects specified in
>> POSIX.1-2008 when they operate on regular files or symbolic links:
>>
>> chmod( )
>> chown( )
>> close( )
>> creat( )
>> dup2( )
>> fchmod( )
>> fchmodat( )
>> fchown( )
>> fchownat( )
>> fcntl( )
>> fstat( )
>> fstatat( )
>> ftruncate( )
>> lchown( )
>> link( )
>> linkat( )
>> lseek( )
>> lstat( )
>> open( )
>> openat( )
>> pread( )
>> read( )
>> readlink( )
>> readlinkat( )
>> readv( )
>> pwrite( )
>> rename( )
>> renameat( )
>> stat( )
>> symlink( )
>> symlinkat( )
>> truncate( )
>> unlink( )
>> unlinkat( )
>> utime( )
>> utimensat( )
>> utimes( )
>> write( )
>> writev( )
>>
>> If two threads each call one of these functions, each call shall
>> either see all of the specified effects
>> of the other call, or none of them.
>> ]]
>>
>> I'd bet that there's a bunch of violations to be found, but the
>> read/write f_pos case is one of the most egregious.
>>
>> For example, I got curious about stat() versus rename(). If one
>> stat()s a directory() while a subdirectory is being renamed to a new
>> name within that directory, does the link count of the parent
>> directory ever change--that is, could stat() ever see a changed link
>> count in the middle of the rename()? My experiments suggest that it
>> can. I suppose it would have to be a very unusual application that
>> would be troubled by that, but it does appear to be a violation of
>> 2.9.7.
>
> A directory isn't a regular file or symlink, though, so the warranty
> would seem to be void in that case.

Oops -- yes, of course.

> If you {f}stat() a regular file that is being concurrently renamed() then
> the link count shouldn't vary, though.

Yes. (I haven't tested that though.)

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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 0/2] regulator: core: Fix ops->enable/disable usage

[Mark Brown]

On Thu, Feb 20, 2014 at 05:36:02PM +0100, Markus Pargmann wrote:
> Hi,
> 
> These two patches replace all ops->enable/disable by
> _regulator_do_disable/enable function calls. These wrappers also handle gpio
> regulators.

Applied both, thanks.


signature.asc
Description: Digital signature

Re: [PATCH v3 0/3] Add TDM slot info OF parsing supports

[Mark Brown]

On Fri, Feb 14, 2014 at 09:34:33AM +0800, Xiubo Li wrote:
> Change in v3:
>- Add .of_xlate_tdm_slot_mask().
>- Add snd_soc_of_xlate_tdm_slot_mask().
>- Remove TDM slot masks OF parsing...
>- Split the TDM infomation into two properties.

Applied all, thanks - this is a really nice, clear binding though I
think we will need to extend it in future to support specifying which
slots are in use by a given device.


signature.asc
Description: Digital signature

Re: [PATCH] pfuze100-regulator: Return error on of_node_get() failure

[Mark Brown]

On Thu, Feb 20, 2014 at 01:47:02PM -0300, Fabio Estevam wrote:
> If of_node_get() fails, we should return an error.

Applied, thanks.


signature.asc
Description: Digital signature

[PATCH v2 1/2] IB/mthca: Use pci_enable_msix_exact() instead of pci_enable_msix()

[Alexander Gordeev]

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.

Signed-off-by: Alexander Gordeev 
Cc: Roland Dreier 
Cc: Sean Hefty 
Cc: Hal Rosenstock 
Cc: linux-r...@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
 drivers/infiniband/hw/mthca/mthca_main.c |8 ++--
 1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/infiniband/hw/mthca/mthca_main.c 
b/drivers/infiniband/hw/mthca/mthca_main.c
index 87897b9..ded76c1 100644
--- a/drivers/infiniband/hw/mthca/mthca_main.c
+++ b/drivers/infiniband/hw/mthca/mthca_main.c
@@ -858,13 +858,9 @@ static int mthca_enable_msi_x(struct mthca_dev *mdev)
entries[1].entry = 1;
entries[2].entry = 2;
 
-   err = pci_enable_msix(mdev->pdev, entries, ARRAY_SIZE(entries));
-   if (err) {
-   if (err > 0)
-   mthca_info(mdev, "Only %d MSI-X vectors available, "
-  "not using MSI-X\n", err);
+   err = pci_enable_msix_exact(mdev->pdev, entries, ARRAY_SIZE(entries));
+   if (err)
return err;
-   }
 
mdev->eq_table.eq[MTHCA_EQ_COMP ].msi_x_vector = entries[0].vector;
mdev->eq_table.eq[MTHCA_EQ_ASYNC].msi_x_vector = entries[1].vector;
-- 
1.7.7.6

-- 
Regards,
Alexander Gordeev
agord...@redhat.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/

[PATCH v2] vmw_vmci: Use pci_enable_msix_exact() instead of pci_enable_msix()

[Alexander Gordeev]

As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range()  or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.

Signed-off-by: Alexander Gordeev 
Cc: Greg Kroah-Hartman 
Cc: Andy King 
Cc: Dmitry Torokhov 
Cc: linux-...@vger.kernel.org
---
 drivers/misc/vmw_vmci/vmci_guest.c |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/misc/vmw_vmci/vmci_guest.c 
b/drivers/misc/vmw_vmci/vmci_guest.c
index d35cda0..e0d5017 100644
--- a/drivers/misc/vmw_vmci/vmci_guest.c
+++ b/drivers/misc/vmw_vmci/vmci_guest.c
@@ -383,11 +383,12 @@ static int vmci_enable_msix(struct pci_dev *pdev,
vmci_dev->msix_entries[i].vector = i;
}
 
-   result = pci_enable_msix(pdev, vmci_dev->msix_entries, VMCI_MAX_INTRS);
+   result = pci_enable_msix_exact(pdev,
+  vmci_dev->msix_entries, VMCI_MAX_INTRS);
if (result == 0)
vmci_dev->exclusive_vectors = true;
-   else if (result > 0)
-   result = pci_enable_msix(pdev, vmci_dev->msix_entries, 1);
+   else if (result == -ENOSPC)
+   result = pci_enable_msix_exact(pdev, vmci_dev->msix_entries, 1);
 
return result;
 }
-- 
1.7.7.6

-- 
Regards,
Alexander Gordeev
agord...@redhat.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 0/5] arch: atomic rework

[Paul E. McKenney]

On Sat, Feb 22, 2014 at 07:50:35PM -0800, Linus Torvalds wrote:
> On Sat, Feb 22, 2014 at 4:39 PM, Paul E. McKenney
>  wrote:
> >
> > Agreed, by far the most frequent use is "->" to dereference and assignment
> > to store into a local variable.  The other operations where the kernel
> > expects ordering to be maintained are:
> >
> > o   Bitwise "&" to strip off low-order bits.  The FIB tree does
> > this, for example in fib_table_lookup() in net/ipv4/fib_trie.c.
> > The low-order bit is used to distinguish internal nodes from
> > leaves -- nodes and leaves are different types of structures.
> > (There are a few others.)
> 
> Note that this is very much outside the scope of the C standard,
> regardless of 'consume' or not.
> 
> We'll always do things outside the standard, so I wouldn't worry.

Fair enough.  I am going to make examples to try to make sure that we
aren't using the same words for two different meanings:

struct foo restrict *p;

p = atomic_load_explicit(, memory_order_consume);
p &= ~0x3;  /* OK because p has restrict property. */
return p->a;/* Ordered WRT above load. */

Of course, the compiler would have to work pretty hard to break this
ordering, so I am with you in not worrying too much about this one.

> > o   Uses "?:" to substitute defaults in case of NULL pointers,
> > but ordering must be maintained in the non-default case.
> > Most, perhaps all, of these could be converted to "if" should
> > "?:" prove problematic.
> 
> Note that this doesn't actually affect the restrict/ordering rule in
> theory: "?:" isn't special according to those rules. The rules are
> fairly simple: we guarantee ordering only to the object that the
> pointer points to, and even that guarantee goes out the window if
> there is some *other* way to reach the object.
> 
> ?: is not really relevant, except in the sense that *any* expression
> that ends up pointing to outside the object will lose the ordering
> guarantee. ?: can be one such expression, but so can "p-p" or anything
> like that.
> 
> And in *practice*, the only thing that needs to be sure to generate
> special code is alpha, and there you'd just add the "rmb" after the
> load. That is sufficient to fulfill the guarantees.

OK, seems reasonable.  Reworking the earlier example:

struct foo restrict *p;

p = atomic_load_explicit(, memory_order_consume);
p = p ? p : _foo;
return p->a;/* Ordered WRT above load if p non-NULL. */

And the ordering makes sense only in the non-NULL case anyway,
so this should be fine.

> On ARM and powerpc, the compiler obviously has to guarantee that it
> doesn't do value-speculation on the result, but again, that never
> really had anything to do with the whole "carries a dependency", it is
> really all about the fact that in order to guarantee the ordering, the
> compiler mustn't generate that magical aliased pointer value. But if
> the aliased pointer value comes from the *source* code, all bets are
> off.

Agreed, compiler-based value speculation is dangerous in any case.
(Though the branch-predictor-based trick seems like it should be safe
on TSO systems like x86, s390, etc.)

> Now, even on alpha, the compiler can obviously move that "rmb" around.
> For example, if there is a conditional after the
> "atomic_read(mo_consume)", and the compiler can tell that the pointer
> that got read by mo_consume is dead along one branch, then the
> compiler can move the "rmb" to only exist in the other branch. Why?
> Because we inherently guarantee only the order to any accesses to the
> object the pointer pointed to, and that the pointer that got loaded is
> the *only* way to get to that object (in this context), so if the
> value is dead, then so is the ordering.

Yep!

> In fact, even if the value is *not* dead, but it is NULL, the compiler
> can validly say "the NULL pointer cannot point to any object, so I
> don't have to guarantee any serialization". So code like this (writing
> alpha assembly, since in practice only alpha will ever care):
> 
> ptr = atomic_read(pp, mo_consume);
> if (ptr) {
>... do something with ptr ..
> }
> return ptr;
> 
> can validly be translated to:
> 
> ldq $1,0($2)
> beq $1,branch-over
> rmb
> .. the do-something code using register $1 ..
> 
> because the compiler knows that a NULL pointer cannot be dereferenced,
> so it can decide to put the rmb in the non-NULL path - even though the
> pointer value is still *live* in the other branch (well, the liveness
> of a constant value is somewhat debatable, but you get the idea), and
> may be used by the caller (but since it is NULL, the "use" can not
> include accessing any object, only really testing)

Agreed.

> So note how this is actually very different from the "carries
> dependency" rule. It's simpler, and it allows much more natural
> optimizations.

I do have a couple more 

Re: [PATCH 1/1] Add device id for Thrustmaster GPX Gamepad for joystick/xpad.c driver

[Dmitry Torokhov]

On Fri, Feb 21, 2014 at 11:51:21PM +0100, Marcin Lulek wrote:
> Signed-off-by: Marcin Lulek 
> ---
>  drivers/input/joystick/xpad.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> index 603fe0d..b94668f 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c
> @@ -124,6 +124,7 @@ static const struct xpad_device {
>   { 0x045e, 0x0291, "Xbox 360 Wireless Receiver (XBOX)", 
> MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360W },
>   { 0x045e, 0x0719, "Xbox 360 Wireless Receiver", MAP_DPAD_TO_BUTTONS, 
> XTYPE_XBOX360W },
>   { 0x044f, 0x0f07, "Thrustmaster, Inc. Controller", 0, XTYPE_XBOX },
> + { 0x24c6, 0x5b02, "Thrustmaster, Inc. GPX Controller", 0, XTYPE_XBOX360 
> },
>   { 0x046d, 0xc21d, "Logitech Gamepad F310", 0, XTYPE_XBOX360 },
>   { 0x046d, 0xc21f, "Logitech Gamepad F710", 0, XTYPE_XBOX360 },
>   { 0x046d, 0xc242, "Logitech Chillstream Controller", 0, XTYPE_XBOX360 },
> -- 
> 1.8.3.2
> 

Applied, thank you.

-- 
Dmitry
--
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 v5 2/3] x86, mpx: hook #BR exception handler to allocate bound tables

[Qiaowei Ren]

An access to an invalid bound directory entry will cause a #BR
exception. This patch hook #BR exception handler to allocate
one bound table and bind it with that buond directory entry.

This will avoid the need of forwarding the #BR exception
to the user space when bound directory has invalid entry.

Signed-off-by: Qiaowei Ren 
---
 arch/x86/include/asm/mpx.h |   35 +++
 arch/x86/kernel/Makefile   |1 +
 arch/x86/kernel/mpx.c  |   46 
 arch/x86/kernel/traps.c|   56 +++-
 4 files changed, 137 insertions(+), 1 deletions(-)
 create mode 100644 arch/x86/include/asm/mpx.h
 create mode 100644 arch/x86/kernel/mpx.c

diff --git a/arch/x86/include/asm/mpx.h b/arch/x86/include/asm/mpx.h
new file mode 100644
index 000..d9a61a8
--- /dev/null
+++ b/arch/x86/include/asm/mpx.h
@@ -0,0 +1,35 @@
+#ifndef _ASM_X86_MPX_H
+#define _ASM_X86_MPX_H
+
+#include 
+#include 
+
+#ifdef CONFIG_X86_64
+
+#define MPX_L1_BITS28
+#define MPX_L1_SHIFT   3
+#define MPX_L2_BITS17
+#define MPX_L2_SHIFT   5
+#define MPX_IGN_BITS   3
+#define MPX_L2_NODE_ADDR_MASK  0xfff8UL
+
+#define MPX_BNDSTA_ADDR_MASK   0xfffcUL
+#define MPX_BNDCFG_ADDR_MASK   0xf000UL
+
+#else
+
+#define MPX_L1_BITS20
+#define MPX_L1_SHIFT   2
+#define MPX_L2_BITS10
+#define MPX_L2_SHIFT   4
+#define MPX_IGN_BITS   2
+#define MPX_L2_NODE_ADDR_MASK  0xfffcUL
+
+#define MPX_BNDSTA_ADDR_MASK   0xfffcUL
+#define MPX_BNDCFG_ADDR_MASK   0xf000UL
+
+#endif
+
+bool do_mpx_bt_fault(struct xsave_struct *xsave_buf);
+
+#endif /* _ASM_X86_MPX_H */
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index cb648c8..becb970 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_PREEMPT) += preempt.o
 
 obj-y  += process.o
 obj-y  += i387.o xsave.o
+obj-y  += mpx.o
 obj-y  += ptrace.o
 obj-$(CONFIG_X86_32)   += tls.o
 obj-$(CONFIG_IA32_EMULATION)   += tls.o
diff --git a/arch/x86/kernel/mpx.c b/arch/x86/kernel/mpx.c
new file mode 100644
index 000..f1a16c0
--- /dev/null
+++ b/arch/x86/kernel/mpx.c
@@ -0,0 +1,46 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static bool allocate_bt(unsigned long bd_entry)
+{
+   unsigned long bt_size = 1UL << (MPX_L2_BITS+MPX_L2_SHIFT);
+   unsigned long bt_addr, old_val = 0;
+
+   bt_addr = sys_mmap_pgoff(0, bt_size, PROT_READ | PROT_WRITE,
+   MAP_ANONYMOUS | MAP_PRIVATE | MAP_POPULATE, -1, 0);
+   if (bt_addr == -1) {
+   pr_err("L2 Node Allocation Failed at L1 addr %lx\n",
+   bd_entry);
+   return false;
+   }
+   bt_addr = (bt_addr & MPX_L2_NODE_ADDR_MASK) | 0x01;
+
+   user_atomic_cmpxchg_inatomic(_val,
+   (long __user *)bd_entry, 0, bt_addr);
+   if (old_val)
+   vm_munmap(bt_addr & MPX_L2_NODE_ADDR_MASK, bt_size);
+
+   return true;
+}
+
+bool do_mpx_bt_fault(struct xsave_struct *xsave_buf)
+{
+   unsigned long status;
+   unsigned long bd_entry, bd_base;
+   unsigned long bd_size = 1UL << (MPX_L1_BITS+MPX_L1_SHIFT);
+
+   bd_base = xsave_buf->bndcsr.cfg_reg_u & MPX_BNDCFG_ADDR_MASK;
+   status = xsave_buf->bndcsr.status_reg;
+
+   bd_entry = status & MPX_BNDSTA_ADDR_MASK;
+   if ((bd_entry >= bd_base) && (bd_entry < bd_base + bd_size))
+   return allocate_bt(bd_entry);
+
+   return false;
+}
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 57409f6..b894f09 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -59,6 +59,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_X86_64
 #include 
@@ -213,7 +214,6 @@ dotraplinkage void do_##name(struct pt_regs *regs, long 
error_code) \
 
 DO_ERROR_INFO(X86_TRAP_DE, SIGFPE,  "divide error",
divide_error,FPE_INTDIV, regs->ip )
 DO_ERROR (X86_TRAP_OF, SIGSEGV, "overflow",
overflow  )
-DO_ERROR (X86_TRAP_BR, SIGSEGV, "bounds",  bounds  
  )
 DO_ERROR_INFO(X86_TRAP_UD, SIGILL,  "invalid opcode",  
invalid_op,  ILL_ILLOPN, regs->ip )
 DO_ERROR (X86_TRAP_OLD_MF, SIGFPE,  "coprocessor segment overrun", 
coprocessor_segment_overrun   )
 DO_ERROR (X86_TRAP_TS, SIGSEGV, "invalid TSS", 
invalid_TSS   )
@@ -263,6 +263,60 @@ dotraplinkage void do_double_fault(struct pt_regs *regs, 
long error_code)
 }
 #endif
 
+dotraplinkage void do_bounds(struct pt_regs *regs, long error_code)
+{
+   enum ctx_state 

[PATCH v5 3/3] x86, mpx: extend siginfo structure to include bound violation information

[Qiaowei Ren]

This patch adds new fields about bound violation into siginfo
structure. si_lower and si_upper are respectively lower bound
and upper bound when bound violation is caused.

These fields will be set in #BR exception handler by decoding
the user instruction and constructing the faulting pointer.
A userspace application can get violation address, lower bound
and upper bound for bound violation from this new siginfo structure.

Signed-off-by: Qiaowei Ren 
---
 arch/x86/include/asm/mpx.h |   19 +++
 arch/x86/kernel/mpx.c  |  289 
 arch/x86/kernel/traps.c|6 +
 include/uapi/asm-generic/siginfo.h |9 +-
 kernel/signal.c|4 +
 5 files changed, 326 insertions(+), 1 deletions(-)

diff --git a/arch/x86/include/asm/mpx.h b/arch/x86/include/asm/mpx.h
index d9a61a8..3296052 100644
--- a/arch/x86/include/asm/mpx.h
+++ b/arch/x86/include/asm/mpx.h
@@ -3,6 +3,7 @@
 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_X86_64
 
@@ -30,6 +31,24 @@
 
 #endif
 
+struct mpx_insn {
+   struct insn_field rex_prefix;   /* REX prefix */
+   struct insn_field modrm;
+   struct insn_field sib;
+   struct insn_field displacement;
+
+   unsigned char addr_bytes;   /* effective address size */
+   unsigned char limit;
+   unsigned char x86_64;
+
+   const unsigned char *kaddr; /* kernel address of insn to analyze */
+   const unsigned char *next_byte;
+};
+
+#define MAX_MPX_INSN_SIZE  15
+
 bool do_mpx_bt_fault(struct xsave_struct *xsave_buf);
+void do_mpx_bounds(struct pt_regs *regs, siginfo_t *info,
+   struct xsave_struct *xsave_buf);
 
 #endif /* _ASM_X86_MPX_H */
diff --git a/arch/x86/kernel/mpx.c b/arch/x86/kernel/mpx.c
index f1a16c0..7c0e36c 100644
--- a/arch/x86/kernel/mpx.c
+++ b/arch/x86/kernel/mpx.c
@@ -7,6 +7,270 @@
 #include 
 #include 
 
+typedef enum {REG_TYPE_RM, REG_TYPE_INDEX, REG_TYPE_BASE} reg_type_t;
+static unsigned long get_reg(struct mpx_insn *insn, struct pt_regs *regs,
+reg_type_t type)
+{
+   int regno = 0;
+   unsigned char modrm = (unsigned char)insn->modrm.value;
+   unsigned char sib = (unsigned char)insn->sib.value;
+
+   static const int regoff[] = {
+   offsetof(struct pt_regs, ax),
+   offsetof(struct pt_regs, cx),
+   offsetof(struct pt_regs, dx),
+   offsetof(struct pt_regs, bx),
+   offsetof(struct pt_regs, sp),
+   offsetof(struct pt_regs, bp),
+   offsetof(struct pt_regs, si),
+   offsetof(struct pt_regs, di),
+#ifdef CONFIG_X86_64
+   offsetof(struct pt_regs, r8),
+   offsetof(struct pt_regs, r9),
+   offsetof(struct pt_regs, r10),
+   offsetof(struct pt_regs, r11),
+   offsetof(struct pt_regs, r12),
+   offsetof(struct pt_regs, r13),
+   offsetof(struct pt_regs, r14),
+   offsetof(struct pt_regs, r15),
+#endif
+   };
+
+   switch (type) {
+   case REG_TYPE_RM:
+   regno = X86_MODRM_RM(modrm);
+   if (X86_REX_B(insn->rex_prefix.value) == 1)
+   regno += 8;
+   break;
+
+   case REG_TYPE_INDEX:
+   regno = X86_SIB_INDEX(sib);
+   if (X86_REX_X(insn->rex_prefix.value) == 1)
+   regno += 8;
+   break;
+
+   case REG_TYPE_BASE:
+   regno = X86_SIB_BASE(sib);
+   if (X86_REX_B(insn->rex_prefix.value) == 1)
+   regno += 8;
+   break;
+
+   default:
+   break;
+   }
+
+   return regs_get_register(regs, regoff[regno]);
+}
+
+/*
+ * return the address being referenced be instruction
+ * for rm=3 returning the content of the rm reg
+ * for rm!=3 calculates the address using SIB and Disp
+ */
+static unsigned long get_addr_ref(struct mpx_insn *insn, struct pt_regs *regs)
+{
+   unsigned long addr;
+   unsigned long base;
+   unsigned long indx;
+   unsigned char modrm = (unsigned char)insn->modrm.value;
+   unsigned char sib = (unsigned char)insn->sib.value;
+
+   if (X86_MODRM_MOD(modrm) == 3) {
+   addr = get_reg(insn, regs, REG_TYPE_RM);
+   } else {
+   if (insn->sib.nbytes) {
+   base = get_reg(insn, regs, REG_TYPE_BASE);
+   indx = get_reg(insn, regs, REG_TYPE_INDEX);
+   addr = base + indx * (1 << X86_SIB_SCALE(sib));
+   } else {
+   addr = get_reg(insn, regs, REG_TYPE_RM);
+   }
+   addr += insn->displacement.value;
+   }
+
+   return addr;
+}
+
+/* Verify next sizeof(t) bytes can be on the same instruction */
+#define validate_next(t, insn, n)  \
+   ((insn)->next_byte + sizeof(t) + n - (insn)->kaddr <= (insn)->limit)
+

[PATCH v5 1/3] x86, mpx: add documentation on Intel MPX

[Qiaowei Ren]

This patch adds the Documentation/x86/intel_mpx.txt file with some
information about Intel MPX.

Signed-off-by: Qiaowei Ren 
---
 Documentation/x86/intel_mpx.txt |  239 +++
 1 files changed, 239 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/x86/intel_mpx.txt

diff --git a/Documentation/x86/intel_mpx.txt b/Documentation/x86/intel_mpx.txt
new file mode 100644
index 000..9af8636
--- /dev/null
+++ b/Documentation/x86/intel_mpx.txt
@@ -0,0 +1,239 @@
+1. Intel(R) MPX Overview
+
+
+
+Intel(R) Memory Protection Extensions (Intel(R) MPX) is a new
+capability introduced into Intel Architecture. Intel MPX provides
+hardware features that can be used in conjunction with compiler
+changes to check memory references, for those references whose
+compile-time normal intentions are usurped at runtime due to
+buffer overflow or underflow.
+
+Two of the most important goals of Intel MPX are to provide
+this capability at very low performance overhead for newly
+compiled code, and to provide compatibility mechanisms with
+legacy software components. MPX architecture is designed to
+allow a machine (i.e., the processor(s) and the OS software)
+to run both MPX enabled software and legacy software that
+is MPX unaware. In such a case, the legacy software does not
+benefit from MPX, but it also does not experience any change
+in functionality or reduction in performance.
+
+Intel(R) MPX Programming Model
+--
+
+Intel MPX introduces new registers and new instructions that
+operate on these registers. Some of the registers added are
+bounds registers which store a pointer's lower bound and upper
+bound limits. Whenever the pointer is used, the requested
+reference is checked against the pointer's associated bounds,
+thereby preventing out-of-bound memory access (such as buffer
+overflows and overruns). Out-of-bounds memory references
+initiate a #BR exception which can then be handled in an
+appropriate manner.
+
+Loading and Storing Bounds using Translation
+
+
+Intel MPX defines two instructions for load/store of the linear
+address of a pointer to a buffer, along with the bounds of the
+buffer into a paging structure of extended bounds. Specifically
+when storing extended bounds, the processor will perform address
+translation of the address where the pointer is stored to an
+address in the Bound Table (BT) to determine the store location
+of extended bounds. Loading of an extended bounds performs the
+reverse sequence.
+
+The structure in memory to load/store an extended bound is a
+4-tuple consisting of lower bound, upper bound, pointer value
+and a reserved field. Bound loads and stores access 32-bit or
+64-bit operand size according to the operation mode. Thus,
+a bound table entry is 4*32 bits in 32-bit mode and 4*64 bits
+in 64-bit mode.
+
+The linear address of a bound table is stored in a Bound
+Directory (BD) entry. The linear address of the bound
+directory is derived from either BNDCFGU or BNDCFGS registers.
+Bounds in memory are stored in Bound Tables (BT) as an extended
+bound, which are accessed via Bound Directory (BD) and address
+translation performed by BNDLDX/BNDSTX instructions.
+
+Bounds Directory (BD) and Bounds Tables (BT) are stored in
+application memory and are allocated by the application (in case
+of kernel use, the structures will be in kernel memory). The
+bound directory and each instance of bound table are in contiguous
+linear memory.
+
+XSAVE/XRESTOR Support of Intel MPX State
+
+
+Enabling Intel MPX requires an OS to manage two bits in XCR0:
+  - BNDREGS for saving and restoring registers BND0-BND3,
+  - BNDCSR for saving and restoring the user-mode configuration
+(BNDCFGU) and the status register (BNDSTATUS).
+
+The reason for having two separate bits is that BND0-BND3 are
+likely to be volatile state, while BNDCFGU and BNDSTATUS are not.
+Therefore, an OS has flexibility in handling these two states
+differently in saving or restoring them.
+
+For details about the Intel MPX instructions, see "Intel(R)
+Architecture Instruction Set Extensions Programming Reference".
+
+
+2. How to get the advantage of MPX
+==
+
+
+To get the advantage of MPX, changes are required in
+the OS kernel, binutils, compiler, and system libraries support.
+
+MPX support in the GNU toolchain
+
+
+This section describes changes in GNU Binutils, GCC and Glibc
+to support MPX.
+
+The first step of MPX support is to implement support for new
+hardware features in binutils and the GCC.
+
+The second step is implementation of MPX instrumentation pass
+in the GCC compiler which is responsible for instrumenting all
+memory accesses with pointer checks. Compiler changes for runtime
+bound checks include:
+
+  * Bounds creation for statically allocated objects, objects
+

[PATCH v5 0/3] Intel MPX support

[Qiaowei Ren]

This patchset adds support for the Memory Protection Extensions
(MPX) feature found in future Intel processors.

MPX can be used in conjunction with compiler changes to check memory
references, for those references whose compile-time normal intentions
are usurped at runtime due to buffer overflow or underflow.

MPX provides this capability at very low performance overhead for
newly compiled code, and provides compatibility mechanisms with legacy
software components. MPX architecture is designed allow a machine to
run both MPX enabled software and legacy software that is MPX unaware.
In such a case, the legacy software does not benefit from MPX, but it
also does not experience any change in functionality or reduction in
performance.

More information about Intel MPX can be found in "Intel(R) Architecture
Instruction Set Extensions Programming Reference".

To get the advantage of MPX, changes are required in the OS kernel,
binutils, compiler, system libraries support.

New GCC option -fmpx is introduced to utilize MPX instructions.
Currently GCC compiler sources with MPX support is available in a
separate branch in common GCC SVN repository. See GCC SVN page
(http://gcc.gnu.org/svn.html) for details.

To have the full protection, we had to add MPX instrumentation to all
the necessary Glibc routines (e.g. memcpy) written on assembler, and
compile Glibc with the MPX enabled GCC compiler. Currently MPX enabled
Glibc source can be found in Glibc git repository.

Enabling an application to use MPX will generally not require source
code updates but there is some runtime code, which is responsible for
configuring and enabling MPX, needed in order to make use of MPX.
For most applications this runtime support will be available by linking
to a library supplied by the compiler or possibly it will come directly
from the OS once OS versions that support MPX are available.

MPX kernel code, namely this patchset, has mainly the 2 responsibilities:
provide handlers for bounds faults (#BR), and manage bounds memory.

Currently no hardware with MPX ISA is available but it is always
possible to use SDE (Intel(R) software Development Emulator) instead,
which can be downloaded from
http://software.intel.com/en-us/articles/intel-software-development-emulator


Changes since v1:
  * check to see if #BR occurred in userspace or kernel space.
  * use generic structure and macro as much as possible when
decode mpx instructions.

Changes since v2:
  * fix some compile warnings.
  * update documentation.

Changes since v3:
  * correct some syntax errors at documentation, and document
extended struct siginfo.
  * for kill the process when the error code of BNDSTATUS is 3.
  * add some comments.
  * remove new prctl() commands.
  * fix some compile warnings for 32-bit.

Changes since v4:
  * raise SIGBUS if the allocations of the bound tables fail.

Qiaowei Ren (3):
  x86, mpx: add documentation on Intel MPX
  x86, mpx: hook #BR exception handler to allocate bound tables
  x86, mpx: extend siginfo structure to include bound violation
information

 Documentation/x86/intel_mpx.txt|  239 +
 arch/x86/include/asm/mpx.h |   54 ++
 arch/x86/kernel/Makefile   |1 +
 arch/x86/kernel/mpx.c  |  335 
 arch/x86/kernel/traps.c|   62 +++-
 include/uapi/asm-generic/siginfo.h |9 +-
 kernel/signal.c|4 +
 7 files changed, 702 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/x86/intel_mpx.txt
 create mode 100644 arch/x86/include/asm/mpx.h
 create mode 100644 arch/x86/kernel/mpx.c

--
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: It BOOTS! 3.13.5 that is.

[Mike Galbraith]

On Sun, 2014-02-23 at 00:18 -0500, Gene Heskett wrote: 
> On Saturday 22 February 2014, Ilia Mirkin wrote:

> Sorry, no such beast As VIDEO_CX88.
> 
> Now that tells me something in the VIDEO dept isn't set, but what?

Beast radar:
find drivers -name Kconfig -exec grep -C5 VIDEO_CX88 {} \;

Blip:
config VIDEO_CX88
tristate "Conexant 2388x (bt878 successor) support"
depends on VIDEO_DEV && PCI && I2C && RC_CORE  <=== IFF signature
select I2C_ALGOBIT
select VIDEO_BTCX
select VIDEOBUF_DMA_SG
--
  TV cards.

  To compile this driver as a module, choose M here: the
  module will be called cx8800

--
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: perf_fuzzer compiled for x32 causes reboot

[H. Peter Anvin]

I'd be interested in how rbp gets set, too.  It might just be a coincidence and 
the value in rbp has some other meaning here.

On February 22, 2014 9:18:17 PM PST, Vince Weaver  
wrote:
>On Fri, 21 Feb 2014, H. Peter Anvin wrote:
>
>> Error 6 reflects a write in userspace to a not-present page.
>> 
>> Since your previous trace indicates that the value of the register in
>question
>> is a different one, I'm guessing that what we have here is PEBS
>getting
>> activated.  0x120 is 2*0x90, and 0x90 is the size of a 64-bit PEBS
>record.
>
>I'm having problems generating a replayable syscall trace that exhibits
>
>the problem.
>
>It turns out that the segfault address listed (the multiple of 0x120) 
>happens to be the value in the RBP register at the time of the
>segfault.
>
>That's odd, as the instruction is
>   movdqa %xmm0,(%rdi)
>and rdi is the valid mmap address of the perf ring buffer
>   rdi0xf7768000   4151738368
>
>so I'm not sure why RBP is involved at all.
>
>In all of the cases I've investigated the precise_ip value has been set
>
>for the problem event... but none of the events have been hardware
>events
>(software and breakpoint so far).  So probably not PEBS related?
>
>Vince

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.
--
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: It BOOTS! 3.13.5 that is.

[Ilia Mirkin]

On Sun, Feb 23, 2014 at 12:18 AM, Gene Heskett  wrote:
> On Saturday 22 February 2014, Ilia Mirkin wrote:
>>On Sat, Feb 22, 2014 at 11:00 PM, Gene Heskett  wrote:
>>> On Saturday 22 February 2014, Ilia Mirkin wrote:
On Sat, Feb 22, 2014 at 10:42 PM, Gene Heskett 
> wrote:
> On Saturday 22 February 2014, Ilia Mirkin wrote:
>>On Sat, Feb 22, 2014 at 8:22 PM, Gene Heskett 
> wrote:
>>> But my tv card isn't being found by kaffeine.  It is this card:
>>>
>>> 01:08.0 Multimedia video controller: Conexant Systems, Inc.
>>> CX23880/1/2/3 PCI Video and Audio Decoder (rev 05)
>>>
>>> Subsystem: pcHDTV Device 3000
>>> Flags: bus master, medium devsel, latency 32, IRQ 10
>>> Memory at fb00 (32-bit, non-prefetchable) [size=16M]
>>> Capabilities: [44] Vital Product Data 
>>> Capabilities: [4c] Power Management version 2
>>>
>>> 01:08.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3
>>> PCI Video and Audio Decoder [MPEG Port] (rev 05)
>>>
>>> Subsystem: pcHDTV Device 3000
>>> Flags: bus master, medium devsel, latency 32, IRQ 10
>>> Memory at fa00 (32-bit, non-prefetchable) [size=16M]
>>> Capabilities: [4c] Power Management version 2
>>>
>>> From an lspci
>>>
>>> In a make xconfig, I cannot find this specific card in the list of
>>> DVB front ends.  What modules do I need to make sure are being
>>> built?
>>
>>You're looking for VIDEO_CX88 ("Conexant 2388x (bt878 successor)
>>support") and its various sub-options (esp CX88_DVB). iirc the
>>pchdtv3000 had a OR51132 tuner, but right now the config is set to
>>auto-select a whole bunch of tuners if you have
>>MEDIA_SUBDRV_AUTOSELECT turned on. Otherwise make sure to select that
>>tuner device. (Hm, I appear to have both OR51132 and CX22702 enabled,
>>and I have that same card.)
>>
>>  -ilia
>
> or51132 rings a bell and is enabled, CX22702 is not.  And I don't
> seem to be able to find the CX88** at all.  I'll give the CX22702 a
> shot, thanks a bunch ilia.

grep CX88 .config

>>> That returns a linefeed only.  And I have done some dozen or so make
>>> oldconfigs.
>>>
If it says "not set" for things like CONFIG_VIDEO_CX88_DVB, you won't
get anything to work.

  -ilia
>>>
>>> If this fails, I'll see if I can plug that in with an editor, but the
>>> last time I tried that, the friggin make did an automatic oldconfig
>>> and stripped it.  Its enough to make one want to reduce the
>>> neighborhood cat population.
>>
>>Adding random stuff to .config won't work, as you noticed.
>>
>>>From menuconfig search results for CX88 (ugh, sorry about the x's, but
>>I'm too lazy to edit them out)
>>
>>  x Symbol: VIDEO_CX88 [=m]
>>  x x Type  : tristate
>> x x Prompt: Conexant 2388x (bt878 successor) support
>>x x   Location:
>>   x x -> Device Drivers
>>  x x   -> Multimedia support (MEDIA_SUPPORT [=m])
>> x x (1) -> Media PCI Adapters (MEDIA_PCI_SUPPORT
>>[=y])  x x   Defined at drivers/media/pci/cx88/Kconfig:1
>>  x x   Depends on: MEDIA_SUPPORT [=m] &&
>>MEDIA_PCI_SUPPORT [=y] && (MEDIA_AN x x   Selects: I2C_ALGOBIT [=m] &&
>>VIDEO_BTCX [=m] && VIDEOBUF_DMA_SG [=m]  x
>>
>>HTH,
>>
>>  -ilia
>
> Sorry, no such beast As VIDEO_CX88.
>
> Now that tells me something in the VIDEO dept isn't set, but what?

Look at the e-mail I sent. It includes the full path to enabling the
right things. First select "Device Drivers", then enable "Multimedia
support", then enable "Media PCI Adapters". You should see "Conexant
2388x" in there.

  -ilia
--
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: perf_fuzzer compiled for x32 causes reboot

[H. Peter Anvin]

What is the instructions around it, by any chance?

On February 22, 2014 9:18:17 PM PST, Vince Weaver  
wrote:
>On Fri, 21 Feb 2014, H. Peter Anvin wrote:
>
>> Error 6 reflects a write in userspace to a not-present page.
>> 
>> Since your previous trace indicates that the value of the register in
>question
>> is a different one, I'm guessing that what we have here is PEBS
>getting
>> activated.  0x120 is 2*0x90, and 0x90 is the size of a 64-bit PEBS
>record.
>
>I'm having problems generating a replayable syscall trace that exhibits
>
>the problem.
>
>It turns out that the segfault address listed (the multiple of 0x120) 
>happens to be the value in the RBP register at the time of the
>segfault.
>
>That's odd, as the instruction is
>   movdqa %xmm0,(%rdi)
>and rdi is the valid mmap address of the perf ring buffer
>   rdi0xf7768000   4151738368
>
>so I'm not sure why RBP is involved at all.
>
>In all of the cases I've investigated the precise_ip value has been set
>
>for the problem event... but none of the events have been hardware
>events
>(software and breakpoint so far).  So probably not PEBS related?
>
>Vince

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.
--
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: It BOOTS! 3.13.5 that is.

[Gene Heskett]

On Saturday 22 February 2014, Ilia Mirkin wrote:
>On Sat, Feb 22, 2014 at 11:00 PM, Gene Heskett  wrote:
>> On Saturday 22 February 2014, Ilia Mirkin wrote:
>>>On Sat, Feb 22, 2014 at 10:42 PM, Gene Heskett  
wrote:
 On Saturday 22 February 2014, Ilia Mirkin wrote:
>On Sat, Feb 22, 2014 at 8:22 PM, Gene Heskett  
wrote:
>> But my tv card isn't being found by kaffeine.  It is this card:
>> 
>> 01:08.0 Multimedia video controller: Conexant Systems, Inc.
>> CX23880/1/2/3 PCI Video and Audio Decoder (rev 05)
>> 
>> Subsystem: pcHDTV Device 3000
>> Flags: bus master, medium devsel, latency 32, IRQ 10
>> Memory at fb00 (32-bit, non-prefetchable) [size=16M]
>> Capabilities: [44] Vital Product Data 
>> Capabilities: [4c] Power Management version 2
>> 
>> 01:08.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3
>> PCI Video and Audio Decoder [MPEG Port] (rev 05)
>> 
>> Subsystem: pcHDTV Device 3000
>> Flags: bus master, medium devsel, latency 32, IRQ 10
>> Memory at fa00 (32-bit, non-prefetchable) [size=16M]
>> Capabilities: [4c] Power Management version 2
>> 
>> From an lspci
>> 
>> In a make xconfig, I cannot find this specific card in the list of
>> DVB front ends.  What modules do I need to make sure are being
>> built?
>
>You're looking for VIDEO_CX88 ("Conexant 2388x (bt878 successor)
>support") and its various sub-options (esp CX88_DVB). iirc the
>pchdtv3000 had a OR51132 tuner, but right now the config is set to
>auto-select a whole bunch of tuners if you have
>MEDIA_SUBDRV_AUTOSELECT turned on. Otherwise make sure to select that
>tuner device. (Hm, I appear to have both OR51132 and CX22702 enabled,
>and I have that same card.)
>
>  -ilia
 
 or51132 rings a bell and is enabled, CX22702 is not.  And I don't
 seem to be able to find the CX88** at all.  I'll give the CX22702 a
 shot, thanks a bunch ilia.
>>>
>>>grep CX88 .config
>>>
>> That returns a linefeed only.  And I have done some dozen or so make
>> oldconfigs.
>> 
>>>If it says "not set" for things like CONFIG_VIDEO_CX88_DVB, you won't
>>>get anything to work.
>>>
>>>  -ilia
>> 
>> If this fails, I'll see if I can plug that in with an editor, but the
>> last time I tried that, the friggin make did an automatic oldconfig
>> and stripped it.  Its enough to make one want to reduce the
>> neighborhood cat population.
>
>Adding random stuff to .config won't work, as you noticed.
>
>>From menuconfig search results for CX88 (ugh, sorry about the x's, but
>I'm too lazy to edit them out)
>
>  x Symbol: VIDEO_CX88 [=m]  
>  x x Type  : tristate  
> x x Prompt: Conexant 2388x (bt878 successor) support   
>x x   Location: 
>   x x -> Device Drivers
>  x x   -> Multimedia support (MEDIA_SUPPORT [=m])  
> x x (1) -> Media PCI Adapters (MEDIA_PCI_SUPPORT
>[=y])  x x   Defined at drivers/media/pci/cx88/Kconfig:1
>  x x   Depends on: MEDIA_SUPPORT [=m] &&
>MEDIA_PCI_SUPPORT [=y] && (MEDIA_AN x x   Selects: I2C_ALGOBIT [=m] &&
>VIDEO_BTCX [=m] && VIDEOBUF_DMA_SG [=m]  x
>
>HTH,
>
>  -ilia

Sorry, no such beast As VIDEO_CX88.

Now that tells me something in the VIDEO dept isn't set, but what?

Thanks Ilia.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

--
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: perf_fuzzer compiled for x32 causes reboot

[Vince Weaver]

On Fri, 21 Feb 2014, H. Peter Anvin wrote:

> Error 6 reflects a write in userspace to a not-present page.
> 
> Since your previous trace indicates that the value of the register in question
> is a different one, I'm guessing that what we have here is PEBS getting
> activated.  0x120 is 2*0x90, and 0x90 is the size of a 64-bit PEBS record.

I'm having problems generating a replayable syscall trace that exhibits 
the problem.

It turns out that the segfault address listed (the multiple of 0x120) 
happens to be the value in the RBP register at the time of the segfault.

That's odd, as the instruction is
movdqa %xmm0,(%rdi)
and rdi is the valid mmap address of the perf ring buffer
rdi0xf7768000   4151738368

so I'm not sure why RBP is involved at all.

In all of the cases I've investigated the precise_ip value has been set 
for the problem event... but none of the events have been hardware events
(software and breakpoint so far).  So probably not PEBS related?

Vince

--
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] [Announcement] Updates to XenGT - a Mediated Graphics Passthrough Solution from Intel

[Cui, Dexuan]

Pasi Kärkkäinen wrote on 2014-02-22:
> On Fri, Feb 21, 2014 at 02:22:11AM +, Cui, Dexuan wrote:
>> Pasi Kärkkäinen wrote on 2014-02-21:
>>> On Thu, Feb 20, 2014 at 07:59:04AM +, Cui, Dexuan wrote:
 Hi all, We're pleased to announce an update to XenGT since its first
 disclosure in last Sep.
>>> 
>>> Are you going to work on upstreaming this stuff? Xen 4.4 will be
>>> released soon(ish), so the Xen 4.5 development window starts in the near
>>> future and hopefully this stuff can be upstreamed then..
>> Hi Pasi,
>> We do plan to upstream but not give a timeframe so far.
>> 
> 
> Ok. Would you like to post an article on the Xen blog about XenGT ?
> I think that would be a good thing to do to get more visibility for this 
> feature.
As I mentioned in the previous mail, we already have a blog article, which
can be easily found by googling xengt: :-)
https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt

>>> Also: Haswell ("4th generation Intel core CPU") is listed as a
>>> requirement in the Setup Guide PDF.. will there be support for SNB/IVB
>>> GPUs aswell?
>> There is no plan for SNB/IVB.
>> 
> 
> Is that because of some hardware limitation on earlier GPU generations,
> or just a matter of amount of work needed to support XenGT on earlier
> GPUs?
> -- Pasi
No HW limitation on earlier GPUs -- actually you can even see some unused
codes about earlier generations in the linux-vgt.patch.
At present we'd like to focus on HSW (and newer generation in future).

-- Dexuan

--
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: nouveau graphical corruption in 3.13.2

[Ilia Mirkin]

On Sat, Feb 22, 2014 at 10:45 PM, Daniel J Blueman  wrote:
> On 9 February 2014 02:57, Ilia Mirkin  wrote:
>> On Sat, Feb 8, 2014 at 10:38 AM, Daniel J Blueman  wrote:
>>> Interestingly, there was graphical failure booting 3.6.11, even
>>> nvidia-current fails to initialise, but these two issues could be due
>>> to running the Xorg stack in Ubuntu 14.04 pre-release. Using
>>> nouveau.noaccel=1 works great for the first X session, but after
>>> logging out, lightdm and the next session experiences this consistent
>>> screen corruption:
>>>
>>> http://quora.org/nouveau-corruption.jpg
>>
>> Does that just happen in 3.6.11 or even in 3.13? If the latter, that.
>> points to some key lack of understanding of... something. With
>> noaccel, we're not using pgraph or anything fancy -- it's just a
>> framebuffer, basically. So if we can't even render _that_ right...
>>
>> Hopefully someone else will pipe up re your other issues -- my
>> knowledge base on this is exhausted :(
>
> Interestingly, it turns out that the screen corruption occurs on every
> boot (booting with nouveau.noaccel=1 for now), and I can consistently
> work around it by one suspend-resume cycle.
>
> To that effect, I've captured kernel message output booting 3.14-rc3
> with 'nouveau.noaccel=1 nouveau.debug=trace,DEVINIT=spam drm.debug=0x6
> log_buf_len=16M', and performed a suspend-resume cycle:
> http://quora.org/nouveau-log.txt

An observation:

on boot:

[7.086599] [drm:drm_crtc_helper_set_mode], [ENCODER:16:LVDS-16]
set [MODE:29:1280x800]
[7.150571] nouveau D[   PDISP][:04:00.0] supervisor 0x0010
0x0020
[7.164662] nouveau D[   PDISP][:04:00.0] supervisor 0x0020
0x0030
[7.164903] nouveau D[   PDISP][:04:00.0] supervisor 0x0040
0x0030

on resume:

[   59.538135] [drm:drm_crtc_helper_set_mode], [ENCODER:16:LVDS-16]
set [MODE:29:1280x800]
[   59.539586] nouveau D[   PDISP][:04:00.0] supervisor 0x0010
0x02a0
[   59.540738] nouveau D[   PDISP][:04:00.0] supervisor 0x0020
0x02b0
[   59.540812] nouveau T[   VBIOS][:04:00.0] 0x547f[0]: SUB_DIRECT 0x556f
[   59.540814] nouveau T[   VBIOS][:04:00.0] 0x556f[1]: NV_REG
R[0x4061c00c] &= 0xfffe |= 0x
[   59.540818] nouveau T[   VBIOS][:04:00.0] 0x557c[1]: NV_REG
R[0x4061c00c] &= 0xfffe |= 0x0001
[   59.540836] nouveau T[   VBIOS][:04:00.0] 0x5589[1]: TIME 0x3e80
[   59.556702] nouveau T[   VBIOS][:04:00.0] 0x558c[1]: NV_REG
R[0x4061c00c] &= 0xfffe |= 0x
[   59.556714] nouveau T[   VBIOS][:04:00.0] 0x5599[1]: DONE
[   59.556716] nouveau T[   VBIOS][:04:00.0] 0x5482[0]: ZM_REG_SEQUENCE 0x05
[   59.556718] nouveau T[   VBIOS][:04:00.0] 0x5488[0]:
R[0x4061c00c] = 0x01060200
[   59.556720] nouveau T[   VBIOS][:04:00.0] 0x548c[0]:
R[0x4061c010] = 0x031a
[   59.556721] nouveau T[   VBIOS][:04:00.0] 0x5490[0]:
R[0x4061c014] = 0x
[   59.556723] nouveau T[   VBIOS][:04:00.0] 0x5494[0]:
R[0x4061c018] = 0x000f4af8
[   59.556725] nouveau T[   VBIOS][:04:00.0] 0x5498[0]:
R[0x4061c01c] = 0x0001caf0
[   59.556726] nouveau T[   VBIOS][:04:00.0] 0x549c[0]: SUB_DIRECT 0x55c5
[   59.556728] nouveau T[   VBIOS][:04:00.0] 0x55c5[1]: NV_REG
R[0x00e1e4] &= 0xfffc |= 0x
[   59.556741] nouveau T[   VBIOS][:04:00.0] 0x55d2[1]: NV_REG
R[0x00e100] &= 0xfff7 |= 0x0008
[   59.556751] nouveau T[   VBIOS][:04:00.0] 0x55df[1]: ZM_REG_SEQUENCE 0x02
[   59.556753] nouveau T[   VBIOS][:04:00.0] 0x55e5[1]:
R[0x4061c118] = 0x15151515
[   59.556754] nouveau T[   VBIOS][:04:00.0] 0x55e9[1]:
R[0x4061c11c] = 0x0015
[   59.556756] nouveau T[   VBIOS][:04:00.0] 0x55ed[1]: ZM_REG_SEQUENCE 0x02
[   59.556757] nouveau T[   VBIOS][:04:00.0] 0x55f3[1]:
R[0x4061c198] = 0x15151515
[   59.556759] nouveau T[   VBIOS][:04:00.0] 0x55f7[1]:
R[0x4061c19c] = 0x0015
[   59.556760] nouveau T[   VBIOS][:04:00.0] 0x55fb[1]: SUB_DIRECT 0x5e02
[   59.556762] nouveau T[   VBIOS][:04:00.0] 0x5e02[2]: DONE
[   59.556763] nouveau T[   VBIOS][:04:00.0] 0x55fe[1]: DONE
[   59.556765] nouveau T[   VBIOS][:04:00.0] 0x549f[0]: SUB_DIRECT 0x55ff
[   59.556766] nouveau T[   VBIOS][:04:00.0] 0x55ff[1]: DONE
[   59.556767] nouveau T[   VBIOS][:04:00.0] 0x54a2[0]: DONE
[   59.811966] nouveau D[   PDISP][:04:00.0] supervisor 0x0040
0x02b0
[   59.812033] nouveau T[   VBIOS][:04:00.0] 0x5600[0]: DONE

I'm pretty weak on that supervisor logic, unfortunately. But somehow
on boot it's not saying to execute the vbios snippet? Perhaps that's
normal though? Ben?

Also, Daniel -- first off, DEVINIT doesn't really do very much (you
might be thinking it has something to do with device init... while you
wouldn't be completely wrong, you also wouldn't be right enough).
Debug levels below "trace" need a special kernel recompile (there's a
config option for how low to compile in, otherwise there'd be too much
overhead). spam causes 

Re: [PATCH v2 5/9] usb: don't use PREPARE_DELAYED_WORK

[Tejun Heo]

Hey, Alan.

On Sat, Feb 22, 2014 at 06:03:04PM -0500, Alan Stern wrote:
> >  then a single init work could be queued to
> > the system_unbound_wq which doesn't care about running times.
> 
> This sort of thing sounds like the best approach.  Tejun, do you want
> to rewrite the patch, getting rid of the hub_init_func3 and HUB_INIT3
> business entirely?  Or would you like me to do it?

I'll doing the minimal patch in this series and then following up with
the update is probably better.  I can put the patches in a separate
branch so that it can be easily pulled.

Thanks.

-- 
tejun
--
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] regulator fixes for v3.14

[Mark Brown]

The following changes since commit 6d0abeca3242a88cab8232e4acd7e2bf088f3bc2:

  Linux 3.14-rc3 (2014-02-16 13:30:25 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 
tags/regulator-v3.14-rc4

for you to fetch changes up to bcad2ca37296ab6c09de7975e850cb8f90c44c08:

  Merge remote-tracking branches 'regulator/fix/da9063', 
'regulator/fix/max14577' and 'regulator/fix/s5m8767' into regulator-linus 
(2014-02-23 12:22:18 +0900)



regulator: Fixes for v3.14

Mostly unexciting driver fixes, plus one fix to lower the severity of
the log message when we don't use an optional regulator - the fixes for
ACPI system made this come up more often and it was correctly observed
that it was causing undue concern for users.


Krzysztof Kozlowski (1):
  regulator: max14577: Fix invalid return value on DT parse success

Mark Brown (2):
  Merge remote-tracking branch 'regulator/fix/core' into regulator-linus
  Merge remote-tracking branches 'regulator/fix/da9063', 
'regulator/fix/max14577' and 'regulator/fix/s5m8767' into regulator-linus

Sachin Kamat (2):
  regulator: s5m8767: Use of_get_child_by_name
  regulator: s5m8767: Add missing of_node_put

Shuah Khan (1):
  regulator: core: Change dummy supplies error message to a warning

Steve Twiss (1):
  regulator: da9063: Bug fix when setting max voltage on LDOs 5-11

 drivers/regulator/core.c | 2 +-
 drivers/regulator/da9063-regulator.c | 4 +++-
 drivers/regulator/max14577.c | 5 +++--
 drivers/regulator/s5m8767.c  | 4 +++-
 4 files changed, 10 insertions(+), 5 deletions(-)


signature.asc
Description: Digital signature

Re: It BOOTS! 3.13.5 that is.

[Ilia Mirkin]

On Sat, Feb 22, 2014 at 11:00 PM, Gene Heskett  wrote:
> On Saturday 22 February 2014, Ilia Mirkin wrote:
>>On Sat, Feb 22, 2014 at 10:42 PM, Gene Heskett  wrote:
>>> On Saturday 22 February 2014, Ilia Mirkin wrote:
On Sat, Feb 22, 2014 at 8:22 PM, Gene Heskett  wrote:
> But my tv card isn't being found by kaffeine.  It is this card:
>
> 01:08.0 Multimedia video controller: Conexant Systems, Inc.
> CX23880/1/2/3 PCI Video and Audio Decoder (rev 05)
>
> Subsystem: pcHDTV Device 3000
> Flags: bus master, medium devsel, latency 32, IRQ 10
> Memory at fb00 (32-bit, non-prefetchable) [size=16M]
> Capabilities: [44] Vital Product Data 
> Capabilities: [4c] Power Management version 2
>
> 01:08.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3
> PCI Video and Audio Decoder [MPEG Port] (rev 05)
>
> Subsystem: pcHDTV Device 3000
> Flags: bus master, medium devsel, latency 32, IRQ 10
> Memory at fa00 (32-bit, non-prefetchable) [size=16M]
> Capabilities: [4c] Power Management version 2
>
> From an lspci
>
> In a make xconfig, I cannot find this specific card in the list of
> DVB front ends.  What modules do I need to make sure are being
> built?

You're looking for VIDEO_CX88 ("Conexant 2388x (bt878 successor)
support") and its various sub-options (esp CX88_DVB). iirc the
pchdtv3000 had a OR51132 tuner, but right now the config is set to
auto-select a whole bunch of tuners if you have
MEDIA_SUBDRV_AUTOSELECT turned on. Otherwise make sure to select that
tuner device. (Hm, I appear to have both OR51132 and CX22702 enabled,
and I have that same card.)

  -ilia
>>>
>>> or51132 rings a bell and is enabled, CX22702 is not.  And I don't seem
>>> to be able to find the CX88** at all.  I'll give the CX22702 a shot,
>>> thanks a bunch ilia.
>>
>>grep CX88 .config
>
> That returns a linefeed only.  And I have done some dozen or so make
> oldconfigs.
>>
>>If it says "not set" for things like CONFIG_VIDEO_CX88_DVB, you won't
>>get anything to work.
>>
>>  -ilia
>
> If this fails, I'll see if I can plug that in with an editor, but the last
> time I tried that, the friggin make did an automatic oldconfig and stripped
> it.  Its enough to make one want to reduce the neighborhood cat population.

Adding random stuff to .config won't work, as you noticed.

>From menuconfig search results for CX88 (ugh, sorry about the x's, but
I'm too lazy to edit them out)

  x Symbol: VIDEO_CX88 [=m] x
  x Type  : tristatex
  x Prompt: Conexant 2388x (bt878 successor) supportx
  x   Location: x
  x -> Device Drivers   x
  x   -> Multimedia support (MEDIA_SUPPORT [=m])x
  x (1) -> Media PCI Adapters (MEDIA_PCI_SUPPORT [=y])  x
  x   Defined at drivers/media/pci/cx88/Kconfig:1   x
  x   Depends on: MEDIA_SUPPORT [=m] && MEDIA_PCI_SUPPORT [=y] && (MEDIA_AN x
  x   Selects: I2C_ALGOBIT [=m] && VIDEO_BTCX [=m] && VIDEOBUF_DMA_SG [=m]  x

HTH,

  -ilia
--
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: nouveau graphical corruption in 3.13.2

[Daniel J Blueman]

On 23 February 2014 11:48, Ilia Mirkin  wrote:
> On Sat, Feb 22, 2014 at 10:45 PM, Daniel J Blueman  wrote:
>> On 9 February 2014 02:57, Ilia Mirkin  wrote:
>>> On Sat, Feb 8, 2014 at 10:38 AM, Daniel J Blueman  wrote:
 Interestingly, there was graphical failure booting 3.6.11, even
 nvidia-current fails to initialise, but these two issues could be due
 to running the Xorg stack in Ubuntu 14.04 pre-release. Using
 nouveau.noaccel=1 works great for the first X session, but after
 logging out, lightdm and the next session experiences this consistent
 screen corruption:

 http://quora.org/nouveau-corruption.jpg
>>>
>>> Does that just happen in 3.6.11 or even in 3.13? If the latter, that.
>>> points to some key lack of understanding of... something. With
>>> noaccel, we're not using pgraph or anything fancy -- it's just a
>>> framebuffer, basically. So if we can't even render _that_ right...
>>>
>>> Hopefully someone else will pipe up re your other issues -- my
>>> knowledge base on this is exhausted :(
>>
>> Interestingly, it turns out that the screen corruption occurs on every
>> boot (booting with nouveau.noaccel=1 for now), and I can consistently
>> work around it by one suspend-resume cycle.
>
> Does booting with nouveau.config=NvForcePost=1 help?

Still no cigar with nouveau.config=NvForcePost=1.

I meant to add that restarting X or changing resolutions doesn't
resolve the issue. The corruption is consistently 16-pixel wide by 1
high stippling on a consistent address range of the framebuffer.

Thanks,
  Daniel
-- 
Daniel J Blueman
--
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: It BOOTS! 3.13.5 that is.

[Gene Heskett]

On Saturday 22 February 2014, Ilia Mirkin wrote:
>On Sat, Feb 22, 2014 at 10:42 PM, Gene Heskett  wrote:
>> On Saturday 22 February 2014, Ilia Mirkin wrote:
>>>On Sat, Feb 22, 2014 at 8:22 PM, Gene Heskett  wrote:
 But my tv card isn't being found by kaffeine.  It is this card:
 
 01:08.0 Multimedia video controller: Conexant Systems, Inc.
 CX23880/1/2/3 PCI Video and Audio Decoder (rev 05)
 
 Subsystem: pcHDTV Device 3000
 Flags: bus master, medium devsel, latency 32, IRQ 10
 Memory at fb00 (32-bit, non-prefetchable) [size=16M]
 Capabilities: [44] Vital Product Data 
 Capabilities: [4c] Power Management version 2
 
 01:08.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3
 PCI Video and Audio Decoder [MPEG Port] (rev 05)
 
 Subsystem: pcHDTV Device 3000
 Flags: bus master, medium devsel, latency 32, IRQ 10
 Memory at fa00 (32-bit, non-prefetchable) [size=16M]
 Capabilities: [4c] Power Management version 2
 
 From an lspci
 
 In a make xconfig, I cannot find this specific card in the list of
 DVB front ends.  What modules do I need to make sure are being
 built?
>>>
>>>You're looking for VIDEO_CX88 ("Conexant 2388x (bt878 successor)
>>>support") and its various sub-options (esp CX88_DVB). iirc the
>>>pchdtv3000 had a OR51132 tuner, but right now the config is set to
>>>auto-select a whole bunch of tuners if you have
>>>MEDIA_SUBDRV_AUTOSELECT turned on. Otherwise make sure to select that
>>>tuner device. (Hm, I appear to have both OR51132 and CX22702 enabled,
>>>and I have that same card.)
>>>
>>>  -ilia
>> 
>> or51132 rings a bell and is enabled, CX22702 is not.  And I don't seem
>> to be able to find the CX88** at all.  I'll give the CX22702 a shot,
>> thanks a bunch ilia.
>
>grep CX88 .config

That returns a linefeed only.  And I have done some dozen or so make 
oldconfigs.
>
>If it says "not set" for things like CONFIG_VIDEO_CX88_DVB, you won't
>get anything to work.
>
>  -ilia

If this fails, I'll see if I can plug that in with an editor, but the last 
time I tried that, the friggin make did an automatic oldconfig and stripped 
it.  Its enough to make one want to reduce the neighborhood cat population.

Thanks Ilia

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

--
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: It BOOTS! 3.13.5 that is.

[Gene Heskett]

On Saturday 22 February 2014, Ilia Mirkin wrote:
>On Sat, Feb 22, 2014 at 8:22 PM, Gene Heskett  wrote:
>> But my tv card isn't being found by kaffeine.  It is this card:
>> 
>> 01:08.0 Multimedia video controller: Conexant Systems, Inc.
>> CX23880/1/2/3 PCI Video and Audio Decoder (rev 05)
>> 
>> Subsystem: pcHDTV Device 3000
>> Flags: bus master, medium devsel, latency 32, IRQ 10
>> Memory at fb00 (32-bit, non-prefetchable) [size=16M]
>> Capabilities: [44] Vital Product Data 
>> Capabilities: [4c] Power Management version 2
>> 
>> 01:08.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI
>> Video and Audio Decoder [MPEG Port] (rev 05)
>> 
>> Subsystem: pcHDTV Device 3000
>> Flags: bus master, medium devsel, latency 32, IRQ 10
>> Memory at fa00 (32-bit, non-prefetchable) [size=16M]
>> Capabilities: [4c] Power Management version 2
>> 
>> From an lspci
>> 
>> In a make xconfig, I cannot find this specific card in the list of DVB
>> front ends.  What modules do I need to make sure are being built?
>
>You're looking for VIDEO_CX88 ("Conexant 2388x (bt878 successor)
>support") and its various sub-options (esp CX88_DVB). iirc the
>pchdtv3000 had a OR51132 tuner, but right now the config is set to
>auto-select a whole bunch of tuners if you have
>MEDIA_SUBDRV_AUTOSELECT turned on. Otherwise make sure to select that
>tuner device. (Hm, I appear to have both OR51132 and CX22702 enabled,
>and I have that same card.)
>
>  -ilia

I just checked, and enabled the **700 version too, since the 702 says its 
for OFDM, and we're on ATSC here. That help sucks.

I hope the firmware is still about. Looks like the or51132-vsb.fw is there 
ok.

Another kernel build underway.  Thanks Ilias.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

--
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 0/5] arch: atomic rework

[Linus Torvalds]

On Sat, Feb 22, 2014 at 4:39 PM, Paul E. McKenney
 wrote:
>
> Agreed, by far the most frequent use is "->" to dereference and assignment
> to store into a local variable.  The other operations where the kernel
> expects ordering to be maintained are:
>
> o   Bitwise "&" to strip off low-order bits.  The FIB tree does
> this, for example in fib_table_lookup() in net/ipv4/fib_trie.c.
> The low-order bit is used to distinguish internal nodes from
> leaves -- nodes and leaves are different types of structures.
> (There are a few others.)

Note that this is very much outside the scope of the C standard,
regardless of 'consume' or not.

We'll always do things outside the standard, so I wouldn't worry.

> o   Uses "?:" to substitute defaults in case of NULL pointers,
> but ordering must be maintained in the non-default case.
> Most, perhaps all, of these could be converted to "if" should
> "?:" prove problematic.

Note that this doesn't actually affect the restrict/ordering rule in
theory: "?:" isn't special according to those rules. The rules are
fairly simple: we guarantee ordering only to the object that the
pointer points to, and even that guarantee goes out the window if
there is some *other* way to reach the object.

?: is not really relevant, except in the sense that *any* expression
that ends up pointing to outside the object will lose the ordering
guarantee. ?: can be one such expression, but so can "p-p" or anything
like that.

And in *practice*, the only thing that needs to be sure to generate
special code is alpha, and there you'd just add the "rmb" after the
load. That is sufficient to fulfill the guarantees.

On ARM and powerpc, the compiler obviously has to guarantee that it
doesn't do value-speculation on the result, but again, that never
really had anything to do with the whole "carries a dependency", it is
really all about the fact that in order to guarantee the ordering, the
compiler mustn't generate that magical aliased pointer value. But if
the aliased pointer value comes from the *source* code, all bets are
off.

Now, even on alpha, the compiler can obviously move that "rmb" around.
For example, if there is a conditional after the
"atomic_read(mo_consume)", and the compiler can tell that the pointer
that got read by mo_consume is dead along one branch, then the
compiler can move the "rmb" to only exist in the other branch. Why?
Because we inherently guarantee only the order to any accesses to the
object the pointer pointed to, and that the pointer that got loaded is
the *only* way to get to that object (in this context), so if the
value is dead, then so is the ordering.

In fact, even if the value is *not* dead, but it is NULL, the compiler
can validly say "the NULL pointer cannot point to any object, so I
don't have to guarantee any serialization". So code like this (writing
alpha assembly, since in practice only alpha will ever care):

ptr = atomic_read(pp, mo_consume);
if (ptr) {
   ... do something with ptr ..
}
return ptr;

can validly be translated to:

ldq $1,0($2)
beq $1,branch-over
rmb
.. the do-something code using register $1 ..

because the compiler knows that a NULL pointer cannot be dereferenced,
so it can decide to put the rmb in the non-NULL path - even though the
pointer value is still *live* in the other branch (well, the liveness
of a constant value is somewhat debatable, but you get the idea), and
may be used by the caller (but since it is NULL, the "use" can not
include accessing any object, only really testing)

So note how this is actually very different from the "carries
dependency" rule. It's simpler, and it allows much more natural
optimizations.

> o   Addition and subtraction to adjust both pointers to and indexes
> into RCU-protected arrays.  There are not that many indexes,
> and they could be converted to pointers, but the addition and
> subtraction looks necessary in a some cases.

Addition and subtraction is fine, as long as they stay within the same
object/array.

And realistically, people violate the whole C pointer "same object"
rule all the time. Any time you implement a raw memory allocator,
you'll violate the C standard and you *will* basically be depending on
architecture-specific behavior. So everybody knows that the C "pointer
arithmetic has to stay within the object" is really a fairly made-up
but convenient shorthand for "sure, we know you'll do tricks on
pointer values, but they won't be portable and you may have to take
particular machine representations into account".

> o   Array indexing.  The value from rcu_dereference() is used both
> before and inside the "[]", interestingly enough.

Well, in the C sense, or in the actual "integer index" sense? Because
technically, a[b] is nothing but *(a+b), so "inside" the "[]" is
strictly speaking meaningless. Inside and outside are just syntactic
sugar.

That said, 

Re: nouveau graphical corruption in 3.13.2

[Ilia Mirkin]

On Sat, Feb 22, 2014 at 10:45 PM, Daniel J Blueman  wrote:
> On 9 February 2014 02:57, Ilia Mirkin  wrote:
>> On Sat, Feb 8, 2014 at 10:38 AM, Daniel J Blueman  wrote:
>>> Interestingly, there was graphical failure booting 3.6.11, even
>>> nvidia-current fails to initialise, but these two issues could be due
>>> to running the Xorg stack in Ubuntu 14.04 pre-release. Using
>>> nouveau.noaccel=1 works great for the first X session, but after
>>> logging out, lightdm and the next session experiences this consistent
>>> screen corruption:
>>>
>>> http://quora.org/nouveau-corruption.jpg
>>
>> Does that just happen in 3.6.11 or even in 3.13? If the latter, that.
>> points to some key lack of understanding of... something. With
>> noaccel, we're not using pgraph or anything fancy -- it's just a
>> framebuffer, basically. So if we can't even render _that_ right...
>>
>> Hopefully someone else will pipe up re your other issues -- my
>> knowledge base on this is exhausted :(
>
> Interestingly, it turns out that the screen corruption occurs on every
> boot (booting with nouveau.noaccel=1 for now), and I can consistently
> work around it by one suspend-resume cycle.

Does booting with nouveau.config=NvForcePost=1 help?
--
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: nouveau graphical corruption in 3.13.2

[Daniel J Blueman]

On 9 February 2014 02:57, Ilia Mirkin  wrote:
> On Sat, Feb 8, 2014 at 10:38 AM, Daniel J Blueman  wrote:
>> Interestingly, there was graphical failure booting 3.6.11, even
>> nvidia-current fails to initialise, but these two issues could be due
>> to running the Xorg stack in Ubuntu 14.04 pre-release. Using
>> nouveau.noaccel=1 works great for the first X session, but after
>> logging out, lightdm and the next session experiences this consistent
>> screen corruption:
>>
>> http://quora.org/nouveau-corruption.jpg
>
> Does that just happen in 3.6.11 or even in 3.13? If the latter, that.
> points to some key lack of understanding of... something. With
> noaccel, we're not using pgraph or anything fancy -- it's just a
> framebuffer, basically. So if we can't even render _that_ right...
>
> Hopefully someone else will pipe up re your other issues -- my
> knowledge base on this is exhausted :(

Interestingly, it turns out that the screen corruption occurs on every
boot (booting with nouveau.noaccel=1 for now), and I can consistently
work around it by one suspend-resume cycle.

To that effect, I've captured kernel message output booting 3.14-rc3
with 'nouveau.noaccel=1 nouveau.debug=trace,DEVINIT=spam drm.debug=0x6
log_buf_len=16M', and performed a suspend-resume cycle:
http://quora.org/nouveau-log.txt

Ben et al, would some specific register tracing or otherwise help to
locate the issue?
-- 
Daniel J Blueman
--
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 07/11] watchdog: xilinx: Use of_property_read_u32

[Guenter Roeck]

On 02/22/2014 10:14 PM, Alejandro Cabrera wrote:

On 22/2/2014 5:36 PM, Guenter Roeck wrote:

On 02/22/2014 07:52 PM, Alejandro Cabrera wrote:

On 22/2/2014 3:18 PM, Guenter Roeck wrote:

On 02/22/2014 05:08 PM, Alejandro Cabrera wrote:

On 22/2/2014 10:46 AM, Wim Van Sebroeck wrote:

Hi All,


Hi Michal,

On Wed, Feb 12, 2014 at 02:41:21PM +0100, Michal Simek wrote:

Use of_property_read_u32 functions to clean probe function.

Signed-off-by: Michal Simek
Reviewed-by: Guenter Roeck
---

Changes in v3:
- Remove one if checking and use variable directly


Looks good.

Another comment/remark.


-pfreq = (u32 *)of_get_property(pdev->dev.of_node,
-"clock-frequency", NULL);
-
-if (pfreq == NULL) {
+rc = of_property_read_u32(pdev->dev.of_node, "clock-frequency",);
+if (rc) {
  dev_warn(>dev,
   "The watchdog clock frequency cannot be obtained\n");
  no_timeout = true;
  }

-tmptr = (u32 *)of_get_property(pdev->dev.of_node,
-"xlnx,wdt-interval", NULL);
-if (tmptr == NULL) {
+rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-interval",
+ >wdt_interval);
+if (rc) {
  dev_warn(>dev,
   "Parameter \"xlnx,wdt-interval\" not found\n");
  no_timeout = true;
-} else {
-xdev->wdt_interval = *tmptr;
  }

-tmptr = (u32 *)of_get_property(pdev->dev.of_node,
-"xlnx,wdt-enable-once", NULL);
-if (tmptr == NULL) {
+rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-enable-once",
+ _once);
+if (rc)
  dev_warn(>dev,
   "Parameter \"xlnx,wdt-enable-once\" not found\n");
-watchdog_set_nowayout(xilinx_wdt_wdd, true);
-}

All the above properties are optional. Is a warning really
warranted in this case ? I usually associate a warning with
something that is wrong, which is not the case here.

I would encourage you to drop those warnings, but that should be
a separate patch.

I agree with Guenter: these are not really warnings. Seperate patch is thus 
welcome.

Hi

I support Michal intention, I think it is a warning because device tree blob must have 
the "xlnx,wdt-enable-once" property specified in order to allow the system to 
be sure of the real value of this property. In addition to, this warning can be helpful 
to detect a wrong device tree specification.



The dt documentation states that the properties are optional.

Optional properties:
- clock-frequency   : Frequency of clock in Hz
- xlnx,wdt-enable-once  : 0 - Watchdog can be restarted
  1 - Watchdog can be enabled just once
- xlnx,wdt-interval : Watchdog timeout interval in 2^ clock cycles,
 is integer from 8 to 31.

This clearly conflicts with your statement. An optional property
is just that, optional. If it warrants a warning, it must
not be optional. If you claim that not providing the properties
would be "wrong", why are they defined as optional ?

Hi Guenter

I didn't know that these properties was classified as optional...
I think that they should not be, because all xilinx watchog devices (at least 
for microblaze processor)
have these properties defined in theirs MPD files and theirs values can be 
obtained during the
hardware specification to device tree conversion.

What is your definition of "wrong" and "must have" ?

what I mean for "must have" is: if these properties can be obtained
for all xilinx watchdog devices they must be present in the device tree because 
they allows
the system (linux/user) to know exactly how a watchdog device is configured.
Because these properties always can be obtained from hardware design there is no
reason to leave them out from the device tree. This is why I consider that a 
device tree without
these properties should be considered as "wrong" device tree.

How do you expect anyone to know that omitting those
"optional" properties is by some definition "wrong" ?

I'm agree with you.
Maybe these properties shouldn't be optional.
For example suppose that "xlnx,wdt-enable-once" is missing in the device tree,
when a watchdog daemon ask for this property what is the obtained value ?
Independently of this value, why do not warn the user about this missing 
property
when it can always be in the device tree ?



Really, this line of argument doesn't make any sense to me.
"xlnx,wdt-enable-once", for example, is a boolean and means
that the watchdog, when enabled, can not be stopped. It defaults
to false, and thus is inherently optional. Making it mandatory
doesn't really add any value.



If the device has been configured with wdt-enable-once=true
and the device tree doesn't have this property then a watchdog daemon
would see it as "false" because it is the default making the system to 
misbehave...
A warning during driver loading could help user to identify the problem.



All this would give you is a false sense of safety. The property could
just as well be there and be wrong (eg be 

Re: It BOOTS! 3.13.5 that is.

[Ilia Mirkin]

On Sat, Feb 22, 2014 at 10:42 PM, Gene Heskett  wrote:
> On Saturday 22 February 2014, Ilia Mirkin wrote:
>>On Sat, Feb 22, 2014 at 8:22 PM, Gene Heskett  wrote:
>>> But my tv card isn't being found by kaffeine.  It is this card:
>>>
>>> 01:08.0 Multimedia video controller: Conexant Systems, Inc.
>>> CX23880/1/2/3 PCI Video and Audio Decoder (rev 05)
>>>
>>> Subsystem: pcHDTV Device 3000
>>> Flags: bus master, medium devsel, latency 32, IRQ 10
>>> Memory at fb00 (32-bit, non-prefetchable) [size=16M]
>>> Capabilities: [44] Vital Product Data 
>>> Capabilities: [4c] Power Management version 2
>>>
>>> 01:08.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI
>>> Video and Audio Decoder [MPEG Port] (rev 05)
>>>
>>> Subsystem: pcHDTV Device 3000
>>> Flags: bus master, medium devsel, latency 32, IRQ 10
>>> Memory at fa00 (32-bit, non-prefetchable) [size=16M]
>>> Capabilities: [4c] Power Management version 2
>>>
>>> From an lspci
>>>
>>> In a make xconfig, I cannot find this specific card in the list of DVB
>>> front ends.  What modules do I need to make sure are being built?
>>
>>You're looking for VIDEO_CX88 ("Conexant 2388x (bt878 successor)
>>support") and its various sub-options (esp CX88_DVB). iirc the
>>pchdtv3000 had a OR51132 tuner, but right now the config is set to
>>auto-select a whole bunch of tuners if you have
>>MEDIA_SUBDRV_AUTOSELECT turned on. Otherwise make sure to select that
>>tuner device. (Hm, I appear to have both OR51132 and CX22702 enabled,
>>and I have that same card.)
>>
>>  -ilia
> or51132 rings a bell and is enabled, CX22702 is not.  And I don't seem to
> be able to find the CX88** at all.  I'll give the CX22702 a shot, thanks a
> bunch ilia.

grep CX88 .config

If it says "not set" for things like CONFIG_VIDEO_CX88_DVB, you won't
get anything to work.

  -ilia
--
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: It BOOTS! 3.13.5 that is.

[Gene Heskett]

On Saturday 22 February 2014, Ilia Mirkin wrote:
>On Sat, Feb 22, 2014 at 8:22 PM, Gene Heskett  wrote:
>> But my tv card isn't being found by kaffeine.  It is this card:
>> 
>> 01:08.0 Multimedia video controller: Conexant Systems, Inc.
>> CX23880/1/2/3 PCI Video and Audio Decoder (rev 05)
>> 
>> Subsystem: pcHDTV Device 3000
>> Flags: bus master, medium devsel, latency 32, IRQ 10
>> Memory at fb00 (32-bit, non-prefetchable) [size=16M]
>> Capabilities: [44] Vital Product Data 
>> Capabilities: [4c] Power Management version 2
>> 
>> 01:08.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI
>> Video and Audio Decoder [MPEG Port] (rev 05)
>> 
>> Subsystem: pcHDTV Device 3000
>> Flags: bus master, medium devsel, latency 32, IRQ 10
>> Memory at fa00 (32-bit, non-prefetchable) [size=16M]
>> Capabilities: [4c] Power Management version 2
>> 
>> From an lspci
>> 
>> In a make xconfig, I cannot find this specific card in the list of DVB
>> front ends.  What modules do I need to make sure are being built?
>
>You're looking for VIDEO_CX88 ("Conexant 2388x (bt878 successor)
>support") and its various sub-options (esp CX88_DVB). iirc the
>pchdtv3000 had a OR51132 tuner, but right now the config is set to
>auto-select a whole bunch of tuners if you have
>MEDIA_SUBDRV_AUTOSELECT turned on. Otherwise make sure to select that
>tuner device. (Hm, I appear to have both OR51132 and CX22702 enabled,
>and I have that same card.)
>
>  -ilia
or51132 rings a bell and is enabled, CX22702 is not.  And I don't seem to 
be able to find the CX88** at all.  I'll give the CX22702 a shot, thanks a 
bunch ilia.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

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

Re: [PATCH 1/4] spi: rspi: List full example compatible properties in bindings

[Mark Brown]

On Fri, Feb 21, 2014 at 05:29:15PM +0100, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven 
> 
> List full example compatible properties with soctypes instead of just the
> soctypes, so checkpatch can validate DTSes.

Applied all, thanks.


signature.asc
Description: Digital signature

Re: [PATCH v3 07/11] watchdog: xilinx: Use of_property_read_u32

[Alejandro Cabrera]

On 22/2/2014 5:36 PM, Guenter Roeck wrote:

On 02/22/2014 07:52 PM, Alejandro Cabrera wrote:

On 22/2/2014 3:18 PM, Guenter Roeck wrote:

On 02/22/2014 05:08 PM, Alejandro Cabrera wrote:

On 22/2/2014 10:46 AM, Wim Van Sebroeck wrote:

Hi All,


Hi Michal,

On Wed, Feb 12, 2014 at 02:41:21PM +0100, Michal Simek wrote:

Use of_property_read_u32 functions to clean probe function.

Signed-off-by: Michal Simek
Reviewed-by: Guenter Roeck
---

Changes in v3:
- Remove one if checking and use variable directly


Looks good.

Another comment/remark.


-pfreq = (u32 *)of_get_property(pdev->dev.of_node,
-"clock-frequency", NULL);
-
-if (pfreq == NULL) {
+rc = of_property_read_u32(pdev->dev.of_node, 
"clock-frequency",);

+if (rc) {
  dev_warn(>dev,
   "The watchdog clock frequency cannot be 
obtained\n");

  no_timeout = true;
  }

-tmptr = (u32 *)of_get_property(pdev->dev.of_node,
-"xlnx,wdt-interval", NULL);
-if (tmptr == NULL) {
+rc = of_property_read_u32(pdev->dev.of_node, 
"xlnx,wdt-interval",

+ >wdt_interval);
+if (rc) {
  dev_warn(>dev,
   "Parameter \"xlnx,wdt-interval\" not found\n");
  no_timeout = true;
-} else {
-xdev->wdt_interval = *tmptr;
  }

-tmptr = (u32 *)of_get_property(pdev->dev.of_node,
-"xlnx,wdt-enable-once", NULL);
-if (tmptr == NULL) {
+rc = of_property_read_u32(pdev->dev.of_node, 
"xlnx,wdt-enable-once",

+ _once);
+if (rc)
  dev_warn(>dev,
   "Parameter \"xlnx,wdt-enable-once\" not found\n");
-watchdog_set_nowayout(xilinx_wdt_wdd, true);
-}

All the above properties are optional. Is a warning really
warranted in this case ? I usually associate a warning with
something that is wrong, which is not the case here.

I would encourage you to drop those warnings, but that should be
a separate patch.
I agree with Guenter: these are not really warnings. Seperate 
patch is thus welcome.

Hi

I support Michal intention, I think it is a warning because device 
tree blob must have the "xlnx,wdt-enable-once" property specified 
in order to allow the system to be sure of the real value of this 
property. In addition to, this warning can be helpful to detect a 
wrong device tree specification.




The dt documentation states that the properties are optional.

Optional properties:
- clock-frequency   : Frequency of clock in Hz
- xlnx,wdt-enable-once  : 0 - Watchdog can be restarted
  1 - Watchdog can be enabled just once
- xlnx,wdt-interval : Watchdog timeout interval in 2^ clock 
cycles,

 is integer from 8 to 31.

This clearly conflicts with your statement. An optional property
is just that, optional. If it warrants a warning, it must
not be optional. If you claim that not providing the properties
would be "wrong", why are they defined as optional ?

Hi Guenter

I didn't know that these properties was classified as optional...
I think that they should not be, because all xilinx watchog devices 
(at least for microblaze processor)
have these properties defined in theirs MPD files and theirs values 
can be obtained during the

hardware specification to device tree conversion.

What is your definition of "wrong" and "must have" ?

what I mean for "must have" is: if these properties can be obtained
for all xilinx watchdog devices they must be present in the device 
tree because they allows
the system (linux/user) to know exactly how a watchdog device is 
configured.
Because these properties always can be obtained from hardware design 
there is no
reason to leave them out from the device tree. This is why I consider 
that a device tree without

these properties should be considered as "wrong" device tree.

How do you expect anyone to know that omitting those
"optional" properties is by some definition "wrong" ?

I'm agree with you.
Maybe these properties shouldn't be optional.
For example suppose that "xlnx,wdt-enable-once" is missing in the 
device tree,
when a watchdog daemon ask for this property what is the obtained 
value ?
Independently of this value, why do not warn the user about this 
missing property

when it can always be in the device tree ?



Really, this line of argument doesn't make any sense to me.
"xlnx,wdt-enable-once", for example, is a boolean and means
that the watchdog, when enabled, can not be stopped. It defaults
to false, and thus is inherently optional. Making it mandatory
doesn't really add any value.



If the device has been configured with wdt-enable-once=true
and the device tree doesn't have this property then a watchdog daemon
would see it as "false" because it is the default making the system to 
misbehave...

A warning during driver loading could help user to identify the problem.

Making these properties as mandatory and warn where any of them
are not in device tree may be helpful.

Alejandro



50 Aniversario de la Cujae. 

Re: [PATCH 1/7] spi: sunxi: Add Allwinner A10 SPI controller driver

[Mark Brown]

On Sat, Feb 22, 2014 at 10:35:53PM +0100, Maxime Ripard wrote:
> The older Allwinner SoCs (A10, A13, A10s and A20) all have the same SPI
> controller.

Applied, thanks.  Please differentiate between these two devices in the
subject line when sending patches for example by using "sun6i" and
"sun4i".


signature.asc
Description: Digital signature

Re: [PATCH] MTD: atmel_nand: POI fall back is not an issue: change log level

[Brian Norris]

On Wed, Feb 12, 2014 at 12:42:00PM +0100, Alexandre Belloni wrote:
> Small nitpick, subject should read PIO, not POI.

Amended the commit message and pushed to l2-mtd.git. Thanks!

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

YOUR URGENT RESPONSE IS NEEDED

[Mr. Paul Compaoree]

Dear Friend,

I am Mr. Paul Compaoree, the head of file department Manager of Banque
Internationale du Burkina (BIB/UBA) Ouagadougou Burkina Faso. In my
department I discover an  abandoned sum of (US$10.5M) The fund belongs
to our deceased customer who died with his entire family in Iraq War
2006, leaving nobody for the claim and as such, I decided to contact
you to enable us claim the fund. Your share is 40% while 60% for me.
This transaction is 100% risk free.

Then after the money is been transferred into your account, i will
visit your country for an investment under your kind control. A lot of
customers open private accounts with different Banks without the
knowledge of their families and when they die, such money will be lost
to the Bank unless someone comes to claim it. You have to contact my
Bank directly as the real next of kin of this deceased account with
next of kin application form which I will send to you immediately I
hear from you.

 I am waiting for your urgent respond to enable us proceed further for
the transfer.

Yours Faithfully,
Mr. Paul Compaoree
Banque Internationale du Burkina (BIB/UBA) ouagadougou
Burkina Faso.
Tel:+226 65 37 29 22.
NB: The fund is free from drug and laundering related offences.
--
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: [sctp] ef2820a735: -50% netperf Throughput_Mbps

[Fengguang Wu]

Hi Matija,

On Wed, Feb 19, 2014 at 06:06:34PM +0100, Matija Glavinic Pecotic wrote:
> Hello Fengguang,
> 
> On 02/19/2014 02:20 PM, ext Fengguang Wu wrote:
> > Hi Matija,
> > 
> > We noticed the below changes on commit 
> > ef2820a735f74ea60335f8ba3801b844f0cb184d
> > (" net: sctp: Fix a_rwnd/rwnd management to reflect real state of the 
> > receiver's buffer")
> > in netperf SCTP_STREAM tests:
> 
> thanks for the info. Though, I've ran netperf in my environment, with and 
> without patch, and I havent observed any difference.
> 
> Could you please give me information on your environment, how do you invoke 
> netperf, and other details you think I might be interested in to observe 
> problem by myself

I see the same regression on both T410 and NHM EX server. On each test
machine, I'm running (2*nr_logical_cpu) the below command in parallel:

netperf -t SCTP_STREAM -c -C -l 120

Thanks,
Fengguang

> Thanks!
> 
> > cd0f0b95fd2cd2b  ef2820a735f74ea60335f8ba3  
> > ---  -  
> >  8 ~ 0% -50.0%  4 ~ 0%  TOTAL netperf.Throughput_Mbps
> >  54287 ~44%+338.1% 237842 ~48%  TOTAL cpuidle.C1E-NHM.time
> >   12008353 ~12% -56.0%5281848 ~ 0%  TOTAL proc-vmstat.pgalloc_normal
> > 114861 ~ 0% -50.3%  57085 ~ 3%  TOTAL softirqs.NET_RX
> >   12964639 ~11% -55.1%5818663 ~ 0%  TOTAL proc-vmstat.pgfree
> > 866489 ~ 0% -43.3% 491417 ~ 0%  TOTAL proc-vmstat.pgalloc_dma32
> > 119373 ~17% -39.1%  72661 ~ 1%  TOTAL softirqs.SCHED
> >   1985 ~13% -24.3%   1502 ~19%  TOTAL 
> > slabinfo.kmalloc-128.active_objs
> >   2139 ~20% -28.4%   1532 ~ 4%  TOTAL proc-vmstat.nr_alloc_batch
> > 124360 ~33% -31.0%  85748 ~ 2%  TOTAL softirqs.RCU
> >   1977 ~ 9% -18.5%   1610 ~ 9%  TOTAL slabinfo.UDP.active_objs
> >   1977 ~ 9% -18.5%   1610 ~ 9%  TOTAL slabinfo.UDP.num_objs
> >   2066 ~ 6% -12.9%   1800 ~ 7%  TOTAL 
> > slabinfo.kmalloc-128.num_objs
> >   1738 ~10% -18.4%   1418 ~ 9%  TOTAL slabinfo.UDPv6.active_objs
> >   1738 ~10% -18.4%   1418 ~ 9%  TOTAL slabinfo.UDPv6.num_objs
> >923 ~10% -17.7%760 ~ 8%  TOTAL slabinfo.TCPv6.active_objs
> >923 ~10% -17.7%760 ~ 8%  TOTAL slabinfo.TCPv6.num_objs
> >989 ~ 9% -17.1%820 ~ 7%  TOTAL slabinfo.TCP.active_objs
> >989 ~ 9% -17.1%820 ~ 7%  TOTAL slabinfo.TCP.num_objs
> > 398761 ~44% -32.6% 268792 ~ 3%  TOTAL numa-vmstat.node2.numa_hit
> > 389672 ~49% -32.9% 261443 ~ 3%  TOTAL numa-vmstat.node0.numa_hit
> >447 ~ 1% -13.8%385 ~ 0%  TOTAL vmstat.system.cs
> > 
> > Note: the "~ XX%" numbers are stddev percent.
> > 
> >   netperf.Throughput_Mbps
> > 
> >  4 
> > *+-*--*--*--*-*--*--*--*--*--*--*--*-*--*--*--*--*--*--*--*-*--*--*--*
> >|
> > |
> >|
> > |
> >3.5 ++   
> > |
> >|
> > |
> >|
> > |
> >|
> > |
> >  3 ++   
> > |
> >|
> > |
> >|
> > |
> >2.5 ++   
> > |
> >|
> > |
> >|
> > |
> >|
> > |
> >  2 
> > O+-O--O--O--O-O--O--O--O--O--O--O--O-O--O--O--O--O--O--O-+
> > 
> > 
> >  vmstat.system.cs
> > 
> >460 
> > ++*--**--+
> >|   .*...*.. :+  +  *.. 
> > .*
> >450 ++*. .*.*..  : +.*..*.. +*..*..*.. + .*. 
> > |
> >440 *+   :  *   :   *..*   *  **.
> > |
> >|:   : * 
> > |
> >430 ++: :
> > |
> >420 ++: :
> > |
> >|  * 
> > |
> >410 ++  

Re: [PATCH v3 07/11] watchdog: xilinx: Use of_property_read_u32

[Guenter Roeck]

On 02/22/2014 07:52 PM, Alejandro Cabrera wrote:

On 22/2/2014 3:18 PM, Guenter Roeck wrote:

On 02/22/2014 05:08 PM, Alejandro Cabrera wrote:

On 22/2/2014 10:46 AM, Wim Van Sebroeck wrote:

Hi All,


Hi Michal,

On Wed, Feb 12, 2014 at 02:41:21PM +0100, Michal Simek wrote:

Use of_property_read_u32 functions to clean probe function.

Signed-off-by: Michal Simek
Reviewed-by: Guenter Roeck
---

Changes in v3:
- Remove one if checking and use variable directly


Looks good.

Another comment/remark.


-pfreq = (u32 *)of_get_property(pdev->dev.of_node,
-"clock-frequency", NULL);
-
-if (pfreq == NULL) {
+rc = of_property_read_u32(pdev->dev.of_node, "clock-frequency",);
+if (rc) {
  dev_warn(>dev,
   "The watchdog clock frequency cannot be obtained\n");
  no_timeout = true;
  }

-tmptr = (u32 *)of_get_property(pdev->dev.of_node,
-"xlnx,wdt-interval", NULL);
-if (tmptr == NULL) {
+rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-interval",
+ >wdt_interval);
+if (rc) {
  dev_warn(>dev,
   "Parameter \"xlnx,wdt-interval\" not found\n");
  no_timeout = true;
-} else {
-xdev->wdt_interval = *tmptr;
  }

-tmptr = (u32 *)of_get_property(pdev->dev.of_node,
-"xlnx,wdt-enable-once", NULL);
-if (tmptr == NULL) {
+rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-enable-once",
+ _once);
+if (rc)
  dev_warn(>dev,
   "Parameter \"xlnx,wdt-enable-once\" not found\n");
-watchdog_set_nowayout(xilinx_wdt_wdd, true);
-}

All the above properties are optional. Is a warning really
warranted in this case ? I usually associate a warning with
something that is wrong, which is not the case here.

I would encourage you to drop those warnings, but that should be
a separate patch.

I agree with Guenter: these are not really warnings. Seperate patch is thus 
welcome.

Hi

I support Michal intention, I think it is a warning because device tree blob must have 
the "xlnx,wdt-enable-once" property specified in order to allow the system to 
be sure of the real value of this property. In addition to, this warning can be helpful 
to detect a wrong device tree specification.



The dt documentation states that the properties are optional.

Optional properties:
- clock-frequency   : Frequency of clock in Hz
- xlnx,wdt-enable-once  : 0 - Watchdog can be restarted
  1 - Watchdog can be enabled just once
- xlnx,wdt-interval : Watchdog timeout interval in 2^ clock cycles,
 is integer from 8 to 31.

This clearly conflicts with your statement. An optional property
is just that, optional. If it warrants a warning, it must
not be optional. If you claim that not providing the properties
would be "wrong", why are they defined as optional ?

Hi Guenter

I didn't know that these properties was classified as optional...
I think that they should not be, because all xilinx watchog devices (at least 
for microblaze processor)
have these properties defined in theirs MPD files and theirs values can be 
obtained during the
hardware specification to device tree conversion.

What is your definition of "wrong" and "must have" ?

what I mean for "must have" is: if these properties can be obtained
for all xilinx watchdog devices they must be present in the device tree because 
they allows
the system (linux/user) to know exactly how a watchdog device is configured.
Because these properties always can be obtained from hardware design there is no
reason to leave them out from the device tree. This is why I consider that a 
device tree without
these properties should be considered as "wrong" device tree.

How do you expect anyone to know that omitting those
"optional" properties is by some definition "wrong" ?

I'm agree with you.
Maybe these properties shouldn't be optional.
For example suppose that "xlnx,wdt-enable-once" is missing in the device tree,
when a watchdog daemon ask for this property what is the obtained value ?
Independently of this value, why do not warn the user about this missing 
property
when it can always be in the device tree ?



Really, this line of argument doesn't make any sense to me.
"xlnx,wdt-enable-once", for example, is a boolean and means
that the watchdog, when enabled, can not be stopped. It defaults
to false, and thus is inherently optional. Making it mandatory
doesn't really add any value.

Similar, the driver choses defaults for the other values.
If that is incorrect, it should not do it.

Really, something is very fishy here. Either the properties are
optional or they are not. If they are optional, the driver should
accept the fact silently. If they are mandatory, the driver should
act accordingly and bail out if the attributes are not there.

You can not have it both ways. I am close to recommending
that Wim should not accept this driver until that is sorted out.

Guenter

--
To 

memory-barriers.txt again (was Re: [PATCH 4/9] firewire: don't use PREPARE_DELAYED_WORK)

[Stefan Richter]

Hi Paul,

in patch "Documentation/memory-barriers.txt: Downgrade UNLOCK+BLOCK" (sic),
you wrote:
+ Memory operations issued before the LOCK may be completed after the
+ LOCK operation has completed.  An smp_mb__before_spinlock(), combined
+ with a following LOCK, orders prior loads against subsequent stores
+ and stores and prior stores against subsequent stores.  Note that

Is there a "and stores" too many?  Or was one "stores" mistyped and meant
to be something else?  Or what else is meant?

@@ -1677,13 +1681,57 @@ LOCK, and an access following the UNLOCK to happen 
before the UNLOCK, and the
 two accesses can themselves then cross:
 
*A = a;
-   LOCK
-   UNLOCK
+   LOCK M
+   UNLOCK M
*B = b;
 
 may occur as:
 
-   LOCK, STORE *B, STORE *A, UNLOCK
+   LOCK M, STORE *B, STORE *A, UNLOCK M
+
+This same reordering can of course occur if the LOCK and UNLOCK are
+to the same lock variable, but only from the perspective of another
+CPU not holding that lock.

The example says "LOCK M" and "UNLOCK M" (since the patch).  I read
this as LOCK and UNLOCK to the same variable, M.  Why does the
following sentence then say that "this same reordering can... occur
if the LOCK and UNLOCK are to the same lock variable"?  This sentence
would make sense if the example had been about LOCK M, UNLOCK N.

+In short, an UNLOCK followed by a LOCK may -not- be assumed to be a full
+memory barrier because it is possible for a preceding UNLOCK to pass a
+later LOCK from the viewpoint of the CPU, but not from the viewpoint
+of the compiler.  Note that deadlocks cannot be introduced by this
+interchange because if such a deadlock threatened, the UNLOCK would
+simply complete.

So rather than deadlock, "the UNLOCK would simply complete".  But
/why/ does it complete?  It is left unclear (to me at least), why
it would do so.  IOW, what mechanism will make it always proceed
to the UNLOCK?  Without knowing that, it is left entirely unclear
(to me) why the deadlock wouldn't happen.
-- 
Stefan Richter
-=-- --=- =-===
http://arcgraph.de/sr/
--
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: It BOOTS! 3.13.5 that is.

[Ilia Mirkin]

On Sat, Feb 22, 2014 at 8:22 PM, Gene Heskett  wrote:
> But my tv card isn't being found by kaffeine.  It is this card:
>
> 01:08.0 Multimedia video controller: Conexant Systems, Inc. CX23880/1/2/3 PCI 
> Video and Audio Decoder (rev 05)
> Subsystem: pcHDTV Device 3000
> Flags: bus master, medium devsel, latency 32, IRQ 10
> Memory at fb00 (32-bit, non-prefetchable) [size=16M]
> Capabilities: [44] Vital Product Data 
> Capabilities: [4c] Power Management version 2
>
> 01:08.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video 
> and Audio Decoder [MPEG Port] (rev 05)
> Subsystem: pcHDTV Device 3000
> Flags: bus master, medium devsel, latency 32, IRQ 10
> Memory at fa00 (32-bit, non-prefetchable) [size=16M]
> Capabilities: [4c] Power Management version 2
>
> From an lspci
>
> In a make xconfig, I cannot find this specific card in the list of DVB
> front ends.  What modules do I need to make sure are being built?

You're looking for VIDEO_CX88 ("Conexant 2388x (bt878 successor)
support") and its various sub-options (esp CX88_DVB). iirc the
pchdtv3000 had a OR51132 tuner, but right now the config is set to
auto-select a whole bunch of tuners if you have
MEDIA_SUBDRV_AUTOSELECT turned on. Otherwise make sure to select that
tuner device. (Hm, I appear to have both OR51132 and CX22702 enabled,
and I have that same card.)

  -ilia
--
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: Update of file offset on write() etc. is non-atomic with I/O

[Kevin Easton]

On Fri, Feb 21, 2014 at 07:01:31AM +0100, Michael Kerrisk (man-pages) wrote:
> Here's the fulll list from POSIX.1-2008/SUSv4 Section XSI 2.9.7:
> 
> [[
> 2.9.7 Thread Interactions with Regular File Operations
> 
> All of the following functions shall be atomic with respect to each
> other in the effects specified in
> POSIX.1-2008 when they operate on regular files or symbolic links:
> 
> chmod( )
> chown( )
> close( )
> creat( )
> dup2( )
> fchmod( )
> fchmodat( )
> fchown( )
> fchownat( )
> fcntl( )
> fstat( )
> fstatat( )
> ftruncate( )
> lchown( )
> link( )
> linkat( )
> lseek( )
> lstat( )
> open( )
> openat( )
> pread( )
> read( )
> readlink( )
> readlinkat( )
> readv( )
> pwrite( )
> rename( )
> renameat( )
> stat( )
> symlink( )
> symlinkat( )
> truncate( )
> unlink( )
> unlinkat( )
> utime( )
> utimensat( )
> utimes( )
> write( )
> writev( )
> 
> If two threads each call one of these functions, each call shall
> either see all of the specified effects
> of the other call, or none of them.
> ]]
> 
> I'd bet that there's a bunch of violations to be found, but the
> read/write f_pos case is one of the most egregious.
> 
> For example, I got curious about stat() versus rename(). If one
> stat()s a directory() while a subdirectory is being renamed to a new
> name within that directory, does the link count of the parent
> directory ever change--that is, could stat() ever see a changed link
> count in the middle of the rename()? My experiments suggest that it
> can. I suppose it would have to be a very unusual application that
> would be troubled by that, but it does appear to be a violation of
> 2.9.7.

A directory isn't a regular file or symlink, though, so the warranty
would seem to be void in that case.

If you {f}stat() a regular file that is being concurrently renamed() then
the link count shouldn't vary, though.

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

It BOOTS! 3.13.5 that is.

[Gene Heskett]

But my tv card isn't being found by kaffeine.  It is this card:

01:08.0 Multimedia video controller: Conexant Systems, Inc. CX23880/1/2/3 PCI 
Video and Audio Decoder (rev 05)
Subsystem: pcHDTV Device 3000
Flags: bus master, medium devsel, latency 32, IRQ 10
Memory at fb00 (32-bit, non-prefetchable) [size=16M]
Capabilities: [44] Vital Product Data 
Capabilities: [4c] Power Management version 2

01:08.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video 
and Audio Decoder [MPEG Port] (rev 05)
Subsystem: pcHDTV Device 3000
Flags: bus master, medium devsel, latency 32, IRQ 10
Memory at fa00 (32-bit, non-prefetchable) [size=16M]
Capabilities: [4c] Power Management version 2

>From an lspci

In a make xconfig, I cannot find this specific card in the list of DVB 
front ends.  What modules do I need to make sure are being built?

Thanks.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

--
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] ktest: Set CLOSE_CONSOLE_SIGNAL in the kvm.conf

[Satoru Takeuchi]

From: Satoru Takeuchi 

As mentioned at commit 5a5d8e48449, we can't terminate 'virsh console'
with the default signal(INT). So it's better to set CLOSE_CONSOLE_SIGNAL
in the kvm.conf.

Signed-off-by: Satoru Takeuchi 
Cc: Steven Rostedt 
---
 tools/testing/ktest/examples/kvm.conf | 4 
 1 file changed, 4 insertions(+)

diff --git a/tools/testing/ktest/examples/kvm.conf 
b/tools/testing/ktest/examples/kvm.conf
index 831c7c5..40356f7 100644
--- a/tools/testing/ktest/examples/kvm.conf
+++ b/tools/testing/ktest/examples/kvm.conf
@@ -10,6 +10,10 @@ MACHINE = Guest
 # Use virsh to read the serial console of the guest
 CONSOLE =  virsh console ${MACHINE}
 
+# Use SIGILL to terminate virsh console. We can't kill virsh console
+# by the default signal, SIGINT.
+CLOSE_CONSOLE_SIGNAL = KILL
+
 #*#
 # This part is the same as test.conf  #
 #*#
-- 
1.8.4.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/

[PATCH RESEND] x86: iosf_mbi: Provide dummy functions if CONFIG_IOSF_MBI not set

[David E. Box]

From: "David E. Box" 

Add iosf_mbi_available function for loadable modules.
Add dummy functions to prevent symbol lookup errors on loadable modules.
Clarify that the write opcode is to be used for iosf_mbi_modify().
Changes Kconfig for IOSF_MBI to default built-in.

Signed-off-by: David E. Box 
---
 arch/x86/Kconfig|2 +-
 arch/x86/include/asm/iosf_mbi.h |   39 +++
 arch/x86/kernel/iosf_mbi.c  |6 ++
 3 files changed, 42 insertions(+), 5 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index d3b1f8b..e25baf1 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2385,7 +2385,7 @@ config X86_DMA_REMAP
depends on STA2X11
 
 config IOSF_MBI
-   bool
+   def_bool y
depends on PCI
---help---
  To be selected by modules requiring access to the Intel OnChip System
diff --git a/arch/x86/include/asm/iosf_mbi.h b/arch/x86/include/asm/iosf_mbi.h
index 8e71c79..1c93591 100644
--- a/arch/x86/include/asm/iosf_mbi.h
+++ b/arch/x86/include/asm/iosf_mbi.h
@@ -5,6 +5,8 @@
 #ifndef IOSF_MBI_SYMS_H
 #define IOSF_MBI_SYMS_H
 
+#ifdef CONFIG_IOSF_MBI
+
 #define MBI_MCR_OFFSET 0xD0
 #define MBI_MDR_OFFSET 0xD4
 #define MBI_MCRX_OFFSET0xD8
@@ -50,6 +52,8 @@
 #define BT_MBI_PCIE_READ   0x00
 #define BT_MBI_PCIE_WRITE  0x01
 
+extern bool iosf_mbi_available(void);
+
 /**
  * iosf_mbi_read() - MailBox Interface read command
  * @port:  port indicating subunit being accessed
@@ -60,7 +64,7 @@
  * Locking is handled by spinlock - cannot sleep.
  * Return: Nonzero on error
  */
-int iosf_mbi_read(u8 port, u8 opcode, u32 offset, u32 *mdr);
+extern int iosf_mbi_read(u8 port, u8 opcode, u32 offset, u32 *mdr);
 
 /**
  * iosf_mbi_write() - MailBox unmasked write command
@@ -72,19 +76,46 @@ int iosf_mbi_read(u8 port, u8 opcode, u32 offset, u32 *mdr);
  * Locking is handled by spinlock - cannot sleep.
  * Return: Nonzero on error
  */
-int iosf_mbi_write(u8 port, u8 opcode, u32 offset, u32 mdr);
+extern int iosf_mbi_write(u8 port, u8 opcode, u32 offset, u32 mdr);
 
 /**
  * iosf_mbi_modify() - MailBox masked write command
  * @port:  port indicating subunit being accessed
- * @opcode:port specific read or write opcode
+ * @opcode:port specific write opcode
  * @offset:register address offset
  * @mdr:   register data being modified
  * @mask:  mask indicating bits in mdr to be modified
  *
+ * Use write opcode for this function.
  * Locking is handled by spinlock - cannot sleep.
  * Return: Nonzero on error
  */
-int iosf_mbi_modify(u8 port, u8 opcode, u32 offset, u32 mdr, u32 mask);
+extern int iosf_mbi_modify(u8 port, u8 opcode, u32 offset, u32 mdr, u32 mask);
+
+#else /* CONFIG_IOSF_MBI is not enabled */
+static inline
+bool iosf_mbi_available(void)
+{
+   return false;
+}
+
+static inline
+int iosf_mbi_read(u8 port, u8 opcode, u32 offset, u32 *mdr)
+{
+   return 0;
+}
+
+static inline
+int iosf_mbi_write(u8 port, u8 opcode, u32 offset, u32 mdr)
+{
+   return 0;
+}
+
+static inline
+int iosf_mbi_modify(u8 port, u8 opcode, u32 offset, u32 mdr, u32 mask)
+{
+   return 0;
+}
+#endif /* CONFIG_IOSF_MBI */
 
 #endif /* IOSF_MBI_SYMS_H */
diff --git a/arch/x86/kernel/iosf_mbi.c b/arch/x86/kernel/iosf_mbi.c
index c3aae66..d3803c6 100644
--- a/arch/x86/kernel/iosf_mbi.c
+++ b/arch/x86/kernel/iosf_mbi.c
@@ -177,6 +177,12 @@ int iosf_mbi_modify(u8 port, u8 opcode, u32 offset, u32 
mdr, u32 mask)
 }
 EXPORT_SYMBOL(iosf_mbi_modify);
 
+bool iosf_mbi_available(void)
+{
+   return mbi_pdev;
+}
+EXPORT_SYMBOL(iosf_mbi_available);
+
 static int iosf_mbi_probe(struct pci_dev *pdev,
  const struct pci_device_id *unused)
 {
-- 
1.7.10.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 v3 07/11] watchdog: xilinx: Use of_property_read_u32

[Alejandro Cabrera]

On 22/2/2014 3:18 PM, Guenter Roeck wrote:

On 02/22/2014 05:08 PM, Alejandro Cabrera wrote:

On 22/2/2014 10:46 AM, Wim Van Sebroeck wrote:

Hi All,


Hi Michal,

On Wed, Feb 12, 2014 at 02:41:21PM +0100, Michal Simek wrote:

Use of_property_read_u32 functions to clean probe function.

Signed-off-by: Michal Simek
Reviewed-by: Guenter Roeck
---

Changes in v3:
- Remove one if checking and use variable directly


Looks good.

Another comment/remark.


-pfreq = (u32 *)of_get_property(pdev->dev.of_node,
-"clock-frequency", NULL);
-
-if (pfreq == NULL) {
+rc = of_property_read_u32(pdev->dev.of_node, 
"clock-frequency",);

+if (rc) {
  dev_warn(>dev,
   "The watchdog clock frequency cannot be obtained\n");
  no_timeout = true;
  }

-tmptr = (u32 *)of_get_property(pdev->dev.of_node,
-"xlnx,wdt-interval", NULL);
-if (tmptr == NULL) {
+rc = of_property_read_u32(pdev->dev.of_node, 
"xlnx,wdt-interval",

+ >wdt_interval);
+if (rc) {
  dev_warn(>dev,
   "Parameter \"xlnx,wdt-interval\" not found\n");
  no_timeout = true;
-} else {
-xdev->wdt_interval = *tmptr;
  }

-tmptr = (u32 *)of_get_property(pdev->dev.of_node,
-"xlnx,wdt-enable-once", NULL);
-if (tmptr == NULL) {
+rc = of_property_read_u32(pdev->dev.of_node, 
"xlnx,wdt-enable-once",

+ _once);
+if (rc)
  dev_warn(>dev,
   "Parameter \"xlnx,wdt-enable-once\" not found\n");
-watchdog_set_nowayout(xilinx_wdt_wdd, true);
-}

All the above properties are optional. Is a warning really
warranted in this case ? I usually associate a warning with
something that is wrong, which is not the case here.

I would encourage you to drop those warnings, but that should be
a separate patch.
I agree with Guenter: these are not really warnings. Seperate patch 
is thus welcome.

Hi

I support Michal intention, I think it is a warning because device 
tree blob must have the "xlnx,wdt-enable-once" property specified in 
order to allow the system to be sure of the real value of this 
property. In addition to, this warning can be helpful to detect a 
wrong device tree specification.




The dt documentation states that the properties are optional.

Optional properties:
- clock-frequency   : Frequency of clock in Hz
- xlnx,wdt-enable-once  : 0 - Watchdog can be restarted
  1 - Watchdog can be enabled just once
- xlnx,wdt-interval : Watchdog timeout interval in 2^ clock 
cycles,

 is integer from 8 to 31.

This clearly conflicts with your statement. An optional property
is just that, optional. If it warrants a warning, it must
not be optional. If you claim that not providing the properties
would be "wrong", why are they defined as optional ?

Hi Guenter

I didn't know that these properties was classified as optional...
I think that they should not be, because all xilinx watchog devices (at 
least for microblaze processor)
have these properties defined in theirs MPD files and theirs values can 
be obtained during the

hardware specification to device tree conversion.

What is your definition of "wrong" and "must have" ?

what I mean for "must have" is: if these properties can be obtained
for all xilinx watchdog devices they must be present in the device tree 
because they allows

the system (linux/user) to know exactly how a watchdog device is configured.
Because these properties always can be obtained from hardware design 
there is no
reason to leave them out from the device tree. This is why I consider 
that a device tree without

these properties should be considered as "wrong" device tree.

How do you expect anyone to know that omitting those
"optional" properties is by some definition "wrong" ?

I'm agree with you.
Maybe these properties shouldn't be optional.
For example suppose that "xlnx,wdt-enable-once" is missing in the device 
tree,

when a watchdog daemon ask for this property what is the obtained value ?
Independently of this value, why do not warn the user about this missing 
property

when it can always be in the device tree ?

Regards
Alejandro




50 Aniversario de la Cujae. Inaugurada por Fidel el 2 de diciembre de 1964  
http://cujae.edu.cu


--
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 0/5] arch: atomic rework

[Paul E. McKenney]

On Sat, Feb 22, 2014 at 01:53:30PM -0800, Linus Torvalds wrote:
> On Sat, Feb 22, 2014 at 10:53 AM, Torvald Riegel  wrote:
> >
> > Stating that (1) "the standard is wrong" and (2) that you think that
> > mo_consume semantics are not good is two different things.
> 
> I do agree. They are two independent things.
> 
> I think the standard is wrong, because it's overly complex, hard to
> understand, and nigh unimplementable. As shown by the bugzilla
> example, "carries a dependency" encompasses things that are *not* just
> synchronizing things just through a pointer, and as a result it's
> actually very complicated, since they could have been optimized away,
> or done in non-local code that wasn't even aware of the dependency
> carrying.
> 
> That said, I'm reconsidering my suggested stricter semantics, because
> for RCU we actually do want to test the resulting pointer against NULL
> _without_ any implied serialization.
> 
> So I still feel that the standard as written is fragile and confusing
> (and the bugzilla entry pretty much proves that it is also practically
> unimplementable as written), but strengthening the serialization may
> be the wrong thing.
> 
> Within the kernel, the RCU use for this is literally purely about
> loading a pointer, and doing either:
> 
>  - testing its value against NULL (without any implied synchronization at all)
> 
>  - using it as a pointer to an object, and expecting that any accesses
> to that object are ordered wrt the consuming load.

Agreed, by far the most frequent use is "->" to dereference and assignment
to store into a local variable.  The other operations where the kernel
expects ordering to be maintained are:

o   Bitwise "&" to strip off low-order bits.  The FIB tree does
this, for example in fib_table_lookup() in net/ipv4/fib_trie.c.
The low-order bit is used to distinguish internal nodes from
leaves -- nodes and leaves are different types of structures.
(There are a few others.)

o   Uses "?:" to substitute defaults in case of NULL pointers,
but ordering must be maintained in the non-default case.
Most, perhaps all, of these could be converted to "if" should
"?:" prove problematic.

o   Addition and subtraction to adjust both pointers to and indexes
into RCU-protected arrays.  There are not that many indexes,
and they could be converted to pointers, but the addition and
subtraction looks necessary in a some cases.

o   Array indexing.  The value from rcu_dereference() is used both
before and inside the "[]", interestingly enough.

o   Casts along with unary "&" and "*".

That said, I did not see any code that dependended on ordering through
the function-call "()", boolean complement "!", comparison (only "=="
and "!="), logical operators ("&&" and "||"), and the "*", "/", and "%"
arithmetic operators.

> So I actually have a suggested *very* different model that people
> might find more acceptable.
> 
> How about saying that the result of a "atomic_read(, mo_consume)" is
> required to be a _restricted_ pointer type, and that the consume
> ordering guarantees the ordering between that atomic read and the
> accesses to the object that the pointer points to.
> 
> No "carries a dependency", no nothing.

In the case of arrays, the object that the pointer points to is
considered to be the full array, right?

> Now, there's two things to note in there:
> 
>  - the "restricted pointer" part means that the compiler does not need
> to worry about serialization to that object through other possible
> pointers - we have basically promised that the *only* pointer to that
> object comes from the mo_consume. So that part makes it clear that the
> "consume" ordering really only is valid wrt that particular pointer
> load.

That could work, though there are some cases where a multi-linked
structure is made visible using a single rcu_assign_pointer(), and
rcu_dereference() is used only for the pointer leading to that
multi-linked structure, not for the pointers among the elements
making up that structure.  One way to handle this would be to
require rcu_dereference() to be used within the structure an well
as upon first traversal to the structure.

>  - the "to the object that the pointer points to" makes it clear that
> you can't use the pointer to generate arbitrary other values and claim
> to serialize that way.
> 
> IOW, with those alternate semantics, that gcc bugzilla example is
> utterly bogus, and a compiler can ignore it, because while it tries to
> synchronize through the "dependency chain" created with that "p-i+i"
> expression, that is completely irrelevant when you use the above rules
> instead.
> 
> In the bugzilla example, the object that "*(p-i+i)" accesses isn't
> actually the object pointed to by the pointer, so no serialization is
> implied. And if it actually *were* to be the same object, because "p"
> happens to have the same value as "i", then the 

Re: [RFCv1 4/4] mfd: twl4030-madc: Move driver to drivers/iio/adc

[Sebastian Reichel]

On Sat, Feb 22, 2014 at 12:47:03PM +, Jonathan Cameron wrote:
> On 14/02/14 18:46, Sebastian Reichel wrote:
> >This is a driver for an A/D converter, which belongs into
> >drivers/iio/adc.
> >
> >Signed-off-by: Sebastian Reichel 
> 
> Being inherently lazy I'm going to review this patch as it gives the complete
> driver rather than taking on the conversion patch directly!

OK.

> It's a long shot, but are there any docs freely available for this part?

There is documentation on Texas Instrument's website for TPS65950,
which is supposed to be very similar to the TWL4030 and contains a
section about the MADC module:

http://www.ti.com/lit/gpn/tps65950

> Obviously that may well mean that some of my comments apply to the driver
> in general rather than the changes you've made.  Please feel free to
> pick and choose!

Having skipped over your comments I guess 70% are about the driver
in general, but I can add another patch to the patchset, which fixes
the driver style.

> I'd like ideally to see a little more generic tidying up in this driver.
> As you'll notice inline I get irritated at having lots and lots of error
> messages.  Still that's personal preference but I felt a lot more justified
> in moaning after finding one that was incorrect ;)
> 
> There is also a bit of functionality in here that I'm not sure is ever
> used (the request callback functions).  It complicates the code so if no
> using it I'd be tempted to drop it.

I think the optimal workflow is:

1. convert madc driver to IIO
2. convert twl4030-madc-battery driver to IIO API
3. convert rx51-battery to IIO API
4. convert twl4030-madc-hwmon to IIO API / deprecate it
5. remove old in-kernel ABI from madc
6. cleanup/simplify madc

I guess its much simpler to do the driver cleanup/simplification
once we can get rid of the old API.

> It's nice in a way that the driver before your conversion provided only
> a very limited and in kernel interface given we don't have to hang on to
> any old ABI elements.
> 
> >---
> >  drivers/iio/adc/Kconfig|  10 +
> >  drivers/iio/adc/Makefile   |   1 +
> >  drivers/iio/adc/twl4030-madc.c | 922 
> > +
> >  drivers/mfd/Kconfig|  10 -
> >  drivers/mfd/Makefile   |   1 -
> >  drivers/mfd/twl4030-madc.c | 922 
> > -
> >  6 files changed, 933 insertions(+), 933 deletions(-)
> >  create mode 100644 drivers/iio/adc/twl4030-madc.c
> >  delete mode 100644 drivers/mfd/twl4030-madc.c
> >
> >diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> >index 2209f28..427f75c 100644
> >--- a/drivers/iio/adc/Kconfig
> >+++ b/drivers/iio/adc/Kconfig
> >@@ -183,6 +183,16 @@ config TI_AM335X_ADC
> >   Say yes here to build support for Texas Instruments ADC
> >   driver which is also a MFD client.
> >
> >+config TWL4030_MADC
> >+tristate "TWL4030 MADC (Monitoring A/D Converter)"
> >+depends on TWL4030_CORE
> >+help
> >+This driver provides support for Triton TWL4030-MADC. The
> >+driver supports both RT and SW conversion methods.
> >+
> >+This driver can also be built as a module. If so, the module will be
> >+called twl4030-madc.
> >+
> >  config TWL6030_GPADC
> > tristate "TWL6030 GPADC (General Purpose A/D Converter) Support"
> > depends on TWL4030_CORE
> >diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> >index ba9a10a..9acf2df 100644
> >--- a/drivers/iio/adc/Makefile
> >+++ b/drivers/iio/adc/Makefile
> >@@ -20,5 +20,6 @@ obj-$(CONFIG_MCP3422) += mcp3422.o
> >  obj-$(CONFIG_NAU7802) += nau7802.o
> >  obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
> >  obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
> >+obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
> >  obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
> >  obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
> >diff --git a/drivers/iio/adc/twl4030-madc.c b/drivers/iio/adc/twl4030-madc.c
> >new file mode 100644
> >index 000..4da61c4
> >--- /dev/null
> >+++ b/drivers/iio/adc/twl4030-madc.c
> >@@ -0,0 +1,922 @@
> >+/*
> >+ *
> >+ * TWL4030 MADC module driver-This driver monitors the real time
> >+ * conversion of analog signals like battery temperature,
> >+ * battery type, battery level etc.
> >+ *
> >+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
> >+ * J Keerthy 
> >+ *
> >+ * Based on twl4030-madc.c
> >+ * Copyright (C) 2008 Nokia Corporation
> >+ * Mikko Ylinen 
> >+ *
> >+ * Amit Kucheria 
> >+ *
> >+ * This program is free software; you can redistribute it and/or
> >+ * modify it under the terms of the GNU General Public License
> >+ * version 2 as published by the Free Software Foundation.
> >+ *
> >+ * This program is distributed in the hope that it will be useful, but
> >+ * WITHOUT ANY WARRANTY; without even the implied warranty of
> >+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> >+ * General Public License for more details.
> >+ *
> >+ * You 

Re: [PATCH 3.13 35/99] tty: Set correct tty name in active sysfs attribute

[Ray Strode]

Hi,

(resending because my phone tried to send the reply as html mail and
it got rejected)

On Sat, Feb 22, 2014 at 9:27 AM, David Herrmann  wrote:
> > How about this:
>
> +   driver = cs[i]->device(cs[i], );
> +/* special case for tty0 which must not be resolved */
> +   if (driver && (index > 0 || cs[i]->major != TTY_MAJOR)) {
> +   count += tty_line_name(driver, index, buf + count);
> +   count += sprintf(buf + count, "%c", i ? ' ':'\n');
> +   } else
> +   count += sprintf(buf + count, "%s%d%c",
> +name, index, i ? ' ':'\n');
Assuming I'm reading the code correctly, I don't think that will work.
 Index will be rewritten from 0 to fg_console (which I suppose is
going to be 1) after the device vfunc is called.

--Ray
--
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] improve_stack: make stack dump output useful again

[Sasha Levin]

Right now when people try to report issues in the kernel they send stack
dumps to eachother, which looks something like this:

[6.906437]  [] ? backtrace_test_irq_callback+0x20/0x20
[6.907121]  [] dump_stack+0x52/0x7f
[6.907640]  [] backtrace_regression_test+0x38/0x110
[6.908281]  [] ? proc_create_data+0xa0/0xd0
[6.908870]  [] ? proc_modules_init+0x22/0x22
[6.909480]  [] do_one_initcall+0xc2/0x1e0
[...]

However, most of the text you get is pure garbage.

The only useful thing above is the function name. Due to the amount of
different kernel code versions and various configurations being used, the
kernel address and the offset into the function are not really helpful in
determining where the problem actually occured.

Too often the result of someone looking at a stack dump is asking the person
who sent it for a translation for one or more 'addr2line' translations. Which
slows down the entire process of debugging the issue (and really annoying).

The "improve_stack" script (wanted: better name) is an attempt to make the
output more useful and easy to work with by translating all kernel addresses
in the stack dump into line numbers. Which means that the stack dump we saw
before would look like this:

[6.906437]  [] ? 
backtrace_test_irq_callback+0x20/0x20
[6.907121]  [] dump_stack+0x52/0x7f
[6.907640]  [] 
backtrace_regression_test+0x38/0x110
[6.908281]  [] ? proc_create_data+0xa0/0xd0
[6.908870]  [] ? proc_modules_init+0x22/0x22
[6.909480]  [] do_one_initcall+0xc2/0x1e0

It's pretty obvious why this is better than the previous stack dump before.

Usage is pretty simple:

./improve_stack.sh [vmlinux] [base path]

Where vmlinux is the vmlinux to extract line numbers from and base path is
the path that points to the root of the build tree, for example:

./improve_stack.sh vmlinux /home/sasha/linux/

And the stack trace should be piped through it (I, for example, just pipe
the output of the serial console of my KVM test box through it).

Signed-off-by: Sasha Levin 
---
 scripts/improve_stack.sh |   32 
 1 files changed, 32 insertions(+), 0 deletions(-)
 create mode 100755 scripts/improve_stack.sh

diff --git a/scripts/improve_stack.sh b/scripts/improve_stack.sh
new file mode 100755
index 000..03a4a90
--- /dev/null
+++ b/scripts/improve_stack.sh
@@ -0,0 +1,32 @@
+#!/bin/bash
+
+if [ $# != "2" ]; then
+   echo "Usage:"
+   echo "  $0 [vmlinux] [base path]"
+   exit 1
+fi
+
+vmlinux=$1
+basepath=$2
+
+while read line; do
+   # Let's see if we have an address in the line
+   if [[ $line =~ \[\<([^]]+)\>\]  ]]; then
+   # Translate address to line numbers
+   code=`addr2line -i -e $vmlinux ${BASH_REMATCH[1]}`
+
+   # Strip useless base path
+   code=${code//$basepath/""}
+
+   # In the case of inlines, move everything to same line
+   code=${code//$'\n'/' '}
+
+   # Replace old address with pretty line numbers
+   newline=${line//${BASH_REMATCH[1]}/$code}
+
+   echo "$newline"
+   else
+   # Nothing special in this line, show it as is
+   echo "$line"
+   fi
+done
-- 
1.7.2.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 RFC 1/2] net: macb: Check DMA mappings for error

[Ben Hutchings]

On Fri, 2014-02-21 at 11:30 -0800, Soren Brinkmann wrote:
[...]
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -632,11 +632,16 @@ static void gem_rx_refill(struct macb *bp)
>  "Unable to allocate sk_buff\n");
>   break;
>   }
> - bp->rx_skbuff[entry] = skb;
>  
>   /* now fill corresponding descriptor entry */
>   paddr = dma_map_single(>pdev->dev, skb->data,
>  bp->rx_buffer_size, 
> DMA_FROM_DEVICE);
> + if (dma_mapping_error(>pdev->dev, paddr)) {
> + dev_kfree_skb(skb);
> + break;
> + }
> +
> + bp->rx_skbuff[entry] = skb;

This bit looks good.

>   if (entry == RX_RING_SIZE - 1)
>   paddr |= MACB_BIT(RX_WRAP);
> @@ -1040,6 +1045,10 @@ static int macb_start_xmit(struct sk_buff *skb, struct 
> net_device *dev)
>   netdev_vdbg(bp->dev, "Allocated ring entry %u\n", entry);
>   mapping = dma_map_single(>pdev->dev, skb->data,
>len, DMA_TO_DEVICE);
> + if (dma_mapping_error(>pdev->dev, mapping)) {
> + dev_kfree_skb(skb);

You need to unlock bp->lock before returning.  Also, I think this should
be kfree_skb(), as that can be observed through dropwatch whereas
dev_kfree_skb() is completely silent.

Ben.

> + return NETDEV_TX_OK;
> + }
>  
>   tx_skb = >tx_skb[entry];
>   tx_skb->skb = skb;

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken.


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

[GIT Pull] timer fixes for 3.14

[Thomas Gleixner]

Linus,

please pull the latest timers-urgent-for-linus git tree from:

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

Short summary:

  * Serialize the registration of a new sched_clock in the
currently ARM only generic sched_clock facilty to avoid
sched_clock havoc

Thanks,

tglx

-->
Stephen Boyd (1):
  sched_clock: Prevent callers from seeing half-updated data


 kernel/time/sched_clock.c |   46 -
 1 file changed, 29 insertions(+), 17 deletions(-)

diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index 0abb364..4d23dc4 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -116,20 +116,42 @@ static enum hrtimer_restart sched_clock_poll(struct 
hrtimer *hrt)
 void __init sched_clock_register(u64 (*read)(void), int bits,
 unsigned long rate)
 {
+   u64 res, wrap, new_mask, new_epoch, cyc, ns;
+   u32 new_mult, new_shift;
+   ktime_t new_wrap_kt;
unsigned long r;
-   u64 res, wrap;
char r_unit;
 
if (cd.rate > rate)
return;
 
WARN_ON(!irqs_disabled());
-   read_sched_clock = read;
-   sched_clock_mask = CLOCKSOURCE_MASK(bits);
-   cd.rate = rate;
 
/* calculate the mult/shift to convert counter ticks to ns. */
-   clocks_calc_mult_shift(, , rate, NSEC_PER_SEC, 3600);
+   clocks_calc_mult_shift(_mult, _shift, rate, NSEC_PER_SEC, 3600);
+
+   new_mask = CLOCKSOURCE_MASK(bits);
+
+   /* calculate how many ns until we wrap */
+   wrap = clocks_calc_max_nsecs(new_mult, new_shift, 0, new_mask);
+   new_wrap_kt = ns_to_ktime(wrap - (wrap >> 3));
+
+   /* update epoch for new counter and update epoch_ns from old counter*/
+   new_epoch = read();
+   cyc = read_sched_clock();
+   ns = cd.epoch_ns + cyc_to_ns((cyc - cd.epoch_cyc) & sched_clock_mask,
+ cd.mult, cd.shift);
+
+   raw_write_seqcount_begin();
+   read_sched_clock = read;
+   sched_clock_mask = new_mask;
+   cd.rate = rate;
+   cd.wrap_kt = new_wrap_kt;
+   cd.mult = new_mult;
+   cd.shift = new_shift;
+   cd.epoch_cyc = new_epoch;
+   cd.epoch_ns = ns;
+   raw_write_seqcount_end();
 
r = rate;
if (r >= 400) {
@@ -141,22 +163,12 @@ void __init sched_clock_register(u64 (*read)(void), int 
bits,
} else
r_unit = ' ';
 
-   /* calculate how many ns until we wrap */
-   wrap = clocks_calc_max_nsecs(cd.mult, cd.shift, 0, sched_clock_mask);
-   cd.wrap_kt = ns_to_ktime(wrap - (wrap >> 3));
-
/* calculate the ns resolution of this counter */
-   res = cyc_to_ns(1ULL, cd.mult, cd.shift);
+   res = cyc_to_ns(1ULL, new_mult, new_shift);
+
pr_info("sched_clock: %u bits at %lu%cHz, resolution %lluns, wraps 
every %lluns\n",
bits, r, r_unit, res, wrap);
 
-   update_sched_clock();
-
-   /*
-* Ensure that sched_clock() starts off at 0ns
-*/
-   cd.epoch_ns = 0;
-
/* Enable IRQ time accounting if we have a fast enough sched_clock */
if (irqtime > 0 || (irqtime == -1 && rate >= 100))
enable_sched_clock_irqtime();
--
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] x86 fixes for 3.14

[Thomas Gleixner]

Linus,

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

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

This pull request provides:

 * A bugfix which prevents a divide by 0 panic when the in 3.14
   newly introduced try_msr_calibrate_tsc() fails.

 * The enablement of the Baytrail platform to utilize the new
   fangled msr based calibration

Thanks,

tglx

-->
Mika Westerberg (1):
  x86: tsc: Add missing Baytrail frequency to the table

Thomas Gleixner (1):
  x86, tsc: Fallback to normal calibration if fast MSR calibration fails


 arch/x86/include/asm/tsc.h |2 +-
 arch/x86/kernel/tsc.c  |7 ++-
 arch/x86/kernel/tsc_msr.c  |   30 +++---
 3 files changed, 18 insertions(+), 21 deletions(-)

diff --git a/arch/x86/include/asm/tsc.h b/arch/x86/include/asm/tsc.h
index 57ae63c..94605c0 100644
--- a/arch/x86/include/asm/tsc.h
+++ b/arch/x86/include/asm/tsc.h
@@ -66,6 +66,6 @@ extern void tsc_save_sched_clock_state(void);
 extern void tsc_restore_sched_clock_state(void);
 
 /* MSR based TSC calibration for Intel Atom SoC platforms */
-int try_msr_calibrate_tsc(unsigned long *fast_calibrate);
+unsigned long try_msr_calibrate_tsc(void);
 
 #endif /* _ASM_X86_TSC_H */
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index acb3b60..cfbe99f 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -653,13 +653,10 @@ unsigned long native_calibrate_tsc(void)
 
/* Calibrate TSC using MSR for Intel Atom SoCs */
local_irq_save(flags);
-   i = try_msr_calibrate_tsc(_calibrate);
+   fast_calibrate = try_msr_calibrate_tsc();
local_irq_restore(flags);
-   if (i >= 0) {
-   if (i == 0)
-   pr_warn("Fast TSC calibration using MSR failed\n");
+   if (fast_calibrate)
return fast_calibrate;
-   }
 
local_irq_save(flags);
fast_calibrate = quick_pit_calibrate();
diff --git a/arch/x86/kernel/tsc_msr.c b/arch/x86/kernel/tsc_msr.c
index 8b5434f..92ae6ac 100644
--- a/arch/x86/kernel/tsc_msr.c
+++ b/arch/x86/kernel/tsc_msr.c
@@ -53,7 +53,7 @@ static struct freq_desc freq_desc_tables[] = {
/* TNG */
{ 6, 0x4a, 1, { 0, FREQ_100, FREQ_133, 0, 0, 0, 0, 0 } },
/* VLV2 */
-   { 6, 0x37, 1, { 0, FREQ_100, FREQ_133, FREQ_166, 0, 0, 0, 0 } },
+   { 6, 0x37, 1, { FREQ_83, FREQ_100, FREQ_133, FREQ_166, 0, 0, 0, 0 } },
/* ANN */
{ 6, 0x5a, 1, { FREQ_83, FREQ_100, FREQ_133, FREQ_100, 0, 0, 0, 0 } },
 };
@@ -77,21 +77,18 @@ static int match_cpu(u8 family, u8 model)
 
 /*
  * Do MSR calibration only for known/supported CPUs.
- * Return values:
- * -1: CPU is unknown/unsupported for MSR based calibration
- *  0: CPU is known/supported, but calibration failed
- *  1: CPU is known/supported, and calibration succeeded
+ *
+ * Returns the calibration value or 0 if MSR calibration failed.
  */
-int try_msr_calibrate_tsc(unsigned long *fast_calibrate)
+unsigned long try_msr_calibrate_tsc(void)
 {
-   int cpu_index;
u32 lo, hi, ratio, freq_id, freq;
+   unsigned long res;
+   int cpu_index;
 
cpu_index = match_cpu(boot_cpu_data.x86, boot_cpu_data.x86_model);
if (cpu_index < 0)
-   return -1;
-
-   *fast_calibrate = 0;
+   return 0;
 
if (freq_desc_tables[cpu_index].msr_plat) {
rdmsr(MSR_PLATFORM_INFO, lo, hi);
@@ -103,7 +100,7 @@ int try_msr_calibrate_tsc(unsigned long *fast_calibrate)
pr_info("Maximum core-clock to bus-clock ratio: 0x%x\n", ratio);
 
if (!ratio)
-   return 0;
+   goto fail;
 
/* Get FSB FREQ ID */
rdmsr(MSR_FSB_FREQ, lo, hi);
@@ -112,16 +109,19 @@ int try_msr_calibrate_tsc(unsigned long *fast_calibrate)
pr_info("Resolved frequency ID: %u, frequency: %u KHz\n",
freq_id, freq);
if (!freq)
-   return 0;
+   goto fail;
 
/* TSC frequency = maximum resolved freq * maximum resolved bus ratio */
-   *fast_calibrate = freq * ratio;
-   pr_info("TSC runs at %lu KHz\n", *fast_calibrate);
+   res = freq * ratio;
+   pr_info("TSC runs at %lu KHz\n", res);
 
 #ifdef CONFIG_X86_LOCAL_APIC
lapic_timer_frequency = (freq * 1000) / HZ;
pr_info("lapic_timer_frequency = %d\n", lapic_timer_frequency);
 #endif
+   return res;
 
-   return 1;
+fail:
+   pr_warn("Fast TSC calibration using MSR failed\n");
+   return 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/

[GIT pull] irq fixes for 3.14

[Thomas Gleixner]

Linus,

please pull the latest irq-urgent-for-linus git tree from:

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

We present you herewith:

 * Another four fixlets to tame the ARM orion irq chip

Thanks,

tglx

-->
Andrew Lunn (1):
  irqchip: orion: Fix getting generic chip pointer.

Sebastian Hesselbarth (3):
  irqchip: orion: clear bridge cause register on init
  irqchip: orion: use handle_edge_irq on bridge irqs
  irqchip: orion: clear stale interrupts in irq_startup


 drivers/irqchip/irq-orion.c |   22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-orion.c b/drivers/irqchip/irq-orion.c
index e51d400..8e41be6 100644
--- a/drivers/irqchip/irq-orion.c
+++ b/drivers/irqchip/irq-orion.c
@@ -111,7 +111,8 @@ IRQCHIP_DECLARE(orion_intc, "marvell,orion-intc", 
orion_irq_init);
 static void orion_bridge_irq_handler(unsigned int irq, struct irq_desc *desc)
 {
struct irq_domain *d = irq_get_handler_data(irq);
-   struct irq_chip_generic *gc = irq_get_domain_generic_chip(d, irq);
+
+   struct irq_chip_generic *gc = irq_get_domain_generic_chip(d, 0);
u32 stat = readl_relaxed(gc->reg_base + ORION_BRIDGE_IRQ_CAUSE) &
   gc->mask_cache;
 
@@ -123,6 +124,19 @@ static void orion_bridge_irq_handler(unsigned int irq, 
struct irq_desc *desc)
}
 }
 
+/*
+ * Bridge IRQ_CAUSE is asserted regardless of IRQ_MASK register.
+ * To avoid interrupt events on stale irqs, we clear them before unmask.
+ */
+static unsigned int orion_bridge_irq_startup(struct irq_data *d)
+{
+   struct irq_chip_type *ct = irq_data_get_chip_type(d);
+
+   ct->chip.irq_ack(d);
+   ct->chip.irq_unmask(d);
+   return 0;
+}
+
 static int __init orion_bridge_irq_init(struct device_node *np,
struct device_node *parent)
 {
@@ -143,7 +157,7 @@ static int __init orion_bridge_irq_init(struct device_node 
*np,
}
 
ret = irq_alloc_domain_generic_chips(domain, nrirqs, 1, np->name,
-handle_level_irq, clr, 0, IRQ_GC_INIT_MASK_CACHE);
+handle_edge_irq, clr, 0, IRQ_GC_INIT_MASK_CACHE);
if (ret) {
pr_err("%s: unable to alloc irq domain gc\n", np->name);
return ret;
@@ -176,12 +190,14 @@ static int __init orion_bridge_irq_init(struct 
device_node *np,
 
gc->chip_types[0].regs.ack = ORION_BRIDGE_IRQ_CAUSE;
gc->chip_types[0].regs.mask = ORION_BRIDGE_IRQ_MASK;
+   gc->chip_types[0].chip.irq_startup = orion_bridge_irq_startup;
gc->chip_types[0].chip.irq_ack = irq_gc_ack_clr_bit;
gc->chip_types[0].chip.irq_mask = irq_gc_mask_clr_bit;
gc->chip_types[0].chip.irq_unmask = irq_gc_mask_set_bit;
 
-   /* mask all interrupts */
+   /* mask and clear all interrupts */
writel(0, gc->reg_base + ORION_BRIDGE_IRQ_MASK);
+   writel(0, gc->reg_base + ORION_BRIDGE_IRQ_CAUSE);
 
irq_set_handler_data(irq, domain);
irq_set_chained_handler(irq, orion_bridge_irq_handler);
--
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 04/10] spi: sh-msiof: Add more register documentation

[Mark Brown]

On Thu, Feb 20, 2014 at 03:43:03PM +0100, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven 

Applied, thanks.


signature.asc
Description: Digital signature

Re: [PATCH v3] spi: core: Validate length of the transfers in message

[Mark Brown]

On Thu, Feb 20, 2014 at 12:02:08PM +0200, Ivan T. Ivanov wrote:
> From: "Ivan T. Ivanov" 
> 
> SPI transfer length should be multiple of SPI word size,
> where SPI word size should be power-of-two multiple

OK, I checked all the existing users and everything using unusual bits
per word settings seems to be doing the right thing here so I've applied
this - thanks!


signature.asc
Description: Digital signature

Re: [PATCH v5 02/33] genirq: Add irq_alloc_reserved_desc()

[Thomas Gleixner]

On Sat, 22 Feb 2014, Yinghai Lu wrote:
> On Sat, Feb 22, 2014 at 9:28 AM, Yinghai Lu  wrote:
> > On Sat, Feb 22, 2014 at 2:08 AM, Thomas Gleixner  wrote:
> >>
> >> As I said before irq_reserve_irq() is a misnomer and a
> >> misconception. Of course this needs to be fixed as well.
> >>
> >> And you cannot just blindly change it because !SPARSE can use the
> >> allocation. We are not creating stupid corner cases just to support
> >> your sloppyness. Its not rocket science to do it the right way.
> >>
> >> That said, it might be worthwhile to get rid of the !SPARSE case
> >> completely. That would probably make quite some stuff simpler.
> >
> > So we need to make all arches support SPARSE_IRQ at first?
> >
> > Now we have arm, arm64, c6x, metag, powerpc, sh, x86 support SPARSE_IRQ.
> >
> > The following  are not with SPARSE_IRQ yet:
> > alpha, arc, avr32, blackfin, cris, frv, hexagon, m32r, m68k, microblaze,
> > mips, mn10300, openrisc, parisc, s390, score, sparc, tile, um,
> > unicore32, xtensa.
> 
> or add calling irq_alloc_desc_at() before irq_set_chip... for !SPARSE_IRQ.
> 
> Please check attached partial patch if you like it.

OMG, you really mean that:

+++ b/arch/alpha/kernel/irq_i8259.c
@@ -92,6 +92,7 @@ init_i8259a_irqs(void)
outb(0xff, 0xA1);   /* mask all of 8259A-2 */
 
for (i = 0; i < 16; i++) {
+   irq_alloc_desc_at(i, 0);
irq_set_chip_and_handler(i, _irq_type, handle_level_irq);
}

You can't be serious about that. There are tons of ways to call into
the core and access an irq descriptor aside of irq_set_chip* before it
is potentially allocated.

Are you going to analyze all of them and add an irq_alloc_desc_at()
before that call?

HELL, NO!

I'm really tired of that.

Stay away from kernel/irq/* and wait for people who are competent
enough and willing to spend the extra thoughts to come up with
solutions which are not completely ass backwards.

Thanks,

tglx
--
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 03/10] spi: sh-msiof: Change hz from unsigned long to u32

[Mark Brown]

On Thu, Feb 20, 2014 at 03:43:02PM +0100, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven 
> 
> Both spi_transfer.speed_hz and spi_master.max_speed_hz are u32

Applied, thanks.


signature.asc
Description: Digital signature

Re: [PATCH 01/10] spi: sh-msiof: Fix SPI bus population from DT

[Mark Brown]

On Thu, Feb 20, 2014 at 03:43:00PM +0100, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven 
> 
> DT doesn't instantiate SPI children if spi_master.dev.of_node is not set up
> properly.

Applied, thanks.


signature.asc
Description: Digital signature

Re: [PATCH 08/10] spi: sh-msiof: Move clock management to (un)prepare_message()

[Mark Brown]

On Thu, Feb 20, 2014 at 03:43:07PM +0100, Geert Uytterhoeven wrote:

> + if (!test_and_set_bit(0, >flags)) {
> + pm_runtime_get_sync(>pdev->dev);
> + clk_enable(p->clk);
> + }

That test_and_set_bit() is a bit odd - what's going on there, perhaps a
comment is in order?  I'd also like to see return value checks, though
the original didn't have them so it's not a blocker, and ideally that
should be clk_prepare_enable().  I guess the clock stuff could even be
moved inside the runtime PM callbacks?  Again not a blocker if the
existing code doesn't have things but it'd be nice to do.

There's also auto_runtime_pm in the SPI core which will do the runtime
PM for you if you can do it unconditionally.


signature.asc
Description: Digital signature

Re: [PATCH] Documentation/spi/spidev_test.c: Document -N/--no-cs and -R/--ready

[Mark Brown]

On Thu, Feb 20, 2014 at 04:01:43PM +0100, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven 
> 
> commit b55f627feeb9d48fdbde3835e18afbc76712e49b ("spi: new spi->mode bits")
> added two new command line options without adding the respective help
> texts.

Applied, please use subject lines matching the style for the subsystem.


signature.asc
Description: Digital signature

Re: [PATCH 02/10] spi: sh-msiof: Typo in comment s/tx/rx/

[Mark Brown]

On Thu, Feb 20, 2014 at 03:43:01PM +0100, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven 

Applied, thanks.


signature.asc
Description: Digital signature

Re: [PATCH 05/10] spi: sh-msiof: Use the core cs_gpio field, and make it optional

[Mark Brown]

On Thu, Feb 20, 2014 at 03:43:04PM +0100, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven 
> 
> In current implementation, CS is controlled by GPIO, which is passed
> through spi->controller_data.  However, the MSIOF HW module has a function
> to output CS by itself, which is already enabled and actual switch will be
> done by pinmux.

Applied, thanks.


signature.asc
Description: Digital signature

Re: [PATCH 07/10] spi: sh-msiof: Add support for R-Car H2 and M2

[Mark Brown]

On Thu, Feb 20, 2014 at 05:13:16PM +0100, Geert Uytterhoeven wrote:

> "renesas,tx-fifo-size" and "renesas,rx-fifo-size" are part of the existing
> bindings, so I'm a bit reluctant to change these.
> Hmm, since the original bindings didn't specify the default values,
> I could make them chip-specific, though.

That sounds like a good idea, you could also change the properties to be
deprecatedn and recommend that people just don't bother setting them at
all.


signature.asc
Description: Digital signature

Re: [PATCH net-next v5 4/9] xen-netback: Change RX path for mapped SKB fragments

[Zoltan Kiss]

On 18/02/14 17:45, Ian Campbell wrote:

On Mon, 2014-01-20 at 21:24 +, Zoltan Kiss wrote:

Re the Subject: change how? Perhaps "handle foreign mapped pages on the
guest RX path" would be clearer.

Ok, I'll do that.




RX path need to know if the SKB fragments are stored on pages from another
domain.

Does this not need to be done either before the mapping change or at the
same time? -- otherwise you have a window of a couple of commits where
things are broken, breaking bisectability.
I can move this to the beginning, to keep bisectability. I've put it 
here originally because none of these makes sense without the previous 
patches.


Zoli
--
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 07/11] watchdog: xilinx: Use of_property_read_u32

[Guenter Roeck]

On 02/22/2014 05:08 PM, Alejandro Cabrera wrote:

On 22/2/2014 10:46 AM, Wim Van Sebroeck wrote:

Hi All,


Hi Michal,

On Wed, Feb 12, 2014 at 02:41:21PM +0100, Michal Simek wrote:

Use of_property_read_u32 functions to clean probe function.

Signed-off-by: Michal Simek
Reviewed-by: Guenter Roeck
---

Changes in v3:
- Remove one if checking and use variable directly


Looks good.

Another comment/remark.


-pfreq = (u32 *)of_get_property(pdev->dev.of_node,
-"clock-frequency", NULL);
-
-if (pfreq == NULL) {
+rc = of_property_read_u32(pdev->dev.of_node, "clock-frequency",);
+if (rc) {
  dev_warn(>dev,
   "The watchdog clock frequency cannot be obtained\n");
  no_timeout = true;
  }

-tmptr = (u32 *)of_get_property(pdev->dev.of_node,
-"xlnx,wdt-interval", NULL);
-if (tmptr == NULL) {
+rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-interval",
+>wdt_interval);
+if (rc) {
  dev_warn(>dev,
   "Parameter \"xlnx,wdt-interval\" not found\n");
  no_timeout = true;
-} else {
-xdev->wdt_interval = *tmptr;
  }

-tmptr = (u32 *)of_get_property(pdev->dev.of_node,
-"xlnx,wdt-enable-once", NULL);
-if (tmptr == NULL) {
+rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-enable-once",
+_once);
+if (rc)
  dev_warn(>dev,
   "Parameter \"xlnx,wdt-enable-once\" not found\n");
-watchdog_set_nowayout(xilinx_wdt_wdd, true);
-}

All the above properties are optional. Is a warning really
warranted in this case ? I usually associate a warning with
something that is wrong, which is not the case here.

I would encourage you to drop those warnings, but that should be
a separate patch.

I agree with Guenter: these are not really warnings. Seperate patch is thus 
welcome.

Hi

I support Michal intention, I think it is a warning because device tree blob must have 
the "xlnx,wdt-enable-once" property specified in order to allow the system to 
be sure of the real value of this property. In addition to, this warning can be helpful 
to detect a wrong device tree specification.



The dt documentation states that the properties are optional.

Optional properties:
- clock-frequency   : Frequency of clock in Hz
- xlnx,wdt-enable-once  : 0 - Watchdog can be restarted
  1 - Watchdog can be enabled just once
- xlnx,wdt-interval : Watchdog timeout interval in 2^ clock cycles,
   is integer from 8 to 31.

This clearly conflicts with your statement. An optional property
is just that, optional. If it warrants a warning, it must
not be optional. If you claim that not providing the properties
would be "wrong", why are they defined as optional ?
What is your definition of "wrong" and "must have" ?
How do you expect anyone to know that omitting those
"optional" properties is by some definition "wrong" ?

Guenter


--
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] USB fix for 3.14-rc4

[Greg KH]

The following changes since commit 6d0abeca3242a88cab8232e4acd7e2bf088f3bc2:

  Linux 3.14-rc3 (2014-02-16 13:30:25 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ 
tags/usb-3.14-rc4

for you to fetch changes up to 5bf5dbeda2454296f1984adfbfc8e6f5965ac389:

  usb: chipidea: need to mask when writting endptflush and endptprime 
(2014-02-21 12:34:45 -0800)


USB fixes for 3.14-rc4

Here are a number of USB fixes for reported issues for 3.14-rc4

The majority of these are for USB gadget, phy, and musb driver issues.
And there's a few new device ids thrown in for good measure.

Signed-off-by: Greg Kroah-Hartman 


Ajay Kumar Gupta (1):
  usb: musb: host: Fix SuperSpeed hub enumeration

Alan Stern (1):
  USB: EHCI: add delay during suspend to prevent erroneous wakeups

Aleksander Morgado (1):
  USB: serial: option: blacklist interface 4 for Cinterion PHS8 and PXS8

Andrzej Pietrasiewicz (1):
  usb: gadget: fix NULL pointer dereference

Daniel Mack (4):
  usb: musb: do not sleep in atomic context
  usb: musb: do not sleep in atomic context
  usb: musb: correct use of schedule_delayed_work()
  usb: musb: correct use of schedule_delayed_work()

Felipe Balbi (1):
  usb: musb: fix obex in g_nokia.ko causing kernel panic

Florian Fainelli (1):
  usb: gadget: bcm63xx_udc: fix build failure on DMA channel code

Greg Kroah-Hartman (1):
  Merge tag 'fixes-for-v3.14-rc4' of git://git.kernel.org/.../balbi/usb 
into usb-linus

Hans de Goede (3):
  phy-core: phy_get: Leave error logging to the caller
  phy-core: Don't propagate -ENOSUPP from phy_pm_runtime_get_sync to caller
  phy-core: Don't allow building phy-core as a module

Josh Cartwright (1):
  usb: phy: msm: fix compilation errors when !CONFIG_PM_SLEEP

Kishon Vijay Abraham I (1):
  phy: let phy_provider_register be the last step in registering PHY

Matthieu CASTET (1):
  usb: chipidea: need to mask when writting endptflush and endptprime

Peter Chen (1):
  usb: gadget: printer: using gadget_is_otg to check otg support at runtime

Richard Weinberger (1):
  phy,phy-bcm-kona-usb2.c: Add dependency on HAS_IOMEM

Roger Quadros (1):
  usb: musb: core: Fix remote-wakeup resume

Sachin Kamat (1):
  usb: gadget: s3c2410_udc: Fix build error

 drivers/phy/Kconfig |  3 +-
 drivers/phy/phy-core.c  | 14 -
 drivers/phy/phy-exynos-dp-video.c   |  8 ++---
 drivers/phy/phy-exynos-mipi-video.c | 10 +++
 drivers/phy/phy-mvebu-sata.c| 10 +++
 drivers/phy/phy-omap-usb2.c | 10 +++
 drivers/phy/phy-twl4030-usb.c   | 10 +++
 drivers/usb/chipidea/udc.c  |  4 +--
 drivers/usb/gadget/bcm63xx_udc.c| 58 -
 drivers/usb/gadget/f_fs.c   |  7 -
 drivers/usb/gadget/printer.c|  2 +-
 drivers/usb/gadget/s3c2410_udc.c|  2 +-
 drivers/usb/host/ehci-hub.c | 26 ++---
 drivers/usb/musb/musb_core.c| 15 --
 drivers/usb/musb/musb_host.c|  3 ++
 drivers/usb/musb/musb_virthub.c | 26 -
 drivers/usb/musb/omap2430.c |  2 --
 drivers/usb/phy/phy-msm-usb.c   | 57 +---
 drivers/usb/serial/option.c |  3 +-
 19 files changed, 159 insertions(+), 111 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/

[GIT PULL] Staging driver fix for 3.14-rc4

[Greg KH]

The following changes since commit 6d0abeca3242a88cab8232e4acd7e2bf088f3bc2:

  Linux 3.14-rc3 (2014-02-16 13:30:25 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ 
tags/staging-3.14-rc4

for you to fetch changes up to e194fd8a5d8e0a7eeed239a8534460724b62fe2d:

  staging: binder: Fix death notifications (2014-02-21 12:30:54 -0800)


Staging tree fix for 3.14-rc4

Here is a single android driver fix for 3.14-rc4 that fixes a reported
problem in the binder driver.

Signed-off-by: Greg Kroah-Hartman 


Arve Hjønnevåg (1):
  staging: binder: Fix death notifications

 drivers/staging/android/binder.c | 3 +--
 1 file changed, 1 insertion(+), 2 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/

[GIT PULL] TTY/Serial fix for 3.14-rc4

[Greg KH]

The following changes since commit 6d0abeca3242a88cab8232e4acd7e2bf088f3bc2:

  Linux 3.14-rc3 (2014-02-16 13:30:25 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ 
tags/tty-3.14-rc4

for you to fetch changes up to 5c0a2450d695bbe32b1fb81c07751bcbea64f084:

  Revert "tty: Set correct tty name in 'active' sysfs attribute" (2014-02-22 
14:31:04 -0800)


TTY patch revert for 3.14-rc4

Here is a single commit, a revert of a sysfs file change that ended up
breaking a userspace tool.

Signed-off-by: Greg Kroah-Hartman 


Greg Kroah-Hartman (1):
  Revert "tty: Set correct tty name in 'active' sysfs attribute"

 Documentation/ABI/testing/sysfs-tty |  3 +--
 drivers/tty/tty_io.c| 25 +++--
 2 files changed, 8 insertions(+), 20 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/

[GIT PULL] char/misc fix for 3.14-rc4

[Greg KH]

The following changes since commit 6d0abeca3242a88cab8232e4acd7e2bf088f3bc2:

  Linux 3.14-rc3 (2014-02-16 13:30:25 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ 
tags/char-misc-3.14-rc4

for you to fetch changes up to accb884b32e82f943340688c9cd30290531e73e0:

  mei: set client's read_cb to NULL when flow control fails (2014-02-18 
10:07:36 -0800)


Char/Misc fix for 3.14-rc4

Here is a single commit, to fix a reported problem in the mei driver.

Signed-off-by: Greg Kroah-Hartman 


Chao Bi (1):
  mei: set client's read_cb to NULL when flow control fails

 drivers/misc/mei/client.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
--
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 RESEND 2/3] SubmittingPatches: Add recommendation for mailing list references

[Randy Dunlap]

On 02/22/2014 02:30 PM, Josh Triplett wrote:
> On Sat, Feb 22, 2014 at 01:56:54PM -0800, Randy Dunlap wrote:
>> On 02/22/2014 12:12 PM, Josh Triplett wrote:
>>> SubmittingPatches already mentions referencing bugs fixed by a commit,
>>> but doesn't mention citing relevant mailing list discussions.  Add a
>>> note to that effect, along with a recommendation to use the
>>> https://lkml.kernel.org/ redirector.
>>>
>>> Portions based on text from git's SubmittingPatches.
>>>
>>> Signed-off-by: Josh Triplett 
>>> Acked-by: Borislav Petkov 
>>> ---
>>>  Documentation/SubmittingPatches | 10 +-
>>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/SubmittingPatches 
>>> b/Documentation/SubmittingPatches
>>> index c74e73c..53e6590 100644
>>> --- a/Documentation/SubmittingPatches
>>> +++ b/Documentation/SubmittingPatches
>>> @@ -112,7 +112,15 @@ to do frotz", as if you are giving orders to the 
>>> codebase to change
>>>  its behaviour.
>>>  
>>>  If the patch fixes a logged bug entry, refer to that bug entry by
>>> -number and URL.
>>> +number and URL.  If the patch follows from a mailing list discussion,
>>> +give a URL to the mailing list archive; use the https://lkml.kernel.org/
>>> +redirector with a Message-Id, to ensure that the links cannot become
>>> +stale.
>>
>> Some of us don't know what that looks like.
>> Could we have an example?
> 
> https://lkml.kernel.org/ provides examples; I didn't want to duplicate
> that documentation.

Thanks, I didn't know that and wouldn't normally look there to see if
it provides examples, so you could do like Boris suggested... :)


-- 
~Randy
--
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 5/9] usb: don't use PREPARE_DELAYED_WORK

[Alan Stern]

On Sat, 22 Feb 2014, Tejun Heo wrote:

> On Sat, Feb 22, 2014 at 10:14:48AM -0500, Alan Stern wrote:
> > Is the cancel_delayed_work_sync(>init_work) call in hub_quiesce()
> > going to get confused by all this?
> 
> Yeah, you can't cancel a work item which hasn't been initialzed.
> Maybe move init of the first work function there?  I don't think it
> really matters tho.
> 
> > It's worth mentioning that the only reason for the hub_init_func3 stuff
> > is, as the comment says, to avoid a long sleep (100 ms) inside a work
> > routine.  With all the changes to the work queue infrastructure, maybe
> > this doesn't matter so much any more.  If we got rid of it then there
> > wouldn't be any multiplexing, and this whole issue would become moot.
> 
> I don't really think that'd be necessary.  Just sleeping synchronously
> should be fine.  How many threads are we talking about?

One thread per hub (no more than 10 on a typical system).  The code in
question is part of the hub driver's probe sequence.


On Sat, 22 Feb 2014, Peter Hurley wrote:

> If a running hub init does not need to be single-threaded wrt
> a different running hub init,

I'm not quite sure what that means, but the hub init threads are indeed
independent of each other.

>  then a single init work could be queued to
> the system_unbound_wq which doesn't care about running times.

This sort of thing sounds like the best approach.  Tejun, do you want
to rewrite the patch, getting rid of the hub_init_func3 and HUB_INIT3
business entirely?  Or would you like me to do it?

Alan Stern

--
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 RESEND 2/3] SubmittingPatches: Add recommendation for mailing list references

[Borislav Petkov]

On Sat, Feb 22, 2014 at 02:30:38PM -0800, Josh Triplett wrote:
> > >  If the patch fixes a logged bug entry, refer to that bug entry by
> > > -number and URL.
> > > +number and URL.  If the patch follows from a mailing list discussion,
> > > +give a URL to the mailing list archive; use the https://lkml.kernel.org/
> > > +redirector with a Message-Id, to ensure that the links cannot become
> > > +stale.
> > 
> > Some of us don't know what that looks like.
> > Could we have an example?
> 
> https://lkml.kernel.org/ provides examples; I didn't want to duplicate
> that documentation.

Yeah, maybe you should say:

"If the patch follows from a mailing list discussion, give a URL to the
mailing list archive; use the https://lkml.kernel.org/ (usage examples
at that very URL) ... "

so that it is crystal clear.

-- 
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 RESEND] bug: When !CONFIG_BUG, simplify WARN_ON_ONCE and family

[Josh Triplett]

On Sat, Feb 22, 2014 at 02:31:20PM -0800, Josh Triplett wrote:
> On Sat, Feb 22, 2014 at 01:54:49PM -0800, Randy Dunlap wrote:
> > On 02/22/2014 11:23 AM, Josh Triplett wrote:
> > 
> > Hi Josh,
> > 
> > If you redo these patches, please make while(0) not look like a
> > function call, i.e., use while (0) instead.
> 
> Good catch.  Fixing in v2.

Looking at the patch, those while(0)s were all in the original code, not
introduced by my patch.  (diff claims my patch moves them, but a better
diff would have shown that I left them alone and just moved other code
above them.)

With that in mind, I didn't want to change that style issue in the same
patch, but I wrote a separate style patch to be applied on top:

- >8 -
>From 2a80f851b507f44142d219af3cf00555e333f4c4 Mon Sep 17 00:00:00 2001
From: Josh Triplett 
Date: Sat, 22 Feb 2014 14:33:01 -0800
Subject: [PATCH] include/asm-generic/bug.h: Style fix: s/while(0)/while (0)/

Reported-by: Randy Dunlap 
Signed-off-by: Josh Triplett 
---
 include/asm-generic/bug.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 34223e0..5f5a277 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -52,7 +52,7 @@ struct bug_entry {
 #endif
 
 #ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while(0)
+#define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while (0)
 #endif
 
 /*
@@ -138,11 +138,11 @@ extern void warn_slowpath_null(const char *file, const 
int line);
 
 #else /* !CONFIG_BUG */
 #ifndef HAVE_ARCH_BUG
-#define BUG() do {} while(0)
+#define BUG() do {} while (0)
 #endif
 
 #ifndef HAVE_ARCH_BUG_ON
-#define BUG_ON(condition) do { if (condition) ; } while(0)
+#define BUG_ON(condition) do { if (condition) ; } while (0)
 #endif
 
 #ifndef HAVE_ARCH_WARN_ON
-- 
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 net-next v5 2/9] xen-netback: Change TX path from grant copy to mapping

[Zoltan Kiss]

On 18/02/14 17:40, Ian Campbell wrote:

On Mon, 2014-01-20 at 21:24 +, Zoltan Kiss wrote:

This patch changes the grant copy on the TX patch to grant mapping


Both this and the previous patch had a single sentence commit message (I
count them together since they are split weirdly and are a single
logical change to my eyes).

Really a change of this magnitude deserves a commit message to match,
e.g. explaining the approach which is taken by the code at a high level,
what it is doing, how it is doing it, the rationale for using a kthread
etc etc.

Ok, I'll  improve that


diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index f0f0c3d..b3daae2 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -122,7 +122,9 @@ static int xenvif_start_xmit(struct sk_buff *skb, struct 
net_device *dev)
BUG_ON(skb->dev != dev);

/* Drop the packet if vif is not ready */
-   if (vif->task == NULL || !xenvif_schedulable(vif))
+   if (vif->task == NULL ||
+   vif->dealloc_task == NULL ||


Under what conditions could this be true? Would it not represent a
rather serious failure?
xenvif_start_xmit can start after xenvif_open, while the threads are 
created when the ring connects. I haven't checked under what 
circumstances can that happen, but I guess if it worked like that 
before, that's fine. If not, that's the topic of a different patch(series).





+   !xenvif_schedulable(vif))
goto drop;

/* At best we'll need one slot for the header and one for each
@@ -344,8 +346,26 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t 
domid,
vif->pending_prod = MAX_PENDING_REQS;
for (i = 0; i < MAX_PENDING_REQS; i++)
vif->pending_ring[i] = i;
-   for (i = 0; i < MAX_PENDING_REQS; i++)
-   vif->mmap_pages[i] = NULL;
+   spin_lock_init(>dealloc_lock);
+   spin_lock_init(>response_lock);
+   /* If ballooning is disabled, this will consume real memory, so you
+* better enable it.


Almost no one who would be affected by this is going to read this
comment. And it doesn't just require enabling ballooning, but actually
booting with some maxmem "slack" to leave space.
Where should we document this? I mean, in case David doesn't fix this 
before acceptance of this patch series :)




@@ -432,6 +454,18 @@ int xenvif_connect(struct xenvif *vif, unsigned long 
tx_ring_ref,

vif->task = task;

+   task = kthread_create(xenvif_dealloc_kthread,
+  (void *)vif,
+  "%s-dealloc",
+  vif->dev->name);


This is separate to the existing kthread that handles rx stuff. If they
cannot or should not be combined then I think the existing one needs
renaming, both the function and the thread itself in a precursor patch.
I've explained in another email about the reasons why they are separate 
thread. I'll rename the existing thread and functions





@@ -494,6 +534,23 @@ void xenvif_disconnect(struct xenvif *vif)

  void xenvif_free(struct xenvif *vif)
  {
+   int i, unmap_timeout = 0;
+
+   for (i = 0; i < MAX_PENDING_REQS; ++i) {
+   if (vif->grant_tx_handle[i] != NETBACK_INVALID_HANDLE) {
+   unmap_timeout++;
+   schedule_timeout(msecs_to_jiffies(1000));


What are we waiting for here? Have we taken any action to ensure that it
is going to happen, like kicking something?
We are waiting for skb's to be freed so we can return the slots. They 
are not owned by us after we sent them, and we don't know who owns them. 
As discussed months ago, it is safe to assume that other devices won't 
sit on it indefinitely. If it goes to userspace or further up the stack 
to IP layer, we swap the pages out with local ones. The only place where 
things can go wrong is an another netback thread, that's handled in 
patch #8.





+   if (unmap_timeout > 9 &&


Why 9? Why not rely on net_ratelimit to DTRT? Or is it normal for this
to fail at least once?
As mentioned earlier, this is quite temporary here, it is improved in 
patch #8





+   net_ratelimit())
+   netdev_err(vif->dev,


I thought there was a ratelimited netdev printk which combined the
limiting and the printing in one function call. Maybe I am mistaken.
There is indeed, net_err_ratelimited and friends. But they call pr_err 
instead of netdev_err, so we lose the vif name from the log entry, which 
could be quite important. If someone introduce a netdev_err_ratelimit 
which calls netdev_err, we can change this, but I would defer this to a 
later patch.




diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index 195602f..747b428 100644
--- a/drivers/net/xen-netback/netback.c
+++ 

Re: [PATCH 1/4] net: rfkill: gpio: remove unused and obsoleteplatform parameters

[Marc Dietrich]

On Friday 21 February 2014 16:23:49 Heikki Krogerus wrote:
> Hi,
> 
> On Fri, Feb 21, 2014 at 02:55:14PM +0100, Marc Dietrich wrote:
> > Am Donnerstag, 20. Februar 2014, 14:51:34 schrieb Heikki Krogerus:
> > > After upgrading to descriptor based gpios, the gpio numbers
> > > are not used anymore. The power_clk_name and the platform
> > > specific setup and close hooks are not used by anybody, and
> > > we should not encourage use of such things, so removing them.
> > 
> > arch/arm/mach-tegra/board-paz00.c is still using platform data. Is there
> > some prerequisite patch I'm missing (3.14-rc3) or how can this file be
> > converted? We are waiting for DT support to arrive so we can finally
> > remove this file.
> True! It still set's the shutdown_gpio and reset_gpio members. I think
> I'll leave the header untouched and just clean net/rfkill/rfkill-gpio.c
> in this patch. We can remove the whole header after you guys have moved
> to DT.

Why? Just update the board file to remove those entries. I just checked that 
it's working fine without. So if you don't mind, add a patch to remove the 
entries as the first patch in your series.

Thanks

Marc
--
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 RESEND] bug: When !CONFIG_BUG, simplify WARN_ON_ONCE and family

[Josh Triplett]

On Sat, Feb 22, 2014 at 01:54:49PM -0800, Randy Dunlap wrote:
> On 02/22/2014 11:23 AM, Josh Triplett wrote:
> 
> Hi Josh,
> 
> If you redo these patches, please make while(0) not look like a
> function call, i.e., use while (0) instead.

Good catch.  Fixing in v2.

- Josh Triplett
--
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 RESEND 2/3] SubmittingPatches: Add recommendation for mailing list references

[Josh Triplett]

On Sat, Feb 22, 2014 at 01:56:54PM -0800, Randy Dunlap wrote:
> On 02/22/2014 12:12 PM, Josh Triplett wrote:
> > SubmittingPatches already mentions referencing bugs fixed by a commit,
> > but doesn't mention citing relevant mailing list discussions.  Add a
> > note to that effect, along with a recommendation to use the
> > https://lkml.kernel.org/ redirector.
> > 
> > Portions based on text from git's SubmittingPatches.
> > 
> > Signed-off-by: Josh Triplett 
> > Acked-by: Borislav Petkov 
> > ---
> >  Documentation/SubmittingPatches | 10 +-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/SubmittingPatches 
> > b/Documentation/SubmittingPatches
> > index c74e73c..53e6590 100644
> > --- a/Documentation/SubmittingPatches
> > +++ b/Documentation/SubmittingPatches
> > @@ -112,7 +112,15 @@ to do frotz", as if you are giving orders to the 
> > codebase to change
> >  its behaviour.
> >  
> >  If the patch fixes a logged bug entry, refer to that bug entry by
> > -number and URL.
> > +number and URL.  If the patch follows from a mailing list discussion,
> > +give a URL to the mailing list archive; use the https://lkml.kernel.org/
> > +redirector with a Message-Id, to ensure that the links cannot become
> > +stale.
> 
> Some of us don't know what that looks like.
> Could we have an example?

https://lkml.kernel.org/ provides examples; I didn't want to duplicate
that documentation.

- Josh Triplett
--
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 v1 3/3] ARM hibernation / suspend-to-disk

[Pavel Machek]

On Sat 2014-02-22 10:16:55, Russell King - ARM Linux wrote:
> On Thu, Feb 20, 2014 at 04:27:55PM +, Lorenzo Pieralisi wrote:
> > I still do not understand why switching to idmap, which is a clone of
> > init_mm + 1:1 kernel mappings is required here. Why idmap ?
> > 
> > And while at it, can't the idmap be overwritten _while_ copying back the
> > resume kernel ? Is it safe to use idmap page tables while copying ?
> > 
> > I had a look at x86 and there idmap page tables used to resume are created
> > on the fly using safe pages, on ARM idmap is created at boot.
> 
> That's fine.
> 
> Remember, you're required to boot exactly the same kernel image when
> resuming as the kernel which created the suspend image.  Unless you
> have random allocations going on, you should get the same layout for
> the idmap stuff at each boot.

Actually, x86-64 is able to resume from different kernel these days,
and some day you may want to do it on arm, too. But it is definitely
not needed for inital merge.

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 RFC v1 3/3] ARM hibernation / suspend-to-disk

[Pavel Machek]

Hi!

> > return from the finisher will always be interpreted as an abort rather
> > than success (because the state has to be unwound.)
> > 
> > This is the only way to get a zero return from cpu_suspend().
> 
> Yes, that's the only reason why this code is jumping to cpu_resume, since
> all it is needed is to snapshot the CPU context and by the time the
> finisher is called that's done. Wanted to say that soft reboot is not
> useful (cache flushing and resume with MMU off), but what you are saying
> is correct. We might be saving swsusp_save return value in a global
> variable and just return from the finisher, but that's horrible and
> given the amount of time it takes to snapshot the image to disk the
> cost of this soft reboot will be dwarfed by that.

I feel bad for the "global variable" trick on x86, and if you can
avoid it, please do!

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 v3 07/11] watchdog: xilinx: Use of_property_read_u32

[Alejandro Cabrera]

On 22/2/2014 10:46 AM, Wim Van Sebroeck wrote:

Hi All,


Hi Michal,

On Wed, Feb 12, 2014 at 02:41:21PM +0100, Michal Simek wrote:

Use of_property_read_u32 functions to clean probe function.

Signed-off-by: Michal Simek
Reviewed-by: Guenter Roeck
---

Changes in v3:
- Remove one if checking and use variable directly


Looks good.

Another comment/remark.


-   pfreq = (u32 *)of_get_property(pdev->dev.of_node,
-   "clock-frequency", NULL);
-
-   if (pfreq == NULL) {
+   rc = of_property_read_u32(pdev->dev.of_node, "clock-frequency",);
+   if (rc) {
dev_warn(>dev,
 "The watchdog clock frequency cannot be obtained\n");
no_timeout = true;
}

-   tmptr = (u32 *)of_get_property(pdev->dev.of_node,
-   "xlnx,wdt-interval", NULL);
-   if (tmptr == NULL) {
+   rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-interval",
+   >wdt_interval);
+   if (rc) {
dev_warn(>dev,
 "Parameter \"xlnx,wdt-interval\" not found\n");
no_timeout = true;
-   } else {
-   xdev->wdt_interval = *tmptr;
}

-   tmptr = (u32 *)of_get_property(pdev->dev.of_node,
-   "xlnx,wdt-enable-once", NULL);
-   if (tmptr == NULL) {
+   rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-enable-once",
+   _once);
+   if (rc)
dev_warn(>dev,
 "Parameter \"xlnx,wdt-enable-once\" not found\n");
-   watchdog_set_nowayout(xilinx_wdt_wdd, true);
-   }

All the above properties are optional. Is a warning really
warranted in this case ? I usually associate a warning with
something that is wrong, which is not the case here.

I would encourage you to drop those warnings, but that should be
a separate patch.

I agree with Guenter: these are not really warnings. Seperate patch is thus 
welcome.

Hi

I support Michal intention, I think it is a warning because device tree 
blob must have the "xlnx,wdt-enable-once" property specified in order to 
allow the system to be sure of the real value of this property. In 
addition to, this warning can be helpful to detect a wrong device tree 
specification.


Best regards
Alejandro



50 Aniversario de la Cujae. Inaugurada por Fidel el 2 de diciembre de 1964  
http://cujae.edu.cu


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

Linux 3.13.5

[Greg KH]

I'm announcing the release of the 3.13.5 kernel.

All users of the 3.13 kernel series must upgrade.

The updated 3.13.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.13.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile  |2 
 arch/arm/mach-pxa/am300epd.c  |1 
 arch/arm/mach-pxa/include/mach/balloon3.h |2 
 arch/arm/mach-pxa/include/mach/corgi.h|1 
 arch/arm/mach-pxa/include/mach/csb726.h   |2 
 arch/arm/mach-pxa/include/mach/gumstix.h  |1 
 arch/arm/mach-pxa/include/mach/idp.h  |1 
 arch/arm/mach-pxa/include/mach/palmld.h   |2 
 arch/arm/mach-pxa/include/mach/palmt5.h   |2 
 arch/arm/mach-pxa/include/mach/palmtc.h   |2 
 arch/arm/mach-pxa/include/mach/palmtx.h   |2 
 arch/arm/mach-pxa/include/mach/pcm027.h   |2 
 arch/arm/mach-pxa/include/mach/pcm990_baseboard.h |1 
 arch/arm/mach-pxa/include/mach/poodle.h   |2 
 arch/arm/mach-pxa/include/mach/spitz.h|2 
 arch/arm/mach-pxa/include/mach/tosa.h |2 
 arch/arm/mach-pxa/include/mach/trizeps4.h |2 
 arch/powerpc/kernel/machine_kexec.c   |   14 ++-
 arch/powerpc/kernel/machine_kexec_64.c|6 -
 arch/s390/kernel/head64.S |7 +
 arch/s390/mm/page-states.c|   10 ++
 arch/x86/include/asm/pgtable.h|   14 ++-
 arch/x86/kernel/cpu/common.c  |7 +
 arch/x86/kernel/ftrace.c  |   83 +++-
 arch/x86/mm/fault.c   |   14 ++-
 arch/x86/xen/mmu.c|4 
 block/blk-lib.c   |8 +
 block/blk.h   |2 
 drivers/block/xen-blkfront.c  |5 -
 drivers/char/raw.c|2 
 drivers/edac/edac_mc.c|   13 +--
 drivers/edac/edac_mc_sysfs.c  |   10 +-
 drivers/edac/edac_module.h|2 
 drivers/gpu/drm/i915/i915_gpu_error.c |5 -
 drivers/gpu/drm/i915/i915_irq.c   |3 
 drivers/gpu/drm/i915/intel_dp.c   |   10 +-
 drivers/gpu/drm/radeon/cik_sdma.c |   43 +++---
 drivers/gpu/drm/radeon/r600.c |4 
 drivers/gpu/drm/radeon/si.c   |4 
 drivers/hv/connection.c   |   13 ---
 drivers/hwmon/ntc_thermistor.c|6 -
 drivers/i2c/busses/i2c-mv64xxx.c  |   33 +++-
 drivers/iio/adc/max1363.c |2 
 drivers/iio/imu/adis16400.h   |1 
 drivers/iio/imu/adis16400_core.c  |   10 +-
 drivers/iio/magnetometer/ak8975.c |   16 ++-
 drivers/infiniband/hw/qib/qib_iba7322.c   |5 +
 drivers/md/raid1.c|   13 ++-
 drivers/md/raid5.c|   90 ++
 drivers/misc/mei/client.c |   11 ++
 drivers/misc/mic/host/mic_virtio.c|3 
 drivers/net/wireless/ath/ar5523/ar5523.c  |2 
 drivers/net/wireless/ath/ath9k/htc_drv_init.c |8 +
 drivers/net/wireless/ath/ath9k/htc_drv_main.c |   25 +++---
 drivers/net/wireless/ath/ath9k/init.c |8 +
 drivers/net/wireless/iwlwifi/iwl-nvm-parse.c  |5 +
 drivers/net/wireless/iwlwifi/mvm/mac80211.c   |2 
 drivers/net/wireless/iwlwifi/mvm/scan.c   |3 
 drivers/net/wireless/iwlwifi/mvm/utils.c  |2 
 drivers/net/wireless/iwlwifi/pcie/drv.c   |7 +
 drivers/of/address.c  |5 -
 drivers/pci/hotplug/acpiphp_glue.c|   15 +++
 drivers/power/max17040_battery.c  |5 -
 drivers/spi/spi-nuc900.c  |2 
 drivers/spi/spi.c |4 
 drivers/staging/comedi/drivers/adv_pci1710.c  |   17 ++--
 drivers/staging/iio/adc/ad799x_core.c |5 -
 drivers/staging/iio/impedance-analyzer/ad5933.c   |2 
 drivers/staging/lustre/lustre/llite/dir.c |2 
 drivers/staging/rtl8188eu/os_dep/usb_intf.c   |2 
 drivers/target/target_core_pr.c   |   11 +-
 drivers/tty/n_gsm.c   |   11 ++
 drivers/tty/n_tty.c   |   12 +-
 drivers/tty/serial/omap-serial.c  |6 -
 drivers/tty/serial/sirfsoc_uart.c |4 
 drivers/tty/vt/vt.c  

Re: [PATCH v5 02/33] genirq: Add irq_alloc_reserved_desc()

[Yinghai Lu]

On Sat, Feb 22, 2014 at 9:28 AM, Yinghai Lu  wrote:
> On Sat, Feb 22, 2014 at 2:08 AM, Thomas Gleixner  wrote:
>>
>> As I said before irq_reserve_irq() is a misnomer and a
>> misconception. Of course this needs to be fixed as well.
>>
>> And you cannot just blindly change it because !SPARSE can use the
>> allocation. We are not creating stupid corner cases just to support
>> your sloppyness. Its not rocket science to do it the right way.
>>
>> That said, it might be worthwhile to get rid of the !SPARSE case
>> completely. That would probably make quite some stuff simpler.
>
> So we need to make all arches support SPARSE_IRQ at first?
>
> Now we have arm, arm64, c6x, metag, powerpc, sh, x86 support SPARSE_IRQ.
>
> The following  are not with SPARSE_IRQ yet:
> alpha, arc, avr32, blackfin, cris, frv, hexagon, m32r, m68k, microblaze,
> mips, mn10300, openrisc, parisc, s390, score, sparc, tile, um,
> unicore32, xtensa.

or add calling irq_alloc_desc_at() before irq_set_chip... for !SPARSE_IRQ.

Please check attached partial patch if you like it.

If you are happy with that, I will split it into pieces and add other
irq_alloc_desc_at()
calling.

Thanks

Yinghai
diff --git a/arch/alpha/kernel/irq_alpha.c b/arch/alpha/kernel/irq_alpha.c
index 1c8625c..6c8728a 100644
--- a/arch/alpha/kernel/irq_alpha.c
+++ b/arch/alpha/kernel/irq_alpha.c
@@ -221,6 +221,7 @@ struct irqaction timer_irqaction = {
 void __init
 init_rtc_irq(void)
 {
+	irq_alloc_desc_at(RTC_IRQ, 0);
 	irq_set_chip_and_handler_name(RTC_IRQ, _irq_chip,
   handle_percpu_irq, "RTC");
 	setup_irq(RTC_IRQ, _irqaction);
diff --git a/arch/alpha/kernel/irq_i8259.c b/arch/alpha/kernel/irq_i8259.c
index e1861c7..c522359 100644
--- a/arch/alpha/kernel/irq_i8259.c
+++ b/arch/alpha/kernel/irq_i8259.c
@@ -92,6 +92,7 @@ init_i8259a_irqs(void)
 	outb(0xff, 0xA1);	/* mask all of 8259A-2 */
 
 	for (i = 0; i < 16; i++) {
+		irq_alloc_desc_at(i, 0);
 		irq_set_chip_and_handler(i, _irq_type, handle_level_irq);
 	}
 
diff --git a/arch/alpha/kernel/irq_pyxis.c b/arch/alpha/kernel/irq_pyxis.c
index 13c97a5..b6da6d1 100644
--- a/arch/alpha/kernel/irq_pyxis.c
+++ b/arch/alpha/kernel/irq_pyxis.c
@@ -102,6 +102,7 @@ init_pyxis_irqs(unsigned long ignore_mask)
 	for (i = 16; i < 48; ++i) {
 		if ((ignore_mask >> i) & 1)
 			continue;
+		irq_alloc_desc_at(i, 0);
 		irq_set_chip_and_handler(i, _irq_type, handle_level_irq);
 		irq_set_status_flags(i, IRQ_LEVEL);
 	}
diff --git a/arch/s390/kernel/irq.c b/arch/s390/kernel/irq.c
index bb27a26..2d1567b 100644
--- a/arch/s390/kernel/irq.c
+++ b/arch/s390/kernel/irq.c
@@ -88,9 +88,13 @@ static const struct irq_class irqclass_sub_desc[NR_ARCH_IRQS] = {
 	[CPU_RST]= {.name = "RST", .desc = "[CPU] CPU Restart"},
 };
 
+int arch_probe_early_allocate_nr_irqs(void)
+{
+	return THIN_INTERRUPT;
+}
+
 void __init init_IRQ(void)
 {
-	irq_reserve_irqs(0, THIN_INTERRUPT);
 	init_cio_interrupts();
 	init_airq_interrupts();
 	init_ext_interrupts();
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 6ad4658..398f9c4 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -206,9 +206,6 @@ int __init arch_early_irq_init(void)
 	count = ARRAY_SIZE(irq_cfgx);
 	node = cpu_to_node(0);
 
-	/* Make sure the legacy interrupts are marked in the bitmap */
-	irq_reserve_irqs(0, legacy_pic->nr_legacy_irqs);
-
 	for (i = 0; i < count; i++) {
 		irq_set_chip_data(i, [i]);
 		zalloc_cpumask_var_node([i].domain, GFP_KERNEL, node);
diff --git a/drivers/sh/intc/core.c b/drivers/sh/intc/core.c
index 8f32a13..05118f92 100644
--- a/drivers/sh/intc/core.c
+++ b/drivers/sh/intc/core.c
@@ -81,11 +81,8 @@ static void __init intc_register_irq(struct intc_desc *desc,
 	unsigned long flags;
 
 	/*
-	 * Register the IRQ position with the global IRQ map, then insert
-	 * it in to the radix tree.
+	 * insert it in to the radix tree.
 	 */
-	irq_reserve_irq(irq);
-
 	raw_spin_lock_irqsave(_big_lock, flags);
 	radix_tree_insert(>tree, enum_id, intc_irq_xlate_get(irq));
 	raw_spin_unlock_irqrestore(_big_lock, flags);
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 7dc1003..584f0d7 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -613,18 +613,13 @@ int __irq_alloc_descs(int irq, unsigned int from, unsigned int cnt, int node,
 	irq_alloc_descs(-1, from, cnt, node)
 
 void irq_free_descs(unsigned int irq, unsigned int cnt);
-int irq_reserve_irqs(unsigned int from, unsigned int cnt);
+int arch_probe_early_allocate_nr_irqs(void);
 
 static inline void irq_free_desc(unsigned int irq)
 {
 	irq_free_descs(irq, 1);
 }
 
-static inline int irq_reserve_irq(unsigned int irq)
-{
-	return irq_reserve_irqs(irq, 1);
-}
-
 #ifndef irq_reg_writel
 # define irq_reg_writel(val, addr)	writel(val, addr)
 #endif
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index dc04c16..4d86cf5 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -38,12 +38,7 @@ int irq_set_chip(unsigned int irq, struct irq_chip *chip)
 

Linux 3.12.13

[Greg KH]

I'm announcing the release of the 3.12.13 kernel.

All users of the 3.12 kernel series must upgrade.

The updated 3.12.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.12.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile  |2 
 arch/s390/kernel/head64.S |7 +-
 arch/s390/mm/page-states.c|   10 ++
 arch/x86/include/asm/pgtable.h|   14 +++-
 arch/x86/kernel/cpu/common.c  |7 +-
 arch/x86/kernel/ftrace.c  |   83 +--
 arch/x86/mm/fault.c   |   14 ++--
 arch/x86/xen/mmu.c|4 -
 block/blk-lib.c   |8 ++
 block/blk.h   |2 
 drivers/block/xen-blkfront.c  |5 +
 drivers/char/raw.c|2 
 drivers/edac/edac_mc.c|   13 ++-
 drivers/edac/edac_mc_sysfs.c  |   10 +-
 drivers/edac/edac_module.h|2 
 drivers/gpu/drm/i915/i915_gpu_error.c |5 +
 drivers/gpu/drm/radeon/r600.c |4 +
 drivers/gpu/drm/radeon/si.c   |4 +
 drivers/hv/connection.c   |   11 ---
 drivers/hwmon/ntc_thermistor.c|6 -
 drivers/i2c/busses/i2c-mv64xxx.c  |   33 -
 drivers/iio/adc/max1363.c |2 
 drivers/iio/imu/adis16400.h   |1 
 drivers/iio/imu/adis16400_core.c  |   10 +-
 drivers/iio/magnetometer/ak8975.c |   16 ++--
 drivers/infiniband/hw/qib/qib_iba7322.c   |5 +
 drivers/md/raid1.c|   13 ++-
 drivers/md/raid5.c|   90 --
 drivers/misc/mei/client.c |   11 ++-
 drivers/net/wireless/ath/ar5523/ar5523.c  |2 
 drivers/net/wireless/ath/ath9k/htc_drv_init.c |8 ++
 drivers/net/wireless/ath/ath9k/htc_drv_main.c |   25 +++
 drivers/net/wireless/ath/ath9k/init.c |8 ++
 drivers/net/wireless/iwlwifi/iwl-nvm-parse.c  |5 +
 drivers/net/wireless/iwlwifi/mvm/scan.c   |3 
 drivers/net/wireless/iwlwifi/mvm/utils.c  |2 
 drivers/of/address.c  |5 -
 drivers/pci/hotplug/acpiphp_glue.c|   15 +++-
 drivers/power/max17040_battery.c  |5 -
 drivers/spi/spi-nuc900.c  |2 
 drivers/spi/spi.c |4 -
 drivers/staging/comedi/drivers/adv_pci1710.c  |   17 +++-
 drivers/staging/iio/adc/ad799x_core.c |3 
 drivers/staging/lustre/lustre/llite/dir.c |2 
 drivers/staging/rtl8188eu/os_dep/usb_intf.c   |2 
 drivers/target/target_core_pr.c   |   11 ++-
 drivers/tty/n_gsm.c   |   11 +++
 drivers/tty/serial/sirfsoc_uart.c |4 -
 drivers/tty/vt/vt.c   |2 
 drivers/usb/core/hcd.c|1 
 drivers/usb/core/hub.c|7 --
 drivers/usb/core/usb.h|1 
 drivers/usb/host/xhci-ring.c  |   54 ---
 drivers/usb/host/xhci.c   |   18 +++--
 drivers/usb/host/xhci.h   |2 
 drivers/usb/serial/ftdi_sio.c |3 
 drivers/usb/serial/ftdi_sio_ids.h |7 ++
 drivers/usb/serial/option.c   |3 
 drivers/usb/serial/qcserial.c |3 
 drivers/usb/serial/usb-serial-simple.c|3 
 drivers/usb/storage/Kconfig   |4 -
 drivers/usb/storage/scsiglue.c|6 +
 drivers/usb/storage/unusual_cypress.h |2 
 drivers/usb/storage/unusual_devs.h|7 ++
 drivers/vme/bridges/vme_ca91cx42.c|4 -
 drivers/vme/bridges/vme_tsi148.c  |4 -
 fs/bio-integrity.c|   10 ++
 fs/cifs/cifsacl.c |   28 ++--
 fs/cifs/cifsglob.h|   10 ++
 fs/cifs/inode.c   |   13 ++-
 fs/cifs/smb1ops.c |8 ++
 fs/cifs/xattr.c   |   64 +++---
 fs/file.c |2 
 fs/lockd/svclock.c|8 ++
 fs/nfs/dir.c  |5 +
 include/linux/compiler-gcc4.h |6 -
 include/linux/usb.h   |2 
 kernel/irq/irqdesc.c  |1 
 kernel/time/jiffies.c |6 +
 kernel/time/tick-broadcast.c 

Re: [PATCH] tty: Fix low_latency BUG

[One Thousand Gnomes]

> Remove the low_latency rx steering from tty_flip_buffer_push();
> however, leave the knob as an optional hint to drivers that can
> tune their rx fifos and such like. Cleanup stale code comments
> regarding low_latency.
> 
> [1] https://lkml.org/lkml/2014/2/20/434
> 
> Reported-by: Beat Bolli 
> Reported-by: Pavel Roskin 
> Cc: Grant Edwards 
> Cc: Stanislaw Gruszka 
> Cc: Hal Murray 
> Cc: Alan Cox 
> Cc:  # 3.12.x+
> Signed-off-by: Peter Hurley 

Signed-off-by: Alan Cox 

Yay.. thats an annoying historical pain in the butt gone.

--
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 RESEND 2/3] SubmittingPatches: Add recommendation for mailing list references

[Randy Dunlap]

On 02/22/2014 12:12 PM, Josh Triplett wrote:
> SubmittingPatches already mentions referencing bugs fixed by a commit,
> but doesn't mention citing relevant mailing list discussions.  Add a
> note to that effect, along with a recommendation to use the
> https://lkml.kernel.org/ redirector.
> 
> Portions based on text from git's SubmittingPatches.
> 
> Signed-off-by: Josh Triplett 
> Acked-by: Borislav Petkov 
> ---
>  Documentation/SubmittingPatches | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index c74e73c..53e6590 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -112,7 +112,15 @@ to do frotz", as if you are giving orders to the 
> codebase to change
>  its behaviour.
>  
>  If the patch fixes a logged bug entry, refer to that bug entry by
> -number and URL.
> +number and URL.  If the patch follows from a mailing list discussion,
> +give a URL to the mailing list archive; use the https://lkml.kernel.org/
> +redirector with a Message-Id, to ensure that the links cannot become
> +stale.

Some of us don't know what that looks like.
Could we have an example?

> +However, try to make your explanation understandable without external
> +resources.  In addition to giving a URL to a mailing list archive or
> +bug, summarize the relevant points of the discussion that led to the
> +patch as submitted.
>  
>  If you want to refer to a specific commit, don't just refer to the
>  SHA-1 ID of the commit. Please also include the oneline summary of
> 


-- 
~Randy
--
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 RESEND] bug: When !CONFIG_BUG, simplify WARN_ON_ONCE and family

[Randy Dunlap]

On 02/22/2014 11:23 AM, Josh Triplett wrote:

Hi Josh,

If you redo these patches, please make while(0) not look like a
function call, i.e., use while (0) instead.

> +#else /* !CONFIG_BUG */
> +#ifndef HAVE_ARCH_BUG
> +#define BUG() do {} while(0)
> +#endif
> +
> +#ifndef HAVE_ARCH_BUG_ON
> +#define BUG_ON(condition) do { if (condition) ; } while(0)
> +#endif

Thanks.
-- 
~Randy
--
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 0/5] arch: atomic rework

[Linus Torvalds]

On Sat, Feb 22, 2014 at 10:53 AM, Torvald Riegel  wrote:
>
> Stating that (1) "the standard is wrong" and (2) that you think that
> mo_consume semantics are not good is two different things.

I do agree. They are two independent things.

I think the standard is wrong, because it's overly complex, hard to
understand, and nigh unimplementable. As shown by the bugzilla
example, "carries a dependency" encompasses things that are *not* just
synchronizing things just through a pointer, and as a result it's
actually very complicated, since they could have been optimized away,
or done in non-local code that wasn't even aware of the dependency
carrying.

That said, I'm reconsidering my suggested stricter semantics, because
for RCU we actually do want to test the resulting pointer against NULL
_without_ any implied serialization.

So I still feel that the standard as written is fragile and confusing
(and the bugzilla entry pretty much proves that it is also practically
unimplementable as written), but strengthening the serialization may
be the wrong thing.

Within the kernel, the RCU use for this is literally purely about
loading a pointer, and doing either:

 - testing its value against NULL (without any implied synchronization at all)

 - using it as a pointer to an object, and expecting that any accesses
to that object are ordered wrt the consuming load.

So I actually have a suggested *very* different model that people
might find more acceptable.

How about saying that the result of a "atomic_read(, mo_consume)" is
required to be a _restricted_ pointer type, and that the consume
ordering guarantees the ordering between that atomic read and the
accesses to the object that the pointer points to.

No "carries a dependency", no nothing.

Now, there's two things to note in there:

 - the "restricted pointer" part means that the compiler does not need
to worry about serialization to that object through other possible
pointers - we have basically promised that the *only* pointer to that
object comes from the mo_consume. So that part makes it clear that the
"consume" ordering really only is valid wrt that particular pointer
load.

 - the "to the object that the pointer points to" makes it clear that
you can't use the pointer to generate arbitrary other values and claim
to serialize that way.

IOW, with those alternate semantics, that gcc bugzilla example is
utterly bogus, and a compiler can ignore it, because while it tries to
synchronize through the "dependency chain" created with that "p-i+i"
expression, that is completely irrelevant when you use the above rules
instead.

In the bugzilla example, the object that "*(p-i+i)" accesses isn't
actually the object pointed to by the pointer, so no serialization is
implied. And if it actually *were* to be the same object, because "p"
happens to have the same value as "i", then the "restrict" part of the
rule pops up and the compiler can again say that there is no ordering
guarantee, since the programmer lied to it and used a restricted
pointer that aliased with another one.

So the above suggestion basically tightens the semantics of "consume"
in a totally different way - it doesn't make it serialize more, in
fact it weakens the serialization guarantees a lot, but it weakens
them in a way that makes the semantics a lot simpler and clearer.

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

Linux 3.10.32

[Greg KH]

I'm announcing the release of the 3.10.32 kernel.

All users of the 3.10 kernel series must upgrade.

The updated 3.10.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.10.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile  |2 
 arch/s390/kernel/head64.S |7 +-
 arch/s390/mm/page-states.c|   10 ++
 arch/x86/include/asm/xen/page.h   |   31 +---
 arch/x86/kernel/cpu/common.c  |7 +-
 arch/x86/kernel/ftrace.c  |   83 +--
 arch/x86/mm/fault.c   |   14 ++--
 arch/x86/xen/p2m.c|   10 +-
 arch/x86/xen/smp.c|9 ++
 block/blk-lib.c   |8 ++
 block/blk.h   |2 
 drivers/block/xen-blkfront.c  |5 +
 drivers/char/raw.c|2 
 drivers/edac/edac_mc.c|   13 ++-
 drivers/edac/edac_mc_sysfs.c  |   12 ++-
 drivers/edac/edac_module.h|2 
 drivers/gpu/drm/radeon/r600.c |4 +
 drivers/gpu/drm/radeon/si.c   |4 +
 drivers/hv/connection.c   |   11 ---
 drivers/hwmon/ntc_thermistor.c|6 -
 drivers/iio/imu/adis16400.h   |1 
 drivers/iio/imu/adis16400_core.c  |   10 +-
 drivers/infiniband/hw/qib/qib_iba7322.c   |5 +
 drivers/md/raid1.c|   13 ++-
 drivers/md/raid5.c|   90 --
 drivers/misc/mei/client.c |   11 ++-
 drivers/net/wireless/ath/ar5523/ar5523.c  |2 
 drivers/net/wireless/ath/ath9k/htc_drv_main.c |   25 +++
 drivers/net/wireless/iwlwifi/iwl-nvm-parse.c  |5 +
 drivers/net/wireless/iwlwifi/mvm/scan.c   |3 
 drivers/net/wireless/iwlwifi/mvm/utils.c  |2 
 drivers/of/address.c  |5 -
 drivers/power/max17040_battery.c  |5 -
 drivers/spi/spi.c |4 -
 drivers/staging/comedi/drivers/adv_pci1710.c  |   17 +++-
 drivers/staging/iio/adc/ad799x_core.c |3 
 drivers/tty/n_gsm.c   |   11 +++
 drivers/tty/vt/vt.c   |2 
 drivers/usb/core/hcd.c|1 
 drivers/usb/core/hub.c|7 --
 drivers/usb/core/usb.h|1 
 drivers/usb/serial/ftdi_sio.c |3 
 drivers/usb/serial/ftdi_sio_ids.h |7 ++
 drivers/usb/serial/option.c   |3 
 drivers/usb/serial/qcserial.c |3 
 drivers/usb/storage/Kconfig   |4 -
 drivers/usb/storage/scsiglue.c|6 +
 drivers/usb/storage/unusual_cypress.h |2 
 drivers/usb/storage/unusual_devs.h|7 ++
 drivers/vme/bridges/vme_ca91cx42.c|4 -
 drivers/vme/bridges/vme_tsi148.c  |4 -
 fs/bio-integrity.c|   10 ++
 fs/cifs/cifsacl.c |   28 ++--
 fs/cifs/cifsglob.h|   10 ++
 fs/cifs/inode.c   |   13 ++-
 fs/cifs/smb1ops.c |8 ++
 fs/cifs/xattr.c   |   64 +++---
 fs/file.c |2 
 fs/lockd/svclock.c|8 ++
 include/linux/compiler-gcc4.h |6 -
 kernel/irq/irqdesc.c  |1 
 kernel/time/jiffies.c |6 +
 kernel/time/tick-broadcast.c  |1 
 kernel/trace/ring_buffer.c|7 ++
 mm/memory-failure.c   |6 +
 net/mac80211/cfg.c|   41 ++-
 net/mac80211/tx.c |2 
 scripts/mod/file2alias.c  |4 -
 sound/pci/hda/patch_realtek.c |1 
 virt/kvm/coalesced_mmio.c |8 --
 70 files changed, 480 insertions(+), 254 deletions(-)

Alan Stern (3):
  usb-storage: add unusual-devs entry for BlackBerry 9000
  usb-storage: restrict bcdDevice range for Super Top in Cypress ATACB
  usb-storage: enable multi-LUN scanning when needed

Alex Deucher (1):
  drm/radeon: fix UVD IRQ support on 7xx

Alexander Usyskin (2):
  mei: clear write cb from waiting list on reset
  mei: don't unset read cb ptr on reset

Bjørn Mork (2):
  usb: qcserial: add Netgear Aircard 340U
  usb: ftdi_sio: add Mindstorms 

[PATCH 6/7] ARM: dt: sun7i: Add SPI muxing options

[Maxime Ripard]

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 0f0ee58..6161fd8 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -571,6 +571,20 @@
allwinner,drive = <3>;
allwinner,pull = <0>;
};
+
+   spi1_pins_a: spi1@0 {
+   allwinner,pins = "PI16", "PI17", "PI18", "PI19";
+   allwinner,function = "spi1";
+   allwinner,drive = <0>;
+   allwinner,pull = <0>;
+   };
+
+   spi2_pins_a: spi2@0 {
+   allwinner,pins = "PC19", "PC20", "PC21", "PC22";
+   allwinner,function = "spi2";
+   allwinner,drive = <0>;
+   allwinner,pull = <0>;
+   };
};
 
timer@01c20c00 {
-- 
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/

[PATCH 7/7] ARM: dts: sun7i: Enable the SPI controllers of the A20-olinuxino-micro

[Maxime Ripard]

The A20-Olinuxino-micro has two SPI bus exposed on its UEXT connectors, enable
them.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts 
b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
index b02a796..9d98316 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
@@ -18,7 +18,24 @@
model = "Olimex A20-Olinuxino Micro";
compatible = "olimex,a20-olinuxino-micro", "allwinner,sun7i-a20";
 
+   aliases {
+   spi0 = 
+   spi1 = 
+   };
+
soc@01c0 {
+   spi1: spi@01c06000 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+   };
+
+   spi2: spi@01c17000 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+   };
+
pinctrl@01c20800 {
led_pins_olinuxino: led_pins@0 {
allwinner,pins = "PH2";
-- 
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/

[PATCH 2/7] ARM: dt: sun7i: Add A20 SPI controller nodes

[Maxime Ripard]

The A20 has 4 SPI controllers compatible with the one found in the A10. Add
them in the DT.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 44 
 1 file changed, 44 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index d00fbf8..0f0ee58 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -401,6 +401,28 @@
#size-cells = <1>;
ranges;
 
+   spi0: spi@01c05000 {
+   compatible = "allwinner,sun4i-a10-spi";
+   reg = <0x01c05000 0x1000>;
+   interrupts = <0 10 4>;
+   clocks = <_gates 20>, <_clk>;
+   clock-names = "ahb", "mod";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   spi1: spi@01c06000 {
+   compatible = "allwinner,sun4i-a10-spi";
+   reg = <0x01c06000 0x1000>;
+   interrupts = <0 11 4>;
+   clocks = <_gates 21>, <_clk>;
+   clock-names = "ahb", "mod";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
emac: ethernet@01c0b000 {
compatible = "allwinner,sun4i-a10-emac";
reg = <0x01c0b000 0x1000>;
@@ -417,6 +439,28 @@
#size-cells = <0>;
};
 
+   spi2: spi@01c17000 {
+   compatible = "allwinner,sun4i-a10-spi";
+   reg = <0x01c17000 0x1000>;
+   interrupts = <0 12 4>;
+   clocks = <_gates 22>, <_clk>;
+   clock-names = "ahb", "mod";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   spi3: spi@01c1f000 {
+   compatible = "allwinner,sun4i-a10-spi";
+   reg = <0x01c1f000 0x1000>;
+   interrupts = <0 50 4>;
+   clocks = <_gates 23>, <_clk>;
+   clock-names = "ahb", "mod";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
pio: pinctrl@01c20800 {
compatible = "allwinner,sun7i-a20-pinctrl";
reg = <0x01c20800 0x400>;
-- 
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/

[PATCH 0/7] Add Allwinner A10 SPI Controller Driver

[Maxime Ripard]

Hi,

This patchset brings support for the SPI controller found in the
Allwinner A10 and derived SoCs.

Even though the controller supports DMA, the driver only supports PIO
mode for now. This driver will be used to bring up and test DMA on the
SoC, so support for the DMA will come eventually.

It doesn't support transfer larger than the FIFO size (64 bytes) for
now, It's one of the things that will be fixed whenever we will have
DMA support.

Thanks!
Maxime

Maxime Ripard (7):
  spi: sunxi: Add Allwinner A10 SPI controller driver
  ARM: dt: sun7i: Add A20 SPI controller nodes
  ARM: dt: sun4i: Add A10 SPI controller nodes
  ARM: dt: sun5i: Add A10s SPI controller nodes
  ARM: dt: sun5i: Add A13 SPI controller nodes
  ARM: dt: sun7i: Add SPI muxing options
  ARM: dts: sun7i: Enable the SPI controllers of the A20-olinuxino-micro

 .../devicetree/bindings/spi/spi-sun4i.txt  |  24 ++
 arch/arm/boot/dts/sun4i-a10.dtsi   |  44 ++
 arch/arm/boot/dts/sun5i-a10s.dtsi  |  33 ++
 arch/arm/boot/dts/sun5i-a13.dtsi   |  33 ++
 arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts|  17 +
 arch/arm/boot/dts/sun7i-a20.dtsi   |  58 +++
 drivers/spi/Kconfig|   6 +
 drivers/spi/Makefile   |   1 +
 drivers/spi/spi-sun4i.c| 477 +
 9 files changed, 693 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/spi/spi-sun4i.txt
 create mode 100644 drivers/spi/spi-sun4i.c

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

[PATCH 5/7] ARM: dt: sun5i: Add A13 SPI controller nodes

[Maxime Ripard]

The A13 has 3 SPI controllers compatible with the one found in the A10. Add
them in the DT.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun5i-a13.dtsi | 33 +
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
index 24cd86cb..7102d12 100644
--- a/arch/arm/boot/dts/sun5i-a13.dtsi
+++ b/arch/arm/boot/dts/sun5i-a13.dtsi
@@ -298,6 +298,39 @@
#size-cells = <1>;
ranges;
 
+   spi0: spi@01c05000 {
+   compatible = "allwinner,sun4i-a10-spi";
+   reg = <0x01c05000 0x1000>;
+   interrupts = <10>;
+   clocks = <_gates 20>, <_clk>;
+   clock-names = "ahb", "mod";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   spi1: spi@01c06000 {
+   compatible = "allwinner,sun4i-a10-spi";
+   reg = <0x01c06000 0x1000>;
+   interrupts = <11>;
+   clocks = <_gates 21>, <_clk>;
+   clock-names = "ahb", "mod";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   spi2: spi@01c17000 {
+   compatible = "allwinner,sun4i-a10-spi";
+   reg = <0x01c17000 0x1000>;
+   interrupts = <12>;
+   clocks = <_gates 22>, <_clk>;
+   clock-names = "ahb", "mod";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
intc: interrupt-controller@01c20400 {
compatible = "allwinner,sun4i-ic";
reg = <0x01c20400 0x400>;
-- 
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/

[PATCH 1/7] spi: sunxi: Add Allwinner A10 SPI controller driver

[Maxime Ripard]

The older Allwinner SoCs (A10, A13, A10s and A20) all have the same SPI
controller.

Unfortunately, this SPI controller, even though quite similar, is significantly
different from the recently supported A31 SPI controller (different registers
offset, split/merged registers, etc.). Supporting both controllers in a single
driver would be unreasonable, hence the addition of a new driver.

Like its more recent counterpart, it supports DMA, but the driver only does PIO
until we have a dmaengine driver for this platform.

Signed-off-by: Maxime Ripard 
---
 .../devicetree/bindings/spi/spi-sun4i.txt  |  24 ++
 drivers/spi/Kconfig|   6 +
 drivers/spi/Makefile   |   1 +
 drivers/spi/spi-sun4i.c| 477 +
 4 files changed, 508 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/spi/spi-sun4i.txt
 create mode 100644 drivers/spi/spi-sun4i.c

diff --git a/Documentation/devicetree/bindings/spi/spi-sun4i.txt 
b/Documentation/devicetree/bindings/spi/spi-sun4i.txt
new file mode 100644
index 000..de827f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-sun4i.txt
@@ -0,0 +1,24 @@
+Allwinner A10 SPI controller
+
+Required properties:
+- compatible: Should be "allwinner,sun4-a10-spi".
+- reg: Should contain register location and length.
+- interrupts: Should contain interrupt.
+- clocks: phandle to the clocks feeding the SPI controller. Two are
+  needed:
+  - "ahb": the gated AHB parent clock
+  - "mod": the parent module clock
+- clock-names: Must contain the clock names described just above
+
+Example:
+
+spi1: spi@01c06000 {
+   compatible = "allwinner,sun4i-a10-spi";
+   reg = <0x01c06000 0x1000>;
+   interrupts = <11>;
+   clocks = <_gates 21>, <_clk>;
+   clock-names = "ahb", "mod";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+};
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index af1a875..e9f40ff 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -446,6 +446,12 @@ config SPI_SIRF
help
  SPI driver for CSR SiRFprimaII SoCs
 
+config SPI_SUN4I
+   tristate "Allwinner A10 SoCs SPI controller"
+   depends on ARCH_SUNXI || COMPILE_TEST
+   help
+ SPI driver for Allwinner sun4i, sun5i and sun7i SoCs
+
 config SPI_SUN6I
tristate "Allwinner A31 SPI controller"
depends on ARCH_SUNXI || COMPILE_TEST
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 13b6ccf..65f4993 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -70,6 +70,7 @@ obj-$(CONFIG_SPI_SH_HSPI) += spi-sh-hspi.o
 obj-$(CONFIG_SPI_SH_MSIOF) += spi-sh-msiof.o
 obj-$(CONFIG_SPI_SH_SCI)   += spi-sh-sci.o
 obj-$(CONFIG_SPI_SIRF) += spi-sirf.o
+obj-$(CONFIG_SPI_SUN4I)+= spi-sun4i.o
 obj-$(CONFIG_SPI_SUN6I)+= spi-sun6i.o
 obj-$(CONFIG_SPI_TEGRA114) += spi-tegra114.o
 obj-$(CONFIG_SPI_TEGRA20_SFLASH)   += spi-tegra20-sflash.o
diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
new file mode 100644
index 000..3f82705
--- /dev/null
+++ b/drivers/spi/spi-sun4i.c
@@ -0,0 +1,477 @@
+/*
+ * Copyright (C) 2012 - 2014 Allwinner Tech
+ * Pan Nan 
+ *
+ * Copyright (C) 2014 Maxime Ripard
+ * Maxime Ripard 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define SUN4I_FIFO_DEPTH   64
+
+#define SUN4I_RXDATA_REG   0x00
+
+#define SUN4I_TXDATA_REG   0x04
+
+#define SUN4I_CTL_REG  0x08
+#define SUN4I_CTL_ENABLE   BIT(0)
+#define SUN4I_CTL_MASTER   BIT(1)
+#define SUN4I_CTL_CPHA BIT(2)
+#define SUN4I_CTL_CPOL BIT(3)
+#define SUN4I_CTL_CS_ACTIVE_LOWBIT(4)
+#define SUN4I_CTL_LMTF BIT(6)
+#define SUN4I_CTL_TF_RST   BIT(8)
+#define SUN4I_CTL_RF_RST   BIT(9)
+#define SUN4I_CTL_XCH  BIT(10)
+#define SUN4I_CTL_CS_MASK  0x3000
+#define SUN4I_CTL_CS(cs)   (((cs) << 12) & 
SUN4I_CTL_CS_MASK)
+#define SUN4I_CTL_DHB  BIT(15)
+#define SUN4I_CTL_CS_MANUALBIT(16)
+#define SUN4I_CTL_CS_LEVEL BIT(17)
+#define SUN4I_CTL_TP   BIT(18)
+
+#define SUN4I_INT_CTL_REG  0x0c
+#define SUN4I_INT_CTL_TC   BIT(16)
+
+#define SUN4I_INT_STA_REG  0x10

[PATCH 4/7] ARM: dt: sun5i: Add A10s SPI controller nodes

[Maxime Ripard]

The A10s has 3 SPI controllers compatible with the one found in the A10. Add
them in the DT.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun5i-a10s.dtsi | 33 +
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi 
b/arch/arm/boot/dts/sun5i-a10s.dtsi
index df90a29..b2cb5dc 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -300,6 +300,28 @@
#size-cells = <1>;
ranges;
 
+   spi0: spi@01c05000 {
+   compatible = "allwinner,sun4i-a10-spi";
+   reg = <0x01c05000 0x1000>;
+   interrupts = <10>;
+   clocks = <_gates 20>, <_clk>;
+   clock-names = "ahb", "mod";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   spi1: spi@01c06000 {
+   compatible = "allwinner,sun4i-a10-spi";
+   reg = <0x01c06000 0x1000>;
+   interrupts = <11>;
+   clocks = <_gates 21>, <_clk>;
+   clock-names = "ahb", "mod";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
emac: ethernet@01c0b000 {
compatible = "allwinner,sun4i-a10-emac";
reg = <0x01c0b000 0x1000>;
@@ -316,6 +338,17 @@
#size-cells = <0>;
};
 
+   spi2: spi@01c17000 {
+   compatible = "allwinner,sun4i-a10-spi";
+   reg = <0x01c17000 0x1000>;
+   interrupts = <12>;
+   clocks = <_gates 22>, <_clk>;
+   clock-names = "ahb", "mod";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
intc: interrupt-controller@01c20400 {
compatible = "allwinner,sun4i-ic";
reg = <0x01c20400 0x400>;
-- 
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/

[PATCH 3/7] ARM: dt: sun4i: Add A10 SPI controller nodes

[Maxime Ripard]

The A10 has 4 SPI controllers that are now supported. Add them in the DT.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun4i-a10.dtsi | 44 
 1 file changed, 44 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index f6f41d6..157bc09 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -339,6 +339,28 @@
#size-cells = <1>;
ranges;
 
+   spi0: spi@01c05000 {
+   compatible = "allwinner,sun4i-a10-spi";
+   reg = <0x01c05000 0x1000>;
+   interrupts = <10>;
+   clocks = <_gates 20>, <_clk>;
+   clock-names = "ahb", "mod";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   spi1: spi@01c06000 {
+   compatible = "allwinner,sun4i-a10-spi";
+   reg = <0x01c06000 0x1000>;
+   interrupts = <11>;
+   clocks = <_gates 21>, <_clk>;
+   clock-names = "ahb", "mod";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
emac: ethernet@01c0b000 {
compatible = "allwinner,sun4i-a10-emac";
reg = <0x01c0b000 0x1000>;
@@ -355,6 +377,28 @@
#size-cells = <0>;
};
 
+   spi2: spi@01c17000 {
+   compatible = "allwinner,sun4i-a10-spi";
+   reg = <0x01c17000 0x1000>;
+   interrupts = <12>;
+   clocks = <_gates 22>, <_clk>;
+   clock-names = "ahb", "mod";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   spi3: spi@01c1f000 {
+   compatible = "allwinner,sun4i-a10-spi";
+   reg = <0x01c1f000 0x1000>;
+   interrupts = <50>;
+   clocks = <_gates 23>, <_clk>;
+   clock-names = "ahb", "mod";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
intc: interrupt-controller@01c20400 {
compatible = "allwinner,sun4i-ic";
reg = <0x01c20400 0x400>;
-- 
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 v2 2/2] x86: Support compiling out human-friendly processor feature names

[Josh Triplett]

On Sat, Feb 22, 2014 at 01:18:14PM -0800, H. Peter Anvin wrote:
> On February 22, 2014 1:00:39 PM PST, Josh Triplett  
> wrote:
> >On Sat, Feb 22, 2014 at 09:49:36PM +0100, Borislav Petkov wrote:
> >> On Sat, Feb 22, 2014 at 11:57:10AM -0800, Josh Triplett wrote:
> >> > diff --git a/arch/x86/boot/cpu.c b/arch/x86/boot/cpu.c
> >> > index 6ec6bb6..29207f6 100644
> >> > --- a/arch/x86/boot/cpu.c
> >> > +++ b/arch/x86/boot/cpu.c
> >> > @@ -16,7 +16,9 @@
> >> >   */
> >> >  
> >> >  #include "boot.h"
> >> > +#ifdef CONFIG_X86_FEATURE_NAMES
> >> >  #include "cpustr.h"
> >> > +#endif
> >> 
> >> You probably could get rid of this ifdef too by moving it into
> >cpustr.h
> >> after teaching arch/x86/boot/mkcpustr.c to issue it...
> >
> >That would require building and running mkcpustr, which doesn't happen
> >when !CONFIG_X86_FEATURE_NAMES.  (And it'd require adding ifdefs to
> >mkcpustr instead, which seems counterproductive.)
> 
> Didn't that change since v1?

No, even after removing the ifdefs around the build rules as you
suggested (and v3's fixes for the resulting build issues, notably
changing some -y's to -$(CONFIG_X86_FEATURE_NAMES)), the makefiles still
manage to not build mkcpustr or cpustr.h, because nothing depends on it.

I could change the build rules to generate an empty cpustr.h and avoid
this ifdef, but that'd require an additional ifdef block in the Makefile.

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

Re: [PATCH v2 2/2] x86: Support compiling out human-friendly processor feature names

[H. Peter Anvin]

On February 22, 2014 1:00:39 PM PST, Josh Triplett  
wrote:
>On Sat, Feb 22, 2014 at 09:49:36PM +0100, Borislav Petkov wrote:
>> On Sat, Feb 22, 2014 at 11:57:10AM -0800, Josh Triplett wrote:
>> > diff --git a/arch/x86/boot/cpu.c b/arch/x86/boot/cpu.c
>> > index 6ec6bb6..29207f6 100644
>> > --- a/arch/x86/boot/cpu.c
>> > +++ b/arch/x86/boot/cpu.c
>> > @@ -16,7 +16,9 @@
>> >   */
>> >  
>> >  #include "boot.h"
>> > +#ifdef CONFIG_X86_FEATURE_NAMES
>> >  #include "cpustr.h"
>> > +#endif
>> 
>> You probably could get rid of this ifdef too by moving it into
>cpustr.h
>> after teaching arch/x86/boot/mkcpustr.c to issue it...
>
>That would require building and running mkcpustr, which doesn't happen
>when !CONFIG_X86_FEATURE_NAMES.  (And it'd require adding ifdefs to
>mkcpustr instead, which seems counterproductive.)
>

Didn't that change since v1?

>However, in exploring this, I ran into some build issues with v2 on a
>clean build; I'll send out v3 shortly with fixes to those.
>
>- Josh Triplett

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.
--
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/