Re: [PATCH 9/9] powerpc/pm: support deep sleep feature on T1040

[Kevin Hao]

On Fri, Mar 14, 2014 at 05:26:27PM -0500, Scott Wood wrote:
> On Thu, 2014-03-13 at 15:46 +0800, Kevin Hao wrote:
> > On Wed, Mar 12, 2014 at 12:43:05PM -0500, Scott Wood wrote:
> > > > Shouldn't we use "readback, sync" here? The following is quoted form 
> > > > t4240RM:
> > > >   To guarantee that the results of any sequence of writes to 
> > > > configuration
> > > >   registers are in effect, the final configuration register write 
> > > > should be
> > > >   immediately followed by a read of the same register, and that should 
> > > > be
> > > >   followed by a SYNC instruction. Then accesses can safely be made to 
> > > > memory
> > > >   regions affected by the configuration register write.
> > > 
> > > I agree that the sync before the readback is probably not necessary,
> > > since transactions to the same address should already be ordered.
> > > 
> > > A sync after the readback helps if you're trying to order the readback
> > > with subsequent memory accesses, though in that case wouldn't a sync
> > > alone (no readback) be adequate?
> > 
> > No, we don't just want to order the subsequent memory access here.
> > The 'write, readback, sync' is the required sequence if we want to make
> > sure that the writing to CCSR register does really take effect.
> > 
> > >  Though maybe not always -- see the
> > > comment near the end of fsl_elbc_write_buf() in
> > > drivers/mtd/nand_fsl_elbc.c.  I guess the readback does more than just
> > > make sure the device has seen the write, ensuring that the device has
> > > finished the transaction to the point of acting on another one.
> > 
> > Agree.
> > 
> > > 
> > > The data dependency plus isync sequence, which is done by the normal I/O
> > > accessors used from C code, orders the readback versus all future
> > > instructions (not just I/O).  The delay loop is not I/O.
> > 
> > According to the PowerISA, the sequence 'load, date dependency, isync' only
> > order the load accesses. 
> 
> The point is to order the delay loop after the load, not to order
> storage versus storage.

I think the point is to make sure that the writing of the CCSR_DDR_SDRAM_CFG_2
does really take effect before we begin to delay loop. The sequence "write,
readback, sync" will guarantee this according to the manual. If we just want to
order the delay loop after the load, the following sequence should be enough:
store to CCSR_DDR_SDRAM_CFG_2
load from CCSR_DDR_SDRAM_CFG_2
isync or sync
delay loop

Why do we need the 'date dependency' here? According to the e6500 manual, the
instructions can execute out of order, but complete in order. So I am really
wondering why we need to order the load and the following delay loop if there
is no intention to order the storage access? 

> 
> This is a sequence we're already using on all of our I/O loads
> (excluding accesses like in this patch that don't use the standard
> accessors).  I'm confident that it works even if it's not
> architecturally guaranteed.

This sequence is used to order the load and the followed storage access.
And this is guaranteed by the architecture. But I don't think it is suitable
for a case like this. The following is quoted from PowerISA:
  Because stores cannot be performed “out-of-order”
  (see Book III), if a Store instruction depends on the
  value returned by a preceding Load instruction
  (because the value returned by the Load is used to
  compute either the effective address specified by the
  Store or the value to be stored), the corresponding stor-
  age accesses are performed in program order. The
  same applies if whether the Store instruction is exe-
  cuted depends on a conditional Branch instruction that
  in turn depends on the value returned by a preceding
  Load instruction.
  
  Because an isync instruction prevents the execution of
  instructions following the isync until instructions pre-
  ceding the isync have completed, if an isync follows a
  conditional Branch instruction that depends on the
  value returned by a preceding Load instruction, the
  load on which the Branch depends is performed before
  any loads caused by instructions following the isync.

I think the above description would guarantee that the load will be performed
before any storage access (both load and store) following the isync in the
following scenario:
lwz r4, 0(r3)
twi 0, r4, 0
isync

>  I'm not sure that there exists a clear
> architectural way of synchronizing non-storage instructions relative to
> storage instructions.

Isn't what the execution synchronization instructions such as sync, isync, mtmsr
do?

> 
> Given that isync is documented as preventing any execution of
> instructions after the isync until all previous instructions complete,
> it doesn't seem to make sense for the architecture to explicitly talk
> about loads (as opposed to any other instruction) following a load,
> dependent conditional branch, isync sequence.

Sorry, I didn't get what you 

Re: [patch] mm: vmscan: do not swap anon pages just because free+file is low

[Hugh Dickins]

On Fri, 14 Mar 2014, Mel Gorman wrote:
> On Fri, Mar 14, 2014 at 12:06:25PM -0400, Rik van Riel wrote:
> > On 03/14/2014 11:35 AM, Johannes Weiner wrote:
> > > Page reclaim force-scans / swaps anonymous pages when file cache drops
> > > below the high watermark of a zone in order to prevent what little
> > > cache remains from thrashing.
> > > 
> > > However, on bigger machines the high watermark value can be quite
> > > large and when the workload is dominated by a static anonymous/shmem
> > > set, the file set might just be a small window of used-once cache.  In
> > > such situations, the VM starts swapping heavily when instead it should
> > > be recycling the no longer used cache.
> > > 
> > > This is a longer-standing problem, but it's more likely to trigger
> > > after 81c0a2bb515f ("mm: page_alloc: fair zone allocator policy")
> > > because file pages can no longer accumulate in a single zone and are
> > > dispersed into smaller fractions among the available zones.
> > > 
> > > To resolve this, do not force scan anon when file pages are low but
> > > instead rely on the scan/rotation ratios to make the right prediction.
> > 
> > I am not entirely sure that the scan/rotation ratio will be
> > meaningful when the page cache has been essentially depleted,
> > but on larger systems the distance between the low and high
> > watermark is gigantic, and I have no better idea on how to
> > fix the bug you encountered, so ...
> > 
> 
> I still agree with the direction in general even though I've not put
> thought into this specific patch yet. We've observed a problem whereby force
> reclaim was causing one or other LRU list to be trashed.  In one specific
> case, the inactive file is low logic was causing problems because while
> the relative size of inactive/active was taken into account, the absolute
> size vs anon was not. It was not a mainline kernel and we do not have a
> test configuration that properly illustrates the problem on mainline it's
> on our radar that it's a potential problem. The scan/rotation ratio at the
> moment does not take absolute sizes into account but we almost certainly
> want to go in that direction at some stage. Hugh's patch on altering how
> proportional shrinking works is also relevant.

That https://lkml.org/lkml/2014/3/13/217
is relevant, yes, but I think rather more so is
Suleiman's in https://lkml.org/lkml/2014/3/15/168

Hannes, your patch looks reasonable to me, and as I read it would
be well complemented by Suleiman's and mine; but I do worry that
the "scan_balance = SCAN_ANON" block you're removing was inserted
for good reason, and its removal bring complaint from some direction.

