KREDIT ANGEBOT / LOAN OFFER
Sie benötigen die Finanzierung? Haben Sie Geschäfts-oder persönliche Darlehen benötigen? Wollen Sie Ihr Unternehmen refinanzieren wollen? Unser Unternehmen ist in den Vereinigten Staaten und Europa. Wir geben Darlehen an jedem einzelnen Unternehmen und bei 2% Zinsen jährlich. Für weitere Informationen, Kontakt e-standardloancompanyma...@rediffmail.com Hinweis: Leiten Sie Ihre Antwort auf diese E-Mail NUR: standardloancompanyma...@rediffmail.com == Do you need funding? Do you need Business or personal Loan? Do you wish to refinance your company? Our company is based in United States and Europe. We give out loan to any individual and company at 2% interest rate yearly. For more information, Contact Email: standardloancompanyma...@rediffmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/2] mm/afmalloc: introduce anti-fragmentation memory allocator
On Mon, Sep 29, 2014 at 11:41:45AM -0400, Dan Streetman wrote:
> On Fri, Sep 26, 2014 at 2:53 AM, Joonsoo Kim wrote:
> > WARNING: This is just RFC patchset. patch 2/2 is only for testing.
> > If you know useful place to use this allocator, please let me know.
> >
> > This is brand-new allocator, called anti-fragmentation memory allocator
> > (aka afmalloc), in order to deal with arbitrary sized object allocation
> > efficiently. zram and zswap uses arbitrary sized object to store
> > compressed data so they can use this allocator. If there are any other
> > use cases, they can use it, too.
> >
> > This work is motivated by observation of fragmentation on zsmalloc which
> > intended for storing arbitrary sized object with low fragmentation.
> > Although it works well on allocation-intensive workload, memory could be
> > highly fragmented after many free occurs. In some cases, unused memory due
> > to fragmentation occupy 20% ~ 50% amount of real used memory. The other
> > problem is that other subsystem cannot use these unused memory. These
> > fragmented memory are zsmalloc specific, so most of other subsystem cannot
> > use it until zspage is freed to page allocator.
> >
> > I guess that there are similar fragmentation problem in zbud, but, I
> > didn't deeply investigate it.
> >
> > This new allocator uses SLAB allocator to solve above problems. When
> > request comes, it returns handle that is pointer of metatdata to point
> > many small chunks. These small chunks are in power of 2 size and
> > build up whole requested memory. We can easily acquire these chunks
> > using SLAB allocator. Following is conceptual represetation of metadata
> > used in this allocator to help understanding of this allocator.
> >
> > Handle A for 400 bytes
> > {
> > Pointer for 256 bytes chunk
> > Pointer for 128 bytes chunk
> > Pointer for 16 bytes chunk
> >
> > (256 + 128 + 16 = 400)
> > }
> >
> > As you can see, 400 bytes memory are not contiguous in afmalloc so that
> > allocator specific store/load functions are needed. These require some
> > computation overhead and I guess that this is the only drawback this
> > allocator has.
>
> This also requires additional memory copying, for each map/unmap, no?
Indeed.
>
> >
> > For optimization, it uses another approach for power of 2 sized request.
> > Instead of returning handle for metadata, it adds tag on pointer from
> > SLAB allocator and directly returns this value as handle. With this tag,
> > afmalloc can recognize whether handle is for metadata or not and do proper
> > processing on it. This optimization can save some memory.
> >
> > Although afmalloc use some memory for metadata, overall utilization of
> > memory is really good due to zero internal fragmentation by using power
> > of 2 sized object. Although zsmalloc has many size class, there is
> > considerable internal fragmentation in zsmalloc.
> >
> > In workload that needs many free, memory could be fragmented like
> > zsmalloc, but, there is big difference. These unused portion of memory
> > are SLAB specific memory so that other subsystem can use it. Therefore,
> > fragmented memory could not be a big problem in this allocator.
> >
> > Extra benefit of this allocator design is NUMA awareness. This allocator
> > allocates real memory from SLAB allocator. SLAB considers client's NUMA
> > affinity, so these allocated memory is NUMA-friendly. Currently, zsmalloc
> > and zbud which are backend of zram and zswap, respectively, are not NUMA
> > awareness so that remote node's memory could be returned to requestor.
> > I think that it could be solved easily if NUMA awareness turns out to be
> > real problem. But, it may enlarge fragmentation depending on number of
> > nodes. Anyway, there is no NUMA awareness issue in this allocator.
> >
> > Although I'd like to replace zsmalloc with this allocator, it cannot be
> > possible, because zsmalloc supports HIGHMEM. In 32-bits world, SLAB memory
> > would be very limited so supporting HIGHMEM would be really good advantage
> > of zsmalloc. Because there is no HIGHMEM in 32-bits low memory device or
> > 64-bits world, this allocator may be good option for this system. I
> > didn't deeply consider whether this allocator can replace zbud or not.
>
> While it looks like there may be some situations that benefit from
> this, this won't work for all cases (as you mention), so maybe zpool
> can allow zram to choose between zsmalloc and afmalloc.
Yes. :)
> >
> > Below is the result of my simple test.
> > (zsmalloc used in experiments is patched with my previous patch:
> > zsmalloc: merge size_class to reduce fragmentation)
> >
> > TEST ENV: EXT4 on zram, mount with discard option
> > WORKLOAD: untar kernel source, remove dir in descending order in size.
> > (drivers arch fs sound include)
> >
> > Each line represents orig_data_size, compr_data_size, mem_used_total,
> > fragmentation overhead (mem_used - compr_data_size) and overhead ratio
> >
Re: [PATCH v4] zsmalloc: merge size_class to reduce fragmentation
On Thu, Oct 02, 2014 at 02:39:49PM +0900, Joonsoo Kim wrote: > On Tue, Sep 30, 2014 at 08:10:22AM +0900, Minchan Kim wrote: > > Hey Joonsoo, > > > > On Mon, Sep 29, 2014 at 04:45:27PM +0900, Joonsoo Kim wrote: > > > zsmalloc has many size_classes to reduce fragmentation and they are > > > in 16 bytes unit, for example, 16, 32, 48, etc., if PAGE_SIZE is 4096. > > > And, zsmalloc has constraint that each zspage has 4 pages at maximum. > > > > > > In this situation, we can see interesting aspect. > > > Let's think about size_class for 1488, 1472, ..., 1376. > > > To prevent external fragmentation, they uses 4 pages per zspage and > > > so all they can contain 11 objects at maximum. > > > > > > 16384 (4096 * 4) = 1488 * 11 + remains > > > 16384 (4096 * 4) = 1472 * 11 + remains > > > 16384 (4096 * 4) = ... > > > 16384 (4096 * 4) = 1376 * 11 + remains > > > > > > It means that they have same characteristics and classification between > > > them isn't needed. If we use one size_class for them, we can reduce > > > fragementation and save some memory since both the 1488 and 1472 sized > > > classes can only fit 11 objects into 4 pages, and an object that's > > > 1472 bytes can fit into an object that's 1488 bytes, merging these > > > classes to always use objects that are 1488 bytes will reduce the total > > > number of size classes. And reducing the total number of size classes > > > reduces overall fragmentation, because a wider range of compressed pages > > > can fit into a single size class, leaving less unused objects in each > > > size class. > > > > > > For this purpose, this patch implement size_class merging. If there is > > > size_class that have same pages_per_zspage and same number of objects > > > per zspage with previous size_class, we don't create new size_class. > > > Instead, we use previous, same characteristic size_class. With this way, > > > above example sizes (1488, 1472, ..., 1376) use just one size_class > > > so we can get much more memory utilization. > > > > > > Below is result of my simple test. > > > > > > TEST ENV: EXT4 on zram, mount with discard option > > > WORKLOAD: untar kernel source code, remove directory in descending order > > > in size. (drivers arch fs sound include net Documentation firmware > > > kernel tools) > > > > > > Each line represents orig_data_size, compr_data_size, mem_used_total, > > > fragmentation overhead (mem_used - compr_data_size) and overhead ratio > > > (overhead to compr_data_size), respectively, after untar and remove > > > operation is executed. > > > > > > * untar-nomerge.out > > > > > > orig_size compr_size used_size overhead overhead_ratio > > > 525.88MB 199.16MB 210.23MB 11.08MB 5.56% > > > 288.32MB 97.43MB 105.63MB 8.20MB 8.41% > > > 177.32MB 61.12MB 69.40MB 8.28MB 13.55% > > > 146.47MB 47.32MB 56.10MB 8.78MB 18.55% > > > 124.16MB 38.85MB 48.41MB 9.55MB 24.58% > > > 103.93MB 31.68MB 40.93MB 9.25MB 29.21% > > > 84.34MB 22.86MB 32.72MB 9.86MB 43.13% > > > 66.87MB 14.83MB 23.83MB 9.00MB 60.70% > > > 60.67MB 11.11MB 18.60MB 7.49MB 67.48% > > > 55.86MB 8.83MB 16.61MB 7.77MB 88.03% > > > 53.32MB 8.01MB 15.32MB 7.31MB 91.24% > > > > > > * untar-merge.out > > > > > > orig_size compr_size used_size overhead overhead_ratio > > > 526.23MB 199.18MB 209.81MB 10.64MB 5.34% > > > 288.68MB 97.45MB 104.08MB 6.63MB 6.80% > > > 177.68MB 61.14MB 66.93MB 5.79MB 9.47% > > > 146.83MB 47.34MB 52.79MB 5.45MB 11.51% > > > 124.52MB 38.87MB 44.30MB 5.43MB 13.96% > > > 104.29MB 31.70MB 36.83MB 5.13MB 16.19% > > > 84.70MB 22.88MB 27.92MB 5.04MB 22.04% > > > 67.11MB 14.83MB 19.26MB 4.43MB 29.86% > > > 60.82MB 11.10MB 14.90MB 3.79MB 34.17% > > > 55.90MB 8.82MB 12.61MB 3.79MB 42.97% > > > 53.32MB 8.01MB 11.73MB 3.73MB 46.53% > > > > > > As you can see above result, merged one has better utilization (overhead > > > ratio, 5th column) and uses less memory (mem_used_total, 3rd column). > > > > > > Changes from v1: > > > - More commit description about what to do in this patch. > > > - Remove nr_obj in size_class, because it isn't need after initialization. > > > - Rename __size_class to size_class, size_class to merged_size_class. > > > - Add code comment for merged_size_class of struct zs_pool. > > > - Add code comment how merging works in zs_create_pool(). > > > > > > Changes from v2: > > > - Add more commit description (Dan) > > > - dynamically allocate size_class structure (Dan) > > > - rename objs_per_zspage to get_maxobj_per_zspage (Minchan) > > > > > > Changes from v3: > > > - Add error handling logic in zs_create_pool (Dan) > > > > > > Signed-off-by: Joonsoo Kim > > > --- > > > mm/zsmalloc.c | 84 > > > +++-- > > > 1 file changed, 70 insertions(+), 14 deletions(-) > > > > > > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c > > > index c4a9157..11556ae 100644 > > > --- a/mm/zsmalloc.c > > > +++ b/mm/zsmalloc.c >
Re: [PATCH v4] zsmalloc: merge size_class to reduce fragmentation
On Tue, Sep 30, 2014 at 08:10:22AM +0900, Minchan Kim wrote:
> Hey Joonsoo,
>
> On Mon, Sep 29, 2014 at 04:45:27PM +0900, Joonsoo Kim wrote:
> > zsmalloc has many size_classes to reduce fragmentation and they are
> > in 16 bytes unit, for example, 16, 32, 48, etc., if PAGE_SIZE is 4096.
> > And, zsmalloc has constraint that each zspage has 4 pages at maximum.
> >
> > In this situation, we can see interesting aspect.
> > Let's think about size_class for 1488, 1472, ..., 1376.
> > To prevent external fragmentation, they uses 4 pages per zspage and
> > so all they can contain 11 objects at maximum.
> >
> > 16384 (4096 * 4) = 1488 * 11 + remains
> > 16384 (4096 * 4) = 1472 * 11 + remains
> > 16384 (4096 * 4) = ...
> > 16384 (4096 * 4) = 1376 * 11 + remains
> >
> > It means that they have same characteristics and classification between
> > them isn't needed. If we use one size_class for them, we can reduce
> > fragementation and save some memory since both the 1488 and 1472 sized
> > classes can only fit 11 objects into 4 pages, and an object that's
> > 1472 bytes can fit into an object that's 1488 bytes, merging these
> > classes to always use objects that are 1488 bytes will reduce the total
> > number of size classes. And reducing the total number of size classes
> > reduces overall fragmentation, because a wider range of compressed pages
> > can fit into a single size class, leaving less unused objects in each
> > size class.
> >
> > For this purpose, this patch implement size_class merging. If there is
> > size_class that have same pages_per_zspage and same number of objects
> > per zspage with previous size_class, we don't create new size_class.
> > Instead, we use previous, same characteristic size_class. With this way,
> > above example sizes (1488, 1472, ..., 1376) use just one size_class
> > so we can get much more memory utilization.
> >
> > Below is result of my simple test.
> >
> > TEST ENV: EXT4 on zram, mount with discard option
> > WORKLOAD: untar kernel source code, remove directory in descending order
> > in size. (drivers arch fs sound include net Documentation firmware
> > kernel tools)
> >
> > Each line represents orig_data_size, compr_data_size, mem_used_total,
> > fragmentation overhead (mem_used - compr_data_size) and overhead ratio
> > (overhead to compr_data_size), respectively, after untar and remove
> > operation is executed.
> >
> > * untar-nomerge.out
> >
> > orig_size compr_size used_size overhead overhead_ratio
> > 525.88MB 199.16MB 210.23MB 11.08MB 5.56%
> > 288.32MB 97.43MB 105.63MB 8.20MB 8.41%
> > 177.32MB 61.12MB 69.40MB 8.28MB 13.55%
> > 146.47MB 47.32MB 56.10MB 8.78MB 18.55%
> > 124.16MB 38.85MB 48.41MB 9.55MB 24.58%
> > 103.93MB 31.68MB 40.93MB 9.25MB 29.21%
> > 84.34MB 22.86MB 32.72MB 9.86MB 43.13%
> > 66.87MB 14.83MB 23.83MB 9.00MB 60.70%
> > 60.67MB 11.11MB 18.60MB 7.49MB 67.48%
> > 55.86MB 8.83MB 16.61MB 7.77MB 88.03%
> > 53.32MB 8.01MB 15.32MB 7.31MB 91.24%
> >
> > * untar-merge.out
> >
> > orig_size compr_size used_size overhead overhead_ratio
> > 526.23MB 199.18MB 209.81MB 10.64MB 5.34%
> > 288.68MB 97.45MB 104.08MB 6.63MB 6.80%
> > 177.68MB 61.14MB 66.93MB 5.79MB 9.47%
> > 146.83MB 47.34MB 52.79MB 5.45MB 11.51%
> > 124.52MB 38.87MB 44.30MB 5.43MB 13.96%
> > 104.29MB 31.70MB 36.83MB 5.13MB 16.19%
> > 84.70MB 22.88MB 27.92MB 5.04MB 22.04%
> > 67.11MB 14.83MB 19.26MB 4.43MB 29.86%
> > 60.82MB 11.10MB 14.90MB 3.79MB 34.17%
> > 55.90MB 8.82MB 12.61MB 3.79MB 42.97%
> > 53.32MB 8.01MB 11.73MB 3.73MB 46.53%
> >
> > As you can see above result, merged one has better utilization (overhead
> > ratio, 5th column) and uses less memory (mem_used_total, 3rd column).
> >
> > Changes from v1:
> > - More commit description about what to do in this patch.
> > - Remove nr_obj in size_class, because it isn't need after initialization.
> > - Rename __size_class to size_class, size_class to merged_size_class.
> > - Add code comment for merged_size_class of struct zs_pool.
> > - Add code comment how merging works in zs_create_pool().
> >
> > Changes from v2:
> > - Add more commit description (Dan)
> > - dynamically allocate size_class structure (Dan)
> > - rename objs_per_zspage to get_maxobj_per_zspage (Minchan)
> >
> > Changes from v3:
> > - Add error handling logic in zs_create_pool (Dan)
> >
> > Signed-off-by: Joonsoo Kim
> > ---
> > mm/zsmalloc.c | 84
> > +++--
> > 1 file changed, 70 insertions(+), 14 deletions(-)
> >
> > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> > index c4a9157..11556ae 100644
> > --- a/mm/zsmalloc.c
> > +++ b/mm/zsmalloc.c
> > @@ -187,6 +187,7 @@ enum fullness_group {
> > static const int fullness_threshold_frac = 4;
> >
> > struct size_class {
> > + int ref;
>
> Couldn't we remove the ref from size_class by making zs_destroy_pool
> aware of merged size class like zs_create_pool?
>
Re: [PATCH v2] vfs: Don't exchange "short" filenames unconditionally.
On Wed, Oct 01, 2014 at 01:16:15AM +0100, Al Viro wrote: > On Mon, Sep 29, 2014 at 11:42:18AM -0700, Paul E. McKenney wrote: > > > Assuming that incrementing the external name's reference count is > > atomic_add_unless, I could believe this part. Or if you have some > > locking that makes it impossible to increment the reference count > > in any case where there is any risk that it might be decremented > > to zero, I guess. > > > > Which might well be the pair of write_seqcount_begin() calls in __d_move(), > > now that I look more carefully. So if the name has to be in use somewhere > > before it can be copied, then a copy can only be created if there is at > > least one copy that is not currently being removed? If so, OK. > > Huh? copy_name() does copy a _reference_, not the name itself. All the > copying involved is source->d_name.name = target->d_name.name. And those > are simply unsigned char *. > > write_seqcount_begin() is irrelevant here. Look: all callers of > __d_move(x, y) are holding references both to x and y. Contributing to > the refcount of dentries themselves, that is, not the names. > > That gives exclusion between __d_move() and free_dentry() - the latter cannot > be called until dentry refcount reaches zero. RCU is completely irrelevant > here. In fact, no call chain leads to __d_move() under rcu_read_lock(). > You must hold the target dentry hard, or it could simply be freed right > under you. > > And __d_move() is taking ->d_lock on all dentries involved (in > addition to rename_lock serializing it system-wide). > > What could possibly lead to refcount zero being observed on target of > __d_move()? The history of any dentry is this: > * it is created by __d_alloc(). Nobody can see it until __d_alloc() > returns. Dentry refcount (not to be confused with refcount of external > name) is 1. > * it passes through some (usually - zero) __d_move() calls. > Some - as the first argument, some - as the second one. All those > calls are serialized by global seqlock - callers must hold rename_lock. > And all of them are done by somebody who is holding a counting reference > to dentries in question. > * counting references to dentry might be taken and dropped; > eventually refcount reaches zero (under ->d_lock) and no further > counting references can be taken after that. See __dentry_kill() - the > first thing it does is poisoning the refcount, so that any future > attempt to increment it would fail. __dentry_kill() (still under ->d_lock > of dentry, ->d_lock of its parent and ->i_lock of its inode) removes > dentry from the tree, from hash and from the alias list of inode; > Then it drops the locks. At that point the only search structure dentry > might be found in is shrink list; if it's not on such list, free_dentry() > is called immediately, otherwise it's marked so that the code processing > the shrink list in question would, as soon as it gets to that sucker, > remove it from the shrink list and call the same free_dentry(). And that's > the only thing done to such dentry by somebody finding it via a shrink list. > * once free_dentry() has been reached, dentry can can be only seen > by RCU lookups, and after the grace period ends it gets physically freed. > > free_dentry() isn't allowed to overlap __d_move(); to have that happen is > a serious dentry refcounting bug. No __d_move() is allowed _after_ > free_dentry() has been entered, either. Again, it would take a refcounting > bug for dentries to have that happen - basically, double dput() somewhere. > If that happens, all bets are off, of course - if dentry gets unexpectedly > freed under somebody who has grabbed a reference to it and has not dropped > it yet, we are fucked. > > Nothing outside of __d_move() is allowed to change ->d_name.name. > RCU-critical > code is allowed to fetch and dereference it, and such code relies upon > a) freeing of name seen by somebody who'd done rcu_read_lock() being > delayed until after the matching rcu_read_unlock() > b) store of terminating NUL done by __d_alloc() (and never overwritten > afterwards) being seen by RCU-critical code that has found the pointer to > that name in dentry->d_name.name > > All other code accessing ->d_name.name is required to hold one of the locks > that are held by __d_move() and its callers. Grabbing any of those leads > to smp_mb() on alpha, which serves as data dependency barrier there, so > we don't need explicit barrier there as we do in RCU-critical places - > guarding > NUL will be seen. Please accept my apologies for the noise! Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 net-next 01/10] r8169:change uppercase numbertolowercase nubmer
I will do that next time. Thanks. -Original Message- From: David Miller [mailto:da...@davemloft.net] Sent: Thursday, October 02, 2014 3:35 AM To: Hau Cc: net...@vger.kernel.org; nic_swsd; linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 net-next 01/10] r8169:change uppercase number tolowercase nubmer From: Chun-Hao Lin Date: Wed, 1 Oct 2014 23:17:12 +0800 > Signed-off-by: Chun-Hao Lin Series applied, and I fixed the typo in the Subject line here. But you _(REALLY)_ need to provide a [PATCH net-next 00/xx] posting at the beginning of the patch series which gives an overview of what the patch series does at a high level, and why. This also allows me to have a sensible post to reply to when I just need to say what I've done with the entire series rather than providing comments on a specific patch. Thanks. --Please consider the environment before printing this e-mail. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [mm/slab] BUG: unable to handle kernel paging request at 00010023
On Tue, Sep 30, 2014 at 03:56:24PM +0800, Fengguang Wu wrote: > Hi Joonsoo, > > 0day kernel testing robot got the below dmesg and the first bad commit is > > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > > commit 36fbfebe776eb5871d61e7a755c9feb1c96cc4aa > Author: Joonsoo Kim > AuthorDate: Tue Sep 23 11:52:35 2014 +1000 > Commit: Stephen Rothwell > CommitDate: Tue Sep 23 11:52:35 2014 +1000 > > mm/slab: support slab merge > > Slab merge is good feature to reduce fragmentation. If new creating slab > have similar size and property with exsitent slab, this feature reuse it > rather than creating new one. As a result, objects are packed into fewer > slabs so that fragmentation is reduced. > > Below is result of my testing. > > * After boot, sleep 20; cat /proc/meminfo | grep Slab > > > Slab: 25136 kB > > > Slab: 24364 kB > > We can save 3% memory used by slab. > > For supporting this feature in SLAB, we need to implement SLAB specific > kmem_cache_flag() and __kmem_cache_alias(), because SLUB implements some > SLUB specific processing related to debug flag and object size change on > these functions. > > Signed-off-by: Joonsoo Kim > Cc: Christoph Lameter > Cc: Pekka Enberg > Cc: David Rientjes > Signed-off-by: Andrew Morton > > +--+++---+ > | | 8c087489b8 | 36fbfebe77 | > next-20140923 | > +--+++---+ > | boot_successes | 60 | 0 | 1 >| > | boot_failures| 0 | 20 | > 314 | > | BUG:unable_to_handle_kernel | 0 | 20 | > 312 | > | Oops | 0 | 20 | > 312 | > | EIP_is_at_kernfs_link_sibling| 0 | 4 | 14 >| > | Kernel_panic-not_syncing:Fatal_exception | 0 | 20 | > 312 | > | backtrace:acpi_bus_scan | 0 | 4 | 14 >| > | backtrace:acpi_scan_init | 0 | 20 | 45 >| > | backtrace:acpi_init | 0 | 20 | 45 >| > | backtrace:kernel_init_freeable | 0 | 20 | > 312 | > | EIP_is_at_kernfs_add_one | 0 | 16 | > 298 | > | backtrace:kobject_add_internal | 0 | 16 | 31 >| > | backtrace:kobject_init_and_add | 0 | 16 | 31 >| > | backtrace:acpi_scan_add_handler_with_hotplug | 0 | 16 | 31 >| > | backtrace:acpi_pci_root_init | 0 | 16 | 31 >| > | backtrace:tty_register_driver| 0 | 0 | > 106 | > | backtrace:pty_init | 0 | 0 | > 106 | > | backtrace:acpi_bus_register_driver | 0 | 0 | 1 >| > | backtrace:acpi_button_driver_init| 0 | 0 | 1 >| > | BUG:kernel_boot_crashed | 0 | 0 | 1 >| > | BUG:kernel_test_crashed | 0 | 0 | 1 >| > | backtrace:subsys_system_register | 0 | 0 | > 160 | > | backtrace:container_dev_init | 0 | 0 | > 160 | > | backtrace:driver_init| 0 | 0 | > 160 | > +--+++---+ > > [0.463788] ACPI: (supports S0 S5) > [0.464003] ACPI: Using IOAPIC for interrupt routing > [0.464738] PCI: Using host bridge windows from ACPI; if necessary, use > "pci=nocrs" and report a bug > [0.466034] BUG: unable to handle kernel paging request at 00010023 > [0.466989] IP: [] kernfs_add_one+0x89/0x130 > [0.467812] *pdpt = *pde = f000ff53f000ff53 > [0.468000] Oops: 0002 [#1] SMP > [0.468000] Modules linked in: > [0.468000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted > 3.17.0-rc6-00089-g36fbfeb #1 > [0.468000] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 > [0.468000] task: d303ec90 ti: d304 task.ti: d304 > [0.468000] EIP: 0060:[] EFLAGS: 00010286 CPU: 0 > [0.468000] EIP is at kernfs_add_one+0x89/0x130 > [0.468000] EAX: 542572cb EBX: 00010003 ECX: 0008 EDX: 2c8de598 > [0.468000] ESI:
Re: [REGRESSION] [FIXED] [PATCH 1/3] mm/slab: use percpu allocator for cpu cache
On Mon, Sep 29, 2014 at 10:03:15AM -0700, Jeremiah Mahler wrote:
> Joonsoo,
>
> On Mon, Sep 29, 2014 at 04:44:18PM +0900, Joonsoo Kim wrote:
> > On Sat, Sep 27, 2014 at 11:24:49PM -0700, Jeremiah Mahler wrote:
> > > On Thu, Aug 21, 2014 at 05:11:13PM +0900, Joonsoo Kim wrote:
> > > > Because of chicken and egg problem, initializaion of SLAB is really
> > > > complicated. We need to allocate cpu cache through SLAB to make
> > > > the kmem_cache works, but, before initialization of kmem_cache,
> > > > allocation through SLAB is impossible.
> > > >
> > > > On the other hand, SLUB does initialization with more simple way. It
> > > > uses percpu allocator to allocate cpu cache so there is no chicken and
> > > > egg problem.
> > > >
> > > > So, this patch try to use percpu allocator in SLAB. This simplify
> > > > initialization step in SLAB so that we could maintain SLAB code more
> > > > easily.
> > > >
> > > > From my testing, there is no performance difference.
> > > >
> > > > Signed-off-by: Joonsoo Kim
> > >
> > > I just encountered a problem on a Lenovo Carbon X1 where it will
> > > suspend but won't resume. A bisect indicated that this patch
> > > is causing the problem.
> > >
> > > 997888488ef92da365b870247de773255227ce1f
> > >
> > > I imagine the patch author, Joonsoo Kim, might have a better idea
> > > why this is happening than I do. But if I can provide any information
> > > or run any tests that might be of help just let me know.
> >
> > Hello,
> >
> > Yeah, there is a bug. Below will fix your issue.
> > Could you test it and report the result?
> >
> > Thanks for reporting it.
> >
> > ->8---
> > From e03ed6cc554e038b86d7b3a72b89d94e9ea808ba Mon Sep 17 00:00:00 2001
> > From: Joonsoo Kim
> > Date: Mon, 29 Sep 2014 16:30:43 +0900
> > Subject: [PATCH] mm/slab: fix cpu on/off handling
> >
> > When cpu off, we flush all cpu cached objects to it's own slab.
> > free_block() is used for this purpose and it's role is just to flush
> > objects from array_cache to proper slab. It doesn't adjust array_cache's
> > internal fields so we should manually reset them to proper value.
> > Without this fix, we maintain free objects duplicately, one is in
> > cpu cache, and, the other one is in the slab. So system would be broken.
> >
> > Reported-by: Jeremiah Mahler
> > Signed-off-by: Joonsoo Kim
> > ---
> > mm/slab.c |4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/mm/slab.c b/mm/slab.c
> > index 1162f0e..ce289b4 100644
> > --- a/mm/slab.c
> > +++ b/mm/slab.c
> > @@ -1102,8 +1102,10 @@ static void cpuup_canceled(long cpu)
> >
> > /* cpu is dead; no one can alloc from it. */
> > nc = per_cpu_ptr(cachep->cpu_cache, cpu);
> > - if (nc)
> > + if (nc) {
> > free_block(cachep, nc->entry, nc->avail, node, );
> > + nc->avail = 0;
> > + }
> >
> > if (!cpumask_empty(mask)) {
> > spin_unlock_irq(>list_lock);
> > --
> > 1.7.9.5
> >
>
> That fixed the problem. Thanks!
>
> Tested-by: Jeremiah Mahler
Good!
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] dmaengine: qcom_bam_dma: Generalize BAM register offset calculations
On Wed, Oct 01, 2014 at 01:52:31PM +0530, Pramod Gurav wrote: > Andy, > With your change "dmaengine: qcom_bam_dma: Add v1.3.0 driver support" > and enabling qcom_bam_dma driver i was seeing some crashes in the kernel > on IFC6410. But after reverting you change and applying these changes > from Vinod I see IFC6410 booting fine. We're dropping my changes in favor of these. So please do revert my change and pull in this. -- sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 06/17] powerpc/powernv: Split out set MSI IRQ chip code
On Thu, 2014-10-02 at 11:57 +1000, Michael Ellerman wrote:
> On Tue, 2014-30-09 at 10:34:55 UTC, Michael Neuling wrote:
> > From: Ian Munsie
> >
> > Some of the MSI IRQ code in pnv_pci_ioda_msi_setup() is generically useful
> > so
> > split it out.
> >
> > This will be used by some of the cxl PCIe code later.
> >
> > diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
> > b/arch/powerpc/platforms/powernv/pci-ioda.c
> > index df241b1..329164f 100644
> > --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> > +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> > @@ -1306,14 +1306,36 @@ static void pnv_ioda2_msi_eoi(struct irq_data *d)
> > icp_native_eoi(d);
> > }
> >
> > +
> > +static void set_msi_irq_chip(struct pnv_phb *phb, unsigned int virq)
> > +{
> > + struct irq_data *idata;
> > + struct irq_chip *ichip;
> > +
> > + if (phb->type != PNV_PHB_IODA2)
> > + return;
> > +
> > + /*
> > +* Change the IRQ chip for the MSI interrupts on PHB3.
> > +* The corresponding IRQ chip should be populated for
> > +* the first time.
>
> Seeing as you're moving this comment can you clarify the wording.
Ok.
Mikey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Fixed all coding style issues for drivers/staging/media/lirc/
On Thu, Oct 2, 2014 at 12:40 AM, Amber Thrall
wrote:
> Fixed various coding style issues, including strings over 80 characters long
> and many
> deprecated printk's have been replaced with proper methods.
>
> Signed-off-by: Amber Thrall
> ---
> drivers/staging/media/lirc/lirc_bt829.c | 2 +-
> drivers/staging/media/lirc/lirc_imon.c | 4 +-
> drivers/staging/media/lirc/lirc_sasem.c | 6 +--
> drivers/staging/media/lirc/lirc_serial.c | 29 ++
> drivers/staging/media/lirc/lirc_sir.c| 3 +-
> drivers/staging/media/lirc/lirc_zilog.c | 69
> +++-
> 6 files changed, 52 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/staging/media/lirc/lirc_bt829.c
> b/drivers/staging/media/lirc/lirc_bt829.c
> index 4c806ba..c70ca68 100644
> --- a/drivers/staging/media/lirc/lirc_bt829.c
> +++ b/drivers/staging/media/lirc/lirc_bt829.c
> @@ -59,7 +59,7 @@ static bool debug;
> #define dprintk(fmt, args...) \
> do { \
> if (debug) \
> - printk(KERN_DEBUG DRIVER_NAME ": "fmt, ## args); \
> + dev_dbg(DRIVER_NAME, ": "fmt, ##args); \
> } while (0)
>
> static int atir_minor;
> diff --git a/drivers/staging/media/lirc/lirc_imon.c
> b/drivers/staging/media/lirc/lirc_imon.c
> index 7aca44f..bce0408 100644
> --- a/drivers/staging/media/lirc/lirc_imon.c
> +++ b/drivers/staging/media/lirc/lirc_imon.c
> @@ -623,8 +623,8 @@ static void imon_incoming_packet(struct imon_context
> *context,
> if (debug) {
> dev_info(dev, "raw packet: ");
> for (i = 0; i < len; ++i)
> - printk("%02x ", buf[i]);
> - printk("\n");
> + dev_info(dev, "%02x ", buf[i]);
> + dev_info(dev, "\n");
Did you mean pr_cont() for both of these? Otherwise each one will get
a level + device info prefix.
> }
>
> /*
> diff --git a/drivers/staging/media/lirc/lirc_sasem.c
> b/drivers/staging/media/lirc/lirc_sasem.c
> index c20ef56..e88e246 100644
> --- a/drivers/staging/media/lirc/lirc_sasem.c
> +++ b/drivers/staging/media/lirc/lirc_sasem.c
> @@ -583,10 +583,10 @@ static void incoming_packet(struct sasem_context
> *context,
> }
>
> if (debug) {
> - printk(KERN_INFO "Incoming data: ");
> + pr_info("Incoming data: ");
> for (i = 0; i < 8; ++i)
> - printk(KERN_CONT "%02x ", buf[i]);
> - printk(KERN_CONT "\n");
> + pr_cont("%02x", buf[i]);
> + pr_cont("\n");
> }
>
> /*
> diff --git a/drivers/staging/media/lirc/lirc_serial.c
> b/drivers/staging/media/lirc/lirc_serial.c
> index 181b92b..b07671b 100644
> --- a/drivers/staging/media/lirc/lirc_serial.c
> +++ b/drivers/staging/media/lirc/lirc_serial.c
> @@ -116,8 +116,7 @@ static bool txsense;/* 0 = active high, 1 =
> active low */
> #define dprintk(fmt, args...) \
> do {\
> if (debug) \
> - printk(KERN_DEBUG LIRC_DRIVER_NAME ": " \
> - fmt, ## args); \
> + dev_dbg(LIRC_DRIVER_NAME, ": "fmt, ##args); \
This wants a device node, not a driver name string. There's a reason
there was no , in the old macro...
> } while (0)
>
> /* forward declarations */
> @@ -356,9 +355,8 @@ static int init_timing_params(unsigned int new_duty_cycle,
> /* Derive pulse and space from the period */
> pulse_width = period * duty_cycle / 100;
> space_width = period - pulse_width;
> - dprintk("in init_timing_params, freq=%d, duty_cycle=%d, "
> - "clk/jiffy=%ld, pulse=%ld, space=%ld, "
> - "conv_us_to_clocks=%ld\n",
> + dprintk("in init_timing_params, freq=%d, duty_cycle=%d, clk/jiffy=%ld,
> + pulse=%ld, space=%ld, conv_us_to_clocks=%ld\n",
> freq, duty_cycle, __this_cpu_read(cpu_info.loops_per_jiffy),
> pulse_width, space_width, conv_us_to_clocks);
> return 0;
> @@ -1075,7 +1073,7 @@ static int __init lirc_serial_init(void)
>
> result = platform_driver_register(_serial_driver);
> if (result) {
> - printk("lirc register returned %d\n", result);
> + dprintk("lirc register returned %d\n", result);
> goto exit_buffer_free;
> }
>
> @@ -1166,22 +1164,20 @@ module_init(lirc_serial_init_module);
> module_exit(lirc_serial_exit_module);
>
> MODULE_DESCRIPTION("Infra-red receiver driver for serial ports.");
> -MODULE_AUTHOR("Ralph Metzler, Trent Piepho, Ben Pfaff, "
> -
[PATCH] [TRIVIAL] mod_devicetable.h: grammar fix in comment
Signed-off-by: Michael Opdenacker
---
include/linux/mod_devicetable.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 44eeef0da186..745def862580 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -69,7 +69,7 @@ struct ieee1394_device_id {
* @bDeviceClass: Class of device; numbers are assigned
* by the USB forum. Products may choose to implement classes,
* or be vendor-specific. Device classes specify behavior of all
- * the interfaces on a devices.
+ * the interfaces on a device.
* @bDeviceSubClass: Subclass of device; associated with bDeviceClass.
* @bDeviceProtocol: Protocol of device; associated with bDeviceClass.
* @bInterfaceClass: Class of interface; numbers are assigned
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the crypto tree with the pci tree
Hi Herbert,
Today's linux-next merge of the crypto tree got a conflict in
arch/arm64/boot/dts/apm-storm.dtsi between commit 84ac1f2ca41f ("arm64:
dts: Add APM X-Gene PCIe device tree nodes") from the pci tree and
commit ab81873974af ("arm64: dts: add random number generator dts node
to APM X-Gene platform") from the crypto tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm64/boot/dts/apm-storm.dtsi
index 403197a0e621,f391972ad135..
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@@ -270,170 -270,18 +270,183 @@@
clock-output-names = "rtcclk";
};
+ rngpkaclk: rngpkaclk@1700 {
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = < 0>;
+ reg = <0x0 0x1700 0x0 0x2000>;
+ reg-names = "csr-reg";
+ csr-offset = <0xc>;
+ csr-mask = <0x10>;
+ enable-offset = <0x10>;
+ enable-mask = <0x10>;
+ clock-output-names = "rngpkaclk";
+ };
++
+ pcie0clk: pcie0clk@1f2bc000 {
+ status = "disabled";
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = < 0>;
+ reg = <0x0 0x1f2bc000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "pcie0clk";
+ };
+
+ pcie1clk: pcie1clk@1f2cc000 {
+ status = "disabled";
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = < 0>;
+ reg = <0x0 0x1f2cc000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "pcie1clk";
+ };
+
+ pcie2clk: pcie2clk@1f2dc000 {
+ status = "disabled";
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = < 0>;
+ reg = <0x0 0x1f2dc000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "pcie2clk";
+ };
+
+ pcie3clk: pcie3clk@1f50c000 {
+ status = "disabled";
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = < 0>;
+ reg = <0x0 0x1f50c000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "pcie3clk";
+ };
+
+ pcie4clk: pcie4clk@1f51c000 {
+ status = "disabled";
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = < 0>;
+ reg = <0x0 0x1f51c000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "pcie4clk";
+ };
+ };
+
+ pcie0: pcie@1f2b {
+ status = "disabled";
+ device_type = "pci";
+ compatible = "apm,xgene-storm-pcie", "apm,xgene-pcie";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = < 0x00 0x1f2b 0x0 0x0001 /* Controller
registers */
+ 0xe0 0xd000 0x0 0x0004>; /* PCI config
space */
+ reg-names = "csr", "cfg";
+ ranges = <0x0100 0x00 0x 0xe0 0x1000
0x00 0x0001 /* io */
+0x0200 0x00 0x8000 0xe1 0x8000
0x00 0x8000>; /* mem */
+ dma-ranges = <0x4200 0x80 0x 0x80
0x 0x00 0x8000
+0x4200 0x00 0x 0x00
0x 0x80 0x>;
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+
[PATCH] Fixed all coding style issues for drivers/staging/media/lirc/
Fixed various coding style issues, including strings over 80 characters long
and many
deprecated printk's have been replaced with proper methods.
Signed-off-by: Amber Thrall
---
drivers/staging/media/lirc/lirc_bt829.c | 2 +-
drivers/staging/media/lirc/lirc_imon.c | 4 +-
drivers/staging/media/lirc/lirc_sasem.c | 6 +--
drivers/staging/media/lirc/lirc_serial.c | 29 ++
drivers/staging/media/lirc/lirc_sir.c| 3 +-
drivers/staging/media/lirc/lirc_zilog.c | 69 +++-
6 files changed, 52 insertions(+), 61 deletions(-)
diff --git a/drivers/staging/media/lirc/lirc_bt829.c
b/drivers/staging/media/lirc/lirc_bt829.c
index 4c806ba..c70ca68 100644
--- a/drivers/staging/media/lirc/lirc_bt829.c
+++ b/drivers/staging/media/lirc/lirc_bt829.c
@@ -59,7 +59,7 @@ static bool debug;
#define dprintk(fmt, args...) \
do { \
if (debug) \
- printk(KERN_DEBUG DRIVER_NAME ": "fmt, ## args); \
+ dev_dbg(DRIVER_NAME, ": "fmt, ##args); \
} while (0)
static int atir_minor;
diff --git a/drivers/staging/media/lirc/lirc_imon.c
b/drivers/staging/media/lirc/lirc_imon.c
index 7aca44f..bce0408 100644
--- a/drivers/staging/media/lirc/lirc_imon.c
+++ b/drivers/staging/media/lirc/lirc_imon.c
@@ -623,8 +623,8 @@ static void imon_incoming_packet(struct imon_context
*context,
if (debug) {
dev_info(dev, "raw packet: ");
for (i = 0; i < len; ++i)
- printk("%02x ", buf[i]);
- printk("\n");
+ dev_info(dev, "%02x ", buf[i]);
+ dev_info(dev, "\n");
}
/*
diff --git a/drivers/staging/media/lirc/lirc_sasem.c
b/drivers/staging/media/lirc/lirc_sasem.c
index c20ef56..e88e246 100644
--- a/drivers/staging/media/lirc/lirc_sasem.c
+++ b/drivers/staging/media/lirc/lirc_sasem.c
@@ -583,10 +583,10 @@ static void incoming_packet(struct sasem_context *context,
}
if (debug) {
- printk(KERN_INFO "Incoming data: ");
+ pr_info("Incoming data: ");
for (i = 0; i < 8; ++i)
- printk(KERN_CONT "%02x ", buf[i]);
- printk(KERN_CONT "\n");
+ pr_cont("%02x", buf[i]);
+ pr_cont("\n");
}
/*
diff --git a/drivers/staging/media/lirc/lirc_serial.c
b/drivers/staging/media/lirc/lirc_serial.c
index 181b92b..b07671b 100644
--- a/drivers/staging/media/lirc/lirc_serial.c
+++ b/drivers/staging/media/lirc/lirc_serial.c
@@ -116,8 +116,7 @@ static bool txsense;/* 0 = active high, 1 = active
low */
#define dprintk(fmt, args...) \
do {\
if (debug) \
- printk(KERN_DEBUG LIRC_DRIVER_NAME ": " \
- fmt, ## args); \
+ dev_dbg(LIRC_DRIVER_NAME, ": "fmt, ##args); \
} while (0)
/* forward declarations */
@@ -356,9 +355,8 @@ static int init_timing_params(unsigned int new_duty_cycle,
/* Derive pulse and space from the period */
pulse_width = period * duty_cycle / 100;
space_width = period - pulse_width;
- dprintk("in init_timing_params, freq=%d, duty_cycle=%d, "
- "clk/jiffy=%ld, pulse=%ld, space=%ld, "
- "conv_us_to_clocks=%ld\n",
+ dprintk("in init_timing_params, freq=%d, duty_cycle=%d, clk/jiffy=%ld,
+ pulse=%ld, space=%ld, conv_us_to_clocks=%ld\n",
freq, duty_cycle, __this_cpu_read(cpu_info.loops_per_jiffy),
pulse_width, space_width, conv_us_to_clocks);
return 0;
@@ -1075,7 +1073,7 @@ static int __init lirc_serial_init(void)
result = platform_driver_register(_serial_driver);
if (result) {
- printk("lirc register returned %d\n", result);
+ dprintk("lirc register returned %d\n", result);
goto exit_buffer_free;
}
@@ -1166,22 +1164,20 @@ module_init(lirc_serial_init_module);
module_exit(lirc_serial_exit_module);
MODULE_DESCRIPTION("Infra-red receiver driver for serial ports.");
-MODULE_AUTHOR("Ralph Metzler, Trent Piepho, Ben Pfaff, "
- "Christoph Bartelmus, Andrei Tanas");
+MODULE_AUTHOR("Ralph Metzler, Trent Piepho, Ben Pfaff, Christoph Bartelmus,
Andrei Tanas");
MODULE_LICENSE("GPL");
module_param(type, int, S_IRUGO);
-MODULE_PARM_DESC(type, "Hardware type (0 = home-brew, 1 = IRdeo,"
-" 2 = IRdeo Remote, 3 = AnimaX, 4 = IgorPlug,"
-" 5 = NSLU2 RX:CTS2/TX:GreenLED)");
+MODULE_PARM_DESC(type, "Hardware type (0 = home-brew, 1 = IRdeo,
+ 2 =
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/usb/r8152.c between commit 204c87041289 ("r8152: remove
clearing bp") from the net tree and commit 8ddfa07778af ("r8152: use
usleep_range") from the net-next tree.
I fixed it up (the former removed some of the code updated by the
latter) and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
[PATCH] checkpatch: Warn on logging functions with KERN_
Warn on probable misuses of logging functions with KERN_
like pr_err(KERN_ERR "foo\n");
Suggested-by: Andrew Morton
Signed-off-by: Joe Perches
---
> > - printk(KERN_ERR "ksm: register sysfs failed\n");
> > + pr_err(KERN_ERR "ksm: register sysfs failed\n");
> A quick grep indicates that we have the same mistake in tens of places.
> checkpatch rule, please?
scripts/checkpatch.pl | 11 +++
1 file changed, 11 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 52a223e..374abf4 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4447,6 +4447,17 @@ sub process {
}
}
+# check for logging functions with KERN_
+ if ($line !~ /printk\s*\(/ &&
+ $line =~ /\b$logFunctions\s*\(.*\b(KERN_[A-Z]+)\b/) {
+ my $level = $1;
+ if (WARN("UNNECESSARY_KERN_LEVEL",
+"Possible unnecessary $level\n" . $herecurr) &&
+ $fix) {
+ $fixed[$fixlinenr] =~ s/\s*$level\s*//;
+ }
+ }
+
# check for bad placement of section $InitAttribute (e.g.: __initdata)
if ($line =~ /(\b$InitAttribute\b)/) {
my $attr = $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: [PATCH v4 2/4] pmbus: core: add helpers for byte write and read modify write
On 10/01/2014 12:05 PM, at...@opensource.altera.com wrote:
From: Alan Tull
Add two helper functions:
* pmbus_write_byte_data = paged byte write
* pmbus_update_byte_data = paged byte read/modify/write
Signed-off-by: Alan Tull
---
drivers/hwmon/pmbus/pmbus_core.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/hwmon/pmbus/pmbus_core.c b/drivers/hwmon/pmbus/pmbus_core.c
index 291d11f..d6c3701 100644
--- a/drivers/hwmon/pmbus/pmbus_core.c
+++ b/drivers/hwmon/pmbus/pmbus_core.c
@@ -253,6 +253,37 @@ int pmbus_read_byte_data(struct i2c_client *client, int
page, u8 reg)
}
EXPORT_SYMBOL_GPL(pmbus_read_byte_data);
+int pmbus_write_byte_data(struct i2c_client *client, int page, u8 reg, u8
value)
+{
+ int rv;
+
+ rv = pmbus_set_page(client, page);
+ if (rv < 0)
+ return rv;
+
+ return i2c_smbus_write_byte_data(client, reg, value);
+}
+EXPORT_SYMBOL_GPL(pmbus_write_byte_data);
+
+int pmbus_update_byte_data(struct i2c_client *client, int page, u8 reg,
+ u8 mask, u8 value)
+{
+ unsigned int tmp;
+ int rv;
+
+ rv = pmbus_read_byte_data(client, page, reg);
+ if (rv < 0)
+ return rv;
+
+ tmp = (rv & ~mask) | (value & mask);
+
+ if (tmp != rv)
+ rv = pmbus_write_byte_data(client, page, reg, tmp);
+
+ return rv;
+}
+EXPORT_SYMBOL_GPL(pmbus_update_byte_data);
+
/*
* _pmbus_read_byte_data() is similar to pmbus_read_byte_data(), but checks if
* a device specific mapping function exists and calls it if necessary.
Results in:
drivers/hwmon/pmbus/pmbus_core.c:259:5: warning: symbol 'pmbus_write_byte_data'
was not declared. Should it be static?
drivers/hwmon/pmbus/pmbus_core.c:271:5: warning: symbol
'pmbus_update_byte_data' was not declared. Should it be static?
drivers/hwmon/pmbus/pmbus_core.c:259:5: warning: no previous prototype for
'pmbus_write_byte_data' [-Wmissing-prototypes]
drivers/hwmon/pmbus/pmbus_core.c:271:5: warning: no previous prototype for
'pmbus_update_byte_data' [-Wmissing-prototypes]
No need to resubmit. I added a patch to un-export the functions
and merged patch 2 and 3 together in order to avoid a warning
after patch 2. We can always export the new helper functions
later if needed.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [dm-devel] dm-raid: add RAID discard support
I plan to submit this to Linus tomorrow, hopefully for 3.7, unless there are
complaints. It is in my for-next branch now.
Thanks,
NeilBrown
From aec6f821ed92fac5ae4f1db50279a3999de5872a Mon Sep 17 00:00:00 2001
From: NeilBrown
Date: Thu, 2 Oct 2014 13:45:00 +1000
Subject: [PATCH] md/raid5: disable 'DISCARD' by default due to safety
concerns.
It has come to my attention (thanks Martin) that 'discard_zeroes_data'
is only a hint. Some devices in some cases don't do what it
says on the label.
The use of DISCARD in RAID5 depends on reads from discarded regions
being predictably zero. If a write to a previously discarded region
performs a read-modify-write cycle it assumes that the parity block
was consistent with the data blocks. If all were zero, this would
be the case. If some are and some aren't this would not be the case.
This could lead to data corruption after a device failure when
data needs to be reconstructed from the parity.
As we cannot trust 'discard_zeroes_data', ignore it by default
and so disallow DISCARD on all raid4/5/6 arrays.
As many devices are trustworthy, and as there are benefits to using
DISCARD, add a module parameter to over-ride this caution and cause
DISCARD to work if discard_zeroes_data is set.
If a site want to enable DISCARD on some arrays but not on others they
should select DISCARD support at the filesystem level, and set the
raid456 module parameter.
raid456.devices_handle_discard_safely=Y
As this is a data-safety issue, I believe this patch is suitable for
-stable.
DISCARD support for RAID456 was added in 3.7
Cc: Shaohua Li
Cc: "Martin K. Petersen"
Cc: Mike Snitzer
Cc: Heinz Mauelshagen
Cc: sta...@vger.kernel.org (3.7+)
Fixes: 620125f2bf8ff0c4969b79653b54d7bcc9d40637
Signed-off-by: NeilBrown
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 183588b11fc1..9f0fbecd1eb5 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -64,6 +64,10 @@
#define cpu_to_group(cpu) cpu_to_node(cpu)
#define ANY_GROUP NUMA_NO_NODE
+static bool devices_handle_discard_safely = false;
+module_param(devices_handle_discard_safely, bool, 0644);
+MODULE_PARM_DESC(devices_handle_discard_safely,
+"Set to Y if all devices in each array reliably return zeroes
on reads from discarded regions");
static struct workqueue_struct *raid5_wq;
/*
* Stripe cache
@@ -6208,7 +6212,7 @@ static int run(struct mddev *mddev)
mddev->queue->limits.discard_granularity = stripe;
/*
* unaligned part of discard request will be ignored, so can't
-* guarantee discard_zerors_data
+* guarantee discard_zeroes_data
*/
mddev->queue->limits.discard_zeroes_data = 0;
@@ -6233,6 +6237,18 @@ static int run(struct mddev *mddev)
!bdev_get_queue(rdev->bdev)->
limits.discard_zeroes_data)
discard_supported = false;
+ /* Unfortunately, discard_zeroes_data is not currently
+* a guarantee - just a hint. So we only allow DISCARD
+* if the sysadmin has confirmed that only safe devices
+* are in use by setting a module parameter.
+*/
+ if (!devices_handle_discard_safely) {
+ if (discard_supported) {
+ pr_info("md/raid456: discard support
disabled due to uncertainty.\n");
+ pr_info("Set
raid456.devices_handle_discard_safely=Y to override.\n");
+ }
+ discard_supported = false;
+ }
}
if (discard_supported &&
pgp1J3QNQBS03.pgp
Description: OpenPGP digital signature
Re: linux-next: Tree for Oct 1
On Wed, Oct 01, 2014 at 05:54:11PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20140930:
>
> The arm-soc tree still had its build failure for which I reverted
> 5 commits.
>
> The net-next tree gained a conflict against the berlin tree, lost
> its build failure but gained another for which I applied a patch.
>
> The vfio tree gained a conflict against the pci tree.
>
> The tty tree lost its build failure.
>
> The staging tree still had its build failure for which I reverted
> a commit.
>
> The gpio tree gained conflicts against Linus' tree and the pinctrl tree.
>
> The akpm tree lost a patch that turned up elsewhere.
>
> Non-merge commits (relative to Linus' tree): 8953
> 7726 files changed, 354879 insertions(+), 267353 deletions(-)
>
>
>
Building arm:cm_x2xx_defconfig ... failed
drivers/built-in.o: In function `clk_set_rate':
:(.text+0xdef44): multiple definition of `clk_set_rate'
arch/arm/mach-pxa/built-in.o::(.text+0xf78): first defined here
drivers/built-in.o:(___ksymtab_gpl+clk_disable+0x0): multiple definition of
`__ksymtab_clk_disable'
arch/arm/mach-pxa/built-in.o:(___ksymtab+clk_disable+0x0): first defined here
drivers/built-in.o: In function `clk_disable':
:(.text+0xddf30): multiple definition of `clk_disable'
arch/arm/mach-pxa/built-in.o::(.text+0xfbc): first defined here
[and more]
---
Building m68k:allmodconfig ... failed
drivers/media/rc/ir-hix5hd2.c: In function 'hix5hd2_ir_config':
drivers/media/rc/ir-hix5hd2.c:100:2: error: implicit declaration of function
'readl_relaxed'
---
Building mn10300:asb2303_defconfig ... failed
Building um:defconfig ... failed
In file included from drivers/base/platform.c:24:0:
include/linux/pm_domain.h:74:23: error: expected identifier or '(' before '&'
token
make[2]: *** [drivers/base/platform.o] Error 1
---
Building sparc64:allmodconfig ... failed
drivers/bcma/main.c: In function 'bcma_of_find_child_device':
drivers/bcma/main.c:150:3: error: implicit declaration of function
'of_translate_address'
---
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] mm: poison critical mm/ structs
On 10/01/2014 05:48 PM, Andrew Morton wrote: > On Wed, 01 Oct 2014 17:39:39 -0400 Sasha Levin wrote: > >>> It looks fairly cheap - I wonder if it should simply fall under >>> CONFIG_DEBUG_VM rather than the new CONFIG_DEBUG_VM_POISON. >> >> Config options are cheap as well :) > > Thing is, lots of people are enabling CONFIG_DEBUG_VM, but a smaller > number of people will enable CONFIG_DEBUG_VM_POISON. Less coverage. > > Defaulting to y if CONFIG_DEBUG_VM might help, but if people do `make > oldconfig' when CONFIG_DEBUG_VM=n, their CONFIG_DEBUG_VM_POISON will > get set to `n' and will remain that way when they set CONFIG_DEBUG_VM > again. In that case, what about: diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index db41b15..b2c7038 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -546,6 +546,7 @@ config DEBUG_VM_RB config DEBUG_VM_POISON bool "Poison VM structures" depends on DEBUG_VM + def_bool y help Add poison to the beggining and end of various VM structure to detect memory corruption in VM management code. We'll default to "Y" in 'make oldconfig' and it'll automatically be switched on when the user selects CONFIG_DEBUG_VM=y, but we still keep the advantages of having it in a different config option. Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 09/17] powerpc/mm: Add new hash_page_mm()
On Tue, 2014-30-09 at 10:34:58 UTC, Michael Neuling wrote:
> From: Ian Munsie
>
> This adds a new function hash_page_mm() based on the existing hash_page().
> This version allows any struct mm to be passed in, rather than assuming
> current. This is useful for servicing co-processor faults which are not in
> the
> context of the current running process.
I'm not a big fan. hash_page() is already a train wreck, and this doesn't make
it any better.
> diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
> index bbdb054..0a5c8c0 100644
> --- a/arch/powerpc/mm/hash_utils_64.c
> +++ b/arch/powerpc/mm/hash_utils_64.c
> @@ -904,7 +904,7 @@ void demote_segment_4k(struct mm_struct *mm, unsigned
> long addr)
> return;
> slice_set_range_psize(mm, addr, 1, MMU_PAGE_4K);
> copro_flush_all_slbs(mm);
> - if (get_paca_psize(addr) != MMU_PAGE_4K) {
> + if ((get_paca_psize(addr) != MMU_PAGE_4K) && (current->mm == mm)) {
> get_paca()->context = mm->context;
> slb_flush_and_rebolt();
This is a bit fishy.
If that mm is currently running on another cpu you just failed to update it's
paca. But I think the call to check_paca_psize() in hash_page() will save you
on that cpu.
In fact we might be able to remove that synchronisation from
demote_segment_4k() and always leave it up to check_paca_psize()?
> @@ -989,26 +989,24 @@ static void check_paca_psize(unsigned long ea, struct
> mm_struct *mm,
> * -1 - critical hash insertion error
> * -2 - access not permitted by subpage protection mechanism
> */
> -int hash_page(unsigned long ea, unsigned long access, unsigned long trap)
> +int hash_page_mm(struct mm_struct *mm, unsigned long ea, unsigned long
> access, unsigned long trap)
> {
> enum ctx_state prev_state = exception_enter();
> pgd_t *pgdir;
> unsigned long vsid;
> - struct mm_struct *mm;
> pte_t *ptep;
> unsigned hugeshift;
> const struct cpumask *tmp;
> int rc, user_region = 0, local = 0;
> int psize, ssize;
>
> - DBG_LOW("hash_page(ea=%016lx, access=%lx, trap=%lx\n",
> - ea, access, trap);
> + DBG_LOW("%s(ea=%016lx, access=%lx, trap=%lx\n",
> + __func__, ea, access, trap);
>
> /* Get region & vsid */
> switch (REGION_ID(ea)) {
> case USER_REGION_ID:
> user_region = 1;
> - mm = current->mm;
> if (! mm) {
> DBG_LOW(" user region with no mm !\n");
> rc = 1;
What about the VMALLOC case where we do:
mm = _mm;
Is that what you want? It seems odd that you pass an mm to the routine, but
then potentially it ends up using a different mm after all depending on the
address.
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 13/17] cxl: Add base builtin support
On Wed, 2014-10-01 at 22:00 +1000, Michael Ellerman wrote:
> On Tue, 2014-30-09 at 10:35:02 UTC, Michael Neuling wrote:
> > This also adds the cxl_ctx_in_use() function for use in the mm code to see
> > if
> > any cxl contexts are currently in use. This is used by the tlbie() to
> > determine if it can do local TLB invalidations or not. This also adds
> > get/put
> > calls for the cxl driver module to refcount the active cxl contexts.
>
> > diff --git a/drivers/misc/cxl/base.c b/drivers/misc/cxl/base.c
> > new file mode 100644
> > index 000..f4cbcfb
> > --- /dev/null
> > +++ b/drivers/misc/cxl/base.c
> > @@ -0,0 +1,102 @@
> > +/*
> > + * Copyright 2014 IBM Corp.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * as published by the Free Software Foundation; either version
> > + * 2 of the License, or (at your option) any later version.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include "cxl.h"
> > +
> > +/* protected by rcu */
> > +static struct cxl_calls *cxl_calls;
> > +
> > +static atomic_t use_count = ATOMIC_INIT(0);
> ...
>
> > +void cxl_ctx_get(void)
> > +{
> > + atomic_inc(_count);
> > +}
> > +EXPORT_SYMBOL(cxl_ctx_get);
> > +
> > +void cxl_ctx_put(void)
> > +{
> > + atomic_dec(_count);
> > +}
> > +EXPORT_SYMBOL(cxl_ctx_put);
> > +
> > +bool cxl_ctx_in_use(void)
> > +{
> > + return (atomic_read(_count) != 0);
> > +}
> > +EXPORT_SYMBOL(cxl_ctx_in_use);
>
> So as written this results in a function call for every tlbie(), even when no
> one has ever used a CAPI adapter, or when none are even in the machine.
Yep.
> I think the patch below is a better trade off. It makes the use_count global,
> but that's not a biggy. The benefit is that the additional code in tlbie()
> becomes:
>
> ld r10,-29112(r2)
> lwz r10,0(r10)
> cmpwi cr7,r10,0
>
> Which is about as good as it can get.
Nice.. I'll add. Thanks.
Mikey
>
> cheers
>
>
> diff --git a/drivers/misc/cxl/base.c b/drivers/misc/cxl/base.c
> index f4cbcfbd8dbc..4401d1c2dd33 100644
> --- a/drivers/misc/cxl/base.c
> +++ b/drivers/misc/cxl/base.c
> @@ -16,7 +16,7 @@
> /* protected by rcu */
> static struct cxl_calls *cxl_calls;
>
> -static atomic_t use_count = ATOMIC_INIT(0);
> +atomic_t cxl_use_count = ATOMIC_INIT(0);
>
> #ifdef CONFIG_CXL_MODULE
>
> @@ -65,24 +65,6 @@ void cxl_slbia(struct mm_struct *mm)
> }
> EXPORT_SYMBOL(cxl_slbia);
>
> -void cxl_ctx_get(void)
> -{
> - atomic_inc(_count);
> -}
> -EXPORT_SYMBOL(cxl_ctx_get);
> -
> -void cxl_ctx_put(void)
> -{
> - atomic_dec(_count);
> -}
> -EXPORT_SYMBOL(cxl_ctx_put);
> -
> -bool cxl_ctx_in_use(void)
> -{
> - return (atomic_read(_count) != 0);
> -}
> -EXPORT_SYMBOL(cxl_ctx_in_use);
> -
> int register_cxl_calls(struct cxl_calls *calls)
> {
> if (cxl_calls)
> diff --git a/include/misc/cxl.h b/include/misc/cxl.h
> index bde46a330881..6e43dca6a792 100644
> --- a/include/misc/cxl.h
> +++ b/include/misc/cxl.h
> @@ -18,12 +18,24 @@ struct cxl_irq_ranges {
> };
>
> #ifdef CONFIG_CXL_BASE
> +extern atomic_t cxl_use_count;
>
> void cxl_slbia(struct mm_struct *mm);
> -void cxl_ctx_get(void);
> -void cxl_ctx_put(void);
> -bool cxl_ctx_in_use(void);
>
> +static inline bool cxl_ctx_in_use(void)
> +{
> + return (atomic_read(_use_count) != 0);
> +}
> +
> +static inline void cxl_ctx_get(void)
> +{
> + atomic_inc(_use_count);
> +}
> +
> +static inline void cxl_ctx_put(void)
> +{
> + atomic_dec(_use_count);
> +}
> #else /* CONFIG_CXL_BASE */
>
> #define cxl_slbia(...) do { } while (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 V3 3/3] mfd: palmas: Add support for optional wakeup
Hi Thomas,
* Thomas Gleixner [140919 12:47]:
>
> The wakeup handler is supposed to bring the thing out of deep sleep
> and nothing else. All you want it to do is to mask itself and save the
> information that the real device irq is pending.
>
> A stub handler for the wakeup irq is enough. We can have that in the
> irq/pm core and all it would do is simply:
Here's a patch along the lines of what you described, hopefully that's
fairly close to what you had in mind.
I also did play with the replaying of the interrupts but I don't think
that's needed. Well at least not for the omap case. I added some
comments about that to the code.
So far I've tested with the omap-serial and omap_hsmmc drivers. The
serial driver does not have any status as the device is powered off.
So replaying of the interrupt does not help there, we need to wait for
the next event anyways.
Then with omap_hsmmc the SDIO interrupt on dat1 line is level
sensitive and is noticed after the MMC controller is powered on
again. So no replaying of the device interrupt needed here either.
I still have not tested the MMC remux lines to GPIO for wake-up
events that's also needed for some omaps.
Regards,
Tony
8<---
From: Tony Lindgren
Date: Wed, 1 Oct 2014 14:56:35 -0700
Subject: [PATCH] genirq: Add support for wake-up interrupts to fix irq reentry
issues in drivers
As pointed out by Thomas Gleixner, at least omap wake-up interrupts
have an issue with re-entrant interrupts because the wake-up interrupts
are now handled as a secondary interrupt controller. Further, the
wake-up interrupt just needs wake the system at least for omaps. So we
should just make the wake-up interrupt handling generic.
Note that at least initially we are keeping things simple by assuming the
wake-up interrupt is level sensitive, and the device pm_runtime_resume()
can deal with the situation, and no replaying of the lost device interrupts
is needed.
After tinkering with replaying of the lost device interrupts, my opinion is
that it should be avoided because of the issues listed in the comments of
this patch.
Signed-off-by: Tony Lindgren
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -139,11 +139,15 @@ extern int __must_check
request_percpu_irq(unsigned int irq, irq_handler_t handler,
const char *devname, void __percpu *percpu_dev_id);
+struct device;
+
+extern int __must_check
+request_wake_irq(struct device *dev, unsigned int wakeirq,
+unsigned long irqflags);
+
extern void free_irq(unsigned int, void *);
extern void free_percpu_irq(unsigned int, void __percpu *);
-struct device;
-
extern int __must_check
devm_request_threaded_irq(struct device *dev, unsigned int irq,
irq_handler_t handler, irq_handler_t thread_fn,
@@ -163,6 +167,10 @@ devm_request_any_context_irq(struct device *dev, unsigned
int irq,
irq_handler_t handler, unsigned long irqflags,
const char *devname, void *dev_id);
+extern int __must_check
+devm_request_wake_irq(struct device *dev, unsigned int wakeirq,
+ unsigned long irqflags);
+
extern void devm_free_irq(struct device *dev, unsigned int irq, void *dev_id);
/*
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1578,6 +1579,111 @@ int request_any_context_irq(unsigned int irq,
irq_handler_t handler,
}
EXPORT_SYMBOL_GPL(request_any_context_irq);
+/**
+ * handle_wakeirq_thread - call device runtime pm calls on wake-up
interrupt
+ * @wakeirq: device specific wake-up interrupt
+ * @dev_id: struct device entry
+ */
+static irqreturn_t handle_wakeirq_thread(int wakeirq, void *dev_id)
+{
+ struct device *dev = dev_id;
+ irqreturn_t ret = IRQ_NONE;
+
+ if (pm_runtime_suspended(dev)) {
+ pm_runtime_mark_last_busy(dev);
+ pm_request_resume(dev);
+ ret = IRQ_HANDLED;
+ }
+
+ return ret;
+}
+
+/**
+ * setup_wakeirq - allocate a wake-up interrupt for a device
+ * @dev: device to wake up
+ * @wakeirq: interrupt that wakes up the device
+ * @wakeflags: flags to pass to the interrupt handler
+ * @devm: use devm
+ *
+ * Note that the wake-up interrupt starts disabled. The wake-up interrupt
+ * is typically enabled from the device pm_runtime_suspend() and disabled
+ * again in the device pm_runtime_resume(). For runtime PM, the wake-up
+ * interrupt should be always enabled, and for device suspend and resume,
+ * the wake-up interrupt should be enabled depending on the device specific
+ * configuration for device_can_wakeup().
+ *
+ * Note also that we are not resending the lost device interrupts.
+ * We assume that the wake-up interrupt just needs to wake-up the device,
+ * and then device pm_runtime_resume() can deal with the situation.
+ *
+ * There are
Re: [PATCH v2 07/17] cxl: Add new header for call backs and structs
On Wed, 2014-10-01 at 22:00 +1000, Michael Ellerman wrote:
> On Tue, 2014-30-09 at 10:34:56 UTC, Michael Neuling wrote:
> > From: Ian Munsie
> >
> > This new header add defines for callbacks and structs needed by the rest of
> > the
> adds
> > kernel to hook into the cxl infrastructure.
> >
> > Empty functions are provided when CONFIG CXL_BASE is not enabled.
> >
> > Signed-off-by: Ian Munsie
> > Signed-off-by: Michael Neuling
> > ---
> > include/misc/cxl.h | 34 ++
>
> include/misc is kind of weird. I guess it's a misc device.
>
> Any reason not to have it in arch/powerpc/include ?
We can do either way. We did consider it a driver so putting it in
arch/powerpc didn't seem quite right.
I might leave it here unless you really object.
>
> > diff --git a/include/misc/cxl.h b/include/misc/cxl.h
> > new file mode 100644
> > index 000..bde46a3
> > --- /dev/null
> > +++ b/include/misc/cxl.h
> > @@ -0,0 +1,34 @@
> > +/*
> > + * Copyright 2014 IBM Corp.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * as published by the Free Software Foundation; either version
> > + * 2 of the License, or (at your option) any later version.
> > + */
> > +
> > +#ifndef _MISC_ASM_CXL_H
>
> No ASM.
Oops, yes.
>
> > +#define _MISC_ASM_CXL_H
> > +
> > +#define CXL_IRQ_RANGES 4
> > +
> > +struct cxl_irq_ranges {
> > + irq_hw_number_t offset[CXL_IRQ_RANGES];
> > + irq_hw_number_t range[CXL_IRQ_RANGES];
> > +};
> > +
> > +#ifdef CONFIG_CXL_BASE
> > +
> > +void cxl_slbia(struct mm_struct *mm);
> > +void cxl_ctx_get(void);
> > +void cxl_ctx_put(void);
> > +bool cxl_ctx_in_use(void);
> > +
> > +#else /* CONFIG_CXL_BASE */
> > +
> > +#define cxl_slbia(...) do { } while (0)
> > +#define cxl_ctx_in_use(...) false
>
> Any reason these shouldn't be static inlines?
No, I'll change.
Mikey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: pipe/page fault oddness.
On 10/01/2014 06:28 PM, Chuck Ebbert wrote: > On Wed, 01 Oct 2014 18:08:30 -0400 > Sasha Levin wrote: > >> > On 10/01/2014 04:20 PM, Linus Torvalds wrote: >>> > > So I'm really sending this patch out in the hope that it will get >>> > > comments, fixup and possibly even testing by people who actually know >>> > > the NUMA balancing code. Rik? Anybody? >> > >> > Hi Linus, >> > >> > I've tried this patch on the same configuration that was triggering >> > the VM_BUG_ON that Hugh mentioned previously. Surprisingly enough it >> > ran fine for ~20 minutes before exploding with: >> > >> > [ 2781.566206] kernel BUG at mm/huge_memory.c:1293! > That's: > BUG_ON(is_huge_zero_page(page)); > > Can you change your scripts to show the source code line when > the error is a BUG_ON()? The machine code disassembly after the > oops message doesn't really help. > Hum? The source code line is the first line in the trace: [ 2781.566206] kernel BUG at mm/huge_memory.c:1293! Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/4] regulator support for pmbus and ltc2978
On 10/01/2014 12:05 PM, at...@opensource.altera.com wrote: From: Alan Tull This set of patches adds regulator support for pmbus_core.c and ltc2978.c Each output has individual on/off control. From PMBus_Specification_Part_II_Rev_1-3_20140318.pdf: 12.1.1. OPERATION Command Bit [7] Bit [7] controls whether the PMBus device output is on or off. If bit [7] is cleared (equals 0), then the output is off. If bit [7] is set (equals 1), then the output is on. Fixes in v4 are not huge: Add device tree bindings documentation for ltc2978. rename _pmbus_regulator_enable to _pmbus_regulator_on_off simplify _pmbus_regulator_on_off code s/regulator_regulator/regulator/ fix build break when !CONFIG_REGULATOR remove unused #define PB_OPERATION_CONTROL_SEQ_OFF fix a #endif comment simplify probe code, remove added switch statement remove BUG_ON(), add error message and fix num_regulators Patch 1: document device tree bindings for ltc2978 Patch 2: add two helper functions for byte pmbus byte operations * byte write and byte read/modify/write Patch 3: regulator support added in pmbus_core.c and pmbus.h * regulator_ops functions (is_enabled, enable, and disable) * gets regulator init data from device tree or platform data * registers the regulators * header has a macro for chip drivers to build their regulator_desc data Patch 4: changes for ltc2978.c * Add Kconfig to enable/disable ltc2978 regulator functionality * add regulator_desc and of_regulator_match info * use same structs for all parts; set num_regulators appropriately. Alan Tull (3): pmbus: core: add helpers for byte write and read modify write pmbus: add regulator support pmbus: ltc2978: add regulator support Alan Tull (4): hwmon: ltc2978: device tree bindings documentation pmbus: core: add helpers for byte write and read modify write pmbus: add regulator support pmbus: ltc2978: add regulator support .../devicetree/bindings/hwmon/ltc2978.txt | 42 + drivers/hwmon/pmbus/Kconfig|7 + drivers/hwmon/pmbus/ltc2978.c | 37 + drivers/hwmon/pmbus/pmbus.h| 26 drivers/hwmon/pmbus/pmbus_core.c | 160 include/linux/i2c/pmbus.h |4 + 6 files changed, 276 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwmon/ltc2978.txt Overall looks ok. There is a whitespace error in patch #1, and the revision history should be after --- since we don't want it in the commit log. I fixed those up, and applied the series to my local hwmon-next branch. I'll do some more testing on a real system and then push it into -next. That should happen tomorrow unless I encounter some problems. We can take care of the Kconfig messages with a follow-up patch. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 08/17] powerpc/powerpc: Add new PCIe functions for allocating cxl interrupts
On Tue, 2014-30-09 at 10:34:57 UTC, Michael Neuling wrote:
> From: Ian Munsie
>
> This adds a number of functions for allocating IRQs under powernv PCIe for
> cxl.
>
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
> b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 329164f..b0b96f0 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -503,6 +505,138 @@ static struct pnv_ioda_pe *pnv_ioda_get_pe(struct
> pci_dev *dev)
> return NULL;
> return >ioda.pe_array[pdn->pe_number];
> }
> +
> +struct device_node *pnv_pci_to_phb_node(struct pci_dev *dev)
> +{
> +struct pci_controller *hose = pci_bus_to_host(dev->bus);
> +
> +return hose->dn;
> +}
> +EXPORT_SYMBOL(pnv_pci_to_phb_node);
> +
> +#ifdef CONFIG_CXL_BASE
> +int pnv_phb_to_cxl(struct pci_dev *dev)
> +{
> + struct pci_controller *hose = pci_bus_to_host(dev->bus);
> + struct pnv_phb *phb = hose->private_data;
> + struct pnv_ioda_pe *pe;
> + int rc;
> +
> + if (!(pe = pnv_ioda_get_pe(dev))) {
> + rc = -ENODEV;
> + goto out;
> + }
That'd be a lot simpler as:
pe = pnv_ioda_get_pe(dev);
if (!pe)
return -ENODEV;
> + pe_info(pe, "switch PHB to CXL\n");
> + pe_info(pe, "PHB-ID : 0x%016llx\n", phb->opal_id);
> + pe_info(pe, " pe : %i\n", pe->pe_number);
Spacing is a bit weird but maybe it matches something else?
> +
> + if ((rc = opal_pci_set_phb_cxl_mode(phb->opal_id, 1, pe->pe_number)))
> + dev_err(>dev, "opal_pci_set_phb_cxl_mode failed: %i\n",
> rc);
Again why not:
rc = opal_pci_set_phb_cxl_mode(phb->opal_id, 1, pe->pe_number);
if (rc)
dev_err(>dev, "opal_pci_set_phb_cxl_mode failed: %i\n",
rc);
> +out:
> + return rc;
> +}
> +EXPORT_SYMBOL(pnv_phb_to_cxl);
> +
> +int pnv_cxl_alloc_hwirq_ranges(struct cxl_irq_ranges *irqs,
> +struct pci_dev *dev, int num)
This could use some documentation.
It seems to be that it allocates num irqs in some number of ranges, up to
CXL_IRQ_RANGES?
> +{
> + struct pci_controller *hose = pci_bus_to_host(dev->bus);
> + struct pnv_phb *phb = hose->private_data;
> + int range = 0;
You reinitialise to 1 below?
> + int hwirq;
> + int try;
So these can be:
int hwirq, try, range;
> + memset(irqs, 0, sizeof(struct cxl_irq_ranges));
> +
> + for (range = 1; range < CXL_IRQ_RANGES && num; range++) {
I think this would be clearer if range was just called "i" as usual.
Why does it start at 1 ?
> + try = num;
> + while (try) {
> + hwirq = msi_bitmap_alloc_hwirqs(>msi_bmp, try);
> + if (hwirq >= 0)
> + break;
> + try /= 2;
> + }
> + if (!try)
> + goto fail;
> +
> + irqs->offset[range] = phb->msi_base + hwirq;
> + irqs->range[range] = try;
irqs->range is irq_hw_number_t but looks like it should just be uint.
> + pr_devel("cxl alloc irq range 0x%x: offset: 0x%lx limit:
> %li\n",
> + range, irqs->offset[range], irqs->range[range]);
> + num -= try;
> + }
> + if (num)
> + goto fail;
> +
> + return 0;
> +fail:
> + for (range--; range >= 0; range--) {
> + hwirq = irqs->offset[range] - phb->msi_base;
> + msi_bitmap_free_hwirqs(>msi_bmp, hwirq,
> +irqs->range[range]);
> + irqs->range[range] = 0;
> + }
Because you zero ranges at the top I think you can replace all of the fail
logic with a call to pnv_cxl_release_hwirq_ranges().
> + return -ENOSPC;
> +}
> +EXPORT_SYMBOL(pnv_cxl_alloc_hwirq_ranges);
> +
> +void pnv_cxl_release_hwirq_ranges(struct cxl_irq_ranges *irqs,
> + struct pci_dev *dev)
> +{
> + struct pci_controller *hose = pci_bus_to_host(dev->bus);
> + struct pnv_phb *phb = hose->private_data;
> + int range = 0;
Unnecessary init again.
> + int hwirq;
> +
> + for (range = 0; range < 4; range++) {
Shouldn't 4 be CXL_IRQ_RANGES ?
> + hwirq = irqs->offset[range] - phb->msi_base;
That should be inside the if.
Or better do:
if (!irqs->range[range])
continue;
...
> + if (irqs->range[range]) {
> + pr_devel("cxl release irq range 0x%x: offset: 0x%lx
> limit: %ld\n",
> + range, irqs->offset[range],
> + irqs->range[range]);
> + msi_bitmap_free_hwirqs(>msi_bmp, hwirq,
> +irqs->range[range]);
> + }
> + }
> +}
> +EXPORT_SYMBOL(pnv_cxl_release_hwirq_ranges);
> +
> +int pnv_cxl_get_irq_count(struct
Re: [PATCH v2 05/17] powerpc/mm: Export mmu_kernel_ssize and mmu_linear_psize
On Wed, 2014-10-01 at 17:13 +1000, Michael Ellerman wrote: > On Tue, 2014-30-09 at 10:34:54 UTC, Michael Neuling wrote: > > From: Ian Munsie > > Mind explaining why ? :) Sure. Mikey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v3.1 1/5] perf report: Set callchain_param.record_mode for future use
Normally the callchain_param.record_mode is used only for record path.
But as it might need to prepare something for dwarf unwinding, setup
this info for perf report too.
Cc: Jiri Olsa
Cc: David Ahern
Cc: Jean Pihet
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c | 6 ++
tools/perf/tests/dwarf-unwind.c | 3 +++
tools/perf/util/callchain.h | 2 ++
tools/perf/util/hist.h | 2 --
4 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index ac145fae0521..495168e73d4a 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -257,6 +257,12 @@ static int report__setup_sample_type(struct report *rep)
}
}
+ if (symbol_conf.use_callchain || symbol_conf.cumulate_callchain) {
+ if (sample_type & PERF_SAMPLE_REGS_USER)
+ callchain_param.record_mode = CALLCHAIN_DWARF;
+ else
+ callchain_param.record_mode = CALLCHAIN_FP;
+ }
return 0;
}
diff --git a/tools/perf/tests/dwarf-unwind.c b/tools/perf/tests/dwarf-unwind.c
index 96adb730b744..fc25e57f4a5d 100644
--- a/tools/perf/tests/dwarf-unwind.c
+++ b/tools/perf/tests/dwarf-unwind.c
@@ -9,6 +9,7 @@
#include "perf_regs.h"
#include "map.h"
#include "thread.h"
+#include "callchain.h"
static int mmap_handler(struct perf_tool *tool __maybe_unused,
union perf_event *event,
@@ -120,6 +121,8 @@ int test__dwarf_unwind(void)
return -1;
}
+ callchain_param.record_mode = CALLCHAIN_DWARF;
+
if (init_live_machine(machine)) {
pr_err("Could not init machine\n");
goto out;
diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
index 2a1f5a46543a..94cfefddf4db 100644
--- a/tools/perf/util/callchain.h
+++ b/tools/perf/util/callchain.h
@@ -65,6 +65,8 @@ struct callchain_param {
enum chain_key key;
};
+extern struct callchain_param callchain_param;
+
struct callchain_list {
u64 ip;
struct map_symbol ms;
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index 8c9c70e18cbb..ac1ee82c6c7e 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -8,8 +8,6 @@
#include "color.h"
#include "ui/progress.h"
-extern struct callchain_param callchain_param;
-
struct hist_entry;
struct addr_location;
struct symbol;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] perf report: Set callchain_param.record_mode for future use
Normally the callchain_param.record_mode is used only for record path.
But as it might need to prepare something for dwarf unwinding, setup
this info for perf report too.
Cc: Jiri Olsa
Cc: David Ahern
Cc: Jean Pihet
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index ac145fae0521..495168e73d4a 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -257,6 +257,12 @@ static int report__setup_sample_type(struct report *rep)
}
}
+ if (symbol_conf.use_callchain || symbol_conf.cumulate_callchain) {
+ if (sample_type & PERF_SAMPLE_REGS_USER)
+ callchain_param.record_mode = CALLCHAIN_DWARF;
+ else
+ callchain_param.record_mode = CALLCHAIN_FP;
+ }
return 0;
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] perf trace: Use thread_{,_set}_priv helpers
This is mechanical changes only for accounting access to thread->priv
properly in the source level.
Cc: David Ahern
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-trace.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 09bcf2393910..fb126459b134 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -1189,13 +1189,13 @@ static struct thread_trace *thread__trace(struct thread
*thread, FILE *fp)
if (thread == NULL)
goto fail;
- if (thread->priv == NULL)
- thread->priv = thread_trace__new();
+ if (thread__priv(thread) == NULL)
+ thread__set_priv(thread, thread_trace__new());
- if (thread->priv == NULL)
+ if (thread__priv(thread) == NULL)
goto fail;
- ttrace = thread->priv;
+ ttrace = thread__priv(thread);
++ttrace->nr_events;
return ttrace;
@@ -1248,7 +1248,7 @@ struct trace {
static int trace__set_fd_pathname(struct thread *thread, int fd, const char
*pathname)
{
- struct thread_trace *ttrace = thread->priv;
+ struct thread_trace *ttrace = thread__priv(thread);
if (fd > ttrace->paths.max) {
char **npath = realloc(ttrace->paths.table, (fd + 1) *
sizeof(char *));
@@ -1301,7 +1301,7 @@ static int thread__read_fd_path(struct thread *thread,
int fd)
static const char *thread__fd_path(struct thread *thread, int fd,
struct trace *trace)
{
- struct thread_trace *ttrace = thread->priv;
+ struct thread_trace *ttrace = thread__priv(thread);
if (ttrace == NULL)
return NULL;
@@ -1338,7 +1338,7 @@ static size_t syscall_arg__scnprintf_close_fd(char *bf,
size_t size,
{
int fd = arg->val;
size_t printed = syscall_arg__scnprintf_fd(bf, size, arg);
- struct thread_trace *ttrace = arg->thread->priv;
+ struct thread_trace *ttrace = thread__priv(arg->thread);
if (ttrace && fd >= 0 && fd <= ttrace->paths.max)
zfree(>paths.table[fd]);
@@ -2381,7 +2381,7 @@ static int trace__fprintf_one_thread(struct thread
*thread, void *priv)
FILE *fp = data->fp;
size_t printed = data->printed;
struct trace *trace = data->trace;
- struct thread_trace *ttrace = thread->priv;
+ struct thread_trace *ttrace = thread__priv(thread);
double ratio;
if (ttrace == NULL)
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] perf callchain: Create an address space per thread
The unw_addr_space_t in libunwind represents an address space to be
used for stack unwinding. It doesn't need to be create/destory
everytime to unwind callchain (as in get_entries) and can have a same
lifetime as thread (unless exec called).
So move the address space construction/destruction logic to the thread
lifetime handling functions. This is a preparation to enable caching
in the unwind library.
Note that it saves unw_addr_space_t object using thread__set_priv().
It seems currently only used by perf trace and perf kvm stat commands
which don't use callchain.
Acked-by: Jean Pihet
Cc: Jiri Olsa
Cc: Arun Sharma
Cc: David Ahern
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/util/thread.c | 6 ++
tools/perf/util/unwind-libunwind.c | 36 +++-
tools/perf/util/unwind.h | 17 +
3 files changed, 54 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
index a9df7f2c6dc9..2b7b2d91c016 100644
--- a/tools/perf/util/thread.c
+++ b/tools/perf/util/thread.c
@@ -7,6 +7,7 @@
#include "util.h"
#include "debug.h"
#include "comm.h"
+#include "unwind.h"
int thread__init_map_groups(struct thread *thread, struct machine *machine)
{
@@ -37,6 +38,9 @@ struct thread *thread__new(pid_t pid, pid_t tid)
thread->cpu = -1;
INIT_LIST_HEAD(>comm_list);
+ if (unwind__prepare_access(thread) < 0)
+ goto err_thread;
+
comm_str = malloc(32);
if (!comm_str)
goto err_thread;
@@ -48,6 +52,7 @@ struct thread *thread__new(pid_t pid, pid_t tid)
goto err_thread;
list_add(>list, >comm_list);
+
}
return thread;
@@ -69,6 +74,7 @@ void thread__delete(struct thread *thread)
list_del(>list);
comm__free(comm);
}
+ unwind__finish_access(thread);
free(thread);
}
diff --git a/tools/perf/util/unwind-libunwind.c
b/tools/perf/util/unwind-libunwind.c
index 92b56db52471..d9874465206b 100644
--- a/tools/perf/util/unwind-libunwind.c
+++ b/tools/perf/util/unwind-libunwind.c
@@ -525,12 +525,12 @@ static unw_accessors_t accessors = {
.get_proc_name = get_proc_name,
};
-static int get_entries(struct unwind_info *ui, unwind_entry_cb_t cb,
- void *arg, int max_stack)
+int unwind__prepare_access(struct thread *thread)
{
unw_addr_space_t addr_space;
- unw_cursor_t c;
- int ret;
+
+ if (callchain_param.record_mode != CALLCHAIN_DWARF)
+ return 0;
addr_space = unw_create_addr_space(, 0);
if (!addr_space) {
@@ -538,6 +538,33 @@ static int get_entries(struct unwind_info *ui,
unwind_entry_cb_t cb,
return -ENOMEM;
}
+ thread__set_priv(thread, addr_space);
+
+ return 0;
+}
+
+void unwind__finish_access(struct thread *thread)
+{
+ unw_addr_space_t addr_space;
+
+ if (callchain_param.record_mode != CALLCHAIN_DWARF)
+ return;
+
+ addr_space = thread__priv(thread);
+ unw_destroy_addr_space(addr_space);
+}
+
+static int get_entries(struct unwind_info *ui, unwind_entry_cb_t cb,
+ void *arg, int max_stack)
+{
+ unw_addr_space_t addr_space;
+ unw_cursor_t c;
+ int ret;
+
+ addr_space = thread__priv(ui->thread);
+ if (addr_space == NULL)
+ return -1;
+
ret = unw_init_remote(, addr_space, ui);
if (ret)
display_error(ret);
@@ -549,7 +576,6 @@ static int get_entries(struct unwind_info *ui,
unwind_entry_cb_t cb,
ret = ip ? entry(ip, ui->thread, ui->machine, cb, arg) : 0;
}
- unw_destroy_addr_space(addr_space);
return ret;
}
diff --git a/tools/perf/util/unwind.h b/tools/perf/util/unwind.h
index f03061260b4e..4b99c6280c2a 100644
--- a/tools/perf/util/unwind.h
+++ b/tools/perf/util/unwind.h
@@ -4,6 +4,7 @@
#include
#include "event.h"
#include "symbol.h"
+#include "thread.h"
struct unwind_entry {
struct map *map;
@@ -21,6 +22,15 @@ int unwind__get_entries(unwind_entry_cb_t cb, void *arg,
/* libunwind specific */
#ifdef HAVE_LIBUNWIND_SUPPORT
int libunwind__arch_reg_id(int regnum);
+int unwind__prepare_access(struct thread *thread);
+void unwind__finish_access(struct thread *thread);
+#else
+static inline int unwind__prepare_access(struct thread *thread)
+{
+ return 0;
+}
+
+static inline void unwind__finish_access(struct thread *thread) {}
#endif
#else
static inline int
@@ -33,5 +43,12 @@ unwind__get_entries(unwind_entry_cb_t cb __maybe_unused,
{
return 0;
}
+
+static inline int unwind__prepare_access(struct thread *thread)
+{
+ return 0;
+}
+
+static inline void unwind__finish_access(struct thread *thread) {}
#endif /*
[PATCHSET 0/5] perf tools: Speed up dwarf callchain post-unwinding for libunwind (v3)
Hello,
This is v3 for libunwind callchain post processing speed up. It was
able to reduce 50% of processing time by using global cache provided
in libunwind. In this version, I decided to use the existing
callchain_param.record_mode instead of adding a new field in the
symbol_conf.
The patch 4 and 5 are just cleanups so that we can easily find out
that which part of code uses the thread->priv.
You can also get it from 'perf/callchain-unwind-v3' branch on my tree:
git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
Thanks,
Namhyung
Namhyung Kim (5):
perf report: Set callchain_param.record_mode for future use
perf callchain: Create an address space per thread
perf callchain: Use global caching provided by libunwind
perf kvm: Use thread_{,_set}_priv helpers
perf trace: Use thread_{,_set}_priv helpers
tools/perf/builtin-kvm.c | 6 ++---
tools/perf/builtin-report.c| 6 +
tools/perf/builtin-trace.c | 16 ++---
tools/perf/tests/dwarf-unwind.c| 3 +++
tools/perf/util/callchain.h| 2 ++
tools/perf/util/hist.h | 2 --
tools/perf/util/thread.c | 9 +++
tools/perf/util/unwind-libunwind.c | 48 ++
tools/perf/util/unwind.h | 20
9 files changed, 94 insertions(+), 18 deletions(-)
--
2.1.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 4/5] perf kvm: Use thread_{,_set}_priv helpers
This is mechanical changes only for accounting access to thread->priv
properly in the source level.
Cc: David Ahern
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-kvm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-kvm.c b/tools/perf/builtin-kvm.c
index d8bf2271f4ea..d9b0743180db 100644
--- a/tools/perf/builtin-kvm.c
+++ b/tools/perf/builtin-kvm.c
@@ -376,7 +376,7 @@ struct vcpu_event_record *per_vcpu_record(struct thread
*thread,
struct perf_sample *sample)
{
/* Only kvm_entry records vcpu id. */
- if (!thread->priv && kvm_entry_event(evsel)) {
+ if (!thread__priv(thread) && kvm_entry_event(evsel)) {
struct vcpu_event_record *vcpu_record;
vcpu_record = zalloc(sizeof(*vcpu_record));
@@ -386,10 +386,10 @@ struct vcpu_event_record *per_vcpu_record(struct thread
*thread,
}
vcpu_record->vcpu_id = perf_evsel__intval(evsel, sample,
VCPU_ID);
- thread->priv = vcpu_record;
+ thread__set_priv(thread, vcpu_record);
}
- return thread->priv;
+ return thread__priv(thread);
}
static bool handle_kvm_event(struct perf_kvm_stat *kvm,
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] perf callchain: Use global caching provided by libunwind
The libunwind provides two caching policy which are global and
per-thread. As perf unwinds callchains in a single thread, it'd
sufficient to use global caching.
This speeds up my perf report from 14s to 7s on a ~260MB data file.
Although the output sometimes contains a slight difference (~0.01% in
terms of number of lines printed) on callchains which were not
resolved.
Acked-by: Jean Pihet
Cc: Jiri Olsa
Cc: Arun Sharma
Cc: David Ahern
Cc: Frederic Weisbecker
Signed-off-by: Namhyung Kim
---
tools/perf/util/thread.c | 3 +++
tools/perf/util/unwind-libunwind.c | 12
tools/perf/util/unwind.h | 3 +++
3 files changed, 18 insertions(+)
diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
index 2b7b2d91c016..c41411726c7a 100644
--- a/tools/perf/util/thread.c
+++ b/tools/perf/util/thread.c
@@ -117,6 +117,9 @@ int __thread__set_comm(struct thread *thread, const char
*str, u64 timestamp,
if (!new)
return -ENOMEM;
list_add(>list, >comm_list);
+
+ if (exec)
+ unwind__flush_access(thread);
}
thread->comm_set = true;
diff --git a/tools/perf/util/unwind-libunwind.c
b/tools/perf/util/unwind-libunwind.c
index d9874465206b..2d52af98bc8d 100644
--- a/tools/perf/util/unwind-libunwind.c
+++ b/tools/perf/util/unwind-libunwind.c
@@ -538,11 +538,23 @@ int unwind__prepare_access(struct thread *thread)
return -ENOMEM;
}
+ unw_set_caching_policy(addr_space, UNW_CACHE_GLOBAL);
thread__set_priv(thread, addr_space);
return 0;
}
+void unwind__flush_access(struct thread *thread)
+{
+ unw_addr_space_t addr_space;
+
+ if (callchain_param.record_mode != CALLCHAIN_DWARF)
+ return;
+
+ addr_space = thread__priv(thread);
+ unw_flush_cache(addr_space, 0, 0);
+}
+
void unwind__finish_access(struct thread *thread)
{
unw_addr_space_t addr_space;
diff --git a/tools/perf/util/unwind.h b/tools/perf/util/unwind.h
index 4b99c6280c2a..d68f24d4f01b 100644
--- a/tools/perf/util/unwind.h
+++ b/tools/perf/util/unwind.h
@@ -23,6 +23,7 @@ int unwind__get_entries(unwind_entry_cb_t cb, void *arg,
#ifdef HAVE_LIBUNWIND_SUPPORT
int libunwind__arch_reg_id(int regnum);
int unwind__prepare_access(struct thread *thread);
+void unwind__flush_access(struct thread *thread);
void unwind__finish_access(struct thread *thread);
#else
static inline int unwind__prepare_access(struct thread *thread)
@@ -30,6 +31,7 @@ static inline int unwind__prepare_access(struct thread
*thread)
return 0;
}
+static inline void unwind__flush_access(struct thread *thread) {}
static inline void unwind__finish_access(struct thread *thread) {}
#endif
#else
@@ -49,6 +51,7 @@ static inline int unwind__prepare_access(struct thread
*thread)
return 0;
}
+static inline void unwind__flush_access(struct thread *thread) {}
static inline void unwind__finish_access(struct thread *thread) {}
#endif /* HAVE_DWARF_UNWIND_SUPPORT */
#endif /* __UNWIND_H */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT] Networking
1) Don't halt the firmware in r8152 driver, from Hayes Wang. 2) Handle full sized 802.1ad frames in bnx2 and tg3 drivers properly, from Vlad Yasevich. 3) Don't sleep while holding tx_clean_lock in netxen driver, fix from Manish Chopra. 4) Certain kinds of ipv6 routes can end up endlessly failing the route validation test, causing it to be re-looked up over and over again. This particularly kills input route caching in TCP sockets. Fix from Hannes Frederic Sowa. 5) netvsc_start_xmit() has a use-after-free access to skb->len, fix from K. Y. Srinivasan. 6) Fix matching of inverted containers in ematch module, from Ignacy Gawędzki. 7) Aggregation of GRO frames via SKB ->frag_list for linear skbs isn't handled properly, regression fix from Eric Dumazet. 8) Don't test return value of ipv4_neigh_lookup(), which returns an error pointer, against NULL. From WANG Cong. 9) Fix an old regression where we mistakenly allow a double add of the same tunnel. Fixes from Steffen Klassert. 10) macvtap device delete and open can run in parallel and corrupt lists etc., fix from Vlad Yasevich. 11) Fix build error with IPV6=m NETFILTER_XT_TARGET_TPROXY=y, from Pablo Neira Ayuso. 12) rhashtable_destroy() triggers lockdep splats, fix also from Pablo. Please pull, thanks a lot! The following changes since commit b94d525e58dc9638dd3f98094cb468bcfb262039: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2014-09-24 12:45:24 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master for you to fetch changes up to 439e9575e777bdad1d9da15941e02adf34f4c392: bna: Update Maintainer Email (2014-10-01 22:13:41 -0400) David S. Miller (5): Merge branch 'qlcnic' Merge git://git.kernel.org/.../pablo/nf Merge branch 'ipv6_tunnel' Merge branch 'netxen' Merge branch 'r8152' Eric Dumazet (1): gro: fix aggregation for skb using frag_list Hannes Frederic Sowa (1): ipv6: remove rt6i_genid Ignacy Gawędzki (1): ematch: Fix matching of inverted containers. KY Srinivasan (1): hyperv: Fix a bug in netvsc_start_xmit() Kweh, Hock Leong (1): net: stmmac: fix stmmac_pci_probe failed when CONFIG_HAVE_CLK is selected Manish Chopra (5): qlcnic: Fix memory corruption while reading stats using ethtool. qlcnic: Remove __QLCNIC_DEV_UP bit check to read TX queues statistics. qlcnic: Fix ordering of stats in stats buffer. netxen: Fix BUG "sleeping function called from invalid context" netxen: Fix bug in Tx completion path. Matan Barak (1): net/mlx4_core: Allow not to specify probe_vf in SRIOV IB mode Nicolas Dichtel (1): ip6gre: add a rtnl link alias for ip6gretap Pablo Neira Ayuso (5): netfilter: nft_hash: no need for rcu in the hash set destroy path netfilter: nft_rbtree: no need for spinlock from set destroy path rhashtable: fix lockdep splat in rhashtable_destroy() netfilter: nfnetlink: deliver netlink errors on batch completion netfilter: xt_TPROXY: undefined reference to `udp6_lib_lookup' Rasesh Mody (1): bna: Update Maintainer Email Sony Chacko (1): qlcnic: Use qlcnic_83xx_flash_read32() API instead of lockless version of the API. Soren Brinkmann (1): Revert "net/macb: add pinctrl consumer support" Steffen Klassert (4): ip_tunnel: Don't allow to add the same tunnel multiple times. ip6_tunnel: Return an error when adding an existing tunnel. ip6_vti: Return an error when adding an existing tunnel. ip6_gre: Return an error when adding an existing tunnel. Vlad Yasevich (3): macvtap: Fix race between device delete and open. tg3: Allow for recieve of full-size 8021AD frames bnx2: Correctly receive full sized 802.1ad fragmes WANG Cong (1): neigh: check error pointer instead of NULL for ipv4_neigh_lookup() hayeswang (4): r8152: fix the carrier off when autoresuming r8152: fix setting RTL8152_UNPLUG r8152: remove clearing bp r8152: disable power cut for RTL8153 MAINTAINERS | 2 +- drivers/net/ethernet/broadcom/bnx2.c | 5 ++-- drivers/net/ethernet/broadcom/tg3.c | 3 +- drivers/net/ethernet/cadence/macb.c | 11 --- drivers/net/ethernet/mellanox/mlx4/main.c | 4 +-- drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c | 6 ++-- drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c | 2 -- drivers/net/ethernet/qlogic/qlcnic/qlcnic_83xx_init.c | 5 ++-- drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c | 10 +++ drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 11 +-- drivers/net/hyperv/netvsc_drv.c | 3 +- drivers/net/macvtap.c | 18 +--
Re: [PATCH] Fixed all coding style issues for drivers/staging/media/lirc/
On Wed, Oct 01, 2014 at 07:35:51PM -0700, Amber Thrall wrote: > Fixed various coding sytles. You need to be specific as to what you changed. Also, use get_maintainer to figure out who to sent this to (hint, not me...) greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fixed all coding style issues for drivers/staging/media/lirc/
Fixed various coding sytles.
Signed-off-by: Amber Thrall
---
drivers/staging/media/lirc/lirc_bt829.c | 2 +-
drivers/staging/media/lirc/lirc_imon.c | 4 +-
drivers/staging/media/lirc/lirc_sasem.c | 6 +--
drivers/staging/media/lirc/lirc_serial.c | 29 ++
drivers/staging/media/lirc/lirc_sir.c| 3 +-
drivers/staging/media/lirc/lirc_zilog.c | 69 +++-
6 files changed, 52 insertions(+), 61 deletions(-)
diff --git a/drivers/staging/media/lirc/lirc_bt829.c
b/drivers/staging/media/lirc/lirc_bt829.c
index 4c806ba..c70ca68 100644
--- a/drivers/staging/media/lirc/lirc_bt829.c
+++ b/drivers/staging/media/lirc/lirc_bt829.c
@@ -59,7 +59,7 @@ static bool debug;
#define dprintk(fmt, args...) \
do { \
if (debug) \
- printk(KERN_DEBUG DRIVER_NAME ": "fmt, ## args); \
+ dev_dbg(DRIVER_NAME, ": "fmt, ##args); \
} while (0)
static int atir_minor;
diff --git a/drivers/staging/media/lirc/lirc_imon.c
b/drivers/staging/media/lirc/lirc_imon.c
index 7aca44f..bce0408 100644
--- a/drivers/staging/media/lirc/lirc_imon.c
+++ b/drivers/staging/media/lirc/lirc_imon.c
@@ -623,8 +623,8 @@ static void imon_incoming_packet(struct imon_context
*context,
if (debug) {
dev_info(dev, "raw packet: ");
for (i = 0; i < len; ++i)
- printk("%02x ", buf[i]);
- printk("\n");
+ dev_info(dev, "%02x ", buf[i]);
+ dev_info(dev, "\n");
}
/*
diff --git a/drivers/staging/media/lirc/lirc_sasem.c
b/drivers/staging/media/lirc/lirc_sasem.c
index c20ef56..e88e246 100644
--- a/drivers/staging/media/lirc/lirc_sasem.c
+++ b/drivers/staging/media/lirc/lirc_sasem.c
@@ -583,10 +583,10 @@ static void incoming_packet(struct sasem_context *context,
}
if (debug) {
- printk(KERN_INFO "Incoming data: ");
+ pr_info("Incoming data: ");
for (i = 0; i < 8; ++i)
- printk(KERN_CONT "%02x ", buf[i]);
- printk(KERN_CONT "\n");
+ pr_cont("%02x", buf[i]);
+ pr_cont("\n");
}
/*
diff --git a/drivers/staging/media/lirc/lirc_serial.c
b/drivers/staging/media/lirc/lirc_serial.c
index 181b92b..b07671b 100644
--- a/drivers/staging/media/lirc/lirc_serial.c
+++ b/drivers/staging/media/lirc/lirc_serial.c
@@ -116,8 +116,7 @@ static bool txsense;/* 0 = active high, 1 = active
low */
#define dprintk(fmt, args...) \
do {\
if (debug) \
- printk(KERN_DEBUG LIRC_DRIVER_NAME ": " \
- fmt, ## args); \
+ dev_dbg(LIRC_DRIVER_NAME, ": "fmt, ##args); \
} while (0)
/* forward declarations */
@@ -356,9 +355,8 @@ static int init_timing_params(unsigned int new_duty_cycle,
/* Derive pulse and space from the period */
pulse_width = period * duty_cycle / 100;
space_width = period - pulse_width;
- dprintk("in init_timing_params, freq=%d, duty_cycle=%d, "
- "clk/jiffy=%ld, pulse=%ld, space=%ld, "
- "conv_us_to_clocks=%ld\n",
+ dprintk("in init_timing_params, freq=%d, duty_cycle=%d, clk/jiffy=%ld,
+ pulse=%ld, space=%ld, conv_us_to_clocks=%ld\n",
freq, duty_cycle, __this_cpu_read(cpu_info.loops_per_jiffy),
pulse_width, space_width, conv_us_to_clocks);
return 0;
@@ -1075,7 +1073,7 @@ static int __init lirc_serial_init(void)
result = platform_driver_register(_serial_driver);
if (result) {
- printk("lirc register returned %d\n", result);
+ dprintk("lirc register returned %d\n", result);
goto exit_buffer_free;
}
@@ -1166,22 +1164,20 @@ module_init(lirc_serial_init_module);
module_exit(lirc_serial_exit_module);
MODULE_DESCRIPTION("Infra-red receiver driver for serial ports.");
-MODULE_AUTHOR("Ralph Metzler, Trent Piepho, Ben Pfaff, "
- "Christoph Bartelmus, Andrei Tanas");
+MODULE_AUTHOR("Ralph Metzler, Trent Piepho, Ben Pfaff, Christoph Bartelmus,
Andrei Tanas");
MODULE_LICENSE("GPL");
module_param(type, int, S_IRUGO);
-MODULE_PARM_DESC(type, "Hardware type (0 = home-brew, 1 = IRdeo,"
-" 2 = IRdeo Remote, 3 = AnimaX, 4 = IgorPlug,"
-" 5 = NSLU2 RX:CTS2/TX:GreenLED)");
+MODULE_PARM_DESC(type, "Hardware type (0 = home-brew, 1 = IRdeo,
+ 2 = IRdeo Remote, 3 = AnimaX, 4 = IgorPlug,
+ 5 = NSLU2 RX:CTS2/TX:GreenLED)");
module_param(io, int, S_IRUGO);
RE: linux-next: build failure after merge of the arm-soc tree
+ Mike
Stephen Rothwell wrote:
>
> Hi all,
>
Hi,
> After merging the arm-soc tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> arch/arm/boot/dts/exynos5250-snow.dts:13:46: fatal error:
> dt-bindings/clock/maxim,max77686.h: No such
> file or directory
> #include
> ^
>
> Caused by commit c04c92ed5614 ("ARM: dts: Add rtc_src clk for s3c-rtc
> on exynos5250-snow").
>
> Presumably there is some dependency on some tree that someone has
> forgotten to merge :-(
>
Hmm...I thought it should be fine once Mike's clk tree is landing into the
-next tree. Firstly sorry about that and how should I do in this case?
> I reverted that commit for today.
>
> Which then got to:
>
> /scratch/sfr/next/arch/arm/boot/dts/exynos5420-peach-pit.dts:15:46: fatal
> error: dt-
> bindings/clock/maxim,max77802.h: No such file or directory
> #include
> ^
> compilation terminated.
> /scratch/sfr/next/arch/arm/boot/dts/exynos5800-peach-pi.dts:15:46: fatal
> error: dt-
> bindings/clock/maxim,max77802.h: No such file or directory
> #include
> ^
> compilation terminated.
> Error: /scratch/sfr/next/arch/arm/boot/dts/hisi-x5hd2.dtsi:417.21-22 syntax
> error
> FATAL ERROR: Unable to parse input tree
>
> Caused by 8bd43b6e6df7 ("ARM: dts: Add rtc_src clk for s3c-rtc on
> exynos Peach boards").
>
> I give up ... please test your trees better ...
>
So sorry, actually it's my fault, I missed the information to arm-soc when I
sent a pull-request, just I thought arm-soc were aware of that before happening
the error when samsung tree merged...
- Kukjin
> I have used the arm-soc tree form next-20141001 for today (which still
> needs 5 reverts to get it to build :-().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] staging: Add Xilinx Clocking Wizard driver
On Thu, 2014-10-02 at 02:19AM +0300, Laurent Pinchart wrote:
> Hi Sören,
>
> Thank you for the patch.
>
> On Wednesday 01 October 2014 14:02:32 Soren Brinkmann wrote:
> > Add a driver for the Xilinx Clocking Wizard soft IP. The clocking wizard
> > provides an AXI interface to dynamically reconfigure the clocking
> > resources of Xilinx FPGAs.
> >
> > Signed-off-by: Soren Brinkmann
> > ---
> > Hi Greg, Dan,
> >
> > I fixed the things Dan pointed out, please take this v2 instead of the
> > original patch.
> >
> > Also, don't get caught up too much with style issues around the code that
> > registers the clocks. To support set_rate() opeartions this will have to
> > change anyway. It doesn't make a lot of sense to spend much time on those
> > parts.
> >
> > Thanks,
> > Sören
> >
> > v2:
> > - implement dev_pm_ops
> > - don't use array for clock inputs
> > - add more information in error output
> > - fix style issues
> > - fix error path
> > ---
> > drivers/staging/Kconfig| 2 +
> > drivers/staging/Makefile | 1 +
> > drivers/staging/clocking-wizard/Kconfig| 9 +
> > drivers/staging/clocking-wizard/Makefile | 1 +
> > drivers/staging/clocking-wizard/TODO | 12 +
> > .../clocking-wizard/clk-xlnx-clock-wizard.c| 336 ++
> > drivers/staging/clocking-wizard/dt-binding.txt | 30 ++
> > 7 files changed, 391 insertions(+)
> > create mode 100644 drivers/staging/clocking-wizard/Kconfig
> > create mode 100644 drivers/staging/clocking-wizard/Makefile
> > create mode 100644 drivers/staging/clocking-wizard/TODO
> > create mode 100644 drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
> > create mode 100644 drivers/staging/clocking-wizard/dt-binding.txt
>
> [snip]
>
> > diff --git a/drivers/staging/clocking-wizard/dt-binding.txt
> > b/drivers/staging/clocking-wizard/dt-binding.txt new file mode 100644
> > index ..cc3cc5e91440
> > --- /dev/null
> > +++ b/drivers/staging/clocking-wizard/dt-binding.txt
> > @@ -0,0 +1,30 @@
> > +Binding for Xilinx Clocking Wizard IP Core
> > +
> > +This binding uses the common clock binding[1]. Details about the devices
> > can be +found in the product guide[2].
> > +
> > +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> > +[2] Clocking Wizard Product Guide
> > +http://www.xilinx.com/support/documentation/ip_documentation/clk_wiz/v5_1/p
> > g065-clk-wiz.pdf +
> > +Required properties:
> > + - compatible: Must be 'xlnx,clocking-wizard'
> > + - reg: Base and size of the cores register space
> > + - clocks: Handle to input clock
> > + - clock-names: Tuple containing 'clk_in1' and 's_axi_aclk'
> > + - clock-output-names: Names for the output clocks
> > +
> > +Optional properties:
> > + - speed-grade: Speed grade of the device
>
> You should document what values are allowed.
Will do.
> > +
> > +Example:
> > + clock-generator@4004 {
> > + reg = <0x4004 0x1000>;
> > + compatible = "xlnx,clocking-wizard";
> > + speed-grade = <(-1)>;
>
> Can't we make the speed grade positive ? It looks to me that the - is
> nowadays
> a dash and not a minus sign, given that higher absolute values of the speed
> grade mean faster devices. The days when the speed grate represented the
> propagation time of signals in ns is long gone I suppose.
Fine with me.
Thanks,
Sören
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] drivers:ethernet:davinci_emac.c:Fixes flaw in mac address handling.
The code currently checks the mac_addr variable that is clearly
zero'd out during allocation.
Further code is added to bring the mac_addr from the partial pdata.
Signed-off-by: Michael Welling
---
drivers/net/ethernet/ti/davinci_emac.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c
b/drivers/net/ethernet/ti/davinci_emac.c
index ea71251..e06f97c 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -1804,11 +1804,9 @@ davinci_emac_of_get_pdata(struct platform_device *pdev,
struct emac_priv *priv)
np = pdev->dev.of_node;
pdata->version = EMAC_VERSION_2;
- if (!is_valid_ether_addr(pdata->mac_addr)) {
- mac_addr = of_get_mac_address(np);
- if (mac_addr)
- memcpy(pdata->mac_addr, mac_addr, ETH_ALEN);
- }
+ mac_addr = of_get_mac_address(np);
+ if (mac_addr)
+ memcpy(pdata->mac_addr, mac_addr, ETH_ALEN);
of_property_read_u32(np, "ti,davinci-ctrl-reg-offset",
>ctrl_reg_offset);
@@ -1834,6 +1832,8 @@ davinci_emac_of_get_pdata(struct platform_device *pdev,
struct emac_priv *priv)
if (auxdata) {
pdata->interrupt_enable = auxdata->interrupt_enable;
pdata->interrupt_disable = auxdata->interrupt_disable;
+ if (is_valid_ether_addr(auxdata->mac_addr))
+ memcpy(pdata->mac_addr, auxdata->mac_addr, ETH_ALEN);
}
match = of_match_device(davinci_emac_of_match, >dev);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 04/17] powerpc/msi: Improve IRQ bitmap allocator
On Wed, 2014-10-01 at 17:13 +1000, Michael Ellerman wrote:
> On Tue, 2014-30-09 at 10:34:53 UTC, Michael Neuling wrote:
> > From: Ian Munsie
> >
> > Currently msi_bitmap_alloc_hwirqs() will round up any IRQ allocation
> > requests
>request
> > to the nearest power of 2. eg. ask for 5 IRQs and you'll get 8. This
> > wastes a
> ^ one space after a period, or die!
>
> > lot of IRQs which can be a scarce resource.
> >
> > For cxl we can require multiple IRQs for every contexts that is attached to
> > the
> context
> > accelerator. For AFU directed accelerators, there may be 1000s of contexts
>
> What is an AFU directed accelerator?
>From the documentation in the last patch:
AFU Models
==
There are two programming models supported by the AFU. Dedicated
and AFU directed. AFU may support one or both models.
In dedicated model only one MMU context is supported. In this
model, only one userspace process can use the accelerator at time.
In AFU directed model, up to 16K simultaneous contexts can be
supported. This means up to 16K simultaneous userspace
applications may use the accelerator (although specific AFUs may
support less). In this mode, the AFU sends a 16 bit context ID
with each of its requests. This tells the PSL which context is
associated with this operation. If the PSL can't translate a
request, the ID can also be accessed by the kernel so it can
determine the associated userspace context to service this
translation with.
>
> > attached, hence we can easily run out of IRQs, especially if we are
> > needlessly
> > wasting them.
> >
> > This changes the msi_bitmap_alloc_hwirqs() to allocate only the required
> > number
> x
> > of IRQs, hence avoiding this wastage.
>
> The crucial detail you failed to mention is that you maintain the behaviour
> that
> allocations are naturally aligned.
ok, I'll add that.
> Can you add a check in the test code at the bottom of the file to confirm that
> please?
Yep
>
> > diff --git a/arch/powerpc/sysdev/msi_bitmap.c
> > b/arch/powerpc/sysdev/msi_bitmap.c
> > index 2ff6302..961a358 100644
> > --- a/arch/powerpc/sysdev/msi_bitmap.c
> > +++ b/arch/powerpc/sysdev/msi_bitmap.c
> > @@ -20,32 +20,37 @@ int msi_bitmap_alloc_hwirqs(struct msi_bitmap *bmp, int
> > num)
> > int offset, order = get_count_order(num);
> >
> > spin_lock_irqsave(>lock, flags);
> > - /*
> > -* This is fast, but stricter than we need. We might want to add
> > -* a fallback routine which does a linear search with no alignment.
> > -*/
> > - offset = bitmap_find_free_region(bmp->bitmap, bmp->irq_count, order);
> > +
> > + offset = bitmap_find_next_zero_area(bmp->bitmap, bmp->irq_count, 0,
> > + num, (1 << order) - 1);
> > + if (offset > bmp->irq_count)
> > + goto err;
>
> Can we get a newline here :)
Ok.
>
> > + bitmap_set(bmp->bitmap, offset, num);
> > spin_unlock_irqrestore(>lock, flags);
> >
> > pr_debug("msi_bitmap: allocated 0x%x (2^%d) at offset 0x%x\n",
> > num, order, offset);
>
> This print out is a bit confusing now, should probably just drop the order.
Arrh, yep.
Thanks,
Mikey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Soft lockup in 3.17-rc7 when using PPP over L2TP over IPSEC
I reliably get the following lockup when trying to set up a VPN tunnel using L2TP over IPSEC: [ 2214.970639] BUG: soft lockup - CPU#1 stuck for 22s! [pppd:9423] [ 2214.970648] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core pppoe pppox ppp_generic slhc authenc cmac rmd160 crypto_null ip_vti ip_tunnel af_key ah6 ah4 esp6 esp4 xfrm4_mode_beet xfrm4_tunnel tunnel4 xfrm4_mode_tunnel xfrm4_mode_transport xfrm6_mode_transport xfrm6_mode_ro xfrm6_mode_beet xfrm6_mode_tunnel ipcomp ipcomp6 xfrm6_tunnel tunnel6 xfrm_ipcomp salsa20_i586 camellia_generic cast6_generic cast5_generic cast_common deflate cts gcm ccm serpent_sse2_i586 serpent_generic glue_helper blowfish_generic blowfish_common twofish_generic twofish_i586 twofish_common xcbc sha512_generic des_generic geode_aes tpm_rng tpm timeriomem_rng virtio_rng uas usb_storage fuse ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 ip6table_filter xt_conntrack ip6_tables nf_conntrack vfat [ 2214.970769] fat snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel arc4 iwldvm snd_hda_controller snd_hda_codec uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev mac80211 snd_hwdep coretemp kvm_intel kvm media snd_seq snd_seq_device iTCO_wdt iTCO_vendor_support snd_pcm snd_timer snd joydev iwlwifi microcode serio_raw cfg80211 asus_laptop lpc_ich atl1c soundcore sparse_keymap rfkill input_polldev acpi_cpufreq binfmt_misc i915 i2c_algo_bit drm_kms_helper drm i2c_core video [ 2214.970854] CPU: 1 PID: 9423 Comm: pppd Tainted: GW 3.16.3-200.fc20.i686 #1 [ 2214.970860] Hardware name: ASUSTeK Computer Inc. UL20A /UL20A , BIOS 207 11/02/2009 [ 2214.970866] task: f0706a00 ti: e359c000 task.ti: e359c000 [ 2214.970873] EIP: 0060:[] EFLAGS: 00200287 CPU: 1 [ 2214.970885] EIP is at _raw_spin_lock_bh+0x28/0x40 [ 2214.970890] EAX: e5ff02a4 EBX: e5ff02a4 ECX: 0060 EDX: 005f [ 2214.970895] ESI: e5ff02b0 EDI: e3470d40 EBP: e359dc34 ESP: e359dc34 [ 2214.970900] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 2214.970906] CR0: 8005003b CR2: b72eb000 CR3: 25f28000 CR4: 000407d0 [ 2214.970910] Stack: [ 2214.970914] e359dc9c f94efe2a f514 e359dc50 c045aba6 f514 00200286 e359dc78 [ 2214.970929] c045c553 0001 f514 001f9076 00200286 628a17c6 f075acc0 f075acc0 [ 2214.970942] 00200246 f4464848 00200246 00200246 e359dc9c e3470d84 f075acc0 [ 2214.970957] Call Trace: [ 2214.970973] [] ppp_push+0x32a/0x550 [ppp_generic] [ 2214.970986] [] ? internal_add_timer+0x26/0x60 [ 2214.970994] [] ? mod_timer_pending+0x63/0x130 [ 2214.971005] [] ppp_xmit_process+0x3cd/0x5e0 [ppp_generic] [ 2214.971007] [] ? harmonize_features+0x31/0x1d0 [ 2214.971007] [] ppp_start_xmit+0x108/0x180 [ppp_generic] [ 2214.971007] [] dev_hard_start_xmit+0x2c4/0x540 [ 2214.971007] [] sch_direct_xmit+0x9f/0x170 [ 2214.971007] [] __dev_queue_xmit+0x1ca/0x430 [ 2214.971007] [] ? ip_fragment+0x930/0x930 [ 2214.971007] [] dev_queue_xmit+0xf/0x20 [ 2214.971007] [] neigh_direct_output+0xf/0x20 [ 2214.971007] [] ip_finish_output+0x1aa/0x850 [ 2214.971007] [] ? ip_fragment+0x930/0x930 [ 2214.971007] [] ip_output+0x8f/0xe0 [ 2214.971007] [] ? ip_fragment+0x930/0x930 [ 2214.971007] [] xfrm_output_resume+0x342/0x3a0 [ 2214.971007] [] xfrm_output+0x43/0xf0 [ 2214.971007] [] xfrm4_output_finish+0x3d/0x40 [ 2214.971007] [] __xfrm4_output+0x25/0x40 [ 2214.971007] [] xfrm4_output+0x2f/0x70 [ 2214.971007] [] ? xfrm4_udp_encap_rcv+0x1b0/0x1b0 [ 2214.971007] [] ip_local_out_sk+0x27/0x30 [ 2214.971007] [] ip_queue_xmit+0x124/0x3f0 [ 2214.971007] [] ? xfrm_bundle_ok+0x64/0x170 [ 2214.971007] [] ? xfrm_dst_check+0x1b/0x30 [ 2214.971007] [] l2tp_xmit_skb+0x298/0x4b0 [l2tp_core] [ 2214.971007] [] pppol2tp_xmit+0x124/0x1d0 [l2tp_ppp] [ 2214.971007] [] ppp_channel_push+0x3b/0xb0 [ppp_generic] [ 2214.971007] [] ppp_write+0x87/0xc8 [ppp_generic] [ 2214.971007] [] ? ppp_start_xmit+0x180/0x180 [ppp_generic] [ 2214.971007] [] vfs_write+0x9d/0x1d0 [ 2214.971007] [] SyS_write+0x51/0xb0 [ 2214.971007] [] sysenter_do_call+0x12/0x12 [ 2214.971007] Code: 00 00 00 55 89 e5 66 66 66 66 90 64 81 05 90 b6 dc c0 00 02 00 00 ba 00 01 00 00 f0 66 0f c1 10 0f b6 ce 38 d1 75 04 5d c3 f3 90 <0f> b6 10 38 ca 75 f7 5d c3 90 90 90 90 90 90 90 90 90 90 90 90 [ 2220.002045] iwlwifi :01:00.0: No space in command queue [ 2220.002058] iwlwifi :01:00.0: Restarting adapter queue is full [ 2220.002073] iwlwifi :01:00.0: Error sending REPLY_LEDS_CMD: enqueue_hcmd failed: -28 [ 2220.002524] ieee80211 phy0: Hardware restart was requested A few seconds after this appears, the second CPU also locks up and the system becomes useless. I don't know if the problem is in the networking core or in the wireless driver. If anyone wants, I can try testing using a wired Ethernet connection. Note: This problem is not new. It has been happening for at least the last several kernel versions -- in
Re: [PATCH v2 06/17] powerpc/powernv: Split out set MSI IRQ chip code
On Tue, 2014-30-09 at 10:34:55 UTC, Michael Neuling wrote:
> From: Ian Munsie
>
> Some of the MSI IRQ code in pnv_pci_ioda_msi_setup() is generically useful so
> split it out.
>
> This will be used by some of the cxl PCIe code later.
>
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
> b/arch/powerpc/platforms/powernv/pci-ioda.c
> index df241b1..329164f 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -1306,14 +1306,36 @@ static void pnv_ioda2_msi_eoi(struct irq_data *d)
> icp_native_eoi(d);
> }
>
> +
> +static void set_msi_irq_chip(struct pnv_phb *phb, unsigned int virq)
> +{
> + struct irq_data *idata;
> + struct irq_chip *ichip;
> +
> + if (phb->type != PNV_PHB_IODA2)
> + return;
> +
> + /*
> + * Change the IRQ chip for the MSI interrupts on PHB3.
> + * The corresponding IRQ chip should be populated for
> + * the first time.
Seeing as you're moving this comment can you clarify the wording.
cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the arm-soc tree
Hi all,
After merging the arm-soc tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
arch/arm/boot/dts/exynos5250-snow.dts:13:46: fatal error:
dt-bindings/clock/maxim,max77686.h: No such file or directory
#include
^
Caused by commit c04c92ed5614 ("ARM: dts: Add rtc_src clk for s3c-rtc
on exynos5250-snow").
Presumably there is some dependency on some tree that someone has
forgotten to merge :-(
I reverted that commit for today.
Which then got to:
/scratch/sfr/next/arch/arm/boot/dts/exynos5420-peach-pit.dts:15:46: fatal
error: dt-bindings/clock/maxim,max77802.h: No such file or directory
#include
^
compilation terminated.
/scratch/sfr/next/arch/arm/boot/dts/exynos5800-peach-pi.dts:15:46: fatal error:
dt-bindings/clock/maxim,max77802.h: No such file or directory
#include
^
compilation terminated.
Error: /scratch/sfr/next/arch/arm/boot/dts/hisi-x5hd2.dtsi:417.21-22 syntax
error
FATAL ERROR: Unable to parse input tree
Caused by 8bd43b6e6df7 ("ARM: dts: Add rtc_src clk for s3c-rtc on
exynos Peach boards").
I give up ... please test your trees better ...
I have used the arm-soc tree form next-20141001 for today (which still
needs 5 reverts to get it to build :-().
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH net-next 0/2] bpf: add search pruning optimization and tests
From: Alexei Starovoitov Date: Mon, 29 Sep 2014 18:50:00 -0700 > patch #1 commit log explains why eBPF verifier has to examine some > instructions multiple times and describes the search pruning optimization > that improves verification speed for branchy programs and allows more > complex programs to be verified successfully. > This patch completes the core verifier logic. > > patch #2 adds more verifier tests related to branches and search pruning > > I'm still working on Andy's 'bitmask for stack slots' suggestion. It will be > done on top of this patch. > > The current verifier algorithm is brute force depth first search with > state pruning. If anyone can come up with another algorithm that demonstrates > better results, we'll replace the algorithm without affecting user space. > > Note verifier doesn't guarantee that all possible valid programs are accepted. > Overly complex programs may still be rejected. > Verifier improvements/optimizations will guarantee that if a program > was passing verification in the past, it will still be passing. Series applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/4] pmbus: ltc2978: add regulator support
On 10/01/2014 03:20 PM, atull wrote: On Wed, 1 Oct 2014, Guenter Roeck wrote: On Wed, Oct 01, 2014 at 03:18:20PM -0500, at...@opensource.altera.com wrote: From: Alan Tull Add simple on/off regulator support for ltc2978 and other pmbus parts supported by ltc2978.c Signed-off-by: Alan Tull v2: Remove '#include ' Only one regulator per pmbus device Get regulator_init_data from pdata or device tree v3: Support multiple regulators for each chip Move most code to pmbus_core.c fixed values for on/off v4: fix a #endif comment simplify probe code, remove added switch statement remove BUG_ON(), add error message and fix num_regulators --- drivers/hwmon/pmbus/Kconfig |7 +++ drivers/hwmon/pmbus/ltc2978.c | 37 + 2 files changed, 44 insertions(+) diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig index 6e1e493..79117b7 100644 --- a/drivers/hwmon/pmbus/Kconfig +++ b/drivers/hwmon/pmbus/Kconfig @@ -56,6 +56,13 @@ config SENSORS_LTC2978 This driver can also be built as a module. If so, the module will be called ltc2978. +config SENSORS_LTC2978_REGULATOR + boolean "Regulator support for LTC2974, LTC2978, LTC3880, and LTC3883" We will need to update this and SENSORS_LTC2978 and add LTC2977 as well as LTM4646 to the list of supported chips. Guenter I will add the whole list to the 'help' sections of SENSORS_LTC2978 and SENSORS_LTC2978_REGULATOR. For the tristate/boolean lines, I can't fit the whole list, so I will leave them as they are. Or I could change to 'LTC2978 and compatibles' as many others in this Kconfig have. Yes, that makes sense. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] stagging : rtl8821ae : Fixed sparse warning
On Wed, Oct 01, 2014 at 08:15:08PM -0400, Jerry Stralko wrote:
> On 09/23/2014 07:09 PM, Jerry Stralko wrote:
> > Symbol was not declared. Should it be static?
> >
> > Signed-off-by: Jerry Stralko
> > ---
> > drivers/staging/rtl8821ae/base.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/staging/rtl8821ae/base.c
> > b/drivers/staging/rtl8821ae/base.c
> > index 4a36da0..dea3c4b 100644
> > --- a/drivers/staging/rtl8821ae/base.c
> > +++ b/drivers/staging/rtl8821ae/base.c
> > @@ -1367,7 +1367,7 @@ u8 *rtl_find_ie(u8 *data, unsigned int len, u8 ie)
> >
> > /* when we use 2 rx ants we send IEEE80211_SMPS_OFF */
> > /* when we use 1 rx ant we send IEEE80211_SMPS_STATIC */
> > -struct sk_buff *rtl_make_smps_action(struct ieee80211_hw *hw,
> > +static struct sk_buff *rtl_make_smps_action(struct ieee80211_hw *hw,
> > enum ieee80211_smps_mode smps,
> > u8 *da, u8 *bssid)
> > {
> > @@ -1540,7 +1540,7 @@ static bool rtl_chk_vendor_ouisub(struct ieee80211_hw
> > *hw,
> > return matched;
> > }
> >
> > -bool rtl_find_221_ie(struct ieee80211_hw *hw, u8 *data,
> > +static bool rtl_find_221_ie(struct ieee80211_hw *hw, u8 *data,
> > unsigned int len)
> > {
> > struct ieee80211_mgmt *mgmt = (void *)data;
>
> Ping?
This fell out of my scripts due to the misspelled subject line, sorry.
I'll queue it up when I get a chance to go through the rest of the
"staging" patches, after 3.18-rc1 is out.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Assalammu'alaikum
Please, i want to confirm if this your email address is still active,i have an important and urgent project to discuss with you. Awaiting your comfirmation. Regards Mustafa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: error trying to fetch the mpc5xxx tree
Hi Anatolij, On Wed, 1 Oct 2014 09:11:25 +0200 Anatolij Gustschin wrote: > > On Wed, 1 Oct 2014 09:01:15 +1000 > Stephen Rothwell wrote: > ... > > Attempting to fetch the mpc5xxx tree > > (git://git.denx.de/linux-2.6-agust.git#next) produces this error: > > > > fatal: Could not read from remote repository. > > > > Please make sure you have the correct access rights > > and the repository exists. > > the repository has been moved just recently. Could you please change > the linux-next tree to pull from > > git://git.denx.de/linux-denx-agust.git#next I have updated to that, thanks. -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature
Re: [PATCH v2 02/17] powerpc/cell: Move data segment faulting code out of cell platform
On Wed, 2014-10-01 at 15:23 +0530, Aneesh Kumar K.V wrote:
> Michael Neuling writes:
>
> > From: Ian Munsie
> >
> > __spu_trap_data_seg() currently contains code to determine the VSID and ESID
> > required for a particular EA and mm struct.
> >
> > This code is generically useful for other co-processors. This moves the
> > code
> > of the cell platform so it can be used by other powerpc code. It also adds
> > 1TB
> > segment handling which Cell didn't have.
> >
> > Signed-off-by: Ian Munsie
> > Signed-off-by: Michael Neuling
> > ---
> > arch/powerpc/include/asm/mmu-hash64.h | 7 -
> > arch/powerpc/mm/copro_fault.c | 48
> > ++
> > arch/powerpc/mm/slb.c | 3 ---
> > arch/powerpc/platforms/cell/spu_base.c | 41 +++--
> > 4 files changed, 58 insertions(+), 41 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/mmu-hash64.h
> > b/arch/powerpc/include/asm/mmu-hash64.h
> > index d765144..6d0b7a2 100644
> > --- a/arch/powerpc/include/asm/mmu-hash64.h
> > +++ b/arch/powerpc/include/asm/mmu-hash64.h
> > @@ -189,7 +189,12 @@ static inline unsigned int mmu_psize_to_shift(unsigned
> > int mmu_psize)
> > #define LP_MASK(i) ((0xFF >> (i)) << LP_SHIFT)
> >
> > #ifndef __ASSEMBLY__
> > -
> > +static inline int slb_vsid_shift(int ssize)
> > +{
> > + if (ssize == MMU_SEGSIZE_256M)
> > + return SLB_VSID_SHIFT;
> > + return SLB_VSID_SHIFT_1T;
> > +}
> > static inline int segment_shift(int ssize)
> > {
> > if (ssize == MMU_SEGSIZE_256M)
> > diff --git a/arch/powerpc/mm/copro_fault.c b/arch/powerpc/mm/copro_fault.c
> > index ba7df14..b865697 100644
> > --- a/arch/powerpc/mm/copro_fault.c
> > +++ b/arch/powerpc/mm/copro_fault.c
> > @@ -90,3 +90,51 @@ out_unlock:
> > return ret;
> > }
> > EXPORT_SYMBOL_GPL(copro_handle_mm_fault);
> > +
> > +int copro_data_segment(struct mm_struct *mm, u64 ea, u64 *esid, u64 *vsid)
> > +{
> > + int psize, ssize;
> > +
> > + *esid = (ea & ESID_MASK) | SLB_ESID_V;
> > +
> > + switch (REGION_ID(ea)) {
> > + case USER_REGION_ID:
> > + pr_devel("copro_data_segment: 0x%llx -- USER_REGION_ID\n", ea);
> > +#ifdef CONFIG_PPC_MM_SLICES
> > + psize = get_slice_psize(mm, ea);
> > +#else
> > + psize = mm->context.user_psize;
> > +#endif
> > + ssize = user_segment_size(ea);
> > + *vsid = (get_vsid(mm->context.id, ea, ssize)
> > +<< slb_vsid_shift(ssize)) | SLB_VSID_USER;
> > + break;
> > + case VMALLOC_REGION_ID:
> > + pr_devel("copro_data_segment: 0x%llx -- VMALLOC_REGION_ID\n",
> > ea);
> > + if (ea < VMALLOC_END)
> > + psize = mmu_vmalloc_psize;
> > + else
> > + psize = mmu_io_psize;
> > + ssize = mmu_kernel_ssize;
> > + *vsid = (get_kernel_vsid(ea, mmu_kernel_ssize)
> > +<< SLB_VSID_SHIFT) | SLB_VSID_KERNEL;
>
> why not
> *vsid = (get_kernel_vsid(ea, mmu_kernel_ssize)
><< slb_vsid_shift(ssize)) | SLB_VSID_KERNEL;
>
> for vmalloc and kernel region ? We could end up using 1T segments for kernel
> mapping too.
Yep, but I'm going to do this in patch 10 where the other optimisations
are for this.
Mikey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 02/17] powerpc/cell: Move data segment faulting code out of cell platform
On Wed, 2014-10-01 at 16:47 +1000, Michael Ellerman wrote: > On Tue, 2014-30-09 at 10:34:51 UTC, Michael Neuling wrote: > > From: Ian Munsie > > > > __spu_trap_data_seg() currently contains code to determine the VSID and ESID > > required for a particular EA and mm struct. > > > > This code is generically useful for other co-processors. This moves the > > code > > of the cell platform so it can be used by other powerpc code. It also adds > > 1TB > > segment handling which Cell didn't have. > > I'm not loving this. > > For starters the name "copro_data_segment()" doesn't contain any verbs, and it > doesn't tell me what it does. Ok. > If we give it a name that says what it does, we get > copro_get_ea_esid_and_vsid(). > Or something equally ugly. Ok > And then in patch 10 you move the bulk of the logic into calculate_vsid(). That was intentional on my part. I want this patch to be clear that we're moving this code out of cell. Then I wanted the optimisations to be in a separate patch. It does mean we touch the code twice in this series, but I was hoping it would make it easier to review. Alas. :-) > So instead can we: > - add a small helper that does the esid calculation, eg. calculate_esid() ? > - factor out the vsid logic into a helper, calculate_vsid() ? > - rework the spu code to use those, dropping __spu_trap_data_seg() > - use the helpers in the cxl code OK, I think I can do that. I might change the name to something better in this patch, but I'll leave these cleanups to the later patch 10. Mikey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] iommu/vt-d: Keep RMRR mappings around on driver unbind
On Tue, Sep 30, 2014 at 01:02:01PM +0200, Joerg Roedel wrote: > Hi, > > here is a patch-set to fix an issue recently discovered when > the Intel IOMMU is in use with devices that need RMRR > mappings. > > The problem is that the RMRR mappings are destroyed when the > device driver is unbound from the device, causing DMAR > faults. > > To solve this problem a device driver core change is > necessary to catch the right point in time for the IOMMU > code to destroy any mappings for a device. > > With this patch-set the RMRR mappings are only destroyed > when the device is actually removed from the system. > > Please review. > > Thanks, > > Joerg > > Joerg Roedel (2): > driver core: Add BUS_NOTIFY_REMOVED_DEVICE event > iommu/vt-d: Only remove domain when device is removed > > drivers/base/core.c | 3 +++ > drivers/iommu/intel-iommu.c | 11 +-- > include/linux/device.h | 11 ++- > 3 files changed, 10 insertions(+), 15 deletions(-) > > -- > 1.9.1 Joerg, I tested on HP Gen7 and Gen9 systems for which we experience dmar faults when we rmmod a driver whose device had RMRR regions associated with it. We don't see problem when patch set is applied. Thanks, Tested-by: Jerry Hoemann -- Jerry HoemannSoftware Engineer Hewlett-Packard 3404 E Harmony Rd. MS 36phone: (970) 898-1022 Ft. Collins, CO 80528 FAX:(970) 898-0707 email: jerry.hoem...@hp.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 v2] mm: softdirty: unmapped addresses between VMAs are clean
On Fri, Sep 26, 2014 at 04:33:26PM -0400, Naoya Horiguchi wrote: > Could you test and merge the following change? Many apologies for the late reply! Your email was in my spam folder :-( I see that Andrew has already merged the patch, so we're in good shape! Thanks for fixing this bug Naoya! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] stagging : rtl8821ae : Fixed sparse warning
On 09/23/2014 07:09 PM, Jerry Stralko wrote:
> Symbol was not declared. Should it be static?
>
> Signed-off-by: Jerry Stralko
> ---
> drivers/staging/rtl8821ae/base.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/rtl8821ae/base.c
> b/drivers/staging/rtl8821ae/base.c
> index 4a36da0..dea3c4b 100644
> --- a/drivers/staging/rtl8821ae/base.c
> +++ b/drivers/staging/rtl8821ae/base.c
> @@ -1367,7 +1367,7 @@ u8 *rtl_find_ie(u8 *data, unsigned int len, u8 ie)
>
> /* when we use 2 rx ants we send IEEE80211_SMPS_OFF */
> /* when we use 1 rx ant we send IEEE80211_SMPS_STATIC */
> -struct sk_buff *rtl_make_smps_action(struct ieee80211_hw *hw,
> +static struct sk_buff *rtl_make_smps_action(struct ieee80211_hw *hw,
>enum ieee80211_smps_mode smps,
>u8 *da, u8 *bssid)
> {
> @@ -1540,7 +1540,7 @@ static bool rtl_chk_vendor_ouisub(struct ieee80211_hw
> *hw,
> return matched;
> }
>
> -bool rtl_find_221_ie(struct ieee80211_hw *hw, u8 *data,
> +static bool rtl_find_221_ie(struct ieee80211_hw *hw, u8 *data,
> unsigned int len)
> {
> struct ieee80211_mgmt *mgmt = (void *)data;
Ping?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/15] Driver core: Unified device properties interface for platform firmware
On Wed, Oct 01, 2014 at 04:10:03AM +0200, Rafael J. Wysocki wrote: > From: "Rafael J. Wysocki" > > Add a uniform interface by which device drivers can request device > properties from the platform firmware by providing a property name > and the corresponding data type. The purpose of it is to help to > write portable code that won't depend on any particular platform > firmware interface. > > Three general helper functions, device_get_property(), > device_read_property() and device_read_property_array() are provided. > The first one allows the raw value of a given device property to be > accessed. The remaining two allow the value of a numeric or string > property and multiple numeric or string values of one array > property to be acquired, respectively. Static inline wrappers are also > provided for the various property data types that can be passed to > device_read_property() or device_read_property_array() for extra type > checking. > > In addition to that, new generic routines are provided for retrieving > properties from device description objects in the platform firmware > in case a device driver needs/wants to access properties of a child > object of a given device object. There are cases in which there is > no struct device representation of such child objects and this > additional API is useful then. Again, three functions are provided, > device_get_child_property(), device_read_child_property(), > device_read_child_property_array(), in analogy with device_get_property(), > device_read_property() and device_read_property_array() described above, > respectively, along with static inline wrappers for all of the propery > data types that can be used. For all of them, the first argument is > a struct device pointer to the parent device object and the second > argument is a (void *) pointer to the child description provided by > the platform firmware (either ACPI or FDT). > > Finally, device_for_each_child_node() is added for iterating over > the children of the device description object associated with a > given device. > > The interface covers both ACPI and Device Trees. > > This change set includes material from Mika Westerberg and Aaron Lu. > > Signed-off-by: Aaron Lu > Signed-off-by: Mika Westerberg > Signed-off-by: Rafael J. Wysocki > --- > > Greg, please let me know if you're fine with this one. Looks good to me: Acked-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH v1 1/2] genirq: Fix error path for resuming irqs
On Wed, 1 Oct 2014, dbasehore . wrote: > On Wed, Oct 1, 2014 at 3:30 PM, Rafael J. Wysocki wrote: Please stop top-posting and trim the quoted text. This is not your $corp mail drop. > dpm_resume_noirq is not early enough for the Xen stuff, but should be > early enough for other stuff. This patch is mostly just a bandage on > top of the broken IRQF_EARLY_RESUME code. You are getting it really backwards. The IRQF_EARLY_RESUME stuff was introduced on behalf of XEN and now you are claiming in your changelog that: > >> > >> This regression was introduced in 9bab0b7f "genirq: Add > >> > >> IRQF_RESUME_EARLY" So you are fixing a 3+ years old regression here? Do you have any prove that the code worked before that commit 9bab0b7f went in during the 3.2 merge window? No, you don't. Simply because the XEN suspend/resume stuff was not working at all before that. So it's not a regression. It either was a wrong design decision back then which did not take an error path into account or the things have changed in a way that this mechanism does not work anymore. I agree with Rafael that this should be solved differently. Though I'm not really convinced of the proposed syscore solution, simply because it will introduce another "tolerated" way for people to work around totally unrelated shortcomings of other parts of the suspend/resume machinery. You noticed yourself that > some rtc drivers started using IRQF_EARLY_RESUME. I can't think > of any reason those drivers would need to be resumed early. This > way, the flag wouldn't even be there for people to mistakenly add. Now the question is WHY XEN is so special that it needs all these extra features and mechanisms all over the place? I have not looked into the guts of XEN that deep that I can judge that and I have no intention to do so as I want to preserve my mental sanity, but I have not seen any reasonable explanation WHY: > dpm_resume_noirq is not early enough for the Xen stuff Is it just because XEN works that way and XEN folks are not willing or able to make it different? Or is there any fundamental and reasonable technical reason why XEN needs to have the extra treatment while the rest of the world does not? Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 07/12] usb: chipidea: add a usb2 driver for ci13xxx
On Tue, Sep 30, 2014 at 08:12:07AM +0800, Peter Chen wrote:
> On Tue, Sep 23, 2014 at 12:28:03PM +0200, Antoine Tenart wrote:
> > Add a USB2 ChipIdea driver for ci13xxx, with optional PHY, clock
> > and DMA mask, to support USB2 ChipIdea controllers that don't need
> > specific functions.
> >
> > Tested on the Marvell Berlin SoCs USB controllers.
> >
> > Signed-off-by: Antoine Tenart
> > ---
> > drivers/usb/chipidea/Makefile | 1 +
> > drivers/usb/chipidea/ci_hdrc_usb2.c | 138
> >
> > 2 files changed, 139 insertions(+)
> > create mode 100644 drivers/usb/chipidea/ci_hdrc_usb2.c
> >
> > diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
> > index 2f099c7df7b5..1fc86a2ca22d 100644
> > --- a/drivers/usb/chipidea/Makefile
> > +++ b/drivers/usb/chipidea/Makefile
> > @@ -10,6 +10,7 @@ ci_hdrc-$(CONFIG_USB_OTG_FSM) += otg_fsm.o
> >
> > # Glue/Bridge layers go here
> >
> > +obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_usb2.o
> > obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_msm.o
> > obj-$(CONFIG_USB_CHIPIDEA) += ci_hdrc_zevio.o
> >
> > diff --git a/drivers/usb/chipidea/ci_hdrc_usb2.c
> > b/drivers/usb/chipidea/ci_hdrc_usb2.c
> > new file mode 100644
> > index ..6eae1de587f2
> > --- /dev/null
> > +++ b/drivers/usb/chipidea/ci_hdrc_usb2.c
> > @@ -0,0 +1,138 @@
> > +/*
> > + * Copyright (C) 2014 Marvell Technology Group Ltd.
> > + *
> > + * Antoine Tenart
> > + *
> > + * This file is licensed under the terms of the GNU General Public
> > + * License version 2. This program is licensed "as is" without any
> > + * warranty of any kind, whether express or implied.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "ci.h"
> > +
> > +struct ci_hdrc_usb2_priv {
> > + struct platform_device *ci_pdev;
> > + struct clk *clk;
> > +};
> > +
> > +static int ci_hdrc_usb2_dt_probe(struct device *dev,
> > +struct ci_hdrc_platform_data *ci_pdata)
> > +{
> > + ci_pdata->phy = of_phy_get(dev->of_node, 0);
> > + if (IS_ERR(ci_pdata->phy)) {
> > + if (PTR_ERR(ci_pdata->phy) == -EPROBE_DEFER)
> > + return -EPROBE_DEFER;
> > +
> > + /* PHY is optional */
> > + ci_pdata->phy = NULL;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static struct ci_hdrc_platform_data ci_default_pdata = {
> > + .capoffset = DEF_CAPOFFSET,
> > + .flags = CI_HDRC_REQUIRE_TRANSCEIVER |
> > + CI_HDRC_DISABLE_STREAMING,
> > +};
> > +
> > +static int ci_hdrc_usb2_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = >dev;
> > + struct ci_hdrc_usb2_priv *priv;
> > + struct ci_hdrc_platform_data *ci_pdata = dev_get_platdata(>dev);
> > + int ret;
> > +
> > + if (!ci_pdata)
> > + ci_pdata = _default_pdata;
> > +
> > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > +
> > + priv->clk = devm_clk_get(dev, NULL);
> > + if (!IS_ERR(priv->clk)) {
> > + ret = clk_prepare_enable(priv->clk);
> > + if (ret) {
> > + dev_err(dev, "failed to enable the clock: %d\n", ret);
> > + return ret;
> > + }
> > + }
> > +
> > + if (dev->of_node) {
> > + ret = ci_hdrc_usb2_dt_probe(dev, ci_pdata);
> > + if (ret)
> > + goto clk_err;
> > + } else {
> > + ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(32));
> > + if (ret)
> > + goto clk_err;
> > + }
>
Hi Antoine, if you pay attention the discussion for this patch, you should
know to do change for your next revision
- Call below unconditionally:
> > + ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(32));
> > + if (ret)
> > + goto clk_err;
-Do not need function ci_hdrc_usb2_dt_probe, we need to cover
both dt and non-dt, but there is nothing we can to differentiate now,
The phy handle should be moved to core driver, since your generic phy
driver are still not accepted, I can't do it by myself. Either you or
I can do it after your generic phy support series has been accepted.
> > + ret = ci_hdrc_usb2_dt_probe(dev, ci_pdata);
- Others are ok
- The sequence of patch sets:
1. The generic PHY support for chipidea idea
2. Move getting PHY from individual glue layer to core driver
3. The generic chipidea driver
Peter
> > +
> > + ci_pdata->name = dev_name(>dev);
> > +
> > + priv->ci_pdev = ci_hdrc_add_device(dev, pdev->resource,
> > + pdev->num_resources, ci_pdata);
> > + if (IS_ERR(priv->ci_pdev)) {
> > + ret = PTR_ERR(priv->ci_pdev);
> > + if (ret != -EPROBE_DEFER)
> > + dev_err(dev,
> > +
Re: [PATCH v5] init: Allow CONFIG_INIT_FALLBACK=n to disable defaults if init= fails
On Wed, Oct 01, 2014 at 03:56:41PM -0700, Andy Lutomirski wrote:
> If a user puts init=/whatever on the command line and /whatever
> can't be run, then the kernel will try a few default options before
> giving up. If init=/whatever came from a bootloader prompt, then
> this is unexpected but probably harmless. On the other hand, if it
> comes from a script (e.g. a tool like virtme or perhaps a future
> kselftest script), then the fallbacks are likely to exist, but
> they'll do the wrong thing. For example, they might unexpectedly
> invoke systemd.
>
> This adds a config option CONFIG_INIT_FALLBACK. If unset,
> then a failure to run the specified init= process be fatal.
>
> The intent is to switch the default to N after a while and to
> possibly even remove the option entirely
>
> Signed-off-by: Andy Lutomirski
Nit: why does this patch gratuitously change the indentation of the
second line of pr_err?
That aside:
Reviewed-by: Josh Triplett
>
> Changes from v4:
> - Switch the default to y
>
> Changes from v3:
> - Get rid of the strictinit option. Now the new behavior is the default
>unless CONFIG_INIT_FALLBACK=y (Rob Landley)
>
> Changes from v2:
> - Improve docs further, to leave the door open to giving strictinit
>some sensible semantics if init= is not set.
> - Improve error output in the failure case (Shuah Khan).
>
> Changes from v1:
> - Add missing "if" to the docs (Randy Dunlap)
>
> init/Kconfig | 16
> init/main.c | 7 ++-
> 2 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/init/Kconfig b/init/Kconfig
> index e84c6423a2e5..ebbd5846478e 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1299,6 +1299,22 @@ source "usr/Kconfig"
>
> endif
>
> +config INIT_FALLBACK
> + bool "Fall back to defaults if init= parameter is bad"
> + default y
> + help
> + If enabled, the kernel will try the default init binaries if an
> + explicit request from the init= parameter fails.
> +
> + This can have unexpected effects. For example, booting
> + with init=/sbin/kiosk_app will run /sbin/init or even /bin/sh
> + if /sbin/kiosk_app cannot be executed.
> +
> + The default value of Y is consistent with historical behavior.
> + Selecting N is likely to be more appropriate for most uses,
> + especially on kiosks and on kernels that are indended to be
> + run under the control of a script.
> +
> config CC_OPTIMIZE_FOR_SIZE
> bool "Optimize for size"
> help
> diff --git a/init/main.c b/init/main.c
> index bb1aed928f21..2bd6105e5dc5 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -960,8 +960,13 @@ static int __ref kernel_init(void *unused)
> ret = run_init_process(execute_command);
> if (!ret)
> return 0;
> +#ifndef CONFIG_INIT_FALLBACK
> + panic("Requested init %s failed (error %d).",
> + execute_command, ret);
> +#else
> pr_err("Failed to execute %s (error %d). Attempting
> defaults...\n",
> - execute_command, ret);
> +execute_command, ret);
> +#endif
> }
> if (!try_to_run_init_process("/sbin/init") ||
> !try_to_run_init_process("/etc/init") ||
> --
> 1.9.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: randconfig build error with next-20141001, in drivers/i2c/algos/i2c-algo-bit.c
On 10/01/14 14:37, Jim Davis wrote: > Building with the attached random configuration file, Also: warning: (CAN_PEAK_PCIEC && SFC && IGB && VIDEO_TW68 && DRM && FB_DDC && FB_VIA) selects I2C_ALGOBIT which has unmet direct dependencies (I2C) > drivers/i2c/algos/i2c-algo-bit.c: In function ‘i2c_bit_add_bus’: > drivers/i2c/algos/i2c-algo-bit.c:658:33: error: ‘i2c_add_adapter’ > undeclared (first use in this function) > return __i2c_bit_add_bus(adap, i2c_add_adapter); > ^ > drivers/i2c/algos/i2c-algo-bit.c:658:33: note: each undeclared > identifier is reported only once for each function it appears in > drivers/i2c/algos/i2c-algo-bit.c: In function ‘i2c_bit_add_numbered_bus’: > drivers/i2c/algos/i2c-algo-bit.c:664:33: error: > ‘i2c_add_numbered_adapter’ undeclared (first use in this function) > return __i2c_bit_add_bus(adap, i2c_add_numbered_adapter); > ^ > CC net/openvswitch/actions.o > drivers/i2c/algos/i2c-algo-bit.c: In function ‘i2c_bit_add_bus’: > drivers/i2c/algos/i2c-algo-bit.c:659:1: warning: control reaches end of > non-void > function [-Wreturn-type] > } > ^ > drivers/i2c/algos/i2c-algo-bit.c: In function ‘i2c_bit_add_numbered_bus’: > drivers/i2c/algos/i2c-algo-bit.c:665:1: warning: control reaches end of > non-void > function [-Wreturn-type] > } > ^ > make[3]: *** [drivers/i2c/algos/i2c-algo-bit.o] Error 1 In drivers/media/pci/tw68/Kconfig, VIDEO_TW68 should depend on I2C in order to make it safe to select I2C_ALGOBIT. In drivers/net/can/sja1000/Kconfig, CAN_PEAK_PCIEC should depend on I2C instead of selecting I2C (and change the help text). -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] staging: Add Xilinx Clocking Wizard driver
Hi Sören,
Thank you for the patch.
On Wednesday 01 October 2014 14:02:32 Soren Brinkmann wrote:
> Add a driver for the Xilinx Clocking Wizard soft IP. The clocking wizard
> provides an AXI interface to dynamically reconfigure the clocking
> resources of Xilinx FPGAs.
>
> Signed-off-by: Soren Brinkmann
> ---
> Hi Greg, Dan,
>
> I fixed the things Dan pointed out, please take this v2 instead of the
> original patch.
>
> Also, don't get caught up too much with style issues around the code that
> registers the clocks. To support set_rate() opeartions this will have to
> change anyway. It doesn't make a lot of sense to spend much time on those
> parts.
>
> Thanks,
> Sören
>
> v2:
> - implement dev_pm_ops
> - don't use array for clock inputs
> - add more information in error output
> - fix style issues
> - fix error path
> ---
> drivers/staging/Kconfig| 2 +
> drivers/staging/Makefile | 1 +
> drivers/staging/clocking-wizard/Kconfig| 9 +
> drivers/staging/clocking-wizard/Makefile | 1 +
> drivers/staging/clocking-wizard/TODO | 12 +
> .../clocking-wizard/clk-xlnx-clock-wizard.c| 336 ++
> drivers/staging/clocking-wizard/dt-binding.txt | 30 ++
> 7 files changed, 391 insertions(+)
> create mode 100644 drivers/staging/clocking-wizard/Kconfig
> create mode 100644 drivers/staging/clocking-wizard/Makefile
> create mode 100644 drivers/staging/clocking-wizard/TODO
> create mode 100644 drivers/staging/clocking-wizard/clk-xlnx-clock-wizard.c
> create mode 100644 drivers/staging/clocking-wizard/dt-binding.txt
[snip]
> diff --git a/drivers/staging/clocking-wizard/dt-binding.txt
> b/drivers/staging/clocking-wizard/dt-binding.txt new file mode 100644
> index ..cc3cc5e91440
> --- /dev/null
> +++ b/drivers/staging/clocking-wizard/dt-binding.txt
> @@ -0,0 +1,30 @@
> +Binding for Xilinx Clocking Wizard IP Core
> +
> +This binding uses the common clock binding[1]. Details about the devices
> can be +found in the product guide[2].
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +[2] Clocking Wizard Product Guide
> +http://www.xilinx.com/support/documentation/ip_documentation/clk_wiz/v5_1/p
> g065-clk-wiz.pdf +
> +Required properties:
> + - compatible: Must be 'xlnx,clocking-wizard'
> + - reg: Base and size of the cores register space
> + - clocks: Handle to input clock
> + - clock-names: Tuple containing 'clk_in1' and 's_axi_aclk'
> + - clock-output-names: Names for the output clocks
> +
> +Optional properties:
> + - speed-grade: Speed grade of the device
You should document what values are allowed.
> +
> +Example:
> + clock-generator@4004 {
> + reg = <0x4004 0x1000>;
> + compatible = "xlnx,clocking-wizard";
> + speed-grade = <(-1)>;
Can't we make the speed grade positive ? It looks to me that the - is nowadays
a dash and not a minus sign, given that higher absolute values of the speed
grade mean faster devices. The days when the speed grate represented the
propagation time of signals in ns is long gone I suppose.
> + clock-names = "clk_in1", "s_axi_aclk";
> + clocks = < 15>, < 15>;
> + clock-output-names = "clk_out0", "clk_out1", "clk_out2",
> + "clk_out3", "clk_out4", "clk_out5",
> + "clk_out6", "clk_out7";
> + };
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] socfpga: hotplug: put cpu1 in wfi
On Wed 2014-10-01 11:07:18, Dinh Nguyen wrote:
>
>
> On 10/1/14, 10:04 AM, Pavel Machek wrote:
> > Hi!
> >
> +__raw_writel(RSTMGR_MPUMODRST_CPU1,
> + rst_manager_base_addr + 0x10);
> >>>
> >>> Would it be possible to copy reset manager description struct from
> >>> u-boot and use it here, instead of raw offset?
> >>
> >> I will replace this 0x10 with a macro that reflects how the register is
> >> named in the register map.
> >
> > That would be better than 0x10, but even better would be just copying
> >
> > struct socfpga_reset_manager {
> > u32 status;
> > u32 ctrl;
> > u32 counts;
> > u32 padding1;
> > u32 mpu_mod_reset;
> > u32 per_mod_reset;
> > u32 per2_mod_reset;
> > u32 brg_mod_reset;
> > };
> >
> > from u-boot. Unlike macros, structs have advantages that typos lead to
> > easier-to-see failure modes... (And they are easier to read/parse,
> > too).
> >
>
> Copying from uboot sounds good, but I already know that the CPU reset
> offset is different for our next SOC, Arria 10. The Arria 10 SOC should
> still be able to use the same MSL as Cyclone5 and Arria5, but with a few
> differences. One of them being, the CPU1 reset offset is at 0x20 instead
> of 0x10. So I think having a macro for this one register is a bit
> cleaner than having to define a whole new struct for Arria10.
I don't think "whole new struct" is a problem. At least it will be
plain to see what changed (which will get easily lost in ifdefs.
struct cyclone5_reset_manager {
struct socfpga_reset_manager common;
u32 brg_mod_reset;
}
struct aria10_reset_manager {
struct socfpga_reset_manager common;
char filler[0x10];
u32 brg_mod_reset;
}
if (of_machine_is_compatible("altr,socfpga-arria10"))
__raw_writel(0, (struct cyclone5_reset_manager *)
rst_manager_base_addr->brg_mod_reset));
else
__raw_writel(0, (struct aria10_reset_manager *)
rst_manager_base_addr->brg_mod_reset));
...does not sound that bad. (And you'll need some nice solution for
u-boot, anyway...)
Best regards,
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/
[PATCH] usb: storage: fix build warnings !CONFIG_PM
Functions fw5895_init() and config_autodelink_before_power_down() are used
only when CONFIG_PM is defined.
drivers/usb/storage/realtek_cr.c:699:13: warning: 'fw5895_init' defined but not
used [-Wunused-function]
drivers/usb/storage/realtek_cr.c:629:12: warning:
'config_autodelink_before_power_down' defined but not used [-Wunused-function]
Signed-off-by: Luis Henriques
---
drivers/usb/storage/realtek_cr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/storage/realtek_cr.c b/drivers/usb/storage/realtek_cr.c
index 281be56d5648..d3ba242b98e1 100644
--- a/drivers/usb/storage/realtek_cr.c
+++ b/drivers/usb/storage/realtek_cr.c
@@ -626,6 +626,7 @@ static int config_autodelink_after_power_on(struct us_data
*us)
return 0;
}
+#ifdef CONFIG_PM
static int config_autodelink_before_power_down(struct us_data *us)
{
struct rts51x_chip *chip = (struct rts51x_chip *)(us->extra);
@@ -716,6 +717,7 @@ static void fw5895_init(struct us_data *us)
}
}
}
+#endif
#ifdef CONFIG_REALTEK_AUTOPM
static void fw5895_set_mmc_wp(struct us_data *us)
--
2.1.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] binfmt_misc: drop old optimisation VERBOSE_STATUS flag
The VERBOSE_STATUS flag doesn't seem to be relevant these days. It is a
compile time flag that for sure doesn't "save 400 bytes kernel memory".
Signed-off-by: Luis Henriques
---
fs/binfmt_misc.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
index b60500300dd7..7560f89669d5 100644
--- a/fs/binfmt_misc.c
+++ b/fs/binfmt_misc.c
@@ -33,10 +33,6 @@
#include
-enum {
- VERBOSE_STATUS = 1 /* make it zero to save 400 bytes kernel memory */
-};
-
static LIST_HEAD(entries);
static int enabled = 1;
@@ -424,11 +420,6 @@ static void entry_status(Node *e, char *page)
if (test_bit(Enabled, >flags))
status = "enabled";
- if (!VERBOSE_STATUS) {
- sprintf(page, "%s\n", status);
- return;
- }
-
sprintf(page, "%s\ninterpreter %s\n", status, e->interpreter);
dp = page + strlen(page);
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] [media] pwc-if: fix build warning when !CONFIG_USB_PWC_INPUT_EVDEV
Label err_video_unreg in function usb_pwc_probe() is only used when
CONFIG_USB_PWC_INPUT_EVDEV is defined.
drivers/media/usb/pwc/pwc-if.c:1104:1: warning: label 'err_video_unreg' defined
but not used [-Wunused-label]
Signed-off-by: Luis Henriques
---
drivers/media/usb/pwc/pwc-if.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/pwc/pwc-if.c b/drivers/media/usb/pwc/pwc-if.c
index 15b754da4a2c..e6b7e63b0b8e 100644
--- a/drivers/media/usb/pwc/pwc-if.c
+++ b/drivers/media/usb/pwc/pwc-if.c
@@ -1078,7 +1078,8 @@ static int usb_pwc_probe(struct usb_interface *intf,
const struct usb_device_id
pdev->button_dev = input_allocate_device();
if (!pdev->button_dev) {
rc = -ENOMEM;
- goto err_video_unreg;
+ video_unregister_device(>vdev);
+ goto err_unregister_v4l2_dev;
}
usb_make_path(udev, pdev->button_phys, sizeof(pdev->button_phys));
@@ -1095,14 +1096,13 @@ static int usb_pwc_probe(struct usb_interface *intf,
const struct usb_device_id
if (rc) {
input_free_device(pdev->button_dev);
pdev->button_dev = NULL;
- goto err_video_unreg;
+ video_unregister_device(>vdev);
+ goto err_unregister_v4l2_dev;
}
#endif
return 0;
-err_video_unreg:
- video_unregister_device(>vdev);
err_unregister_v4l2_dev:
v4l2_device_unregister(>v4l2_dev);
err_free_controls:
--
2.1.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: [Xen-devel] [PATCH v1 1/2] genirq: Fix error path for resuming irqs
On Wednesday, October 01, 2014 04:01:33 PM dbasehore . wrote:
> dpm_resume_noirq is not early enough for the Xen stuff, but should be
> early enough for other stuff. This patch is mostly just a bandage on
> top of the broken IRQF_EARLY_RESUME code.
>
> We may consider getting rid of IRQF_EARLY_RESUME and having Xen
> register its own syscore resume function to enable whatever irq it
> needs.
I'd very much prefer that.
> I'd be fine with that since some rtc drivers started using
> IRQF_EARLY_RESUME. I can't think of any reason those drivers would
> need to be resumed early. This way, the flag wouldn't even be there
> for people to mistakenly add.
There seem to be some ordering issues they are trying to solve this way,
but I think those issues can and should be addressed differently.
> On Wed, Oct 1, 2014 at 3:30 PM, Rafael J. Wysocki wrote:
> > On Thursday, October 02, 2014 12:25:08 AM Rafael J. Wysocki wrote:
> >> On Wednesday, October 01, 2014 01:48:39 PM dbasehore . wrote:
> >> > Adding maintainers for affected systems to this CL for review.
> >> >
> >> > On Mon, Jul 7, 2014 at 8:33 AM, Konrad Rzeszutek Wilk
> >> > wrote:
> >> > > On Fri, Jun 27, 2014 at 05:04:24PM -0700, Derek Basehore wrote:
> >> > >> In the case of a late abort to suspend/hibernate, irqs marked with
> >> > >> IRQF_EARLY_RESUME will not be enabled. This is due to syscore_resume
> >> > >> not getting
> >> > >> called on these paths.
> >> > >>
> >> > >> This can happen with a pm test for platform, a late wakeup irq, and
> >> > >> other
> >> > >> instances. This change removes the function from syscore and calls it
> >> > >> explicitly
> >> > >> in suspend, hibernate, etc.
> >> > >>
> >> > >> This regression was introduced in 9bab0b7f "genirq: Add
> >> > >> IRQF_RESUME_EARLY"
> >> > >>
> >> > >> Signed-off-by: Derek Basehore
> >> > >
> >> > > Tested-by: Konrad Rzeszutek Wilk
> >> > >
> >> > > on the Xen side.
> >> > >> ---
> >> > >> drivers/base/power/main.c | 5 -
> >> > >> drivers/xen/manage.c | 5 -
> >> > >> include/linux/interrupt.h | 1 +
> >> > >> include/linux/pm.h| 2 +-
> >> > >> kernel/irq/pm.c | 17 +++--
> >> > >> kernel/kexec.c| 2 +-
> >> > >> kernel/power/hibernate.c | 6 +++---
> >> > >> kernel/power/suspend.c| 2 +-
> >> > >> 8 files changed, 18 insertions(+), 22 deletions(-)
> >> > >>
> >> > >> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> >> > >> index bf41296..a087473 100644
> >> > >> --- a/drivers/base/power/main.c
> >> > >> +++ b/drivers/base/power/main.c
> >> > >> @@ -712,8 +712,10 @@ static void dpm_resume_early(pm_message_t state)
> >> > >> * dpm_resume_start - Execute "noirq" and "early" device callbacks.
> >> > >> * @state: PM transition of the system being carried out.
> >> > >> */
> >> > >> -void dpm_resume_start(pm_message_t state)
> >> > >> +void dpm_resume_start(pm_message_t state, bool enable_early_irqs)
> >> > >> {
> >> > >> + if (enable_early_irqs)
> >> > >> + early_resume_device_irqs();
> >>
> >> This conflicts with some changes I've already queued up for merging.
> >>
> >> Why don't you do that in dpm_resume_noirq() directly? Also why do we need
> >> the extra argument here? The only case when we pass 'false' apprears to be
> >> the Xen one, so perhaps we can use a special PM_EVENT_XEN flag or something
> >> similar to indicate that? Honestly, I don't want to litter the regular
> >> suspend
> >> code with Xen-specific stuff like this.
> >
> > BTW, is dpm_resume_noirq() early enough? What about the time we bring up
> > the non-boot CPUs? Don't we need to call the early_resume_device_irqs()
> > thing before that?
> >
> >> > >> dpm_resume_noirq(state);
> >> > >> dpm_resume_early(state);
> >> > >> }
> >> > >> @@ -1132,6 +1134,7 @@ static int dpm_suspend_noirq(pm_message_t state)
> >> > >> if (error) {
> >> > >> suspend_stats.failed_suspend_noirq++;
> >> > >> dpm_save_failed_step(SUSPEND_SUSPEND_NOIRQ);
> >> > >> + early_resume_device_irqs();
> >> > >> dpm_resume_noirq(resume_event(state));
> >> > >> } else {
> >> > >> dpm_show_time(starttime, state, "noirq");
> >> > >> diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
> >> > >> index c3667b2..d387cdf 100644
> >> > >> --- a/drivers/xen/manage.c
> >> > >> +++ b/drivers/xen/manage.c
> >> > >> @@ -68,6 +68,7 @@ static int xen_suspend(void *data)
> >> > >> err = syscore_suspend();
> >> > >> if (err) {
> >> > >> pr_err("%s: system core suspend failed: %d\n",
> >> > >> __func__, err);
> >> > >> + early_resume_device_irqs();
> >> > >> return err;
> >> > >> }
> >> > >>
> >> > >> @@ -92,6 +93,8 @@ static int xen_suspend(void *data)
> >> > >> xen_timer_resume();
> >> > >> }
> >> > >>
> >> > >> + early_resume_device_irqs();
> >> > >> +
> >> > >>
[PATCH 2/5] x86/common.c: fix build warning when !CONFIG_IA32_EMULATION
Function syscall32_cpu_init() is used only when CONFIG_IA32_EMULATION is
defined.
arch/x86/kernel/cpu/common.c:968:13: warning: 'syscall32_cpu_init' defined but
not used [-Wunused-function]
Signed-off-by: Luis Henriques
---
arch/x86/kernel/cpu/common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index e4ab2b42bd6f..b7ac5404cacf 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -964,6 +964,7 @@ static void vgetcpu_set_mode(void)
vgetcpu_mode = VGETCPU_LSL;
}
+#ifdef CONFIG_IA32_EMULATION
/* May not be __init: called during resume */
static void syscall32_cpu_init(void)
{
@@ -976,6 +977,7 @@ static void syscall32_cpu_init(void)
wrmsrl(MSR_CSTAR, ia32_cstar_target);
}
#endif
+#endif
#ifdef CONFIG_X86_32
void enable_sep_cpu(void)
--
2.1.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/
[PATCHv2 1/4] target: Remove unneeded check in sbc_parse_cdb
The check of SCF_SCSI_DATA_CDB seems to be a remnant from before hch's
refactoring of this function. There are no places where that flag is set
that cmd->execute_cmd isn't also set.
Signed-off-by: Andy Grover
---
drivers/target/target_core_sbc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/target/target_core_sbc.c b/drivers/target/target_core_sbc.c
index bd78d92..ebe62af 100644
--- a/drivers/target/target_core_sbc.c
+++ b/drivers/target/target_core_sbc.c
@@ -948,7 +948,7 @@ sbc_parse_cdb(struct se_cmd *cmd, struct sbc_ops *ops)
}
/* reject any command that we don't have a handler for */
- if (!(cmd->se_cmd_flags & SCF_SCSI_DATA_CDB) && !cmd->execute_cmd)
+ if (!cmd->execute_cmd)
return TCM_UNSUPPORTED_SCSI_OPCODE;
if (cmd->se_cmd_flags & SCF_SCSI_DATA_CDB) {
--
1.9.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/
[PATCHv2 0/4] Userspace Passthrough backstore for LIO
Hi Nick and all, Here's version 2, against Nick's target-pending/for-next. Note that since that tree is still on 3.17-rc5, in testing I ran into an issue fixed by: genhd: fix leftover might_sleep() in blk_free_devt() which first appears in 3.17-rc7. Incorporates feedback from Nick. Doc fixes * add table of contents * add example code for the user-side * document specific opcodes that IO mode passes through Code fixes * add back support for PASS_ALL and PASS_IO pass_level option. * Removed retry-in-kernel mechanism * fix issues from kbuild test robot * remove kref from tcmu_dev and call kfree(udev) from tcmu_free_device instead * set hw_block_size to 512 instead of 4096 * Don't copy DMA_FROM_DEVICE data if there was a CHECK_CONDITION * use goto-style error handling in tcmu_configure_device * Check retval from genlmsg_multicast and ignore -ESRCH * properly handle if device is unconfigured in tcmu_free_device Thanks -- Andy Andy Grover (4): target: Remove unneeded check in sbc_parse_cdb uio: Export definition of struct uio_device target: Add documentation on the target userspace pass-through driver target: Add a user-passthrough backstore Documentation/target/tcmu-design.txt | 378 +++ drivers/target/Kconfig |5 + drivers/target/Makefile|1 + drivers/target/target_core_sbc.c |2 +- drivers/target/target_core_transport.c |4 + drivers/target/target_core_user.c | 1163 drivers/uio/uio.c | 12 - include/linux/uio_driver.h | 12 +- include/uapi/linux/Kbuild |1 + include/uapi/linux/target_core_user.h | 142 10 files changed, 1706 insertions(+), 14 deletions(-) create mode 100644 Documentation/target/tcmu-design.txt create mode 100644 drivers/target/target_core_user.c create mode 100644 include/uapi/linux/target_core_user.h -- 1.9.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/
[PATCHv2 4/4] target: Add a user-passthrough backstore
Add a LIO storage engine that presents commands to userspace for execution.
This would allow more complex backstores to be implemented out-of-kernel,
and also make experimentation a-la FUSE (but at the SCSI level -- "SUSE"?)
possible.
It uses a mmap()able UIO device per LUN to share a command ring and data
area. The commands are raw SCSI CDBs and iovs for in/out data. The command
ring is also reused for returning scsi command status and optional sense
data.
This implementation is based on Shaohua Li's earlier version but heavily
modified. Differences include:
* Shared memory allocated by kernel, not locked-down user pages
* Single ring for command request and response
* Offsets instead of embedded pointers
* Generic SCSI CDB passthrough instead of per-cmd specialization in ring
format.
* Uses UIO device instead of anon_file passed in mailbox.
* Optional in-kernel handling of some commands.
The main reason for these differences is to permit greater resiliency
if the user process dies or hangs.
Things not yet implemented (on purpose):
* Zero copy. The data area is flexible enough to allow page flipping or
backend-allocated pages to be used by fabrics, but it's not clear these
are performance wins. Can come later.
* Out-of-order command completion by userspace. Possible to add by just
allowing userspace to change cmd_id in rsp cmd entries, but currently
not supported.
* No locks between kernel cmd submission and completion routines. Sounds
like it's possible, but this can come later.
* Sparse allocation of mmaped area. Current code vmallocs the whole thing.
If the mapped area was larger and not fully mapped then the driver would
have more freedom to change cmd and data area sizes based on demand.
Current code open issues:
* The use of idrs may be overkill -- we maybe can replace them with a
simple counter to generate cmd_ids, and a hash table to get a cmd_id's
associated pointer.
* Use of a free-running counter for cmd ring instead of explicit modulo
math. This would require power-of-2 cmd ring size.
Signed-off-by: Andy Grover
---
drivers/target/Kconfig |5 +
drivers/target/Makefile|1 +
drivers/target/target_core_transport.c |4 +
drivers/target/target_core_user.c | 1163
include/uapi/linux/Kbuild |1 +
include/uapi/linux/target_core_user.h | 142
6 files changed, 1316 insertions(+)
create mode 100644 drivers/target/target_core_user.c
create mode 100644 include/uapi/linux/target_core_user.h
diff --git a/drivers/target/Kconfig b/drivers/target/Kconfig
index dc2d84a..b03a845 100644
--- a/drivers/target/Kconfig
+++ b/drivers/target/Kconfig
@@ -31,6 +31,11 @@ config TCM_PSCSI
Say Y here to enable the TCM/pSCSI subsystem plugin for non-buffered
passthrough access to Linux/SCSI device
+config TCM_USER
+ tristate "TCM/USER Subsystem Plugin for Linux"
+ help
+ Say Y here to enable the TCM/USER subsystem plugin
+
source "drivers/target/loopback/Kconfig"
source "drivers/target/tcm_fc/Kconfig"
source "drivers/target/iscsi/Kconfig"
diff --git a/drivers/target/Makefile b/drivers/target/Makefile
index 85b012d..bbb4a7d 100644
--- a/drivers/target/Makefile
+++ b/drivers/target/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_TARGET_CORE) += target_core_mod.o
obj-$(CONFIG_TCM_IBLOCK) += target_core_iblock.o
obj-$(CONFIG_TCM_FILEIO) += target_core_file.o
obj-$(CONFIG_TCM_PSCSI)+= target_core_pscsi.o
+obj-$(CONFIG_TCM_USER) += target_core_user.o
# Fabric modules
obj-$(CONFIG_LOOPBACK_TARGET) += loopback/
diff --git a/drivers/target/target_core_transport.c
b/drivers/target/target_core_transport.c
index 9700ea1..9ea0d5f 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -232,6 +232,10 @@ void transport_subsystem_check_init(void)
if (ret != 0)
pr_err("Unable to load target_core_pscsi\n");
+ ret = request_module("target_core_user");
+ if (ret != 0)
+ pr_err("Unable to load target_core_user\n");
+
sub_api_initialized = 1;
}
diff --git a/drivers/target/target_core_user.c
b/drivers/target/target_core_user.c
new file mode 100644
index 000..6608ecf
--- /dev/null
+++ b/drivers/target/target_core_user.c
@@ -0,0 +1,1163 @@
+/*
+ * Copyright (C) 2013 Shaohua Li
+ * Copyright (C) 2014 Red Hat, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General
[PATCHv2 3/4] target: Add documentation on the target userspace pass-through driver
Describes the driver and its interface to make it possible for user
programs to back a LIO-exported LUN.
Thanks to Richard W. M. Jones for review, and supplementing this doc
with the first two paragraphs.
Signed-off-by: Andy Grover
---
Documentation/target/tcmu-design.txt | 378 +++
1 file changed, 378 insertions(+)
create mode 100644 Documentation/target/tcmu-design.txt
diff --git a/Documentation/target/tcmu-design.txt
b/Documentation/target/tcmu-design.txt
new file mode 100644
index 000..5518465
--- /dev/null
+++ b/Documentation/target/tcmu-design.txt
@@ -0,0 +1,378 @@
+Contents:
+
+1) TCM Userspace Design
+ a) Background
+ b) Benefits
+ c) Design constraints
+ d) Implementation overview
+ i. Mailbox
+ ii. Command ring
+ iii. Data Area
+ e) Device discovery
+ f) Device events
+ g) Other contingencies
+2) Writing a user pass-through handler
+ a) Discovering and configuring TCMU uio devices
+ b) Waiting for events on the device(s)
+ c) Managing the command ring
+3) Command filtering and pass_level
+4) A final note
+
+
+TCM Userspace Design
+
+
+TCM is another name for LIO, an in-kernel iSCSI target (server).
+Existing TCM targets run in the kernel. TCMU (TCM in Userspace)
+allows userspace programs to be written which act as iSCSI targets.
+This document describes the design.
+
+The existing kernel provides modules for different SCSI transport
+protocols. TCM also modularizes the data storage. There are existing
+modules for file, block device, RAM or using another SCSI device as
+storage. These are called "backstores" or "storage engines". These
+built-in modules are implemented entirely as kernel code.
+
+Background:
+
+In addition to modularizing the transport protocol used for carrying
+SCSI commands ("fabrics"), the Linux kernel target, LIO, also modularizes
+the actual data storage as well. These are referred to as "backstores"
+or "storage engines". The target comes with backstores that allow a
+file, a block device, RAM, or another SCSI device to be used for the
+local storage needed for the exported SCSI LUN. Like the rest of LIO,
+these are implemented entirely as kernel code.
+
+These backstores cover the most common use cases, but not all. One new
+use case that other non-kernel target solutions, such as tgt, are able
+to support is using Gluster's GLFS or Ceph's RBD as a backstore. The
+target then serves as a translator, allowing initiators to store data
+in these non-traditional networked storage systems, while still only
+using standard protocols themselves.
+
+If the target is a userspace process, supporting these is easy. tgt,
+for example, needs only a small adapter module for each, because the
+modules just use the available userspace libraries for RBD and GLFS.
+
+Adding support for these backstores in LIO is considerably more
+difficult, because LIO is entirely kernel code. Instead of undertaking
+the significant work to port the GLFS or RBD APIs and protocols to the
+kernel, another approach is to create a userspace pass-through
+backstore for LIO, "TCMU".
+
+
+Benefits:
+
+In addition to allowing relatively easy support for RBD and GLFS, TCMU
+will also allow easier development of new backstores. TCMU combines
+with the LIO loopback fabric to become something similar to FUSE
+(Filesystem in Userspace), but at the SCSI layer instead of the
+filesystem layer. A SUSE, if you will.
+
+The disadvantage is there are more distinct components to configure, and
+potentially to malfunction. This is unavoidable, but hopefully not
+fatal if we're careful to keep things as simple as possible.
+
+Design constraints:
+
+- Good performance: high throughput, low latency
+- Cleanly handle if userspace:
+ 1) never attaches
+ 2) hangs
+ 3) dies
+ 4) misbehaves
+- Allow future flexibility in user & kernel implementations
+- Be reasonably memory-efficient
+- Simple to configure & run
+- Simple to write a userspace backend
+
+
+Implementation overview:
+
+The core of the TCMU interface is a memory region that is shared
+between kernel and userspace. Within this region is: a control area
+(mailbox); a lockless producer/consumer circular buffer for commands
+to be passed up, and status returned; and an in/out data buffer area.
+
+TCMU uses the pre-existing UIO subsystem. UIO allows device driver
+development in userspace, and this is conceptually very close to the
+TCMU use case, except instead of a physical device, TCMU implements a
+memory-mapped layout designed for SCSI commands. Using UIO also
+benefits TCMU by handling device introspection (e.g. a way for
+userspace to determine how large the shared region is) and signaling
+mechanisms in both directions.
+
+There are no embedded pointers in the memory region. Everything is
+expressed as an offset from the region's starting address. This allows
+the ring to still work if the user process dies and is restarted with
+the region mapped at a different virtual
[PATCHv2 2/4] uio: Export definition of struct uio_device
In order to prevent a O(n) search of the filesystem to link up its uio
node with its target configuration, TCMU needs to know the minor number
that UIO assigned. Expose the definition of this struct so TCMU can
access this field.
Signed-off-by: Andy Grover
---
drivers/uio/uio.c | 12
include/linux/uio_driver.h | 12 +++-
2 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index a673e5b..60fa627 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -28,18 +28,6 @@
#define UIO_MAX_DEVICES(1U << MINORBITS)
-struct uio_device {
- struct module *owner;
- struct device *dev;
- int minor;
- atomic_tevent;
- struct fasync_struct*async_queue;
- wait_queue_head_t wait;
- struct uio_info *info;
- struct kobject *map_dir;
- struct kobject *portio_dir;
-};
-
static int uio_major;
static struct cdev *uio_cdev;
static DEFINE_IDR(uio_idr);
diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
index 1ad4724..baa8171 100644
--- a/include/linux/uio_driver.h
+++ b/include/linux/uio_driver.h
@@ -63,7 +63,17 @@ struct uio_port {
#define MAX_UIO_PORT_REGIONS 5
-struct uio_device;
+struct uio_device {
+struct module *owner;
+struct device *dev;
+int minor;
+atomic_tevent;
+struct fasync_struct*async_queue;
+wait_queue_head_t wait;
+struct uio_info *info;
+struct kobject *map_dir;
+struct kobject *portio_dir;
+};
/**
* struct uio_info - UIO device capabilities
--
1.9.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] acct: fix build warning when ACCT_VERSION != 3
struct pid_namespace *ns is used only when ACCT_VERSION is 3. kernel/acct.c:475:24: warning: unused variable 'ns' [-Wunused-variable] Signed-off-by: Luis Henriques --- kernel/acct.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/acct.c b/kernel/acct.c index b4c667d22e79..5f277f5c5e29 100644 --- a/kernel/acct.c +++ b/kernel/acct.c @@ -472,7 +472,9 @@ static void do_acct_process(struct bsd_acct_struct *acct) acct_t ac; unsigned long flim; const struct cred *orig_cred; +#if ACCT_VERSION == 3 struct pid_namespace *ns = acct->ns; +#endif struct file *file = acct->file; /* -- 2.1.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: [Xen-devel] [PATCH v1 1/2] genirq: Fix error path for resuming irqs
dpm_resume_noirq is not early enough for the Xen stuff, but should be
early enough for other stuff. This patch is mostly just a bandage on
top of the broken IRQF_EARLY_RESUME code.
We may consider getting rid of IRQF_EARLY_RESUME and having Xen
register its own syscore resume function to enable whatever irq it
needs. I'd be fine with that since some rtc drivers started using
IRQF_EARLY_RESUME. I can't think of any reason those drivers would
need to be resumed early. This way, the flag wouldn't even be there
for people to mistakenly add.
On Wed, Oct 1, 2014 at 3:30 PM, Rafael J. Wysocki wrote:
> On Thursday, October 02, 2014 12:25:08 AM Rafael J. Wysocki wrote:
>> On Wednesday, October 01, 2014 01:48:39 PM dbasehore . wrote:
>> > Adding maintainers for affected systems to this CL for review.
>> >
>> > On Mon, Jul 7, 2014 at 8:33 AM, Konrad Rzeszutek Wilk
>> > wrote:
>> > > On Fri, Jun 27, 2014 at 05:04:24PM -0700, Derek Basehore wrote:
>> > >> In the case of a late abort to suspend/hibernate, irqs marked with
>> > >> IRQF_EARLY_RESUME will not be enabled. This is due to syscore_resume
>> > >> not getting
>> > >> called on these paths.
>> > >>
>> > >> This can happen with a pm test for platform, a late wakeup irq, and
>> > >> other
>> > >> instances. This change removes the function from syscore and calls it
>> > >> explicitly
>> > >> in suspend, hibernate, etc.
>> > >>
>> > >> This regression was introduced in 9bab0b7f "genirq: Add
>> > >> IRQF_RESUME_EARLY"
>> > >>
>> > >> Signed-off-by: Derek Basehore
>> > >
>> > > Tested-by: Konrad Rzeszutek Wilk
>> > >
>> > > on the Xen side.
>> > >> ---
>> > >> drivers/base/power/main.c | 5 -
>> > >> drivers/xen/manage.c | 5 -
>> > >> include/linux/interrupt.h | 1 +
>> > >> include/linux/pm.h| 2 +-
>> > >> kernel/irq/pm.c | 17 +++--
>> > >> kernel/kexec.c| 2 +-
>> > >> kernel/power/hibernate.c | 6 +++---
>> > >> kernel/power/suspend.c| 2 +-
>> > >> 8 files changed, 18 insertions(+), 22 deletions(-)
>> > >>
>> > >> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
>> > >> index bf41296..a087473 100644
>> > >> --- a/drivers/base/power/main.c
>> > >> +++ b/drivers/base/power/main.c
>> > >> @@ -712,8 +712,10 @@ static void dpm_resume_early(pm_message_t state)
>> > >> * dpm_resume_start - Execute "noirq" and "early" device callbacks.
>> > >> * @state: PM transition of the system being carried out.
>> > >> */
>> > >> -void dpm_resume_start(pm_message_t state)
>> > >> +void dpm_resume_start(pm_message_t state, bool enable_early_irqs)
>> > >> {
>> > >> + if (enable_early_irqs)
>> > >> + early_resume_device_irqs();
>>
>> This conflicts with some changes I've already queued up for merging.
>>
>> Why don't you do that in dpm_resume_noirq() directly? Also why do we need
>> the extra argument here? The only case when we pass 'false' apprears to be
>> the Xen one, so perhaps we can use a special PM_EVENT_XEN flag or something
>> similar to indicate that? Honestly, I don't want to litter the regular
>> suspend
>> code with Xen-specific stuff like this.
>
> BTW, is dpm_resume_noirq() early enough? What about the time we bring up
> the non-boot CPUs? Don't we need to call the early_resume_device_irqs()
> thing before that?
>
>> > >> dpm_resume_noirq(state);
>> > >> dpm_resume_early(state);
>> > >> }
>> > >> @@ -1132,6 +1134,7 @@ static int dpm_suspend_noirq(pm_message_t state)
>> > >> if (error) {
>> > >> suspend_stats.failed_suspend_noirq++;
>> > >> dpm_save_failed_step(SUSPEND_SUSPEND_NOIRQ);
>> > >> + early_resume_device_irqs();
>> > >> dpm_resume_noirq(resume_event(state));
>> > >> } else {
>> > >> dpm_show_time(starttime, state, "noirq");
>> > >> diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
>> > >> index c3667b2..d387cdf 100644
>> > >> --- a/drivers/xen/manage.c
>> > >> +++ b/drivers/xen/manage.c
>> > >> @@ -68,6 +68,7 @@ static int xen_suspend(void *data)
>> > >> err = syscore_suspend();
>> > >> if (err) {
>> > >> pr_err("%s: system core suspend failed: %d\n", __func__,
>> > >> err);
>> > >> + early_resume_device_irqs();
>> > >> return err;
>> > >> }
>> > >>
>> > >> @@ -92,6 +93,8 @@ static int xen_suspend(void *data)
>> > >> xen_timer_resume();
>> > >> }
>> > >>
>> > >> + early_resume_device_irqs();
>> > >> +
>> > >> syscore_resume();
>> > >>
>> > >> return 0;
>> > >> @@ -137,7 +140,7 @@ static void do_suspend(void)
>> > >>
>> > >> raw_notifier_call_chain(_resume_notifier, 0, NULL);
>> > >>
>> > >> - dpm_resume_start(si.cancelled ? PMSG_THAW : PMSG_RESTORE);
>> > >> + dpm_resume_start(si.cancelled ? PMSG_THAW : PMSG_RESTORE, false);
>> > >>
>> > >> if (err) {
>> > >> pr_err("failed to start xen_suspend: %d\n", err);
>>
[PATCH v5] init: Allow CONFIG_INIT_FALLBACK=n to disable defaults if init= fails
If a user puts init=/whatever on the command line and /whatever
can't be run, then the kernel will try a few default options before
giving up. If init=/whatever came from a bootloader prompt, then
this is unexpected but probably harmless. On the other hand, if it
comes from a script (e.g. a tool like virtme or perhaps a future
kselftest script), then the fallbacks are likely to exist, but
they'll do the wrong thing. For example, they might unexpectedly
invoke systemd.
This adds a config option CONFIG_INIT_FALLBACK. If unset,
then a failure to run the specified init= process be fatal.
The intent is to switch the default to N after a while and to
possibly even remove the option entirely
Signed-off-by: Andy Lutomirski
---
Changes from v4:
- Switch the default to y
Changes from v3:
- Get rid of the strictinit option. Now the new behavior is the default
unless CONFIG_INIT_FALLBACK=y (Rob Landley)
Changes from v2:
- Improve docs further, to leave the door open to giving strictinit
some sensible semantics if init= is not set.
- Improve error output in the failure case (Shuah Khan).
Changes from v1:
- Add missing "if" to the docs (Randy Dunlap)
init/Kconfig | 16
init/main.c | 7 ++-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/init/Kconfig b/init/Kconfig
index e84c6423a2e5..ebbd5846478e 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1299,6 +1299,22 @@ source "usr/Kconfig"
endif
+config INIT_FALLBACK
+ bool "Fall back to defaults if init= parameter is bad"
+ default y
+ help
+ If enabled, the kernel will try the default init binaries if an
+ explicit request from the init= parameter fails.
+
+ This can have unexpected effects. For example, booting
+ with init=/sbin/kiosk_app will run /sbin/init or even /bin/sh
+ if /sbin/kiosk_app cannot be executed.
+
+ The default value of Y is consistent with historical behavior.
+ Selecting N is likely to be more appropriate for most uses,
+ especially on kiosks and on kernels that are indended to be
+ run under the control of a script.
+
config CC_OPTIMIZE_FOR_SIZE
bool "Optimize for size"
help
diff --git a/init/main.c b/init/main.c
index bb1aed928f21..2bd6105e5dc5 100644
--- a/init/main.c
+++ b/init/main.c
@@ -960,8 +960,13 @@ static int __ref kernel_init(void *unused)
ret = run_init_process(execute_command);
if (!ret)
return 0;
+#ifndef CONFIG_INIT_FALLBACK
+ panic("Requested init %s failed (error %d).",
+ execute_command, ret);
+#else
pr_err("Failed to execute %s (error %d). Attempting
defaults...\n",
- execute_command, ret);
+ execute_command, ret);
+#endif
}
if (!try_to_run_init_process("/sbin/init") ||
!try_to_run_init_process("/etc/init") ||
--
1.9.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: linux-next: manual merge of the vfio tree with the pci tree
Hi Alex,
On Wed, 01 Oct 2014 11:06:14 -0600 Alex Williamson
wrote:
>
> On Wed, 2014-10-01 at 13:14 +1000, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the vfio tree got a conflict in
> > drivers/pci/msi.c between commits a160fe94cb53 ("PCI/MSI: Remove unused
> > get_cached_msi_msg()") and 18ef822c59f6 ("PCI/MSI: Rename
> > __get_cached_msi_msg() to get_cached_msi_msg()") from the pci tree and
> > commit 3b307ffe3faa ("PCI: Export MSI message relevant functions") from
> > the vfio tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary (no action
> > is required). And then I added this merge fix patch (I should probably
> > also have added an include of linux/irq.h):
>
> Thanks for the heads-up and manual merge. I've reviewed the changes to
> the MSI API that got us into this conflict and I disagree with them.
> I've posted a series to revert a selection of changes currently coming
> in through pci/next that should make for a clean merge should Bjorn come
> to the same conclusion. If you need to re-apply the fix in the
> meantime, please do include since it generated a build
> failure on arm without it. Thanks!
Seems Bjorn has removed the conflicting commits from the pci tree.
Thanks.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH] i2c: rk3x: fix 0 length write transfers
Alex,
On Wed, Oct 1, 2014 at 10:40 AM, Alexandru M Stan wrote:
> i2cdetect -q was broken (everything was a false positive, and no transfers
> were
> actually being sent over i2c). The way it works is by sending a 0 length write
> request and checking for NACK. This patch fixes the 0 length writes and
> actually
> sends them.
>
> Reported-by: Doug Anderson
> Signed-off-by: Alexandru M Stan
> ---
> drivers/i2c/busses/i2c-rk3x.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
> index b41d979..f486d0e 100644
> --- a/drivers/i2c/busses/i2c-rk3x.c
> +++ b/drivers/i2c/busses/i2c-rk3x.c
> @@ -238,7 +238,7 @@ static void rk3x_i2c_fill_transmit_buf(struct rk3x_i2c
> *i2c)
> for (i = 0; i < 8; ++i) {
> val = 0;
> for (j = 0; j < 4; ++j) {
> - if (i2c->processed == i2c->msg->len)
> + if ((i2c->processed == i2c->msg->len) && (cnt != 0))
This looks good to me. Basically we still need to write the address
of the device onto the bus even if there's no data.
Reviewed-by: Doug Anderson
Tested-by: Doug Anderson
-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] fork.c: copy_process(): fix cleanup WRT perf_event_free_task()
On Mon, 29 Sep 2014 16:00:48 +0200 Peter Zijlstra wrote: > On Mon, Sep 29, 2014 at 02:07:22PM +0200, Ingo Molnar wrote: > > > > * Peter Zijlstra wrote: > > > > > Subject: perf: Fix perf bug in fork() > > > > > > Oleg noticed that a cleanup by Sylvain actually uncovered a bug; by > > > calling perf_event_free_task() when failing sched_fork() we will not yet > > > have done the memset() on ->perf_event_ctxp[] and will therefore try and > > > 'free' the inherited contexts, which are still in use by the parent > > > process. This is bad.. > > > > > > Suggested-by: Oleg Nesterov > > > Reported-by: Oleg Nesterov > > > Reported-by: Sylvain 'ythier' Hitier > > > Signed-off-by: Peter Zijlstra (Intel) > > > > Could this fix a couple of fuzzer triggered perf crashes perhaps? > > It could indeed I suppose.. you never know what paths those fuzzers > manage to hit. The patch isn't in linux-next and didn't cc stable. I think I'll squirt it Linuswards later this week unless someone stops me.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: pipe/page fault oddness.
On Wed, Oct 1, 2014 at 3:08 PM, Sasha Levin wrote: > > I've tried this patch on the same configuration that was triggering > the VM_BUG_ON that Hugh mentioned previously. Surprisingly enough it > ran fine for ~20 minutes before exploding with: Well, that's somewhat encouraging. I didn't expect it to be perfect. That said, "ran fine" isn't necessarily the same thing as "worked". Who knows how buggy it was without showing overt symptoms until the BUG_ON() triggered. But hey, I'll be optimistic. > [ 2781.566206] kernel BUG at mm/huge_memory.c:1293! So that's BUG_ON(is_huge_zero_page(page)); and the reason is trivial: the old code used to have a magical special case for the zero-page hugepage (see change_huge_pmd()) and I got rid of that (because now it's just about setting protections, and the zero-page hugepage is in no way special. So I think the solution is equally trivial: just accept that the zero-page can happen, and ignore it (just un-numa it). Appended is a incremental diff on top of the previous one. Even less tested than the last case, but I think you get the idea if it doesn't work as-is. Linus diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 14de54af6c38..fc33952d59c4 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1290,7 +1290,9 @@ int do_huge_pmd_numa_page(struct mm_struct *mm, struct vm_area_struct *vma, } page = pmd_page(pmd); - BUG_ON(is_huge_zero_page(page)); + if (is_huge_zero_page(page)) + goto huge_zero_page; + page_nid = page_to_nid(page); last_cpupid = page_cpupid_last(page); count_vm_numa_event(NUMA_HINT_FAULTS); @@ -1381,6 +1383,11 @@ out: task_numa_fault(last_cpupid, page_nid, HPAGE_PMD_NR, flags); return 0; +huge_zero_page: + pmd = pmd_modify(pmd, vma->vm_page_prot); + set_pmd_at(mm, haddr, pmdp, pmd); + update_mmu_cache_pmd(vma, addr, pmdp); + goto out_unlock; } int zap_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma,
Re: [PATCH v5] init: Disable defaults if init= fails
On Wed, Oct 01, 2014 at 11:13:14AM -0700, Andy Lutomirski wrote: > On Wed, Oct 1, 2014 at 11:05 AM, wrote: > > On Tue, Sep 30, 2014 at 09:53:56PM -0700, Andy Lutomirski wrote: > >> I significantly prefer default N. Scripts that play with init= really > >> don't want the fallback, and I can imagine contexts in which it could > >> be a security problem. > > > > While I certainly would prefer the non-fallback behavior for init as > > well, standard kernel practice has typically been to use "default y" for > > previously built-in features that become configurable. And I'd > > certainly prefer a compile-time configuration option like this (even > > with default y) over a "strictinit" kernel command-line option. > > Fair enough. > > So: "default y" for a release or two, then switch the default? Default y for a few releases, get it on the radar of various distributions so they make an explicit decision about it, then consider changing the upstream default. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/15] Driver core: Unified device properties interface for platform firmware
On Thursday, October 02, 2014 12:09:44 AM Rafael J. Wysocki wrote:
> On Wednesday, October 01, 2014 09:47:40 AM Arnd Bergmann wrote:
> > On Wednesday 01 October 2014 04:10:03 Rafael J. Wysocki wrote:
> > > From: "Rafael J. Wysocki"
> > >
> > > Add a uniform interface by which device drivers can request device
> > > properties from the platform firmware by providing a property name
> > > and the corresponding data type. The purpose of it is to help to
> > > write portable code that won't depend on any particular platform
> > > firmware interface.
> > >
> > > Three general helper functions, device_get_property(),
> > > device_read_property() and device_read_property_array() are provided.
> > > The first one allows the raw value of a given device property to be
> > > accessed. The remaining two allow the value of a numeric or string
> > > property and multiple numeric or string values of one array
> > > property to be acquired, respectively. Static inline wrappers are also
> > > provided for the various property data types that can be passed to
> > > device_read_property() or device_read_property_array() for extra type
> > > checking.
> >
> > These look great!
> >
> > > In addition to that, new generic routines are provided for retrieving
> > > properties from device description objects in the platform firmware
> > > in case a device driver needs/wants to access properties of a child
> > > object of a given device object. There are cases in which there is
> > > no struct device representation of such child objects and this
> > > additional API is useful then. Again, three functions are provided,
> > > device_get_child_property(), device_read_child_property(),
> > > device_read_child_property_array(), in analogy with device_get_property(),
> > > device_read_property() and device_read_property_array() described above,
> > > respectively, along with static inline wrappers for all of the propery
> > > data types that can be used. For all of them, the first argument is
> > > a struct device pointer to the parent device object and the second
> > > argument is a (void *) pointer to the child description provided by
> > > the platform firmware (either ACPI or FDT).
> >
> > I still have my reservations against the child accessors, and would
> > like to hear what other people think. Passing a void pointer rather
> > than struct fw_dev_node has both advantages and disadvantages, and
> > I won't complain about either one if enough other people on the DT
> > side would like to see the addition of the child functions.
>
> I actually would rather like to know if the people on the DT side have any
> problems with the child functions.
>
> Because, suppose that they wouldn't like those functions at all. What are we
> supposed to do, then, honestly? Add the whole DT vs ACPI logic to the
> leds-gpio
> and gpio_keys_polled drivers? But these drivers have no reason whatsoever
> to include that. Zero.
>
> So suggestions welcome.
>
> [BTW, In principle we also could use something like
>
> typedef union dev_node {
> struct acpi_device *acpi_node;
> struct device_node *of_node;
> } dev_node_t;
>
> instead of the (void *) for more type safety. It still is useful to pass the
> parent pointer along with that, though.]
>
> > > Finally, device_for_each_child_node() is added for iterating over
> > > the children of the device description object associated with a
> > > given device.
> > >
> > > The interface covers both ACPI and Device Trees.
> > >
> > > This change set includes material from Mika Westerberg and Aaron Lu.
> > >
> >
> > Regarding device_for_each_child_node(), the syntax is inconsistent
> > with what we normally use, which can probably be changed. All of the
> > DT for_each_* helpers are macros that are used like
> >
> > struct device *dev = ...;
> > void *child; /* iterator */
> >
> > device_for_each_child_node(dev, child) {
> > u32 something;
> > device_child_property_read_u32(dev, child, "propname",
> > );
> >
> > do_something(dev, something);
> > }
> >
> > If we get a consensus on having the child interfaces, I'd rather see
> > them done this way than with a callback pointer, for consistency
> > reasons.
>
> That certainly is doable, although the resulting macro would generate a rather
> large chunk of code each time it is used.
On a second thought I'm not so sure, because we need to iterate either this
way or that way depending on a condition evaluated at run time. I have no
idea how to do that in a macro at the moment.
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 3/5] amd64_edac: enforce synchronous probe
On Tue, Sep 30, 2014 at 09:23:28AM +0200, Luis R. Rodriguez wrote:
> On Sun, Sep 28, 2014 at 10:41:23AM -0400, Tejun Heo wrote:
> > On Fri, Sep 26, 2014 at 02:57:15PM -0700, Luis R. Rodriguez wrote:
> > ...
> > > [ 14.414746] [] ? dump_stack+0x41/0x51
> > > [ 14.414790] [] ? warn_slowpath_common+0x72/0x90
> > > [ 14.414834] [] ? warn_slowpath_fmt+0x47/0x50
> > > [ 14.414880] [] ? printk+0x4f/0x51
> > > [ 14.414921] [] ? kernfs_remove_by_name_ns+0x83/0x90
> > > [ 14.415000] [] ? driver_sysfs_remove+0x1d/0x40
> > > [ 14.415046] [] ? driver_probe_device+0x1d5/0x250
> > > [ 14.415099] [] ? __driver_attach+0x7b/0x80
> > > [ 14.415149] [] ? __device_attach+0x40/0x40
> > > [ 14.415204] [] ? bus_for_each_dev+0x53/0x90
> > > [ 14.415254] [] ? driver_attach_workfn+0x13/0x80
> > > [ 14.415298] [] ? process_one_work+0x143/0x3c0
> > > [ 14.415342] [] ? worker_thread+0x114/0x480
> > > [ 14.415384] [] ? rescuer_thread+0x2b0/0x2b0
> > > [ 14.415427] [] ? kthread+0xc1/0xe0
> > > [ 14.415468] [] ? kthread_create_on_node+0x170/0x170
> > > [ 14.415511] [] ? ret_from_fork+0x7c/0xb0
> > > [ 14.415554] [] ? kthread_create_on_node+0x170/0x170
> >
> > Do you have CONFIG_FRAME_POINTER turned off?
>
> Yeah..
So the above warn came from having DWARF2 EH-frame based stack unwinding
but no CONFIG_FRAME_POINTER. By enabling CONFIG_FRAME_POINTER *and*
removing the DWARF2 EH-frame based stack unwinding patches the warning
I get is slightly different:
[ 13.208930] EDAC MC: Ver: 3.0.0
[ 13.213807] MCE: In-kernel MCE decoding enabled.
[ 13.235121] AMD64 EDAC driver v3.4.0
[ 13.235170] bus: 'pci': probe for driver amd64_edac is run asynchronously
[ 13.235236] [ cut here ]
[ 13.235283] WARNING: CPU: 2 PID: 127 at fs/kernfs/dir.c:377
kernfs_get+0x31/0x40()
[ 13.235323] Modules linked in: amd64_edac_mod(-) lrw serio_raw gf128mul
edac_mce_amd glue_helper edac_core sp5100_tco pcspkr snd_timer i2c_piix4
k10temp fam15h_power snd soundcore i2c_core wmi button xen_acpi_processor
processor thermal_sys xen_pciback xen_netback xen_blkback xen_gntalloc
xen_gntdev xen_evtchn loop fuse autofs4 ext4 crc16 mbcache jbd2 sg sd_mod
crc_t10dif crct10dif_generic crct10dif_common hid_logitech_dj usbhid hid dm_mod
ahci xhci_hcd ohci_pci libahci ohci_hcd ehci_pci ehci_hcd libata usbcore
scsi_mod r8169 usb_common mii
[ 13.237129] CPU: 2 PID: 127 Comm: kworker/u16:5 Not tainted 3.17.0-rc7+ #2
[ 13.237165] Hardware name: To be filled by O.E.M. To be filled by
O.E.M./M5A97, BIOS 1605 10/25/2012
[ 13.237207] Workqueue: events_unbound driver_attach_workfn
[ 13.237271] 0009 88040a7e7c48 814f7f1f
[ 13.237426] 88040a7e7c80 81066378 880409a63be0
88040a259a78
[ 13.237582] 880409a63be0 880409a63be0 88040f15cf00
88040a7e7c90
[ 13.237740] Call Trace:
[ 13.23] [] dump_stack+0x45/0x56
[ 13.237814] [] warn_slowpath_common+0x78/0xa0
[ 13.237851] [] warn_slowpath_null+0x15/0x20
[ 13.237887] [] kernfs_get+0x31/0x40
[ 13.237950] [] kernfs_new_node+0x31/0x40
[ 13.238003] [] kernfs_create_link+0x1e/0x80
[ 13.238052] [] sysfs_do_create_link_sd.isra.2+0x5a/0xb0
[ 13.238097] [] sysfs_create_link+0x20/0x40
[ 13.238143] [] driver_sysfs_add+0x50/0xb0
[ 13.238216] [] driver_probe_device+0x59/0x250
[ 13.238253] [] __driver_attach+0x8b/0x90
[ 13.238290] [] ? __device_attach+0x40/0x40
[ 13.238327] [] bus_for_each_dev+0x63/0xa0
[ 13.238367] [] driver_attach+0x19/0x20
[ 13.238409] [] driver_attach_workfn+0x18/0x80
[ 13.238446] [] process_one_work+0x14f/0x400
[ 13.238482] [] worker_thread+0x6b/0x4b0
[ 13.238519] [] ? rescuer_thread+0x270/0x270
[ 13.238556] [] kthread+0xd6/0xf0
[ 13.238592] [] ? kthread_create_on_node+0x180/0x180
[ 13.238630] [] ret_from_fork+0x7c/0xb0
[ 13.238666] [] ? kthread_create_on_node+0x180/0x180
[ 13.238702] ---[ end trace bfbfc1541fcb030e ]---
[ 13.238739] really_probe: driver_sysfs_add(:00:18.2) failed
[ 13.238776] amd64_edac: probe of :00:18.2 failed with error 0
[ 13.299111] AVX version of gcm_enc/dec engaged.
[ 13.312828] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni)
I tried looking into this but a later in a later kernel I had enabled
a few other things I had forgotten (like acpi thermal stuff) and then
the kernel just spewed out similar error and unfortunately I was not
able to capture the top but it all seemed related to the above.
I decided to try this:
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index dc997ae..f8bf000 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2872,7 +2872,6 @@ static struct pci_driver amd64_pci_driver = {
.probe = probe_one_instance,
.remove = remove_one_instance,
.id_table = amd64_pci_table,
- .driver.sync_probe = true,
};
static void
Re: [PATCHv8.1] fanotify: enable close-on-exec on events' fd when requested in fanotify_init()
On Mon, 29 Sep 2014 10:49:15 +0200 Yann Droneaud wrote:
> According to commit 80af258867648 ('fanotify: groups can specify
> their f_flags for new fd'), file descriptors created as part of
> file access notification events inherit flags from the
> event_f_flags argument passed to syscall fanotify_init(2).
>
> So while it is legal for userspace to call fanotify_init() with
> O_CLOEXEC as part of its second argument, O_CLOEXEC is currently
> silently ignored.
>
> Indeed event_f_flags are only given to dentry_open(), which only
> seems to care about O_ACCMODE and O_PATH in do_dentry_open(),
> O_DIRECT in open_check_o_direct() and O_LARGEFILE in
> generic_file_open().
>
> But it seems logical to set close-on-exec flag on the file
> descriptor if userspace is allowed to request it with O_CLOEXEC.
>
> In fact, according to some lookup on http://codesearch.debian.net/
> and various search engine, there's already some userspace code
> requesting it:
>
> - in systemd's readahead[2]:
>
> fanotify_fd = fanotify_init(FAN_CLOEXEC|FAN_NONBLOCK,
> O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_NOATIME);
>
> - in clsync[3]:
>
> #define FANOTIFY_EVFLAGS (O_LARGEFILE|O_RDONLY|O_CLOEXEC)
>
> int fanotify_d = fanotify_init(FANOTIFY_FLAGS, FANOTIFY_EVFLAGS);
>
> - in examples [4] from "Filesystem monitoring in the Linux
> kernel" article[5] by Aleksander Morgado:
>
> if ((fanotify_fd = fanotify_init (FAN_CLOEXEC,
> O_RDONLY | O_CLOEXEC | O_LARGEFILE)) <
> 0)
So we have a number of apps which are setting O_CLOEXEC, but it doesn't
actually work. With this change it *will* work, so the behaviour of
those apps might change, possibly breaking them?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] iommu/vt-d: Keep RMRR mappings around on driver unbind
On Tue, Sep 30, 2014 at 01:02:01PM +0200, Joerg Roedel wrote: > Hi, > > here is a patch-set to fix an issue recently discovered when > the Intel IOMMU is in use with devices that need RMRR > mappings. > > The problem is that the RMRR mappings are destroyed when the > device driver is unbound from the device, causing DMAR > faults. > > To solve this problem a device driver core change is > necessary to catch the right point in time for the IOMMU > code to destroy any mappings for a device. > > With this patch-set the RMRR mappings are only destroyed > when the device is actually removed from the system. > > Please review. I have no objection to these, do you want me to take them through my tree? Or if they are going through some other one feel free to add: Acked-by: Greg Kroah-Hartman To the first patch. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1 linux-next] net/dccp/ccid.c: add __init to ccid_activate
From: Fabian Frederick Date: Wed, 1 Oct 2014 06:52:06 +0200 > ccid_activate is only called by __init ccid_initialize_builtins in same > module. > > Signed-off-by: Fabian Frederick Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 linux-next] net/dccp/proto.c: add __init to dccp_mib_init
From: Fabian Frederick Date: Wed, 1 Oct 2014 06:48:03 +0200 > dccp_mib_init is only called by __init dccp_init in same module. > > Signed-off-by: Fabian Frederick Applied. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: pipe/page fault oddness.
On Wed, 01 Oct 2014 18:08:30 -0400 Sasha Levin wrote: > On 10/01/2014 04:20 PM, Linus Torvalds wrote: > > So I'm really sending this patch out in the hope that it will get > > comments, fixup and possibly even testing by people who actually know > > the NUMA balancing code. Rik? Anybody? > > Hi Linus, > > I've tried this patch on the same configuration that was triggering > the VM_BUG_ON that Hugh mentioned previously. Surprisingly enough it > ran fine for ~20 minutes before exploding with: > > [ 2781.566206] kernel BUG at mm/huge_memory.c:1293! That's: BUG_ON(is_huge_zero_page(page)); Can you change your scripts to show the source code line when the error is a BUG_ON()? The machine code disassembly after the oops message doesn't really help. > [ 2781.566953] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC > [ 2781.568054] Dumping ftrace buffer: > [ 2781.568826](ftrace buffer empty) > [ 2781.569392] Modules linked in: > [ 2781.569909] CPU: 61 PID: 13111 Comm: trinity-c61 Not tainted > 3.17.0-rc7-sasha-00040-g65e1cb2 #1259 > [ 2781.571077] task: 88050ba8 ti: 880418ecc000 task.ti: > 880418ecc000 > [ 2781.571077] RIP: do_huge_pmd_numa_page (mm/huge_memory.c:1293 > (discriminator 1)) > [ 2781.571077] RSP: :880418ecfc60 EFLAGS: 00010246 > [ 2781.571077] RAX: ea0074c6 RBX: ea0074c6 RCX: > 001d318009e0 > [ 2781.571077] RDX: ea00 RSI: b5706ef3 RDI: > 001d318009e0 > [ 2781.571077] RBP: 880418ecfcc8 R08: 0038 R09: > 0001 > [ 2781.571077] R10: 0038 R11: 0001 R12: > 8804f9b52000 > [ 2781.571077] R13: 001d318009e0 R14: 880508a1f840 R15: > 0028 > [ 2781.571077] FS: 7f5502fc9700() GS:881d77e0() > knlGS: > [ 2781.571077] CS: 0010 DS: ES: CR0: 80050033 > [ 2781.571077] CR2: CR3: 0004bfac4000 CR4: > 06a0 > [ 2781.571077] Stack: > [ 2781.571077] 880418ecfc98 0282 88050ba8 > 000b > [ 2781.571077] 88060d2ab000 8806001d > 881d30b3ec00 > [ 2781.571077] 881d30b3ec00 88060d2ab000 > 0100 > [ 2781.571077] Call Trace: > [ 2781.571077] handle_mm_fault (mm/memory.c:3304 mm/memory.c:3368) > [ 2781.571077] __do_page_fault (arch/x86/mm/fault.c:1231) > [ 2781.571077] ? kvm_clock_read (./arch/x86/include/asm/preempt.h:90 > arch/x86/kernel/kvmclock.c:86) > [ 2781.571077] ? sched_clock (./arch/x86/include/asm/paravirt.h:192 > arch/x86/kernel/tsc.c:304) > [ 2781.571077] ? sched_clock_local (kernel/sched/clock.c:214) > [ 2781.571077] ? context_tracking_user_exit (kernel/context_tracking.c:184) > [ 2781.571077] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63) > [ 2781.571077] ? trace_hardirqs_off_caller (kernel/locking/lockdep.c:2641 > (discriminator 8)) > [ 2781.571077] trace_do_page_fault (arch/x86/mm/fault.c:1314 > include/linux/jump_label.h:115 include/linux/context_tracking_state.h:27 > include/linux/context_tracking.h:45 arch/x86/mm/fault.c:1315) > [ 2781.571077] do_async_page_fault (arch/x86/kernel/kvm.c:279) > [ 2781.571077] async_page_fault (arch/x86/kernel/entry_64.S:1314) > [ 2781.571077] ? copy_user_generic_unrolled (arch/x86/lib/copy_user_64.S:166) > [ 2781.571077] ? sys32_mmap (arch/x86/ia32/sys_ia32.c:159) > [ 2781.571077] ia32_do_call (arch/x86/ia32/ia32entry.S:430) > [ 2781.571077] Code: b4 eb e0 0f 1f 84 00 00 00 00 00 4c 89 f7 e8 88 2f 0c 03 > 48 8b 45 d0 4c 89 e6 48 8b b8 88 00 00 00 e8 85 c7 ff ff e9 90 fe ff ff <0f> > 0b 66 0f 1f 44 00 00 48 89 df e8 90 e9 f9 ff 84 c0 0f 85 be > All code > >0: b4 eb mov$0xeb,%ah >2: e0 0f loopne 0x13 >4: 1f (bad) >5: 84 00 test %al,(%rax) >7: 00 00 add%al,(%rax) >9: 00 00 add%al,(%rax) >b: 4c 89 f7mov%r14,%rdi >e: e8 88 2f 0c 03 callq 0x30c2f9b > 13: 48 8b 45 d0 mov-0x30(%rbp),%rax > 17: 4c 89 e6mov%r12,%rsi > 1a: 48 8b b8 88 00 00 00mov0x88(%rax),%rdi > 21: e8 85 c7 ff ff callq 0xc7ab > 26: e9 90 fe ff ff jmpq 0xfebb > 2b:*0f 0b ud2 <-- trapping instruction > 2d: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) > 33: 48 89 dfmov%rbx,%rdi > 36: e8 90 e9 f9 ff callq 0xfff9e9cb > 3b: 84 c0 test %al,%al > 3d: 0f .byte 0xf > 3e: 85 .byte 0x85 > 3f: be .byte 0xbe > ... > > Code starting with the faulting instruction > === >0: 0f 0b ud2 >2: 66 0f 1f 44 00 00 nopw
Re: [PATCH v4 4/4] pmbus: ltc2978: add regulator support
On Wed, 1 Oct 2014, Guenter Roeck wrote: > On Wed, Oct 01, 2014 at 03:18:20PM -0500, at...@opensource.altera.com wrote: > > From: Alan Tull > > > > Add simple on/off regulator support for ltc2978 and > > other pmbus parts supported by ltc2978.c > > > > Signed-off-by: Alan Tull > > > > v2: Remove '#include ' > > Only one regulator per pmbus device > > Get regulator_init_data from pdata or device tree > > > > v3: Support multiple regulators for each chip > > Move most code to pmbus_core.c > > fixed values for on/off > > > > v4: fix a #endif comment > > simplify probe code, remove added switch statement > > remove BUG_ON(), add error message and fix num_regulators > > --- > > drivers/hwmon/pmbus/Kconfig |7 +++ > > drivers/hwmon/pmbus/ltc2978.c | 37 + > > 2 files changed, 44 insertions(+) > > > > diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig > > index 6e1e493..79117b7 100644 > > --- a/drivers/hwmon/pmbus/Kconfig > > +++ b/drivers/hwmon/pmbus/Kconfig > > @@ -56,6 +56,13 @@ config SENSORS_LTC2978 > > This driver can also be built as a module. If so, the module will > > be called ltc2978. > > > > +config SENSORS_LTC2978_REGULATOR > > + boolean "Regulator support for LTC2974, LTC2978, LTC3880, and LTC3883" > > We will need to update this and SENSORS_LTC2978 and add LTC2977 as well as > LTM4646 to the list of supported chips. > > Guenter I will add the whole list to the 'help' sections of SENSORS_LTC2978 and SENSORS_LTC2978_REGULATOR. For the tristate/boolean lines, I can't fit the whole list, so I will leave them as they are. Or I could change to 'LTC2978 and compatibles' as many others in this Kconfig have. Alan > > > + depends on SENSORS_LTC2978 && REGULATOR > > + help > > + If you say yes here you get regulator support for Linear > > + Technology LTC2974, LTC2978, LTC3880, and LTC3883. > > + -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND] MIPS/loongson2_cpufreq: Fix CPU clock rate setting mismerge
During 3.16 merge window, parts of the commit 8e8acb32960f
(MIPS/loongson2_cpufreq: Fix CPU clock rate setting) seem to have
been deleted probably due to a mismerge, and as a result cpufreq
is broken again on Loongson2 boards in 3.16 and newer kernels.
Fix by repeating the fix.
Signed-off-by: Aaro Koskinen
Cc: sta...@vger.kernel.org # 3.16
---
arch/mips/loongson/lemote-2f/clock.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/mips/loongson/lemote-2f/clock.c
b/arch/mips/loongson/lemote-2f/clock.c
index a217061..462e34d 100644
--- a/arch/mips/loongson/lemote-2f/clock.c
+++ b/arch/mips/loongson/lemote-2f/clock.c
@@ -91,6 +91,7 @@ EXPORT_SYMBOL(clk_put);
int clk_set_rate(struct clk *clk, unsigned long rate)
{
+ unsigned int rate_khz = rate / 1000;
struct cpufreq_frequency_table *pos;
int ret = 0;
int regval;
@@ -107,9 +108,9 @@ int clk_set_rate(struct clk *clk, unsigned long rate)
propagate_rate(clk);
cpufreq_for_each_valid_entry(pos, loongson2_clockmod_table)
- if (rate == pos->frequency)
+ if (rate_khz == pos->frequency)
break;
- if (rate != pos->frequency)
+ if (rate_khz != pos->frequency)
return -ENOTSUPP;
clk->rate = rate;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/4] pmbus: ltc2978: add regulator support
On Wed, 1 Oct 2014, Guenter Roeck wrote:
> On Wed, Oct 01, 2014 at 03:18:20PM -0500, at...@opensource.altera.com wrote:
> > From: Alan Tull
> >
> > Add simple on/off regulator support for ltc2978 and
> > other pmbus parts supported by ltc2978.c
> >
> > Signed-off-by: Alan Tull
> >
> > v2: Remove '#include '
> > Only one regulator per pmbus device
> > Get regulator_init_data from pdata or device tree
> >
> > v3: Support multiple regulators for each chip
> > Move most code to pmbus_core.c
> > fixed values for on/off
> >
> > v4: fix a #endif comment
> > simplify probe code, remove added switch statement
> > remove BUG_ON(), add error message and fix num_regulators
> > ---
> > drivers/hwmon/pmbus/Kconfig |7 +++
> > drivers/hwmon/pmbus/ltc2978.c | 37 +
> > 2 files changed, 44 insertions(+)
> >
> > diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
> > index 6e1e493..79117b7 100644
> > --- a/drivers/hwmon/pmbus/Kconfig
> > +++ b/drivers/hwmon/pmbus/Kconfig
> > @@ -56,6 +56,13 @@ config SENSORS_LTC2978
> > This driver can also be built as a module. If so, the module will
> > be called ltc2978.
> >
> > +config SENSORS_LTC2978_REGULATOR
> > + boolean "Regulator support for LTC2974, LTC2978, LTC3880, and LTC3883"
>
> We will need to update this and SENSORS_LTC2978 and add LTC2977 as well as
> LTM4646 to the list of supported chips.
>
> Guenter
OK
Alan
>
> > + depends on SENSORS_LTC2978 && REGULATOR
> > + help
> > + If you say yes here you get regulator support for Linear
> > + Technology LTC2974, LTC2978, LTC3880, and LTC3883.
> > +
> > config SENSORS_MAX16064
> > tristate "Maxim MAX16064"
> > default n
> > diff --git a/drivers/hwmon/pmbus/ltc2978.c b/drivers/hwmon/pmbus/ltc2978.c
> > index e24ed52..422712e 100644
> > --- a/drivers/hwmon/pmbus/ltc2978.c
> > +++ b/drivers/hwmon/pmbus/ltc2978.c
> > @@ -22,6 +22,8 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > #include "pmbus.h"
> >
> > enum chips { ltc2974, ltc2977, ltc2978, ltc3880, ltc3883, ltm4676 };
> > @@ -374,6 +376,30 @@ static const struct i2c_device_id ltc2978_id[] = {
> > };
> > MODULE_DEVICE_TABLE(i2c, ltc2978_id);
> >
> > +#if IS_ENABLED(CONFIG_SENSORS_LTC2978_REGULATOR)
> > +static const struct regulator_desc ltc2978_reg_desc[] = {
> > + PMBUS_REGULATOR("vout_en", 0),
> > + PMBUS_REGULATOR("vout_en", 1),
> > + PMBUS_REGULATOR("vout_en", 2),
> > + PMBUS_REGULATOR("vout_en", 3),
> > + PMBUS_REGULATOR("vout_en", 4),
> > + PMBUS_REGULATOR("vout_en", 5),
> > + PMBUS_REGULATOR("vout_en", 6),
> > + PMBUS_REGULATOR("vout_en", 7),
> > +};
> > +
> > +static struct of_regulator_match ltc2978_reg_matches[] = {
> > + { .name = "vout_en0" },
> > + { .name = "vout_en1" },
> > + { .name = "vout_en2" },
> > + { .name = "vout_en3" },
> > + { .name = "vout_en4" },
> > + { .name = "vout_en5" },
> > + { .name = "vout_en6" },
> > + { .name = "vout_en7" },
> > +};
> > +#endif /* CONFIG_SENSORS_LTC2978_REGULATOR */
> > +
> > static int ltc2978_probe(struct i2c_client *client,
> > const struct i2c_device_id *id)
> > {
> > @@ -487,6 +513,17 @@ static int ltc2978_probe(struct i2c_client *client,
> > default:
> > return -ENODEV;
> > }
> > +
> > +#if IS_ENABLED(CONFIG_SENSORS_LTC2978_REGULATOR)
> > + info->num_regulators = info->pages;
> > + info->reg_desc = ltc2978_reg_desc;
> > + info->reg_matches = ltc2978_reg_matches;
> > + if (info->num_regulators > ARRAY_SIZE(ltc2978_reg_desc)) {
> > + dev_err(>dev, "num_regulators too large!");
> > + info->num_regulators = ARRAY_SIZE(ltc2978_reg_desc);
> > + }
> > +#endif
> > +
> > return pmbus_do_probe(client, id, info);
> > }
> >
> > --
> > 1.7.9.5
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: rts5208: Clean up coding style in rtsx_chip.c to get rid of checkpatch.pl warnings
Fix 10 occurences of coding style errors where the line exceeds 80 characters
by breaking them into more lines.
Checkpatch.pl reports these errors as: 'WARNING: line over 80 characters'
Also, removes unnecessary returns in two void functions by removing the return
statements.
Checkpatch.pl reports these errors as: 'WARNING: void function return
statements are not generally useful'
Patch is against Greg KH's staging-next tree.
Signed-off-by: Giedrius Statkevicius
---
drivers/staging/rts5208/rtsx_chip.c | 40 -
1 file changed, 26 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx_chip.c
b/drivers/staging/rts5208/rtsx_chip.c
index 1411471..d604341 100644
--- a/drivers/staging/rts5208/rtsx_chip.c
+++ b/drivers/staging/rts5208/rtsx_chip.c
@@ -291,7 +291,9 @@ int rtsx_reset_chip(struct rtsx_chip *chip)
if (chip->dynamic_aspm) {
if (CHK_SDIO_EXIST(chip)) {
if (CHECK_PID(chip, 0x5288)) {
- retval = rtsx_write_cfg_dw(chip, 2,
0xC0, 0xFF, chip->aspm_l0s_l1_en);
+ retval = rtsx_write_cfg_dw(chip, 2,
+ 0xC0, 0xFF,
+ chip->aspm_l0s_l1_en);
if (retval != STATUS_SUCCESS)
TRACE_RET(chip, STATUS_FAIL);
}
@@ -310,9 +312,13 @@ int rtsx_reset_chip(struct rtsx_chip *chip)
if (CHK_SDIO_EXIST(chip)) {
chip->aspm_level[1] = chip->aspm_l0s_l1_en;
if (CHECK_PID(chip, 0x5288))
- retval = rtsx_write_cfg_dw(chip, 2,
0xC0, 0xFF, chip->aspm_l0s_l1_en);
+ retval = rtsx_write_cfg_dw(chip, 2,
+ 0xC0, 0xFF,
+ chip->aspm_l0s_l1_en);
else
- retval = rtsx_write_cfg_dw(chip, 1,
0xC0, 0xFF, chip->aspm_l0s_l1_en);
+ retval = rtsx_write_cfg_dw(chip, 1,
+ 0xC0, 0xFF,
+ chip->aspm_l0s_l1_en);
if (retval != STATUS_SUCCESS)
TRACE_RET(chip, STATUS_FAIL);
@@ -966,7 +972,8 @@ void rtsx_polling_func(struct rtsx_chip *chip)
dev_dbg(rtsx_dev(chip), "SDIO enter
ASPM!\n");
rtsx_write_register(chip,
ASPM_FORCE_CTL, 0xFC,
- 0x30 | (chip->aspm_level[1] <<
2));
+ 0x30 |
+ (chip->aspm_level[1] << 2));
chip->sdio_aspm = 1;
}
}
@@ -988,8 +995,10 @@ void rtsx_polling_func(struct rtsx_chip *chip)
turn_off_led(chip, LED_GPIO);
- if (chip->auto_power_down && !chip->card_ready &&
!chip->sd_io)
- rtsx_force_power_down(chip, SSC_PDCTL |
OC_PDCTL);
+ if (chip->auto_power_down && !chip->card_ready &&
+ !chip->sd_io)
+ rtsx_force_power_down(chip,
+ SSC_PDCTL | OC_PDCTL);
}
}
@@ -1081,7 +1090,9 @@ Delink_Stage:
dev_dbg(rtsx_dev(chip), "False card
inserted, do force delink\n");
if (enter_L1)
- rtsx_write_register(chip,
HOST_SLEEP_STATE, 0x03, 1);
+ rtsx_write_register(chip,
+ HOST_SLEEP_STATE,
+ 0x03, 1);
rtsx_write_register(chip,
CHANGE_LINK_STATE, 0x0A,
@@ -1090,14 +1101,19 @@ Delink_Stage:
if (enter_L1)
rtsx_enter_L1(chip);
- chip->auto_delink_cnt =
delink_stage3_cnt + 1;
+ chip->auto_delink_cnt =
+ delink_stage3_cnt + 1;
} else {
Re: Adding a filter to events (instead of replacing one) was Re: [PATCH 1/2] perf, tools: Add PERF_PID
Em Wed, Oct 01, 2014 at 03:02:18PM -0700, Andi Kleen escreveu: > On Wed, Oct 01, 2014 at 03:03:16PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Wed, Sep 24, 2014 at 01:51:08PM -0700, Andi Kleen escreveu: > > > It's currently difficult to filter out perf itself using a filter. > > > This can give cascading effects during IO tracing when the IO perf > > > does itself causes more trace output. > > > The best way to filter is to use the pid. But it's difficult to get the > > > pid > > > of perf without using hacks. > > > Add a PERF_PID meta variable to the perf filter that contains the current > > > pid. > > > With this patch the following works > > > % perf record -e syscalls:sys_enter_write -a --filter 'common_pid != > > > PERF_PID' ... > > So I tried this one now and saw the other patch, that applies the > > --filter to all events, while trying I got: > Patch seems reasonable to me. > However adding PERF_PID and sanitizing --filter are really two > different things and should probably not be mixed in a patch. Yes, there are two things, but what seems to be wanted first is a way to exclude 'perf record' samples, for all events. Being able to specify PERF_PID on a filter so that some events can include 'perf record' samples and some not seems to be something not really needed at this point, i.e. just doing: perf record --filter-self -e syscalls:sys_enter_write -a ... Is shorter and doesn't breaks the current --filter semantic (apply just to the last tracepoint informed in the cmdline, not to all tracepoints) like in your second patch. So probably what is best to do is to finish the patch I sent here, which will cover the filter-out-perf-tooling-samples usecase, and then, if people still think it is needed, introduce the PERF_PID meta filter variable. - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH v1 1/2] genirq: Fix error path for resuming irqs
On Thursday, October 02, 2014 12:25:08 AM Rafael J. Wysocki wrote:
> On Wednesday, October 01, 2014 01:48:39 PM dbasehore . wrote:
> > Adding maintainers for affected systems to this CL for review.
> >
> > On Mon, Jul 7, 2014 at 8:33 AM, Konrad Rzeszutek Wilk
> > wrote:
> > > On Fri, Jun 27, 2014 at 05:04:24PM -0700, Derek Basehore wrote:
> > >> In the case of a late abort to suspend/hibernate, irqs marked with
> > >> IRQF_EARLY_RESUME will not be enabled. This is due to syscore_resume not
> > >> getting
> > >> called on these paths.
> > >>
> > >> This can happen with a pm test for platform, a late wakeup irq, and other
> > >> instances. This change removes the function from syscore and calls it
> > >> explicitly
> > >> in suspend, hibernate, etc.
> > >>
> > >> This regression was introduced in 9bab0b7f "genirq: Add
> > >> IRQF_RESUME_EARLY"
> > >>
> > >> Signed-off-by: Derek Basehore
> > >
> > > Tested-by: Konrad Rzeszutek Wilk
> > >
> > > on the Xen side.
> > >> ---
> > >> drivers/base/power/main.c | 5 -
> > >> drivers/xen/manage.c | 5 -
> > >> include/linux/interrupt.h | 1 +
> > >> include/linux/pm.h| 2 +-
> > >> kernel/irq/pm.c | 17 +++--
> > >> kernel/kexec.c| 2 +-
> > >> kernel/power/hibernate.c | 6 +++---
> > >> kernel/power/suspend.c| 2 +-
> > >> 8 files changed, 18 insertions(+), 22 deletions(-)
> > >>
> > >> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> > >> index bf41296..a087473 100644
> > >> --- a/drivers/base/power/main.c
> > >> +++ b/drivers/base/power/main.c
> > >> @@ -712,8 +712,10 @@ static void dpm_resume_early(pm_message_t state)
> > >> * dpm_resume_start - Execute "noirq" and "early" device callbacks.
> > >> * @state: PM transition of the system being carried out.
> > >> */
> > >> -void dpm_resume_start(pm_message_t state)
> > >> +void dpm_resume_start(pm_message_t state, bool enable_early_irqs)
> > >> {
> > >> + if (enable_early_irqs)
> > >> + early_resume_device_irqs();
>
> This conflicts with some changes I've already queued up for merging.
>
> Why don't you do that in dpm_resume_noirq() directly? Also why do we need
> the extra argument here? The only case when we pass 'false' apprears to be
> the Xen one, so perhaps we can use a special PM_EVENT_XEN flag or something
> similar to indicate that? Honestly, I don't want to litter the regular
> suspend
> code with Xen-specific stuff like this.
BTW, is dpm_resume_noirq() early enough? What about the time we bring up
the non-boot CPUs? Don't we need to call the early_resume_device_irqs()
thing before that?
> > >> dpm_resume_noirq(state);
> > >> dpm_resume_early(state);
> > >> }
> > >> @@ -1132,6 +1134,7 @@ static int dpm_suspend_noirq(pm_message_t state)
> > >> if (error) {
> > >> suspend_stats.failed_suspend_noirq++;
> > >> dpm_save_failed_step(SUSPEND_SUSPEND_NOIRQ);
> > >> + early_resume_device_irqs();
> > >> dpm_resume_noirq(resume_event(state));
> > >> } else {
> > >> dpm_show_time(starttime, state, "noirq");
> > >> diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
> > >> index c3667b2..d387cdf 100644
> > >> --- a/drivers/xen/manage.c
> > >> +++ b/drivers/xen/manage.c
> > >> @@ -68,6 +68,7 @@ static int xen_suspend(void *data)
> > >> err = syscore_suspend();
> > >> if (err) {
> > >> pr_err("%s: system core suspend failed: %d\n", __func__,
> > >> err);
> > >> + early_resume_device_irqs();
> > >> return err;
> > >> }
> > >>
> > >> @@ -92,6 +93,8 @@ static int xen_suspend(void *data)
> > >> xen_timer_resume();
> > >> }
> > >>
> > >> + early_resume_device_irqs();
> > >> +
> > >> syscore_resume();
> > >>
> > >> return 0;
> > >> @@ -137,7 +140,7 @@ static void do_suspend(void)
> > >>
> > >> raw_notifier_call_chain(_resume_notifier, 0, NULL);
> > >>
> > >> - dpm_resume_start(si.cancelled ? PMSG_THAW : PMSG_RESTORE);
> > >> + dpm_resume_start(si.cancelled ? PMSG_THAW : PMSG_RESTORE, false);
> > >>
> > >> if (err) {
> > >> pr_err("failed to start xen_suspend: %d\n", err);
> > >> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> > >> index 698ad05..7f390e3 100644
> > >> --- a/include/linux/interrupt.h
> > >> +++ b/include/linux/interrupt.h
> > >> @@ -193,6 +193,7 @@ extern void irq_wake_thread(unsigned int irq, void
> > >> *dev_id);
> > >> /* The following three functions are for the core kernel use only. */
> > >> extern void suspend_device_irqs(void);
> > >> extern void resume_device_irqs(void);
> > >> +extern void early_resume_device_irqs(void);
> > >> #ifdef CONFIG_PM_SLEEP
> > >> extern int check_wakeup_irqs(void);
> > >> #else
> > >> diff --git a/include/linux/pm.h b/include/linux/pm.h
> > >> index 72c0fe0..ae5b26a 100644
> > >> ---
Re: pipe/page fault oddness.
On 10/01/2014 04:20 PM, Linus Torvalds wrote: > So I'm really sending this patch out in the hope that it will get > comments, fixup and possibly even testing by people who actually know > the NUMA balancing code. Rik? Anybody? Hi Linus, I've tried this patch on the same configuration that was triggering the VM_BUG_ON that Hugh mentioned previously. Surprisingly enough it ran fine for ~20 minutes before exploding with: [ 2781.566206] kernel BUG at mm/huge_memory.c:1293! [ 2781.566953] invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 2781.568054] Dumping ftrace buffer: [ 2781.568826](ftrace buffer empty) [ 2781.569392] Modules linked in: [ 2781.569909] CPU: 61 PID: 13111 Comm: trinity-c61 Not tainted 3.17.0-rc7-sasha-00040-g65e1cb2 #1259 [ 2781.571077] task: 88050ba8 ti: 880418ecc000 task.ti: 880418ecc000 [ 2781.571077] RIP: do_huge_pmd_numa_page (mm/huge_memory.c:1293 (discriminator 1)) [ 2781.571077] RSP: :880418ecfc60 EFLAGS: 00010246 [ 2781.571077] RAX: ea0074c6 RBX: ea0074c6 RCX: 001d318009e0 [ 2781.571077] RDX: ea00 RSI: b5706ef3 RDI: 001d318009e0 [ 2781.571077] RBP: 880418ecfcc8 R08: 0038 R09: 0001 [ 2781.571077] R10: 0038 R11: 0001 R12: 8804f9b52000 [ 2781.571077] R13: 001d318009e0 R14: 880508a1f840 R15: 0028 [ 2781.571077] FS: 7f5502fc9700() GS:881d77e0() knlGS: [ 2781.571077] CS: 0010 DS: ES: CR0: 80050033 [ 2781.571077] CR2: CR3: 0004bfac4000 CR4: 06a0 [ 2781.571077] Stack: [ 2781.571077] 880418ecfc98 0282 88050ba8 000b [ 2781.571077] 88060d2ab000 8806001d 881d30b3ec00 [ 2781.571077] 881d30b3ec00 88060d2ab000 0100 [ 2781.571077] Call Trace: [ 2781.571077] handle_mm_fault (mm/memory.c:3304 mm/memory.c:3368) [ 2781.571077] __do_page_fault (arch/x86/mm/fault.c:1231) [ 2781.571077] ? kvm_clock_read (./arch/x86/include/asm/preempt.h:90 arch/x86/kernel/kvmclock.c:86) [ 2781.571077] ? sched_clock (./arch/x86/include/asm/paravirt.h:192 arch/x86/kernel/tsc.c:304) [ 2781.571077] ? sched_clock_local (kernel/sched/clock.c:214) [ 2781.571077] ? context_tracking_user_exit (kernel/context_tracking.c:184) [ 2781.571077] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63) [ 2781.571077] ? trace_hardirqs_off_caller (kernel/locking/lockdep.c:2641 (discriminator 8)) [ 2781.571077] trace_do_page_fault (arch/x86/mm/fault.c:1314 include/linux/jump_label.h:115 include/linux/context_tracking_state.h:27 include/linux/context_tracking.h:45 arch/x86/mm/fault.c:1315) [ 2781.571077] do_async_page_fault (arch/x86/kernel/kvm.c:279) [ 2781.571077] async_page_fault (arch/x86/kernel/entry_64.S:1314) [ 2781.571077] ? copy_user_generic_unrolled (arch/x86/lib/copy_user_64.S:166) [ 2781.571077] ? sys32_mmap (arch/x86/ia32/sys_ia32.c:159) [ 2781.571077] ia32_do_call (arch/x86/ia32/ia32entry.S:430) [ 2781.571077] Code: b4 eb e0 0f 1f 84 00 00 00 00 00 4c 89 f7 e8 88 2f 0c 03 48 8b 45 d0 4c 89 e6 48 8b b8 88 00 00 00 e8 85 c7 ff ff e9 90 fe ff ff <0f> 0b 66 0f 1f 44 00 00 48 89 df e8 90 e9 f9 ff 84 c0 0f 85 be All code 0: b4 eb mov$0xeb,%ah 2: e0 0f loopne 0x13 4: 1f (bad) 5: 84 00 test %al,(%rax) 7: 00 00 add%al,(%rax) 9: 00 00 add%al,(%rax) b: 4c 89 f7mov%r14,%rdi e: e8 88 2f 0c 03 callq 0x30c2f9b 13: 48 8b 45 d0 mov-0x30(%rbp),%rax 17: 4c 89 e6mov%r12,%rsi 1a: 48 8b b8 88 00 00 00mov0x88(%rax),%rdi 21: e8 85 c7 ff ff callq 0xc7ab 26: e9 90 fe ff ff jmpq 0xfebb 2b:* 0f 0b ud2 <-- trapping instruction 2d: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) 33: 48 89 dfmov%rbx,%rdi 36: e8 90 e9 f9 ff callq 0xfff9e9cb 3b: 84 c0 test %al,%al 3d: 0f .byte 0xf 3e: 85 .byte 0x85 3f: be .byte 0xbe ... Code starting with the faulting instruction === 0: 0f 0b ud2 2: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) 8: 48 89 dfmov%rbx,%rdi b: e8 90 e9 f9 ff callq 0xfff9e9a0 10: 84 c0 test %al,%al 12: 0f .byte 0xf 13: 85 .byte 0x85 14: be .byte 0xbe ... [ 2781.571077] RIP do_huge_pmd_numa_page (mm/huge_memory.c:1293 (discriminator 1)) [ 2781.571077] RSP Thanks, Sasha
Re: [PATCH 2/3] ARM: vfp: fix VFPv3 hwcap detection on non-ARM vfp implementations
On 10/01/14 14:50, Russell King - ARM Linux wrote:
> On Fri, Sep 19, 2014 at 11:24:01AM -0700, Stephen Boyd wrote:
>>
>> Do you, or anyone else, know of other implementations? I *hope* that
>> this same exercise was done by the VFP architects before they
>> re-purposed bits but who knows. If nobody is actually setting these
>> higher bits then is there any problem widening the mask (besides it
>> being slightly confusing)?
> There are certainly non-ARM implementations around, eg:
>
> VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5
Can you provide the raw value of the id register or at least bits 22:16?
This print is currently masking off the bits so we don't know what's
there. All we know is that bit 20 is not set because it doesn't fail to
initialize vfp.
>
> which is from Marvell Dove. I don't know how the other Marvell offerings
> identify. I wouldn't be surprised if there were other implementations
> from other vendors too.
>
> However, if we do have any implementation which indicates that it does
> not support both single and double precision ops (bit 20), then today
> the VFP support code refuses to initialise, and the system will behave
> as if there is no VFP present.
>
> So, the problem case is whether we do have non-ARM produced implementations
> where the VFP code refuses to init, which would then be misidentified as
> some insane architecture version.
>
I'm not aware of anything. You would know better than I though.
That check assumes a v2. We should update that check to only look for v2
or less (this isn't based on the current patch but can be squashed in).
---8<---
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 2f37e1d6cb45..22d6a1171a4e 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -738,14 +738,18 @@ static int __init vfp_init(void)
vfp_vector = vfp_null_entry;
pr_info("VFP support v0.3: ");
- if (VFP_arch)
+ if (VFP_arch) {
pr_cont("not present\n");
- else if (vfpsid & FPSID_NODOUBLE) {
- pr_cont("no double precision support\n");
} else {
hotcpu_notifier(vfp_hotplug, 0);
VFP_arch = (vfpsid & FPSID_ARCH_MASK) >> FPSID_ARCH_BIT; /*
Extract the architecture version */
+
+ if (VFP_arch < 2 && (vfpsid & FPSID_NODOUBLE)) {
+ pr_cont("no double precision support\n");
+ return 0;
+ }
+
pr_cont("implementor %02x architecture %d part %02x variant %x
rev %x\n",
(vfpsid & FPSID_IMPLEMENTER_MASK) >>
FPSID_IMPLEMENTER_BIT,
(vfpsid & FPSID_ARCH_MASK) >> FPSID_ARCH_BIT,
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH v1 1/2] genirq: Fix error path for resuming irqs
On Wednesday, October 01, 2014 01:48:39 PM dbasehore . wrote:
> Adding maintainers for affected systems to this CL for review.
>
> On Mon, Jul 7, 2014 at 8:33 AM, Konrad Rzeszutek Wilk
> wrote:
> > On Fri, Jun 27, 2014 at 05:04:24PM -0700, Derek Basehore wrote:
> >> In the case of a late abort to suspend/hibernate, irqs marked with
> >> IRQF_EARLY_RESUME will not be enabled. This is due to syscore_resume not
> >> getting
> >> called on these paths.
> >>
> >> This can happen with a pm test for platform, a late wakeup irq, and other
> >> instances. This change removes the function from syscore and calls it
> >> explicitly
> >> in suspend, hibernate, etc.
> >>
> >> This regression was introduced in 9bab0b7f "genirq: Add IRQF_RESUME_EARLY"
> >>
> >> Signed-off-by: Derek Basehore
> >
> > Tested-by: Konrad Rzeszutek Wilk
> >
> > on the Xen side.
> >> ---
> >> drivers/base/power/main.c | 5 -
> >> drivers/xen/manage.c | 5 -
> >> include/linux/interrupt.h | 1 +
> >> include/linux/pm.h| 2 +-
> >> kernel/irq/pm.c | 17 +++--
> >> kernel/kexec.c| 2 +-
> >> kernel/power/hibernate.c | 6 +++---
> >> kernel/power/suspend.c| 2 +-
> >> 8 files changed, 18 insertions(+), 22 deletions(-)
> >>
> >> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> >> index bf41296..a087473 100644
> >> --- a/drivers/base/power/main.c
> >> +++ b/drivers/base/power/main.c
> >> @@ -712,8 +712,10 @@ static void dpm_resume_early(pm_message_t state)
> >> * dpm_resume_start - Execute "noirq" and "early" device callbacks.
> >> * @state: PM transition of the system being carried out.
> >> */
> >> -void dpm_resume_start(pm_message_t state)
> >> +void dpm_resume_start(pm_message_t state, bool enable_early_irqs)
> >> {
> >> + if (enable_early_irqs)
> >> + early_resume_device_irqs();
This conflicts with some changes I've already queued up for merging.
Why don't you do that in dpm_resume_noirq() directly? Also why do we need
the extra argument here? The only case when we pass 'false' apprears to be
the Xen one, so perhaps we can use a special PM_EVENT_XEN flag or something
similar to indicate that? Honestly, I don't want to litter the regular suspend
code with Xen-specific stuff like this.
> >> dpm_resume_noirq(state);
> >> dpm_resume_early(state);
> >> }
> >> @@ -1132,6 +1134,7 @@ static int dpm_suspend_noirq(pm_message_t state)
> >> if (error) {
> >> suspend_stats.failed_suspend_noirq++;
> >> dpm_save_failed_step(SUSPEND_SUSPEND_NOIRQ);
> >> + early_resume_device_irqs();
> >> dpm_resume_noirq(resume_event(state));
> >> } else {
> >> dpm_show_time(starttime, state, "noirq");
> >> diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
> >> index c3667b2..d387cdf 100644
> >> --- a/drivers/xen/manage.c
> >> +++ b/drivers/xen/manage.c
> >> @@ -68,6 +68,7 @@ static int xen_suspend(void *data)
> >> err = syscore_suspend();
> >> if (err) {
> >> pr_err("%s: system core suspend failed: %d\n", __func__,
> >> err);
> >> + early_resume_device_irqs();
> >> return err;
> >> }
> >>
> >> @@ -92,6 +93,8 @@ static int xen_suspend(void *data)
> >> xen_timer_resume();
> >> }
> >>
> >> + early_resume_device_irqs();
> >> +
> >> syscore_resume();
> >>
> >> return 0;
> >> @@ -137,7 +140,7 @@ static void do_suspend(void)
> >>
> >> raw_notifier_call_chain(_resume_notifier, 0, NULL);
> >>
> >> - dpm_resume_start(si.cancelled ? PMSG_THAW : PMSG_RESTORE);
> >> + dpm_resume_start(si.cancelled ? PMSG_THAW : PMSG_RESTORE, false);
> >>
> >> if (err) {
> >> pr_err("failed to start xen_suspend: %d\n", err);
> >> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> >> index 698ad05..7f390e3 100644
> >> --- a/include/linux/interrupt.h
> >> +++ b/include/linux/interrupt.h
> >> @@ -193,6 +193,7 @@ extern void irq_wake_thread(unsigned int irq, void
> >> *dev_id);
> >> /* The following three functions are for the core kernel use only. */
> >> extern void suspend_device_irqs(void);
> >> extern void resume_device_irqs(void);
> >> +extern void early_resume_device_irqs(void);
> >> #ifdef CONFIG_PM_SLEEP
> >> extern int check_wakeup_irqs(void);
> >> #else
> >> diff --git a/include/linux/pm.h b/include/linux/pm.h
> >> index 72c0fe0..ae5b26a 100644
> >> --- a/include/linux/pm.h
> >> +++ b/include/linux/pm.h
> >> @@ -677,7 +677,7 @@ struct dev_pm_domain {
> >>
> >> #ifdef CONFIG_PM_SLEEP
> >> extern void device_pm_lock(void);
> >> -extern void dpm_resume_start(pm_message_t state);
> >> +extern void dpm_resume_start(pm_message_t state, bool enable_early_irqs);
> >> extern void dpm_resume_end(pm_message_t state);
> >> extern void dpm_resume(pm_message_t state);
> >> extern void dpm_complete(pm_message_t state);
> >> diff --git
Re: Adding a filter to events (instead of replacing one) was Re: [PATCH 1/2] perf, tools: Add PERF_PID
On Wed, Oct 01, 2014 at 03:03:16PM -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Sep 24, 2014 at 01:51:08PM -0700, Andi Kleen escreveu: > > > It's currently difficult to filter out perf itself using a filter. > > This can give cascading effects during IO tracing when the IO perf > > does itself causes more trace output. > > > The best way to filter is to use the pid. But it's difficult to get the pid > > of perf without using hacks. > > > Add a PERF_PID meta variable to the perf filter that contains the current > > pid. > > > With this patch the following works > > > % perf record -e syscalls:sys_enter_write -a --filter 'common_pid != > > PERF_PID' ... > > So I tried this one now and saw the other patch, that applies the > --filter to all events, while trying I got: Patch seems reasonable to me. However adding PERF_PID and sanitizing --filter are really two different things and should probably not be mixed in a patch. -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/
[PATCH 2/3] net/rds: do proper house keeping if connection fails in rds_tcp_conn_connect
I see two problems if we consider the sock->ops->connect attempt to fail in
rds_tcp_conn_connect. The first issue is that for example we don't remove the
previously added rds_tcp_connection item to rds_tcp_tc_list at
rds_tcp_set_callbacks, which means that on a next reconnect attempt for the
same rds_connection, when rds_tcp_conn_connect is called we can again call
rds_tcp_set_callbacks, resulting in duplicated items on rds_tcp_tc_list,
leading to list corruption: to avoid this just make sure we call
properly rds_tcp_restore_callbacks before we exit. The second issue
is that we should also release the sock properly, by setting sock = NULL
only if we are returning without error.
Signed-off-by: Herton R. Krzesinski
---
net/rds/tcp_connect.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/rds/tcp_connect.c b/net/rds/tcp_connect.c
index a65ee78..f9f564a 100644
--- a/net/rds/tcp_connect.c
+++ b/net/rds/tcp_connect.c
@@ -106,11 +106,14 @@ int rds_tcp_conn_connect(struct rds_connection *conn)
rds_tcp_set_callbacks(sock, conn);
ret = sock->ops->connect(sock, (struct sockaddr *), sizeof(dest),
O_NONBLOCK);
- sock = NULL;
rdsdebug("connect to address %pI4 returned %d\n", >c_faddr, ret);
if (ret == -EINPROGRESS)
ret = 0;
+ if (ret == 0)
+ sock = NULL;
+ else
+ rds_tcp_restore_callbacks(sock, conn->c_transport_data);
out:
if (sock)
--
1.9.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/
Small fixes/changes for RDS
Hi, I got a report of one issue within RDS (after investigation it was a double free), and I'm sending the fix (patch 3/3) which reporter said it works (no more WARNING triggered on a specially instrumented kernel). The report/test was done on a very old kernel (RHEL 5, 2.6.18 based with backports), but the problem the patch handles still exists and should not change. Besides that, while reviewing some of the code but being unable to reproduce with rds_tcp, I noticed two small improvements/fixes which are in patches 1 and 2. thanks, -- []'s Herton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: vfp: fix VFPv3 hwcap detection on non-ARM vfp implementations
On Fri, Sep 19, 2014 at 11:24:01AM -0700, Stephen Boyd wrote: > Thank you for the warm welcome! I looked at the TRMs for ARM11 and ARM9. > I can't find anywhere where VFPv2 is supported and these bits are set. > > Bits 22-16 of FPSID: > > ARM1136r1p5: 0x01 > ARM1136r1p3: 0x01 > ARM1176: 0x01 > ARM11MPCorer2p0: 0x01 > ARM11MPCorer1p0: 0x01 > ARM1156: 0x01 > ARM9:0x01 > > > Do you, or anyone else, know of other implementations? I *hope* that > this same exercise was done by the VFP architects before they > re-purposed bits but who knows. If nobody is actually setting these > higher bits then is there any problem widening the mask (besides it > being slightly confusing)? There are certainly non-ARM implementations around, eg: VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 5 which is from Marvell Dove. I don't know how the other Marvell offerings identify. I wouldn't be surprised if there were other implementations from other vendors too. However, if we do have any implementation which indicates that it does not support both single and double precision ops (bit 20), then today the VFP support code refuses to initialise, and the system will behave as if there is no VFP present. So, the problem case is whether we do have non-ARM produced implementations where the VFP code refuses to init, which would then be misidentified as some insane architecture version. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