By the way, I notice you marked yours for stable [3.12+]:
if it's for stable at all, shouldn't it be for 3.9+?
(well, maybe nobody's doing a 3.9.N.M but 3.10.N is still alive).

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

Re: 3.14-rc: /proc/acpi/battery gone?

[Stefan Lippers-Hollmann]

Hi

On Saturday 15 March 2014, Lan Tianyu wrote:
> On 03/14/2014 10:17 PM, Stefan Lippers-Hollmann wrote:
> > Hi
> >
> > On Saturday 15 March 2014, Rafael J. Wysocki wrote:
> >> On Friday, March 14, 2014 06:14:12 PM Ilia Mirkin wrote:
> >>> On Fri, Mar 14, 2014 at 6:11 PM, Pavel Machek  wrote:
>  On Fri 2014-03-14 17:29:41, Ilia Mirkin wrote:
> > On Fri, Mar 14, 2014 at 5:14 PM, Pavel Machek  wrote:
[...]
> Hi Stefan:
>   I just glance wmbattery code. I find the code in the acpi.c is already 
> using the new sysfs battery interfaces, right?

By default, wmbattery appears to default to using upower as abstraction
level, instead of querying sysfs itself directly.

http://git.kitenet.net/?p=wmbattery.git;a=blob;f=autoconf/makeinfo.in;hb=HEAD

which sets USE_UPOWER=1 by default.

If USE_UPOWER=0 is set explicitly for the build, it reverts back to 
direct sysfs parsing - and yes, it does appear to adhere to the current
sysfs API properly.

The last remains, and the ability to parse procfs (which hasn't been 
default for quite some time already, in favour of using hal as 
abstraction layer) has finally been removed in

http://git.kitenet.net/?p=wmbattery.git;a=commitdiff;h=833eb63a5ce4f2fb712a201b1db4f2db1700fddb

The switch from procfs parsing to hal (by default at least) in turn 
happened with

http://git.kitenet.net/?p=wmbattery.git;a=commitdiff;h=63c3d1a0b11e8ade1a5612bb5baa3d92e153bbbe

in 2008 (before Debian squeeze/ oldstable). I have not investigated if 
hal then read from procfs or sysfs, but wmbattery at least didn't read
from procfs itself, unless explicitly told to do so (USE_HAL=0) during 
the build since mid 2008.

The current version of wmbattery however will never try to access 
/proc/acpi, the current version no longer knows of its existence.

[Again, I'm not familiar with wmbattery myself and have never run it]

Regards
Stefan Lippers-Hollmann
--
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: performance regression due to commit e82e0561("mm: vmscan: obey proportional scanning requirements for kswapd")

[Hugh Dickins]

On Fri, 14 Mar 2014, Mel Gorman wrote:
> On Thu, Mar 13, 2014 at 05:44:57AM -0700, Hugh Dickins wrote:
> > On Wed, 12 Mar 2014, Mel Gorman wrote:
> > > On Tue, Feb 18, 2014 at 04:01:22PM +0800, Yuanhan Liu wrote:
> > > > Hi,
> > > > 
> > > > Commit e82e0561("mm: vmscan: obey proportional scanning requirements for
> > > > kswapd") caused a big performance regression(73%) for vm-scalability/
> > > > lru-file-readonce testcase on a system with 256G memory without swap.
> > > > 
> > > > That testcase simply looks like this:
> > > >  truncate -s 1T /tmp/vm-scalability.img
> > > >  mkfs.xfs -q /tmp/vm-scalability.img
> > > >  mount -o loop /tmp/vm-scalability.img /tmp/vm-scalability
> > > > 
> > > >  SPARESE_FILE="/tmp/vm-scalability/sparse-lru-file-readonce"
> > > >  for i in `seq 1 120`; do
> > > >  truncate $SPARESE_FILE-$i -s 36G
> > > >  timeout --foreground -s INT 300 dd bs=4k if=$SPARESE_FILE-$i 
> > > > of=/dev/null
> > > >  done
> > > > 
> > > >  wait
> > > > 
> > > 
> > > The filename implies that it's a sparse file with no IO but does not say
> > > what the truncate function/program/whatever actually does. If it's really 
> > > a
> > > sparse file then the dd process should be reading zeros and writing them 
> > > to
> > > NULL without IO. Where are pages being dirtied? Does the truncate command
> > > really create a sparse file or is it something else?
> > > 
> > > > Actually, it's not the newlly added code(obey proportional scanning)
> > > > in that commit caused the regression. But instead, it's the following
> > > > change:
> > > > +
> > > > +   if (nr_reclaimed < nr_to_reclaim || scan_adjusted)
> > > > +   continue;
> > > > +
> > > > 
> > > > 
> > > > -   if (nr_reclaimed >= nr_to_reclaim &&
> > > > -   sc->priority < DEF_PRIORITY)
> > > > +   if (global_reclaim(sc) && !current_is_kswapd())
> > > > break;
> > > > 
> > > > The difference is that we might reclaim more than requested before
> > > > in the first round reclaimming(sc->priority == DEF_PRIORITY).
> > > > 
> > > > So, for a testcase like lru-file-readonce, the dirty rate is fast, and
> > > > reclaimming SWAP_CLUSTER_MAX(32 pages) each time is not enough for 
> > > > catching
> > > > up the dirty rate. And thus page allocation stalls, and performance 
> > > > drops:
> > ...
> > > > I made a patch which simply keeps reclaimming more if sc->priority == 
> > > > DEF_PRIORITY.
> > > > I'm not sure it's the right way to go or not. Anyway, I pasted it here 
> > > > for comments.
> > > > 
> > > 
> > > The impact of the patch is that a direct reclaimer will now scan and
> > > reclaim more pages than requested so the unlucky reclaiming process will
> > > stall for longer than it should while others make forward progress.
> > > 
> > > That would explain the difference in allocstall figure as each stall is
> > > now doing more work than it did previously. The throughput figure is
> > > harder to explain. What is it measuring?
> > > 
> > > Any idea why kswapd is failing to keep up?
> > > 
> > > I'm not saying the patch is wrong but there appears to be more going on
> > > that is explained in the changelog. Is the full source of the benchmark
> > > suite available? If so, can you point me to it and the exact commands
> > > you use to run the testcase please?
> > 
> > I missed Yuanhan's mail, but seeing your reply reminds me of another
> > issue with that proportionality patch - or perhaps more thought would
> > show them to be two sides of the same issue, with just one fix required.
> > Let me throw our patch into the cauldron.
> > 
> > [PATCH] mm: revisit shrink_lruvec's attempt at proportionality
> > 
> > We have a memcg reclaim test which exerts a certain amount of pressure,
> > and expects to see a certain range of page reclaim in response.  It's a
> > very wide range allowed, but the test repeatably failed on v3.11 onwards,
> > because reclaim goes wild and frees up almost everything.
> > 
> > This wild behaviour bisects to Mel's "scan_adjusted" commit e82e0561dae9
> > "mm: vmscan: obey proportional scanning requirements for kswapd".  That
> > attempts to achieve proportionality between anon and file lrus: to the
> > extent that once one of those is empty, it then tries to empty the other.
> > Stop that.
> > 
> > Signed-off-by: Hugh Dickins 
> > ---
> > 
> > We've been running happily with this for months; but all that time it's
> > been on my TODO list with a "needs more thought" tag before we could
> > upstream it, and I never got around to that.  We also have a somewhat
> > similar, but older and quite independent, fix to get_scan_count() from
> > Suleiman, which I'd meant to send along at the same time: I'll dig that
> > one out tomorrow or the day after.

I've sent that one out now in a new thread
https://lkml.org/lkml/2014/3/15/168
and also let's tie these together with Hannes's

[PATCH] mm: Only force scan in reclaim when none of the LRUs are big enough.

[Hugh Dickins]

From: Suleiman Souhlal 

Prior to this change, we would decide whether to force scan a LRU
during reclaim if that LRU itself was too small for the current
priority. However, this can lead to the file LRU getting force
scanned even if there are a lot of anonymous pages we can reclaim,
leading to hot file pages getting needlessly reclaimed.

To address this, we instead only force scan when none of the
reclaimable LRUs are big enough.

Gives huge improvements with zswap. For example, when doing -j20
kernel build in a 500MB container with zswap enabled, runtime (in
seconds) is greatly reduced:

x without this change
+ with this change
N   Min   MaxMedian   AvgStddev
x   5   700.997   790.076   763.928754.05  39.59493
+   5   141.634   197.899   155.706 161.9 21.270224
Difference at 95.0% confidence
-592.15 +/- 46.3521
-78.5293% +/- 6.14709%
(Student's t, pooled s = 31.7819)

Should also give some improvements in regular (non-zswap) swap cases.

Yes, hughd found significant speedup using regular swap, with several
memcgs under pressure; and it should also be effective in the non-memcg
case, whenever one or another zone LRU is forced too small.

Signed-off-by: Suleiman Souhlal 
Signed-off-by: Hugh Dickins 
---

I apologize to everyone for holding on to this so long: I think it's
a very helpful patch (which we've been using in Google for months now).
Been sitting on my TODO list, now prompted to send by related patches

https://lkml.org/lkml/2014/3/13/217
https://lkml.org/lkml/2014/3/14/277

Certainly worth considering all three together, but my understanding
is that they're actually three independent attacks on different ways
in which we currently squeeze an LRU too small; and this patch from
Suleiman seems to be the most valuable of the three, at least for
the workloads I've tried it on.  But I'm not much of a page reclaim
performance tester: please try it out to see if it's good for you.
Thanks!

 mm/vmscan.c |   72 +-
 1 file changed, 42 insertions(+), 30 deletions(-)

We did experiment with different ways of writing the patch, I'm afraid
the way it came out best indents deeper, making it look more than it is.

--- 3.14-rc6/mm/vmscan.c2014-02-02 18:49:07.949302116 -0800
+++ linux/mm/vmscan.c   2014-03-15 19:31:44.948977032 -0700
@@ -1852,6 +1852,8 @@ static void get_scan_count(struct lruvec
bool force_scan = false;
unsigned long ap, fp;
enum lru_list lru;
+   bool some_scanned;
+   int pass;
 
/*
 * If the zone or memcg is small, nr[l] can be 0.  This
@@ -1971,39 +1973,49 @@ static void get_scan_count(struct lruvec
fraction[1] = fp;
denominator = ap + fp + 1;
 out:
-   for_each_evictable_lru(lru) {
-   int file = is_file_lru(lru);
-   unsigned long size;
-   unsigned long scan;
-
-   size = get_lru_size(lruvec, lru);
-   scan = size >> sc->priority;
-
-   if (!scan && force_scan)
-   scan = min(size, SWAP_CLUSTER_MAX);
-
-   switch (scan_balance) {
-   case SCAN_EQUAL:
-   /* Scan lists relative to size */
-   break;
-   case SCAN_FRACT:
+   some_scanned = false;
+   /* Only use force_scan on second pass. */
+   for (pass = 0; !some_scanned && pass < 2; pass++) {
+   for_each_evictable_lru(lru) {
+   int file = is_file_lru(lru);
+   unsigned long size;
+   unsigned long scan;
+
+   size = get_lru_size(lruvec, lru);
+   scan = size >> sc->priority;
+
+   if (!scan && pass && force_scan)
+   scan = min(size, SWAP_CLUSTER_MAX);
+
+   switch (scan_balance) {
+   case SCAN_EQUAL:
+   /* Scan lists relative to size */
+   break;
+   case SCAN_FRACT:
+   /*
+* Scan types proportional to swappiness and
+* their relative recent reclaim efficiency.
+*/
+   scan = div64_u64(scan * fraction[file],
+   denominator);
+   break;
+   case SCAN_FILE:
+   case SCAN_ANON:
+   /* Scan one type exclusively */
+   if ((scan_balance == SCAN_FILE) != file)
+   scan = 0;
+   break;
+   default:
+   /* Look ma, no brain 

Re: [Suggestion] Makefile: about allmodconfig issue.

[Chen Gang]

On 03/16/2014 05:36 AM, Randy Dunlap wrote:
> On 03/15/2014 02:30 PM, Chen Gang wrote:
>> On 03/11/2014 09:08 AM, Chen Gang wrote:
>>> On 03/10/2014 12:24 AM, Randy Dunlap wrote:
 On 03/09/2014 08:02 AM, Chen Gang wrote:
>> [...]
> Else ('depends on' priority is higher than 'select')
>
>  - some architectures can choose whether support IRQ_DOMAIN.
>
>  - if IRQ_DOMAIN enabled, our gpio driver can be used, and then select
>GENERIC_IRQ_CHIP (need not consider about it selects IRQ_DOMAIN).
>
>  - else (IRQ_DOMAIN_disabled), we can not use our gpio driver, and also
>can not select GENERIC_IRQ_CHIP (need not consider about it selects
>IRQ_DOMAIN, either).
>
> Excuse me, I am not quite familiar with Kconfig grammar, can any members
> give a confirmation for it (whether 'select' priority is higher or equal
> than 'depends on').

 Sorry, I don't really understand the problem that you are trying to solve.
 Maybe you could back up and explain the underlying problem... ?

>>>
>>> If the fix patch applied (don't depend on IRQ_DOMAIN), I guess, if one
>>> architecture don't support IRQ_DOMAIN, GPIO_DWAPB may still be enabled
>>> and then let IRQ_DOMAIN enable too.
>>>
>>
>> Is it possible to still go further? For me, I still think, this is not
>> gpio driver's issue, the kbuild need be improved to support this using case.
>>
>> So, if it is necessary, I will/should try to go further about it.
> 
> 
> If you can demonstrate a problem, then please submit a patch for it,
> but don't just hypothesize a problem, actually show that there is one.
>

We are discussing this gpio driver's issue, and also discussing one fix
patch (remove IRQ_DOMAIN dependency).

For me, when discussing one patch (e.g. this fix patch), it is necessary
for patch maker to provide proofs to clear all related doubts from any
members (e.g. me).

And theoretically, 'kbuild' need support (implement correctly) the
priority between 'select' and 'depends on', or it can not express all
related features (although it can not cause real world issue, now).


Thanks.
-- 
Chen Gang

Open, share and attitude like air, water and life which God blessed
--
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: [v7] ext4: Add support FALLOC_FL_COLLAPSE_RANGE for fallocate

[tytso]

I just noticed I had the v6 version of your patch in my tree.  I've
updated it to be the v7 version, thanks.

 - Ted
--
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] Support map_pages() for DAX

[Matthew Wilcox]

On Sat, Mar 15, 2014 at 01:32:33AM +0200, Kirill A. Shutemov wrote:
> Side note: I'm sceptical about whole idea to use i_mmap_mutux to protect
> against truncate. It will not scale good enough comparing lock_page()
> with its granularity.

I'm actually working on this now.  The basic idea is to put an entry in
the radix tree for each page.  For zero pages, that's a pagecache page.
For pages that map to the media, it's an exceptional entry.  Radix tree
exceptional entries take two bits, leaving us with 30 or 62 bits depending
on sizeof(void *).  We can then take two more bits for Dirty and Lock,
leaving 28 or 60 bits that we can use to cache the PFN on the page,
meaning that we won't have to call the filesystem's get_block as often.

This means that shmem_find_get_pages_and_swap() moves from the shmem code
to filemap and gets renamed to find_get_rtes().  Next step is making
the truncate code use it so that the truncate code locks against DAX
code paths as well as pagecache codepaths.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND v2 PATCH 1/2] aio, memory-hotplug: Fix confliction when migrating and accessing ring pages.

[Gu Zheng]

Hi Ben,
Sorry for late.
On 03/14/2014 11:14 PM, Benjamin LaHaise wrote:

> Hi Gu,
> 
> On Fri, Mar 14, 2014 at 06:25:16PM +0800, Gu Zheng wrote:
>> Hi Ben,
>> On 03/13/2014 06:17 AM, Benjamin LaHaise wrote:
>>
>>> Hello Tang,
>>>
>>> On Wed, Mar 12, 2014 at 01:25:26PM +0800, Tang Chen wrote:
>>> ...  ...
>>>
> Another spot is in
> aio_read_events_ring() where head and tail are fetched from the ring 
> without
> any locking.  I also fear we'll be introducing new performance issues with
> all the additonal spinlock bouncing, despite the fact that is only ever
> needed for migration.  I'm going to continue looking into this today and
> will try to send out a followup to this email later.

 In the beginning of aio_read_events_ring(), it reads head and tail, not 
 write.
 So even if ring pages are migrated, the contents of the pages will not 
 be changed.
 So reading it is OK, from old page or from the new page, I think.
>>>
>>> Your assumption that reading it is okay is incorrect.  Since we do not have 
>>> a reference on the page at that point, it is possible that the read of the 
>>> page takes place after the page has been freed and allocated to another 
>>> part 
>>> of the kernel.  This would result in the read returning invalid information.
>>
>> What about the following patch? It adds additional reference to protect the 
>> page
>> avoid being freed when we reading it.
>> ps.It is applied on linux-next(3-13).
> 
> I think that's even worse than the spinlock approach since we'll end up 
> bouncing around the struct page's cacheline in addition to spinlock we're 
> going to end up taking anyways.

But we can not use spinlock approach to avoid this issue in 
aio_read_events_ring(),
because we need to copy events to user space. And on the other side, it will 
break
the concurrency of aio_read_events_ring() and aio_complete().
Besides, IMHO, the problem you mentioned above is almost insignificant when 
reading
events.
Any better solution? Other guys?

Regards,
Gu 

> 
>   -ben


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

cond_resched() and RCU CPU stall warnings

[Paul E. McKenney]

So I have been tightening up rcutorture a bit over the past year.
The other day, I came across what looked like a great opportunity for
further tightening, namely the schedule() in rcu_torture_reader().
Why not turn this into a cond_resched(), speeding up the readers a bit
and placing more stress on RCU?

And boy does it increase stress!

Unfortunately, this increased stress sometimes shows up in the form of
lots of RCU CPU stall warnings.  These can appear when an instance of
rcu_torture_reader() gets a CPU to itself, in which case it won't ever
enter the scheduler, and RCU will never see a quiescent state from that
CPU, which means the grace period never ends.

So I am taking a more measured approach to cond_resched() in
rcu_torture_reader() for the moment.

But longer term, should cond_resched() imply a set of RCU
quiescent states?  One way to do this would be to add calls to
rcu_note_context_switch() in each of the various cond_resched() functions.
Easy change, but of course adds some overhead.  On the other hand,
there might be more than a few of the 500+ calls to cond_resched() that
expect that RCU CPU stalls will be prevented (to say nothing of
might_sleep() and cond_resched_lock()).

Thoughts?

(Untested patch below, FWIW.)

Thanx, Paul



diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index b46131ef6aab..994d2b0fd0b2 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4075,6 +4075,9 @@ int __sched _cond_resched(void)
__cond_resched();
return 1;
}
+   preempt_disable();
+   rcu_note_context_switch(smp_processor_id());
+   preempt_enable();
return 0;
 }
 EXPORT_SYMBOL(_cond_resched);

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

[PATCHv4 4/7] mfd: twl-core: Add twl_i2c_read/write_u16

[Sebastian Reichel]

Add a simple twl_i2c_read/write_u16 wrapper over
the twl_i2c_read/write, which is similar to the
twl_i2c_read/write_u8 wrapper.

Signed-off-by: Sebastian Reichel 
Acked-by: Lee Jones 
Acked-by: Jonathan Cameron 
Tested-by: Marek Belisko 
---
 include/linux/i2c/twl.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index ade1c06..d2b1670 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -195,6 +195,18 @@ static inline int twl_i2c_read_u8(u8 mod_no, u8 *val, u8 
reg) {
return twl_i2c_read(mod_no, val, reg, 1);
 }
 
+static inline int twl_i2c_write_u16(u8 mod_no, u16 val, u8 reg) {
+   val = cpu_to_le16(val);
+   return twl_i2c_write(mod_no, (u8*) , reg, 2);
+}
+
+static inline int twl_i2c_read_u16(u8 mod_no, u16 *val, u8 reg) {
+   int ret;
+   ret = twl_i2c_read(mod_no, (u8*) val, reg, 2);
+   *val = le16_to_cpu(*val);
+   return ret;
+}
+
 int twl_get_type(void);
 int twl_get_version(void);
 int twl_get_hfclk_rate(void);
-- 
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/

[PATCHv4 6/7] Documentation: DT: Document twl4030-madc binding

[Sebastian Reichel]

Add devicetree binding documentation for twl4030-madc
analog digital converter.

Signed-off-by: Sebastian Reichel 
Acked-by: Jonathan Cameron 
---
 .../devicetree/bindings/iio/adc/twl4030-madc.txt   | 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/twl4030-madc.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/twl4030-madc.txt 
b/Documentation/devicetree/bindings/iio/adc/twl4030-madc.txt
new file mode 100644
index 000..6bdd214
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/twl4030-madc.txt
@@ -0,0 +1,24 @@
+* TWL4030 Monitoring Analog to Digital Converter (MADC)
+
+The MADC subsystem in the TWL4030 consists of a 10-bit ADC
+combined with a 16-input analog multiplexer.
+
+Required properties:
+  - compatible: Should contain "ti,twl4030-madc".
+  - interrupts: IRQ line for the MADC submodule.
+  - #io-channel-cells: Should be set to <1>.
+
+Optional properties:
+  - ti,system-uses-second-madc-irq: boolean, set if the second madc irq 
register
+   should be used, which is intended to be used
+   by Co-Processors (e.g. a modem).
+
+Example:
+
+ {
+   madc {
+   compatible = "ti,twl4030-madc";
+   interrupts = <3>;
+   #io-channel-cells = <1>;
+   };
+};
-- 
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/

[PATCHv4 3/7] mfd: twl4030-madc: Cleanup driver

[Sebastian Reichel]

Some style fixes in twl4030-madc driver.

Reported-by: Jonathan Cameron 
Reported-by: Lee Jones 
Signed-off-by: Sebastian Reichel 
Acked-by: Lee Jones 
Acked-by: Jonathan Cameron 
Tested-by: Marek Belisko 
---
 drivers/mfd/twl4030-madc.c   | 145 +++
 include/linux/i2c/twl4030-madc.h |   2 +-
 2 files changed, 73 insertions(+), 74 deletions(-)

diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c
index 93ef912..98b9c98 100644
--- a/drivers/mfd/twl4030-madc.c
+++ b/drivers/mfd/twl4030-madc.c
@@ -49,22 +49,22 @@
 
 #include 
 
-/*
+/**
  * struct twl4030_madc_data - a container for madc info
- * @dev - pointer to device structure for madc
- * @lock - mutex protecting this data structure
- * @requests - Array of request struct corresponding to SW1, SW2 and RT
- * @use_second_irq - IRQ selection (main or co-processor)
- * @imr - Interrupt mask register of MADC
- * @isr - Interrupt status register of MADC
+ * @dev:   Pointer to device structure for madc
+ * @lock:  Mutex protecting this data structure
+ * @requests:  Array of request struct corresponding to SW1, SW2 and RT
+ * @use_second_irq:IRQ selection (main or co-processor)
+ * @imr:   Interrupt mask register of MADC
+ * @isr:   Interrupt status register of MADC
  */
 struct twl4030_madc_data {
struct device *dev;
struct mutex lock;  /* mutex protecting this data structure */
struct twl4030_madc_request requests[TWL4030_MADC_NUM_METHODS];
bool use_second_irq;
-   int imr;
-   int isr;
+   u8 imr;
+   u8 isr;
 };
 
 static int twl4030_madc_read(struct iio_dev *iio_dev,
@@ -155,17 +155,16 @@ twl4030_divider_ratios[16] = {
 };
 
 
-/*
- * Conversion table from -3 to 55 degree Celcius
- */
-static int therm_tbl[] = {
-30800, 29500,  28300,  27100,
-26000, 24900,  23900,  22900,  22000,  21100,  20300,  19400,  18700,  17900,
-17200, 16500,  15900,  15300,  14700,  14100,  13600,  13100,  12600,  12100,
-11600, 11200,  10800,  10400,  1,  9630,   9280,   8950,   8620,   8310,
-8020,  7730,   7460,   7200,   6950,   6710,   6470,   6250,   6040,   5830,
-5640,  5450,   5260,   5090,   4920,   4760,   4600,   4450,   4310,   4170,
-4040,  3910,   3790,   3670,   3550
+/* Conversion table from -3 to 55 degrees Celcius */
+static int twl4030_therm_tbl[] = {
+   30800,  29500,  28300,  27100,
+   26000,  24900,  23900,  22900,  22000,  21100,  20300,  19400,  18700,
+   17900,  17200,  16500,  15900,  15300,  14700,  14100,  13600,  13100,
+   12600,  12100,  11600,  11200,  10800,  10400,  1,  9630,   9280,
+   8950,   8620,   8310,   8020,   7730,   7460,   7200,   6950,   6710,
+   6470,   6250,   6040,   5830,   5640,   5450,   5260,   5090,   4920,
+   4760,   4600,   4450,   4310,   4170,   4040,   3910,   3790,   3670,
+   3550
 };
 
 /*
@@ -197,11 +196,12 @@ const struct twl4030_madc_conversion_method 
twl4030_conversion_methods[] = {
  },
 };
 
-/*
- * Function to read a particular channel value.
- * @madc - pointer to struct twl4030_madc_data
- * @reg - lsb of ADC Channel
- * If the i2c read fails it returns an error else returns 0.
+/**
+ * twl4030_madc_channel_raw_read() - Function to read a particular channel 
value
+ * @madc:  pointer to struct twl4030_madc_data
+ * @reg:   lsb of ADC Channel
+ *
+ * Return: 0 on success, an error code otherwise.
  */
 static int twl4030_madc_channel_raw_read(struct twl4030_madc_data *madc, u8 
reg)
 {
@@ -227,7 +227,7 @@ static int twl4030_madc_channel_raw_read(struct 
twl4030_madc_data *madc, u8 reg)
 }
 
 /*
- * Return battery temperature
+ * Return battery temperature in degrees Celsius
  * Or < 0 on failure.
  */
 static int twl4030battery_temperature(int raw_volt)
@@ -236,18 +236,18 @@ static int twl4030battery_temperature(int raw_volt)
int temp, curr, volt, res, ret;
 
volt = (raw_volt * TEMP_STEP_SIZE) / TEMP_PSR_R;
-   /* Getting and calculating the supply current in micro ampers */
+   /* Getting and calculating the supply current in micro amperes */
ret = twl_i2c_read_u8(TWL_MODULE_MAIN_CHARGE, ,
REG_BCICTL2);
if (ret < 0)
return ret;
+
curr = ((val & TWL4030_BCI_ITHEN) + 1) * 10;
/* Getting and calculating the thermistor resistance in ohms */
res = volt * 1000 / curr;
/* calculating temperature */
for (temp = 58; temp >= 0; temp--) {
-   int actual = therm_tbl[temp];
-
+   int actual = twl4030_therm_tbl[temp];
if ((actual - res) >= 0)
break;
}
@@ -269,11 +269,12 @@ static int twl4030battery_current(int raw_volt)
else /* slope of 0.88 mV/mA */
return (raw_volt * CURR_STEP_SIZE) / CURR_PSR_R2;
 }
+
 /*
  * Function to read channel values
  * @madc - pointer to 

[PATCHv4 5/7] mfd: twl4030-madc: Use twl_i2c_read/write_u16 for 16 bit registers

[Sebastian Reichel]

Simplify reading and writing of 16 bit TWL registers in the
driver by using twl_i2c_read_u16 and twl_i2c_write_u16.

Signed-off-by: Sebastian Reichel 
Acked-by: Lee Jones 
Acked-by: Jonathan Cameron 
Tested-by: Marek Belisko 
---
 drivers/mfd/twl4030-madc.c | 39 ---
 1 file changed, 8 insertions(+), 31 deletions(-)

diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c
index 98b9c98..8a014fb 100644
--- a/drivers/mfd/twl4030-madc.c
+++ b/drivers/mfd/twl4030-madc.c
@@ -205,25 +205,19 @@ const struct twl4030_madc_conversion_method 
twl4030_conversion_methods[] = {
  */
 static int twl4030_madc_channel_raw_read(struct twl4030_madc_data *madc, u8 
reg)
 {
-   u8 msb, lsb;
+   u16 val;
int ret;
/*
 * For each ADC channel, we have MSB and LSB register pair. MSB address
 * is always LSB address+1. reg parameter is the address of LSB register
 */
-   ret = twl_i2c_read_u8(TWL4030_MODULE_MADC, , reg + 1);
+   ret = twl_i2c_read_u16(TWL4030_MODULE_MADC, , reg);
if (ret) {
-   dev_err(madc->dev, "unable to read MSB register 0x%X\n",
-   reg + 1);
-   return ret;
-   }
-   ret = twl_i2c_read_u8(TWL4030_MODULE_MADC, , reg);
-   if (ret) {
-   dev_err(madc->dev, "unable to read LSB register 0x%X\n", reg);
+   dev_err(madc->dev, "unable to read register 0x%X\n", reg);
return ret;
}
 
-   return (int)(((msb << 8) | lsb) >> 6);
+   return (int)(val >> 6);
 }
 
 /*
@@ -572,7 +566,6 @@ static int twl4030_madc_wait_conversion_ready(struct 
twl4030_madc_data *madc,
 int twl4030_madc_conversion(struct twl4030_madc_request *req)
 {
const struct twl4030_madc_conversion_method *method;
-   u8 ch_msb, ch_lsb;
int ret;
 
if (!req || !twl4030_madc)
@@ -588,37 +581,21 @@ int twl4030_madc_conversion(struct twl4030_madc_request 
*req)
ret = -EBUSY;
goto out;
}
-   ch_msb = (req->channels >> 8) & 0xff;
-   ch_lsb = req->channels & 0xff;
method = _conversion_methods[req->method];
/* Select channels to be converted */
-   ret = twl_i2c_write_u8(TWL4030_MODULE_MADC, ch_msb, method->sel + 1);
+   ret = twl_i2c_write_u16(TWL4030_MODULE_MADC, req->channels, 
method->sel);
if (ret) {
dev_err(twl4030_madc->dev,
-   "unable to write sel register 0x%X\n", method->sel + 1);
-   goto out;
-   }
-   ret = twl_i2c_write_u8(TWL4030_MODULE_MADC, ch_lsb, method->sel);
-   if (ret) {
-   dev_err(twl4030_madc->dev,
-   "unable to write sel register 0x%X\n", method->sel + 1);
+   "unable to write sel register 0x%X\n", method->sel);
goto out;
}
/* Select averaging for all channels if do_avg is set */
if (req->do_avg) {
-   ret = twl_i2c_write_u8(TWL4030_MODULE_MADC,
-  ch_msb, method->avg + 1);
+   ret = twl_i2c_write_u16(TWL4030_MODULE_MADC, req->channels,
+  method->avg);
if (ret) {
dev_err(twl4030_madc->dev,
"unable to write avg register 0x%X\n",
-   method->avg + 1);
-   goto out;
-   }
-   ret = twl_i2c_write_u8(TWL4030_MODULE_MADC,
-  ch_lsb, method->avg);
-   if (ret) {
-   dev_err(twl4030_madc->dev,
-   "unable to write avg reg 0x%X\n",
method->avg);
goto out;
}
-- 
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/

[PATCHv4 2/7] mfd: twl4030-madc: Add DT support and convert to IIO framework

[Sebastian Reichel]

This converts twl4030-madc module to use the Industrial IO ADC
framework and adds device tree support.

Signed-off-by: Sebastian Reichel 
Tested-by: Marek Belisko 
Acked-by: Lee Jones 
Acked-by: Jonathan Cameron 
---
 drivers/mfd/twl4030-madc.c | 127 +
 1 file changed, 116 insertions(+), 11 deletions(-)

diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c
index 5458561..93ef912 100644
--- a/drivers/mfd/twl4030-madc.c
+++ b/drivers/mfd/twl4030-madc.c
@@ -47,11 +47,14 @@
 #include 
 #include 
 
+#include 
+
 /*
  * struct twl4030_madc_data - a container for madc info
  * @dev - pointer to device structure for madc
  * @lock - mutex protecting this data structure
  * @requests - Array of request struct corresponding to SW1, SW2 and RT
+ * @use_second_irq - IRQ selection (main or co-processor)
  * @imr - Interrupt mask register of MADC
  * @isr - Interrupt status register of MADC
  */
@@ -59,10 +62,71 @@ struct twl4030_madc_data {
struct device *dev;
struct mutex lock;  /* mutex protecting this data structure */
struct twl4030_madc_request requests[TWL4030_MADC_NUM_METHODS];
+   bool use_second_irq;
int imr;
int isr;
 };
 
+static int twl4030_madc_read(struct iio_dev *iio_dev,
+const struct iio_chan_spec *chan,
+int *val, int *val2, long mask)
+{
+   struct twl4030_madc_data *madc = iio_priv(iio_dev);
+   struct twl4030_madc_request req;
+   int ret;
+
+   req.method = madc->use_second_irq ? TWL4030_MADC_SW2 : TWL4030_MADC_SW1;
+
+   req.channels = BIT(chan->channel);
+   req.active = false;
+   req.func_cb = NULL;
+   req.type = TWL4030_MADC_WAIT;
+   req.raw = !(mask == IIO_CHAN_INFO_PROCESSED);
+   req.do_avg = (mask == IIO_CHAN_INFO_AVERAGE_RAW);
+
+   ret = twl4030_madc_conversion();
+   if (ret < 0)
+   return ret;
+
+   *val = req.rbuf[chan->channel];
+
+   return IIO_VAL_INT;
+}
+
+static const struct iio_info twl4030_madc_iio_info = {
+   .read_raw = _madc_read,
+   .driver_module = THIS_MODULE,
+};
+
+#define TWL4030_ADC_CHANNEL(_channel, _type, _name) {  \
+   .type = _type,  \
+   .channel = _channel,\
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |  \
+ BIT(IIO_CHAN_INFO_AVERAGE_RAW) | \
+ BIT(IIO_CHAN_INFO_PROCESSED), \
+   .datasheet_name = _name,\
+   .indexed = 1,   \
+}
+
+static const struct iio_chan_spec twl4030_madc_iio_channels[] = {
+   TWL4030_ADC_CHANNEL(0, IIO_VOLTAGE, "ADCIN0"),
+   TWL4030_ADC_CHANNEL(1, IIO_TEMP, "ADCIN1"),
+   TWL4030_ADC_CHANNEL(2, IIO_VOLTAGE, "ADCIN2"),
+   TWL4030_ADC_CHANNEL(3, IIO_VOLTAGE, "ADCIN3"),
+   TWL4030_ADC_CHANNEL(4, IIO_VOLTAGE, "ADCIN4"),
+   TWL4030_ADC_CHANNEL(5, IIO_VOLTAGE, "ADCIN5"),
+   TWL4030_ADC_CHANNEL(6, IIO_VOLTAGE, "ADCIN6"),
+   TWL4030_ADC_CHANNEL(7, IIO_VOLTAGE, "ADCIN7"),
+   TWL4030_ADC_CHANNEL(8, IIO_VOLTAGE, "ADCIN8"),
+   TWL4030_ADC_CHANNEL(9, IIO_VOLTAGE, "ADCIN9"),
+   TWL4030_ADC_CHANNEL(10, IIO_CURRENT, "ADCIN10"),
+   TWL4030_ADC_CHANNEL(11, IIO_VOLTAGE, "ADCIN11"),
+   TWL4030_ADC_CHANNEL(12, IIO_VOLTAGE, "ADCIN12"),
+   TWL4030_ADC_CHANNEL(13, IIO_VOLTAGE, "ADCIN13"),
+   TWL4030_ADC_CHANNEL(14, IIO_VOLTAGE, "ADCIN14"),
+   TWL4030_ADC_CHANNEL(15, IIO_VOLTAGE, "ADCIN15"),
+};
+
 static struct twl4030_madc_data *twl4030_madc;
 
 struct twl4030_prescale_divider_ratios {
@@ -702,28 +766,49 @@ static int twl4030_madc_probe(struct platform_device 
*pdev)
 {
struct twl4030_madc_data *madc;
struct twl4030_madc_platform_data *pdata = dev_get_platdata(>dev);
+   struct device_node *np = pdev->dev.of_node;
int irq, ret;
u8 regval;
+   struct iio_dev *iio_dev = NULL;
 
-   if (!pdata) {
-   dev_err(>dev, "platform_data not available\n");
+   if (!pdata && !np) {
+   dev_err(>dev, "neither platform data nor Device Tree node 
available\n");
return -EINVAL;
}
-   madc = devm_kzalloc(>dev, sizeof(*madc), GFP_KERNEL);
-   if (!madc)
+
+   iio_dev = devm_iio_device_alloc(>dev, sizeof(*madc));
+   if (!iio_dev) {
+   dev_err(>dev, "failed allocating iio device\n");
return -ENOMEM;
+   }
 
+   madc = iio_priv(iio_dev);
madc->dev = >dev;
 
+   iio_dev->name = dev_name(>dev);
+   iio_dev->dev.parent = >dev;
+   iio_dev->dev.of_node = pdev->dev.of_node;
+   iio_dev->info = _madc_iio_info;
+   iio_dev->modes = INDIO_DIRECT_MODE;
+   iio_dev->channels = twl4030_madc_iio_channels;
+   iio_dev->num_channels = ARRAY_SIZE(twl4030_madc_iio_channels);
+
/*
 * 

[PATCHv4 1/7] mfd: twl4030-madc: Use managed resources

[Sebastian Reichel]

Update twl4030-madc driver to use managed resources.

Signed-off-by: Sebastian Reichel 
Acked-by: Lee Jones 
Acked-by: Jonathan Cameron 
Tested-by: Marek Belisko 
---
 drivers/mfd/twl4030-madc.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c
index 4c583e4..5458561 100644
--- a/drivers/mfd/twl4030-madc.c
+++ b/drivers/mfd/twl4030-madc.c
@@ -702,14 +702,14 @@ static int twl4030_madc_probe(struct platform_device 
*pdev)
 {
struct twl4030_madc_data *madc;
struct twl4030_madc_platform_data *pdata = dev_get_platdata(>dev);
-   int ret;
+   int irq, ret;
u8 regval;
 
if (!pdata) {
dev_err(>dev, "platform_data not available\n");
return -EINVAL;
}
-   madc = kzalloc(sizeof(*madc), GFP_KERNEL);
+   madc = devm_kzalloc(>dev, sizeof(*madc), GFP_KERNEL);
if (!madc)
return -ENOMEM;
 
@@ -726,7 +726,7 @@ static int twl4030_madc_probe(struct platform_device *pdev)
TWL4030_MADC_ISR1 : TWL4030_MADC_ISR2;
ret = twl4030_madc_set_power(madc, 1);
if (ret < 0)
-   goto err_power;
+   return ret;
ret = twl4030_madc_set_current_generator(madc, 0, 1);
if (ret < 0)
goto err_current_generator;
@@ -770,7 +770,9 @@ static int twl4030_madc_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, madc);
mutex_init(>lock);
-   ret = request_threaded_irq(platform_get_irq(pdev, 0), NULL,
+
+   irq = platform_get_irq(pdev, 0);
+   ret = devm_request_threaded_irq(>dev, irq, NULL,
   twl4030_madc_threaded_irq_handler,
   IRQF_TRIGGER_RISING, "twl4030_madc", madc);
if (ret) {
@@ -783,9 +785,6 @@ err_i2c:
twl4030_madc_set_current_generator(madc, 0, 0);
 err_current_generator:
twl4030_madc_set_power(madc, 0);
-err_power:
-   kfree(madc);
-
return ret;
 }
 
@@ -793,10 +792,8 @@ static int twl4030_madc_remove(struct platform_device 
*pdev)
 {
struct twl4030_madc_data *madc = platform_get_drvdata(pdev);
 
-   free_irq(platform_get_irq(pdev, 0), madc);
twl4030_madc_set_current_generator(madc, 0, 0);
twl4030_madc_set_power(madc, 0);
-   kfree(madc);
 
return 0;
 }
-- 
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/

[PATCHv4 0/7] Convert twl4030-madc to IIO API and add DT support

[Sebastian Reichel]

Hi,

This is PATCHv4 for converting twl4030-madc to the IIO API and
adding DT support. The plan is to remove the private twl4030-madc
API once all users have been removed or converted to the IIO API.
The patchset compiles and has been tested on my Nokia N900.

Changes since PATCHv3 [0]:
 * Dropped the following patches (applied in iio tree)
  - iio: documentation: Add ABI documentation for *_mean_raw
  - iio: inkern: add iio_read_channel_average_raw
 * Added some more Acked-by from Jonathan Cameron
  - one of them on the basis of "Reorder that and I'm happy".
 * Changed some minor stuff requested by Jonathan
  - reorder cleanup calls in driver's remove function
  - convert another comment to kerneldoc

Status:
 * Only feedback from DT binding maintainers is missing.
   side note: The binding & the corresponding binding documentation
   patch has not changed since 2014-02-13. So depending on when the
   time frame starts the three weeks are over already ;)
 * It would be nice to see this patchset in 3.15.

[0] https://lkml.org/lkml/2014/3/10/727

-- Sebastian

Sebastian Reichel (7):
  mfd: twl4030-madc: Use managed resources
  mfd: twl4030-madc: Add DT support and convert to IIO framework
  mfd: twl4030-madc: Cleanup driver
  mfd: twl-core: Add twl_i2c_read/write_u16
  mfd: twl4030-madc: Use twl_i2c_read/write_u16 for 16 bit registers
  Documentation: DT: Document twl4030-madc binding
  mfd: twl4030-madc: Move driver to drivers/iio/adc

 .../devicetree/bindings/iio/adc/twl4030-madc.txt   |  24 ++
 drivers/iio/adc/Kconfig|  10 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/{mfd => iio/adc}/twl4030-madc.c| 320 +
 drivers/mfd/Kconfig|  10 -
 drivers/mfd/Makefile   |   1 -
 include/linux/i2c/twl.h|  12 +
 include/linux/i2c/twl4030-madc.h   |   2 +-
 8 files changed, 247 insertions(+), 133 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/twl4030-madc.txt
 rename drivers/{mfd => iio/adc}/twl4030-madc.c (74%)

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

[PATCHv4 7/7] mfd: twl4030-madc: Move driver to drivers/iio/adc

[Sebastian Reichel]

This is a driver for an A/D converter, which belongs into
drivers/iio/adc.

Signed-off-by: Sebastian Reichel 
Acked-by: Lee Jones 
Acked-by: Jonathan Cameron 
---
 drivers/iio/adc/Kconfig | 10 ++
 drivers/iio/adc/Makefile|  1 +
 drivers/{mfd => iio/adc}/twl4030-madc.c |  0
 drivers/mfd/Kconfig | 10 --
 drivers/mfd/Makefile|  1 -
 5 files changed, 11 insertions(+), 11 deletions(-)
 rename drivers/{mfd => iio/adc}/twl4030-madc.c (100%)

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/mfd/twl4030-madc.c b/drivers/iio/adc/twl4030-madc.c
similarity index 100%
rename from drivers/mfd/twl4030-madc.c
rename to drivers/iio/adc/twl4030-madc.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 49bb445..23a8a51 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -935,16 +935,6 @@ config TWL4030_CORE
  high speed USB OTG transceiver, an audio codec (on most
  versions) and many other features.
 
-config TWL4030_MADC
-   tristate "TI TWL4030 MADC"
-   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 be built as a module. If so it will be
-   named twl4030-madc
-
 config TWL4030_POWER
bool "TI TWL4030 power resources"
depends on TWL4030_CORE && ARM
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 5aea5ef..c8eb0bc 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -71,7 +71,6 @@ obj-$(CONFIG_MFD_TPS80031)+= tps80031.o
 obj-$(CONFIG_MENELAUS) += menelaus.o
 
 obj-$(CONFIG_TWL4030_CORE) += twl-core.o twl4030-irq.o twl6030-irq.o
-obj-$(CONFIG_TWL4030_MADC)  += twl4030-madc.o
 obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
 obj-$(CONFIG_MFD_TWL4030_AUDIO)+= twl4030-audio.o
 obj-$(CONFIG_TWL6040_CORE) += twl6040.o
-- 
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] autofs4: check dev ioctl size before allocating

[Sasha Levin]

There wasn't any check of the size passed from userspace before
trying to allocate the memory required.

This meant that userspace might request more space than allowed,
triggering an OOM.

Signed-off-by: Sasha Levin 
---
 fs/autofs4/dev-ioctl.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/fs/autofs4/dev-ioctl.c b/fs/autofs4/dev-ioctl.c
index 3182c0e..86fa7af 100644
--- a/fs/autofs4/dev-ioctl.c
+++ b/fs/autofs4/dev-ioctl.c
@@ -103,6 +103,9 @@ static struct autofs_dev_ioctl *copy_dev_ioctl(struct 
autofs_dev_ioctl __user *i
if (tmp.size < sizeof(tmp))
return ERR_PTR(-EINVAL);
 
+   if (tmp.size > (PATH_MAX + sizeof(tmp)))
+   return ERR_PTR(-E2BIG);
+
return memdup_user(in, tmp.size);
 }
 
-- 
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/

asus-nb-wmi: probe of asus-nb-wmi failed with error -5

[E R]

Hello all,

've run into this issue I've submitted a bug report for;

asus-nb-wmi: probe of asus-nb-wmi failed with error -5

https://bugzilla.kernel.org/show_bug.cgi?id=72131

Anyone have a clue here as to what is going on with this can help out?

Thank you...

EB
--
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: next-20140312 - build error in drivers/acpi/sleep.c

[David Rientjes]

On Fri, 14 Mar 2014, valdis.kletni...@vt.edu wrote:

> This appears to be fixed in next-20140314, with updated commit:
> 

Yes, I can no longer trigger the build errors, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RC6 Bell Chime] [PATCH 00/24] rfcomm fixes

[Linus Torvalds]

On Sat, Mar 15, 2014 at 1:45 PM, Peter Hurley  wrote:
>
> FWIW, the 'known breakage' for 3.14 is a (valid) lockdep report.

Ok, if it's just lockdep and unlikely to hit in real life and getting
fixed later, I guess I don't really care all that deeply for 3.14

  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/

[PATCH V2] ATHEROS-ALX: Use dma_set_mask_and_coherent and fix a bug

[Peter Senna Tschudin]

 1. For the 64 bits dma mask use dma_set_mask_and_coherent instead of
 dma_set_mask and dma_set_coherent_mask.

 2. For the 32 bits dma mask dma_set_coherent_mask is only called if
 dma_set_mask fails, which is unusual. Assuming this as a bug, fixes
 it by replacing calls to dma_set_mask and dma_set_coherent_mask by a
 call to dma_set_mask_and_coherent.
 
 Signed-off-by: Peter Senna Tschudin 
---

 Tested by compilation only.

 Change from V1: Updated commit message.

 drivers/net/ethernet/atheros/alx/main.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/atheros/alx/main.c 
b/drivers/net/ethernet/atheros/alx/main.c
index 2e45f6e..380d249 100644
--- a/drivers/net/ethernet/atheros/alx/main.c
+++ b/drivers/net/ethernet/atheros/alx/main.c
@@ -1248,19 +1248,13 @@ static int alx_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 * shared register for the high 32 bits, so only a single, aligned,
 * 4 GB physical address range can be used for descriptors.
 */
-   if (!dma_set_mask(>dev, DMA_BIT_MASK(64)) &&
-   !dma_set_coherent_mask(>dev, DMA_BIT_MASK(64))) {
+   if (!dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(64))) {
dev_dbg(>dev, "DMA to 64-BIT addresses\n");
} else {
-   err = dma_set_mask(>dev, DMA_BIT_MASK(32));
+   err = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(32));
if (err) {
-   err = dma_set_coherent_mask(>dev,
-   DMA_BIT_MASK(32));
-   if (err) {
-   dev_err(>dev,
-   "No usable DMA config, aborting\n");
-   goto out_pci_disable;
-   }
+   dev_err(>dev, "No usable DMA config, aborting\n");
+   goto out_pci_disable;
}
}
 
-- 
1.8.3.1

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

[PATCH] audit: get comm using lock to avoid race in string printing

[Richard Guy Briggs]

---
 kernel/audit.c   |5 ++---
 kernel/auditsc.c |9 +
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/kernel/audit.c b/kernel/audit.c
index 9239e5e..5b600c8 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1883,7 +1883,7 @@ EXPORT_SYMBOL(audit_log_task_context);
 void audit_log_task_info(struct audit_buffer *ab, struct task_struct *tsk)
 {
const struct cred *cred;
-   char name[sizeof(tsk->comm)];
+   char comm[sizeof(tsk->comm)];
struct mm_struct *mm = tsk->mm;
char *tty;
 
@@ -1917,9 +1917,8 @@ void audit_log_task_info(struct audit_buffer *ab, struct 
task_struct *tsk)
 from_kgid(_user_ns, cred->fsgid),
 tty, audit_get_sessionid(tsk));
 
-   get_task_comm(name, tsk);
audit_log_format(ab, " comm=");
-   audit_log_untrustedstring(ab, name);
+   audit_log_untrustedstring(ab, get_task_comm(name, tsk));
 
if (mm) {
down_read(>mmap_sem);
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 8fffca8..b789e0c 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2289,7 +2289,7 @@ void __audit_ptrace(struct task_struct *t)
context->target_uid = task_uid(t);
context->target_sessionid = audit_get_sessionid(t);
security_task_getsecid(t, >target_sid);
-   memcpy(context->target_comm, t->comm, TASK_COMM_LEN);
+   get_task_comm(context->target_comm, t);
 }
 
 /**
@@ -2328,7 +2328,7 @@ int __audit_signal_info(int sig, struct task_struct *t)
ctx->target_uid = t_uid;
ctx->target_sessionid = audit_get_sessionid(t);
security_task_getsecid(t, >target_sid);
-   memcpy(ctx->target_comm, t->comm, TASK_COMM_LEN);
+   get_task_comm(ctx->target_comm, t);
return 0;
}
 
@@ -2349,7 +2349,7 @@ int __audit_signal_info(int sig, struct task_struct *t)
axp->target_uid[axp->pid_count] = t_uid;
axp->target_sessionid[axp->pid_count] = audit_get_sessionid(t);
security_task_getsecid(t, >target_sid[axp->pid_count]);
-   memcpy(axp->target_comm[axp->pid_count], t->comm, TASK_COMM_LEN);
+   get_task_comm(axp->target_comm[axp->pid_count], t);
axp->pid_count++;
 
return 0;
@@ -2435,6 +2435,7 @@ static void audit_log_task(struct audit_buffer *ab)
kgid_t gid;
unsigned int sessionid;
struct mm_struct *mm = current->mm;
+   char comm[sizeof(current->comm)];
 
auid = audit_get_loginuid(current);
sessionid = audit_get_sessionid(current);
@@ -2447,7 +2448,7 @@ static void audit_log_task(struct audit_buffer *ab)
 sessionid);
audit_log_task_context(ab);
audit_log_format(ab, " pid=%d comm=", task_pid_nr(current));
-   audit_log_untrustedstring(ab, current->comm);
+   audit_log_untrustedstring(ab, get_task_comm(comm, current);
if (mm) {
down_read(>mmap_sem);
if (mm->exe_file)
-- 
1.7.1

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

[PATCH] audit: copy comm to avoid race in string printing

[Richard Guy Briggs]

---
 kernel/audit.c   |5 ++---
 kernel/auditsc.c |3 ++-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/audit.c b/kernel/audit.c
index 9239e5e..ecb08a5 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1883,7 +1883,7 @@ EXPORT_SYMBOL(audit_log_task_context);
 void audit_log_task_info(struct audit_buffer *ab, struct task_struct *tsk)
 {
const struct cred *cred;
-   char name[sizeof(tsk->comm)];
+   char comm[sizeof(tsk->comm)];
struct mm_struct *mm = tsk->mm;
char *tty;
 
@@ -1917,9 +1917,8 @@ void audit_log_task_info(struct audit_buffer *ab, struct 
task_struct *tsk)
 from_kgid(_user_ns, cred->fsgid),
 tty, audit_get_sessionid(tsk));
 
-   get_task_comm(name, tsk);
audit_log_format(ab, " comm=");
-   audit_log_untrustedstring(ab, name);
+   audit_log_untrustedstring(ab, memcpy(comm, tsk->comm, sizeof(comm));
 
if (mm) {
down_read(>mmap_sem);
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 8fffca8..dcddadd 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -2434,6 +2434,7 @@ static void audit_log_task(struct audit_buffer *ab)
kuid_t auid, uid;
kgid_t gid;
unsigned int sessionid;
+   char comm[sizeof(current->comm)];
struct mm_struct *mm = current->mm;
 
auid = audit_get_loginuid(current);
@@ -2447,7 +2448,7 @@ static void audit_log_task(struct audit_buffer *ab)
 sessionid);
audit_log_task_context(ab);
audit_log_format(ab, " pid=%d comm=", task_pid_nr(current));
-   audit_log_untrustedstring(ab, current->comm);
+   audit_log_untrustedstring(ab, memcpy(comm, current->comm, sizeof(comm));
if (mm) {
down_read(>mmap_sem);
if (mm->exe_file)
-- 
1.7.1

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

race in audit_log_untrusted_string for task_struct::comm

[Richard Guy Briggs]

Hi,

I'm investigating a race in audit_log_untrusted_string() in the case of
task_struct::comm.

Originally from commit 0a4ff8c2 audit_log_task() currently hands
task_struct::comm directly to audit_log_untrusted_string() which can
race if another task/thread on another CPU modifies it between the time
strlen() is called on it and the time it is processed in
audit_log_n_untrustedstring().  I originally thought it was just a
matter of the value being truncated or mixed between old and new values,
but it appears it is worse than that in that it causes following labels
to be dropped.  If it just affected the value of comm that was printed,
I am guessing this wouldn't be a big deal since the user can modify this
value anyway and we never did trust it.  however, since it affects the
rest of the line, it has to be addressed.

In commit 219f0817 from 2005, Stephen Smalley used get_task_comm() to
get the value of comm to log to audit_log_untrusted_string() which calls
the task_lock.  This is quite safe, but incurs overhead that may not be
found acceptable by some.

Eric subsequently used memcpy() in c2a7780e in 2008 in another area of the
code that stores the value for later rather than use it immediately, so
the race issue was not present there, but there is still the danger of
incomplete or mixed text in that field.

Both are safe in terms of avoiding losing other fields.  One might have
half-inconsistent information in it, the other incurs locking costs. 

I'm inclined to go get_task_comm() in all 5 locations, but if we care
more about locking overhead, I'll switch to memcpy().

Steve, do we care about the integrity of the comm field?
Eric, is the overhead of task_lock unacceptable?

Linked in this thread (should I be able to convince git send-email to
work with me) please find the get_task_comm() patch and the alternate
memcpy() patch.


- RGB

--
Richard Guy Briggs 
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red 
Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
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] ATHEROS-ALX: Use dma_set_mask_and_coherent and fix a bug

[Sergei Shtylyov]

Hello.

On 03/15/2014 09:19 PM, Peter Senna Tschudin wrote:


  1. For the 64 bits dma mask use dma_set_mask_and_coherent instead of
  dma_set_mask and dma_set_coherent_mask.



  2. For the 32 bits dma mask dma_set_coherent_mask is only called if
  dma_set_mask fails, which is unusual. Assuming this as a bug, fixes
  it by replacing calls to dma_set_mask and dma_set_coherent_mask by a
  call to dma_set_coherent_mask.


   You meant to say dma_set_mask_and_coherent() here?


  Signed-off-by: Peter Senna Tschudin 
---



  Tested by compilation only.



  drivers/net/ethernet/atheros/alx/main.c | 14 --
  1 file changed, 4 insertions(+), 10 deletions(-)



diff --git a/drivers/net/ethernet/atheros/alx/main.c 
b/drivers/net/ethernet/atheros/alx/main.c
index 2e45f6e..380d249 100644
--- a/drivers/net/ethernet/atheros/alx/main.c
+++ b/drivers/net/ethernet/atheros/alx/main.c
@@ -1248,19 +1248,13 @@ static int alx_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 * shared register for the high 32 bits, so only a single, aligned,
 * 4 GB physical address range can be used for descriptors.
 */
-   if (!dma_set_mask(>dev, DMA_BIT_MASK(64)) &&
-   !dma_set_coherent_mask(>dev, DMA_BIT_MASK(64))) {
+   if (!dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(64))) {
dev_dbg(>dev, "DMA to 64-BIT addresses\n");
} else {
-   err = dma_set_mask(>dev, DMA_BIT_MASK(32));
+   err = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(32));
if (err) {
-   err = dma_set_coherent_mask(>dev,
-   DMA_BIT_MASK(32));
-   if (err) {
-   dev_err(>dev,
-   "No usable DMA config, aborting\n");
-   goto out_pci_disable;
-   }
+   dev_err(>dev, "No usable DMA config, aborting\n");
+   goto out_pci_disable;
}
}


WBR, Sergei


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

Re: [PATCH 0/2] KVM: x86 emulator: emulate MOVAPS and MOVAPD SSE instructions

[H. Peter Anvin]

Stupid question... what instructions do NOT need emulsion in KVM? It would seem 
that at least anything that touches memory would?

On March 15, 2014 1:01:58 PM PDT, Igor Mammedov  wrote:
>MS HCK test fails on 32-bit Windows 8.1 due to missing MOVAPS
>instruction emulation, this series adds it and while at it,
>it adds emulation of MOVAPD which is trivial to implement on
>top of MOVAPS.
>
>Igor Mammedov (2):
>  KVM: x86 emulator: emulate MOVAPS
>  KVM: x86 emulator: emulate MOVAPD
>
> arch/x86/kvm/emulate.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)

-- 
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: [PATCH 0/2] KVM: x86 emulator: emulate MOVAPS and MOVAPD SSE instructions

[H. Peter Anvin]

MOVAPS, MOVAPD, and MOVDQA are the same operation.  They may, architecturally, 
have different performance characteristics, but nothing that would affect an 
emulator.

On March 15, 2014 1:01:58 PM PDT, Igor Mammedov  wrote:
>MS HCK test fails on 32-bit Windows 8.1 due to missing MOVAPS
>instruction emulation, this series adds it and while at it,
>it adds emulation of MOVAPD which is trivial to implement on
>top of MOVAPS.
>
>Igor Mammedov (2):
>  KVM: x86 emulator: emulate MOVAPS
>  KVM: x86 emulator: emulate MOVAPD
>
> arch/x86/kvm/emulate.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)

-- 
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: [RC6 Bell Chime] [PATCH 00/24] rfcomm fixes

[Sander Eikelenboom]

Saturday, March 15, 2014, 9:45:03 PM, you wrote:

> On 03/15/2014 01:53 PM, Linus Torvalds wrote:
>> Guys, why is this being discussed?

> FWIW, the 'known breakage' for 3.14 is a (valid) lockdep report.

Hmm .. whoops you are right .. i remembered it as being an "oops",
but you are right it was merely an lockdep warning.
Should have checked that before putting up my big mouth .. sorry for that!

> This regression was introduced by a small patchset added to -next
> over the holidays that was intended to address 2 bug reports
> stemming from a long-overdue overhaul of the RFCOMM tty driver by
> Gianluca Anzolin (which fixed numerous problems and several hangs
> reported since 3.8).

Ok if what went in for 3.14 fixes some hangs that should probably outweigh
the lockdep warning regression.

> It is the bulk of that small patchset which is being reverted.

> The point of this brief history is that:
> 1) the 3.13 state of rfcomm is just as broken as 3.14-rcX, but
> in a different way
> 2) there are plenty of serious defects in both versions regardless.

> I mean for this to be informative and not argumentative --
> either outcome is ok with me. In fact, I'm ok if you want to
> pick my entire 24-patch series that addresses the bugs in 3.13
> and 3.14, plus a bunch of other problems that I found at the time.

> Regards,
> Peter Hurley



--
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: [Suggestion] Makefile: about allmodconfig issue.

[Randy Dunlap]

On 03/15/2014 02:30 PM, Chen Gang wrote:
> On 03/11/2014 09:08 AM, Chen Gang wrote:
>> On 03/10/2014 12:24 AM, Randy Dunlap wrote:
>>> On 03/09/2014 08:02 AM, Chen Gang wrote:
> [...]
 Else ('depends on' priority is higher than 'select')

  - some architectures can choose whether support IRQ_DOMAIN.

  - if IRQ_DOMAIN enabled, our gpio driver can be used, and then select
GENERIC_IRQ_CHIP (need not consider about it selects IRQ_DOMAIN).

  - else (IRQ_DOMAIN_disabled), we can not use our gpio driver, and also
can not select GENERIC_IRQ_CHIP (need not consider about it selects
IRQ_DOMAIN, either).

 Excuse me, I am not quite familiar with Kconfig grammar, can any members
 give a confirmation for it (whether 'select' priority is higher or equal
 than 'depends on').
>>>
>>> Sorry, I don't really understand the problem that you are trying to solve.
>>> Maybe you could back up and explain the underlying problem... ?
>>>
>>
>> If the fix patch applied (don't depend on IRQ_DOMAIN), I guess, if one
>> architecture don't support IRQ_DOMAIN, GPIO_DWAPB may still be enabled
>> and then let IRQ_DOMAIN enable too.
>>
> 
> Is it possible to still go further? For me, I still think, this is not
> gpio driver's issue, the kbuild need be improved to support this using case.
> 
> So, if it is necessary, I will/should try to go further about it.


If you can demonstrate a problem, then please submit a patch for it,
but don't just hypothesize a problem, actually show that there is one.


-- 
~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: [Suggestion] Makefile: about allmodconfig issue.

[Chen Gang]

On 03/11/2014 09:08 AM, Chen Gang wrote:
> On 03/10/2014 12:24 AM, Randy Dunlap wrote:
>> On 03/09/2014 08:02 AM, Chen Gang wrote:
[...]
>>> Else ('depends on' priority is higher than 'select')
>>>
>>>  - some architectures can choose whether support IRQ_DOMAIN.
>>>
>>>  - if IRQ_DOMAIN enabled, our gpio driver can be used, and then select
>>>GENERIC_IRQ_CHIP (need not consider about it selects IRQ_DOMAIN).
>>>
>>>  - else (IRQ_DOMAIN_disabled), we can not use our gpio driver, and also
>>>can not select GENERIC_IRQ_CHIP (need not consider about it selects
>>>IRQ_DOMAIN, either).
>>>
>>> Excuse me, I am not quite familiar with Kconfig grammar, can any members
>>> give a confirmation for it (whether 'select' priority is higher or equal
>>> than 'depends on').
>>
>> Sorry, I don't really understand the problem that you are trying to solve.
>> Maybe you could back up and explain the underlying problem... ?
>>
> 
> If the fix patch applied (don't depend on IRQ_DOMAIN), I guess, if one
> architecture don't support IRQ_DOMAIN, GPIO_DWAPB may still be enabled
> and then let IRQ_DOMAIN enable too.
> 

Is it possible to still go further? For me, I still think, this is not
gpio driver's issue, the kbuild need be improved to support this using case.

So, if it is necessary, I will/should try to go further about it.


Thanks.
-- 
Chen Gang

Open, share and attitude like air, water and life which God blessed
--
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] iio: adc: at91_adc: correct default shtim value

[Alexandre Belloni]

Hi,

On 15/03/2014 at 16:34:02 +, Jonathan Cameron wrote :
> Applied to the fixes-togreg branch of iio.git.
> Note that is likely that this will go upstream after the merge window now.
> 

I was aiming at 3.15 anyway.

Thanks for you help !

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

Re: [PATCH] arch/avr32/mm/cache.c: export symbol flush_icache_range() for module using

[Chen Gang]

On 03/09/2014 11:19 PM, Chen Gang wrote:
> On 03/09/2014 06:17 AM, Hans-Christian Egtvedt wrote:
>> Around Sun 09 Mar 2014 05:47:04 +0800 or thereabout, Chen Gang wrote:
>>>
>>> After this patch, our linux kernel can pass "avr32-linux-" allmodconfig
>>> (it contents quite a few of warnings, but after check, I guess they are
>>> not kernel's issue).
>>
>> That sounds great, I am a bit surprised however that the lkdtm module need
>> flush_icache_range. Would have been interesting to look into what causes this
>> dependency.
>>

After read a little more details for lkdtm, I guess "after overwrite an
executable area by do_nothing(), it needs flush_icache_range() to be
sure the new instructions/data must have effect with all cpu".

Welcome any additional information for it.

Thanks.

> 
> "driver/misc/lkdtm.c" will use this flush_icache_range().
> 
> And some architectures export it to modules.
> 
>   [root@gchen arch]# grep -rn flush_icache_range * | grep EXPORT
>   arm64/mm/flush.c:105:EXPORT_SYMBOL(flush_icache_range);
>   avr32/mm/cache.c:114:EXPORT_SYMBOL(flush_icache_range);
>   m68k/mm/cache.c:106:EXPORT_SYMBOL(flush_icache_range);
>   mn10300/mm/cache-inv-icache.c:129:EXPORT_SYMBOL(flush_icache_range);
>   mn10300/mm/cache-flush-icache.c:155:EXPORT_SYMBOL(flush_icache_range);
>   sparc/mm/init_64.c:435:EXPORT_SYMBOL(flush_icache_range);
> 
> 
> Welcome any more details information by any other members, thanks.
> 
> 

Thanks.
-- 
Chen Gang

Open, share and attitude like air, water and life which God blessed
--
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/1] remove cpqarray from mainline kernel

[Félix]

On Thu, Oct 17 2013, Jens Axboe wrote:
> On Thu, Oct 17 2013, Andrew Morton wrote:
> > On Thu, 17 Oct 2013 12:52:26 -0500 Mike Miller 
> wrote:
> >
> > > cpqarray hasn't been used in over 12 years. It's doubtful that
> > > anyone still uses the board. It's time the driver was removed from the
> mainline kernel.
> > > The only updates these days are minor and mostly done by people
> outside of HP.
> >
> > It's amazing the weird stuff people get up to.  Perhaps we should
> > disable it in config for a cycle or two, see if that flushes anyone out?
> 
> I think that would be prudent, you never know what people run...

Yes, I am still using a 16 years old Compaq server, and I need the 'cpqarray' 
module.
So please, don't delete it...

-- 
Félix Faisant

--
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: [RC6 Bell Chime] [PATCH 00/24] rfcomm fixes

[Peter Hurley]

On 03/15/2014 01:53 PM, Linus Torvalds wrote:

Guys, why is this being discussed?


FWIW, the 'known breakage' for 3.14 is a (valid) lockdep report.

This regression was introduced by a small patchset added to -next
over the holidays that was intended to address 2 bug reports
stemming from a long-overdue overhaul of the RFCOMM tty driver by
Gianluca Anzolin (which fixed numerous problems and several hangs
reported since 3.8).

It is the bulk of that small patchset which is being reverted.

The point of this brief history is that:
1) the 3.13 state of rfcomm is just as broken as 3.14-rcX, but
   in a different way
2) there are plenty of serious defects in both versions regardless.

I mean for this to be informative and not argumentative --
either outcome is ok with me. In fact, I'm ok if you want to
pick my entire 24-patch series that addresses the bugs in 3.13
and 3.14, plus a bunch of other problems that I found at the time.

Regards,
Peter Hurley

--
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] zram: include linux/err.h

[Arnd Bergmann]

On Saturday 15 March 2014, Sergey Senozhatsky wrote:
> On (03/15/14 10:40), Arnd Bergmann wrote:
> > The zram driver uses the ERR_PTR macro defined in 
> > and relies on this header to be included implicitly through
> > other headers, which is not (always) the case on the ARM architecture.
> > 
> 
> returned from zcomp ERR_PTR is checked and used in zram_drv.c, should
> in this case there also be inclusion of err.h in zram_drv.h? if so, it
> probably makes sense to move inclusion of err.h to zcomp.h, which is
> included both in zcomp.c and zram_drv.c
> 

The normal convention is to only include headers from other headers if
that is required by the contents of the header itself.

Following the common conventions, it's better to include linux/err.h
in both zram_drv.c and zcomp.c, but not in zram_drv.h.
I didn't do that in my patch, because I only got a build error in
one of the two files.

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

Re: [PATCH] backing_dev: Fix hung task on sync

[dbasehore .]

Resurrecting this for further discussion about the root of the problem.

mod_delayed_work_if_later addresses the problem one way, but the
problem is still there for mod_delayed_work. I think we could take
another approach that doesn't modify the API, but still addresses
(most of) the problem.

mod_delayed_work currently removes a work item from a workqueue if it
is on it. Correct me if I'm wrong, but I don't think that this is
necessarily required for mod_delayed_work to have the current
behavior. We should be able to set the timer while a delayed_work is
currently on a workqueue. If the delayed_work is still on the
workqueue when the timer goes off, everything is fine. If it has left
the workqueue, we can queue it again.

On Wed, Feb 19, 2014 at 11:01 AM, Tejun Heo  wrote:
> Hello, Jan.
>
> On Wed, Feb 19, 2014 at 10:27:31AM +0100, Jan Kara wrote:
>>   You are the workqueue expert so you may know better ;) But the way I
>> understand it is that queue_delayed_work() does nothing if the timer is
>> already running. Since we queue flusher work to run either immediately or
>> after dirty_writeback_interval we are safe to run queue_delayed_work()
>> whenever we want it to run after dirty_writeback_interval and
>> mod_delayed_work() whenever we want to run it immediately.
>
> Ah, okay, so it's always mod on immediate and queue on delayed.  Yeah,
> that should work.
>
>> But it's subtle and some interface where we could say queue delayed work
>> after no later than X would be easier to grasp.
>
> Yeah, I think it'd be better if we had something like
> mod_delayed_work_if_later().  Hmm...
>
> 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/

[PATCH] ia64: keep format strings from leaking into printk

[Kees Cook]

The buffer being sent to printk has already had format strings
resolved. The string should not be reinterpreted again to avoid any
unintended format strings from leaking into printk.

Signed-off-by: Kees Cook 
---
 arch/ia64/kernel/mca.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/ia64/kernel/mca.c b/arch/ia64/kernel/mca.c
index b8edfa75a83f..601502ab7141 100644
--- a/arch/ia64/kernel/mca.c
+++ b/arch/ia64/kernel/mca.c
@@ -217,7 +217,7 @@ void ia64_mca_printk(const char *fmt, ...)
/* Copy the output into mlogbuf */
if (oops_in_progress) {
/* mlogbuf was abandoned, use printk directly instead. */
-   printk(temp_buf);
+   printk("%s", temp_buf);
} else {
spin_lock(_wlock);
for (p = temp_buf; *p; p++) {
@@ -268,7 +268,7 @@ void ia64_mlogbuf_dump(void)
}
*p = '\0';
if (temp_buf[0])
-   printk(temp_buf);
+   printk("%s", temp_buf);
mlogbuf_start = index;
 
mlogbuf_timestamp = 0;
-- 
1.7.9.5


-- 
Kees Cook
Chrome OS Security
--
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 6/8] mfd: lpc_ich: Change Avoton to iTCO v3

[Wim Van Sebroeck]

Hi Peter,

> The register layout of the Avoton is compatible with the iTCO v3
> register layout.
> 
> Signed-off-by: Peter Tyser 
> Tested-by: Rajat Jain 
> Cc: Guenter Roeck 
> Cc: James Ralston 
> Cc: Samuel Ortiz 
> Cc: Lee Jones 
> Cc: Wim Van Sebroeck 
> Cc: linux-watch...@vger.kernel.org
> ---
>  drivers/mfd/lpc_ich.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 

Acked-by: Wim Van Sebroeck 

Kind regards,
Wim.

--
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 kvm-unit-tests 0/2] test MOVAPS and MOVAPD SSE instructions

[Igor Mammedov]

This series adds checks for MOVAPS and MOVAPD SSE instructions.
It's used by MS HCK test on 32-bit Windows 8.1

Igor Mammedov (2):
  emulator: movaps
  emulator: movapd

 x86/emulator.c | 14 ++
 1 file changed, 14 insertions(+)

-- 
1.8.5.3

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

[PATCH kvm-unit-tests 1/2] emulator: movaps

[Igor Mammedov]

Signed-off-by: Igor Mammedov 
---
 x86/emulator.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/x86/emulator.c b/x86/emulator.c
index 2e25dd8..1296a99 100644
--- a/x86/emulator.c
+++ b/x86/emulator.c
@@ -645,6 +645,13 @@ static void test_sse(sse_union *mem)
 mem->u[0] = 5; mem->u[1] = 6; mem->u[2] = 7; mem->u[3] = 8;
 asm("movdqu %1, %0" : "=x"(v.sse) : "m"(*mem));
 report("movdqu (write)", sseeq(mem, ));
+
+v.u[0] = 1; v.u[1] = 2; v.u[2] = 3; v.u[3] = 4;
+asm("movaps %1, %0" : "=m"(*mem) : "x"(v.sse));
+report("movaps (read)", sseeq(mem, ));
+mem->u[0] = 5; mem->u[1] = 6; mem->u[2] = 7; mem->u[3] = 8;
+asm("movaps %1, %0" : "=x"(v.sse) : "m"(*mem));
+report("movaps (write)", sseeq(, mem));
 }
 
 static void test_mmx(uint64_t *mem)
-- 
1.8.5.3

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

Re: [PATCH 4/8] mfd: lpc_ich: Add support for iTCO v3

[Wim Van Sebroeck]

Hi Peter,

> Some newer Atom CPUs, eg Avoton and Bay Trail, use slightly different
> register layouts for the iTCO than the current v1 and v2 iTCO.
> Differences from previous iTCO versions include:
> - The ACPI space is enabled in the "ACPI base address" register instead
>   of the "ACPI control register"
> 
> - The "no reboot" functionality is set in the "Power Management
>   Configuration" register instead of the "General Control and Status"
>   (GCS) register or PCI configuration space.
> 
> - The "ACPI Control Register" is not present on v3.  The "Power
>   Management Configuration Base Address" register resides at the same
>   address is Avoton/Bay Trail.
> 
> To differentiate these newer chipsets create a new v3 iTCO version and
> update the MFD driver to support them.
> 
> Signed-off-by: Peter Tyser 
> Tested-by: Rajat Jain 
> Cc: Guenter Roeck 
> Cc: James Ralston 
> Cc: Samuel Ortiz 
> Cc: Lee Jones 
> Cc: Wim Van Sebroeck 
> Cc: linux-watch...@vger.kernel.org
> ---
>  drivers/mfd/lpc_ich.c   |   81 +++---
>  include/linux/mfd/lpc_ich.h |8 ++--
>  2 files changed, 71 insertions(+), 18 deletions(-)
> 

Acked-by: Wim Van Sebroeck 

Kind regards,
Wim.

--
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 kvm-unit-tests 2/2] emulator: movapd

[Igor Mammedov]

Signed-off-by: Igor Mammedov 
---
 x86/emulator.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/x86/emulator.c b/x86/emulator.c
index 1296a99..388db99 100644
--- a/x86/emulator.c
+++ b/x86/emulator.c
@@ -652,6 +652,13 @@ static void test_sse(sse_union *mem)
 mem->u[0] = 5; mem->u[1] = 6; mem->u[2] = 7; mem->u[3] = 8;
 asm("movaps %1, %0" : "=x"(v.sse) : "m"(*mem));
 report("movaps (write)", sseeq(, mem));
+
+v.u[0] = 1; v.u[1] = 2; v.u[2] = 3; v.u[3] = 4;
+asm("movapd %1, %0" : "=m"(*mem) : "x"(v.sse));
+report("movapd (read)", sseeq(mem, ));
+mem->u[0] = 5; mem->u[1] = 6; mem->u[2] = 7; mem->u[3] = 8;
+asm("movapd %1, %0" : "=x"(v.sse) : "m"(*mem));
+report("movapd (write)", sseeq(, mem));
 }
 
 static void test_mmx(uint64_t *mem)
-- 
1.8.5.3

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

Re: [PATCH 5/8] watchdog: iTCO_wdt: Add support for v3 silicon

[Wim Van Sebroeck]

Hi Peter,

> Some new Atom's, eg Avoton and Bay Trail, have slightly different iTCO
> functionality:
> - The watchdog timer ticks at 1 second instead of .6 seconds
> 
> - Some 8 and 16-bit registers were combined into 32-bit registers
> 
> - Some registers were removed (DAT_IN, DAT_OUT, MESSAGE)
> 
> - The BOOT_STS field in TCO_STS was removed
> 
> - The NO_REBOOT bit is in the PMC area instead of GCS
> 
> Update the driver to support the above changes and bump the version to
> 1.11.
> 
> Signed-off-by: Peter Tyser 
> Tested-by: Rajat Jain 
> Cc: Guenter Roeck 
> Cc: James Ralston 
> Cc: Samuel Ortiz 
> Cc: Lee Jones 
> Cc: Wim Van Sebroeck 
> Cc: linux-watch...@vger.kernel.org

Signed-off-by: Wim Van Sebroeck 

Kind regards,
Wim.

--
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/2] KVM: x86 emulator: emulate MOVAPS

[Igor Mammedov]

HCK memory driver test fails when testing 32-bit Windows 8.1
with baloon driver.

tracing KVM shows error:
reason EXIT_ERR rip 0x81c18326 info 0 0

x/10i 0x81c18326-20
0x81c18312:  add%al,(%eax)
0x81c18314:  add%cl,-0x7127711d(%esi)
0x81c1831a:  rolb   $0x0,0x80ec(%ecx)
0x81c18321:  and$0xfff0,%esp
0x81c18324:  mov%esp,%esi
0x81c18326:  movaps %xmm0,(%esi)
0x81c18329:  movaps %xmm1,0x10(%esi)
0x81c1832d:  movaps %xmm2,0x20(%esi)
0x81c18331:  movaps %xmm3,0x30(%esi)
0x81c18335:  movaps %xmm4,0x40(%esi)

which points to MOVAPS instruction currently no emulated by KVM.
Fix it by adding appropriate entries to opcode table in KVM's emulator.

Signed-off-by: Igor Mammedov 
---
 arch/x86/kvm/emulate.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 07ffca0..a26d075 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -3668,6 +3668,10 @@ static const struct gprefix pfx_vmovntpx = {
I(0, em_mov), N, N, N,
 };
 
+static const struct gprefix pfx_0f_28_0f_29 = {
+   I(Aligned, em_mov), N, N, N,
+};
+
 static const struct escape escape_d9 = { {
N, N, N, N, N, N, N, I(DstMem, em_fnstcw),
 }, {
@@ -3870,7 +3874,9 @@ static const struct opcode twobyte_table[256] = {
IIP(ModRM | SrcMem | Priv | Op3264, em_cr_write, cr_write, 
check_cr_write),
IIP(ModRM | SrcMem | Priv | Op3264, em_dr_write, dr_write, 
check_dr_write),
N, N, N, N,
-   N, N, N, GP(ModRM | DstMem | SrcReg | Sse | Mov | Aligned, 
_vmovntpx),
+   GP(ModRM | DstReg | SrcMem | Mov | Sse, _0f_28_0f_29),
+   GP(ModRM | DstMem | SrcReg | Mov | Sse, _0f_28_0f_29),
+   N, GP(ModRM | DstMem | SrcReg | Sse | Mov | Aligned, _vmovntpx),
N, N, N, N,
/* 0x30 - 0x3F */
II(ImplicitOps | Priv, em_wrmsr, wrmsr),
-- 
1.8.5.3

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

[PATCH 2/2] KVM: x86 emulator: emulate MOVAPD

[Igor Mammedov]

Add emulation for 0x66 prefixed instruction of 0f 28 opcode
that has been added earlier.

Signed-off-by: Igor Mammedov 
---
 arch/x86/kvm/emulate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index a26d075..205b17e 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -3669,7 +3669,7 @@ static const struct gprefix pfx_vmovntpx = {
 };
 
 static const struct gprefix pfx_0f_28_0f_29 = {
-   I(Aligned, em_mov), N, N, N,
+   I(Aligned, em_mov), I(Aligned, em_mov), N, N,
 };
 
 static const struct escape escape_d9 = { {
-- 
1.8.5.3

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

[PATCH 0/2] KVM: x86 emulator: emulate MOVAPS and MOVAPD SSE instructions

[Igor Mammedov]

MS HCK test fails on 32-bit Windows 8.1 due to missing MOVAPS
instruction emulation, this series adds it and while at it,
it adds emulation of MOVAPD which is trivial to implement on
top of MOVAPS.

Igor Mammedov (2):
  KVM: x86 emulator: emulate MOVAPS
  KVM: x86 emulator: emulate MOVAPD

 arch/x86/kvm/emulate.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

-- 
1.8.5.3

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

Re: [PATCH v10 net-next 1/3] filter: add Extended BPF interpreter and converter

[Daniel Borkmann]

On 03/14/2014 09:08 PM, David Miller wrote:

From: Alexei Starovoitov 
Date: Fri, 14 Mar 2014 12:51:17 -0700


can you please explain why the status of these
patches is 'deferred' in patchwork ?
Is it because of bpf vs nft thread?
I think that's orthogonal.


I do not find it orthogonal, Pablo brings up some very valid points
which I agree with.

EBPF has a lot of the same user side interface limitations that the
existing BPF has, and you refuse to accept this core point Pablo is
making.

That is, that it lacks extensibility, and is too strongly tied to the
implementation.

This is exactly how we run into problems in the future, and you'll be
proposing EBPF_2.0 to address such problems.


Hm, so currently there's no interface where this is exposed to uapi,
and we surely can and should put the definitions back to the non-uapi
include to keep it inside the kernel, you're right.

I think, at least for me, the take-away of Alexei's work is, that
even (if we assume) without any further functionality, the new design
would greatly improve the interpreter (and presumably later on as
well JIT) performance based on Alexei's benchmarks, which would already
be a win for seccomp and socket filters and where ever they are being
used across the networking subsystem, and therefore out-of-the-box
without any changes for user space applications such as libpcap.

I was thinking that it could be an option to make this transparently
available to everyone, by just dropping the bpf_ext_enable knob, and
perhaps just replace the old BPF interpreter entirely in this set?
So the process would be: 1) test if normal BPF filter can be JIT'ed,
go for it, if it's not supported by JIT (or if it is disabled), run
it transparently in the new (non-exposed) BPF representation to have
a better overall performance.

Would that perhaps address the above concern? So on the big picture,
it provides a BPF performance improvement. I think if there's a wish
to extend the socket filtering api to run alternative interpreters,
such as nft, then that could still happen, of course.
--
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 v3 3/3] of: Make of_find_node_by_path() handle /aliases

[Rob Herring]

On Sat, Mar 15, 2014 at 7:33 AM, Grant Likely  wrote:
> On Fri, 14 Mar 2014 16:39:38 -0500, Rob Herring  wrote:
>> On Fri, Mar 14, 2014 at 12:11 PM, Grant Likely  
>> wrote:
>> > Make of_find_node_by_path() handle aliases as prefixes. To make this
>> > work the name search is refactored to search by path component instead
>> > of by full string. This should be a more efficient search, and it makes
>> > it possible to start a search at a subnode of a tree.
>> >
>> > Signed-off-by: David Daney 
>> > Signed-off-by: Pantelis Antoniou 
>> > [grant.likely: Rework to not require allocating at runtime]
>> > Signed-off-by: Grant Likely 
>>
>> I should have read the comments before trying to figure out why you
>> had that "pointless" recursion...
>
> Hi Rob,
>
> Thanks for the review. However, I'm a little slow this morning and I
> don't understand what you mean. Did I miss an early comment?

No, it's me that was being slow. At first glance I was thinking the
recursion was pointless until I saw the alias + path case.

Rob
--
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] it87_wdt: Work around non-working CIR interrupts

[Wim Van Sebroeck]

Hi Marc,

> From: Marc van der Wal 
> 
> On some hardware platforms, the it87_wdt watchdog resets the machine
> despite the watchdog daemon running and writing to /dev/watchdog.
> 
> This is due to Consumer IR buffer underrun interrupts being used as
> triggers to reset the timer.  On some buggy hardware implementations
> such as the iEi AFL-12A-N270 single-board computer, this method does 
> not work.
> 
> However, resetting the timer by writing its original timeout value in
> its configuration register over and over again suppresses the unwanted
> reboots.
> 
> Add a module option (nocir), 0 by default in order not to break existing
> setups.  Setting it to 1 enables the workaround.
> 
> Fixes bug #42801 .
> Tested primarily on Linux 3.5.7, applies cleanly on Linux 3.13.5.
> 
> Signed-off-by: Marc van der Wal 
> ---

Patch has been added to linux-watchdog-next.

Kind regards,
Wim.

--
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] watchdog: bcm281xx: Fix Kconfig dependency

[Wim Van Sebroeck]

Hi Markus,

> Use more the applicable ARCH_BCM_MOBILE option instead of ARCH_BCM as
> dependency for bcm_kona_wdt.c.
> 
> Signed-off-by: Markus Mayer 
> ---
>  drivers/watchdog/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 79d2589..47a6f10 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -1160,7 +1160,7 @@ config BCM2835_WDT
>  
>  config BCM_KONA_WDT
>   tristate "BCM Kona Watchdog"
> - depends on ARCH_BCM
> + depends on ARCH_BCM_MOBILE
>   select WATCHDOG_CORE
>   help
> Support for the watchdog timer on the following Broadcom BCM281xx

Patch has been added to linux-watchdog-next.

Kind regards,
Wim.

--
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] powerpc/mm: Make sure a local_irq_disable prevent a parallel THP split

[Rik van Riel]

On 03/15/2014 06:47 AM, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" 
> 
> We have generic code like the one in get_futex_key that assume that
> a local_irq_disable prevents a parallel THP split. Support that by
> adding a dummy smp call function after setting _PAGE_SPLITTING. Code
> paths like get_user_pages_fast still need to check for _PAGE_SPLITTING
> after disabling IRQ which indicate that a parallel THP splitting is
> ongoing. Now if they don't find _PAGE_SPLITTING set, then we can be
> sure that parallel split will now block in pmdp_splitting flush
> until we enables IRQ
> 
> Signed-off-by: Aneesh Kumar K.V 

Acked-by: Rik van Riel 

-- 
All rights reversed
--
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] exit.c: call proc_exit_connector() after exit_state is set

[Linus Torvalds]

On Sat, Mar 15, 2014 at 12:12 PM, Oleg Nesterov  wrote:
>
> So I think the patch is fine, but let me repeat:
>
> I hope that someone
> can confirm that netlink_broadcast() is safe even if 
> release_task(current)
> was already called, so that the caller has no pids, sighand, is not 
> visible
> via /proc/, etc.
>
> not that I expect this should not work, but still.

Ok. I think people use netlink_broadcast from irq context (well,
strictly speaking looks lik ebottom half) judging by the GFP_ATOMIC
users, so that had better work regardless.

> Yes... BTW, Guillaume, I forgot to mention that perhaps you can use
> signalfd(SIGCHLD) instead of connector, this is epoll-able too. SIGCHLD
> doesn't queue, so it can't tell you which child has exited, but WNOHANG
> should work.

Yeah, that sounds like a good approach if SIGCHLD is the only thing needed.

Anyway, I see that the patch is apparently in -mm, and I think your
netlink_broadcast issue should be fine, so things are moving along.
It's not like this is a new issue or even so much an outright "bug" as
a misfeature.

 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/

Re: [PATCH RFC 0/9] socket filtering using nf_tables

[Alexei Starovoitov]

On Sat, Mar 15, 2014 at 12:03 PM, Pablo Neira Ayuso  wrote:
> On Fri, Mar 14, 2014 at 09:04:50PM -0700, Alexei Starovoitov wrote:
> [...]
>> In the patches I sent, ebpf is _not_ exposed to the user.
>
> From your last patch: http://patchwork.ozlabs.org/patch/329713/
>
> diff --git a/include/uapi/linux/filter.h b/include/uapi/linux/filter.h
> index 8eb9ccaa5b48..4e98fe16ba88 100644
> --- a/include/uapi/linux/filter.h
> +++ b/include/uapi/linux/filter.h
> @@ -1,5 +1,6 @@
>  /*
>   * Linux Socket Filter Data Structures
> + * Extended BPF is Copyright (c) 2011-2014, PLUMgrid, http://plumgrid.com
>   */
>
>  #ifndef _UAPI__LINUX_FILTER_H__
> @@ -19,7 +20,7 @@
>   * Try and keep these values and structures similar to BSD,
>   * especially
>   * the BPF code definitions which need to match so you can share
>   * filters
>   */
> -
> +
>  struct sock_filter {   /* Filter block */
> __u16   code;   /* Actual filter code */
> __u8jt; /* Jump true */
> @@ -27,6 +28,14 @@  struct sock_filter {/* Filter block */
> __u32   k;  /* Generic multiuse field */
>  };
>
> +struct sock_filter_ext {
> +   __u8code;/* opcode */
> +   __u8a_reg:4; /* dest register */
> +   __u8x_reg:4; /* source register */
> +   __s16   off; /* signed offset */
> +   __s32   imm; /* signed immediate constant */
> +};
> +
>  struct sock_fprog {/* Required for SO_ATTACH_FILTER. */
> unsigned short  len;/* Number of filter blocks */
> struct sock_filter __user *filter;
>
> That sock_filter_ext structure is exposed to userspace as well as many
> other new BPF_* macros that you have defined.

For the first few versions of the patchset they were in linux/bpf.h,
but then it was suggested to put them into uapi/linux/filter.h
to make the whole thing consistent with existing sock_filter structure.
So yes, uapi header is changed as:
 include/uapi/linux/filter.h |   33 ++---
 1 file changed, 26 insertions(+), 7 deletions(-)

but there is no way to use these #define from user space at present.

As I said I think it's safe to expose it, because these defines won't change,
but if there is a concern I can move it back into linux/bpf.h

Thanks
Alexei
--
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] exit.c: call proc_exit_connector() after exit_state is set

[Oleg Nesterov]

On 03/15, Linus Torvalds wrote:
>
> [ Going through old emails, adding relevant people, ie Oleg for
> kernel/exit.c and David because he seems to be the go-to person for
> connector issues judging by commits ]
>
> Patch looks sane to me, and logically that exit_connector thing would
> pair with exit_notify(), but I'd like some comments on it.

Please see the (confusing, my fault) discussion

http://marc.info/?t=13932788663

But in short, personally I agree with this change too. Just it was not
clear from the changelog (to me ;) which problem this change actually
tries to solve, because in general the task is not waitable after it
reports PROC_EVENT_EXIT.

So I think the patch is fine, but let me repeat:

I hope that someone
can confirm that netlink_broadcast() is safe even if 
release_task(current)
was already called, so that the caller has no pids, sighand, is not 
visible
via /proc/, etc.

not that I expect this should not work, but still.

> That
> usability issue/race has been there since forever afaik. We probably
> should never have added that process events connector thing, but since
> we did and people apparently use it..

Yes... BTW, Guillaume, I forgot to mention that perhaps you can use
signalfd(SIGCHLD) instead of connector, this is epoll-able too. SIGCHLD
doesn't queue, so it can't tell you which child has exited, but WNOHANG
should work.

Oleg.

--
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 0/9] socket filtering using nf_tables

[Pablo Neira Ayuso]

On Fri, Mar 14, 2014 at 09:04:50PM -0700, Alexei Starovoitov wrote:
[...]
> In the patches I sent, ebpf is _not_ exposed to the user.

>From your last patch: http://patchwork.ozlabs.org/patch/329713/

diff --git a/include/uapi/linux/filter.h b/include/uapi/linux/filter.h
index 8eb9ccaa5b48..4e98fe16ba88 100644
--- a/include/uapi/linux/filter.h
+++ b/include/uapi/linux/filter.h
@@ -1,5 +1,6 @@ 
 /*
  * Linux Socket Filter Data Structures
+ * Extended BPF is Copyright (c) 2011-2014, PLUMgrid, http://plumgrid.com
  */
 
 #ifndef _UAPI__LINUX_FILTER_H__
@@ -19,7 +20,7 @@ 
  * Try and keep these values and structures similar to BSD,
  * especially
  * the BPF code definitions which need to match so you can share
  * filters
  */
- 
+
 struct sock_filter {   /* Filter block */
__u16   code;   /* Actual filter code */
__u8jt; /* Jump true */
@@ -27,6 +28,14 @@  struct sock_filter {/* Filter block */
__u32   k;  /* Generic multiuse field */
 };
 
+struct sock_filter_ext {
+   __u8code;/* opcode */
+   __u8a_reg:4; /* dest register */
+   __u8x_reg:4; /* source register */
+   __s16   off; /* signed offset */
+   __s32   imm; /* signed immediate constant */
+};
+
 struct sock_fprog {/* Required for SO_ATTACH_FILTER. */
unsigned short  len;/* Number of filter blocks */
struct sock_filter __user *filter;

That sock_filter_ext structure is exposed to userspace as well as many
other new BPF_* macros that you have defined.
--
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] exit.c: call proc_exit_connector() after exit_state is set

[Linus Torvalds]

[ Going through old emails, adding relevant people, ie Oleg for
kernel/exit.c and David because he seems to be the go-to person for
connector issues judging by commits ]

Patch looks sane to me, and logically that exit_connector thing would
pair with exit_notify(), but I'd like some comments on it. That
usability issue/race has been there since forever afaik. We probably
should never have added that process events connector thing, but since
we did and people apparently use it..

Comments?

 Linus

On Mon, Feb 24, 2014 at 11:27 AM, Guillaume Morin  wrote:
> From: Guillaume Morin 
>
> The process events connector delivers a notification when a process
> exits.  This is really convenient for a process that spawns and wants
> to monitor its children through an epoll-able() interface.
>
> Unfortunately, there is a small window between when the event is
> delivered and the child become wait()-able.
>
> This is creates a race if the parent wants to make sure that it knows
> about the exit, e.g
>
> pid_t pid = fork();
> if (pid > 0) {
> register_interest_for_pid(pid);
> if (waitpid(pid, NULL, WNOHANG) > 0)
> {
>   /* We might have raced with exit() */
> }
> return;
> }
>
> /* Child */
> execve(...)
>
> register_interest_for_pid() would be telling the the connector socket
> reader to pay attention to events related to pid.
>
> Though this is not a bug, I think it would make the connector a bit
> more usable if this race was closed by simply moving the call to
> proc_exit_connector() from just before exit_notify() to right after.
>
> Signed-off-by: Guillaume Morin 
> Cc: matt.hels...@gmail.com
> ---
> diff --git a/kernel/exit.c b/kernel/exit.c
> index 1e77fc6..9b0ac8c 100644
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -804,7 +804,6 @@ void do_exit(long code)
>
> module_put(task_thread_info(tsk)->exec_domain->module);
>
> -   proc_exit_connector(tsk);
>
> /*
>  * FIXME: do that only when needed, using sched_exit tracepoint
> @@ -812,6 +811,7 @@ void do_exit(long code)
> flush_ptrace_hw_breakpoint(tsk);
>
> exit_notify(tsk, group_dead);
> +   proc_exit_connector(tsk);
>  #ifdef CONFIG_NUMA
> task_lock(tsk);
> mpol_put(tsk->mempolicy);
>
>
>
> --
> Guillaume Morin 
--
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] ATHEROS-ALX: Use dma_set_mask_and_coherent and fix a bug

[Peter Senna Tschudin]

 1. For the 64 bits dma mask use dma_set_mask_and_coherent instead of
 dma_set_mask and dma_set_coherent_mask.

 2. For the 32 bits dma mask dma_set_coherent_mask is only called if
 dma_set_mask fails, which is unusual. Assuming this as a bug, fixes
 it by replacing calls to dma_set_mask and dma_set_coherent_mask by a
 call to dma_set_coherent_mask.
 
 Signed-off-by: Peter Senna Tschudin 
---

 Tested by compilation only.

 drivers/net/ethernet/atheros/alx/main.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/atheros/alx/main.c 
b/drivers/net/ethernet/atheros/alx/main.c
index 2e45f6e..380d249 100644
--- a/drivers/net/ethernet/atheros/alx/main.c
+++ b/drivers/net/ethernet/atheros/alx/main.c
@@ -1248,19 +1248,13 @@ static int alx_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
 * shared register for the high 32 bits, so only a single, aligned,
 * 4 GB physical address range can be used for descriptors.
 */
-   if (!dma_set_mask(>dev, DMA_BIT_MASK(64)) &&
-   !dma_set_coherent_mask(>dev, DMA_BIT_MASK(64))) {
+   if (!dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(64))) {
dev_dbg(>dev, "DMA to 64-BIT addresses\n");
} else {
-   err = dma_set_mask(>dev, DMA_BIT_MASK(32));
+   err = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(32));
if (err) {
-   err = dma_set_coherent_mask(>dev,
-   DMA_BIT_MASK(32));
-   if (err) {
-   dev_err(>dev,
-   "No usable DMA config, aborting\n");
-   goto out_pci_disable;
-   }
+   dev_err(>dev, "No usable DMA config, aborting\n");
+   goto out_pci_disable;
}
}
 
-- 
1.8.3.1

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

Re: kernel panic 3.11.7 in kmem_cache_alloc+0x66/0x150

[Linus Torvalds]

[ Going through old emails, this is probably stale by now since you
already figured out it was fixed in 3.13 ]

On Mon, Feb 24, 2014 at 3:47 AM, Jasper Spaans  wrote:
>
> Last weekend one of our machines showed some interesting behaviour, where
> processes seemed to be crashing randomly. Further inspection showed that
> all the oopses in syslog were on core #12, and had
> kmem_cache_alloc+0x66/0x150 as the RIP, except for the second one, which had
> kmem_cache_alloc_trace+0x6a/0x140 .

This indeed looks very much like the pipe use-after-free that was
fixed by commit b0d8d2292160 ("vfs: fix subtle use-after-free of
pipe_inode_info"), and afffects 3.10-3.12. It should be in stable
kernels, but you probably have a 3.11 that predates that stable
backport.

For 3.11, you need 3.11.10.2 or newer, but 3.12 or 3.13 stable sounds
like a better idea from a maintenance standpoint.

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/

Re: [PATCH 01/10] perf, tools: Add jsmn `jasmine' JSON parser

[Andi Kleen]

> Will this be useful for all arches?

Yes they could define their own JSON files, perhaps with minor
extensions of the parser and a new download sites in the downloader.

-Andi
--
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: [RC6 Bell Chime] [PATCH 00/24] rfcomm fixes

[Linus Torvalds]

On Sat, Mar 15, 2014 at 6:51 AM, Sander Eikelenboom
 wrote:
>
>
> Ok but the breakage/regression was known since around the merge window.
> I thought the "standard policy" when things cause new regression and are not 
> fixable (too intrusive, too time consuming you
> name the reason), was to revert ..

It is indeed.

Guys, why is this being discussed? We should not release a
known-broken 3.14 just because the fix is too big for rc. Things
should be reverted.

   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/

[GIT PULL] SCSI fixes for 3.14-rc6

[James Bottomley]

This is a set of six fixes.  Two are instant crash/null deref types
(storvsc and isci reset fixes). The two qla2xxx are initialisation
problems that cause MSI-X failures and card misdetection, the isci
erroneous macro is actually illegal C that's causing a miscompile with
certain gcc versions and the be2iscsi bad if expression is a static
checker fix. 

The patch is available here:

git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes

The short changelog is:

Ales Novak (1):
  storvsc: NULL pointer dereference fix

Chad Dupuis (1):
  qla2xxx: Fix multiqueue MSI-X registration.

Dan Williams (1):
  isci: fix reset timeout handling

Giridhar Malavali (1):
  qla2xxx: Poll during initialization for ISP25xx and ISP83xx

Lukasz Dorau (1):
  isci: correct erroneous for_each_isci_host macro

Mike Christie (1):
  be2iscsi: fix bad if expression

The diffstat is:

 drivers/scsi/be2iscsi/be_main.c |  2 +-
 drivers/scsi/isci/host.h|  5 ++---
 drivers/scsi/isci/port_config.c |  7 ---
 drivers/scsi/isci/task.c|  2 +-
 drivers/scsi/qla2xxx/qla_def.h  |  3 +--
 drivers/scsi/qla2xxx/qla_isr.c  | 46 +++--
 drivers/scsi/storvsc_drv.c  |  3 +++
 7 files changed, 38 insertions(+), 30 deletions(-)

With the full diff below.

James

---

diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
index 1f37505..5642a9b 100644
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b/drivers/scsi/be2iscsi/be_main.c
@@ -325,7 +325,7 @@ static int beiscsi_eh_device_reset(struct scsi_cmnd *sc)
if (!abrt_task->sc || abrt_task->state == ISCSI_TASK_FREE)
continue;
 
-   if (abrt_task->sc->device->lun != abrt_task->sc->device->lun)
+   if (sc->device->lun != abrt_task->sc->device->lun)
continue;
 
/* Invalidate WRB Posted for this Task */
diff --git a/drivers/scsi/isci/host.h b/drivers/scsi/isci/host.h
index 4911310..22a9bb1 100644
--- a/drivers/scsi/isci/host.h
+++ b/drivers/scsi/isci/host.h
@@ -311,9 +311,8 @@ static inline struct Scsi_Host *to_shost(struct isci_host 
*ihost)
 }
 
 #define for_each_isci_host(id, ihost, pdev) \
-   for (id = 0, ihost = to_pci_info(pdev)->hosts[id]; \
-id < ARRAY_SIZE(to_pci_info(pdev)->hosts) && ihost; \
-ihost = to_pci_info(pdev)->hosts[++id])
+   for (id = 0; id < SCI_MAX_CONTROLLERS && \
+(ihost = to_pci_info(pdev)->hosts[id]); id++)
 
 static inline void wait_for_start(struct isci_host *ihost)
 {
diff --git a/drivers/scsi/isci/port_config.c b/drivers/scsi/isci/port_config.c
index 85c77f6..ac87974 100644
--- a/drivers/scsi/isci/port_config.c
+++ b/drivers/scsi/isci/port_config.c
@@ -615,13 +615,6 @@ static void sci_apc_agent_link_up(struct isci_host *ihost,
  
SCIC_SDS_APC_WAIT_LINK_UP_NOTIFICATION);
} else {
/* the phy is already the part of the port */
-   u32 port_state = iport->sm.current_state_id;
-
-   /* if the PORT'S state is resetting then the link up is from
-* port hard reset in this case, we need to tell the port
-* that link up is recieved
-*/
-   BUG_ON(port_state != SCI_PORT_RESETTING);
port_agent->phy_ready_mask |= 1 << phy_index;
sci_port_link_up(iport, iphy);
}
diff --git a/drivers/scsi/isci/task.c b/drivers/scsi/isci/task.c
index 0d30ca8..5d6fda7 100644
--- a/drivers/scsi/isci/task.c
+++ b/drivers/scsi/isci/task.c
@@ -801,7 +801,7 @@ int isci_task_I_T_nexus_reset(struct domain_device *dev)
/* XXX: need to cleanup any ireqs targeting this
 * domain_device
 */
-   ret = TMF_RESP_FUNC_COMPLETE;
+   ret = -ENODEV;
goto out;
}
 
diff --git a/drivers/scsi/qla2xxx/qla_def.h b/drivers/scsi/qla2xxx/qla_def.h
index e1fe95e..266724b 100644
--- a/drivers/scsi/qla2xxx/qla_def.h
+++ b/drivers/scsi/qla2xxx/qla_def.h
@@ -2996,8 +2996,7 @@ struct qla_hw_data {
IS_QLA82XX(ha) || IS_QLA83XX(ha) || \
IS_QLA8044(ha))
 #define IS_MSIX_NACK_CAPABLE(ha) (IS_QLA81XX(ha) || IS_QLA83XX(ha))
-#define IS_NOPOLLING_TYPE(ha)  ((IS_QLA25XX(ha) || IS_QLA81XX(ha) || \
-   IS_QLA83XX(ha)) && (ha)->flags.msix_enabled)
+#define IS_NOPOLLING_TYPE(ha)  (IS_QLA81XX(ha) && (ha)->flags.msix_enabled)
 #define IS_FAC_REQUIRED(ha)(IS_QLA81XX(ha) || IS_QLA83XX(ha))
 #define IS_NOCACHE_VPD_TYPE(ha)(IS_QLA81XX(ha) || IS_QLA83XX(ha))
 #define IS_ALOGIO_CAPABLE(ha)  (IS_QLA23XX(ha) || IS_FWI2_CAPABLE(ha))
diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
index 9bc86b9..0a1dcb4 100644
--- a/drivers/scsi/qla2xxx/qla_isr.c
+++ b/drivers/scsi/qla2xxx/qla_isr.c
@@ -2880,6 +2880,7 @@ 

[Fix PATCH] ACPI/Button: Add ACPI Button event via netlink routine

[Lan Tianyu]

Commit 1696d9d(ACPI: Remove the old /proc/acpi/event interface)
removes ACPI Button event which originally was sent to userspace via
/proc/acpi/event. This causes ACPI shutdown regression on gentoo
in the VirtualBox. Now ACPI events are sent to userspace via netlink.
This patch is to add ACPI Button event back via netlink routine.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=71721
Reported-and-tested-by: Richard Musil 
Signed-off-by: Lan Tianyu 
Cc:  # 3.11.x
---
 drivers/acpi/button.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
index 714e957..db35594 100644
--- a/drivers/acpi/button.c
+++ b/drivers/acpi/button.c
@@ -302,6 +302,10 @@ static void acpi_button_notify(struct acpi_device *device, 
u32 event)
input_sync(input);
 
pm_wakeup_event(>dev, 0);
+   acpi_bus_generate_netlink_event(
+   device->pnp.device_class,
+   dev_name(>dev),
+   event, ++button->pushed);
}
break;
default:
-- 
1.8.3.1

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

Re: [PATCHv4 4/7] hwspinlock/core: add common OF helpers

[Ohad Ben-Cohen]

On Fri, Mar 14, 2014 at 5:23 PM, Josh Cartwright  wrote:
> So, are you suggesting that because fatal errors should be "extremely
> rare", a consuming driver should just assume that if NULL is returned
> from a hwspin_lock_request*() function that it was the "device not yet
> probed" case that was hit?

No - it's not the scarcity, it's the severity.

The error path that will be optimized here is an invalid id. If this
happens, the consumer will crash and burn, and I'm not sure that
slightly optimizing his death is very interesting?

BTW the hwspinlock core once did use ERR_PTR and friends, and it was
changed due to convincing arguments against that methodology on this
mailing list. We can change it back but we need a strong(er) case.

> Note that having the consumer/hwspinlock device relationship modeled in
> devicetree introduces more potential failure cases...

Yeah. Even the error above, presumed to be EPROBE_DEFER, may be a
symptom of some other fatal error that occurred, and we can't be sure
that a future request will surely be satisfied. So before we bloat our
code, I suggest that we wait for consumers to show up and see if
there's real benefit.

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

Re: 3.14-rc: /proc/acpi/battery gone?

[Lan Tianyu]

On 03/15/2014 12:05 PM, Pavel Machek wrote:

Hi!


They have attempted to use the sysfs api, but apparently that
integration was done with an older version of that API. There's also
some attempt to get it to work with upower, but I couldn't figure out
how to make that work either on my (up-to-date gentoo) box. (TBH I
didn't spend more than an hour or two on it, so it may not be
impossible.)


Tianyu, can you please have a look at this?


Disclaimer, I've never used wmbattery so far.

The current upstream version (2.42, released in early december 2013)
of wmbattery[1] no longer reads from /proc/acpi/ at all. Apparently
it changed to using upower by default, with non-default fall-backs for
reading from sysfs.

The only change required for building upower with wmbattery 2.42
appears to be a new build-dependency on libupower-glib-dev (at least
on Debian, built from the upower source package). Given that this
version is present in Debian testing and unstable, I'd assume that it's
supposed to work using upower, although I haven't confirmed that myself.

Judging from the Gentoo ebuild, you probably just have to add
"sys-power/upower" to the RDEPEND variable and make sure to build
wmbattery 2.42; this is untested.



Hi Stefan:
I just glance wmbattery code. I find the code in the acpi.c is
already using the new sysfs battery interfaces, right?

...

#define SYSFS_PATH "/sys/class/power_supply"

...
char *acpi_labels[] = {
"uevent",
"status",
"BAT",
"AC",
"POWER_SUPPLY_CAPACITY=",
"POWER_SUPPLY_??_FULL_DESIGN=", /* CHARGE or ENERGY */
"POWER_SUPPLY_PRESENT=",
"POWER_SUPPLY_??_NOW=",
"POWER_SUPPLY_CURRENT_NOW=",
"POWER_SUPPLY_STATUS=",
#if ACPI_THERMAL
"thermal_zone",
#endif
"POWER_SUPPLY_ONLINE=",
"POWER_SUPPLY_??_FULL=",
NULL
};


New kernel should work with old userspace... and clearly it does not.

Do you have test patch for a revert?

Pavel


Please try this patch.

commit 6cb7ea8975bf8ffafd893204f55eddd1aebd8ff6
Author: Lan Tianyu 
Date:   Sat Mar 15 12:20:15 2014 -0400

Revert "ACPI / Battery: Remove battery's proc directory" and "ACPI: 
Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c"


The commit 1e2d9cd and 7d7ee95 remove ACPI Proc Battery
directory and breaks some old userspace tools. This patch
is to revert them.

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index f60f11d..c9231b1 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -43,6 +43,23 @@ config ACPI_SLEEP
depends on SUSPEND || HIBERNATION
default y

+config ACPI_PROCFS_POWER
+   bool "Deprecated power /proc/acpi directories"
+   depends on PROC_FS
+   help
+ For backwards compatibility, this option allows
+  deprecated power /proc/acpi/ directories to exist, even when
+  they have been replaced by functions in /sys.
+  The deprecated directories (and their replacements) include:
+ /proc/acpi/battery/* (/sys/class/power_supply/*)
+ /proc/acpi/ac_adapter/* (sys/class/power_supply/*)
+ This option has no effect on /proc/acpi/ directories
+ and functions, which do not yet exist in /sys
+ This option, together with the proc directories, will be
+ deleted in 2.6.39.
+
+ Say N to delete power /proc/acpi/ directories that have moved to /sys/
+
 config ACPI_EC_DEBUGFS
tristate "EC read/write access through /sys/kernel/debug/ec"
default n
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 0331f91..bce34af 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -47,6 +47,7 @@ acpi-y+= sysfs.o
 acpi-$(CONFIG_X86) += acpi_cmos_rtc.o
 acpi-$(CONFIG_DEBUG_FS)+= debugfs.o
 acpi-$(CONFIG_ACPI_NUMA)   += numa.o
+acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
 ifdef CONFIG_ACPI_VIDEO
 acpi-y += video_detect.o
 endif
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index 797a693..22c8696 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -36,6 +36,12 @@
 #include 
 #include 

+#ifdef CONFIG_ACPI_PROCFS_POWER
+#include 
+#include 
+#include 
+#endif
+
 #include 
 #include 

@@ -66,6 +72,19 @@ static unsigned int cache_time = 1000;
 module_param(cache_time, uint, 0644);
 MODULE_PARM_DESC(cache_time, "cache time in milliseconds");

+#ifdef CONFIG_ACPI_PROCFS_POWER
+extern struct proc_dir_entry *acpi_lock_battery_dir(void);
+extern void *acpi_unlock_battery_dir(struct proc_dir_entry 
*acpi_battery_dir);

+
+enum acpi_battery_files {
+   info_tag = 0,
+   state_tag,
+   alarm_tag,
+   ACPI_BATTERY_NUMFILES,
+};
+
+#endif
+
 static const struct acpi_device_id battery_device_ids[] = {
{"PNP0C0A", 0},
{"", 0},
@@ -301,6 +320,14 @@ 

Re: [PATCH] iio: adc: at91_adc: correct default shtim value

[Jonathan Cameron]

On 05/03/14 11:04, Josh Wu wrote:

Hi, Alexandre

On 3/4/2014 2:07 AM, Alexandre Belloni wrote:

When sample_hold_time is zero (this is the case when DT is not used or if
atmel,adc-sample-hold-time is omitted), then the calculated shtim is large.

Make that 0, which is the default for that register and the ADC will then use a
sane value of 2/ADCCLK or 1/ADCCLK depending on the version.

Signed-off-by: Alexandre Belloni 


Thanks for the fix and

Acked-by: Josh Wu


Applied to the fixes-togreg branch of iio.git.
Note that is likely that this will go upstream after the merge window now.

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

[PATCH net-next,v2,0/1] hyperv: Add support for virtual Receive Side Scaling (vRSS)

[Haiyang Zhang]

In this updated version, I have re-written the send queue selection, which is
based on ndo_select_queue now. I also applied the stop/wake queue for each
queue separately as suggested by reviewers.

Tom Herbert  has submitted a Toeplitz library function with
some optimization. But it's not accepted yet. I'm still using my Toeplitz
implementation in netvsc module. Please accept my patch if no other issues, 
because it already provides significant performance enhancement at current
state. I will be happy to switch to the Toeplitz library function when it's
accepted in the future.

Haiyang Zhang (1):
  hyperv: Add support for virtual Receive Side Scaling (vRSS)

 drivers/net/hyperv/hyperv_net.h   |  111 ++-
 drivers/net/hyperv/netvsc.c   |  132 +-
 drivers/net/hyperv/netvsc_drv.c   |  104 -
 drivers/net/hyperv/rndis_filter.c |  186 -
 4 files changed, 500 insertions(+), 33 deletions(-)

-- 
1.7.4.1

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

[PATCH net-next,v2,1/1] hyperv: Add support for virtual Receive Side Scaling (vRSS)

[Haiyang Zhang]

This feature allows multiple channels to be used by each virtual NIC.
It is available on Hyper-V host 2012 R2.

Signed-off-by: Haiyang Zhang 
Reviewed-by: K. Y. Srinivasan 
---
 drivers/net/hyperv/hyperv_net.h   |  111 ++-
 drivers/net/hyperv/netvsc.c   |  132 +-
 drivers/net/hyperv/netvsc_drv.c   |  104 -
 drivers/net/hyperv/rndis_filter.c |  186 -
 4 files changed, 500 insertions(+), 33 deletions(-)

diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 13010b4..f67292f 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -28,6 +28,98 @@
 #include 
 #include 
 
+/* RSS related */
+#define OID_GEN_RECEIVE_SCALE_CAPABILITIES 0x00010203  /* query only */
+#define OID_GEN_RECEIVE_SCALE_PARAMETERS 0x00010204  /* query and set */
+
+#define NDIS_OBJECT_TYPE_RSS_CAPABILITIES 0x88
+#define NDIS_OBJECT_TYPE_RSS_PARAMETERS 0x89
+
+#define NDIS_RECEIVE_SCALE_CAPABILITIES_REVISION_2 2
+#define NDIS_RECEIVE_SCALE_PARAMETERS_REVISION_2 2
+
+struct ndis_obj_header {
+   u8 type;
+   u8 rev;
+   u16 size;
+} __packed;
+
+
+/* ndis_recv_scale_cap/cap_flag */
+#define NDIS_RSS_CAPS_MESSAGE_SIGNALED_INTERRUPTS 0x0100
+#define NDIS_RSS_CAPS_CLASSIFICATION_AT_ISR   0x0200
+#define NDIS_RSS_CAPS_CLASSIFICATION_AT_DPC   0x0400
+#define NDIS_RSS_CAPS_USING_MSI_X 0x0800
+#define NDIS_RSS_CAPS_RSS_AVAILABLE_ON_PORTS  0x1000
+#define NDIS_RSS_CAPS_SUPPORTS_MSI_X  0x2000
+#define NDIS_RSS_CAPS_HASH_TYPE_TCP_IPV4  0x0100
+#define NDIS_RSS_CAPS_HASH_TYPE_TCP_IPV6  0x0200
+#define NDIS_RSS_CAPS_HASH_TYPE_TCP_IPV6_EX   0x0400
+
+struct ndis_recv_scale_cap { /* NDIS_RECEIVE_SCALE_CAPABILITIES */
+   struct ndis_obj_header hdr;
+   u32 cap_flag;
+   u32 num_int_msg;
+   u32 num_recv_que;
+   u16 num_indirect_tabent;
+} __packed;
+
+
+/* ndis_recv_scale_param flags */
+#define NDIS_RSS_PARAM_FLAG_BASE_CPU_UNCHANGED 0x0001
+#define NDIS_RSS_PARAM_FLAG_HASH_INFO_UNCHANGED0x0002
+#define NDIS_RSS_PARAM_FLAG_ITABLE_UNCHANGED   0x0004
+#define NDIS_RSS_PARAM_FLAG_HASH_KEY_UNCHANGED 0x0008
+#define NDIS_RSS_PARAM_FLAG_DISABLE_RSS0x0010
+
+/* Hash info bits */
+#define NDIS_HASH_FUNC_TOEPLITZ 0x0001
+#define NDIS_HASH_IPV4  0x0100
+#define NDIS_HASH_TCP_IPV4  0x0200
+#define NDIS_HASH_IPV6  0x0400
+#define NDIS_HASH_IPV6_EX   0x0800
+#define NDIS_HASH_TCP_IPV6  0x1000
+#define NDIS_HASH_TCP_IPV6_EX   0x2000
+
+#define NDIS_RSS_INDIRECTION_TABLE_MAX_SIZE_REVISION_2 (128 * 4)
+#define NDIS_RSS_HASH_SECRET_KEY_MAX_SIZE_REVISION_2   40
+
+#define ITAB_NUM 128
+#define HASH_KEYLEN NDIS_RSS_HASH_SECRET_KEY_MAX_SIZE_REVISION_2
+extern u8 hash_key[];
+
+struct ndis_recv_scale_param { /* NDIS_RECEIVE_SCALE_PARAMETERS */
+   struct ndis_obj_header hdr;
+
+   /* Qualifies the rest of the information */
+   u16 flag;
+
+   /* The base CPU number to do receive processing. not used */
+   u16 base_cpu_number;
+
+   /* This describes the hash function and type being enabled */
+   u32 hashinfo;
+
+   /* The size of indirection table array */
+   u16 indirect_tabsize;
+
+   /* The offset of the indirection table from the beginning of this
+* structure
+*/
+   u32 indirect_taboffset;
+
+   /* The size of the hash secret key */
+   u16 hashkey_size;
+
+   /* The offset of the secret key from the beginning of this structure */
+   u32 kashkey_offset;
+
+   u32 processor_masks_offset;
+   u32 num_processor_masks;
+   u32 processor_masks_entry_size;
+};
+
+
 /* Fwd declaration */
 struct hv_netvsc_packet;
 struct ndis_tcp_ip_checksum_info;
@@ -39,6 +131,8 @@ struct xferpage_packet {
 
/* # of netvsc packets this xfer packet contains */
u32 count;
+
+   struct vmbus_channel *channel;
 };
 
 /*
@@ -54,6 +148,9 @@ struct hv_netvsc_packet {
bool is_data_pkt;
u16 vlan_tci;
 
+   u16 q_idx;
+   struct vmbus_channel *channel;
+
/*
 * Valid only for receives when we break a xfer page packet
 * into multiple netvsc packets
@@ -120,6 +217,7 @@ void netvsc_linkstatus_callback(struct hv_device 
*device_obj,
 int netvsc_recv_callback(struct hv_device *device_obj,
struct hv_netvsc_packet *packet,
struct ndis_tcp_ip_checksum_info *csum_info);
+extern void netvsc_channel_cb(void *context);
 int rndis_filter_open(struct hv_device *dev);
 int rndis_filter_close(struct hv_device *dev);
 int rndis_filter_device_add(struct hv_device *dev,
@@ -131,6 +229,7 @@ int rndis_filter_receive(struct hv_device *dev,
 int rndis_filter_set_packet_filter(struct rndis_device *dev, u32 new_filter);
 int 

Re: [PATCH] iio: cm36651: Fix i2c client leak and possible NULL pointer dereference

[Jonathan Cameron]

On 06/03/14 09:33, Krzysztof Kozlowski wrote:

During probe the driver allocates dummy I2C devices (i2c_new_dummy())
but they aren't unregistered during driver remove or probe failure.

Additionally driver does not check the return value of i2c_new_dummy().
In case of error (i2c_new_device(): memory allocation failure or I2C
address cannot be used) this function returns NULL which is later
dereferenced by i2c_smbus_{read,write}_data() functions.

Fix issues by properly checking for i2c_new_dummy() return value and
unregistering I2C devices on driver remove or probe failure.

Signed-off-by: Krzysztof Kozlowski 

Good catch, but the error path needs more care.

---
  drivers/iio/light/cm36651.c |   12 
  1 file changed, 12 insertions(+)

diff --git a/drivers/iio/light/cm36651.c b/drivers/iio/light/cm36651.c
index a45e07492db3..e7e9a597159f 100644
--- a/drivers/iio/light/cm36651.c
+++ b/drivers/iio/light/cm36651.c
@@ -653,6 +653,11 @@ static int cm36651_probe(struct i2c_client *client,
cm36651->ps_client = i2c_new_dummy(client->adapter,
 CM36651_I2C_ADDR_PS);
cm36651->ara_client = i2c_new_dummy(client->adapter, CM36651_ARA);
+   if (!cm36651->ps_client || !cm36651->ara_client) {
+   dev_err(>dev, "%s: new i2c device failed\n", __func__);
+   ret = -ENODEV;
+   goto error_i2c_unregister;
+   }

The two failures need to be handled independently as we only want to unregister
those that succeeded.  i2c_new_dummy will not return an error and leave a device
registered.  This is particularly true given the first thing that 
i2c_unregister_device
does is to derefence the client pointer.  That will cause a segfault if you do 
it
for NULL as here.


mutex_init(>lock);
indio_dev->dev.parent = >dev;
indio_dev->channels = cm36651_channels;
@@ -687,6 +692,11 @@ error_free_irq:
free_irq(client->irq, indio_dev);
  error_disable_reg:
regulator_disable(cm36651->vled_reg);
+error_i2c_unregister:
+   if (cm36651->ps_client)
+   i2c_unregister_device(cm36651->ps_client);
+   if (cm36651->ara_client)
+   i2c_unregister_device(cm36651->ara_client);
return ret;
  }

@@ -698,6 +708,8 @@ static int cm36651_remove(struct i2c_client *client)
iio_device_unregister(indio_dev);
regulator_disable(cm36651->vled_reg);
free_irq(client->irq, indio_dev);
+   i2c_unregister_device(cm36651->ps_client);
+   i2c_unregister_device(cm36651->ara_client);

Good catch.


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/

[PATCH] perf sched latency: prettify printed table

[Ramkumar Ramachandra]

Cc: Frederic Weisbecker 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Arnaldo Carvalho de Melo 
Signed-off-by: Ramkumar Ramachandra 
---
 tools/perf/builtin-sched.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 6a76a07..0c41a2b 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -1124,7 +1124,7 @@ static void output_lat_thread(struct perf_sched *sched, 
struct work_atoms *work_
 
avg = work_list->total_lat / work_list->nb_atoms;
 
-   printf("|%11.3f ms |%9" PRIu64 " | avg:%9.3f ms | max:%9.3f ms | max 
at: %9.6f s\n",
+   printf("|%11.3f ms |%9" PRIu64 " | avg:%9.3f ms | max:%9.3f ms | max 
at: %12.6f s\n",
  (double)work_list->total_runtime / 1e6,
 work_list->nb_atoms, (double)avg / 1e6,
 (double)work_list->max_lat / 1e6,
@@ -1527,9 +1527,9 @@ static int perf_sched__lat(struct perf_sched *sched)
 
perf_sched__sort_lat(sched);
 
-   printf("\n 
---\n");
-   printf("  Task  |   Runtime ms  | Switches | Average 
delay ms | Maximum delay ms | Maximum delay at |\n");
-   printf(" 
---\n");
+   printf("\n 
-\n");
+   printf("  Task  |   Runtime ms  | Switches | Average 
delay ms | Maximum delay ms | Maximum delay at   |\n");
+   printf(" 
-\n");
 
next = rb_first(>sorted_atom_root);
 
@@ -1541,7 +1541,7 @@ static int perf_sched__lat(struct perf_sched *sched)
next = rb_next(next);
}
 
-   printf(" 
-\n");
+   printf(" 
-\n");
printf("  TOTAL:|%11.3f ms |%9" PRIu64 " |\n",
(double)sched->all_runtime / 1e6, sched->all_count);
 
-- 
1.9.rc0.1.g9d22d25

--
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: [mac80211_hwsim] BUG: unable to handle kernel paging request at ce1db404

[Krishna Chaitanya]

On Sat, Mar 15, 2014 at 9:11 PM, Johannes Berg
 wrote:
> On Sat, 2014-03-15 at 21:03 +0530, Krishna Chaitanya wrote:
>
>> > > what RC are u using? Default should be minstrel, i dont see
>> > > a reason for rc alloc to fail (remote reason kmalloc failure),
>> > > so did you disable RC completely? No prints either w.r.t RC either in
>> > > dmesg?
>> >
>> > Pay attention to the .config.
>> >
>> Missed the attachment, thanks for pointing.
>> As guessed the rate control is empty causing the registration fail.
>
> It still shouldn't crash though. Looks like there's a fix in this
> thread, can somebody verify & post it?
>
Yes, it should not crash. The change suggested by martin is not correct
there is no double free as the the list he mentioned will be empty.
(Only after successful registration we will add the radio to the list)

the problem here is platform_driver_unregister internally calls the
driver_unregister
which tries to get the kobject through get_device, but we have already
freed the kobject using
device_unregister (which calls device_del which frees the kobject).

In other failures cases we use mac80211_hwsim_free() and return, so the call to
platform_driver_unregister is not there, hence no crash.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 3.14-rc: /proc/acpi/battery gone?

[Pavel Machek]

Hi!

> >>>They have attempted to use the sysfs api, but apparently that
> >>>integration was done with an older version of that API. There's also
> >>>some attempt to get it to work with upower, but I couldn't figure out
> >>>how to make that work either on my (up-to-date gentoo) box. (TBH I
> >>>didn't spend more than an hour or two on it, so it may not be
> >>>impossible.)
> >>
> >>Tianyu, can you please have a look at this?
> >
> >Disclaimer, I've never used wmbattery so far.
> >
> >The current upstream version (2.42, released in early december 2013)
> >of wmbattery[1] no longer reads from /proc/acpi/ at all. Apparently
> >it changed to using upower by default, with non-default fall-backs for
> >reading from sysfs.
> >
> >The only change required for building upower with wmbattery 2.42
> >appears to be a new build-dependency on libupower-glib-dev (at least
> >on Debian, built from the upower source package). Given that this
> >version is present in Debian testing and unstable, I'd assume that it's
> >supposed to work using upower, although I haven't confirmed that myself.
> >
> >Judging from the Gentoo ebuild, you probably just have to add
> >"sys-power/upower" to the RDEPEND variable and make sure to build
> >wmbattery 2.42; this is untested.
> >
> 
> Hi Stefan:
>   I just glance wmbattery code. I find the code in the acpi.c is
> already using the new sysfs battery interfaces, right?
> 
> ...
> 
> #define SYSFS_PATH "/sys/class/power_supply"
> 
> ...
> char *acpi_labels[] = {
>   "uevent",
>   "status",
>   "BAT",
>   "AC",
>   "POWER_SUPPLY_CAPACITY=",
>   "POWER_SUPPLY_??_FULL_DESIGN=", /* CHARGE or ENERGY */
>   "POWER_SUPPLY_PRESENT=",
>   "POWER_SUPPLY_??_NOW=",
>   "POWER_SUPPLY_CURRENT_NOW=",
>   "POWER_SUPPLY_STATUS=",
> #if ACPI_THERMAL
>   "thermal_zone",
> #endif
>   "POWER_SUPPLY_ONLINE=",
>   "POWER_SUPPLY_??_FULL=",
>   NULL
> };

New kernel should work with old userspace... and clearly it does not.

Do you have test patch for a revert?

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/

[ INFO: possible circular locking dependency detected ]

[poma]

https://bugzilla.redhat.com/attachment.cgi?id=874823


poma

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

Re: [PATCH 0/4] perf: trivial follow-ons to --list-cmds

[David Ahern]

On 3/14/14, 9:17 PM, Ramkumar Ramachandra wrote:

Hi,

With "perf kvm: introduce --list-cmds for use by scripts" accepted,
these are trivial follow-on patches to enable the same functionality
in kmem, mem, lock, and sched.

Thanks.

Ramkumar Ramachandra (4):
   perf kmem: introduce --list-cmds for use by scripts
   perf mem: introduce --list-cmds for use by scripts
   perf lock: introduce --list-cmds for use by scripts
   perf sched: introduce --list-cmds for use by scripts



All 4 look good to me.

Acked-by: David Ahern 
--
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 01/10] perf, tools: Add jsmn `jasmine' JSON parser

[David Ahern]

On 3/14/14, 8:27 PM, Andi Kleen wrote:

On Fri, Mar 14, 2014 at 04:41:31PM -0600, David Ahern wrote:

On 3/14/14, 3:31 PM, Andi Kleen wrote:

@@ -374,6 +376,8 @@ LIB_OBJS += $(OUTPUT)util/stat.o
  LIB_OBJS += $(OUTPUT)util/record.o
  LIB_OBJS += $(OUTPUT)util/srcline.o
  LIB_OBJS += $(OUTPUT)util/data.o
+LIB_OBJS += $(OUTPUT)util/jsmn.o
+LIB_OBJS += $(OUTPUT)util/json.o

  LIB_OBJS += $(OUTPUT)ui/setup.o
  LIB_OBJS += $(OUTPUT)ui/helpline.o



CONFIG driven? Allow a user to omit this.


Why? It has no external dependencies. AFAIK that's the only reason for configs.


We have also talked about config driven builds to allow pieces to be 
omitted -- e.g., to keep binary size down for embedded systems. This is 
clearly a standalone piece so why not add the config upfront now?


David

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

Re: [mac80211_hwsim] BUG: unable to handle kernel paging request at ce1db404

[Johannes Berg]

On Sat, 2014-03-15 at 21:03 +0530, Krishna Chaitanya wrote:

> > > what RC are u using? Default should be minstrel, i dont see
> > > a reason for rc alloc to fail (remote reason kmalloc failure),
> > > so did you disable RC completely? No prints either w.r.t RC either in
> > > dmesg?
> >
> > Pay attention to the .config.
> >
> Missed the attachment, thanks for pointing.
> As guessed the rate control is empty causing the registration fail.

It still shouldn't crash though. Looks like there's a fix in this
thread, can somebody verify & post it?

Thx,
johannes

--
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: [PATCHv3 9/9] iio: inkern: add iio_read_channel_average_raw

[Jonathan Cameron]

On 10/03/14 17:25, Sebastian Reichel wrote:

Add iio_read_channel_average_raw to support reading
averaged raw values in consumer drivers.

Signed-off-by: Sebastian Reichel 

As this one also stands fine on it's own and isn't actually used
by the rest of the patch set - applied to the togreg branch of iio.git
This will get pushed out initially as 'testing' for the autobuilders
to play.

Jonathan

---
  drivers/iio/inkern.c | 18 ++
  include/linux/iio/consumer.h | 13 +
  2 files changed, 31 insertions(+)

diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
index 0cf5f8e..adeba5a 100644
--- a/drivers/iio/inkern.c
+++ b/drivers/iio/inkern.c
@@ -443,6 +443,24 @@ err_unlock:
  }
  EXPORT_SYMBOL_GPL(iio_read_channel_raw);

+int iio_read_channel_average_raw(struct iio_channel *chan, int *val)
+{
+   int ret;
+
+   mutex_lock(>indio_dev->info_exist_lock);
+   if (chan->indio_dev->info == NULL) {
+   ret = -ENODEV;
+   goto err_unlock;
+   }
+
+   ret = iio_channel_read(chan, val, NULL, IIO_CHAN_INFO_AVERAGE_RAW);
+err_unlock:
+   mutex_unlock(>indio_dev->info_exist_lock);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(iio_read_channel_average_raw);
+
  static int iio_convert_raw_to_processed_unlocked(struct iio_channel *chan,
int raw, int *processed, unsigned int scale)
  {
diff --git a/include/linux/iio/consumer.h b/include/linux/iio/consumer.h
index 2752b1f..651f9a0 100644
--- a/include/linux/iio/consumer.h
+++ b/include/linux/iio/consumer.h
@@ -123,6 +123,19 @@ int iio_read_channel_raw(struct iio_channel *chan,
 int *val);

  /**
+ * iio_read_channel_average_raw() - read from a given channel
+ * @chan:  The channel being queried.
+ * @val:   Value read back.
+ *
+ * Note raw reads from iio channels are in adc counts and hence
+ * scale will need to be applied if standard units required.
+ *
+ * In opposit to the normal iio_read_channel_raw this function
+ * returns the average of multiple reads.
+ */
+int iio_read_channel_average_raw(struct iio_channel *chan, int *val);
+
+/**
   * iio_read_channel_processed() - read processed value from a given channel
   * @chan: The channel being queried.
   * @val:  Value read back.



--
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: [PATCHv3 8/9] iio: documentation: Add ABI documentation for *_mean_raw

[Jonathan Cameron]

On 10/03/14 17:25, Sebastian Reichel wrote:

Add ABI documentation for in_*_mean_raw files, which are
already supported and used in the kernel for some time.

Signed-off-by: Sebastian Reichel 

As this one stands fine on it's own...

Applied to the togreg branch of iio.git

Thanks

---
  Documentation/ABI/testing/sysfs-bus-iio | 8 
  1 file changed, 8 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
b/Documentation/ABI/testing/sysfs-bus-iio
index 6e02c50..58ba333 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -210,6 +210,14 @@ Contact:   linux-...@vger.kernel.org
  Description:
Scaled humidity measurement in milli percent.

+What:  /sys/bus/iio/devices/iio:deviceX/in_X_mean_raw
+KernelVersion: 3.5
+Contact:   linux-...@vger.kernel.org
+Description:
+   Averaged raw measurement from channel X. The number of values
+   used for averaging is device specific. The converting rules for
+   normal raw values also applies to the averaged raw values.
+
  What: /sys/bus/iio/devices/iio:deviceX/in_accel_offset
  What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_offset
  What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_offset



--
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: [PATCHv3 3/9] mfd: twl4030-madc: Cleanup driver

[Jonathan Cameron]

On 10/03/14 17:25, Sebastian Reichel wrote:

Some style fixes in twl4030-madc driver.

Reported-by: Jonathan Cameron 
Reported-by: Lee Jones 
Signed-off-by: Sebastian Reichel 
Acked-by: Lee Jones 
Tested-by: Marek Belisko 

Acked-by: Jonathan Cameron 

One, whilst you are here request below.

---
  drivers/mfd/twl4030-madc.c   | 127 +++
  include/linux/i2c/twl4030-madc.h |   2 +-
  2 files changed, 62 insertions(+), 67 deletions(-)

diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c
index 1c5c4db..890d520 100644
--- a/drivers/mfd/twl4030-madc.c
+++ b/drivers/mfd/twl4030-madc.c
@@ -49,22 +49,22 @@

  #include 

-/*
+/**
   * struct twl4030_madc_data - a container for madc info
- * @dev - pointer to device structure for madc
- * @lock - mutex protecting this data structure
- * @requests - Array of request struct corresponding to SW1, SW2 and RT
- * @use_second_irq - IRQ selection (main or co-processor)
- * @imr - Interrupt mask register of MADC
- * @isr - Interrupt status register of MADC
+ * @dev:   Pointer to device structure for madc
+ * @lock:  Mutex protecting this data structure
+ * @requests:  Array of request struct corresponding to SW1, SW2 and RT
+ * @use_second_irq:IRQ selection (main or co-processor)
+ * @imr:   Interrupt mask register of MADC
+ * @isr:   Interrupt status register of MADC
   */
  struct twl4030_madc_data {
struct device *dev;
struct mutex lock;  /* mutex protecting this data structure */
struct twl4030_madc_request requests[TWL4030_MADC_NUM_METHODS];
bool use_second_irq;
-   int imr;
-   int isr;
+   u8 imr;
+   u8 isr;
  };

  static int twl4030_madc_read(struct iio_dev *iio_dev,
@@ -155,17 +155,16 @@ twl4030_divider_ratios[16] = {
  };


-/*
- * Conversion table from -3 to 55 degree Celcius
- */
-static int therm_tbl[] = {
-30800, 29500,  28300,  27100,
-26000, 24900,  23900,  22900,  22000,  21100,  20300,  19400,  18700,  17900,
-17200, 16500,  15900,  15300,  14700,  14100,  13600,  13100,  12600,  12100,
-11600, 11200,  10800,  10400,  1,  9630,   9280,   8950,   8620,   8310,
-8020,  7730,   7460,   7200,   6950,   6710,   6470,   6250,   6040,   5830,
-5640,  5450,   5260,   5090,   4920,   4760,   4600,   4450,   4310,   4170,
-4040,  3910,   3790,   3670,   3550
+/* Conversion table from -3 to 55 degrees Celcius */
+static int twl4030_therm_tbl[] = {
+   30800,  29500,  28300,  27100,
+   26000,  24900,  23900,  22900,  22000,  21100,  20300,  19400,  18700,
+   17900,  17200,  16500,  15900,  15300,  14700,  14100,  13600,  13100,
+   12600,  12100,  11600,  11200,  10800,  10400,  1,  9630,   9280,
+   8950,   8620,   8310,   8020,   7730,   7460,   7200,   6950,   6710,
+   6470,   6250,   6040,   5830,   5640,   5450,   5260,   5090,   4920,
+   4760,   4600,   4450,   4310,   4170,   4040,   3910,   3790,   3670,
+   3550
  };

  /*
@@ -197,11 +196,12 @@ const struct twl4030_madc_conversion_method 
twl4030_conversion_methods[] = {
  },
  };

-/*
- * Function to read a particular channel value.
- * @madc - pointer to struct twl4030_madc_data
- * @reg - lsb of ADC Channel
- * If the i2c read fails it returns an error else returns 0.
+/**
+ * twl4030_madc_channel_raw_read() - Function to read a particular channel 
value
+ * @madc:  pointer to struct twl4030_madc_data
+ * @reg:   lsb of ADC Channel
+ *
+ * Return: 0 on success, an error code otherwise.
   */
  static int twl4030_madc_channel_raw_read(struct twl4030_madc_data *madc, u8 
reg)
  {
@@ -227,7 +227,7 @@ static int twl4030_madc_channel_raw_read(struct 
twl4030_madc_data *madc, u8 reg)
  }

  /*
- * Return battery temperature
+ * Return battery temperature in degrees Celsius
   * Or < 0 on failure.
   */
  static int twl4030battery_temperature(int raw_volt)
@@ -236,18 +236,18 @@ static int twl4030battery_temperature(int raw_volt)
int temp, curr, volt, res, ret;

volt = (raw_volt * TEMP_STEP_SIZE) / TEMP_PSR_R;
-   /* Getting and calculating the supply current in micro ampers */
+   /* Getting and calculating the supply current in micro amperes */
ret = twl_i2c_read_u8(TWL_MODULE_MAIN_CHARGE, ,
REG_BCICTL2);
if (ret < 0)
return ret;
+
curr = ((val & TWL4030_BCI_ITHEN) + 1) * 10;
/* Getting and calculating the thermistor resistance in ohms */
res = volt * 1000 / curr;
/* calculating temperature */
for (temp = 58; temp >= 0; temp--) {
-   int actual = therm_tbl[temp];
-
+   int actual = twl4030_therm_tbl[temp];
if ((actual - res) >= 0)
break;
}
@@ -269,11 +269,12 @@ static int twl4030battery_current(int raw_volt)
else /* slope of 0.88 mV/mA */
return (raw_volt * 

Re: [PATCHv3 2/9] mfd: twl4030-madc: Add DT support and convert to IIO framework

[Jonathan Cameron]

On 10/03/14 17:25, Sebastian Reichel wrote:

This converts twl4030-madc module to use the Industrial IO ADC
framework and adds device tree support.

Signed-off-by: Sebastian Reichel 
Tested-by: Marek Belisko 


One issue in the remove function.  Reorder that
and I'm happy.


---
  drivers/mfd/twl4030-madc.c | 127 +
  1 file changed, 116 insertions(+), 11 deletions(-)

diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c
index 5458561..1c5c4db 100644
--- a/drivers/mfd/twl4030-madc.c
+++ b/drivers/mfd/twl4030-madc.c
@@ -47,11 +47,14 @@
  #include 
  #include 

+#include 
+
  /*
   * struct twl4030_madc_data - a container for madc info
   * @dev - pointer to device structure for madc
   * @lock - mutex protecting this data structure
   * @requests - Array of request struct corresponding to SW1, SW2 and RT
+ * @use_second_irq - IRQ selection (main or co-processor)
   * @imr - Interrupt mask register of MADC
   * @isr - Interrupt status register of MADC
   */
@@ -59,10 +62,71 @@ struct twl4030_madc_data {
struct device *dev;
struct mutex lock;  /* mutex protecting this data structure */
struct twl4030_madc_request requests[TWL4030_MADC_NUM_METHODS];
+   bool use_second_irq;
int imr;
int isr;
  };

+static int twl4030_madc_read(struct iio_dev *iio_dev,
+const struct iio_chan_spec *chan,
+int *val, int *val2, long mask)
+{
+   struct twl4030_madc_data *madc = iio_priv(iio_dev);
+   struct twl4030_madc_request req;
+   int ret;
+
+   req.method = madc->use_second_irq ? TWL4030_MADC_SW2 : TWL4030_MADC_SW1;
+
+   req.channels = BIT(chan->channel);
+   req.active = false;
+   req.func_cb = NULL;
+   req.type = TWL4030_MADC_WAIT;
+   req.raw = !(mask == IIO_CHAN_INFO_PROCESSED);
+   req.do_avg = (mask == IIO_CHAN_INFO_AVERAGE_RAW);
+
+   ret = twl4030_madc_conversion();
+   if (ret < 0)
+   return ret;
+
+   *val = req.rbuf[chan->channel];
+
+   return IIO_VAL_INT;
+}
+
+static const struct iio_info twl4030_madc_iio_info = {
+   .read_raw = _madc_read,
+   .driver_module = THIS_MODULE,
+};
+
+#define TWL4030_ADC_CHANNEL(_channel, _type, _name) {  \
+   .type = _type,  \
+   .channel = _channel,\
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |  \
+ BIT(IIO_CHAN_INFO_AVERAGE_RAW) | \
+ BIT(IIO_CHAN_INFO_PROCESSED), \
+   .datasheet_name = _name,\
+   .indexed = 1,   \
+}
+
+static const struct iio_chan_spec twl4030_madc_iio_channels[] = {
+   TWL4030_ADC_CHANNEL(0, IIO_VOLTAGE, "ADCIN0"),
+   TWL4030_ADC_CHANNEL(1, IIO_TEMP, "ADCIN1"),
+   TWL4030_ADC_CHANNEL(2, IIO_VOLTAGE, "ADCIN2"),
+   TWL4030_ADC_CHANNEL(3, IIO_VOLTAGE, "ADCIN3"),
+   TWL4030_ADC_CHANNEL(4, IIO_VOLTAGE, "ADCIN4"),
+   TWL4030_ADC_CHANNEL(5, IIO_VOLTAGE, "ADCIN5"),
+   TWL4030_ADC_CHANNEL(6, IIO_VOLTAGE, "ADCIN6"),
+   TWL4030_ADC_CHANNEL(7, IIO_VOLTAGE, "ADCIN7"),
+   TWL4030_ADC_CHANNEL(8, IIO_VOLTAGE, "ADCIN8"),
+   TWL4030_ADC_CHANNEL(9, IIO_VOLTAGE, "ADCIN9"),
+   TWL4030_ADC_CHANNEL(10, IIO_CURRENT, "ADCIN10"),
+   TWL4030_ADC_CHANNEL(11, IIO_VOLTAGE, "ADCIN11"),
+   TWL4030_ADC_CHANNEL(12, IIO_VOLTAGE, "ADCIN12"),
+   TWL4030_ADC_CHANNEL(13, IIO_VOLTAGE, "ADCIN13"),
+   TWL4030_ADC_CHANNEL(14, IIO_VOLTAGE, "ADCIN14"),
+   TWL4030_ADC_CHANNEL(15, IIO_VOLTAGE, "ADCIN15"),
+};
+
  static struct twl4030_madc_data *twl4030_madc;

  struct twl4030_prescale_divider_ratios {
@@ -702,28 +766,49 @@ static int twl4030_madc_probe(struct platform_device 
*pdev)
  {
struct twl4030_madc_data *madc;
struct twl4030_madc_platform_data *pdata = dev_get_platdata(>dev);
+   struct device_node *np = pdev->dev.of_node;
int irq, ret;
u8 regval;
+   struct iio_dev *iio_dev = NULL;

-   if (!pdata) {
-   dev_err(>dev, "platform_data not available\n");
+   if (!pdata && !np) {
+   dev_err(>dev, "neither platform data nor Device Tree node 
available\n");
return -EINVAL;
}
-   madc = devm_kzalloc(>dev, sizeof(*madc), GFP_KERNEL);
-   if (!madc)
+
+   iio_dev = devm_iio_device_alloc(>dev, sizeof(*madc));
+   if (!iio_dev) {
+   dev_err(>dev, "failed allocating iio device\n");
return -ENOMEM;
+   }

+   madc = iio_priv(iio_dev);
madc->dev = >dev;

+   iio_dev->name = dev_name(>dev);
+   iio_dev->dev.parent = >dev;
+   iio_dev->dev.of_node = pdev->dev.of_node;
+   iio_dev->info = _madc_iio_info;
+   iio_dev->modes = INDIO_DIRECT_MODE;
+   iio_dev->channels = twl4030_madc_iio_channels;
+   

Re: [PATCHv3 1/9] mfd: twl4030-madc: Use managed resources

[Jonathan Cameron]

On 10/03/14 17:25, Sebastian Reichel wrote:

Update twl4030-madc driver to use managed resources.

Signed-off-by: Sebastian Reichel 
Acked-by: Lee Jones 
Tested-by: Marek Belisko 

My email client was having a crazy day and not showing me this revision of the
patches - I'll bring my comments across so they don't get lost.

Acked-by: Jonathan Cameron 


--
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: [mac80211_hwsim] BUG: unable to handle kernel paging request at ce1db404

[Krishna Chaitanya]

On Sat, Mar 15, 2014 at 8:50 PM, Johannes Berg
 wrote:
>
> On Thu, 2014-03-13 at 02:15 +0530, Krishna Chaitanya wrote:
>
> > From the logs it looks like "rate_control_alloc" is failed,
> > causing ieee80211_register_hw to fail triggering the crash.
>
> Yes.
>
> > what RC are u using? Default should be minstrel, i dont see
> > a reason for rc alloc to fail (remote reason kmalloc failure),
> > so did you disable RC completely? No prints either w.r.t RC either in
> > dmesg?
>
> Pay attention to the .config.
>
Missed the attachment, thanks for pointing.
As guessed the rate control is empty causing the registration fail.

CONFIG_MAC80211=y
# CONFIG_MAC80211_RC_PID is not set
# CONFIG_MAC80211_RC_MINSTREL is not set
CONFIG_MAC80211_RC_DEFAULT=""
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] ARM: at91: at91sam9g45: change at91_adc name

[Jonathan Cameron]

On 10/03/14 13:26, Nicolas Ferre wrote:

On 06/03/2014 20:16, Jonathan Cameron :

On 05/03/14 16:57, Alexandre Belloni wrote:

We can't use "at91_adc" to refer to the at91_adc driver anymore as the name is
used to match an id_table.

Signed-off-by: Alexandre Belloni 

As stated in previous email, I'll take this along with the fix that 'broke'
this, if I get an Ack from one of the at91 maintainers.


Jonathan,

It is maybe more clear if I answer here:
- so, yes, you can take the 3 patches yourself (if you do not mind)
- you have, for the whole series::

Acked-by: Nicolas Ferre 

Applied to the fixes-togreg branch of iio.git

Timing wise, these will now hit immediately after the merge window closes.

Jonathan


Thanks for your help with this issue.

Bye,


---
   arch/arm/mach-at91/at91sam9g45_devices.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c 
b/arch/arm/mach-at91/at91sam9g45_devices.c
index cb36fa872d30..88554024eb2d 100644
--- a/arch/arm/mach-at91/at91sam9g45_devices.c
+++ b/arch/arm/mach-at91/at91sam9g45_devices.c
@@ -1203,7 +1203,7 @@ static struct resource adc_resources[] = {
   };

   static struct platform_device at91_adc_device = {
-   .name   = "at91_adc",
+   .name   = "at91sam9g45-adc",
.id = -1,
.dev= {
.platform_data  = _data,









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

Re: 3.14-rc: /proc/acpi/battery gone?

[Lan Tianyu]

On 03/14/2014 10:17 PM, Stefan Lippers-Hollmann wrote:

Hi

On Saturday 15 March 2014, Rafael J. Wysocki wrote:

On Friday, March 14, 2014 06:14:12 PM Ilia Mirkin wrote:

On Fri, Mar 14, 2014 at 6:11 PM, Pavel Machek  wrote:

On Fri 2014-03-14 17:29:41, Ilia Mirkin wrote:

On Fri, Mar 14, 2014 at 5:14 PM, Pavel Machek  wrote:

[...]

wmbattery

They have attempted to use the sysfs api, but apparently that
integration was done with an older version of that API. There's also
some attempt to get it to work with upower, but I couldn't figure out
how to make that work either on my (up-to-date gentoo) box. (TBH I
didn't spend more than an hour or two on it, so it may not be
impossible.)


Tianyu, can you please have a look at this?


Disclaimer, I've never used wmbattery so far.

The current upstream version (2.42, released in early december 2013)
of wmbattery[1] no longer reads from /proc/acpi/ at all. Apparently
it changed to using upower by default, with non-default fall-backs for
reading from sysfs.

The only change required for building upower with wmbattery 2.42
appears to be a new build-dependency on libupower-glib-dev (at least
on Debian, built from the upower source package). Given that this
version is present in Debian testing and unstable, I'd assume that it's
supposed to work using upower, although I haven't confirmed that myself.

Judging from the Gentoo ebuild, you probably just have to add
"sys-power/upower" to the RDEPEND variable and make sure to build
wmbattery 2.42; this is untested.



Hi Stefan:
	I just glance wmbattery code. I find the code in the acpi.c is already 
using the new sysfs battery interfaces, right?


...

#define SYSFS_PATH "/sys/class/power_supply"

...
char *acpi_labels[] = {
"uevent",
"status",
"BAT",
"AC",
"POWER_SUPPLY_CAPACITY=",
"POWER_SUPPLY_??_FULL_DESIGN=", /* CHARGE or ENERGY */
"POWER_SUPPLY_PRESENT=",
"POWER_SUPPLY_??_NOW=",
"POWER_SUPPLY_CURRENT_NOW=",
"POWER_SUPPLY_STATUS=",
#if ACPI_THERMAL
"thermal_zone",
#endif
"POWER_SUPPLY_ONLINE=",
"POWER_SUPPLY_??_FULL=",
NULL
};



Regards
Stefan Lippers-Hollmann

[1] Homepage: http://kitenet.net/~joey/code/wmbattery/
Vcs-Git: git://git.kitenet.net/wmbattery



--
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: [PATCHv2 9/9] iio: inkern: add iio_read_channel_average_raw

[Jonathan Cameron]

On 04/03/14 22:05, Sebastian Reichel wrote:

Add iio_read_channel_average_raw to support reading
averaged raw values in consumer drivers.

Signed-off-by: Sebastian Reichel 

Acked-by: Jonathan Cameron 

Sometimes these wrappers seem a little bit silly. There
might be a case for automating them somewhat via some
macros, but for now this is fine.

Docs should in theory probably be with the implementation,
but that's wrong throughout consumer.h so this isn't the time
to change it!

Jonathan

---
  drivers/iio/inkern.c | 18 ++
  include/linux/iio/consumer.h | 13 +
  2 files changed, 31 insertions(+)

diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
index 0cf5f8e..adeba5a 100644
--- a/drivers/iio/inkern.c
+++ b/drivers/iio/inkern.c
@@ -443,6 +443,24 @@ err_unlock:
  }
  EXPORT_SYMBOL_GPL(iio_read_channel_raw);

+int iio_read_channel_average_raw(struct iio_channel *chan, int *val)
+{
+   int ret;
+
+   mutex_lock(>indio_dev->info_exist_lock);
+   if (chan->indio_dev->info == NULL) {
+   ret = -ENODEV;
+   goto err_unlock;
+   }
+
+   ret = iio_channel_read(chan, val, NULL, IIO_CHAN_INFO_AVERAGE_RAW);
+err_unlock:
+   mutex_unlock(>indio_dev->info_exist_lock);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(iio_read_channel_average_raw);
+
  static int iio_convert_raw_to_processed_unlocked(struct iio_channel *chan,
int raw, int *processed, unsigned int scale)
  {
diff --git a/include/linux/iio/consumer.h b/include/linux/iio/consumer.h
index 2752b1f..651f9a0 100644
--- a/include/linux/iio/consumer.h
+++ b/include/linux/iio/consumer.h
@@ -123,6 +123,19 @@ int iio_read_channel_raw(struct iio_channel *chan,
 int *val);


Ah, my bad habits propogate onwards.  The docs should be with the 
implementation.
Oh well, at somepoint I'll clean all remaining cases of this up.

  /**
+ * iio_read_channel_average_raw() - read from a given channel
+ * @chan:  The channel being queried.
+ * @val:   Value read back.
+ *
+ * Note raw reads from iio channels are in adc counts and hence
+ * scale will need to be applied if standard units required.
+ *
+ * In opposit to the normal iio_read_channel_raw this function
+ * returns the average of multiple reads.
+ */
+int iio_read_channel_average_raw(struct iio_channel *chan, int *val);
+
+/**
   * iio_read_channel_processed() - read processed value from a given channel
   * @chan: The channel being queried.
   * @val:  Value read back.



--
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: [PATCHv2 8/9] iio: documentation: Add ABI documentation for *_mean_raw

[Jonathan Cameron]

On 04/03/14 22:05, Sebastian Reichel wrote:

Add ABI documentation for in_*_mean_raw files, which are
already supported and used in the kernel for some time.

Signed-off-by: Sebastian Reichel 

Acked-by: Jonathan Cameron 

Thanks for doing this.

---
  Documentation/ABI/testing/sysfs-bus-iio | 8 
  1 file changed, 8 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
b/Documentation/ABI/testing/sysfs-bus-iio
index 6e02c50..58ba333 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -210,6 +210,14 @@ Contact:   linux-...@vger.kernel.org
  Description:
Scaled humidity measurement in milli percent.

+What:  /sys/bus/iio/devices/iio:deviceX/in_X_mean_raw
+KernelVersion: 3.5
+Contact:   linux-...@vger.kernel.org
+Description:
+   Averaged raw measurement from channel X. The number of values
+   used for averaging is device specific. The converting rules for
+   normal raw values also applies to the averaged raw values.
+
  What: /sys/bus/iio/devices/iio:deviceX/in_accel_offset
  What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_offset
  What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_offset



--
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: [PATCHv2 6/9] Documentation: DT: Document twl4030-madc binding

[Jonathan Cameron]

On 04/03/14 22:05, Sebastian Reichel wrote:

Add devicetree binding documentation for twl4030-madc
analog digital converter.

Signed-off-by: Sebastian Reichel 

I'm happy with this, but it needs the usual sign off form a device tree
maintainer or 3 weeks to pass since it was posted.
Acked-by: Jonathan Cameron 

---
  .../devicetree/bindings/iio/adc/twl4030-madc.txt   | 24 ++
  1 file changed, 24 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/iio/adc/twl4030-madc.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/twl4030-madc.txt 
b/Documentation/devicetree/bindings/iio/adc/twl4030-madc.txt
new file mode 100644
index 000..6bdd214
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/twl4030-madc.txt
@@ -0,0 +1,24 @@
+* TWL4030 Monitoring Analog to Digital Converter (MADC)
+
+The MADC subsystem in the TWL4030 consists of a 10-bit ADC
+combined with a 16-input analog multiplexer.
+
+Required properties:
+  - compatible: Should contain "ti,twl4030-madc".
+  - interrupts: IRQ line for the MADC submodule.
+  - #io-channel-cells: Should be set to <1>.
+
+Optional properties:
+  - ti,system-uses-second-madc-irq: boolean, set if the second madc irq 
register
+   should be used, which is intended to be used
+   by Co-Processors (e.g. a modem).
+
+Example:
+
+ {
+   madc {
+   compatible = "ti,twl4030-madc";
+   interrupts = <3>;
+   #io-channel-cells = <1>;
+   };
+};



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

Re: [PATCHv2 3/9] mfd: twl4030-madc: Cleanup driver

[Jonathan Cameron]

On 04/03/14 22:05, Sebastian Reichel wrote:

Some style fixes in twl4030-madc driver.

Reported-by: Jonathan Cameron 

Gah - not sure I want to be known for reporting style
issues :)

Signed-off-by: Sebastian Reichel 
Acked-by: Lee Jones 

Looks good - one little whilst you are here comment below.
Acked-by: Jonathan Cameron 
whether you do that or not.  We can hardly hold there being
remaining style issues against a style cleanup patch ;)

---
  drivers/mfd/twl4030-madc.c   | 125 +++
  include/linux/i2c/twl4030-madc.h |   2 +-
  2 files changed, 61 insertions(+), 66 deletions(-)

diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c
index 0479af0..f37da65 100644
--- a/drivers/mfd/twl4030-madc.c
+++ b/drivers/mfd/twl4030-madc.c
@@ -49,22 +49,22 @@

  #include 

-/*
+/**
   * struct twl4030_madc_data - a container for madc info
- * @dev - pointer to device structure for madc
- * @lock - mutex protecting this data structure
- * @requests - Array of request struct corresponding to SW1, SW2 and RT
- * @use_second_irq - IRQ selection (main or co-processor)
- * @imr - Interrupt mask register of MADC
- * @isr - Interrupt status register of MADC
+ * @dev:   Pointer to device structure for madc
+ * @lock:  Mutex protecting this data structure
+ * @requests:  Array of request struct corresponding to SW1, SW2 and RT
+ * @use_second_irq:IRQ selection (main or co-processor)
+ * @imr:   Interrupt mask register of MADC
+ * @isr:   Interrupt status register of MADC
   */
  struct twl4030_madc_data {
struct device *dev;
struct mutex lock;  /* mutex protecting this data structure */
struct twl4030_madc_request requests[TWL4030_MADC_NUM_METHODS];
bool use_second_irq;
-   int imr;
-   int isr;
+   u8 imr;
+   u8 isr;
  };

  static int twl4030_madc_read(struct iio_dev *iio_dev,
@@ -155,17 +155,16 @@ twl4030_divider_ratios[16] = {
  };


-/*
- * Conversion table from -3 to 55 degree Celcius
- */
-static int therm_tbl[] = {
-30800, 29500,  28300,  27100,
-26000, 24900,  23900,  22900,  22000,  21100,  20300,  19400,  18700,  17900,
-17200, 16500,  15900,  15300,  14700,  14100,  13600,  13100,  12600,  12100,
-11600, 11200,  10800,  10400,  1,  9630,   9280,   8950,   8620,   8310,
-8020,  7730,   7460,   7200,   6950,   6710,   6470,   6250,   6040,   5830,
-5640,  5450,   5260,   5090,   4920,   4760,   4600,   4450,   4310,   4170,
-4040,  3910,   3790,   3670,   3550
+/* Conversion table from -3 to 55 degrees Celcius */
+static int twl4030_therm_tbl[] = {
+   30800,  29500,  28300,  27100,
+   26000,  24900,  23900,  22900,  22000,  21100,  20300,  19400,  18700,
+   17900,  17200,  16500,  15900,  15300,  14700,  14100,  13600,  13100,
+   12600,  12100,  11600,  11200,  10800,  10400,  1,  9630,   9280,
+   8950,   8620,   8310,   8020,   7730,   7460,   7200,   6950,   6710,
+   6470,   6250,   6040,   5830,   5640,   5450,   5260,   5090,   4920,
+   4760,   4600,   4450,   4310,   4170,   4040,   3910,   3790,   3670,
+   3550
  };

  /*
@@ -197,11 +196,12 @@ const struct twl4030_madc_conversion_method 
twl4030_conversion_methods[] = {
  },
  };

-/*
- * Function to read a particular channel value.
- * @madc - pointer to struct twl4030_madc_data
- * @reg - lsb of ADC Channel
- * If the i2c read fails it returns an error else returns 0.
+/**
+ * twl4030_madc_channel_raw_read() - Function to read a particular channel 
value
+ * @madc:  pointer to struct twl4030_madc_data
+ * @reg:   lsb of ADC Channel
+ *
+ * Return: 0 on success, an error code otherwise.
   */
  static int twl4030_madc_channel_raw_read(struct twl4030_madc_data *madc, u8 
reg)
  {
@@ -227,7 +227,7 @@ static int twl4030_madc_channel_raw_read(struct 
twl4030_madc_data *madc, u8 reg)
  }

  /*
- * Return battery temperature
+ * Return battery temperature in degrees Celsius
   * Or < 0 on failure.
   */
  static int twl4030battery_temperature(int raw_volt)
@@ -236,18 +236,18 @@ static int twl4030battery_temperature(int raw_volt)
int temp, curr, volt, res, ret;

volt = (raw_volt * TEMP_STEP_SIZE) / TEMP_PSR_R;
-   /* Getting and calculating the supply current in micro ampers */
+   /* Getting and calculating the supply current in micro amperes */
ret = twl_i2c_read_u8(TWL_MODULE_MAIN_CHARGE, ,
REG_BCICTL2);
if (ret < 0)
return ret;
+
curr = ((val & TWL4030_BCI_ITHEN) + 1) * 10;
/* Getting and calculating the thermistor resistance in ohms */
res = volt * 1000 / curr;
/* calculating temperature */
for (temp = 58; temp >= 0; temp--) {
-   int actual = therm_tbl[temp];
-
+   int actual = twl4030_therm_tbl[temp];
if ((actual - res) >= 0)
break;

Re: [PATCHv2 2/9] mfd: twl4030-madc: Add DT support and convert to IIO framework

[Jonathan Cameron]

On 04/03/14 22:05, Sebastian Reichel wrote:

This converts twl4030-madc module to use the Industrial IO ADC
framework and adds device tree support.

Signed-off-by: Sebastian Reichel 

One issues right down in the remove function alongside the ones Lee raised.
Otherwise looks pretty much there to me.

---
  drivers/mfd/twl4030-madc.c | 126 +
  1 file changed, 116 insertions(+), 10 deletions(-)

diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c
index 5458561..0479af0 100644
--- a/drivers/mfd/twl4030-madc.c
+++ b/drivers/mfd/twl4030-madc.c
@@ -47,11 +47,14 @@
  #include 
  #include 

+#include 
+
  /*
   * struct twl4030_madc_data - a container for madc info
   * @dev - pointer to device structure for madc
   * @lock - mutex protecting this data structure
   * @requests - Array of request struct corresponding to SW1, SW2 and RT
+ * @use_second_irq - IRQ selection (main or co-processor)
   * @imr - Interrupt mask register of MADC
   * @isr - Interrupt status register of MADC
   */
@@ -59,10 +62,71 @@ struct twl4030_madc_data {
struct device *dev;
struct mutex lock;  /* mutex protecting this data structure */
struct twl4030_madc_request requests[TWL4030_MADC_NUM_METHODS];
+   bool use_second_irq;
int imr;
int isr;
  };

+static int twl4030_madc_read(struct iio_dev *iio_dev,
+const struct iio_chan_spec *chan,
+int *val, int *val2, long mask)
+{
+   struct twl4030_madc_data *madc = iio_priv(iio_dev);
+   struct twl4030_madc_request req;
+   int ret;
+
+   req.method = madc->use_second_irq ? TWL4030_MADC_SW2 : TWL4030_MADC_SW1;
+
+   req.channels = BIT(chan->channel);
+   req.active = false;
+   req.func_cb = NULL;
+   req.type = TWL4030_MADC_WAIT;
+   req.raw = !(mask == IIO_CHAN_INFO_PROCESSED);
+   req.do_avg = (mask == IIO_CHAN_INFO_AVERAGE_RAW);
+
+   ret = twl4030_madc_conversion();
+   if (ret < 0)
+   return ret;
+
+   *val = req.rbuf[chan->channel];
+
+   return IIO_VAL_INT;
+}
+
+static const struct iio_info twl4030_madc_iio_info = {
+   .read_raw = _madc_read,
+   .driver_module = THIS_MODULE,
+};
+
+#define TWL4030_ADC_CHANNEL(_channel, _type, _name) {  \
+   .type = _type,  \
+   .channel = _channel,\
+   .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |  \
+ BIT(IIO_CHAN_INFO_AVERAGE_RAW) | \
+ BIT(IIO_CHAN_INFO_PROCESSED), \
+   .datasheet_name = _name,\
+   .indexed = 1,   \
+}
+
+static const struct iio_chan_spec twl4030_madc_iio_channels[] = {
+   TWL4030_ADC_CHANNEL(0, IIO_VOLTAGE, "ADCIN0"),
+   TWL4030_ADC_CHANNEL(1, IIO_TEMP, "ADCIN1"),
+   TWL4030_ADC_CHANNEL(2, IIO_VOLTAGE, "ADCIN2"),
+   TWL4030_ADC_CHANNEL(3, IIO_VOLTAGE, "ADCIN3"),
+   TWL4030_ADC_CHANNEL(4, IIO_VOLTAGE, "ADCIN4"),
+   TWL4030_ADC_CHANNEL(5, IIO_VOLTAGE, "ADCIN5"),
+   TWL4030_ADC_CHANNEL(6, IIO_VOLTAGE, "ADCIN6"),
+   TWL4030_ADC_CHANNEL(7, IIO_VOLTAGE, "ADCIN7"),
+   TWL4030_ADC_CHANNEL(8, IIO_VOLTAGE, "ADCIN8"),
+   TWL4030_ADC_CHANNEL(9, IIO_VOLTAGE, "ADCIN9"),
+   TWL4030_ADC_CHANNEL(10, IIO_CURRENT, "ADCIN10"),
+   TWL4030_ADC_CHANNEL(11, IIO_VOLTAGE, "ADCIN11"),
+   TWL4030_ADC_CHANNEL(12, IIO_VOLTAGE, "ADCIN12"),
+   TWL4030_ADC_CHANNEL(13, IIO_VOLTAGE, "ADCIN13"),
+   TWL4030_ADC_CHANNEL(14, IIO_VOLTAGE, "ADCIN14"),
+   TWL4030_ADC_CHANNEL(15, IIO_VOLTAGE, "ADCIN15"),
+};
+
  static struct twl4030_madc_data *twl4030_madc;

  struct twl4030_prescale_divider_ratios {
@@ -702,28 +766,50 @@ static int twl4030_madc_probe(struct platform_device 
*pdev)
  {
struct twl4030_madc_data *madc;
struct twl4030_madc_platform_data *pdata = dev_get_platdata(>dev);
+   struct device_node *np = pdev->dev.of_node;
int irq, ret;
u8 regval;
+   struct iio_dev *iio_dev = NULL;

-   if (!pdata) {
-   dev_err(>dev, "platform_data not available\n");
+   if (!pdata && !np) {
+   dev_err(>dev, "neither platform data nor Device Tree node 
available\n");
return -EINVAL;
}
-   madc = devm_kzalloc(>dev, sizeof(*madc), GFP_KERNEL);
-   if (!madc)
+
+   iio_dev = devm_iio_device_alloc(>dev, sizeof(*madc));
+   if (!iio_dev) {
+   dev_err(>dev, "failed allocating iio device\n");
return -ENOMEM;
+   }

+   madc = iio_priv(iio_dev);
madc->dev = >dev;
+   madc->use_second_irq = false;
+
+   iio_dev->name = dev_name(>dev);
+   iio_dev->dev.parent = >dev;
+   iio_dev->dev.of_node = pdev->dev.of_node;
+   iio_dev->info = _madc_iio_info;
+   iio_dev->modes = INDIO_DIRECT_MODE;
+   

Re: [mac80211_hwsim] BUG: unable to handle kernel paging request at ce1db404

[Johannes Berg]

On Thu, 2014-03-13 at 02:15 +0530, Krishna Chaitanya wrote:

> From the logs it looks like "rate_control_alloc" is failed,
> causing ieee80211_register_hw to fail triggering the crash.

Yes.

> what RC are u using? Default should be minstrel, i dont see
> a reason for rc alloc to fail (remote reason kmalloc failure),
> so did you disable RC completely? No prints either w.r.t RC either in
> dmesg?

Pay attention to the .config.

johannes

--
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: [PATCHv2 1/9] mfd: twl4030-madc: Use managed resources

[Jonathan Cameron]

On 04/03/14 22:05, Sebastian Reichel wrote:

Update twl4030-madc driver to use managed resources.

Signed-off-by: Sebastian Reichel 
Acked-by: Lee Jones 

Acked-by: Jonathan Cameron 

---
  drivers/mfd/twl4030-madc.c | 15 ++-
  1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/mfd/twl4030-madc.c b/drivers/mfd/twl4030-madc.c
index 4c583e4..5458561 100644
--- a/drivers/mfd/twl4030-madc.c
+++ b/drivers/mfd/twl4030-madc.c
@@ -702,14 +702,14 @@ static int twl4030_madc_probe(struct platform_device 
*pdev)
  {
struct twl4030_madc_data *madc;
struct twl4030_madc_platform_data *pdata = dev_get_platdata(>dev);
-   int ret;
+   int irq, ret;
u8 regval;

if (!pdata) {
dev_err(>dev, "platform_data not available\n");
return -EINVAL;
}
-   madc = kzalloc(sizeof(*madc), GFP_KERNEL);
+   madc = devm_kzalloc(>dev, sizeof(*madc), GFP_KERNEL);
if (!madc)
return -ENOMEM;

@@ -726,7 +726,7 @@ static int twl4030_madc_probe(struct platform_device *pdev)
TWL4030_MADC_ISR1 : TWL4030_MADC_ISR2;
ret = twl4030_madc_set_power(madc, 1);
if (ret < 0)
-   goto err_power;
+   return ret;
ret = twl4030_madc_set_current_generator(madc, 0, 1);
if (ret < 0)
goto err_current_generator;
@@ -770,7 +770,9 @@ static int twl4030_madc_probe(struct platform_device *pdev)

platform_set_drvdata(pdev, madc);
mutex_init(>lock);
-   ret = request_threaded_irq(platform_get_irq(pdev, 0), NULL,
+
+   irq = platform_get_irq(pdev, 0);
+   ret = devm_request_threaded_irq(>dev, irq, NULL,
   twl4030_madc_threaded_irq_handler,
   IRQF_TRIGGER_RISING, "twl4030_madc", madc);
if (ret) {
@@ -783,9 +785,6 @@ err_i2c:
twl4030_madc_set_current_generator(madc, 0, 0);
  err_current_generator:
twl4030_madc_set_power(madc, 0);
-err_power:
-   kfree(madc);
-
return ret;
  }

@@ -793,10 +792,8 @@ static int twl4030_madc_remove(struct platform_device 
*pdev)
  {
struct twl4030_madc_data *madc = platform_get_drvdata(pdev);

-   free_irq(platform_get_irq(pdev, 0), madc);
twl4030_madc_set_current_generator(madc, 0, 0);
twl4030_madc_set_power(madc, 0);
-   kfree(madc);

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/

Re: [PATCH] virtio-blk: make the queue depth the max supportable by the hypervisor

[Theodore Ts'o]

On Sat, Mar 15, 2014 at 06:57:23AM -0700, Christoph Hellwig wrote:
> I don't think this should be a module parameter.  The default sizing
> should be based of the parameters of the actual virtqueue, and if we
> want to allow tuning it it should be by a sysfs attribute, preferable
> using the same semantics as SCSI.

I wanted that too, but looking at the multiqueue code, it wasn't all
obvious how to safely adjust the queue depth once the virtio-blk
device driver is initialized and becomes active.  There are all sorts
data structures including bitmaps, etc. that would have to be resized,
and I decided it would be too difficult / risky for me to make it be
dynamically resizeable.

So I settled on a module parameter thinking it would mostly only used
by testers / benchmarkers.

Can someone suggest a way to do a dynamic resizing of the virtio-blk
queue depth easily / safely?

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

Re: 3.14-rc: /proc/acpi/battery gone?

[Lan Tianyu]

On 03/14/2014 05:45 PM, Richard Weinberger wrote:

On Fri, Mar 14, 2014 at 10:29 PM, Ilia Mirkin  wrote:

On Fri, Mar 14, 2014 at 5:14 PM, Pavel Machek  wrote:

Hi!

It seems /proc/acpi/battery interface is gone, and I don't see any
option to reintroduce it... what is going on?


The interface went away in a semi-recent kernel release (3.13 or
3.12), breaking pretty much every battery app. (Admittedly the
interface was marked as deprecated for quite some time, but that
didn't stop everyone from using it and not caring about the new
thing.) I've yet to find a windowmaker dock app that works with the
current sysfs API :(



commit 1e2d9cdfb4494fce682b4ae010d86a2766816d36
Author: Lan Tianyu 
Date:   Fri Oct 11 09:54:08 2013 +0800

 ACPI / Battery: Remove battery's proc directory

 The battery's proc directory isn't useded and remove it.

 Signed-off-by: Lan Tianyu 
 Signed-off-by: Rafael J. Wysocki 

Looks like this one is the said commit.
If it breaks userspace we have to revert it IMHO.



Yes, we will revert the commit if it really breaks some APPs.
--
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/

Fwd: vmcore-dmesg ends with "No program header covering vaddr"

[Prasad Koya]

Forwarding to lkml. If there is any other relevant mailing list, pl let me know.


-- Forwarded message --
From: Prasad Koya 
Date: Fri, Mar 14, 2014 at 10:39 PM
Subject: vmcore-dmesg ends with "No program header covering vaddr"
To: ke...@lists.infradead.org


Hi

I'm increasing dmesg buffer size at runtime by passing log_buf_len=1M
(or 512K) at command line. At compile time, I have LOG_BUF_LEN as
256K. However, when this kernel crashes (crashkernel set at 64M),
vmcore-dmesg fails with below error.

No program header covering vaddr 0x88013ff0found kexec bug?

Am I missing something here?

Thank you.

Here are some debugs I added to kernel. This is with 3.4 kernel and
I've tried with kexec-tools-2.0.4.

[0.00] log_buf_len_setup: log_buf_len 262144 new 1048576
8170b140
[0.00] setup_log_buf: early 1 262144 new_log_buf_len 1048576
[0.00] log_buf_len: 1048576 880037d58000
[0.00] early log buf free: 258671(98%)
[0.00] setup_log_buf: early 0 1048576 new_log_buf_len 0
[0.503752] log_buf_kexec_setup: lbl 1048576 new 0 816198c4
logbuf 880037d58000
In kdump, running vmcore_dmesg /proc/vmcore
No program header covering vaddr 0x88013ff0found kexec bug?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/2] irqchip: sun4i: simplify sun4i_irq_ack

[Hans de Goede]

Now that we only ack irq 0 the code can be simplified a lot.

Also switch from read / modify / write to a simple write clear:
1) This is what the android code does (it has a hack for acking irq 0
  in its unmask code doing this)
2) read / modify / write simply does not make sense for an irq status
  register like this, if the other bits are writeable (and the data sheet says
  they are not) they should be write 1 to clear, since otherwise a read /
  modify / write can race with a device raising an interrupt and then clear
  the pending bit unintentionally

Signed-off-by: Hans de Goede 
---
 drivers/irqchip/irq-sun4i.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/irqchip/irq-sun4i.c b/drivers/irqchip/irq-sun4i.c
index 6a8c88d..75615b5 100644
--- a/drivers/irqchip/irq-sun4i.c
+++ b/drivers/irqchip/irq-sun4i.c
@@ -41,16 +41,11 @@ static asmlinkage void __exception_irq_entry 
sun4i_handle_irq(struct pt_regs *re
 static void sun4i_irq_ack(struct irq_data *irqd)
 {
unsigned int irq = irqd_to_hwirq(irqd);
-   unsigned int irq_off = irq % 32;
-   int reg = irq / 32;
-   u32 val;
 
if (irq != 0)
return; /* Only IRQ 0 / the ENMI needs to be acked */
 
-   val = readl(sun4i_irq_base + SUN4I_IRQ_PENDING_REG(reg));
-   writel(val | (1 << irq_off),
-  sun4i_irq_base + SUN4I_IRQ_PENDING_REG(reg));
+   writel(BIT(0), sun4i_irq_base + SUN4I_IRQ_PENDING_REG(0));
 }
 
 static void sun4i_irq_mask(struct irq_data *irqd)
-- 
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 v2 1/2] irqchip: sun4i: Use handle_fasteoi_irq for all interrupts

[Hans de Goede]

Since the sun4i irq chip does not require any action and clears the interrupt
when the level goes back to inactive, we don't need to mask / unmask for
non oneshot IRQs, to achieve this we make sun4i_irq_ack a nop for all irqs
except irq 0 and use handle_fasteoi_irq for all interrupts.

Now there might be a case when the device reactivates the interrupt
before the RETI. But that does not matter as we run the primary
interrupt handlers with interrupts disabled.

This also allows us to get rid of needing to use 2 irq_chip structs, this
means that the IRQCHIP_EOI_THREADED | IRQCHIP_EOI_IF_HANDLED will now influence
all interrupts rather then just irq 0, but that does not matter as the eoi
is now a nop anyways for all interrupts but irq 0.

Signed-off-by: Hans de Goede 
---
 drivers/irqchip/irq-sun4i.c | 18 --
 1 file changed, 4 insertions(+), 14 deletions(-)

diff --git a/drivers/irqchip/irq-sun4i.c b/drivers/irqchip/irq-sun4i.c
index a0ed1ea..6a8c88d 100644
--- a/drivers/irqchip/irq-sun4i.c
+++ b/drivers/irqchip/irq-sun4i.c
@@ -45,6 +45,9 @@ static void sun4i_irq_ack(struct irq_data *irqd)
int reg = irq / 32;
u32 val;
 
+   if (irq != 0)
+   return; /* Only IRQ 0 / the ENMI needs to be acked */
+
val = readl(sun4i_irq_base + SUN4I_IRQ_PENDING_REG(reg));
writel(val | (1 << irq_off),
   sun4i_irq_base + SUN4I_IRQ_PENDING_REG(reg));
@@ -76,13 +79,6 @@ static void sun4i_irq_unmask(struct irq_data *irqd)
 
 static struct irq_chip sun4i_irq_chip = {
.name   = "sun4i_irq",
-   .irq_mask   = sun4i_irq_mask,
-   .irq_unmask = sun4i_irq_unmask,
-};
-
-/* IRQ 0 / the ENMI needs a late eoi call */
-static struct irq_chip sun4i_irq_chip_enmi = {
-   .name   = "sun4i_irq",
.irq_eoi= sun4i_irq_ack,
.irq_mask   = sun4i_irq_mask,
.irq_unmask = sun4i_irq_unmask,
@@ -92,13 +88,7 @@ static struct irq_chip sun4i_irq_chip_enmi = {
 static int sun4i_irq_map(struct irq_domain *d, unsigned int virq,
 irq_hw_number_t hw)
 {
-   if (hw == 0)
-   irq_set_chip_and_handler(virq, _irq_chip_enmi,
-handle_fasteoi_irq);
-   else
-   irq_set_chip_and_handler(virq, _irq_chip,
-handle_level_irq);
-
+   irq_set_chip_and_handler(virq, _irq_chip, handle_fasteoi_irq);
set_irq_flags(virq, IRQF_VALID | IRQF_PROBE);
 
return 0;
-- 
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 v2 0/2] irqchip: sun4i: Use handle_fasteoi_irq for all irqs

[Hans de Goede]

Hi All,

Here is v2 of my patchset for sun4i-irq.c to use handle_fasteoi_irq for all
irqs + follow up clean-up patch.

Changes since v2:
-adjust commit msg based on Thomas' comments, and merge patch 1 and 2 as
 they make more sense as 1 patch

Regards,

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

Re: [PATCH v8 2/2] iio: Add AS3935 lightning sensor support

[Jonathan Cameron]

On 13/03/14 02:09, Marek Vasut wrote:

On Wednesday, March 12, 2014 at 01:53:14 PM, Matt Ranostay wrote:

AS3935 chipset can detect lightning strikes and reports those back as
events and the estimated distance to the storm.

Signed-off-by: Matt Ranostay 


Reviewed-by: Marek Vasut 

I'm not 100% happy with sensor_sensitivity but don't have a better idea.
As it is device specific lets leave it be for now.   Should we come
up with a better idea later it isn't much extra code to keep supporting
this interface going forwards.

Applied to the togreg branch of iio.git (pushed out initially as testing)

Thanks,

Jonathan

--
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 v8 1/2] iio:as3935: Add DT binding docs for AS3935 driver

[Jonathan Cameron]

On 12/03/14 14:30, Rob Herring wrote:

On Wed, Mar 12, 2014 at 7:53 AM, Matt Ranostay  wrote:

Document compatible string, required and optional DT properties for
AS3935 chipset driver.

Signed-off-by: Matt Ranostay 


Acked-by: Rob Herring 

Applied to the togreg branch of iio.git (probably pushed out as testing
first to allow the autobuilders to play.

Thanks

Jonathan



---
  .../devicetree/bindings/iio/proximity/as3935.txt   | 28 ++
  .../devicetree/bindings/vendor-prefixes.txt|  1 +
  2 files changed, 29 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/iio/proximity/as3935.txt

diff --git a/Documentation/devicetree/bindings/iio/proximity/as3935.txt 
b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
new file mode 100644
index 000..ae23dd8
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
@@ -0,0 +1,28 @@
+Austrian Microsystems AS3935 Franklin lightning sensor device driver
+
+Required properties:
+   - compatible: must be "ams,as3935"
+   - reg: SPI chip select number for the device
+   - spi-cpha: SPI Mode 1. Refer to spi/spi-bus.txt for generic SPI
+   slave node bindings.
+   - interrupt-parent : should be the phandle for the interrupt controller
+   - interrupts : the sole interrupt generated by the device
+
+   Refer to interrupt-controller/interrupts.txt for generic
+   interrupt client node bindings.
+
+Optional properties:
+   - ams,tuning-capacitor-pf: Calibration tuning capacitor stepping
+ value 0 - 120pF. This will require using the calibration data from
+ the manufacturer.
+
+Example:
+
+as3935@0 {
+   compatible = "ams,as3935";
+   reg = <0>;
+   spi-cpha;
+   interrupt-parent = <>;
+   interrupts = <16 1>;
+   ams,tuning-capacitor-pf = <80>;
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 4685ec3..517831d 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -11,6 +11,7 @@ akAsahi Kasei Corp.
  allwinner  Allwinner Technology Co., Ltd.
  altr   Altera Corp.
  amcc   Applied Micro Circuits Corporation (APM, formally AMCC)
+amsAMS AG
  amstaosAMS-Taos Inc.
  apmApplied Micro Circuits Corporation (APM)
  armARM Ltd.
--
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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



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